安全治理篇 · AI 质量课程

AI 评估 Evals

Evals 不是一次演示，也不是拍脑袋说“感觉变好了”。它是用固定测试集、明确评分标准和重复可比的流程，证明 AI 系统是否真的进步。只有能被反复验证的改进，才算工程上的改进。

要有测试集 固定样例、覆盖常见场景、异常边界和高风险输入。

要有评分标准 明确什么叫完整、正确、合规、可用，而不是只写“看起来不错”。

要能比较版本 比较不同 Prompt、模型、知识库和工具设计，确认改动是否真的更好。

要推动回流 失败样例回流到测试集和规则里，形成持续优化闭环。

eval-loop dataset / rubric / score / regress

测试集 固定问题、固定期望、固定版本，确保可比。

评分标准 完整性、事实性、格式、风险、工具路径。

→

评估结果 发现失败样例、比较新旧版本、定位回归。

Test
测试集

Rubric
评分

Compare
对比

Reflow
回流

01 · 先给定义

Evals 是用固定测试集和评分标准，证明 AI 系统真的变好了

它解决的不是“这次看起来不错”，而是“新版本到底有没有比旧版本更好”。

不做评估

靠感觉判断

演示时好像还行，但每次结果都不稳定，无法判断改动到底有没有带来提升。

做 Evals

靠样例和标准判断

用固定输入、固定期望和固定评分规则反复比较版本，改动效果一眼可见。

一句话面试版 可直接背

Evals 是用固定测试集和明确评分标准来评估 AI 系统的质量方法。它可以比较不同 Prompt、模型、检索策略、工具设计和护栏策略是否真的带来提升，并把失败样例回流到后续优化中。

02 · 为什么需要评估

没有 Evals，AI 系统很容易“看起来变好了，实际上没变好”

模型迭代、Prompt 调整、知识库更新、工具改动都可能让系统变好，也可能让系统悄悄退化。没有测试，就不知道。

不可比

每次看的是不同题

没有固定题集，就没法比较两个版本谁更好。

不稳定

一次好不代表次次好

模型输出有随机性，单次演示很容易误判质量。

难定位

不知道哪里坏了

没有评分标准和错误分类，就只能看到结果坏了，却不知道坏在哪。

难回归

修完又可能坏回来

改了 Prompt、知识库或工具后，旧问题可能修好，新问题又冒出来。

03 · 评估维度

评估不是只看“答案像不像”，而是看一组维度

不同应用要看的东西不一样。客服、PRD、搜索、工具调用、Agent 任务完成率，评估重点都不同。

内容质量

对不对、全不全

包括准确性、完整性、事实性、格式、风格和可执行性。

安全性

会不会越界

包括越权、敏感信息、攻击内容、错误动作和不合规输出。

系统性

流程走得通吗

包括工具调用路径、任务完成率、失败恢复和多步一致性。

评估维度配置 eval-dimensions.json

{
  "dimensions": [
    "accuracy",
    "completeness",
    "factuality",
    "format",
    "safety",
    "tool_path",
    "task_completion"
  ]
}

04 · 测试集怎么建

测试集不是随手挑几个例子，而是要有代表性和覆盖面

一个好的测试集，至少要覆盖常见场景、异常场景、边界场景和高风险场景，才能看出系统是否真的稳。

测试集来源 Dataset

1真实线上样本，做脱敏后抽样保存。
2人工设计的边界样例和对抗样例。
3历史失败样例和人工申诉样例。
4业务方提供的典型问题和黄金答案。

测试集样例 eval-sample.json

{
  "sampleId": "prd_eval_1042",
  "input": "商品导入失败后，运营如何查看失败原因并下载明细？",
  "goldAnswer": "说明入口、字段、权限、下载和过期规则",
  "tags": ["prd", "enterprise", "workflow"],
  "difficulty": "medium",
  "expectedBehaviors": [
    "不编造系统现状",
    "列出本期范围和非范围",
    "说明权限和异常状态"
  ]
}

05 · 评分标准

评分标准要把“什么算好”写清楚，不要只写感觉词

Rubric 的作用，是让不同人、不同时间、不同版本的评估尽量一致。

维度	0 分	3 分	5 分
完整性	严重缺项	基本覆盖，但有遗漏	关键点齐全，结构清楚
事实性	明显编造	部分准确，部分不确定	与资料和工具结果一致
安全性	有越权或泄露	能识别部分风险	能稳定拦截高风险内容
可执行性	无法落地	大致可执行	能直接进入后续流程

06 · 评估流程

评估流程要固定，不然结果没法比较

固定流程的意义，是保证每次评估都在同一套条件下进行，避免“这次用这个题集、下次换那个题集”的错觉。

1 定义任务 先明确要评的是内容、工具、检索还是 Agent 任务完成。

2 准备测试集 把样例固定下来，版本化管理。

3 写 Rubric 定义什么算通过，什么算部分通过，什么算失败。

4 运行评估 同一批样例跑多个版本。

5 人工复核 对关键样例和分歧样例做人工确认。

6 分析回流 定位失败原因并回写到测试集和规则里。

07 · A/B 对比

真正有用的 Evals，通常是在比较两个版本谁更好

比较对象可以是 Prompt 版本、模型版本、检索策略、工具权限、输出模板，或者护栏配置。

Prompt A/B

比较不同提示词

看哪个版本更完整、更稳定、更少幻觉。

Model A/B

比较不同模型

看换模型后质量是否真的提升，以及成本是否可接受。

System A/B

比较不同系统设计

比如换检索策略、换工具边界、换输出格式，再看结果变化。

08 · 回归测试

每次改动都要跑回归，不然修一个坑会踩出新坑

Prompt、知识库、工具、护栏和模型都可能引入回归。回归测试的作用就是尽早发现。

旧 旧样例不变

保持一组稳定样例，作为长期基准。

新 新样例补充

把最近出现的失败和新风险加入评估集。

比 版本对比

比较新旧版本是否真的更好，还是只是换了表现方式。

回 持续回归

每次改动后都跑一遍，避免旧问题复活。

09 · 失败分析

评估真正有价值的地方，是找到“为什么失败”

只知道分数没有用。你要知道是上下文不够、规则不清、检索错了、工具错了，还是输出格式有问题。

失败类型	常见原因	修法
漏信息	上下文没给全、测试集题目不够明确。	补上下文、补测试样例、补追问规则。
幻觉	模型硬猜、缺乏事实来源。	加检索、加引用、加工具校验。
格式错	没有稳定输出模板。	加结构化输出和程序校验。
越权	工具权限过大或护栏没拦住。	收紧权限、加审批和输出过滤。

10 · 样例回流

失败样例和人工反馈，才是最值钱的资产

每次评估后，不是只出报告，还要把高价值失败样例回流到测试集、规则和 Prompt 里。

回流对象 Reflow

1测试集：补进新的失败和边界样例。
2Rubric：修正评分标准里的模糊项。
3Prompt：修正指令歧义和输出要求。
4护栏：补风险判断和审批条件。

回流记录 feedback-loop.json

{
  "sampleId": "prd_eval_1042",
  "failureType": "missing_scope_and_non_scope",
  "humanFeedback": "没有明确写出本期不做什么",
  "actionTaken": [
    "added_to_dataset",
    "updated_rubric",
    "patched_prompt"
  ]
}

11 · 评估治理

Evals 本身也要治理，不然会变成新的形式主义

评估不是一次性动作，而是一个需要 owner、版本、门禁和审计的长期机制。

版本管理

题集和 Rubric 要版本化

不然你连去年 5 月的分数是怎么来的都解释不清。

门禁

发布前必须过评估线

重要改动不能只看开发自测，必须过统一评估。

审计

分数背后要能追溯

谁打的分、依据是什么、样例从哪来，都要留得住。

12 · 完整案例

用 Evals 证明 PRD Agent 的版本确实变好了

这段可以作为面试项目讲法：从历史需求出发，建立评估集，再用评分标准比较新旧版本。

收集历史样例 整理 50 条历史需求、人工评审过的 PRD 和失败 PRD。

标注 Rubric 给每条样例标完整性、系统贴合度、规则准确性和可测试性。

跑旧版和新版 比较 v1 和 v2 Agent 的输出，观察是否减少遗漏和编造。

分析差异 看是 Prompt 改进、知识库补全，还是工具和护栏升级带来的提升。

回流修正 把失败样例加入测试集，把评分争议补进 Rubric。

发布门禁 没有通过评估线，就不能进入生产环境。

评分报告片段 eval-report.md

# PRD Agent Evaluation Report

## Version Compare
- v1 average score: 3.1 / 5
- v2 average score: 4.2 / 5

## Improvements
- more complete scope definition
- fewer missing assumptions
- better handling of non-goals

## Remaining Failures
- still weak on legacy system compatibility
- some rubrics need clearer boundary cases

13 · 指标和报表

评估结果最后要落成能给团队看的报表

报表不是装饰，它是推动改进的依据。没有报表，评估结果很快就被忘掉。

报表项	看什么	作用
总体分数	每个版本的平均得分。	看整体趋势。
维度分数	完整性、事实性、安全性等单项得分。	看强弱项。
失败分类	漏项、幻觉、格式错、越权等。	看主要问题来源。
回归数	新版本引入的退化样例数量。	看是否越改越坏。

14 · 面试问答

面试时讲评估，要讲“怎么证明”，不是只讲“怎么跑”

面试官想听的是你如何把 AI 质量工程化，而不是你会不会调一个分数面板。

问题 1：Evals 和单次演示有什么区别？

单次演示只能说明“这次回答看起来不错”，不能证明系统稳定。Evals 用固定测试集和评分标准反复比较版本，能判断系统是否真的进步，并定位改动带来的副作用。

问题 2：为什么测试集要版本化？

因为业务和系统会变，样例也会变。版本化后，才能知道某个分数对应哪一批题、哪一版规则、哪一个 Prompt。这样历史结果才可追溯，回归测试也能持续做。

问题 3：评分标准怎么避免主观？

把 Rubric 写成可操作的规则，明确 0 分、3 分、5 分分别意味着什么，并尽量配具体例子。必要时让多人标注，检查一致性，再把争议样例补进标准里。

问题 4：如何把 Evals 接到上线流程里？

把评估设成发布门禁。每次改 Prompt、模型、检索、工具或护栏前，都先跑回归测试。没过线不能发布，过了线才进入灰度或正式环境。

问题 5：这个体系里最值钱的数据是什么？

最值钱的是失败样例、人工标注和回流结果。成功样例能看上限，失败样例才能看问题在哪里；人工反馈能把主观判断变成稳定规则。

15 · 练习和速查

最后记住一条主线：测试集、评分标准、对比、回流

这节课学完，应该能把“我觉得变好了”改成“我用什么样例、什么标准、比出了什么提升”。

练习任务 Practice

1为 PRD Agent 设计 5 个评估维度。
2写 3 条失败样例，并给出失败原因。
3设计一次 Prompt A/B 测试。
4列出测试集来源和版本管理方式。
5说明如何把人工反馈回流到评估集。

一页速查卡 Cheatsheet

测固定测试集，保证可比。
标写清评分标准，保证一致。
比比较版本，证明改进。
析分析失败，找根因。
回失败样例回流到题集和规则。
门评估结果做发布门禁。

面试项目表达模板 interview-script.md

我会把 Evals 设计成四层：

第一层是数据层，准备固定测试集，覆盖常见、异常、边界和高风险样例。
第二层是标准层，写清楚 Rubric，定义完整性、事实性、安全性和可执行性。
第三层是对比层，比较 Prompt、模型、检索、工具和护栏不同版本的效果。
第四层是闭环层，把失败样例和人工反馈回流到测试集、规则和上线门禁里。

这样做的目的不是得到一个分数，而是证明 AI 系统真的变好了，并且知道它为什么变好。