RAG分块应从检索数据结构开始设计

RAG 检索效果不好，先换 embedding 模型，再加 re-ranker，最后反复调整 top_k 和分块重叠比例。这套排查路径很常见，但原文提醒：如果答案需要的上下文早已被切散，后面的模型再强，也可能只是在不完整的材料里选出最像答案的一段。

作者的建议是，把分块当成索引的数据结构设计：用小片段定位信息，再按文档结构补齐生成所需的上下文。同时，评测要专门检查跨分块的信息是否完整送达模型。这条思路值得借鉴，但「切开就永久丢失」的判断需要加上前提。

为什么相关片段排第一，回答还是不完整

作者举了一个合同场景：第 3 段定义术语，第 9 段使用术语，分块器却在第 5 段切开。两个片段各自都能被检索，但任何一个单独拿出来，都不足以解释完整含义。

问题在于，文本相关性和回答完整性是两件事。一个片段可能精准命中用户的问题，却缺少定义、限制条件或例外。模型拿着它生成回答，往往不会报错，只会给出一个有出处、听起来合理，却漏掉关键条件的答案。

普通 cross-encoder re-ranker 的工作，是把查询与一个候选片段一起输入，计算相关性分数。按原文讨论的用法，它看不到相邻片段，也不知道当前内容只是完整论述的一半。

重排能调整候选顺序，不能凭空补回候选之外的上下文。

如果答案散落在 2 到 3 个分块中，单独给每块打分，并不会自动把它们组装起来。因此，换重排模型可能有一点改善，随后又遇到瓶颈。

原文把这个瓶颈归因于索引设计，但没有提供实验数据。更准确的理解是：当缺失内容没有进入候选或后续上下文时，继续优化排序解决不了材料不全的问题。

检索用的小块，为什么不必直接交给模型

检索和生成对文本粒度的要求不同。

检索希望片段主题集中，便于与查询匹配。作者用一个 50-token 的片段说明：它只表达一项具体主张，向量表示就不容易被旁边另外三项无关主张稀释。这里的 50-token 是示例，不是推荐的统一分块大小。

生成需要更完整的材料。用户问一个术语如何适用，模型可能既要看到具体条款，也要看到术语定义。只送入命中的短段落，信息就可能不够。

作者给出的原则是「按最小有用单元建索引，按上下文需要扩展」。可以先检索一句话、一个列表项或一个短段落，再补入它附近的窗口、所属章节，或者关联的定义。

这对应几种已有做法：parent-document retrieval（父文档检索）、windowed expansion（窗口扩展）和 hierarchical indexing（分层索引）。它们的共同点是，把「负责定位的文本」和「交给模型阅读的文本」分开。

要实现这一步，索引就不能只有向量和文本。每个分块还需要记录它来自哪份文档、位于哪里、相邻片段是谁、属于哪个父章节。否则，系统虽然找到了一段话，却不知道该去哪里补齐材料。

这也是标题里 schema 的含义：分块策略会影响索引保存哪些关系，以及后续还能执行哪些操作，不能只当成一个 N tokens 的切割参数。

评测要检查模型是否拿到了完整论述

只检查「有没有召回相关片段」，容易漏掉这类问题。

假设问题必须同时依赖定义和应用场景。系统找到了应用场景，相关性分数很高，但定义没有进入提示词。如果评测只认定「命中相关内容」，检索看起来已经成功，生成却仍然缺材料。

作者建议，直接围绕实际分块边界设计题目：选出已知信息横跨两个相邻分块的文档，让问题必须结合两块才能回答。随后检查生成阶段收到的材料，是否包含完整论述。

这和 recall（召回率）、faithfulness（忠实度）的侧重点不同。召回率取决于如何标注相关材料；忠实度主要检查回答是否有依据。即使回答忠实于某个局部片段，也可能遗漏决定结论的条件。

因此，评测最好保留中间过程：最初命中了哪些块，扩展后加入了什么，最终送给模型的又是什么。这样才能分清，缺失发生在检索、上下文扩展，还是模型作答阶段。

不过，原文没有给出完整度指标的公式、标注规范和通过阈值。它提出了一个值得补测的方向，还不是一套可以直接照搬的评测方案。

我的判断

我赞同作者把注意力拉回索引结构。相比连续更换 embedding 和 re-ranker，先确认模型有没有拿到回答所需的材料，通常更有诊断价值。

但「切开之后信息永久、不可逆地消失」说得太满。只要原文、位置和关联关系仍然保留，系统就有机会重新组装上下文；两个分块也可能同时被召回并进入提示词。真正危险的是：切开以后没有保存恢复关系，或者后续流程始终按孤立片段处理。

小块也不是天然更好。切得太细，代词可能失去指向，标题和正文可能分离，扩展后又可能引入大量重复内容。父章节过大，同样会增加上下文开销。原文没有提供不同粒度、重叠比例和扩展范围的对照结果，不能据此确定最佳参数。

同样，标准评测并非一定抓不到跨块问题。只要题目确实需要多段证据，并且检查遗漏条件，也能覆盖这种失败。作者真正指出的缺口，是很多评测没有主动针对实际切割位置设计样本。

这篇更适合作为排查框架，不能当作已经验证的性能结论。

能拿来做什么

• 排查知识库问答时，挑一个「回答有出处但条件不全」的案例，同时查看原文、分块结果和最终提示词，确认缺失内容在哪一步掉了，再决定是否调整 top_k 或重排。
• 在 Node 编写的入库流程中，为分块保留来源文档、原文位置、父章节和相邻关系，让检索结果能够按需扩展，而不只是返回一段孤立文本。
• 给开发文档问答增加跨块测试，例如定义与用法、规则与例外分别落在不同块的题目，检查模型最终是否同时收到两部分材料。
• 比较固定重叠、邻近窗口和父章节扩展时，把答案完整度、送入模型的文本量及重复内容一起记录，依据自己的文档结构选择方案。