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_size=512,        # token数
    chunk_overlap=50,      # 重叠token数
    # LlamaIndex的独特参数
    paragraph_separator="\n\n",  # 优先在此处分割
    secondary_chunking_regex="[^,.;]+[,.;]?",  # 次级分割模式
)

# 语义分割——LlamaIndex的差异化能力
# 通过embedding相似度检测语义边界，这是LangChain中没有内置的能力
semantic_splitter = SemanticSplitter(
    buffer_size=1,          # 评估窗口大小
    breakpoint_percentile_threshold=95,  # 语义断点阈值
    embed_model=OpenAIEmbedding(),
)

# === LangChain 分割 ===
from langchain.text_splitter import (
    RecursiveCharacterTextSplitter,
    MarkdownHeaderTextSplitter,
)

# 递归字符分割（默认）
recursive_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    # LangChain的独特参数
    separators=["\n\n", "\n", "。", ".", " ", ""],  # 优先级顺序
    length_function=len,  # 自定义长度函数
)

# 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(
    index=index,
    similarity_top_k=10,  # 初始检索10条
)
query_engine = RetrieverQueryEngine.from_args(
    retriever=retriever,
    # LlamaIndex内置的后处理器链
    node_postprocessors=[
        SimilarityPostprocessor(similarity_cutoff=0.7),  # 相似度过滤
    ],
    # 响应合成模式
    response_mode="compact",  # 压缩后再生成
)

# === 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(
    retriever=base_retriever,
    llm=llm,
)

compressor = LLMChainFilter.from_llm(llm)
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=multi_query_retriever,
)

四、两个框架的边界与适用场景

选择LlamaIndex的场景：

• 构建以文档为中心的QA系统（文档是核心资产）
• 需要使用复杂的数据连接器（LlamaHub有300+）
• 需要内置的索引持久化和版本管理
• 团队偏好"数据优先"的思维模型

选择LangChain的场景：

• 构建包含多步推理的复杂Agent
• 需要高度定制化的检索-生成管道
• 链式组件的高频替换和AB测试
• 已经有LangChain技术栈的其他组件

graph TD
    A[RAG框架选型] --> B{核心关注点}
    B -->|数据索引| C[LlamaIndex<br/>数据为中心的API]
    B -->|流程编排| D[LangChain<br/>链式组合的API]
    A --> E{团队背景}
    E -->|数据工程| C
    E -->|软件工程| D
    A --> F{复杂度需求}
    F -->|标准RAG| C
    F -->|多Agent协同| D

五、总结

LlamaIndex和LangChain在RAG领域的竞争反映了两种工程哲学的分歧：数据索引视角 vs. 链式组合视角。LlamaIndex的优势在于文档处理的开箱即用性（语义分割、多样化检索后处理）和数据资产的持久化管理。LangChain的优势在于管道的可组合性和灵活性（每个组件可替换）。在实际项目中，两者并非互斥——可以在LlamaIndex中管理索引，在LangChain中编排Agent逻辑。选择标准应从"哪个框架更好"转变为"哪个框架的默认假设更接近你的场景"。