LangChain vs 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看成应用编排引擎，两者互补。 实际选型时，我会先画出系统的数据流和决策流，再决定哪个框架做主力。