RAG 检索需要在切片之间保留完整逻辑

RAG 文档检索即使命中了相关片段，也不代表模型已经获得完整依据。固定 Chunk Size 容易把前提、条件与结论切到不同片段，LLM 只能自行补齐中断的逻辑，于是回答可能偏离原文。

围绕 DeepSeek-V3、Claude 3.5 Sonnet 和 GPT-4o 的对比验证显示，切片策略需要结合模型特点与文档结构选择，单纯调整长度并不能解决所有上下文断裂问题。

重叠切片只能修补片段边界

重叠切片 (Overlapping) 通过让相邻块保留 200-500 字的重叠窗口，减轻因切分位置造成的上下文截断。在 GPT-4o 的对比中，这种策略效果最好，模型能够利用重复内容重新衔接断裂的逻辑。

它的局限也很明确。Claude 3.5 面对极长上下文时，过量重复内容会干扰检索，降低命中率；跨段落之间的逻辑依赖也无法靠重叠从根本上恢复，同时还会造成严重的 Token 浪费。当片段只是缺少相邻边界信息时，重叠切片可以用于缓解；若问题来自跨段落关系，继续依赖重叠并不可靠。

语义切片更适合保持技术内容完整

语义切片 (Semantic Chunking) 先由 Embedding 模型计算句子间的余弦相似度，再在相似度明显下降的位置划分边界。技术文档场景能够从这种切法中获得更完整的结果，API 定义、逻辑步骤也更可能被保留在同一个 Chunk 中。

采用 DeepSeek 的 Embedding 模型进行切分时，DeepSeek-V3 在推理阶段能够较快锁定关键信息，不必像 GPT-4o 那样翻找大量冗余文本。采用这条路径时，应让切分位置跟随语义变化，而不是重新套用固定 Chunk Size，否则前提与结论仍可能再次分离。就检索精度和上下文完整度而言，语义切片在技术文档中更有优势。

父子索引兼顾检索精度与上下文

父子索引 (Parent-Document Retrieval) 将检索与推理分配给不同粒度的片段：检索阶段使用较小的 小型子片段 (Child Chunk) 定位内容，送入 LLM 时再取回它所属的 大型父片段 (Parent Chunk)。这种安排可以避免片段过小导致背景缺失，也能防止片段过大造成检索不准。

在父子索引模式下，Claude 3.5 Sonnet 的表现最为突出，能够从 2k 字的父段落 中提取与查询有关的细微联系，并减少无关信息对判断的干扰。GPT-4o 虽然鲁棒性较强，但处理大块上下文时偶尔会出现“中间丢失”，进而影响回答准确性。

在 LangChain 中，可以通过 ParentDocumentRetriever 和 InMemoryStore 建立子片段与父片段之间的联系，核心参考伪代码为：

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

retriever = ParentDocumentRetriever(
    vectorstore=vectorstore,
    docstore=InMemoryStore(),
    child_splitter=RecursiveCharacterTextSplitter(chunk_size=400),
    parent_splitter=RecursiveCharacterTextSplitter(chunk_size=2000)
)

真正落地时，应让 Child Chunk 负责精准命中，再由 Parent Chunk 为 LLM 补回完整背景。若直接用大型父片段承担检索，或只把小型子片段交给 LLM，父子索引原本兼顾检索与上下文的作用便无法发挥。技术文档若侧重保存完整逻辑，可以采用语义切片；既要求检索精准，又要求推理时保留充足上下文时，父子索引是更稳妥的工程化路径。重叠切片适合缓解相邻块之间的截断，却不能替代对跨段落逻辑断裂的处理。