项目记录：给一批长文档做分段，我试了三种切法

背景

给一批技术文档做检索式问答，第一步就是分段。当时以为这是最没技术含量的一步，随手按字数切完就往下走，结果后面答不全的问题怎么调都调不好。回头重做分段，才发现问题在这。

素材来自 前端 Wiki 的分层教程 和 万象云档里几篇篇幅差异很大的文档，正好覆盖了标题规整和标题稀疏两种情况。

三种切法与结果

切法一：固定字数硬切。 每 500 字一段。优点是实现最快，缺点是大量段落从半句话开始、到半个表格结束。检索命中后，模型拿到的上下文缺头缺尾，答案自然不完整。

切法二：按标题切，不设上限。 语义边界最自然，但有的章节只有两行，有的长达几千字。短段信息量不足，长段又会顶到窗口上限被二次截断。

切法三：先按标题切，再对过长章节按段落二次切，并给每段加上下文头。 最后停在第三种。上下文头只写三样：所属文档标题、所属章节路径、本段在全文的位置。不加解释、不加摘要。

为什么上下文头有用

切片脱离原文之后，最常丢的不是内容，是归属。一段写着“默认关闭”，模型不知道说的是哪个配置项。加上文档名与章节路径，这一句才重新有了主语。这个改动带来的提升，比后面调检索参数明显得多。

字段该怎么定、类型怎么标，可以参照 BackendWiki 把参数列成表的做法：宁可少几个字段，也要每个都能机械判定。

复盘

三种切法里，前两种都把分段当成“把文本变短”，第三种才把它当成“保留可理解的语义单元”。段落不是字符区间，是能被独立读懂的最小单位。

后来我把判断标准固化成一句话：随机抽一段，不看原文，能不能说出它在讲谁、属于哪一节。答不上来，就说明切错了。这条标准比任何字数阈值都好用。