分段切断代码块24.3% 是碎的

这是一次真实排查的完整复盘。一套上线运行的知识问答应用做体检时，故障手册知识库里 1401 个分段中有 341 个是代码碎块，占 24.3%（碎块的判定口径：一个分段里代码围栏出现奇数次，说明代码块被从中间切开了）。而它上线前专门做过一轮清洗。

从碎块形态倒推三条线：源文档围栏密度极高（MPLS 章节 7.6 万字符里有 1502 个围栏行，平均每块一到两行命令）；清洗只做了一半（把 1502 个围栏合并成 156 个，但 817 个代码块里有 113 个超过 800 字符，最长的超过两万两千字符）；目标库 max_tokens 只有 800——长代码块远超上限，被分段器第二级「按长度硬切」，切点正好落在围栏上。

修复用结构感知切分（代码块整体优先、超长块在语义边界切开并补完整围栏、普通文本也控长），碎块率从 30.0% 降到 5.3%。对照实验里有一个反直觉的发现：把 max_tokens 从 500 一路调到 2000，碎块率几乎没降（29.1% → 25.3%）——问题不是上限太小，是切点不受控。剩下的 5% 追下去，是 PDF 转 Markdown 时围栏和正文被合并到同一行（154 处、涉及 22/25 个文档），这部分只能回源文档层解决。

收尾给出三条可直接照用的判据，核心一句：清洗的输出尺寸，必须由目标库的分段配置决定，而不是由源文档的格式决定。

完整文字版见下方文章。