企业RAG上线前自检清单：30项逐条核对

结论先行：企业 RAG 上线前必须逐项核对，漏掉任何一项都可能变成线上事故。下面 30 项分六组，作为发布闸门逐条打勾，任何一项不达标先拦下。

一、数据质量（1–5）

数据质量是第一道闸门，因为它坏了后面全坏：解析丢掉的段落，检索和生成永远补不回来。行业经验里约 80% 的 RAG 效果问题出在数据处理不当，这五项就是拦住它的第一道网。

• 解析完整度达标，无整篇乱码或丢页
• 扫描件走 OCR + 版面，表格结构还原正确
• 页眉页脚水印已清洗，无结构噪声
• 老格式（OLE2 .doc / 巨潮 .bin / HTML）差异化解析兜底
• parse_quality 三层评分在可接受阈值内

扫描件与老格式是重灾区。批量入库前先跑样本拿基线：一份 443 页的 OFD 版式文档跑完整条解析流水线约 124 秒，三层解析质检 0.924 分——样本达标再放量。

二、检索与切片（6–10）

解析过关后是切片与检索，这一组决定“问得到找不到”。固定长度粗暴切块把语义切碎，只做向量检索又对型号、编号、指标词这类精确查询不友好，两边的坑都要堵上。

• 切片按文档类型选四档预设，未用粗暴固定长度
• 父子 Chunk 已启用，检索用子块、生成用父块
• Chunk 四级增强（面包屑/关键词/摘要/HyDE）已加
• 混合检索 BM25 + 向量 + RRF 融合已开
• CJK bigram 分词已用于中文 BM25 支路

上线前用真实业务问题做检索冒烟测试。某匿名案例中 000001、000002 十问冒烟均 10/10 命中——先把冒烟跑绿再上线。

三、安全与权限（11–15）

安全项的特别之处在于出错无声：脱敏晚了、权限过滤后置，系统照常返回答案，只是答案里混进了不该出现的内容。所以这一组不能靠表象，要逐项确认机制在生效。

• 脱敏在切片与向量化之前完成
• 11 类敏感目标检测已开启并处理
• 权限打标三级继承、密级就高合并
• 权限过滤在检索前前置，非后置
• 数据不出域，推理全本地 ONNX

权限过滤务必前置：后置过滤不仅浪费 Top-K 名额，还会向用户泄露敏感文档的存在性。11 类敏感目标检测与密级就高合并，都必须在切片与向量化之前生效。

四、评测闭环（16–20）

评测不是一次性仪式，而是持续闸门：切片或清洗规则一改，自动重跑对比，效果回退立即暴露。

• 语料级指标（解析/表格/OCR/脱敏/权限）有基线
• 检索级 HitRate@K / MRR / NDCG@K 已度量
• 生成级 Faithfulness / AnswerRelevancy 达标
• 回归门禁已接入，变更自动重跑评测
• 磁盘嵌入缓存开启，迭代成本可控

三层指标分层看：语料级定位数据问题，检索级 HitRate@K / MRR 定位检索问题，生成级 Faithfulness 定位幻觉问题。过滤手段也要量化——某匿名案例中时间过滤约 95.5% 的无关候选，Top-K 才干净。

五、部署形态（21–25）

四组全绿后，最后一道坎是部署：形态与场景不匹配，好管道也会被运维拖垮。

• 交付形态（CLI / HTTP / FFI）与场景匹配
• HTTP 服务 SSE 进度推送与 Prometheus 监控就绪
• FFI 接口 catch_unwind 保护，无崩溃外溢
• 文件式存储，备份与迁移可操作
• 多租户鉴权、配额、审计日志已配置

验收前跑工程证据清单：61 项单元测试、12/12 HTTP API 测试、28/28 SDK C API 测试，六格式入库 E2E 增量审计全部通过——数字对不上，先别签验收单。

六、运维与治理（26–30）

上线不是终点，知识库会持续增长，这一组决定半年后它是资产还是负债。

• SHA-256 幂等，重跑不返工
• 增量 diff 只更新变更块
• 版本归档默认 3 版，可回滚
• valid_until 时效治理，作废内容不再被引
• 断点续跑状态机就位，大规模语料可分批

重点验证幂等与断点续跑：SHA-256 幂等让重跑 0.2 秒即跳过已完成预处理，大规模语料分批导入不返工；valid_until 保证作废制度不再被引用。

收尾

把这 30 项当作发布闸门：任何一项不达标都先拦下。最容易踩坑的是数据质量的 1–5 与安全权限的 11–15，且它们的出错常常无声，建议发布前优先复核。配套能力见 RAG 数据质量、评测三层指标 与 私有化部署。

清单管流程，评测管证据：前者保证该做的都做了，后者证明做得够好。都齐了再按发布键。

上线之后：前 30 天的运维节奏

清单管上线，节奏管持续。上线后前 30 天建议按周推进：

• 第 1 周 · 基线固化：跑三层评测并归档基线（检索冒烟对标 10/10 命中），开启用户点踩采集，接入 R1–R6 归因。
• 第 2 周 · 缺陷回收：点踩 badcase 回流评测集，按归因分布决定先修哪一环（多数团队的第一个热点是切片或解析，而不是模型）。
• 第 3 周 · 变更上轨：所有切片 / 清洗 / 检索参数变更强制过回归门禁，控制变量实验批量调参。
• 第 4 周 · 治理转正：版本归档与时效治理（valid_until）进入例行，增量导入 + 断点续跑成为默认更新方式。

判断这套节奏是否健康，看两个信号：评测是否每次变更都跑（DiskEmbeddingCache 让它零重复嵌入成本），点踩归因是否收敛到具体环节而不是「答得不好」。门禁机制的完整设计见RAG 回归门禁与控制变量实验；上线前的 30 项静态核查清单见本文正文。上线只是起点，持续运营的方法论见RAG 评测三层指标。

常见问题 FAQ

Q1：这 30 项清单分几组？

分六组：数据质量（1–5）、检索与切片（6–10）、安全与权限（11–15）、评测闭环（16–20）、部署形态（21–25）、运维与治理（26–30），每组五项，发布前逐条打勾。

Q2：最该优先核对的是哪几项？

数据质量的 1–5 与安全权限的 11–15 最容易踩坑，且出错常是无声的：解析丢段、脱敏滞后、权限过滤后置，都到线上才暴露，建议优先复核。

Q3：清单应该什么时候用？

作为发布闸门在正式上线前逐条打勾，任何一项不达标先拦下；切片或清洗规则大改后，也建议重跑一遍清单再发布。

Q4：清单能代替评测吗？

不能。清单是流程闸门，保证该做的都做了；评测是量化证据，证明做得够好。两者配合才构成完整的上线依据。