# Evals, explained
**作者**: Lotte
**日期**: 2026-05-19T15:09:22.000Z
**来源**: [https://x.com/lotte_verheyden/status/2056754091817361670](https://x.com/lotte_verheyden/status/2056754091817361670)
---
This is one piece of a series we’re publishing as part of the Langfuse Academy, where we walk through the full AI engineering lifecycle. If you’re new to the series,The AI Engineering Loop is the best place to start.
## A short recap of the AI Engineering Loop
The AI Engineering Loop is how teams continuously improve AI systems. It connects what’s happening in production (tracing, monitoring) to structured iteration during development (datasets, experiments, evaluation). Each shipped improvement produces new data, and teams loop through this process continuously.
You can read more on this here.
# How evaluation fits into the loop
Offline evaluation is the step in the loop between running an experiment and shipping a change. You have a dataset, you have run your application against it, and now you need to judge whether the outputs are good.
## How evaluation typically evolves
Most of the time, you start by manually reviewing outputs to build intuition for what good and bad look like in your application. From there, you identify specific failure modes worth checking for. Once you can define them precisely, you automate with dedicated evaluators.
The rest of this page covers the different kinds of evaluation in detail. In practice, you'll likely end up combining all of them. But the path to a well-functioning automated evaluation setup almost always starts from manual review.
Manual evaluation is not a one-and-done step. Good production setups incorporate continuous review by human experts to catch new failure modes and keep automated evaluators calibrated.
# Evaluation methods
There are three main ways to evaluate: manually, with code, or with an LLM. Each is suited to different kinds of quality checks.
## Manual evaluation
Manual evaluation is the process of manually looking at outputs and scoring it/writing down your thoughts on its quality.
This is an important process, reading outputs builds an understanding of what your application actually does, where it struggles, and what "good" looks like for your specific use case. That understanding is what tells you which automated evaluators to build and how to define their criteria later on. Teams that skip this step and jump straight to automated evaluation often end up measuring things that don't matter.
Manual evaluation also produces human labels that serve as ground truth for validating automated evaluators later.
## Code-based evaluation
Code-based evaluators check properties that can be verified with deterministic logic. They are fast, cheap, and produce the same result every time.
Some example checks where code-based evaluators are a natural fit:
- The output is valid JSON or follows a required schema
- The output contains (or does not contain) specific keywords or patterns
- The output stays within a length limit
- The generated SQL executes without errors
Their limitation is that they cannot assess meaning. A code-based evaluator can check that an output contains the word "refund," but it cannot check whether the output correctly explains the refund policy.
## LLM-as-a-judge
An LLM-as-a-judge evaluator uses a language model to score outputs. It is required to overcome the core issue that quality of AI Applications/Agents depends on grading the quality of a text output.
This is the right method for qualities that require understanding language: whether a response is relevant to the question, whether the tone matches the intended audience, whether a summary captures the key points of the source material, etc.
LLM judges are imperfect and easy to get wrong. This means:
- A model does not automatically grade things as a human expert would as they do not have the context of the expert
- They need calibration against human preferences to verify they are measuring what you think they are measuring
- They can share blind spots with your application's LLM, especially when the same model family is used for both
These limitations aren't reasons to avoid LLM judges. An LLM judge that has been calibrated against human labels and is backed by code-based checks is a reliable evaluator.
# Reference-based vs reference-free evaluators
Both code-based and LLM-as-a-judge evaluators can be either reference-based or reference-free. A reference-based evaluator compares the output against a predefined expected output, like a correct answer or a golden response. A reference-free evaluator assesses the output on its own, without needing a ground truth to compare against.
The advantage of reference-free evaluators is that they can be applied to unseen production data, while reference-based evaluators always need a pre-defined reference response.
# In practice
## When to set up evaluators
As mentioned above, you always start by manually reviewing. Once you have done that, the question then becomes: should you set up an automated evaluator for what you found?
Ask yourself whether the issue is a one-time fix or a generalization problem. If a simple prompt change resolves it, just make the change, there's no need for an evaluator. But if you can clearly identify a failure mode that you want to test for repeatedly across different inputs, that's when setting up an evaluator makes sense.
## What should you evaluate?
Generic qualities like "helpfulness" or "quality" are tempting starting points, but they rarely produce useful signal. An evaluator that checks a vague criterion will give vague results. The more precisely you can define what "good" or "bad" looks like for your application, the more useful your evaluators will be.
One practical recommendation: prefer binary scores (pass/fail) over graded scales (1-5) when designing evaluators. Binary scores force a clear definition of what separates acceptable from unacceptable. Graded scales introduce ambiguity about what a 3 means versus a 4, which makes scores harder to interpret and less consistent across evaluators and over time.
## Combining evaluation methods
Each quality you care about gets its own evaluator.
Most mature evaluation setups use all three evaluation methods. Together, they give you a view on overall quality of your application.
# Where to start
Start with manual review, then automate only the checks you need to run repeatedly.
1. Review outputs manually to build intuition for what good and bad look like in your application.
2. Write down the specific failure modes you want to catch and define them as clearly as possible.
3. Set up an automated evaluator only when you need to test that failure mode repeatedly across many inputs or over time.
# What comes next
If the results are good enough, you can ship the change. Once it is live, the loop starts again: the updated system produces new traces, new monitoring signals, and new opportunities to improve.
Some evaluators should also move beyond offline experiments. Reference-free evaluators, user feedback signals, and other production-safe checks can be applied to live traffic to confirm that quality in production matches what you saw before deployment.
If production behavior matches expectations, you can keep scaling with more confidence. If it does not, capture those cases in traces, turn them into dataset items, and run the next round of experiments. That is how you close the loop.
## 相关链接
- [Lotte](https://x.com/lotte_verheyden)
- [@lotte_verheyden](https://x.com/lotte_verheyden)
- [23K](https://x.com/lotte_verheyden/status/2056754091817361670/analytics)
- [Langfuse Academy](https://langfuse.com/academy)
- [The AI Engineering Loop](https://langfuse.com/academy/ai-engineering-loop)
- [here](https://langfuse.com/academy/ai-engineering-loop)
- [all three evaluation methods](https://langfuse.com/academy/evaluate#three-kinds-of-evaluation)
- [Review outputs manually](https://langfuse.com/academy/evaluate#how-evaluation-typically-evolves)
- [traces](https://langfuse.com/academy/tracing)
- [monitoring](https://langfuse.com/academy/monitoring)
- [dataset](https://langfuse.com/academy/datasets)
- [experiments](https://langfuse.com/academy/experiments)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:09 PM · May 19, 2026](https://x.com/lotte_verheyden/status/2056754091817361670)
- [23.6K Views](https://x.com/lotte_verheyden/status/2056754091817361670/analytics)
- [View quotes](https://x.com/lotte_verheyden/status/2056754091817361670/quotes)
---
*导出时间: 2026/5/20 10:20:04*
---
## 中文翻译
# Evals，详解
**作者**: Lotte
**日期**: 2026-05-19T15:09:22.000Z
**来源**: [https://x.com/lotte_verheyden/status/2056754091817361670](https://x.com/lotte_verheyden/status/2056754091817361670)
---
这是我们作为 Langfuse 学院一部分发布的系列文章之一，在该系列中，我们将完整梳理 AI 工程全生命周期。如果你刚接触这个系列，[The AI Engineering Loop](https://langfuse.com/academy/ai-engineering-loop) 是最佳起点。
## AI 工程循环简述
AI 工程循环是团队持续改进 AI 系统的方式。它将生产环境中发生的情况（追踪、监控）与开发过程中的结构化迭代（数据集、实验、评估）连接起来。每次发布的改进都会产生新数据，团队在这个循环中不断往复。
你可以[在这里](https://langfuse.com/academy/ai-engineering-loop)阅读更多相关内容。
# 评估如何融入循环
离线评估是循环中介于“运行实验”和“发布更改”之间的步骤。此时你已经有了数据集，并针对它运行了应用程序，现在需要判断输出结果是否达标。
## 评估通常如何演进
大多数情况下，你会先通过人工审查输出来建立直觉，了解你的应用中什么是好的，什么是坏的。在此基础上，你会识别出值得检查的具体失败模式。一旦你能精确定义它们，就可以用专门的评估器来实现自动化。
本页的其余部分将详细介绍不同类型的评估。在实践中，你可能会结合使用所有这些方法。但建立一个运行良好的自动化评估体系，几乎总是从人工审查开始的。
人工评估不是一次性步骤。良好的生产环境设置会包含人类专家的持续审查，以捕捉新的失败模式，并保持自动化评估器的校准状态。
# 评估方法
主要有三种评估方式：人工评估、基于代码的评估，或使用 LLM 进行评估。每种都适用于不同类型的质量检查。
## 人工评估
人工评估是指手动查看输出，并对其打分/记录你对质量的看法的过程。
这是一个重要的过程，阅读输出能让你深入理解你的应用实际在做什么、它在哪些方面存在困难，以及针对你的特定用例，“好”的标准是什么。这种理解能告诉你后续应该构建哪些自动化评估器，以及如何定义它们的标准。跳过这一步直接跳到自动化评估的团队，往往最终都在衡量无关紧要的事情。
人工评估还会产生人类标记（Human labels），这些标记将作为验证自动化评估器的基本真值。
## 基于代码的评估
基于代码的评估器检查可以用确定性逻辑验证的属性。它们速度快、成本低，并且每次产生的结果都一致。
在一些示例检查中，基于代码的评估器是天然的最佳选择：
- 输出是有效的 JSON 或遵循所需的架构
- 输出包含（或不包含）特定关键词或模式
- 输出保持在长度限制内
- 生成的 SQL 可以正确执行
它们的局限性在于无法评估语义。基于代码的评估器可以检查输出是否包含“退款”一词，但无法检查输出是否正确解释了退款政策。
## LLM 即评判者 (LLM-as-a-judge)
LLM 评判者使用语言模型对输出进行评分。为了解决核心问题——即 AI 应用/代理的质量取决于对文本输出质量的评分——这种方法是必不可少的。
对于需要理解语言质量的指标，这是正确的方法：例如回答是否与问题相关、语气是否匹配目标受众、摘要是否抓住了源材料的关键点等。
LLM 评判者并不完美，且很容易用错。这意味着：
- 模型不会像人类专家那样自动评分，因为他们不具备专家的上下文
- 它们需要根据人类偏好进行校准，以验证它们测量的确实是你认为它们正在测量的东西
- 它们可能与你的应用 LLM 存在共同的盲点，尤其是当两者使用同一模型家族时
这些局限性并不是避免使用 LLM 评判者的理由。一个经过人类标签校准、并由基于代码的检查作为支撑的 LLM 评判者，是一个可靠的评估器。
# 有参考 vs 无参考评估器
基于代码的和 LLM 评判者这两类评估器，都可以是基于参考的或无参考的。基于参考的评估器会将输出与预定义的预期输出（如正确答案或黄金回答）进行比较。无参考的评估器则独立评估输出，无需对比基本真值。
无参考评估器的优势在于它们可以应用于未见过的生产数据，而基于参考的评估器则始终需要预定义的参考回答。
# 实践指南
## 何时设置评估器
如上所述，你始终要从人工审查开始。完成这一步后，问题就变成了：你是否应该为你发现的问题设置一个自动化评估器？
问自己，这个问题是一次性修复还是一个泛化问题。如果简单的提示词更改就能解决，那就直接改，没必要设置评估器。但如果你能清晰地识别出一个需要在不同输入中反复测试的失败模式，那就是设置评估器的时候了。
## 你应该评估什么？
像“有帮助”或“质量”这样通用的指标虽然很诱人，但很少能产生有效的信号。检查模糊标准的评估器会给出模糊的结果。你能越精确地定义应用中什么是“好”或“坏”，你的评估器就会越有用。
一个实用的建议：在设计评估器时，优先使用二元评分（通过/失败），而不是分级量表（1-5 分）。二元评分迫使你明确定义可接受与不可接受之间的界限。分级量表则会导致 3 分和 4 分的含义产生歧义，这使得分数更难解释，且在不同评估器和不同时间段之间的一致性更差。
## 组合评估方法
你在乎的每一个质量指标都应拥有自己的评估器。
大多数成熟的评估设置都会使用所有三种评估方法。它们共同为你提供应用整体质量的视图。
# 从哪里开始
从人工审查开始，然后仅自动化你需要反复运行的检查。
1. 人工审查输出，建立对应用中好坏表现的直觉。
2. 记录下你想要捕捉的具体失败模式，并尽可能清晰地定义它们。
3. 只有当你需要针对许多输入或随着时间的推移反复测试该失败模式时，才设置自动化评估器。
# 下一步做什么
如果结果足够好，你就可以发布更改。一旦上线，循环重新开始：更新后的系统会产生新的追踪记录、新的监控信号，以及新的改进机会。
部分评估器还应超越离线实验。无参考评估器、用户反馈信号和其他生产级检查可以应用于实时流量，以确认生产环境的质量是否与部署前所见一致。
如果生产行为符合预期，你可以更有信心地继续扩展。如果不符合，则在追踪记录中捕获这些案例，将其转化为数据集项，并运行下一轮实验。这就是你闭环的方式。
## 相关链接
- [Lotte](https://x.com/lotte_verheyden)
- [@lotte_verheyden](https://x.com/lotte_verheyden)
- [23K](https://x.com/lotte_verheyden/status/2056754091817361670/analytics)
- [Langfuse Academy](https://langfuse.com/academy)
- [The AI Engineering Loop](https://langfuse.com/academy/ai-engineering-loop)
- [here](https://langfuse.com/academy/ai-engineering-loop)
- [all three evaluation methods](https://langfuse.com/academy/evaluate#three-kinds-of-evaluation)
- [Review outputs manually](https://langfuse.com/academy/evaluate#how-evaluation-typically-evolves)
- [traces](https://langfuse.com/academy/tracing)
- [monitoring](https://langfuse.com/academy/monitoring)
- [dataset](https://langfuse.com/academy/datasets)
- [experiments](https://langfuse.com/academy/experiments)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:09 PM · May 19, 2026](https://x.com/lotte_verheyden/status/2056754091817361670)
- [23.6K Views](https://x.com/lotte_verheyden/status/2056754091817361670/analytics)
- [View quotes](https://x.com/lotte_verheyden/status/2056754091817361670/quotes)
---
*导出时间: 2026/5/20 10:20:04*