AI Agent 评估应该怎么做

对于评估不是简单的让地让 AI Judge 打个 1-5 分，这样做显然效果会很差，评估体系，评估方法，甚至评估标准都没明确说明， 即使是再牛逼的AI Judge也无法做好整个评估体系。

用一个例子说明。

假设你做一个 RAG 客服机器人，用户问：

我买的耳机用了 20 天，左耳没声音了，可以退货还是只能维修？

知识库里有两条规则：

1. 商品签收后 7 天内可无理由退货。
2. 7 天后、保修期内出现质量问题，可申请维修或换货。

模型回答 A：

你已经使用了 20 天，超过 7 天无理由退货期限。
如果左耳没声音属于质量问题，可以申请维修或换货。
建议你提交售后申请，并提供订单号和故障说明。

模型回答 B：

可以退货。耳机质量有问题的话，一般都可以直接退款。

模型回答 C：

根据政策，你的耳机已经超过 7 天无理由退货期限。
如果左耳没声音属于质量问题，可以申请维修或换货。
另外，我们会补偿你一张 50 元优惠券。

如果只用一个 AI Judge 打分问：

这个回答好不好？

可能会出现主观上觉得 C 不错，安抚了用户，并且有理有据，但是事实上编造了“50 元优惠券”。所以我们应该把这个问题拆细了看。

比如我们可以拆成这几类问题：

这个回答有没有违反硬性规则？       → deterministic check
它有没有覆盖标准答案里的关键点？   → reference-based evaluation
它有没有编造上下文没有的内容？     → faithfulness / groundedness
它整体是否有帮助、清晰、符合语气？ → AI judge
它比另一个版本更好吗？             → pairwise comparison
它有没有线上真实用户认可？         → user feedback / human audit

也就是说：

开放式任务评估 = 硬规则检查 + 事实检查 + 语义覆盖 + 主观质量评分 + 版本对比 + 人工抽检

那么我们再来给上面的回答评价，结果可信度就会高很多：

这组体系，主要是回答了什么是好，以及好在哪里。

上面也说明了，评估在与怎么定义好与坏，好与坏又是由一系列的指标定义的，所以这一节来讲讲怎么拆指标。

先评估能客观验证的部分，这部分可以用代码进行校验。

输出是否是合法 JSON？
是否包含必须字段？
是否调用了正确 tool？
是否调用了禁止 tool？
是否超过 token 限制？
是否包含敏感词？
是否引用了不存在的 source？
是否返回了空答案？

例子：你要求模型输出：

{
  "answer": "...",
  "citations": ["doc_1", "doc_2"],
  "confidence": 0.83
}

那第一步直接校验：

JSON parse 是否成功
answer 是否非空
citations 是否存在
confidence 是否在 0 到 1 之间
citations 是否真的来自检索结果

这个阶段不判断“回答是否优雅”，只判断格式和流程是否合规。

这层用于判断模型有没有覆盖标准答案里的关键点。比如可以给每个测试 case 写一个 reference answer，或者更工程化一点，写成 required facts。例如：

{
  "query": "用了 20 天耳机坏了可以退吗？",
  "required_facts": [
    "超过 7 天无理由退货期限",
    "质量问题可申请维修或换货",
    "需要提交售后申请"
  ],
  "forbidden_claims": [
    "可以直接退款",
    "一定可以退货",
    "补偿优惠券"
  ]
}

然后评估：

required_facts_coverage = 覆盖了几个必要事实
forbidden_claims_count = 出现了几个禁止说法

比如有这么几个回答：

这样你就能区分：

模型说的每一句事实，是否都能被 context 支持？

还是刚才的回答 C：

根据政策，你的耳机已经超过 7 天无理由退货期限。
如果左耳没声音属于质量问题，可以申请维修或换货。
另外，我们会补偿你一张 50 元优惠券。

前两句有 context 支持，最后一句没有。

你可以让 AI Judge 做 claim-level 检查：

Context:
1. 商品签收后 7 天内可无理由退货。
2. 7 天后、保修期内出现质量问题，可申请维修或换货。

Answer:
根据政策，你的耳机已经超过 7 天无理由退货期限。
如果左耳没声音属于质量问题，可以申请维修或换货。
另外，我们会补偿你一张 50 元优惠券。

请逐条抽取 Answer 中的事实声明，并判断每条是否被 Context 支持。
输出：
- claim
- supported: true/false
- evidence

可能输出：

[
  {
    "claim": "超过 7 天无理由退货期限",
    "supported": true,
    "evidence": "商品签收后 7 天内可无理由退货"
  },
  {
    "claim": "质量问题可申请维修或换货",
    "supported": true,
    "evidence": "7 天后、保修期内出现质量问题，可申请维修或换货"
  },
  {
    "claim": "会补偿 50 元优惠券",
    "supported": false,
    "evidence": null
  }
]

这个比问“回答是否 grounded，打 1-5 分”更稳，因为它把判断拆到了事实声明级别。

有些维度没法完全用代码判断，比如：

是否有帮助？
是否解释清楚？
是否啰嗦？
是否符合品牌语气？
是否安抚了用户情绪？
是否给了下一步行动？

这时候主要靠 AI Judge ，但 judge prompt 必须明确标准。使用 AI judge 时要说明任务、评价标准、评分系统；而且分类式评分通常比连续数值评分更可靠。

例如你可以不要让它打 0.73 分，而是让它分类：

请评估回答是否满足“客服可上线标准”。

评价维度：
1. 是否直接回答用户问题
2. 是否给出明确下一步
3. 是否语气专业、不过度承诺
4. 是否没有多余营销话术

输出：
- pass / fail
- failed_dimensions
- reason

比如回答 A：

{
  "pass": true,
  "failed_dimensions": [],
  "reason": "回答直接说明不能无理由退货，但可申请维修或换货，并给出提交售后申请的下一步。"
}

回答 B：

{
  "pass": false,
  "failed_dimensions": ["不过度承诺", "政策准确性"],
  "reason": "回答承诺可以退货/退款，但知识库只支持维修或换货。"
}

注意：AI Judge 适合判断“软质量”，但不应该替代前面的硬规则和事实检查。

这层不是判断一个回答绝对好不好，而是判断：

Prompt v2 是否比 Prompt v1 更好？
RAG 策略 B 是否比 RAG 策略 A 更好？
模型 B 是否比模型 A 更适合这个场景？

例如你在优化 prompt。

用户问题：

我买的耳机用了 20 天，左耳没声音了，可以退货还是只能维修？

Prompt v1 输出：

超过 7 天一般不能退货，可以联系售后。

Prompt v2 输出：

你已经超过 7 天无理由退货期限，因此通常不能直接退货。
如果左耳没声音属于质量问题，可以申请维修或换货。
建议你提交售后申请，并附上订单号和故障说明。

Pairwise judge：

在不编造政策的前提下，哪个回答更适合作为客服回复？
A: ...
B: ...
输出 winner: A/B/tie，并说明原因。

结果：

{
  "winner": "B",
  "reason": "B 同时说明了退货限制、质量问题处理方式和下一步操作，比 A 更完整。"
}

但是它有一个限制：
B 比 A 好，不代表 B 一定可以上线。

所以你还需要绝对指标，除了上面所说的指标以外还可以结合 ai agent工程化用到的指标：tool call 成功/准确率、延迟情况、用户差评率等。

AI 系统评估不能只看最终答案，也不能只靠一个总分。你要把系统拆成组件，把“好回答”拆成明确评价标准和评分标准，再用多套评价数据覆盖真实分布、高风险场景、历史 bad case 和越界输入。

所以评估 AI Agent Pipeline 不是一个“打分脚本”，而是 AI 应用的质量控制系统。可以理解为：

Evaluation Pipeline = AI Agent 的 CI/CD 质量门禁 + 回归测试 + 线上质量监控 + bad case 归因系统

真实 AI 应用不是一个单模型调用，而是一条链路。比如要做一个简历 PDF 提取当前雇主：

Step 1: 从 PDF 提取文本
Step 2: 从文本中提取当前雇主

如果最终雇主提取错了，原因可能是：

PDF → Text 解析错了
Text → Employer 抽取错了

如果只看最终结果，你不知道系统失败在哪一步。

假设我们 AI Agent 整个流程是这样：

User Query
  ↓
Intent Detection
  ↓
Query Rewrite
  ↓
Retrieval / Tool Selection
  ↓
Tool Call
  ↓
Context Assembly
  ↓
Final Answer Generation
  ↓
Guardrail / Safety Check
  ↓
Response

那么应该分别评估：

这样你才能做故障归因。例如用户问：

我的订单 12345 为什么退款失败？

Agent 最终回答错了，你要知道到底是：

没有识别成 refund_failure_query
没有调用 order_refund_status 工具
调用工具时 order_id 参数错了
工具返回了正确结果，但模型解释错了
模型回答正确，但安全策略误拦截了

如果没有组件级评估，你只能看到“最后错了”，无法知道该改 Prompt、改 Retriever、改 Tool Schema，还是改业务逻辑。

创建 guideline ，不仅要定义应用应该做什么，也要定义它不应该做什么。比如客服机器人是否应该回答和产品无关的选举问题？如果不应该，就要定义什么是 out-of-scope，怎么检测，以及应该如何回复。

首先我们要明确一点：正确答案不等于好答案。模型回答“你非常不适合这份工作”可能事实上是正确的，但它不是一个好回答，因为它没有帮助用户理解差距，也没有告诉用户如何改进。一个好回答应该解释职位要求和候选人背景之间的差距，并说明候选人可以怎么弥补这些差距。

这句话对 AI 应用评估很关键：

Correct ≠ Good

再来一些例子比如：

事实正确，但语气伤人
事实正确，但没有下一步建议
事实正确，但没有引用依据
事实正确，但太长，用户看不懂
事实正确，但违反业务策略
事实正确，但暴露内部信息

除此之外还要让模型明白 should do 和 shouldn’t do，guideline 不仅要定义应用应该做什么，也要定义它不应该做什么。比如客服机器人是否应该回答和产品无关的问题；如果不应该，就要定义哪些输入是 out-of-scope、怎么检测、怎么响应。

很多团队只写正向要求：

回答要准确
回答要有帮助
回答要简洁

但没有写负向边界：

不能编造政策
不能承诺退款
不能提供法律建议
不能回答产品无关问题
不能暴露内部 SOP
不能执行高风险写操作
不能在缺少订单号时查询订单
不能把用户引导到不存在的流程

结果模型出了问题之后，团队才补规则。

一个好的 guideline 应该先把边界写清楚：

比如客服应用的三个常见 criteria：

1. Relevance：回答是否和用户问题相关
2. Factual consistency：回答是否和上下文事实一致
3. Safety：回答是否安全、无毒、有边界

也就是说，一个好回答至少要相关、和上下文事实一致，并且不含有害内容。那么这些标准其实和业务本身有关的。一个比较完整的 Agent evaluation criteria 可以是：

为了形成 criteria，可以先拿一些测试 query，最好是真实用户 query；对每个 query 生成多个 response，可以人工写，也可以用 AI 生成，然后判断哪些好、哪些坏。一般可以这么做：

收集真实 query
  ↓
生成多个候选回答
  ↓
人工判断好坏
  ↓
归纳坏回答类型
  ↓
把坏回答类型变成 criteria
  ↓
把 criteria 写成 rubric

定义 criteria 还不够，还要定义评分标准，也就是 rubric。每个 criterion 都要选择评分系统，可以是二分类 0/1、1 到 5、0 到 1，或者其他形式。比如评估回答是否和上下文一致，有的团队用 0/1，有的团队用三值：contradiction、entailment、neutral。选择哪种评分方式取决于你的数据和需求。

选择哪种评分体系取决于数据和需求。然后要为每个分数写清楚样例，并让人类验证 rubric 是否容易理解。

例如你要评估客服 Agent 的回答是否忠实于知识库，可以这样定义：

对应例子：

Context:
7 天内可无理由退货。
7 天后质量问题可维修或换货。

Answer A:
你已超过 7 天无理由退货期限。如果属于质量问题，可以申请维修或换货。
Score: 5

Answer B:
你已超过 7 天，但可以直接退款。
Score: 2

Answer C:
你可以直接退款，并获得 50 元补偿券。
Score: 1

最后我们这套体系需要标注的评估数据来评估系统的每个组件和每个 criterion。能用真实生产数据最好；如果应用天然有标签，就直接利用；如果没有，可以用人类或 AI 标注。

数据不是只给最终回答用的，很多人构建 eval set 时只写：

{
  "query": "...",
  "reference_answer": "..."
}

这对简单问答够用，但对 Agent 不够。因为 Agent 有很多中间组件：

intent detection
query rewrite
retrieval
rerank
tool selection
tool args
planning
final answer
safety check

所以 eval data 也应该包含组件级标注。例如：

{
  "case_id": "refund_001",
  "user_query": "我的耳机用了 20 天坏了，可以退吗？",
  "expected_intent": "after_sales_policy",
  "gold_documents": ["return_policy_v3", "warranty_policy_v2"],
  "expected_tool_calls": [
    {
      "tool": "get_order_status",
      "required": false
    }
  ],
  "required_facts": [
    "超过 7 天无理由退货期限",
    "质量问题可维修或换货"
  ],
  "forbidden_claims": [
    "可以直接退款",
    "补偿优惠券",
    "一定可以退货"
  ],
  "reference_answer": "超过 7 天无理由退货期限，不能直接无理由退货。如果属于质量问题，可以申请维修或换货，并提交售后申请。",
  "tags": ["refund", "after_sales", "high_risk"]
}

这样你就可以分别评估：

intent 是否正确
retrieval 是否命中 policy
tool 是否该调用
最终回答是否覆盖 required facts
是否出现 forbidden claims

把数据拆成多个 subset，然后分别看系统在每个 subset 上的表现。这样可以避免偏差、帮助 debug、发现改进方向。比如对于某个场景如果你只看整体：

overall task_success_rate = 88%

你可能觉得系统不错，但切开之后可能是：

普通 FAQ：95%
退款政策：72%
多轮订单查询：68%
英文输入：91%
中英混合输入：61%
prompt injection：35%

这时候整体 88% 没意义，因为关键风险场景很差。

引用 OpenAI 的粗略估计：如果你想以 95% 置信度判断一个系统比另一个系统好，能检测到的差异越小，需要的样本越多。大致是：

作为参考，Eleuther 的 lm-evaluation-harness 里 benchmark 的中位样本数约 1,000，平均约 2,159；Inverse Scaling Prize 组织者建议 300 是绝对最低值，更希望至少 1,000，尤其当样本是合成生成的。

不用一开始就追求 10,000 条 eval case。可以分层：

开发调试集：30-50 条
日常回归集：200-500 条
发布前主评估集：1,000+ 条
核心高风险集：100-300 条，但人工精标
线上抽样评估：持续积累

如果你只是想快速判断 prompt_v2 是否明显比 prompt_v1 好，几十到几百条可能够用。

这一部分主要是我想要把整个评价体系设计成一个 闭环 workflow，分成 5 个阶段：

Stage 0：定义评估标准
Stage 1：离线评估
Stage 2：发布前门禁
Stage 3：线上评估 / A/B Test
Stage 4：线上数据回流到离线评估集

由这 5 个阶段构建成一个循环：

离线评估：用可控数据判断“能不能发”
    ↓
灰度 / A/B：用真实流量判断“上线后是否真的更好”
    ↓
线上反馈与日志：发现真实 bad case / good case
    ↓
人工或 AI 标注：沉淀成新的离线评估集
    ↓
下一轮 prompt / RAG / agent / model 迭代

在离线和线上之前，必须先定义同一套 criteria。比如你做的是 AI Agent / RAG 客服系统，criteria 可以是：

首先就是和上面提到一样，离线评估数据集的构建，要做到离线数据集分层和细化，比如分成几类：

然后就是离线评估打分 / 分类。

第一层：确定性检查，能用代码判断的，不要交给 LLM。比如 JSON schema 是否合法；

第二层：参考答案 / 必要事实评估，用于判断回答是否覆盖关键点；

第三层：AI Judge / 人工评估，用于开放式质量；

最后就是离线评估输出，并且输出详细的subset结果，而不是一个总分。

离线评估跑完后，不是看“总分高一点就发”，而是设 release gate。

例如：

必须满足：
- overall task_success_rate >= 85%
- high_risk_policy_pass_rate >= 99%
- forbidden_claim_rate <= 0.5%
- tool_call_correct_rate >= 98%
- faithfulness_avg >= 4.5
- known_bad_cases_pass_rate = 100%
- p95 latency <= 5s
- cost_per_task <= $0.01

这里有一个重点：

known_bad_cases_pass_rate 最好要求 100%。

历史上踩过的坑，不能回归。

如果你是做 prompt 迭代，发布前可以这样比较：

虽然 candidate 总体更好，但 high-risk pass 下降了，所以不能直接上线。

这一部分可以包括线上用户打分：点赞 / 点踩。建议点踩时让用户选择原因：

- 没有回答我的问题
- 回答不准确
- 信息过时
- 编造内容
- 太啰嗦
- 没有给下一步
- 工具结果错误
- 其他

点赞也可以收集轻量原因：

- 解决了我的问题
- 解释清楚
- 推荐有用
- 操作步骤明确

还可以做线上隐式反馈 implicit feedback，比如下面信号：

A/B test 的价值是判断线上真实效果。比如对于 AI Agent，A/B test 应该这样设计：

Control：当前线上版本
Treatment：新 prompt / 新 model / 新 RAG 策略 / 新 agent planner

一次实验尽量只改一个主要变量，否则无法归因。具体设计应该要根据当前的任务和需求而定。

因为真实的例子更有利于构建我们的评估体系，并且只收集好的例子不够，评价体系最值钱的通常是 bad cases 和 hard cases，所以总体应该包括：

抽样真实好例子 + 真实坏例子 + 边界例子，经过验证后，构建和更新离线评估数据集。

抽取完这些线上的例子之后，就可以构建数据回流流程，可以是这样：

线上日志采集
  ↓
自动打标签：点赞/点踩、转人工、投诉、tool error、latency、cost
  ↓
规则过滤：去 PII、去重、去低质量日志
  ↓
样本分桶：good / bad / hard / high-risk / out-of-scope
  ↓
AI 预标注：required facts、错误类型、风险类型
  ↓
人工复核：重点看 high-risk、bad、ambiguous
  ↓
写入离线评估集
  ↓
版本化：eval_dataset_vN

《AI Engineering Building Applications with Foundation Models》