如何解决 RAG 在处理长文档时出现的检索片段断层问题？

针对长文档 RAG 出现的“检索片段断层”，最核心的痛点在于传统的 Fixed-size Chunking（固定长度切分）会把一个完整的逻辑语义强行劈成两半，导致 Embedding 向量丢失上下文，检索出来的片段像碎片一样，模型根本拼不回原意。

我最近在跑一个 50 页的行业技术白皮书测试，用标准的 500 token 切分，发现只要关键答案跨页或跨段落，检索回来的 Top-k 片段之间存在巨大的语义断裂，LLM 经常在回答时出现“幻觉”或者直接说找不到相关信息。

实测下来，解决这个问题不能只靠调大 Chunk Size，因为那样会导致噪声增加，稀释关键信息。目前最有效的方案是「父子索引 (Parent-Document Retrieval)」+「滑动窗口重叠 (Sliding Window)」。

实测对比表现：

方案 A：纯固定切分 (Naive RAG)

• 表现：检索精准度低，容易在语义转折点断开。
• 缺点：答案碎片化，模型无法还原上下文。

方案 B：滑动窗口 (Overlap)

• 设置：chunk_size=500, chunk_overlap=100。
• 表现：缓解了断层，但依然存在大量重复内容，浪费上下文窗口。

方案 C：父子索引 (Parent-Document Retrieval)

• 逻辑：将文档切分为大的 Parent Chunk（如 1000 token）和小的 Child Chunk（如 200 token）。检索时匹配 Child，但喂给 LLM 的是其所属的 Parent。
• 表现：检索精度（由子块保证）和上下文完整度（由父块保证）达到了平衡，长文档的长程依赖问题基本解决。

在具体实现上，如果你用 LangChain，可以尝试 ParentDocumentRetriever。这里给个简化的逻辑配置参考：

from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import InMemoryStore
from langchain.text_splitter import RecursiveCharacterTextSplitter

# 子块用于向量检索，保证命中率
child_splitter = RecursiveCharacterTextSplitter(chunk_size=200)
# 父块用于提供给LLM，保证语义连续
parent_splitter = RecursiveCharacterTextSplitter(chunk_size=1000)

retriever = ParentDocumentRetriever(
    vectorstore=vectorstore,
    docstore=InMemoryStore(),
    child_splitter=child_splitter,
    parent_splitter=parent_splitter,
)

此外，对于极长且结构复杂的文档，我建议在切分前先用 LLM 做一次 「语义分段 (Semantic Chunking)」。即通过计算相邻句子的 Cosine Similarity，在语义发生剧烈变化的临界点才进行切分，而不是死板地数字符。

模型选择上，处理这类检索回来的长上下文，Claude 3.5 Sonnet 的理解力明显强于 GPT-4o，它在面对带有少量噪声的长片段时，提取核心答案的鲁棒性更高，不容易被片段之间的衔接瑕疵干扰。