知识库验收需要能够回到具体问题和具体资料。只写“回答准确率达到要求”，业务方与工程方可能对分母、评分标准和资料版本有不同理解。本文提供一份建议评测方法，可按项目风险和使用范围调整。
先让业务方确认答案依据
以下为教育场景示例。用户询问某校区的申请截止时间，评测表应记录校区、政策版本、生效日期和允许查询的身份。若问题缺少校区，预期行为可以是追问；若资料尚未发布，预期行为可以是说明缺少依据并指向人工咨询渠道。
评测不要求所有回答字面相同，但应写明必要事实、不得推断的内容和需要提供的来源。遇到部门意见不同的政策，先解决资料口径，再调整模型。
每条样本记录这些字段
| 字段 | 用途 |
|---|---|
| 样本编号与问题 | 便于重复运行和定位讨论 |
| 用户角色与资料版本 | 确认该角色可见的有效内容 |
| 预期行为与必要事实 | 规定答复、追问或转人工的条件 |
| 检索片段与实际回答 | 区分资料获取和答案组织的问题 |
| 评分、问题类型与评审人 | 留下业务判断依据 |
| 耗时、任务状态与版本号 | 追踪运行条件及修改影响 |
业务测试集应包含正常问题、缺失条件、相互冲突的旧新资料，以及不同权限的用户。另保留未用于日常调优的样本作复核，避免只对一组熟悉问题表现良好。
如何定义评分口径
“业务通过”可定义为必要事实正确、来源可核对且符合该用户权限。缺少来源但结论正确的结果，可以单独标记为待改进，而不是由每位评审人自行决定是否通过。统计时同时展示总样本数、通过数、追问或拒答是否符合预期，以及未完成任务数。
如果某一类样本涉及关键业务决策，应单独列出结果，不能让大量简单问题掩盖该类失败。不存在适用于所有知识库的统一通过比例；目标由业务用途和错误影响共同决定。
失败之后怎样分配修复任务
没有有效资料时找资料负责人；资料有效却未取到时检查解析、分段和检索；取到资料却答错时检查问题理解和回答约束；角色能看到不该看的内容时检查权限链路。每次修复后复测相关样本，也复测此前已经通过的关键项。
在试用期收集“查到但没用上”的反馈，例如引用无法打开、政策格式难读或工作入口不方便。这类问题可能不影响离线分数，却影响日常使用。
扩展阅读：Microsoft 的生成式 AI 可观测性说明介绍了评估、跟踪与监控的配合关系。本文的表格是用于项目沟通的建议格式，具体指标仍需按实际任务制定。