手工测评很快会遇到瓶颈。
20 个案例、两个版本、三个模型，每个案例再运行三次，已经是 360 条结果。如果还要逐条复制、打分、记录成本和整理坏案例，团队很难把测评变成日常工作。
工具确实能解决这个问题，但前提是先分清它替你做哪一步。
测评中的自动化大致分为三类：
- 批量运行；
- 自动评分；
- 记录、分析和回流。
工具可以让这些动作更快，不能替团队决定什么叫成功。
先自动化重复劳动，不要自动化模糊标准
如果团队还没有统一成功标准，直接引入平台，常见结果是：
- 可以批量跑几百个案例，却不知道分数代表什么；
- 配置了十几个指标，却没有任何一个能决定是否发布；
- AI 裁判自动给分，但产品和业务专家并不认可；
- 保存了大量 Trace，却没有人知道哪些失败值得回归。
所以，适合自动化的起点不是“我们准备做 Eval”，而是：
- 已经手工跑通过至少一次闭环；
- 用例结构基本稳定；
- 评分标准大体一致；
- 已经找到最慢、最贵或最容易出错的环节。
如果最耗时的是复制输入和收集结果，先自动化批量执行。如果瓶颈是内容评分，先建立 AI 裁判。如果问题是线上失败无法复现，再增加 Trace 和数据回流。
工具选型应该从当前瓶颈开始，不是从功能清单开始。
能写成规则的，不要先交给大模型
确定性检查是最便宜、最稳定的一层。
常见对象包括：
- JSON、XML 或 Markdown 结构；
- 必填字段与数值范围；
- 文件是否存在、是否可打开；
- 工具名称和参数；
- 数据库或业务状态变化；
- 禁止词、敏感字段和权限规则；
- 时延、Token 和调用次数。
这类检查可以用普通代码、测试框架或 Eval 工具中的断言完成。
例如，一个 Skill 声称生成了报告。规则可以直接检查文件路径、格式和大小，而不需要让另一个大模型阅读“我已经完成”的回复后猜测。
确定性检查的优势是结果可重复、失败容易定位。它的边界也很明确：规则可以确认报告里有“风险”章节，却很难判断风险分析是否真正有价值。
因此，原则不是“代码评分优于模型评分”，而是能确定判断的部分不要引入额外不确定性。
怎样用大模型做 AI 裁判
当结果没有唯一答案时，可以让另一个大模型按照评分标准判断。
适合 AI 裁判的维度通常包括：
- 回答是否相关；
- 关键内容是否完整；
- 结论是否被材料支持；
- 表达是否清楚；
- 是否遵守指定风格或业务规则。
AI 裁判的输入至少要包含：
- 原始任务；
- 必要上下文；
- 待评分结果；
- 清晰的 Rubric；
- 分数等级或通过条件；
- 要求输出判定理由。
不要给它一句“请从 1 到 10 评分”。不同分数没有锚点时，评分很难复现。
更有效的 Rubric 会描述每一档：
| 等级 | 完整性示例 |
|---|---|
| 通过 | 覆盖全部关键目标、流程、字段、规则和验收点 |
| 部分通过 | 主体可用，但遗漏一项重要信息，需要人工补充 |
| 失败 | 多项关键信息缺失，无法供后续角色使用 |
如果目标是比较两个版本，可以让裁判在同一案例上选择 A 更好、B 更好或两者相当。为减少位置偏差，可以交换候选顺序，并隐藏版本身份。
但 AI 裁判仍然会受到篇幅、措辞、模型偏好和任务难度影响。它是一个测量工具，不是最终真相。
人工不负责全部打分，而是负责校准
完全人工评分很贵，也难以扩大规模。完全自动评分又会带来新的误判。
更实际的分工是：
- 规则检查确定性要求；
- AI 裁判处理大量开放质量；
- 人工评审负责 Gold 样本、严重失败、临界案例和评分分歧。
Gold 样本是一小批经过产品或业务专家认真判断的结果，用来检查 AI 裁判是否理解团队标准。
可以定期比较：
- AI 与人工是否给出相同通过结论；
- 分数差异集中在哪些维度；
- 哪类任务最容易误判；
- 更换评分模型或 Rubric 后，一致性是否变化。
当评分模型、任务类型或成功标准变化时，需要重新校准。AI 裁判本身也要被测评。
常见工具分别解决哪一步
下面的定位已于 2026 年 8 月 3 日根据各工具官方文档复核。工具能力仍会更新，正式选型和接入前需要再次检查版本、许可、部署方式和数据边界。
| 工具 | 更适合解决的问题 | 典型使用场景 |
|---|---|---|
| Promptfoo | 批量比较 Prompt、模型和断言 | Prompt A/B、模型矩阵、快速回归 |
| DeepEval | 在测试代码中组织 LLM 指标与回归 | 应用级 Eval、CI 检查 |
| Ragas | 评估 RAG、Agent 和工具调用质量 | 检索生成、工具准确性、目标完成 |
| Inspect | 组织数据集、Agent、工具和评分实验 | 可复现实验、沙箱与 Agent 任务评估 |
| Langfuse | 记录 Trace，并连接数据集、实验和线上评分 | 生产观测、实验比较、坏例回流 |
| Phoenix | 用代码或 LLM 评估 Trace、实验和数据集 | RAG/Agent 调试与评估分析 |
| pytest | 确定性代码、接口和状态回归 | 格式、权限、工具函数与业务不变量 |
它们不是互斥选项。
pytest 可以守住工具函数和状态不变量，Promptfoo 可以批量比较 Prompt 与模型，Langfuse 或 Phoenix 可以保存真实运行轨迹。RAG 场景再增加 Ragas 等专项指标。
选型时先问三个问题：
- 当前主要评 Prompt、RAG、Skill，还是完整 Agent？
- 当前瓶颈在运行、评分、观测，还是协作治理？
- 团队需要本地脚本、CI 回归，还是生产平台？
三种团队规模的最小组合
个人或首次试验
目标是尽快跑通闭环。
- CSV、JSON 或表格保存案例；
- 简单脚本或 Promptfoo 批量运行；
- 规则断言检查硬要求；
- 一个评分模型辅助开放质量；
- 人工复核全部失败和部分通过案例。
此时不必先建设统一平台。
小型产品团队
目标是让测评进入日常迭代。
- 数据集与 Prompt/Skill 一起版本化；
- 批量执行新旧版本和模型矩阵；
- 代码评分与 AI 裁判组合；
- 关键回归接入 CI；
- 用 Trace 工具保存失败过程；
- 统一输出版本对比和发布结论。
平台或多 Agent 团队
目标是管理多个能力和生产反馈。
- 统一 Case、Run、Score 和版本标识；
- 集中保存 Trace、Artifact 和关键状态；
- 管理评分器、人工 Gold 与校准记录；
- 建立模型、Prompt、Skill 的变更触发规则；
- 将发布门槛与线上坏例回流接入流程；
- 控制数据权限、隐私和审计。
规模变大之后，平台价值才会逐渐高于维护成本。
一张工具选型顺序表
| 当前问题 | 优先能力 | 不要先做 |
|---|---|---|
| 手工运行太慢 | 批量执行、缓存、模型矩阵 | 先搭生产观测平台 |
| 格式和状态经常错 | 代码断言、pytest | 让 AI 裁判判断文件是否存在 |
| 内容评分太慢 | Rubric、AI 裁判、人工抽检 | 直接接受模型总分 |
| 失败无法定位 | Trace、工具调用和 Artifact 记录 | 只保存最终回复 |
| 线上问题无法复现 | 生产采样、脱敏、数据集回流 | 把全部真实对话直接塞进回归集 |
| 多团队标准不一致 | Gold 样本、评分校准、Owner | 继续增加指标数量 |
真正高效的 Eval，不是工具越多越好，而是让规则、模型和人工分别处理自己擅长的判断。
最后一篇将把这些能力放进生产流程：上线前如何设门槛，上线后如何收集坏案例，以及怎样让一次失败减少未来的重复失败。
Agent 测评入门系列
- 【Eval】Agent测评不是简单给回答打分
- 【Eval】测试同学别焦虑，Eval也不是替代品
- 【Eval】第一次Eval，先干小事情
- 【Eval】测Skill，不只是盯结果
- 【Eval】分数变高，不代表版本真的变好
- 【Eval】规则、AI裁判和人工怎么成为铁三角（本文）
- 【Eval】离线全通过，上线仍会失败的原因到底是啥