LlamaIndex与LangChain的RAG管道对比：文档分割、检索与生成的全链路分析

LlamaIndex与LangChain的RAG管道对比文档分割、检索与生成的全链路分析一、RAG框架的管道抽象之争检索增强生成RAG已成为LLM应用的事实标准架构。其核心管道——文档加载→文本分割→向量化→检索→提示构建→生成——在概念上简洁明了但在工程实现中各环节的设计选择会显著影响最终效果。LlamaIndex前身为GPT Index和LangChain是两个主流的RAG框架但它们的设计哲学有本质区别。LlamaIndex以数据索引为中心将文档视为需要被结构化索引的信息源其API围绕索引的构建、查询和更新设计。LangChain以链式组合为中心将RAG视为一系列可组合的组件Document Loader → Text Splitter → VectorStore → Retriever → LLM Chain强调组件的可替换性和灵活性。这种设计哲学差异导致了在相同RAG任务上两个框架提供了不同的默认行为、优化策略和扩展方式。graph TB subgraph LlamaIndex 数据索引视角 A1[文档] -- B1[解析器] B1 -- C1[节点解析br/Node Parser] C1 -- D1[向量存储索引br/VectorStoreIndex] D1 -- E1[查询引擎br/QueryEngine] E1 -- F1[响应合成br/Response Synthesizer] end subgraph LangChain 链式组合视角 A2[文档] -- B2[Document Loader] B2 -- C2[Text Splitter] C2 -- D2[VectorStore] D2 -- E2[Retriever] E2 -- F2[LLM Chain] end二、文档分割策略——最被低估的RAG环节文档分割Chunking对RAG性能的影响常被低估。两个框架在默认分割策略和高级分割选项上的差异反映了它们的设计哲学。LlamaIndex的分割器提供了丰富的语义感知选项SentenceSplitter基于句子边界分割默认保持语义完整性TokenTextSplitter基于token数分割保证chunk大小精确CodeSplitter基于AST分析分割代码保持函数/类的完整性SemanticSplitter通过embedding相似度检测语义转折点LangChain的分割器更侧重文本结构RecursiveCharacterTextSplitter按优先级段落→句子→词→字符递归分割MarkdownHeaderTextSplitter按Markdown标题层级分割HTMLHeaderTextSplitter按HTML标题层级分割# 两个框架在相同文档上的分割行为对比 # 设计思路使用同一文档比较两个框架的默认分割结果 # LlamaIndex 分割 from llama_index.core.node_parser import ( SentenceSplitter, SemanticSplitter, ) from llama_index.embeddings.openai import OpenAIEmbedding # 基于句子分割默认 sentence_splitter SentenceSplitter( chunk_size512, # token数 chunk_overlap50, # 重叠token数 # LlamaIndex的独特参数 paragraph_separator\n\n, # 优先在此处分割 secondary_chunking_regex[^,.;][,.;]?, # 次级分割模式 ) # 语义分割——LlamaIndex的差异化能力 # 通过embedding相似度检测语义边界这是LangChain中没有内置的能力 semantic_splitter SemanticSplitter( buffer_size1, # 评估窗口大小 breakpoint_percentile_threshold95, # 语义断点阈值 embed_modelOpenAIEmbedding(), ) # LangChain 分割 from langchain.text_splitter import ( RecursiveCharacterTextSplitter, MarkdownHeaderTextSplitter, ) # 递归字符分割默认 recursive_splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap50, # LangChain的独特参数 separators[\n\n, \n, 。, ., , ], # 优先级顺序 length_functionlen, # 自定义长度函数 ) # Markdown感知分割——LangChain的差异化能力 markdown_splitter MarkdownHeaderTextSplitter( headers_to_split_on[ (#, Header 1), (##, Header 2), (###, Header 3), ] )三、检索增强策略——从朴素检索到高级RAG两个框架都提供了从基础到高级的检索增强策略但实现路径不同LlamaIndex的高级检索通过查询转换实现SubQuestionQueryEngine将复杂问题分解为子问题逐一检索HyDEQueryTransform先生成假设文档再以其embedding检索FLAREInstructQueryEngine在生成过程中动态检索补充信息LangChain的高级检索通过链的嵌套组合实现MultiQueryRetriever用LLM生成多个变体查询合并检索结果ContextualCompressionRetriever检索后压缩过滤不相关内容EnsembleRetriever多检索器的加权混合# 两个框架的高级检索模式对比 # 设计思路实现相同的多查询混合检索逻辑展示API差异 # LlamaIndex 实现 from llama_index.core.query_engine import RetrieverQueryEngine from llama_index.core.retrievers import VectorIndexRetriever from llama_index.core.postprocessor import SimilarityPostprocessor # LlamaIndex的查询引擎模式以数据为中心 retriever VectorIndexRetriever( indexindex, similarity_top_k10, # 初始检索10条 ) query_engine RetrieverQueryEngine.from_args( retrieverretriever, # LlamaIndex内置的后处理器链 node_postprocessors[ SimilarityPostprocessor(similarity_cutoff0.7), # 相似度过滤 ], # 响应合成模式 response_modecompact, # 压缩后再生成 ) # LangChain 实现 from langchain.retrievers import ( ContextualCompressionRetriever, MultiQueryRetriever, ) from langchain.retrievers.document_compressors import LLMChainFilter # LangChain的链式模式以流程为中心 base_retriever vectorstore.as_retriever( search_kwargs{k: 10} ) # 多层包装MultiQuery → Compression # 每层包装是一个独立的链 multi_query_retriever MultiQueryRetriever.from_llm( retrieverbase_retriever, llmllm, ) compressor LLMChainFilter.from_llm(llm) compression_retriever ContextualCompressionRetriever( base_compressorcompressor, base_retrievermulti_query_retriever, )四、两个框架的边界与适用场景选择LlamaIndex的场景构建以文档为中心的QA系统文档是核心资产需要使用复杂的数据连接器LlamaHub有300需要内置的索引持久化和版本管理团队偏好数据优先的思维模型选择LangChain的场景构建包含多步推理的复杂Agent需要高度定制化的检索-生成管道链式组件的高频替换和AB测试已经有LangChain技术栈的其他组件graph TD A[RAG框架选型] -- B{核心关注点} B --|数据索引| C[LlamaIndexbr/数据为中心的API] B --|流程编排| D[LangChainbr/链式组合的API] A -- E{团队背景} E --|数据工程| C E --|软件工程| D A -- F{复杂度需求} F --|标准RAG| C F --|多Agent协同| D五、总结LlamaIndex和LangChain在RAG领域的竞争反映了两种工程哲学的分歧数据索引视角 vs. 链式组合视角。LlamaIndex的优势在于文档处理的开箱即用性语义分割、多样化检索后处理和数据资产的持久化管理。LangChain的优势在于管道的可组合性和灵活性每个组件可替换。在实际项目中两者并非互斥——可以在LlamaIndex中管理索引在LangChain中编排Agent逻辑。选择标准应从哪个框架更好转变为哪个框架的默认假设更接近你的场景。