一、为什么 RAG 框架选型是个难题2024 年以来RAG 已经成为大模型应用的标准范式。但当你真正动手搭建一个生产级 RAG 系统时面临的第一个决策就是用什么框架RAG 系统的核心链路 这条链路上的每一个环节都有大量可配置的选项用什么切分策略用什么 Embedding 模型用 Milvus 还是 Pinecone要不要 Reranker多轮对话怎么管理上下文三大框架对此给出了截然不同的答案框架核心理念适合谁LangChain通用 LLM 应用编排框架链式组合一切需要高度定制、构建复杂 Agent 的开发者LlamaIndex以数据为核心的 RAG 专用框架追求检索质量和数据连接的开发者Dify开源 LLMOps 平台低代码可视化快速搭建生产级应用、非纯代码团队二、三大框架架构深度对比2.1 LangChain万能瑞士军刀LangChain 的核心抽象是Chain链——把 LLM 调用、Prompt 模板、工具调用、检索器等组件像链条一样串联。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA from langchain_core.prompts import ChatPromptTemplate # 1. 文档加载 loader PyPDFLoader(knowledge_base.pdf) documents loader.load() # 2. 文档切分 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, ] ) chunks text_splitter.split_documents(documents) # 3. 向量化 存储 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) # 4. 构建检索链 llm ChatOpenAI(modelgpt-4o, temperature0) retriever vectorstore.as_retriever(search_typemmr, search_kwargs{k: 5}) # 5. 自定义 Prompt prompt ChatPromptTemplate.from_template( 基于以下检索到的上下文回答问题。如果上下文中没有相关信息请说我不知道。 上下文 {context} 问题{question} ) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverretriever, chain_type_kwargs{prompt: prompt} ) # 6. 查询 result qa_chain.invoke({query: 公司的退款政策是什么}) print(result[result])架构特点优势组件最丰富100 文档加载器、20 向量库、20 Embedding 模型LCELLangChain Expression Language声明式编排灵活Agent 生态成熟工具调用、多步推理、ReAct 模式社区最大文档教程最多劣势抽象层过多简单 RAG 也要写不少胶水代码版本迭代频繁API 经常 breaking change1.0 前 vs 后差异大检索能力不是核心专长高级检索需要自己组装生产部署需要额外搭 LangServe2.2 LlamaIndexRAG 专精框架LlamaIndex 的核心理念是以数据为中心——所有设计都围绕如何更好地索引、检索、生成。from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings from llama_index.core.node_parser import SentenceSplitter from llama_index.core.postprocessor import SentenceTransformerRerank from llama_index.core.retrievers import QueryFusionRetriever from llama_index.vector_stores.milvus import MilvusVectorStore from llama_index.embeddings.openai import OpenAIEmbedding from llama_index.llms.openai import OpenAI # 1. 全局配置 Settings.llm OpenAI(modelgpt-4o, temperature0) Settings.embed_model OpenAIEmbedding(modeltext-embedding-3-small) # 2. 文档加载 documents SimpleDirectoryReader(./docs).load_data() # 3. 文档切分LlamaIndex 原生支持更精细的切分 node_parser SentenceSplitter( chunk_size512, chunk_overlap50, paragraph_separator\n\n\n ) # 4. 向量存储直接用 Milvus vector_store MilvusVectorStore( urihttp://localhost:19530, collection_nameknowledge_base, dim1536, overwriteFalse ) # 5. 构建索引 index VectorStoreIndex.from_documents( documents, transformations[node_parser], vector_storevector_store ) # 6. 添加 Reranker reranker SentenceTransformerRerank( modelcross-encoder/ms-marco-MiniLM-L-6-v2, top_n3 ) # 7. 构建查询引擎 query_engine index.as_query_engine( similarity_top_k10, # 先检索 10 个 node_postprocessors[reranker] # 重排序取 3 个 ) # 8. 查询 response query_engine.query(公司的退款政策是什么) print(response.response)架构特点优势检索能力最强原生支持向量检索 关键词检索 知识图谱三种索引Query Engine 抽象设计精良支持子查询、多步检索、递归检索内置 Reranker、HyDE、Query Transformation 等高级 RAG 技术数据连接器丰富Notion、Slack、GitHub、Confluence 等 40LlamaParse 文档解析能力尤其 PDF 表格业界领先劣势偏重 RAG 场景做 Agent / 工具调用不如 LangChain学习曲线相对陡峭Index → Retriever → QueryEngine 多层抽象可视化和管理工具不如 Dify2.3 Dify低代码 LLMOps 平台Dify 走的是完全不同的路线——可视化编排 一站式 LLMOps。# Dify 通过 Web UI 拖拽编排配置文件大致如下 # 实际操作在 Web 界面完成这里用 YAML 表示逻辑结构 workflow: name: 企业知识库问答 nodes: - id: start type: start variables: - name: query type: string - id: knowledge_retrieval type: knowledge-retrieval dataset_id: kb_2024 retrieval_mode: hybrid # 向量 关键词混合检索 top_k: 5 rerank_model: cohere-rerank-multilingual-v3.0 - id: llm type: llm model: gpt-4o prompt_template: | 基于以下上下文回答用户问题。 上下文{{knowledge_retrieval.result}} 问题{{start.query}} temperature: 0.1 - id: end type: end output: {{llm.text}}架构特点优势零代码上手产品经理也能搭 RAG 应用一站式平台知识库管理 模型管理 应用发布 监控Workflow 编排器支持复杂逻辑条件分支、循环、HTTP 调用内置多种应用类型Chatbot、Agent、文本生成、Workflow自带 API 网关直接对外提供服务劣势深度定制能力受限复杂的检索逻辑不如代码灵活框架本身较重部署需要 Docker Compose 或 K8s代码侵入性强一旦用 Dify 很难迁移到其他框架高级特性如自定义 Reranker需要企业版三、核心能力横向对比3.1 文档处理能力3.2 检索能力3.3 生产部署能力四、实测同一知识库三大框架性能对比4.1 测试环境硬件 - CPU: Intel Xeon 8358 (2.6GHz, 32C) - GPU: 1× A100 40G - 内存: 256GB - 存储: NVMe SSD 软件 - Python 3.11 - LangChain 0.3.x - LlamaIndex 0.11.x - Dify 0.15.x (Docker 部署) - 向量库: Milvus 2.4 (独立部署) - LLM: GPT-4o (API) - Embedding: text-embedding-3-small 数据集 - 500 份企业文档PDF Word Markdown - 总计约 1200 万字 - 切分后约 24000 个 chunks - 评测问题 200 道含单跳/多跳/对比/摘要四类4.2 索引构建性能4.3 检索质量对比使用 200 道评测题统计 Recall5 和 MRR平均倒数排名结论LlamaIndex 在检索质量上全面领先尤其在多跳问答场景下优势显著SubQuestionQueryEngine 自动拆分子查询的能力是关键。4.4 端到端延迟单次问答从用户提问到返回完整答案组件LangChainLlamaIndexDify查询向量化120ms118ms125ms向量检索45ms43ms48msReranker180ms175ms185msLLM 生成2.3s2.3s2.4s框架开销85ms62ms210ms总延迟2.73s2.70s2.97sDify 的框架开销明显高于另外两者多了一层 API 网关 Workflow 引擎但绝对差距在可接受范围内。4.5 开发效率对比实现同样功能含文档上传、知识库构建、问答、多轮对话、流式输出指标LangChainLlamaIndexDify代码行数~180 行~120 行~0 行UI 配置开发时间~4 小时~3 小时~1 小时需要的先验知识Python LangChain APIPython LlamaIndex 概念基本无调试难度中链式调用报错信息长中多层抽象需理解低UI 可视化五、选型决策树场景化推荐场景推荐框架理由企业内部知识库问答Dify非技术人员也能管理知识库自带用户管理对检索质量要求极高法律/医疗LlamaIndex多索引 子查询 Reranker检索质量最优复杂 Agent多工具调用 推理LangChainAgent 生态最成熟工具链最丰富快速 MVP 验证Dify1 小时搭出可用 demo多数据源 RAGNotion DB APILlamaIndex40 数据连接器QueryFusion 多路召回需要深度定制检索逻辑LangChain组件可自由组合不设限需要运维监控 AB 测试Dify内置完整 LLMOps 能力知识图谱 向量混合检索LlamaIndex唯一原生支持 KG Vector 的框架六、混合方案生产环境最佳实践在实际生产中三个框架并非互斥。一个常见的成熟架构是分工逻辑Dify 负责应用层UI、API、监控、用户管理LlamaIndex 负责检索层文档解析、索引构建、多路检索、RerankLangChain 负责生成层Agent 编排、工具调用、复杂推理Milvus 作为独立向量数据库这种架构的好处是各取所长但复杂度也最高——适合有专门 AI 团队的企业。七、三个框架的常见踩坑LangChain 踩坑坑 1版本兼容性噩梦# LangChain 0.1 vs 0.2 vs 0.3 的 import 路径全变了 # 0.1: from langchain.chains import RetrievalQA # 0.2: from langchain.chains import RetrievalQA (deprecation warning) # 0.3: from langchain.chains import RetrievalQA (removed, use LCEL) # 建议锁定版本 使用 LCEL 替代旧 Chain API pip install langchain0.3.7 langchain-core0.3.7坑 2RetrievalQA 不支持流式# RetrievalQA 不支持 stream要用 LCEL 重写 from langchain_core.runnables import RunnablePassthrough rag_chain ( {context: retriever | format_docs, question: RunnablePassthrough()} | prompt | llm ) for chunk in rag_chain.stream(退款政策是什么): print(chunk.content, end, flushTrue)LlamaIndex 踩坑坑 1Settings 全局配置污染# Settings 是全局的多索引场景会互相覆盖 # 解决在每个 index 构建时显式传入 llm 和 embed_model index VectorStoreIndex.from_documents( documents, llmcustom_llm, # 显式传入 embed_modelcustom_embed, # 显式传入 )坑 2Reranker 模型首次加载慢# SentenceTransformerRerank 首次使用会下载模型~80MB # 预加载到本地避免生产环境首次请求超时 from sentence_transformers import SentenceTransformer SentenceTransformer(cross-encoder/ms-marco-MiniLM-L-6-v2) # 预热Dify 踩坑坑 1知识库切分策略不可自定义Dify 内置切分策略只有 3 种 - 自动切分按段落 字数上限 - 按段落切分 - 按固定字数切分 不支持递归切分、语义切分等高级策略。 解决先在外部用 LlamaIndex 切分再逐条上传到 Dify 知识库。坑 2Workflow 不支持循环Dify Workflow 引擎不支持 for/while 循环结构。 如果需要检索→判断→再检索的迭代逻辑 只能用 Agent 模式但 Agent 模式延迟更高。八、成本对比开发成本项目LangChainLlamaIndexDify学习时间2-3 天2-3 天0.5 天MVP 开发4 小时3 小时1 小时生产级开发2-3 周1.5-2 周3-5 天运维成本中自建 API中自建 API低内置监控运行成本项目LangChainLlamaIndexDify框架开销低低中多一层网关GPU 需求同等同等同等服务器最低配置4C8G4C8G8C16G含平台自身LLM API 成本同等同等同等但可做多模型负载均衡省钱九、总结与建议维度最优选择检索质量LlamaIndex开发速度Dify灵活定制LangChainAgent 能力LangChain生产运维Dify社区生态LangChain文档解析LlamaIndex (LlamaParse)低代码友好Dify一句话建议如果你是独立开发者 / 小团队直接用 Dify1 小时上线省下的时间做业务如果你是 AI 工程师 / 追求效果LlamaIndex 做检索核心效果天花板最高如果你要做复杂 AI AgentLangChain 的 Agent 生态无可替代如果你有 AI 团队做生产系统Dify应用层 LlamaIndex检索层 LangChainAgent 层混合架构专栏导航上一篇ESP32 开发环境搭建指南从零配置到编译烧录的 12 个坑下一篇kafka 深度解剖 StickyAssignor 分区分配策略如果觉得有用点赞收藏关注三连支持一下这个专栏会持续更新 RAG 和大模型部署的深度内容。下周我们会发布 RAG 架构设计 7 个关键决策的深度文章别错过