1. 项目概述：为什么我们需要更聪明的“分块”？

如果你已经尝试过构建自己的RAG（检索增强生成）应用，无论是用LangChain、LlamaIndex还是其他框架，大概率都踩过“分块”这个坑。简单来说，分块就是把长文档（比如PDF、网页文章）切成一个个小片段，然后转换成向量存起来，方便后续检索。听起来很简单，对吧？但问题恰恰出在这里：传统的固定长度分块（比如每512个字符切一刀）或者按段落、标题分块，在实际应用中经常“翻车”。

我遇到过最典型的情况是：用户问一个非常具体的问题，比如“合同里关于违约金的计算方式是什么？”。系统检索出来的，可能只是包含“违约金”三个字的一个句子片段，比如“...应支付违约金...”，而真正关键的上下文——计算基数、比例、支付时限——都在前几段或后几段里，因为被生硬地切开了，导致模型拿到的信息是残缺的，回答自然也就含糊不清甚至错误。另一个常见场景是技术文档，一个函数定义的参数说明可能跨了好几个自然段，固定分块很容易把函数名和它的关键参数分隔开。

这就是“Parent-Child”与“Contextual Retrieval”这类高级分块策略要解决的核心痛点。它们不再是机械地切割文本，而是开始考虑文本的语义结构和检索时的上下文需求。Parent-Child策略像是一个“分层地图”，它保留了文档的层级关系；而Contextual Retrieval则更像一个“智能秘书”，在检索时懂得把相关的信息“打包”给你。这不仅仅是提升召回率，更是为了提升最终答案的准确性和连贯性。对于开发面向企业知识库、法律文档分析、长篇幅研究报告等复杂场景的RAG应用来说，掌握这些策略是从“玩具demo”走向“生产可用”的关键一步。

2. 核心思路拆解：从“切片”到“图谱”

在深入代码之前，我们必须先理解这两种策略背后的设计哲学。它们代表了两种不同的优化方向，但最终目的都是让检索结果更“有用”。

2.1 Parent-Child 分块：构建文档的“家谱树”

Parent-Child分块的核心思想是建立两个层次的索引。

1. 父文档（Parent）：这是一个较大的、完整的语义单元。例如，一个完整的章节、一个FAQ问答对、一个独立的合同条款。它包含了该主题下相对完整的信息。
2. 子文档（Child）：这是从父文档中进一步切分出来的、更小的片段。通常，我们会用较小的、重叠的子块（例如每200字符，重叠50字符）来确保检索的粒度足够细。

它们如何协同工作？在检索时，系统首先在子文档级别进行向量相似度搜索。因为子文档更小，与查询的语义匹配可以更精准。一旦找到相关的子文档，系统不会直接返回这个子文档片段给LLM，而是返回其对应的整个父文档作为上下文。

为什么这样做？

• 解决上下文碎片化：即使检索命中了一个不完整的句子，LLM也能获得该句子所在的完整语义背景（整个条款或章节），极大减少了因信息缺失导致的幻觉。
• 平衡召回率与上下文长度：细粒度的子块保证了高召回率，而返回父文档则提供了充足、连贯的上下文，避免了给LLM一堆零碎的“拼图”。
• 保留结构信息：父文档天然承载了文档的层级结构（如章节标题），这对于LLM理解信息在全文中的位置和重要性很有帮助。

类比：想象你要在一本百科全书里找“光合作用中光反应的具体步骤”。传统分块可能只给你撕下来一页纸的一角，上面写着“NADPH生成”。而Parent-Child策略会先通过那一角定位到“光合作用”这个完整的词条（父文档），然后把整个词条给你。你得到的答案自然会全面、准确得多。

2.2 Contextual Retrieval：动态的“上下文装配”

如果说Parent-Child是在索引阶段预设了上下文关系，那么Contextual Retrieval则是在检索阶段动态地、智能地扩展上下文。它的核心不是改变分块方式，而是优化检索后的结果处理流程。

一个典型的Contextual Retrieval流程包含以下步骤：

1. 初步检索：使用标准方法（如基于子块向量检索）获取top-k个最相关的文档块。
2. 上下文扩展：对于每一个初步检索到的相关块，系统会去查找它在原始文档中的“邻居”。这不仅仅是前后相邻的块，而是根据文档结构（如标题层级、段落归属）或语义相似度，动态地选取一定数量的相关块。
3. 上下文融合：将初步检索到的核心块和扩展得到的邻居块，按合理的顺序（通常是原文顺序）组合成一个新的、更丰富的上下文文本。
4. 最终投喂：将这个融合后的、加长了上下文的文本，送入LLM生成答案。

它的优势在哪里？

• 极强的灵活性：上下文扩展的策略可以多种多样，可以向前后扩展固定数量的字符/块，也可以扩展到同一个章节的所有内容，甚至可以根据初步检索结果的关键词进行二次语义检索。
• 解决“边缘命中”问题：有时答案的关键信息恰好落在两个块的边界上。传统检索可能只命中其中一个，而上下文扩展能自动把相邻块包含进来。
• 适配不同查询需求：对于简单事实性问题，可能不需要太多扩展；对于需要推理、总结的复杂问题，则可以扩展更广泛的上下文。

类比：这就像你问朋友“上次开会说的项目预算最后定了多少？”。一个简单的回答可能是“定了100万”。但Contextual Retrieval会把你朋友当时说的话前后相关的部分也告诉你：“…经过激烈讨论，考虑到市场变化…最终，项目预算定为100万，分两个季度拨付…”。后者提供的决策背景，让这个数字更有意义。

在实际项目中，这两种策略常常结合使用。例如，先用Parent-Child建立索引，确保检索的准确性；在返回父文档后，再根据当前查询，在父文档内部进行小范围的Contextual Retrieval，进一步精炼上下文。接下来，我们就看看如何在LangChain中实现它们。

3. 实战：基于LangChain实现高级分块策略

LangChain提供了丰富的工具链，让我们能够相对优雅地实现这些高级策略。这里我将以一个处理长篇技术文档（例如API手册）的场景为例，分步拆解。

3.1 环境准备与文档加载

首先，确保你的环境已安装必要库。这里我们主要用到langchain的核心文本拆分、向量存储和检索器模块，以及一个嵌入模型和向量数据库（以Chroma为例）。

pip install langchain langchain-community chromadb tiktoken

我们假设有一个名为api_manual.md的Markdown格式技术文档。使用LangChain的文档加载器读取它。

from langchain_community.document_loaders import TextLoader loader = TextLoader(‘api_manual.md‘, encoding=‘utf-8‘) documents = loader.load() # 此时 documents 是一个列表，里面只有一个Document对象，其page_content包含了整个文档的文本。

3.2 实现Parent-Child分块索引

这是最关键的一步。我们需要创建两种尺寸的文本分割器，并建立它们之间的关联。

步骤一：定义分割器

• 父分割器：按文档的大标题（如##）进行分割。这样每个父块就是一个完整的API接口说明章节。
• 子分割器：在父块的基础上，用更小的、带重叠的滑动窗口进行分割，以确保检索粒度。

from langchain.text_splitter import RecursiveCharacterTextSplitter, MarkdownHeaderTextSplitter # 1. 首先，按Markdown标题划分出父文档 headers_to_split_on = [ (“#“, “Header 1“), (“##“, “Header 2“), # 我们假设##是API接口的名称，以此作为父块 (“###“, “Header 3“), ] markdown_splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) md_header_splits = markdown_splitter.split_text(documents[0].page_content) # md_header_splits 现在是一个个的Document，每个Document的metadata里记录了它所属的标题。 # 2. 然后，对每个父文档块，用递归字符分割器创建子块 child_splitter = RecursiveCharacterTextSplitter( chunk_size=400, # 子块较小 chunk_overlap=50, # 重叠避免切断句子 separators=[“\n\n“, “\n“, “。“, “；“, “，“, “ “, ““], # 分隔符优先级 length_function=len, ) all_child_docs = [] parent_docs = [] for i, parent_doc in enumerate(md_header_splits): # 为每个父块生成唯一ID，并存储 parent_id = f“parent_{i}“ parent_doc.metadata[“parent_id“] = parent_id parent_doc.metadata[“source“] = “api_manual.md“ parent_docs.append(parent_doc) # 将父块内容切分成子块 child_docs = child_splitter.split_documents([parent_doc]) for child in child_docs: # 在每个子块的元数据中，记录其父块的ID child.metadata[“parent_id“] = parent_id all_child_docs.extend(child_docs)

步骤二：创建向量存储并建立关联我们需要将子文档向量化并存入向量数据库，同时以某种形式存储父文档，以便后续根据parent_id查找。

from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings # 示例用OpenAI，可替换为其他模型 import os os.environ[“OPENAI_API_KEY“] = “your-api-key“ embeddings = OpenAIEmbeddings(model=“text-embedding-3-small“) # 只对子文档创建向量存储 vectorstore = Chroma.from_documents( documents=all_child_docs, embedding=embeddings, collection_name=“api_child_chunks“, persist_directory=“./chroma_db“ ) vectorstore.persist() # 同时，我们需要一个字典或简单数据库来存储父文档ID到其完整内容的映射。 # 这里用一个简单的字典在内存中模拟，生产环境可存入SQLite或文档数据库。 parent_id_to_doc = {doc.metadata[“parent_id“]: doc for doc in parent_docs}

关键提示：这里有一个重要的设计选择。我们只索引了子文档，因为子文档数量多、粒度细，是检索的第一现场。父文档作为“上下文仓库”单独存储。这比将父子文档都做向量化更节省资源，且逻辑更清晰。

3.3 构建支持Parent-Child检索的检索器

现在，我们需要自定义一个检索器，它先检索子块，然后返回对应的父文档。

from langchain.retrievers import BaseRetriever from typing import List from langchain.schema import Document class ParentChildRetriever(BaseRetriever): def __init__(self, vectorstore, parent_map, k=5): self.vectorstore = vectorstore self.parent_map = parent_map # 之前存储的 parent_id_to_doc 字典 self.k = k # 初始检索的子块数量 def _get_relevant_documents(self, query: str) -> List[Document]: # 1. 在子块向量库中检索 child_docs = self.vectorstore.similarity_search(query, k=self.k) # 2. 获取这些子块对应的父块ID，并去重 parent_ids = set() for doc in child_docs: if “parent_id“ in doc.metadata: parent_ids.add(doc.metadata[“parent_id“]) # 3. 根据父块ID，取出完整的父文档 relevant_parent_docs = [] for pid in parent_ids: if pid in self.parent_map: relevant_parent_docs.append(self.parent_map[pid]) # 4. 返回父文档列表 return relevant_parent_docs async def _aget_relevant_documents(self, query: str) -> List[Document]: # 异步实现，这里简化处理，调用同步方法 return self._get_relevant_documents(query) # 初始化检索器 retriever = ParentChildRetriever(vectorstore=vectorstore, parent_map=parent_id_to_doc, k=3)

这个自定义检索器完成了核心逻辑：输入查询 -> 检索相关子块 -> 映射到父块 -> 返回父块。现在，当你使用这个检索器时，LLM获得的上下文就是一个完整的API接口说明章节，而不是零碎的代码片段。

3.4 集成Contextual Retrieval进行动态扩展

有了完整的父文档作为基础上下文，我们还可以在它内部做进一步的动态扩展，这就是Contextual Retrieval的思路。我们可以创建一个“包装器”检索器来实现。

假设我们的父文档（一个API章节）本身可能也很长，我们想在检索到它之后，再根据查询，定位到这个章节内部最相关的部分。

from langchain.text_splitter import RecursiveCharacterTextSplitter class ContextualExpansionRetriever(BaseRetriever): def __init__(self, base_retriever, expander_splitter, expansion_k=2): self.base_retriever = base_retriever # 例如上面定义的ParentChildRetriever self.expander_splitter = expander_splitter # 用于在父文档内部分块的拆分器 self.expansion_k = expansion_k # 在核心块前后各扩展多少块 def _get_relevant_documents(self, query: str) -> List[Document]: # 1. 基础检索：获取父文档 parent_docs = self.base_retriever.get_relevant_documents(query) final_docs = [] for parent_doc in parent_docs: # 2. 将父文档内容再次分块（小块，用于精确定位） small_chunks = self.expander_splitter.split_documents([parent_doc]) # 3. 为这些小块创建临时向量库（或使用其他方式找到最相关的一个） # 这里简化处理：计算查询与每个小块的嵌入相似度（实际生产需优化） from langchain_community.vectorstores import Chroma temp_store = Chroma.from_documents(small_chunks, embedding=OpenAIEmbeddings()) # 找到最相关的一个小块 most_relevant_chunks = temp_store.similarity_search(query, k=1) if not most_relevant_chunks: final_docs.append(parent_doc) continue core_chunk = most_relevant_chunks[0] core_index = small_chunks.index(core_chunk) # 找到核心块在列表中的位置 # 4. 动态扩展：取核心块及其前后各 expansion_k 个块 start_idx = max(0, core_index - self.expansion_k) end_idx = min(len(small_chunks), core_index + self.expansion_k + 1) expanded_chunks = small_chunks[start_idx:end_idx] # 5. 合并扩展后的块，形成新的上下文文档 expanded_content = “\n\n“.join([chunk.page_content for chunk in expanded_chunks]) new_doc = Document( page_content=expanded_content, metadata=parent_doc.metadata # 保留父文档的元数据，如来源 ) final_docs.append(new_doc) return final_docs # 创建用于在父文档内部分割的拆分器（块更小） internal_splitter = RecursiveCharacterTextSplitter(chunk_size=200, chunk_overlap=20) # 组合检索器：先Parent-Child，再动态扩展 contextual_retriever = ContextualExpansionRetriever( base_retriever=retriever, expander_splitter=internal_splitter, expansion_k=1 # 前后各扩展1块 )

现在，contextual_retriever就是一个功能强大的检索器了。它的工作流程是：查询 -> 找到相关的完整API章节（Parent）-> 在该章节内定位到最相关的具体段落（Child）-> 将该段落及其前后文打包返回。这提供了极高的上下文精准度。

3.5 接入问答链进行测试

最后，我们将这个强大的检索器接入一个标准的RAG问答链。

from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI llm = ChatOpenAI(model=“gpt-4-turbo“, temperature=0) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type=“stuff“, # 对于我们已经精炼过的上下文，“stuff”方式简单高效 retriever=contextual_retriever, # 使用我们精心打造的检索器 return_source_documents=True, # 返回源文档，方便调试 chain_type_kwargs={“prompt“: ...} # 可以自定义提示词，这里省略 ) # 进行提问 question = “用户认证接口的access_token有效期是多长？“ result = qa_chain.invoke({“query“: question}) print(“答案：“, result[‘result‘]) print(“\n来源上下文：“) for doc in result[‘source_documents‘]: print(f“--- 片段 (来自 {doc.metadata.get(‘source‘, ‘N/A‘)}) ---“) print(doc.page_content[:500]) # 打印前500字符 print()

通过这样的流程，系统会先定位到“用户认证接口”整个章节，然后在章节内找到描述“access_token”参数的部分，并连同其有效期、刷新方式等上下文一起送给LLM，从而生成准确、可靠的答案。

4. 策略对比、选型与调优心得

实现之后，我们还需要知道在什么情况下选择哪种策略，以及如何调整参数。

4.1 Parent-Child vs. Contextual Retrieval 对比

经验之谈：对于大多数结构化文档，Parent-Child是基本盘，它能解决80%的上下文缺失问题。而Contextual Retrieval是优化器，当Parent-Child返回的父文档仍然太长（比如一个长达10页的章节），或者查询非常具体时，再用它进行内部精炼。两者结合使用效果最佳。

4.2 关键参数调优指南

1. 父块大小：父块应该是一个完整的“语义容器”。对于Markdown/HTML，按标题（H1, H2）分割是自然的。对于纯文本，可以尝试按章节标识符、固定长度（如2000字）或利用NLP句子分割模型来识别主题边界。
2. 子块大小与重叠：这是召回率的生命线。
   • 大小：通常比父块小一个数量级。常见范围在128-512字符（token）之间。需要权衡：太小则可能失去局部上下文，太大会降低检索精度。一个实用的技巧是，子块大小应能容纳一个完整的“问答对”或一个核心概念的定义。
   • 重叠：通常设置为子块大小的10%-25%。重叠能有效防止完整的句子或关键信息被切分在两块的边界。务必测试！可以尝试不同的重叠度，观察对长答案问题召回率的影响。
3. Contextual Expansion的“窗口”大小：即expansion_k，表示在核心块前后各扩展多少块。
   • 从1开始尝试。对于技术文档，扩展1-2个块（约400-800字符）通常足以覆盖必要的参数说明或示例代码。
   • 可以设计动态窗口：根据核心块与查询的相似度分数来决定扩展范围，分数越低（越模糊），扩展范围可以适当增大。

4.3 性能考量与生产建议

• 索引效率：Parent-Child需要存储和处理两份数据（父和子）。确保你的向量数据库支持高效的批量插入和元数据过滤。定期清理测试产生的临时向量集合。
• 检索延迟：Contextual Retrieval的二次检索或计算会增加延迟。如果对延迟敏感，可以：
  • 将父文档内部的子块向量也预先计算并存储，通过元数据parent_id关联，这样二次检索就是高效的向量查询，而非全文扫描。
  • 设置缓存，对相同或相似的查询直接返回扩展后的上下文。
• 元数据管理：妥善管理parent_id、source、header等元数据。它们不仅是父子关联的纽带，在后续的引用溯源、相关性过滤（如“只检索某章节”）中也至关重要。
• 评估与迭代：建立评估基准。准备一组标准问题，记录使用不同分块策略和参数下的答案准确率（Hit Rate）、答案相关性（Relevance）等指标。没有放之四海而皆准的最佳参数，只有最适合你文档和业务场景的参数。

5. 避坑指南与常见问题排查

在实际部署中，我踩过不少坑，这里总结几个最典型的：

问题一：检索结果似乎没有用到父文档，返回的还是碎片。

• 检查点1：确认你的自定义检索器_get_relevant_documents方法返回的是parent_map中的父文档对象，而不是child_docs。
• 检查点2：打印检索器的返回结果，查看page_content的长度和内容，确认它是否是一个完整的章节。
• 检查点3：检查向量库检索时，子块的元数据是否正确写入了parent_id。

问题二：上下文扩展后，LLM的答案反而变差了，包含无关信息。

• 原因：扩展窗口expansion_k设置过大，引入了噪声。
• 解决：减小expansion_k，或采用更智能的扩展策略。例如，不是固定扩展前后N块，而是扩展到同一个二级标题（###）下为止。或者，计算扩展块与核心块的语义相似度，只纳入相似度高于阈值的块。

问题三：处理超长文档时，父文档本身仍然太长，超出LLM上下文窗口。

• 策略：实施“递归式Parent-Child”。即定义多级父块：全书（一级）-> 章节（二级）-> 小节（三级）。检索时，先定位到章节，如果章节还是太长，再在章节内进行二次Parent-Child或Contextual Retrieval。这需要更复杂的元数据设计来维护层级关系。

问题四：如何应对表格、代码等特殊格式内容？

• 表格：传统的按字符分割会破坏表格结构。建议使用专门的分割器（如MarkdownTextSplitter尝试保持表格的Markdown格式），或将表格提取为结构化数据（如CSV），单独处理。在分块时，尽量将整个表格作为一个不可分割的“子块”。
• 代码：同理，一个完整的函数/类定义应作为一个整体。可以按代码块（```）分割，或使用RecursiveCharacterTextSplitter并将separators中的“\n\n“优先级提高，并设置chunk_size稍大以容纳常见函数。

问题五：向量数据库的相似度搜索，对于非常细粒度的子块效果不佳。

• 分析：当子块非常小（如一两句话）时，其嵌入向量可能无法充分表征语义，导致相似度匹配不稳定。
• 解决：
  1. 考虑使用专门为短文本优化的嵌入模型。
  2. 适当增大子块大小，但配合更大的重叠度来保证边界召回。
  3. 采用混合检索（Hybrid Search），结合基于关键词的稀疏检索（如BM25）和向量检索，利用前者在精确关键词匹配上的优势。

高级分块策略的引入，标志着RAG系统从“能用”向“好用”演进。它要求开发者更深入地理解自己的数据特性和用户查询模式。没有银弹，持续的测试、评估和迭代才是构建健壮RAG系统的唯一路径。当你看到LLM开始引用完整、连贯的文档段落来回答问题，而不是支离破碎的片段时，你就会觉得这些复杂的设置都是值得的。