AI产品功能评测框架：AI客服、RAG与Agent评测集模板

AI 功能评测不是上线前做一次“准确率测试”。它是一套持续的决策系统：把用户任务变成可检查的标准，用离线数据快速比较版本，再用线上行为、业务结果和风险信号验证真实价值。

只看“回答看起来不错”，无法复现；只看点赞率，会混入流量、人群和界面变化；只看一个平均分，又可能掩盖高风险切片。完整框架需要把任务、数据、评分、发布和监控连起来。

一、先写评测章程

在选择工具或评分器之前，用一页文档写清：

1. 用户任务：用户想完成什么，而不是模型要生成什么；
2. 产品边界：哪些输入、语言、地区和动作包含或排除；
3. 正确行为：什么算通过、部分通过和严重失败；
4. 决策用途：选择模型、调提示词、灰度上线还是监控回归；
5. 风险等级：错误是否可发现、可撤回，影响谁；
6. 负责人：谁维护数据、裁决分歧、批准上线。

例如，“客服助手回答问题”仍然太宽。更可评测的任务是：

根据已批准的帮助中心内容，草拟一条可追溯的退款政策回复；信息不足时应追问或转人工，不得虚构政策。

OpenAI 的官方 Evals 指南 把评测组织为任务、测试输入、分析和迭代；评测最佳实践 强调以任务目标为起点并持续评估。以下框架采用这些通用原则，但不依赖特定模型或平台。

二、定义一个可执行的评分标准

把抽象的“质量好”拆成独立维度。对于基于知识库的客服草稿，可以使用：

再定义决策权重。高风险政策错误不能被“语气很好”的得分抵消，因此通常需要单独的发布阻断规则，而不是简单加权平均。

评分标准的质量检查

• 两位评审对同一批样本是否大体一致；
• 分歧是否集中在含糊描述上；
• 评分器能否引用触发判断的具体片段；
• “不知道/转人工”在适当场景是否算正确；
• 严重失败是否有明确、可执行的定义。

先用少量样本试评并讨论分歧，再扩大评测。

三、构建代表真实任务的评测集

评测集至少应包含四部分：

1. 典型样本：覆盖高频任务与主要用户；
2. 边界样本：长输入、错别字、多语言、信息缺失和冲突；
3. 高风险样本：隐私、越权、诱导编造和不可逆动作；
4. 历史回归样本：曾经在线上或测试中失败的案例。

为每条样本保存：

• 稳定的 case_id；
• 来源、创建日期、使用权限；
• 输入与必要上下文；
• 期望行为和允许的答案范围；
• 所属切片与风险等级；
• 人工标注者和争议记录。

不要把同一来源的近重复样本随机分到训练和测试两侧，否则可能高估泛化效果。评测集应版本化；修改标准或答案时，记录原因和影响。

下载评测集 CSV 模板

为了把字段直接落到表格中，可以使用以下无需注册的资产：

• 下载 AI 产品评测 CSV 模板
• 下载中文字段说明与使用指南

模板包含显著标注的合成示例，覆盖普通任务、信息不足、冲突来源、提示注入、敏感信息和越权工具调用。示例不是生产数据，也不是某个模型的真实评测结果；baseline_output、candidate_output 与人工标签字段留给你的团队填写。

同一份模板怎样适配 AI 客服、RAG 与 Agent

三类产品不能共用一套笼统的“回答质量”标准。先固定用户任务，再按系统能访问的上下文和能执行的动作填写字段。

这些只是字段写法，不是通用发布标准。是否阻断发布，要结合动作可逆性、影响范围、用户能否发现错误以及人工兜底能力决定。

按五步填写 CSV

1. 用 task_type 固定任务边界，不把“客服助手”或“智能 Agent”当作任务名称；
2. 把影响决策的语言、证据缺失、权限或失败状态写入 slice 和 risk_tier；
3. 在 context 中只放本次运行允许系统使用的事实、检索片段和工具约束；
4. 把可观察的通过行为写入 expected_behavior，把一票否决错误写入 critical_failure；
5. 固定输入后分别写入 baseline_output 与 candidate_output，再依据三项 rubric 填写 human_label、failure_type 和 reviewer_notes。

不要先运行模型再倒推“期望答案”。关键用例应先由熟悉任务的人定义可判定行为；若存在多个合理答案，就写允许范围和不可接受边界，而不是只保留一句参考文本。

样本量如何决定

没有适用于所有任务的固定数字。样本量取决于切片数量、失败率、差异大小和决策风险。探索阶段可以从几十条高质量样本开始，发布决定则需要更稳定的覆盖和不确定性分析。报告每个切片的样本数与区间，不要把小样本的一两次变化包装成确定提升。

四、组合三类评测器

1. 确定性检查

适合格式、结构和可程序化验证的约束：

• JSON 是否符合 schema；
• 必填字段是否存在；
• 引用 ID 是否来自检索结果；
• 禁止词、长度或数值范围；
• 工具调用参数是否在权限内。

它们便宜、稳定、易定位，但不能判断所有语义质量。

2. 模型评分器

适合需要语义判断的大规模初筛，如相关性、完整性和语气。使用时应：

• 给出清晰 rubric 和正反例；
• 要求结构化分数、理由和证据片段；
• 固定并记录评分模型、提示词和参数版本；
• 用人工标注集校准；
• 检查位置偏差、偏好冗长、同源模型偏差等问题。

模型评分不能自动成为“真值”。它是一个测量工具，也需要评测。

3. 人工评审

适合高风险、主观体验和最终发布抽样。采用盲测或随机顺序，隐藏候选版本名称；提供冲突裁决规则，并记录评审时间与一致性。

最实用的组合通常是：确定性检查覆盖硬约束，模型评分器扩大语义覆盖，人工评审校准并处理高风险切片。

五、离线结果应该怎样读

每次比较至少报告：

• 总体严格通过率；
• 各关键切片的通过率和样本数；
• 各类严重失败次数与比例；
• 相对基线的差异及不确定性；
• 延迟、成本、超时和格式失败；
• 与上一版本相比新增、修复和复发的案例。

平均分提升但高风险切片退化，不应直接上线。对同一批样本做配对比较，能减少样本差异造成的噪声；候选版本顺序也应随机或盲化。

六、把离线评测连接到线上指标

离线质量是发布门，不等于用户价值。线上至少观察四层：

同时设置护栏：投诉、敏感信息事件、越权动作、特定人群差异和人工负担。上线实验应明确分流单位、观察窗口、最小样本、停止条件和回滚方案。

如果无法随机实验，可以使用分阶段灰度、前后对比或匹配对照，但要公开其限制，不把观察性结果写成确定因果。

七、三类项目分别要展示什么结论

如果评测内容要进入产品方案或求职作品集，最终页面不要停在一张总分图。不同项目应回答不同的发布问题。

AI 客服

• 事实能否追溯到批准政策，政策缺失时会不会主动转人工；
• 草拟回复与执行退款、改订单等动作是否严格分离；
• 哪类问题人工修正最多，修正后能否进入脱敏回归集；
• 语气改善是否掩盖了政策错误或权限问题。

RAG 问答

• 失败来自检索未命中、文档本身冲突，还是生成阶段没有忠实使用证据；
• 引用是否真的支持对应结论，而不只是主题相关；
• 证据不足时是否拒答或追问，过期文档如何识别；
• 切换索引、切分、重排或模型后，哪些切片改善、哪些回归。

工具调用 Agent

• 计划正确不等于执行安全：工具名、参数、对象、权限和最终状态要分别检查；
• 不可逆或有外部承诺的动作是否在目标解析后再次确认；
• 工具部分成功、超时或返回歧义时，系统是否停止并如实报告；
• 多步执行是否出现重复调用、循环、状态丢失或“假成功”。

任何一类项目都要把“当前证据支持什么”与“尚未验证什么”分开写。离线评测可以支持版本比较与灰度范围判断，但不能替代真实线上业务结果。

八、持续评测与回归

上线后建立闭环：

1. 记录模型、提示词、检索库、工具和评分标准版本；
2. 从用户纠错、人工接管和事故中抽取候选案例；
3. 脱敏并审核后加入回归集；
4. 每次变更运行固定门禁；
5. 按语言、场景和风险切片监控漂移；
6. 定期复核评分标准是否仍对应用户任务。

数据分布会变化，知识库也会更新。评测通过只表示某个版本在某套数据和标准下达到要求，不是永久有效的认证。

九、可复制的评测计划模板

任务： 目标用户与场景： 包含 / 排除范围： 当前基线： 评测集版本与来源： 关键切片： 评分维度： 严重失败定义： 确定性检查： 模型评分器与校准方法： 人工评审与分歧裁决： 离线发布门槛： 线上主要指标： 护栏与停止条件： 灰度范围与回滚： 负责人和复评日期：

如果还不确定评测集能否成为作品集证据，可以先完成AI 产品经理作品集 12 项免费自检。已经把评测集放进作品集、希望检查证据链和表达是否完整时，可以查看作品集 / 简历异步批改。