围绕证据与答案所需内容对文档进行分块处理

试想一下，当需要确定何时回滚服务时去查阅部署手册。搜索会返回回滚指令，但问题出在接下来的内容中：该指令仅在实际的健康检查失败后才适用。虽然找到的文本相关，但答案仍可能是错误的。

这就是核心的分块问题——易于建立索引的单元与足以解释某事的单元往往并不一致。

在调整嵌入模型之前，先查看这些分块让模型看到了什么。

从你现有的结构入手

对于技术文章而言，标题及其段落是个合理的起点。代码示例应与其假设说明一同呈现；表格则需要足够的标签来解释数值；而异常情况则应放在它所修改的规则附近。

这取决于能否找回可信赖的源文本。如果解析器已经将表格转换为含义模糊的序列，那么更小的片段只会加剧这种模糊性。

一个实用的第一步是在章节边界处进行分割，将相邻段落打包在大小限制范围内，并在句子边界处拆分过大的章节。当代码块和表格超出大小限制时需要特殊处理：保留其结构并重复标注，以便解读各部分内容。

这只是初步设计，并非普遍最优方案。词汇表和事件报告对信息的组织方式有所不同。

出于特定原因使用重叠处理

重叠机制可以保留那些否则会跨越边界而丢失的句子，但同时也会导致文本重复。如果重叠程度过高，多个顶级结果可能会包含几乎完全相同的段落，这样既消耗了上下文资源，又没有增添新的有效信息。

除了评估单个片段的相关性外，还需衡量其实际覆盖范围。如果检索到的五个片段都在解释回滚触发条件，却没有任何一个包含异常情况，那么继续检索更多相同文本也无法解决问题。

在完成检索后，需找出来自同一来源的重复段落，并在构建提示语之前将其合并或去重。同时要保留这些段落的来源位置，以便后续能够追溯引用出处。

精准检索，有针对性地扩展

短段落是良好的搜索目标，因为它聚焦于一个主题。而周围的章节则能提供更好的生成上下文，因为其中包含定义与相关说明。

一种设计方法是为每个小片段指定一个父章节标识符。先搜索这些较小的单元，当答案需要更多上下文时再将选中的结果展开到其父章节中。不过这种扩展仍需控制成本；若每次搜索都加载整份文档，只会将原有问题推迟解决。

对于部署手册而言，搜索结果可指出回滚条件，此时父章节便可提供异常情况及恢复步骤。这样就能得到连贯的解释，而无需让检索系统去处理庞大的文档片段。

比较具有相同问题的配置

设计能够揭示边界条件的题目：定义类问题、段落间对比题、表格查询题，以及包含例外情况的规则题。同时标明每个答案所需的证据。

将简单的固定长度基准版本与具备结构感知能力的版本进行比较。保持语料库、题目数量以及最终上下文长度不变，检查每种配置是否能获取足够的证据、会产生多少重复内容，以及根据现有上下文还有哪些答案无法得出。

在设定实际应用时的资源限制时，不要将单词与模型令牌混为一谈。原型开发时可使用字数分割工具，但最终的提示语必须符合处理它的模型的分词器规则及容量限制。

一旦证据单元完备，混合检索便能帮助用户通过精确术语和普通语言找到它们。当返回的段落本身就值得阅读时，更好的检索功能才能发挥最大作用。