61-LangChain-vs-LlamaIndex-选型对比-功能矩阵-混用实践
文章目录
- 【61.Python+AI】LangChain vs LlamaIndex：两大LLM框架功能矩阵与混用最佳实践
- 导入语
- 1 ~> 一张图看懂两个框架的定位
- 1.1 核心差异：全栈编排 vs 数据专家
- 1.2 功能覆盖矩阵
- 1.3 选型速查
- 2 ~> 数据处理管道：IngestionPipeline vs DocumentLoader
- 2.1 LangChain 的数据加载方式
- 2.2 LlamaIndex 的 IngestionPipeline
- 3 ~> Agent 能力对比
- 3.1 LangChain 的 Agent 体系
- 3.2 LlamaIndex 的 Agent
- 3.3 Agent 场景选型
- 4 ~> 三种混用方案
- 4.1 方案一：LlamaIndex 做数据层，LangChain 做编排层
- 4.2 方案二：两个框架各自独立模块
- 4.3 方案三：全用 LangChain + 手动实现高级检索
- 5 ~> 优缺点总结
- LangChain 的优缺点
- LlamaIndex 的优缺点
- 一句话总结
- 思考 && 总结
- 结尾
【61.Python+AI】LangChain vs LlamaIndex：两大LLM框架功能矩阵与混用最佳实践
📖文章简介：本文针对"LangChain和LlamaIndex到底该选哪个"这个LLM开发者的高频困惑，从功能定位、架构哲学、典型场景三个维度做一次不偏不倚的横向对比。文章绘制了功能覆盖矩阵图，拆解了两者在数据处理管道（Ingestion Pipeline vs Document Loader）、检索策略（高级索引 vs RetrievalQA）、Agent能力上的差异化设计，并给出三种混用方案：以LlamaIndex为数据层+LangChain为编排层的协同架构。适合已经上手其中一个框架、正在评估是否引入另一个的开发者。
🎬 个人主页：源码骑士
❄专栏传送门：《Android开发基础》《python基础课程》
⭐️热衷从源码视角拆解技术底层原理，将复杂架构讲得通俗易懂
🎬 源码骑士的简介：
5年Android Framework系统开发经验，曾主导多项系统级性能优化专项
技术栈覆盖Android系统全链路（Binder/Handler/AMS/WMS/启动流程）及Java后端全家桶（Spring + MyBatis + Redis + Oracle）
累计产出原创技术文章100+篇，文章以流程图为特色，被读者评价为"看一篇胜过啃一周源码"
导入语
你学习LLM应用开发，第一个接触的框架大概率是LangChain。后来做到RAG环节，周围越来越多声音说"LlamaIndex在数据索引方面更强"。
于是你面临一个灵魂拷问：要转投LlamaIndex吗？还是两个都学？能不能混用？这篇文章就帮你把这道选择题做完。我们不谈哪个"更好"，只谈哪个"更适合你的场景"。
1 ~> 一张图看懂两个框架的定位
1.1 核心差异：全栈编排 vs 数据专家
LangChain 是一个通用LLM应用框架——它关心的是"怎么把LLM、工具、记忆、Agent拼在一起"。RAG是它其中一个模块，不是它的全部。
LlamaIndex 是一个数据框架——它只关心一件事：“怎么把外部数据变成LLM能用好的格式”。它的全部功能围绕数据索引和检索展开。
1.2 功能覆盖矩阵
| 能力域 | LangChain | LlamaIndex | 谁更擅长 |
|---|---|---|---|
| LLM调用封装 | ✅ 支持几乎所有模型 | ✅ 通过langchain桥接 | LangChain |
| Chain/Pipeline编排 | ✅ LCEL表达式语言 | ⚠️ 基础支持 | LangChain |
| Agent/工具调用 | ✅ AgentExecutor系列 | ⚠️ 简单Agent | LangChain |
| 数据加载/解析 | ✅ 100+ DocumentLoader | ✅ 支持PDF/网页/数据库 | 持平 |
| 基础向量检索 | ✅ RetrievalQA | ✅ VectorStoreIndex | 持平 |
| 高级检索策略 | ❌ 需自己实现 | ✅ 句子窗口/递归/合并 | LlamaIndex |
| 知识图谱索引 | ❌ 无原生支持 | ✅ KnowledgeGraphIndex | LlamaIndex |
| RAG评估 | ❌ 无 | ✅ 内置评估模块 | LlamaIndex |
| Callbacks监控 | ✅ 完善的回调系统 | ⚠️ 通过langchain | LangChain |
| Memory管理 | ✅ 多种Memory方案 | ❌ | LangChain |
1.3 选型速查
你需要构建的主要功能是什么？ ├─ 复杂Agent + 多工具编排 + 对话记忆 │ → 选 LangChain │ ├─ RAG + 复杂文档检索 + 知识图谱问答 │ → 选 LlamaIndex │ └─ 既需要Agent又需要高级RAG → 两个都学，混用2 ~> 数据处理管道：IngestionPipeline vs DocumentLoader
2.1 LangChain 的数据加载方式
LangChain 的数据加载遵循"加载→转换→存储"的线性流程：
fromlangchain.document_loadersimportPyPDFLoaderfromlangchain.text_splitterimportRecursiveCharacterTextSplitterfromlangchain.vectorstoresimportChroma loader=PyPDFLoader("document.pdf")documents=loader.load()splitter=RecursiveCharacterTextSplitter(chunk_size=500,chunk_overlap=50)chunks=splitter.split_documents(documents)vectordb=Chroma.from_documents(chunks,embedding=embeddings)这个流程简单直接，但缺少预处理hook——比如你想在embedding之前对文本做清洗，需要在代码里额外写一步。
2.2 LlamaIndex 的 IngestionPipeline
LlamaIndex 用IngestionPipeline把整个数据摄入过程封装成一条可配置的管道：
fromllama_index.core.ingestionimportIngestionPipelinefromllama_index.core.node_parserimportSentenceSplitterfromllama_index.core.extractorsimportTitleExtractor pipeline=IngestionPipeline(transformations=[SentenceSplitter(chunk_size=512),# 分块TitleExtractor(),# 自动提取标题embeddings,# 向量化])nodes=pipeline.run(documents=documents)管道带来的好处：
| 特性 | LangChain 方式 | LlamaIndex 管道 |
|---|---|---|
| 可配置性 | 需手动串联 | 声明式配置 |
| 可缓存 | 需自己实现 | 内置cache支持 |
| 并行处理 | 需手动多线程 | 管道内支持parallel |
3 ~> Agent 能力对比
3.1 LangChain 的 Agent 体系
LangChain 的 Agent 是它最强的护城河——支持多种Agent类型、工具绑定、自定义推理循环：
fromlangchain.agentsimportcreate_openai_functions_agent,AgentExecutor agent=create_openai_functions_agent(llm,tools,prompt)executor=AgentExecutor(agent=agent,tools=tools,verbose=True)executor.invoke({"input":"查一下今天的天气，如果下雨就帮我订外卖"})3.2 LlamaIndex 的 Agent
LlamaIndex 的 Agent 设计更专注于"数据相关的任务"：
fromllama_index.core.agentimportReActAgent agent=ReActAgent.from_tools([query_tool,search_tool],llm=llm,verbose=True)agent.chat("从知识库中找到关于异常处理的最佳实践")3.3 Agent 场景选型
| 需求 | 建议框架 |
|---|---|
| 调用外部API、数据库、文件系统 | LangChain |
| 混合使用多个检索策略回答问题 | 都可以 |
| 先检索知识库、再调用计算工具、最后写入数据库 | LangChain（混用LlamaIndex做检索） |
4 ~> 三种混用方案
4.1 方案一：LlamaIndex 做数据层，LangChain 做编排层
这是最常见也最推荐的混用方式：
fromllama_index.coreimportVectorStoreIndexfromlangchain.agentsimportinitialize_agent# LlamaIndex 构建索引和检索器index=VectorStoreIndex.from_documents(docs)retriever=index.as_retriever(similarity_top_k=5)# 把检索器包装成 LangChain Toolfromlangchain.toolsimportTool retrieval_tool=Tool(name="knowledge_base",func=lambdaq:str(retriever.retrieve(q)),description="从知识库中检索信息")# LangChain Agent 调用这个工具agent=initialize_agent([retrieval_tool,other_tools],llm)agent.run("查一下知识库里关于微服务的架构设计")4.2 方案二：两个框架各自独立模块
如果你的项目同时有"复杂RAG需求"和"Agent编排需求"，把两块独立开发和测试：
项目结构 ├─ rag_module/ ← 用 LlamaIndex，专注检索 │ ├─ ingestion.py │ └─ retrievers.py │ ├─ agent_module/ ← 用 LangChain，专注编排 │ ├─ tools.py │ └─ executor.py │ └─ main.py ← 粘合层4.3 方案三：全用 LangChain + 手动实现高级检索
如果你的团队不想引入第二个框架，也可以用 LangChain 手动实现 LlamaIndex 的部分高级检索功能——但这意味着你要自己写递归检索、句子窗口等逻辑。
5 ~> 优缺点总结
LangChain 的优缺点
| 优点 | 缺点 |
|---|---|
| 生态最丰富，几乎支持所有LLM | 抽象层太多，初学者容易迷失 |
| Agent和Chain能力最强 | RAG只是它的一部分，不够专注 |
| LCEL表达式语言统一了调用方式 | API变化快，版本升级成本高 |
| Callbacks可观测性好 | 高级检索需要自己动手 |
LlamaIndex 的优缺点
| 优点 | 缺点 |
|---|---|
| RAG和数据索引做到极致 | Agent和编排能力不如LangChain |
| 高级检索开箱即用 | 生态相对较小 |
| IngestionPipeline设计优雅 | 社区的教程和案例偏少 |
| 知识图谱原生支持 | Memory管理较弱 |
一句话总结
RAG和知识库项目，用LlamaIndex。Agent和多工具编排项目，用LangChain。两者兼有的项目，LlamaIndex做数据层、LangChain做编排层。
思考 && 总结
- 两个框架不是竞争关系，是互补关系：LangChain 擅长"把各种东西串起来"，LlamaIndex 擅长"让外部数据被更好地检索"。一个关注流程编排，一个关注数据质量。
- 不要为了"全用最新技术"而引入不必要的复杂度：如果你的项目就是一个简单的QA机器人，LangChain 的 RetrievalQA 就够了。当检索复杂度上去了（多文档、层级结构、需要知识图谱），再考虑引入 LlamaIndex。
- 混用的关键是定义清楚边界：数据摄入和检索归 LlamaIndex 管，Agent 流程和工具编排归 LangChain 管。在边界上用一个简单的Tool包装器桥接。
- 功能矩阵表是你选型的第一参考：每个项目需求不同，不要问"哪个更好"，要看功能矩阵里哪个框架在你的核心需求上得分更高。
选框架和选数据库一样——没有银弹，只有最适合你当前场景的工具组合。
结尾
各位小伙伴，本文的内容到这里就全部结束了，源码骑士在这里再次感谢您的阅读！
源码骑士 — Android Framework & 全栈开发
👀关注：跟博主一起从源码视角深耕底层原理，见证每一次成长
❤️点赞：让优质内容被更多人看见，让知识传递更有力量
⭐收藏：把核心知识点存好，在需要时随时查、随时用
💬评论：分享你的经验或疑问，评论区一起交流避坑
🔄一键四连：不要忘记给博主"一键四连"哦！
🗡️寄语：技术之路难免有困惑，但同行的人会让前进更有方向
结语：每次新技术选型都像在迷宫里找出口。本文的功能矩阵和三种混用方案，就是帮你快速定位出口的地图。记住——框架是工具，不是信仰。不要忘记给博主"一键四连"哦！