← 返回文章列表

知识库数据清洗后,怎么知道洗得干不干净?一套三层质量门禁实测

基于 doc-cleaner v1.9.0 实测(2026-08-28)。

📖 摘要:文档清洗完就能建库?不行——「看着干净」和「真的干净」是两回事。本文拆解我们清洗管线的质量门禁:四项 25 分制健康度评分 + 四层验证(格式/内容/结构/下游)+ 污染注入回归,用实测数据说明「评分 99 分为什么还会翻车」「清除率 94% 误伤 0 是怎么测出来的」,以及 H3C 337 份手册空段率 0.01% 背后的门禁逻辑。

导读

一、业务场景:清洗完,然后呢?

客户丢来 337 份 H3C 手册(PDF/CHM/XLSX/HTML 混杂),我们有一套清洗管线:转换 → 去噪 → 去重 → 脱敏 → 分节。管线跑完,输出一堆 .cleaned.md——这时候问题来了:

这批文档能建库了吗?

外行会说「看着挺干净」。但我们交付的不是给人看的文档,是给向量检索吃的语料——「看着干净」的文档,可能藏着三类杀手:格式残破(空段、碎表格)、内容丢失(图表截断、行错位)、敏感残留(手机号、身份证)。它们不会让页面变难看,但会让检索静默劣化、甚至泄露隐私。

于是我们建了一套质量门禁:清洗后的文档,过不了门禁就不许进库。

二、场景痛点:三个认知误区

做门禁之前,我们反复踩过三个坑:

  1. 评分高 ≠ 洗得好。有一次清洗输出健康度评分 99 分(近乎满分),结果人工抽检发现表格列错位——6 列压成 4 列,数据全错位了。评分只测「格式规不规范」,测不出「内容对不对」。
  2. 清洗是一次性的。后来我们改了清洗规则(比如新增手机号脱敏正则),旧的清洗结果没重跑——新规则根本没生效,一批库带着未脱敏的手机号进了生产。
  3. 清洗只影响格式。以为清洗是「美观工程」,实际上清洗质量直接传导到检索——脏段抢占候选名额、空段稀释分数,最终回答质量全看清洗这层地基。

门禁不是「加一道检查」,是把这三个误区变成三道闸。

三、解决方案:三层质量门禁

graph TD A["清洗后的文档"] --> B["第一道闸:健康度评分"] B --> C{"≥ 80 分?"} C -- "是" --> D["第二道闸:四层验证"] C -- "60-79 分" --> E["人工确认后放行"] C -- "< 60 分" --> F["阻断,回到清洗"] D --> G{"四层全过?"} G -- "是" --> H["第三道闸:污染注入回归"] G -- "否" --> F H --> I{"清除率 ≥ 90% 且误伤 0?"} I -- "是" --> J["建库"] I -- "否" --> F

三道闸各管一件事:

管什么 工具
评分闸 格式层:结构是否可解析、有没有异常膨胀/重复/脱敏残留 自动评分(四项 25 分制 + 守恒双指标)
验证闸 内容层 + 结构层:该留的没丢、图文完整 指纹抽检 + 自包含检查 + 人工抽检
回归闸 规则变更后:清洗规则改了,效果是否保持 污染注入回归

四、模块设计:每道闸怎么落地

4.1 评分闸:四项 25 分制 + 守恒双指标

健康度评分 0-100,四项各 25 分:

维度 满分 测什么 扣分条件
完整性 25 内容没被洗没 字符数异常膨胀/坍缩(<30% 或 >150%)
格式合规 25 Markdown 结构有效、表格完整 表格空/NaN 单元格密度 >30% 扣 10 分
重复率 25 没把内容洗重 重复段落占比 ≥5%
脱敏覆盖率 25 敏感字段处理干净 高置信敏感字段有残留

光靠四项还不够——v1.9.0 加了守恒双指标:字符守恒(30%-150% 阈值)+ 行数守恒(去重行占比 >50% 告警、清洗后行数 <30% 告警)。为什么?之前的教训:单看字符比率太宽,轻微错位检测不到——行数守恒能抓住「整块内容被误删」这类结构性损伤。

评分只是第一道闸,它回答「格式规不规范」,不回答「内容对不对」

4.2 验证闸:四层验证 L0-L3

评分闸之后是内容验证,四层递进:

验证什么 方法 阈值
L0 格式层 语法/结构可解析 自动评分 + 表格结构检测 + 守恒双指标 ≥80 分
L1 内容层 该留的没丢 指纹抽检(源 vs 清洗后子串匹配) ≥80% 匹配
L2 结构层 章节/图文完整 自包含检查 + 图引用完整性 + 人工抽检(每批 10-20 图 + 5-10 表) 抽检无截断
L3 下游层 建库后好不好用 RAG 体检(检索召回质量) 库内问题 top-3 命中

L1 指纹抽检是我们最常用的内容层手段:把源文档和清洗后文档做子串匹配,看该留的内容留下多少——阈值 80%,低于说明清洗「洗过头」了。

L2 图表防截断是 H3C 项目的专项:PDF 渲染区域提取图时,边界判定不准会把「OSPF 邻居 Down 诊断流程图」只提取 1/4 高度。我们做了三层检测:同系列图高宽比分布对比(偏离中位数 50% = 截断嫌疑)、非白像素占比验证(内容行 <5% = 空白错误区域)、表格行数对比(md vs 源缺行 = 截断)。

4.3 回归闸:污染注入回归

清洗规则改一次,就得证明「改完还是干净的」——这就是污染注入回归:

污染注入(乱码/重复/噪声/手机号/邮箱)

    → 跑清洗管线

    → 计算清除率%(被清除的污染 / 注入的污染)

    → 计算误伤率(原文指纹行保留率)

五、运行验证:H3C 项目实测

337 份手册过门禁的实测数据:

指标
清洗后空段率 0.01%(4277 页手册)
表格结构抽检 无截断(图表防截断三层检测)
提示框识别 配置指导 18.5%、故障手册 6.4%(无「图 N-N」标题的图标图,清洗时删引用不入 manifest)
污染注入回归 清除率 ≥94%、误伤 0
建库后检索 RAG 体检通过、库内问题 top-3 命中

六、实战坑(都是真踩出来的)

现象 修复
评分 99 却列错位 表格 6 列压成 4 列、数据错位,评分全绿 评分测格式测不出内容——加 L1 指纹抽检 + 人工抽检表格
清洗规则改了旧结果没重跑 新脱敏正则未生效,敏感信息进库 规则变更后必跑污染注入回归 + 重跑受影响批次
短行一刀切误伤 按长度删「短行」把有效内容删了 不按长度一刀切——只删纯符号/乱码/页眉页脚特征行
图表截断肉眼发现不了 流程图只提取 1/4,尺寸正常但内容残缺 系列内高宽比对比 + 非白像素占比 + 内容回环验证
手机号残留统计误计 代码块长数字串被当手机号计为「未脱敏」 正则 lookaround 精确匹配,不裸 findall

七、启示

门禁的本质是把「看起来干净」变成「可证明的干净」:评分闸证明格式、验证闸证明内容、回归闸证明规则——三道闸合起来回答「这批文档能不能建库」,而不是「这批文档干不干净」。

对我们来说,门禁最大的价值不是挡下了多少脏文档,而是让清洗变成可审计的过程:每次清洗都有评分、有指纹、有回归记录,出了问题能追到是哪道闸放行的。交付客户时,「空段率 0.01%、污染清除率 94%+」这些数字,比「我们洗得很认真」有说服力得多。

清洗质量 = 信息保持 + 噪声去除,两个都要量化,缺一不可。

本文基于真实项目交付经验撰写(doc-cleaner v1.9.0 清洗管线 + Dify 1.16.x 建库环境)。文中数据均来自我们自己的实测记录(H3C 手册项目 337 份文档、污染注入回归清除率与误伤数据),理论与推断部分以「实测」标注边界,不构成任何平台的官方结论。

联系我

15088711270

手机端点击号码可直接拨打 · 桌面端可复制

微信二维码

扫码加微信 · 备注「门户」更快通过