RAG 文档切块按标题层级保留语义边界

RAG 召回结果总是“答到章节附近，却没有答到问题”，很多时候不是向量模型先出了问题，而是切块时把标题、限定条件和正文拆散了。更稳妥的做法是把标题层级当作语义边界：先保留完整的标题路径，再对过长章节按段落、句子和 token 上限递归细分。这样每个 chunk 既能独立检索，又能沿着父级章节恢复上下文。

先把标题路径变成 chunk 的安全边界

一个“退款接口”段落如果脱离“支付服务 > 退款 > 幂等规则”，嵌入后仍可能命中“退款”，但生成模型看不到适用范围。解析阶段应给每个结构单元保留 heading_path，并把路径作为前缀或独立元数据写入 chunk。

建议把文档先变成下面这样的内部对象：正文负责向量化，路径负责过滤、解释和回填。

sections = [
    {
        "section_id": "pay.refund.idempotency",
        "heading_path": ["支付服务", "退款", "幂等规则"],
        "text": "同一业务单号只能成功退款一次……",
        "source_span": {"start": 1840, "end": 2028}
    }
]

图中所示的层级关系是静态结构说明，不代表某个真实产品的运行截图。

超长章节采用由粗到细的递归切分

标题边界解决的是“不要跨主题”，并不能保证一个章节足够短。切分器可以按标题、空行、段落、句子和字符的顺序逐级降级：当前层级已经低于上限就停止，仍然过长才进入下一层。表格和代码块应视为不可随意打散的结构，必要时先单独抽取，再为它们补上同一条标题路径。

下面的示例只演示切分决策，实际项目应把 token_len 替换成目标嵌入模型 tokenizer 的真实计数：

def split_section(section, max_tokens=420):
    # 先保留完整章节；只有超出嵌入上限才继续拆分
    if section["token_len"]  max_tokens:
            chunks.append(make_chunk(section, "\n".join(current)))
            current = [piece]
        else:
            current.append(piece)
    if current:
        chunks.append(make_chunk(section, "\n".join(current)))
    return chunks

上限不能照搬某个示例数字。嵌入模型的最大序列长度、语言分词方式和召回窗口都不同，通常要先统计长度分布，再给表格、列表和代码保留足够余量。

元数据、重叠和召回聚合要一起设计

每个片段至少保存 document_id、section_id、heading_path、chunk_index、token_len 与源位置。source_span 能帮助引用回原文，chunk_index 能让相邻片段按顺序拼接。重叠只用于跨句边界的短暂连接，不要用很大的 overlap 掩盖错误的标题切分。

用离线问题集检查语义边界是否真的保留

不要只看向量相似度。准备一组带章节答案的问题，分别检查：命中的 chunk 是否包含限定条件；同一问题的相邻片段是否能恢复顺序；标题相同但产品不同的段落是否能靠 document_id 区分；长表格是否出现半行。把“命中正确章节”和“答案引用完整”分开记录，才知道是召回排序问题，还是切块阶段已经丢了信息。

一个实用的验收清单是：先看标题路径，再看 token 长度，再看源位置连续性，最后观察聚合后是否超过生成模型上下文。任何一项失败，都优先修切块规则，而不是盲目增大 top-k。

常见问题

标题路径应该放进正文还是只放 metadata？

建议双写。正文前缀帮助嵌入理解主题，metadata 方便过滤、引用和召回后聚合。

每个标题都必须单独成为一个 chunk 吗？

不必。短标题应与其正文合并；只有当章节跨过长度上限，或需要独立权限、引用和过滤时，才拆成多个子块。

chunk overlap 越大越好吗？

不是。overlap 只补跨句边界，过大会制造重复向量并占用上下文。先保证标题和段落边界正确，再用离线问题集调小范围参数。

切块的目标不是制造数量相等的小段，而是让一个检索片段能回答一个明确问题，并且能沿着标题路径回到原文。标题优先、长度受控、元数据完整，再配合章节级聚合，通常比单纯调整固定字符数更容易稳定。