检查一、二：语料与切分
语料是否有清单、授权与负责人；切分是否按文档结构进行，而不是按固定字数机械切。为什么先查这两项？因为切分错导致的召回失败，往往被误判成模型能力问题，白白花掉很多时间在调提示词上。
检查三、四：权限与检索
元数据是否包含来源、版本、生效日期与可见范围；权限是否在检索层过滤；关键词与向量是否同时启用并接入重排。四项缺一项，都会让答案在多文档环境下变得不可靠，甚至出现越权，这是权限设计的边界。
检查五、六：引用与评测
答案是否附出处并可点回原文；低置信度时是否拒答并转人工；评测是否拆成召回与生成两段，各自有样本与指标。只评最终答案的系统，无法判断问题出在检索还是生成，迭代会失去方向，也就无从判断该修哪一层，这是评测设计的边界。
检查七、八：更新与闭环
文档变更是否触发索引更新，旧版本是否有失效标记；未命中问题是否有记录、分配与复盘机制。最后两项决定系统半年后是否还能用，也是最容易被当成后续优化而无限期推迟的部分，边界要一开始就划清。
适用与不适用
适合谁
- 正在评审 RAG 方案的项目组
- 已经上线、准备做二期优化的团队
- 需要给管理层一份可核对依据的负责人
不适合谁
- 还没有任何文档基础、也没有负责人的项目
- 希望接上模型就直接有答案的团队
典型场景
某保险公司的知识问答上线前按八项复核，发现语料清单没有负责人、权限只在提示词里约束、评测也只有最终答案打分。团队补了三项后重新评测，召回层问题一目了然，调整切分后准确率明显改善，也没有再出现越权提问。
可执行步骤
- 把八项做成一页复核表，逐项写明通过标准，以及需要提交的证据材料
- 随机抽查十个文档，逐段确认切分时是否完整保留了条款与章节结构
- 用不同岗位的账号各测一次，验证权限过滤是否在检索层就已经生效
- 用三十条真实问题各跑一轮召回测试，逐题记录正确段落排在第几名
- 检查各个旧版本是否都有失效标记，未命中的问题是否有台账和责任人
常见坑
- 只查模型与界面，不查语料清单，上线之后才发现部分文档根本没有授权，只能下线重做。
- 权限只用提示词约束，实际没有过滤候选文档，一次提问就可能暴露敏感条款，且无法追溯。
- 评测只看最终答案，召回问题被完全掩盖，改来改去都在调提示词，效果原地踏步不前，也找不出原因。
- 旧版本没有失效标记，制度改版后新旧答案并存，用户看到哪一条全凭运气，投诉很难解释。
自检与验收清单
- 语料是否有清单、授权文件以及明确指定的负责人
- 切分是否按文档结构进行，并保留完整的元数据
- 权限是否在检索层就已经完成过滤，并留下记录
- 答案是否附出处，并支持在置信度较低时主动拒答
- 是否有召回与生成两段独立的评测集，以及各自指标
- 旧版本是否有失效标记，是否能立即下线并通知用户
常见问题
八项里最容易被忽略的是哪项？
通常是语料授权与旧版本失效。前者在技术评审里不显眼，却可能在合规检查时成为硬伤；后者平时不影响使用，等制度改版后才发现系统还在引用作废条款，解释起来很被动。
上线后还要做这些检查吗？
要，但频率可以降低。建议每季度复核一次语料清单与权限，每月看一次未命中清单与拒答率。制度类文档改版时，临时加一次失效标记检查，避免新旧版本同时出现在答案里。
检查要留下什么证据？
每次检查保留截图、抽样清单与结论，形成可追溯的记录。口头确认在半年后基本无法复盘，尤其是权限与授权这两项，留痕比结论本身更重要，也方便后续交接与复盘追问。