LlamaIndex vs LangChain：RAG 框架到底怎么选

开篇：先别急着写代码，这是个架构决策

当你准备做一个RAG应用，打开GitHub搜索，第一屏几乎必然出现 LlamaIndex 和 LangChain。然后你陷入了经典的选型困境：LlamaIndex 说自己是数据框架，LangChain 说自己是应用框架，但实际功能高度重叠——都能加载文档、切块、embedding、调LLM。

更麻烦的是，选错框架的成本极高。RAG 的核心逻辑（文档切块、索引构建、检索策略）一旦用某套框架写死，迁移到另一个框架几乎等于重写。你需要的不是"哪个更好"，而是哪个更适配你的核心业务约束。本文直接给出判断依据。

竞品全景

LlamaIndex（原 GPT Index）

定位是 数据框架，专注解决"如何让 LLM 连接私有数据"。核心优势在数据层：内置 30+ 种数据连接器（LlamaHub），对文档切块、索引结构（树形、关键词、向量）有深度优化。最新版本已将数据层抽象为 StorageContext，便于替换底层向量库。适合以数据管道为核心、检索质量为生命线的场景。

LangChain

定位是 应用编排框架，强调"模型无关的应用开发"。它通过 Chain、Agent、Tool 三个抽象，把 RAG 从"文档处理"上升到"工具调用 + 多步推理"。如果你除了 RAG，还规划了 Agent 交互、工具调用、对话记忆等复杂逻辑，LangChain 的抽象层能省大量时间。代价是数据层厚度远不如 LlamaIndex。

其他竞品

• Haystack（deepset）：生产级 RAG 管道框架，强调可观测性和部署，但生态活跃度低于前两者。
• Vectara / 云厂商原生方案（如 AWS Kendra）：托管服务，几乎无代码，但绑定厂商，自定义能力弱，本文不做深入讨论。

对比维度

本次对比聚焦 5 个维度：开发体验（上手速度）、数据层深度（文档处理与索引）、生态丰富度（集成/教程）、生产可用性（部署与调试）、架构灵活性（是否敢深度定制）。性能不在表内作绝对比较，因为 RAG 性能的 70% 取决于数据清洗和切块策略，而非框架本身。

核心对比表格

深度分析

差异一：数据层 vs 编排层的优先级

LlamaIndex 的架构哲学是：数据管道是 RAG 的核心，LLM 只是管道末端的一个算子。它会对你的 PDF 做结构化解析、自动切块、生成索引。这个深度 LangChain 完全做不到。例如切块策略：

# LlamaIndex：内置语义切块
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.core.node_parser import SemanticSplitterNodeParser

documents = SimpleDirectoryReader("data").load_data()
splitter = SemanticSplitterNodeParser(embed_model=embed_model)
nodes = splitter.get_nodes_from_documents(documents)

LangChain 的切块更基础，需要你自己探索更优策略：

# LangChain：基础按递归字符切块，语义化需要额外实现
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter.from_tiktoken_encoder(
    chunk_size=512, chunk_overlap=64
)

如果你的核心工作是处理格式各异的私有文档，选 LlamaIndex，它在数据加工上的坑少得多。

差异二：调 OpenAI 之外模型的经历

这一点是选型的一票否决项。LangChain 做了大量轻量化工具链：

# LangChain：切换 Ollama 只需改一行
from langchain_community.llms import Ollama
llm = Ollama(model="llama3", base_url="http://localhost:11434")

LlamaIndex 同样支持 OpenAI 兼容接口和多种模型，但对非主流在线模型支持滞后，且配置更细碎——需要手动设置 Settings.llm、Settings.embed_model。

差异三：Agent 与 RAG 的组合模式

如果你做的不是纯 QA，而是要"查文档 + 调工具 + 多轮反思"的 Agent：

LangChain 天然支持工具调用循环，Agent 是内建概念：

# LangChain：Agent 内嵌 RAG
from langchain.agents import create_tool_calling_agent
tools = [retriever_tool, search_tool, calculator_tool]

LlamaIndex 在 v0.10 后终于有了 Workflow（基于事件驱动），但 Agent 生态成熟度差一个等级。如果你能预判项目未来会演化出多 Agent 或频繁工具调用，LangChain 是安全选择。

按场景选型

• 你是数据工程师 / 文档密集型产品（金融研报、法律条文、医学文档）→ 选 LlamaIndex。它的结构化数据抽取、语义切块、元数据过滤能直接提升检索准确率。
• 你要做全栈 LLM 应用，不只是 RAG（Agent + 工具 + 多轮记忆 + 外部 API）→ 选 LangChain。LCEL 语法能优雅地表达复杂逻辑链。
• 快速验证想法 / Hackathon → 选 LlamaIndex。3 行代码拿到可用的 QA 接口，快速启动比什么都重要。
• 已有稳定 RAG 管道，想接入 Agent 层 → 不要二选一。用 LlamaIndex 构建索引，再用 LangChain 的 create_retrieval_tool 包装后喂给 Agent 即可，这是社区验证过的最优组合。

结语

明确的观点是：如果你的业务满足以下 2 条以上，果断选 LlamaIndex——数据格式复杂多变、检索精度直接决定产品价值、技术团队规模小于 5 人且没有专门的数据工程人力。它让你在数据侧少交学费。而 LangChain 更适合那些核心价值在编排逻辑（如何设计 Agent 流程、如何接入工具）而非数据加工本身的团队。它给你的是灵活性，同时把数据层的坑交还给你自己填。

最后提醒一句：别被“框架选择焦虑”绑架。两个框架都内聚了百家之长，真正的瓶颈从来不在于你选 A 还是 B，而在于你有没有把文档质量、切块策略、指标评估这三件事做好。选一个深度钻研，远比来回横跳价值高。