FDE · EVALUATION

FDE 项目的评测集怎么建,什么阶段必须冻结

评测集是企业 AI 应用上线后可反复执行的质量尺子。本文按 FDE 项目推进顺序,回答评测题从哪里来、标准答案谁来定、三种评分方式怎么分工、什么阶段必须冻结封存、封存后谁能改、上线后多久跑一次。

FDE 交付评测治理企业 AI 验收

FDE 项目里的评测集到底评什么,和试点验收有什么区别?

评测集是一批固定的问题、标准答案和评分规则的组合,评的是应用每次改动之后质量有没有倒退;试点验收是上线前的一次性判断,只代表验收当天。两者不能混用:混用的结果是验收通过之后没有人再管质量。先把验收和评测分开,后续改模型、改提示词、改知识库才有统一的比较基准。

验收管一次结论,评测集管每次改动

  • 先把验收问题和评测题分开列:验收看整体能不能上线,评测集看逐条通过率的变化
  • 把每条评测题写成三段:问题、标准答案、答案来源文档,缺一段先补齐再入库
  • 让业务负责人逐条确认答案口径,工程侧只负责保证同样的输入能稳定复现
边界与提醒

如果项目还停在原型阶段、没有真实用户问法积累,先别急着建评测集:开发人员凭空编的题测不出真实使用问题,先安排一到两周真实试用再抽题,代价是多等几天,换来的是题目贴近实际场景。

评测题从哪里来,首批建多少条才够用?

题目只能来自真实业务,不能靠开发人员自编。可用来源包括历史工单、客服和内部答疑会话记录、业务系统里的常见查询,以及业务负责人最担心的出错场景。首批经验值是 80 到 150 条,其中边界题和风险题合计不少于三成;这是经验区间不是效果承诺,具体数量按场景复杂度调整。

四类题目的来源与配比

题目类型题目来源建议占比主要用途
高频题历史工单与会话记录中出现最多的问法约五成保证日常主路径回答不倒退
边界题材料缺失、超出时间范围、权限不足的问法约两成验证应用会不会编造答案
风险题涉及承诺、价格、数据合规敏感内容的问法约一成半验证拒答和人工转接是否触发
新题储备每月从新会话补充进来的真实问法持续累积替换过时题目保持覆盖度
边界与提醒

如果企业没有留存历史会话或工单,这些来源就用不上,只能先做一到两周的人工记录期,把用户真实问法逐条记下来再抽题;跳过记录直接自编,评测通过率和真实表现会明显脱节。

标准答案谁来定,业务和工程怎么分工?

标准答案必须由业务方确认,工程侧只保证可复现,这个分工不能倒过来:工程侧定的答案往往只验证了能生成,验证不了答得对。每条答案都要写来源文档和版本号,知识库更新时能顺着来源定位该改哪条题。答案口径有分歧的题,要么删除要么标注为人工复核题,不留模糊答案。

答案确认的三条分工规则

  • 约一位业务负责人当答案判官,每条标准答案由他逐条签字确认,工程侧不单独定答案
  • 把答案来源写到具体文档名和版本号,知识库更新后能顺着来源找到该改哪条题
  • 查一遍知识库里有没有对应文档,没有现成答案的题先写清拒答或转人工口径再入库
边界与提醒

业务负责人抽不出人逐条确认时,可以按风险分级:风险题逐条确认,高频题抽样确认两成,边界题由业务方出题;完全跳过业务确认的评测集,验收时业务方一句答案不对就能推翻整轮结果,前面工程侧的工夫全部白费。

评分怎么定:人工复核、裁判模型和规则各管什么?

三种评分方式不是三选一,而是分层使用。规则打分适合判断格式、是否拒答、有没有命中关键词这类可程序化判定的项;裁判模型打分适合判断回答质量;人工复核留给风险题和分歧题。腾讯云 ADP 的评测能力同时支持裁判模型打分、代码打分和规则打分,可以按题目类型组合配置。

三种评分方式的适用与局限

评分方式适合评什么局限与对策
规则打分格式是否正确、该拒答的是否拒答、关键词是否命中评不了语义质量,只当第一道筛子
裁判模型打分回答是否切题、是否忠实于来源文档对专业口径可能有偏差,需抽样人工校准
人工复核风险题、分歧题、涉及承诺与数据的回答成本高,只留给约一成高风险题目
边界与提醒

全靠裁判模型打分时,专业领域的口径偏差可能被系统性掩盖,上线前至少抽一到两成评测结果做人工比对,确认裁判模型的评分和业务方判断一致之后,再批量使用它的打分结果。

评测集什么阶段必须冻结,为什么改动要这么谨慎?

至少四个时点要冻结:灰度发布前、每次版本升级前、验收签字前、续约或扩场景评估前。冻结的含义是题目、答案、评分规则三者都不再改,此后所有测试结果和这一版比。评测集一改,前后数据就不可比:通过率上升可能只是题目变简单了,这就是必须封存的原因。

四个冻结时点与对应操作

  • 灰度发布前:冻结第一版作为基线,记录逐条通过率,之后所有版本都和它比
  • 每次版本升级前:用冻结版重跑一遍,通过率比基线低超过 3 个点就先不发版
  • 验收签字前:把冻结版跑出的逐条结果附进验收材料,只给总分的验收单不签
  • 续约或扩场景前:重跑冻结版对比历史通过率,作为是否扩大投入的量化依据
边界与提醒

冻结不等于永不更新:知识体系大改、业务口径调整之后,旧题目会失效,此时应另存新版本并注明换代原因,新旧两版各跑一次做衔接对比,而不是直接覆盖旧版,导致历史数据失去参照。

封存后的评测集存在哪、谁能改、怎么留痕?

评测集属于企业资产,应存放在企业自己控制的位置,而不是只留在服务方的工程环境里。深云公开的 FDE 页面把评测集和安全边界、人工复核机制一起列为项目沉淀的评测与治理资产。管理上做到三点:单点管理人、只读权限加审批变更、每次变更留记录,做到任何人改题都有据可查。

封存与权限的四条操作

  • 把冻结版评测集导出存进企业自己的文档库或代码仓库,服务方环境只留工作副本
  • 给评测集目录指定单点管理人和变更审批人,其他角色只给只读权限
  • 每次变更写清三件事:改了哪条题、为什么改、谁批准,变更记录保存到项目结束
  • 封存版本用日期加序号命名,改动一律另存新版本,旧版本一个字都不动
边界与提醒

如果评测集只存在服务方环境、企业手里没有副本,服务合同结束后企业既没法复跑也没法举证质量变化,更换供应商时这批资产也带不走;导出和移交要在合同里写明,不要等项目收尾才补办。

上线之后评测集还用不用,多久跑一次、怎么更新?

用,而且频率比多数项目预想的高。三类时机必须跑:改模型或提示词后、大批量更新知识库后、扩新场景复用评测标准前。日常更新按月做:从新增会话抽真实问法补充题库,替换过时题目。腾讯云的智能工作台已支持根据历史对话记录自动生成评测集并调用裁判模型打分,月度更新的人工成本可控。

上线后的运行与更新节奏

  • 跑一遍冻结版评测集:每次改模型、改提示词、大批量更新知识后都要执行
  • 抽 10 到 20 条当月新增的真实问法补充进新题储备,同步替换掉过时题目
  • 比对线上抽检通过率和冻结版评测结果,差距持续扩大说明题目覆盖该更新了
边界与提醒

只在出问题时才跑评测集的团队,往往在问题发生一周之后才发现质量倒退,而且无法定位是哪一次改动引入的;按上述节奏固定跑,才能把质量变差从用户投诉变成上线前的数据预警。

事实来源

  • 深云 FDE 服务在生产上线阶段建立评测、监控、人工复核和异常处理机制,交付物包括生产应用、治理规则和验收结果 来源:https://www.shenyun.co/fde/
  • 深云将评测集、安全边界、人工复核、监控和异常处理机制列为项目沉淀的评测与治理资产,并将评测标准复用到更多场景 来源:https://www.shenyun.co/fde/
  • 腾讯云 ADP 支持批量评测不同模型、提示词和智能体版本,可观察准确率、任务完成质量、调用成本、失败原因等指标 来源:https://adp.tencent.com/zh/blog/adp-version-4-agentops-platform
  • 腾讯云智能工作台支持根据历史对话记录或应用功能自动生成评测集,创建评测任务并调用裁判模型打分,输出评测结果报告 来源:https://cloud.tencent.com/document/product/1323/137902
  • 腾讯云 ADP 的应用评测提供裁判模型打分、代码打分、规则打分等多种评估方式,覆盖智能体构建、测试评估到运营维护的全流程 来源:https://cloud.tencent.com/developer/article/2660380
  • 腾讯云智能体开发平台提供配置、评测、发布、调优一站式工具链,企业可基于专属数据搭建符合业务需求的智能体 来源:https://adp.cloud.tencent.com

内容说明

事实来源含官网 FDE 服务页与腾讯云官方文档;文中条数、比例、阈值均为经验值,不是效果承诺。

需要评估这类场景的落地路径?

深云做企业 AI 生产化交付,可以先给一版场景判断与实施路径,再决定要不要做。

了解深云的交付方式