---
title: "Evals 到底在评什么？一文拆解 AI 评估的三种方法"
author: "Lotte Verheyden (Langfuse)"
source_url: "https://mp.weixin.qq.com/s/hQyh7ln5RlIjKdssnDiwSQ"
published_date: "2026-05-20"
feed_name: "微信公众号"
tags: [evals, llm-evaluation, llm-as-judge, langfuse, ai-engineering-loop, agent-quality]
type: article
review_value: 7
review_confidence: 8
review_recommendation: "pass"
sha256: d2100528cf1db797e3581b1e4d5c535dfd0e28ec2d9e65902abe6eb5ca734ace
---
---
# Evals 到底在评什么？一文拆解 AI 评估的三种方法
> 原文：Evals 到底在评什么？一文拆解 AI 评估的三种方法
> 作者：Lotte Verheyden（Langfuse Product Marketing Engineer & Developer Relations）
> 来源：https://mp.weixin.qq.com/s/hQyh7ln5RlIjKdssnDiwSQ
> 日期：2026年5月20日
## 核心定义
AI Evals 的本质：**把"好不好"变成可重复判断的工程机制**。
传统软件测试确定性代码路径；AI 输出具有概率性——同一功能可能因 prompt、模型、检索数据、工具调用、上下文组织或用户场景变化而表现不同。
Evals 把业务质量、安全边界、任务完成度、格式约束、推理过程和用户反馈转成可运行的检查。有些用代码判断，有些由人工标注，有些交给 LLM 裁判扩展规模。
成熟团队把 evals 放进完整循环：从生产 traces 中发现失败模式，沉淀数据集和黄金样例，用 evals 比较 prompt/模型/系统改动，通过 CI 门禁、灰度发布、线上监控和漂移检测持续回流。
**对 Agent 尤其如此：** Agent 不只生成一段文本，还会多轮规划、调用工具、读写状态、执行动作；evals 不只测最终答案，还要观察中间轨迹、工具错误、策略偏移、成本和延迟以及高风险行为。
## AI Engineering Loop
团队通过 AI Engineering Loop 持续改进 AI 系统。它把生产环境（追踪、监控）和开发阶段（数据集、实验、评估）串联起来。每次发布产生新数据，团队不断重复这个过程。
```
生产 traces → 识别失败模式 → 沉淀数据集 → 实验评估 → CI门禁/灰度发布 → 线上监控/漂移检测 → 新traces
```
## 评估演进路径
1. **先人工审阅输出**——建立对应用里什么算好、什么算差的直觉
2. **识别值得检查的具体失败模式**
3. **精确定义后，用专门评估器自动化检查**
跳过第一步、直接进入自动化的团队，最后衡量的往往是无关紧要的东西。
## 三种评估方法
### 1. 人工评估
手动查看输出、打分、写看法。
**重要性：** 阅读输出才能真正理解应用实际做了什么、在哪些地方表现不佳，以及什么才算"好"。人工评估还会产生人工标注，作为验证自动评估器的基准真值。
### 2. 基于代码的评估
检查可以用确定性逻辑验证的属性。**速度快、成本低、每次相同结果。**
适用场景：
- 输出是有效 JSON，或符合要求的 schema
- 输出包含（或不包含）特定关键词或模式
- 输出保持在长度限制内
- 生成的 SQL 可以无错误执行
**局限：** 无法评估含义。可以检查输出是否包含 "refund"，但无法判断输出是否正确解释了退款政策。
### 3. LLM-as-a-Judge
用语言模型为输出打分。适合需要理解语言的质量判断：回答是否与问题相关、语气是否匹配目标受众、摘要是否抓住关键点。
**局限：**
- 模型不会自动像人类专家一样打分——它没有专家所拥有的上下文
- 需要用人类偏好来校准，验证衡量的确实是以为在衡量的东西
- 可能与应用 LLM 共享盲点（尤其是同一模型家族时）
**结论：** 一个经过人工标注校准、并由基于代码检查兜底的 LLM 裁判，可以成为可靠的评估器。
## 基于参考答案 vs 无参考答案
| 类型 | 机制 | 优势 | 局限 |
|------|------|------|------|
| **参考答案** | 输出与预定义期望输出比较 | 精确、可量化 | 需要预先定义参考回答 |
| **无参考答案** | 只评估输出本身 | 可应用到未见过的生产数据 | 无法做精确对比 |
无参考答案评估器可应用到实时流量，确认生产质量是否与部署前一致。
## 组合评估方法
**每一种关心的质量，都应该有自己的评估器。** 成熟体系通常组合三种方法，可以让你看到应用整体质量。
## 实用建议
### 优先使用二元分数，而非分级量表
二元分数（通过/失败）迫使你清楚定义可接受和不可接受之间的分界。
分级量表（1-5）引入歧义：3分和4分到底差在哪里？这会让分数更难解释，降低不同评估器之间以及跨时间的一致性。
### 判断是否设置自动评估器
问自己：这个问题是"修一次就解决了"，还是"会反复出现"？
- **修一次就解决** → 直接修改，不需要评估器
- **会反复出现** → 适合设置评估器
### 起点永远是人工审阅
1. 人工审阅输出，建立对应用中好坏输出的直觉
2. 写下想捕捉的具体失败模式，尽可能清楚定义它们
3. 只有当需要在大量输入上或跨时间反复测试某个失败模式时，才设置自动评估器
## 闭环流程
```
人工审阅 → 定义失败模式 → 设置自动评估器 → 实验 → 发布 → 上线监控 → 新的traces → 回到人工审阅
```
无参考答案评估器 + 用户反馈信号可以应用到实时流量上，确认生产行为是否符合预期。如果不符合，就把案例捕捉到 traces 中，转成数据集条目，运行下一轮实验。
## 来源
作者 Lotte Verheyden，Langfuse（YC W23）Product Marketing Engineer & Developer Relations，比利时鲁汶大学计算机科学工程硕士。