RAG 项目验收标准怎么写

这是一份给 RAG 项目业务负责人、内容负责人和技术负责人共同填写的验收专题页。

材料齐备时，可以安排 1 个工作日的跨角色工作坊完成初稿；这不是对所有项目的普遍工期承诺。参与者至少包括业务、知识所有者、技术和安全或权限负责人。小范围试点结束后，再安排复测与签字。最终交付不是一个孤立准确率，而是范围说明、版本化问题集、评分规则、权限测试、性能条件、失败记录和维护计划。

参考安排：材料齐备后用 1 天完成初稿，试点后再安排半天至 1 天复测。 内容始终按边界、问题集、评分、引用、权限、失败与性能、反馈维护 7 个模块组织，每个模块都要留下可验收材料。

这套模板解决什么问题

“回答准确率达到某个数字”无法说明测试了哪些问题、由谁评分、引用是否可信、越权是否被平均值掩盖。

这套模板把验收拆成可重复执行的测试。具体阈值必须根据真实问题、风险和原流程基线确定，本文不提供虚假的通用合格线。

第一项交付：服务边界表

| 字段 | 填写内容 | 示例 | | --- | --- | --- | | 目标用户 | 哪个角色使用 | 售后客服 | | 支持任务 | 系统负责什么 | 查询现行售后政策 | | 知识范围 | 接入哪些集合 | 已审核政策库 | | 不支持任务 | 明确排除什么 | 个案赔付裁决 | | 人工出口 | 范围外交给谁 | 值班主管 | | 版本 | 本轮验收边界版本 | scope-v1 |

范围外问题的正确表现可以是拒答或转人工，而不是勉强生成。

第二项交付：版本化问题集

问题应来自脱敏后的工单、内部搜索或业务访谈，并覆盖直接问法、口语改写、条件缺失、冲突资料、范围外和高风险问题。

每行填写：问题 ID、原始问法、期望证据、关键结论、允许差异、禁止输出、风险级别、评审人和数据集版本。

文档变化后，要判断旧标注是否仍有效；不要只更新知识库而保留过期标准答案。

第三项交付：分层评分表

| 验收层 | 通过条件写法 | 证据 | | --- | --- | --- | | 召回 | 目标证据进入约定候选范围 | 候选记录 | | 回答 | 关键结论完整且无虚构 | 人工评分理由 | | 引用 | 引用能定位并支持结论 | 原文位置 | | 拒答 | 无资料或范围外时不猜测 | 失败状态 | | 权限 | 用户只检索被授权内容 | 多角色测试 | | 任务 | 结果能被确认并进入下一步 | 写回记录 |

每项填写项目自己的阈值或逐条规则。高风险错误可以设为阻断项，不应被平均分抵消。

第四项交付：引用与版本测试

引用必须能打开当前有效原文，并定位到支持结论的片段。多条结论要分别找到证据，冲突来源不能被静默忽略。

可执行一个“隐藏回答，只看引用”的检查：评审者能否从证据恢复核心结论。若不能，引用只是装饰。

第五项交付：多角色权限测试

为不同部门或角色准备测试身份，对同一问题比较候选集合、回答、原文访问、缓存、日志、导出和分享结果。

表格记录测试账号角色、预期可见范围、实际候选、是否泄露和处理结论。一次严重越权就应阻断上线，不进入平均分。

第六项交付：失败与恢复测试

至少覆盖无可信资料、无权限、文档解析失败、模型超时、输出格式错误和外部服务不可用。

每个失败填写用户看到什么、中间状态是否保存、能否安全重试、是否会重复写入、由谁接管。响应快并不代表任务体验完整。

同一项交付还要写清延迟与容量条件。不要只填平均响应时间，而要分别记录约定并发下的分位延迟、超时比例、单次请求上限、批量任务队列、重试上限和降级行为。测试环境、文档规模、模型版本与缓存状态必须随结果保存，否则数字不可复现。

性能阈值应来自原流程和用户等待窗口。例如需要现场确认的客服辅助，与允许异步完成的批量文档处理，不能共用一条延迟标准。容量超过上限时，系统应排队、拒绝或降级，而不是静默丢失任务。

第七项交付：反馈与维护计划

交付时说明文档怎样新增、旧版本怎样下线、索引怎样更新、变更后怎样回归，以及未命中和人工修正由谁处理。

维护表至少有问题类型、负责人、状态、修复版本、验证人和复盘时间。没有运营入口，首次验收通过也难以长期保持。

适合谁与不适合谁

适合：已有明确场景、能取得真实问题、文档有所有者、准备做小范围试点的企业知识库团队。

不适合：一次性演示、没有数据授权、希望用一个数字覆盖所有风险、要求系统替代正式审批或专业判断的项目。个人资料库可以简化，但仍建议保留来源和失败记录。

常见失败

只测演示问题；只看答案不看引用；评分规则由评审者临时理解；管理员账号代替多角色测试；阈值精确但没有业务依据；项目通过后不再回归。

发现标准理解不一致时，先修验收表，再运行测试。否则结果不可比较。

FAQ

没有真实问题集能否验收？ 只能做技术试验，不能声称完成业务验收。先通过访谈和小范围使用建立初版问题集。

问题集需要多大？ 由问题类型、风险与覆盖决定。高风险低频问题应单独纳入，不能只追求数量。

自动指标能替代人工吗？ 可以辅助批量回归，但事实、权限和业务可用性仍需明确评审责任。

文档更新后要全部重测吗？ 至少重测受影响范围、高风险问题和历史失败样本，并记录本轮回归版本。

谁应该批准最终验收？ 业务负责人确认任务可用，知识所有者确认事实版本，技术负责人确认稳定与可追溯，安全或合规角色确认权限边界。任何角色都不应替另一角色签字。

模板的可信边界

这份页面是 v0.1 公开草案，提供验收结构，不替代企业自己的安全、法务与采购评审。本站目前没有可公开核验的客户交付履历或脱敏验收表，不能声称这套模板已在真实项目中证明有效。模板是否可用，要由采用团队把每条标准落到样本、环境、证据、责任人和复测记录；无法提供材料时，结论必须标为待验证。

首次使用后应公开或内部保存版本变更记录：哪些字段无法填写，哪些高风险样本遗漏，性能条件是否可复现，哪些签字角色实际缺席。至少经过一次真实项目的脱敏复盘，才适合把 v0.1 升级为“已验证模板”。

行动入口

复制本文七张交付表，先由业务、内容和技术负责人分别填写，再开一次对齐评审。第一轮只选择一类知识和一组真实问题。

评审结束必须留下：已确认通过条件、阻断项、待验证假设、责任人和下一次回归触发条件。验收的价值不是宣布系统永远正确，而是让团队知道何时可用、何时拒答、出了问题怎样修。