选择 RAG 分块边界和重叠以保留节上下文

选择保留答案的单元

分块的主要目标是确保每个块包含足够的上下文来独立回答潜在的查询。正如 Microsoft RAG 指南中所述，块太小且上下文不足会导致结果不佳。在我们假设的支持说明中 - - “退货：未开封的商品可在 14 天内退货。保修：制造缺陷保修期为 12 个月。” - - 关于退货资格的查询取决于条件（未开封）和时间限制（14 天）。如果块边界分割了“内”和“14 天”，检索可能会错过完整的条件。

选择能同时保留相关条件及其期限的文本单元，并遵守嵌入模型实际的输入限制。文档结构和 token 数量都很重要：较长的章节仍可能需要继续拆分。完整的简短规则是合理的起点，但不能保证检索系统一定会找到它。

将标题与其段落一起保留

节标题为解释内容提供了基本上下文。当像“未开封的商品可在 14 天内退货”这样的段落出现在没有“退货”标题的情况下时，其含义变得模糊。Microsoft RAG 文档强调保留语义相关内容，这包括将标题与其各自的文本块相关联。

将章节标题与对应段落关联。仅把标题存为元数据，并不意味着它会进入嵌入向量或被展示给语言模型。如果标题提供必要的上下文，应将其包含在用于生成嵌入的文本中，并传入答案生成器使用的检索上下文。下面的字典只是存储文本块的示例，并不是完整的 Azure 索引配置。

chunk = {
  "text": "Returns: unopened items may be returned within 14 days.",
  "metadata": {"section": "Returns"}
}

比较两个说明性边界

考虑对支持说明的两种说明性分段。首先，假设一个基于字符的边界将注释切断在一个单词中间：

块 1：“退货：未开封的商品可在内” 块 2：“14 天。保修：制造缺陷” 块 3：“保修期为 12 个月。”

在这里，退货政策被分割在块之间，存在检索不完整的风险。现在比较一种使用“保修：”作为边界的文档感知方法：

块 A：“退货：未开封的商品可在 14 天内退货。” 块 B：“保修：制造缺陷保修期为 12 个月。”

此版本完整地保留了两个策略。第一个方法仅依赖于大小，而第二个方法则尊重语义结构 - - 这是 Azure 关于可变大小和语义分块的指南中强调的一个关键优势。

选择初始大小和重叠

Azure AI Search 建议在使用固定大小分块时，从 512 个 token（约 2000 个字符）和 25% 的重叠（128 个 token）开始。这在上下文连续性和冗余之间取得了平衡。重叠允许跨块分割的短语至少在一个结果中完整出现。

对于我们的示例，将块大小设置为 60 个字符，重叠 15 个字符，可能有助于弥合“内”和“14 天”之间的差距。然而，如果逻辑单元跨越一个以上的块，重叠本身无法保证意图的保留。因此，虽然重叠提高了鲁棒性，但它不能替代结构感知。

考虑重复的上下文

重叠会引入重复的文本，增加存储和索引成本。正如 Microsoft RAG 文章中所指出的，一些方法会产生更高的财务和时间成本。在多个块中重复节标题也会增加冗余，但可以提高可解释性。

在我们的案例中，在每个块的开头重复“退货：”以确保清晰度，即使它会增加 token 使用量。当正确回答用户问题取决于上下文时，权衡有利于准确性而非效率。

检查边界附近的答案

分块后，测试针对可能分割点的附近信息设计的查询。例如，询问“未开封的商品可以退货多久？”并验证检索到的块是否同时包含主题和时间范围。

由于这是一个假设的示例，因此没有实际测试检索系统。但在实际实现中，检查结构转换周围的结果 - - 例如标题后或句子中间分割处 - - 对于验证块质量至关重要，正如 RAG 分块阶段文档中所建议的那样。

一次更改一个参数

优化分块时，每次迭代只更改一个变量 - - 大小、重叠或解析方法 - - 以隔离其影响。例如，首先测试 500 与 1000 个字符的固定大小块，然后将重叠从 10% 调整到 25%，同时保持其他设置不变。

这种系统化的方法支持可靠的评估，与 Microsoft 建议在最终确定策略之前尝试各种分块排列并观察权衡的建议一致。

了解分块检查无法证明什么

可视化块或检查重叠并不能保证检索的有效性。语义边界并不自动意味着相关性，没有任何静态分析可以证明给定查询会检索某个块。正如 Microsoft 指南所指出的，您的分块方法是半永久性的，会影响下游流程，因此必须通过经验来验证假设。

将退货与其政策一起保留可以使段落更易于理解，但实际的检索器仍然必须选择它，并且答案必须正确使用它。检查检索到的证据并跨代表性查询审查生成的答案。在一个查询上获得良好结果并不能建立可靠性；比较几个边界情况，包括答案在文档中缺失的问题。