一、為什么 RAG 框架選型是個(gè)難題2024 年以來RAG 已經(jīng)成為大模型應(yīng)用的標(biāo)準(zhǔn)范式。但當(dāng)你真正動(dòng)手搭建一個(gè)生產(chǎn)級(jí) RAG 系統(tǒng)時(shí)面臨的第一個(gè)決策就是用什么框架RAG 系統(tǒng)的核心鏈路 ?這條鏈路上的每一個(gè)環(huán)節(jié)都有大量可配置的選項(xiàng)用什么切分策略用什么 Embedding 模型用 Milvus 還是 Pinecone要不要 Reranker多輪對(duì)話怎么管理上下文三大框架對(duì)此給出了截然不同的答案框架核心理念適合誰LangChain通用 LLM 應(yīng)用編排框架鏈?zhǔn)浇M合一切需要高度定制、構(gòu)建復(fù)雜 Agent 的開發(fā)者LlamaIndex以數(shù)據(jù)為核心的 RAG 專用框架追求檢索質(zhì)量和數(shù)據(jù)連接的開發(fā)者Dify開源 LLMOps 平臺(tái)低代碼可視化快速搭建生產(chǎn)級(jí)應(yīng)用、非純代碼團(tuán)隊(duì)二、三大框架架構(gòu)深度對(duì)比2.1 LangChain萬能瑞士軍刀LangChain 的核心抽象是Chain鏈——把 LLM 調(diào)用、Prompt 模板、工具調(diào)用、檢索器等組件像鏈條一樣串聯(lián)。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. 向量化 存儲(chǔ) embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) ? # 4. 構(gòu)建檢索鏈 llm ChatOpenAI(modelgpt-4o, temperature0) retriever vectorstore.as_retriever(search_typemmr, search_kwargs{k: 5}) ? # 5. 自定義 Prompt prompt ChatPromptTemplate.from_template( 基于以下檢索到的上下文回答問題。如果上下文中沒有相關(guān)信息請(qǐng)說我不知道。 ? 上下文 {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])架構(gòu)特點(diǎn)優(yōu)勢(shì)組件最豐富100 文檔加載器、20 向量庫、20 Embedding 模型LCELLangChain Expression Language聲明式編排靈活A(yù)gent 生態(tài)成熟工具調(diào)用、多步推理、ReAct 模式社區(qū)最大文檔教程最多劣勢(shì)抽象層過多簡(jiǎn)單 RAG 也要寫不少膠水代碼版本迭代頻繁API 經(jīng)常 breaking change1.0 前 vs 后差異大檢索能力不是核心專長(zhǎng)高級(jí)檢索需要自己組裝生產(chǎn)部署需要額外搭 LangServe2.2 LlamaIndexRAG 專精框架LlamaIndex 的核心理念是以數(shù)據(jù)為中心——所有設(shè)計(jì)都圍繞如何更好地索引、檢索、生成。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 原生支持更精細(xì)的切分 node_parser SentenceSplitter( chunk_size512, chunk_overlap50, paragraph_separator\n\n\n ) ? # 4. 向量存儲(chǔ)直接用 Milvus vector_store MilvusVectorStore( urihttp://localhost:19530, collection_nameknowledge_base, dim1536, overwriteFalse ) ? # 5. 構(gòu)建索引 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. 構(gòu)建查詢引擎 query_engine index.as_query_engine( similarity_top_k10, # 先檢索 10 個(gè) node_postprocessors[reranker] # 重排序取 3 個(gè) ) ? # 8. 查詢 response query_engine.query(公司的退款政策是什么) print(response.response)架構(gòu)特點(diǎn)優(yōu)勢(shì)檢索能力最強(qiáng)原生支持向量檢索 關(guān)鍵詞檢索 知識(shí)圖譜三種索引Query Engine 抽象設(shè)計(jì)精良支持子查詢、多步檢索、遞歸檢索內(nèi)置 Reranker、HyDE、Query Transformation 等高級(jí) RAG 技術(shù)數(shù)據(jù)連接器豐富Notion、Slack、GitHub、Confluence 等 40LlamaParse 文檔解析能力尤其 PDF 表格業(yè)界領(lǐng)先劣勢(shì)偏重 RAG 場(chǎng)景做 Agent / 工具調(diào)用不如 LangChain學(xué)習(xí)曲線相對(duì)陡峭Index → Retriever → QueryEngine 多層抽象可視化和管理工具不如 Dify2.3 Dify低代碼 LLMOps 平臺(tái)Dify 走的是完全不同的路線——可視化編排 一站式 LLMOps。# Dify 通過 Web UI 拖拽編排配置文件大致如下 # 實(shí)際操作在 Web 界面完成這里用 YAML 表示邏輯結(jié)構(gòu) ? workflow: name: 企業(yè)知識(shí)庫問答 nodes: - id: start type: start variables: - name: query type: string ? - id: knowledge_retrieval type: knowledge-retrieval dataset_id: kb_2024 retrieval_mode: hybrid # 向量 關(guān)鍵詞混合檢索 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}}架構(gòu)特點(diǎn)優(yōu)勢(shì)零代碼上手產(chǎn)品經(jīng)理也能搭 RAG 應(yīng)用一站式平臺(tái)知識(shí)庫管理 模型管理 應(yīng)用發(fā)布 監(jiān)控Workflow 編排器支持復(fù)雜邏輯條件分支、循環(huán)、HTTP 調(diào)用內(nèi)置多種應(yīng)用類型Chatbot、Agent、文本生成、Workflow自帶 API 網(wǎng)關(guān)直接對(duì)外提供服務(wù)劣勢(shì)深度定制能力受限復(fù)雜的檢索邏輯不如代碼靈活框架本身較重部署需要 Docker Compose 或 K8s代碼侵入性強(qiáng)一旦用 Dify 很難遷移到其他框架高級(jí)特性如自定義 Reranker需要企業(yè)版三、核心能力橫向?qū)Ρ?.1 文檔處理能力3.2 檢索能力3.3 生產(chǎn)部署能力四、實(shí)測(cè)同一知識(shí)庫三大框架性能對(duì)比4.1 測(cè)試環(huán)境硬件 - CPU: Intel Xeon 8358 (2.6GHz, 32C) - GPU: 1× A100 40G - 內(nèi)存: 256GB - 存儲(chǔ): NVMe SSD ? 軟件 - Python 3.11 - LangChain 0.3.x - LlamaIndex 0.11.x - Dify 0.15.x (Docker 部署) - 向量庫: Milvus 2.4 (獨(dú)立部署) - LLM: GPT-4o (API) - Embedding: text-embedding-3-small ? 數(shù)據(jù)集 - 500 份企業(yè)文檔PDF Word Markdown - 總計(jì)約 1200 萬字 - 切分后約 24000 個(gè) chunks - 評(píng)測(cè)問題 200 道含單跳/多跳/對(duì)比/摘要四類4.2 索引構(gòu)建性能4.3 檢索質(zhì)量對(duì)比使用 200 道評(píng)測(cè)題統(tǒng)計(jì) Recall5 和 MRR平均倒數(shù)排名結(jié)論LlamaIndex 在檢索質(zhì)量上全面領(lǐng)先尤其在多跳問答場(chǎng)景下優(yōu)勢(shì)顯著SubQuestionQueryEngine 自動(dòng)拆分子查詢的能力是關(guān)鍵。4.4 端到端延遲單次問答從用戶提問到返回完整答案組件LangChainLlamaIndexDify查詢向量化120ms118ms125ms向量檢索45ms43ms48msReranker180ms175ms185msLLM 生成2.3s2.3s2.4s框架開銷85ms62ms210ms總延遲2.73s2.70s2.97sDify 的框架開銷明顯高于另外兩者多了一層 API 網(wǎng)關(guān) Workflow 引擎但絕對(duì)差距在可接受范圍內(nèi)。4.5 開發(fā)效率對(duì)比實(shí)現(xiàn)同樣功能含文檔上傳、知識(shí)庫構(gòu)建、問答、多輪對(duì)話、流式輸出指標(biāo)LangChainLlamaIndexDify代碼行數(shù)~180 行~120 行~0 行UI 配置開發(fā)時(shí)間~4 小時(shí)~3 小時(shí)~1 小時(shí)需要的先驗(yàn)知識(shí)Python LangChain APIPython LlamaIndex 概念基本無調(diào)試難度中鏈?zhǔn)秸{(diào)用報(bào)錯(cuò)信息長(zhǎng)中多層抽象需理解低UI 可視化五、選型決策樹場(chǎng)景化推薦場(chǎng)景推薦框架理由企業(yè)內(nèi)部知識(shí)庫問答Dify非技術(shù)人員也能管理知識(shí)庫自帶用戶管理對(duì)檢索質(zhì)量要求極高法律/醫(yī)療LlamaIndex多索引 子查詢 Reranker檢索質(zhì)量最優(yōu)復(fù)雜 Agent多工具調(diào)用 推理LangChainAgent 生態(tài)最成熟工具鏈最豐富快速 MVP 驗(yàn)證Dify1 小時(shí)搭出可用 demo多數(shù)據(jù)源 RAGNotion DB APILlamaIndex40 數(shù)據(jù)連接器QueryFusion 多路召回需要深度定制檢索邏輯LangChain組件可自由組合不設(shè)限需要運(yùn)維監(jiān)控 AB 測(cè)試Dify內(nèi)置完整 LLMOps 能力知識(shí)圖譜 向量混合檢索LlamaIndex唯一原生支持 KG Vector 的框架六、混合方案生產(chǎn)環(huán)境最佳實(shí)踐在實(shí)際生產(chǎn)中三個(gè)框架并非互斥。一個(gè)常見的成熟架構(gòu)是分工邏輯Dify 負(fù)責(zé)應(yīng)用層UI、API、監(jiān)控、用戶管理LlamaIndex 負(fù)責(zé)檢索層文檔解析、索引構(gòu)建、多路檢索、RerankLangChain 負(fù)責(zé)生成層Agent 編排、工具調(diào)用、復(fù)雜推理Milvus 作為獨(dú)立向量數(shù)據(jù)庫這種架構(gòu)的好處是各取所長(zhǎng)但復(fù)雜度也最高——適合有專門 AI 團(tuán)隊(duì)的企業(yè)。七、三個(gè)框架的常見踩坑LangChain 踩坑坑 1版本兼容性噩夢(mèng)# 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 是全局的多索引場(chǎng)景會(huì)互相覆蓋 # 解決在每個(gè) index 構(gòu)建時(shí)顯式傳入 llm 和 embed_model index VectorStoreIndex.from_documents( documents, llmcustom_llm, # 顯式傳入 embed_modelcustom_embed, # 顯式傳入 )坑 2Reranker 模型首次加載慢# SentenceTransformerRerank 首次使用會(huì)下載模型~80MB # 預(yù)加載到本地避免生產(chǎn)環(huán)境首次請(qǐng)求超時(shí) from sentence_transformers import SentenceTransformer SentenceTransformer(cross-encoder/ms-marco-MiniLM-L-6-v2) # 預(yù)熱Dify 踩坑坑 1知識(shí)庫切分策略不可自定義Dify 內(nèi)置切分策略只有 3 種 - 自動(dòng)切分按段落 字?jǐn)?shù)上限 - 按段落切分 - 按固定字?jǐn)?shù)切分 ? 不支持遞歸切分、語義切分等高級(jí)策略。 解決先在外部用 LlamaIndex 切分再逐條上傳到 Dify 知識(shí)庫?？?2Workflow 不支持循環(huán)Dify Workflow 引擎不支持 for/while 循環(huán)結(jié)構(gòu)。 如果需要檢索→判斷→再檢索的迭代邏輯 只能用 Agent 模式但 Agent 模式延遲更高。八、成本對(duì)比開發(fā)成本項(xiàng)目LangChainLlamaIndexDify學(xué)習(xí)時(shí)間2-3 天2-3 天0.5 天MVP 開發(fā)4 小時(shí)3 小時(shí)1 小時(shí)生產(chǎn)級(jí)開發(fā)2-3 周1.5-2 周3-5 天運(yùn)維成本中自建 API中自建 API低內(nèi)置監(jiān)控運(yùn)行成本項(xiàng)目LangChainLlamaIndexDify框架開銷低低中多一層網(wǎng)關(guān)GPU 需求同等同等同等服務(wù)器最低配置4C8G4C8G8C16G含平臺(tái)自身LLM API 成本同等同等同等但可做多模型負(fù)載均衡省錢九、總結(jié)與建議維度最優(yōu)選擇檢索質(zhì)量LlamaIndex開發(fā)速度Dify靈活定制LangChainAgent 能力LangChain生產(chǎn)運(yùn)維Dify社區(qū)生態(tài)LangChain文檔解析LlamaIndex (LlamaParse)低代碼友好Dify一句話建議如果你是獨(dú)立開發(fā)者 / 小團(tuán)隊(duì)直接用 Dify1 小時(shí)上線省下的時(shí)間做業(yè)務(wù)如果你是 AI 工程師 / 追求效果LlamaIndex 做檢索核心效果天花板最高如果你要做復(fù)雜 AI AgentLangChain 的 Agent 生態(tài)無可替代如果你有 AI 團(tuán)隊(duì)做生產(chǎn)系統(tǒng)Dify應(yīng)用層 LlamaIndex檢索層 LangChainAgent 層混合架構(gòu)專欄導(dǎo)航上一篇ESP32 開發(fā)環(huán)境搭建指南從零配置到編譯燒錄的 12 個(gè)坑下一篇kafka 深度解剖 StickyAssignor 分區(qū)分配策略如果覺得有用點(diǎn)贊收藏關(guān)注三連支持一下這個(gè)專欄會(huì)持續(xù)更新 RAG 和大模型部署的深度內(nèi)容。下周我們會(huì)發(fā)布 RAG 架構(gòu)設(shè)計(jì) 7 個(gè)關(guān)鍵決策的深度文章別錯(cuò)過