LangChain vs LlamaIndex 场景怎么选？
核心设计理念与适用场景对比,技术侧重点分析
原题：LangChain和LlamaIndex都是流行的AI应用开发框架，请比较它们的核心设计理念、适用场景和技术侧重点，说明在什么情况下应优先选择其中一个。
RAG基础 · 阿里真题
回答与解析
核心定位差异
| 维度 | LangChain | LlamaIndex |
|---|---|---|
| 设计目标 | 通用LLM应用编排框架 | 数据检索与知识库专用框架 |
| 抽象层级 | 高，覆盖完整应用生命周期 | 聚焦数据摄入→索引→检索→合成 |
| 核心优势 | 工具链整合、Agent编排、记忆管理 | 数据连接器、索引策略、检索优化 |
技术侧重点对比
LangChain的核心能力
- 链式编排：通过LCEL构建复杂工作流，支持条件分支、并行执行
- 工具生态：内置大量第三方工具集成（搜索、数据库、API）
- Agent系统：ReAct、Plan-and-Execute等多模式Agent实现
- 记忆管理：ConversationBufferMemory等上下文持久化方案
LlamaIndex的核心能力
- 数据连接器：100+种数据源（PDF、Notion、数据库、SaaS等）
- 索引策略：VectorStoreIndex、TreeIndex、KGIndex、DocumentSummaryIndex等
- 检索优化：自动检索器选择、混合搜索、重排序（rerank）、递归检索
- 查询引擎：支持子问题分解、多文档对比、结构化数据查询
选型决策
优先选LangChain
- 需要调用多个外部工具/API的复杂Agent
- 工作流涉及条件判断、循环、人工介入审批
- 多模态任务编排（LLM+图像生成+代码执行）
优先选LlamaIndex
- 企业知识库场景：海量文档（10万+）的高效检索
- 需要精细控制检索策略（分层摘要、知识图谱增强）
- 数据源多样且需要自动化解析（非结构化+半结构化混合）
实际趋势
生产环境中两者常组合使用：LlamaIndex负责数据层（索引+检索），LangChain负责应用层（Agent编排+工具调用）。LlamaIndex也推出了llama-index-agent模块，边界正在模糊，但原生优势领域依然分明。
学习建议
建议系统学习该知识点
口语版讲法(约4分钟)
- 本质是工作流编排 vs 数据检索
- LangChain适合多工具Agent场景
- LlamaIndex适合知识库精细检索
- 实际落地常组合使用
- 风险与取舍
这道题其实在问一个核心问题：当你要做一个AI应用的时候，你的重心是在编排多个工具和模型的工作流，还是在高效地检索和理解私有数据。这两个框架的出发点完全不同。
先说LangChain，它的设计目标很明确，就是把LLM、工具、API、记忆这些东西串成一个可编程的工作流。你可以把它理解成一个乐高积木盒子，里面有各种零件，你用它搭出复杂的Agent系统。举个例子，比如一个客服退款场景，用户说“我订单超时了，要退款”，LangChain可以这么搭：第一步，让LLM理解意图，提取订单号；第二步，调订单系统查状态；第三步，如果符合规则，调退款API；第四步，把结果总结成自然语言回复。中间还能加人工审批节点。这里它的优势是链式编排，像LCEL这种声明式语法，写起来很舒服。但前提是你的场景需要调用多个外部服务，并且流程有分支和决策。 如果只是简单问答，用它反而重了。
再来看LlamaIndex，它从一开始就是为数据检索和知识库场景设计的。它的核心能力在数据连接器、索引策略和检索优化上。比如企业有几十万份SOP和合规文档，你可以连上Confluence、SharePoint、本地PDF，然后用它的分层索引或者知识图谱索引。它的强项是对检索过程的精细控制，比如混合搜索、重排序、子问题分解。同样客服场景，如果用户问“商家满减政策和订单异常怎么处理”，LlamaIndex可以做到：先拆成两个子问题，分别从不同文档检索，再合并答案。这里有个坑，就是如果你的文档质量差，比如OCR识别率低，或者格式混乱，那再好的索引也救不了。我会特别关注数据预处理阶段，上线前一定要用一批真实query跑一遍召回率，低于80%就别急着上。
说到落地，其实生产环境里这两个框架经常一起用。LlamaIndex负责数据层，把文档变成可检索的索引；LangChain负责应用层，把检索结果和工具调用、Agent决策串起来。比如一个企业知识库助手，用户问“帮我查库存价格”，LlamaIndex先检索到相关文档，LangChain再调库存API获取实时数据，最后合成答案。这种组合是目前最成熟的模式。 当然，边界也在模糊，LlamaIndex现在也有Agent模块，LangChain也在加强检索，但原生优势还是分明的。
不过有一点很多人忽略，就是当数据量超过百万级时，LlamaIndex的默认索引策略可能会遇到性能瓶颈，这时候就得考虑分库、缓存或者用更轻量的Faiss。这个其实涉及到索引规模和实时性的取舍，如果面试官感兴趣可以深入聊。
所以我的判断是：如果核心是“怎么调用和编排”，优先LangChain；如果核心是“怎么从海量数据里找到最相关的那段话”，优先LlamaIndex。我更倾向把LlamaIndex看成数据基础设施，LangChain看成应用编排引擎，两者互补。 实际选型时，我会先画出系统的数据流和决策流，再决定哪个框架做主力。
关键一句:百万级数据量时LlamaIndex默认索引可能性能不足，需要分库、缓存或改用更轻量的Faiss。
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做企业知识库问答，用户上传了PDF、网页和数据库表，你要从中检索答案。LangChain和LlamaIndex你更倾向用哪个？为什么？
- 问法 2 · 层层追问
你用过LangChain或者LlamaIndex吗？……如果让你给一个知识库系统选型，你会怎么选？……那在数据索引和检索这块，你觉得哪个更强？
- 问法 3 · 直球架构
请直接比较LangChain和LlamaIndex的核心设计理念、适用场景和技术侧重点，什么情况下优先选哪个？