RAG 文档切片如何保留标题层级：从章节路径到检索上下文

把产品手册接入 RAG 后，回答“这个字段在哪一章定义”时，很多系统只能找回一段孤零零的正文。更稳妥的做法是：每次切片都带上从文档标题一路走到当前小节的章节路径，再把这条路径和正文一起送入检索索引。

切片不是把文字任意截短，而是要让每个可检索片段独立说明“它属于哪一章、解决什么问题”。章节路径保留下来，召回结果才不会只剩半句话。

为什么普通切片会丢掉真正的问题

按固定字符数切分很省事，却会把标题和解释拆开。比如“密码最少长度”出现在多个章节，片段只剩“最少长度为 12 位”，检索器很难判断它属于账号设置、接口鉴权还是管理员策略。

这类错不是模型知识不足，而是输入证据缺少位置。对知识库来说，章节路径相当于一枚轻量的语义坐标：它不改变原文，却告诉后续环节这句话从哪里来。

先把标题层级变成章节路径

解析文档时维护一条当前路径即可。遇到一级标题就替换第一段，遇到二级标题就替换第二段；正文段落到来时，复制当前路径并与段落绑定。没有标题的前言可以使用“文档前言”作为固定根节点，避免出现空路径。

本篇示例的最小路径是“产品手册 / 账号设置 / 密码策略”。它应该和正文一起进入片段，而不是只留在导入日志里。这样一来，片段脱离原文预览时仍然有可读的上下文。

切片时保留上下文，检索时再控制长度

路径并不需要复制整篇文档。建议把路径作为短前缀，后面接正文和必要的相邻句子；正文仍按语义段落切开，表格、列表和说明文字尽量不要从中间断开。

召回时可以同时展示路径、片段标题和正文。回答器先确认多个片段是否属于同一章节，再决定是合并说明，还是明确指出“账号设置”和“管理员策略”是两个不同边界。这里的重点是给模型一个可核对的归属，而不是盲目增加片段长度。

和只保存正文的方案相比，差异在哪里

只保存正文的方案在短 FAQ 上通常够用，导入速度也更容易估算；但遇到同名字段、跨章节引用和版本附录时，召回结果会变得难以解释。保留章节路径会增加少量索引文本，却换来更清楚的证据边界。

两者可以并存：正文用于语义相似度，章节路径用于过滤、排序和回答时的引用展示。不要把路径写成一大段重复目录，否则索引噪声会抵消它的好处。

落地前要检查的三个边界

标题缺失或层级跳跃

现实文档里经常出现从一级标题直接跳到三级标题的情况。导入器应保留实际标题文本，并为缺失的中间层留空或使用已知上级，不要凭空补一个不存在的章节。

表格和列表被拆散

如果问题答案依赖表头，切片必须把表头和对应行放在一起。列表同理，至少要保留列表的主题句，否则召回后只看到几个无主语的条目。

跨章节引用

当正文写着“详见上一节”时，单个片段本身不完整。可以保留当前路径，同时追加一小段相邻上下文；如果仍无法独立解释，就在回答中提示需要继续检索，而不是把猜测当成结论。

常见问题：章节路径应该参与向量化吗

可以参与，但不必让路径占据片段的大部分内容。较短的路径能帮助主题定位；如果目录层级很深，建议把完整路径保存在元数据，同时只把最近两级标题拼到检索文本中，再按场景验证召回质量。

切片越小，检索一定越准吗

不一定。切片过小会失去定义、条件和例外，路径只能补充归属，不能替代缺失的语义。应以一个问题所需的最小完整证据为边界。

要不要把整棵目录放进每个片段

通常不要。整棵目录会制造重复词，增加索引噪声；保留当前章节路径和必要的上级标题，往往更容易解释，也更省存储。

总结

RAG 文档切片的关键不是追求一个固定字符数，而是让片段离开原文后仍然知道自己的位置。先保存“产品手册 / 账号设置 / 密码策略”这样的章节路径，再围绕完整语义切分，最后在检索和回答阶段利用这条路径做归并与核对，知识库的结果会更容易复查，也更少出现跨章节混淆。