清洗不是分段垃圾不清，分段也白切

客户说「资料都在，你们做成知识库就行」，然后发来一个压缩包：337 份手册，PDF、CHM、XLSX、HTML 混在一起，有的还是扫描版，图表占了半本书，全部加起来 4277 页。

第一次做这种事的人最常见的想法是：文档都有了，直接传进平台建库不就行了？我们把这几千页完整走了一遍，结论很明确：直接灌库，检索质量大概率不及格。更麻烦的是，问题出在你看不见的地方——脏数据进库不像报错那样弹出来，它是静默劣化。我们实测遇到过三类：结构瑕疵切出空段（命中标题空壳段，模型只能答「未找到」，内容明明在库里）；噪声抢占候选名额（目录页、导航页、重复版权行挤进候选，把精准段落顶出去）；最危险的是内容错误命中却答错（转换丢行、错字、表格列错位，检索看着正常，答出来是错的，统计对账还抓不住）。而且修错的成本随时间指数上升：清洗阶段发现，改一份 markdown 是分钟级；建库后才发现，重建库是小时级，还带着向量库被污染的风险。

核心认知只有一句：清洗不是分段。分段是平台入库时的能力，解决「内容怎么切」；清洗是入库之前的内容治理，解决「内容里有什么垃圾」。垃圾不清就分段，等于把垃圾切碎，均匀地灌满整个知识库，分段规则再好也救不回来。

我们沉淀出的管线有七段：盘点备份 → 素材预检 → 格式转换 → 去噪去重 → 脱敏 → 分段适配 → 质量门禁，每一段都带实测数据与踩过的坑。盘点备份决定后面所有验证能不能做（清洗不可逆，源文件必须留着做对照）；预检要先体检再开工（有一次 604 张图里 84% 是噪声，没体检就转换，白跑两轮）；转换按格式分三条路线，不自己写解析器；去噪不能按行长一刀切，会误伤命令和设备型号；脱敏要正则加词表双保险，还要小心别把公开规定的金额也掩掉；分段适配要治连续标题行造成的空段（旧库 1703 段净化到 623 段）；最后一道门禁决定语料能不能进库，健康度 ≥80 分才放行。

门禁有三个反直觉之处：评分高不代表好（我们遇到过 99 分但表格列错位的）；验证要做四层，从格式一直到建库后的检索体检；最有用的武器是污染注入回归——往干净语料里注入已知垃圾，看清除率和误伤率，实测乱码清除 94%、其余 100%、误伤 0，每次规则变更后必须重跑，它防的是「修好一个坑又引入一个新坑」。

实测口径：337 份手册 × 3 库全量清洗空段率 0.01%；段落池 1703 → 623 段；扫描件 OCR 223 页、低置信 0 页；污染注入回归清除率 94% 以上、误伤 0。完整判定表、四项评分细则与复现材料见下方两篇原文。