Evals 到底在评什么？一文拆解 AI 评估的三种方法¶
Ch01.492 Evals 到底在评什么？一文拆解 AI 评估的三种方法¶
📊 Level ⭐⭐ | 7.1KB |
entities/evals-three-methods-of-ai-evaluation.md
Evals 到底在评什么？一文拆解 AI 评估的三种方法¶
原文：Evals 到底在评什么？一文拆解 AI 评估的三种方法 作者：Lotte Verheyden（Langfuse Product Marketing Engineer & Developer Relations） 来源：https://mp.weixin.qq.com/s/hQyh7ln5RlIjKdssnDiwSQ AI Evals 的本质：把"好不好"变成可重复判断的工程机制。
相关实体¶
- Ai Skill Skill Creator 源码拆解
- Ai Skill Metrics System
- Langsmith Trajectory Evals
- Aws Bedrock Agentcore Quality Optimization Flywheel
- Generalization Dynamics Of Lm Pre Training Jiaxin Wen 1
→ 原文存档
深度分析¶
AI Evals 将"质量判断"从主观评价转化为可重复验证的工程系统，这一转变对 AI 应用开发至关重要。 传统软件开发中，代码路径是确定的——给定相同输入，相同代码总是产生相同输出，测试可以精确验证预期行为。但 AI 系统具有概率性：同一功能可能因 prompt 措辞、模型版本、检索数据变化、工具调用结果、上下文组织方式甚至用户场景差异而表现不同。Evals 通过将质量边界转化为可运行的检查，实现了对 AI 系统输出的持续、可信、可量化的评估——这是 AI 应用工程化从"艺术"走向"科学"的关键基础设施。
三种评估方法代表了对"AI 质量"不同维度的观测能力，它们的局限性决定了组合使用的必要性。 人工评估能捕捉语义、意图、创意等机器难以量化的质量维度，但无法规模化、成本高昂且不可重复。基于代码的评估速度快、成本低、结果确定，但只能检测结构化属性（JSON 有效性、关键词存在、长度约束），无法评估语义正确性——"可以检查输出是否包含 refund，但无法判断输出是否正确解释了退款政策"。LLM-as-a-Judge 能处理语义质量判断，但需要人类偏好校准，且可能与应用 LLM 共享盲点。三种方法相互补充，缺一不可。
LLM-as-a-Judge 的核心挑战是校准而非评分能力本身。 语言模型具有对输出进行评分的能力，但它的评分标准与人类专家的期望往往存在系统性偏差——模型没有专家所拥有的领域上下文，也没有经历过人类专家在专业环境中形成的质量直觉。这意味着 LLM-as-a-Judge 的核心工程问题不是"模型能不能打分"，而是"如何用人类标注来校准模型的评分标准"，以及"如何检测模型与应用 LLM 共享的盲点"。没有经过校准的 LLM 裁判，其评分结果可能完全无法反映真实质量。
AI Engineering Loop 的闭环设计是成熟 AI 团队的区分标志。 该循环将生产环境（traces 追踪、线上监控）与开发阶段（数据集管理、实验评估、CI 门禁）串联起来，每次发布产生的新数据回流到下一轮改进。这意味着 AI 质量评估不是一次性工作，而是一个持续运营的系统工程——evals 捕捉的失败模式产生新的训练数据，更好的训练数据改进模型，改进的模型带来新的行为模式，新的行为模式又产生新的失败模式需要 evals 捕捉。这个飞轮转动得越顺畅，AI 系统的质量改进效率就越高。
无参考答案评估器打开了生产质量监控的可能性，这是 AI Evals 在工程上的重大突破。 传统评估需要预先定义"正确答案"，这在封闭测试集上是可行的，但无法应用于实时流量——生产数据是开放分布的，不可能提前准备所有可能输入的参考答案。无参考答案评估器只评估输出本身的质量属性（如格式正确性、长度合理性、是否拒绝无害请求），可以实时运行在生产流量上，确认部署后的模型行为是否与实验阶段一致，从而实现真正的生产质量漂移检测。
实践启示¶
在建立评估体系时，永远从人工审阅开始，而非直接进入自动化。 跳过人工审阅直接构建自动评估器的团队，最终衡量的往往是无关紧要的东西。正确流程是：人工审阅输出 → 建立对应用中"好"与"差"的直觉 → 识别值得自动化检查的具体失败模式 → 将失败模式精确定义为可运行的评估器。人工审阅阶段的产出（高质量标注数据）也是校准 LLM-as-a-Judge 的基准真值。
优先使用二元分数（通过/失败）而非分级量表（1-5分）来定义评估指标。 二元分数迫使团队清楚定义"可接受"与"不可接受"之间的精确边界，而分级量表引入的歧义（"3分和4分到底差在哪里？"）会降低分数的可解释性以及不同评估器之间的一致性。如果确实需要多档评分，先明确定义每个档位对应的具体条件，再将评分员的一致性校准到可接受的水平。
判断是否设置自动评估器的标准是失败模式的重复频率，而非失败本身的重要性。 "修一次就解决了"的问题不需要评估器；"会反复出现"的失败模式才值得投入工程成本构建自动化的持续监控。这个判断框架帮助团队避免两个极端：要么过度工程化（为所有问题都建评估器），要么工程不足（完全依赖人工审视）。
构建 LLM-as-a-Judge 时，必须同时配备基于代码检查的兜底机制。 单纯依赖 LLM 裁判存在评分偏差和质量盲点的风险。对于可以用确定性逻辑验证的属性（JSON 有效性、必需字段存在、输出长度限制），应优先使用代码级检查，将 LLM 裁判的调用留给真正需要语义理解的判断场景。这种分层设计既能控制成本（代码检查比 LLM 调用快且便宜），又能提升整体评估的可靠性。
建立从生产 traces 到评估改进的完整闭环机制。 当无参考答案评估器在实时流量上检测到质量下降时，应自动将偏差案例捕捉到 traces 中，标记为待人工审核，审核通过后加入评估数据集触发下一轮实验。这个机制确保了评估体系能够持续适应用户实际使用中产生的新 failure pattern，而非永远用历史数据测试一个不断进化的系统。