LlamaIndex vs LangChain——两个框架的真正区别
LlamaIndex vs LangChain——两个框架的真正区别
LangChain 和 LlamaIndex 是 AI 应用最常用的两个框架。但它们的定位完全不同——用错了南辕北辙。
核心定位差异
LangChain 的定位
通用 LLM 应用框架——
- 不只是 RAG,还有 Agent、Chain、Memory、Tools
- 目标是”LLM 时代的 Spring 框架”
- 适合:任何 LLM 应用
LlamaIndex 的定位
专注文档问答和 RAG——
- 核心是 “把私有数据接入 LLM”
- 数据连接器、索引、检索是核心
- 适合:RAG 应用、知识库
一句话总结
- LangChain = “LLM 应用的全家桶“
- LlamaIndex = “RAG 应用的瑞士军刀“
详细对比
1. 数据接入
LangChain:
1 | from langchain.document_loaders import PyPDFLoader |
支持 100+ 数据源——但每个都要单独学 API。
LlamaIndex:
1 | from llama_index import SimpleDirectoryReader |
更简单——一个 SimpleDirectoryReader 读所有常见格式。
LlamaIndex 在数据接入上更友好。
2. 索引构建
LangChain:
1 | from langchain.text_splitter import RecursiveCharacterTextSplitter |
要自己拼装多个组件。
LlamaIndex:
1 | from llama_index import VectorStoreIndex |
LlamaIndex 在索引上更优雅——抽象层次更高。
3. 查询接口
LangChain:
1 | from langchain.chains import RetrievalQA |
LlamaIndex:
1 | query_engine = index.as_query_engine() |
两者差不多——但 LlamaIndex 默认行为更智能(自动用 GPT-4o 优化问题)。
4. RAG 高级特性
LlamaIndex 显著领先:
| 特性 | LangChain | LlamaIndex |
|---|---|---|
| 基础 RAG | ✅ | ✅ |
| 多文档索引 | 手动 | ✅ 原生 |
| 自动问题改写 | 手动 | ✅ 默认 |
| Hybrid 检索 | 手动 | ✅ 一行 |
| Sub-question Query | ❌ | ✅ |
| Router Query | 手动 | ✅ |
| 递归检索 | ❌ | ✅ |
如果你专注 RAG,LlamaIndex 优势明显。
5. Agent 能力
LangChain 显著领先:
| 特性 | LangChain | LlamaIndex |
|---|---|---|
| Agent | ✅ LangGraph | 弱 |
| Tools | ✅ 大量 | 基础 |
| Memory | ✅ 完善 | 简单 |
| Multi-Agent | ✅ | ❌ |
| Function Calling | ✅ | ✅ |
如果你做 Agent,选 LangChain。
6. 文档质量
LlamaIndex 略胜——文档清晰、有图解、有最佳实践。
LangChain 文档量大,但有些混乱(版本变化大)。
7. 社区生态
LangChain 更大——GitHub 90k+ stars,生态丰富。
LlamaIndex 25k+ stars,但增速更快(RAG 方向深耕)。
实测对比:RAG 应用
我做了个 RAG 项目,分别用两个框架实现同样的功能——
任务:PDF 知识库问答
LangChain 实现(50 行代码)
1 | from langchain.document_loaders import PyPDFLoader |
LlamaIndex 实现(10 行代码)
1 | from llama_index import VectorStoreIndex, SimpleDirectoryReader |
LlamaIndex 代码量是 LangChain 的 1/5。
性能对比
| 维度 | LangChain | LlamaIndex |
|---|---|---|
| 代码量 | 50 行 | 10 行 |
| 索引速度 | 中 | 快(底层优化) |
| 查询准确率 | 82% | 87%(默认优化) |
| 灵活性 | 高 | 中 |
| 学习曲线 | 陡 | 平缓 |
实测对比:Agent 应用
任务:客服 Agent,能调用订单查询工具
LangChain(LangGraph)实现
1 | from langgraph.graph import StateGraph |
完整、灵活、可控。
LlamaIndex 实现
LlamaIndex 的 Agent 能力很弱——需要结合 LangChain。
1 | # 实际上 LlamaIndex 没有真正的 Agent 框架 |
我的选择策略
选 LlamaIndex 的场景
✅ 纯 RAG 应用
- 企业知识库
- 文档问答
- PDF 分析
✅ 数据接入复杂
- 多种格式(Markdown、PDF、Notion、Slack)
- 多源数据整合
✅ 想要快速 POC
- 不需要复杂 Agent
- 几天内出 demo
选 LangChain 的场景
✅ 需要 Agent
- 多工具调用
- 多步决策
- 复杂工作流
✅ 复杂 LLM 应用
- 不只是 RAG
- 涉及多个 LLM 调用
- 需要状态管理
✅ 生产级系统
- LangGraph 提供状态管理
- 完善的监控和调试
两者结合
最常见的生产方案——LlamaIndex 做 RAG,LangChain 做 Agent。
1 | # LlamaIndex 做 RAG 引擎 |
这种组合充分利用了两个框架的优势。
我的实际项目经验
项目 1:企业内部知识库
用 LlamaIndex——纯 RAG 场景,代码量小,准确率高。
3 天搭建,1 周上线,半年没出过问题。
项目 2:AI 助手 Agent
用 LangChain + LangGraph——涉及多工具调用,需要状态管理。
1 周搭建,2 周迭代,Agent 复杂但可控。
项目 3:混合系统
LlamaIndex 做知识检索,LangChain 做决策——RAG + Agent 都要。
这种组合最常见,也是最实用的方案。
写在最后
LangChain vs LlamaIndex 不是”二选一”——是”看场景搭配”。
我的最终建议:
| 你要做的事 | 用什么 |
|---|---|
| 纯 RAG | LlamaIndex |
| 纯 Agent | LangChain + LangGraph |
| RAG + Agent | LlamaIndex + LangChain |
| 想快速 POC | LlamaIndex |
| 生产级复杂系统 | LangChain |
框架不是信仰——工具而已。选最适合场景的,别追”主流”。
