Product evals are misunderstood. Some folks think that adding another tool, metric, or LLM-as-judge will solve the problems and save the product. But this sidesteps the core problem and avoids the real work. Evals aren’t static artifacts or quick fixes; they’re practices that apply the scientific method, eval-driven development, and AI output monitoring.人们对产品评估存在误解。有些人认为，只要增加一个工具、指标或“大模型裁判”，就能解决问题并拯救产品。但这实际上是在回避核心问题，逃避真正的工作。评估不是静态的产物或速效药，而是一种实践，它应用了科学方法、评估驱动开发以及 AI 输出监控等手段。

Building product evals is simply the scientific method in disguise. That’s the secret sauce. It’s a cycle of inquiry, experimentation, and analysis.构建产品评估本质上就是科学方法的变体，这正是其核心秘诀。它是一个包含探究、实验和分析的循环过程。

It starts with observation aka Look at The Data™. This means examining our inputs, AI outputs, and how users interact with our systems. By looking at the data, we learn where the system works well, and perhaps more crucially, where it fails. Identifying these failure modes is the starting point for meaningful improvement.首先是观察，也就是“审视数据™”。这意味着要检查我们的输入、AI 的输出以及用户与系统的交互方式。通过审视数据，我们能了解系统在哪些方面表现良好，更重要的是，了解它在哪些方面失败了。识别这些失败模式是进行有效改进的起点。

Then, we annotate some data, prioritizing problematic outputs. This means labeling samples of successes and failures to build a balanced and representative dataset. Ideally, we should have a 50:50 split of passes and fails that spans the distribution of inputs. This dataset forms the foundation for targeted evals that track performance on the issues we’ve identified.接着，我们要对部分数据进行标注，优先处理那些有问题的输出。这意味着要标记成功和失败的样本，以构建一个平衡且具有代表性的数据集。理想情况下，通过覆盖各种输入分布，我们应保持 50:50 的成功与失败比例。该数据集为针对性评估奠定了基础，让我们能够跟踪已识别问题的表现。

Next, we hypothesize why specific failures occur. Perhaps our RAG’s retrieval isn’t returning the relevant context, or maybe the model struggles to follow the complex—and sometimes conflicting—instructions. By looking at data such as retrieved documents, reasoning traces, and erroneous outputs, we can prioritize failures to fix and hypotheses to test.随后，我们要针对特定的失败原因提出假设。也许是 RAG 的检索功能没有返回相关背景信息，又或者是模型难以遵循复杂且有时相互矛盾的指令。通过查看检索到的文档、推理过程和错误的输出等数据，我们可以确定优先修复的失败点和需要验证的假设。

Then, we design and run experiments to test our hypotheses. Experiments could involve rewriting prompts, updating retrieval components, or switching to a different model. A good experiment defines the outcomes that confirm or invalidate the hypotheses. Ideally, it should also include a baseline or control condition against which to compare.之后，我们设计并运行实验来验证假设。实验可能涉及重写提示词、更新检索组件或更换不同的模型。一个好的实验会明确定义确认或否定假设的结果。理想情况下，它还应包含一个基准或对照组，以便进行比较。

Measuring outcomes and analyzing errors is often the most challenging step. Unlike casual vibe checks, this requires quantifying whether an experiment’s updates actually improved outcomes: Did accuracy increase? Were fewer defects generated? Does the new version do better in pairwise comparisons? We can’t improve outcomes if we can’t measure it.衡量结果和分析错误往往是最具挑战性的一步。与随意的“感觉检查”不同，这要求量化实验更新是否真正改善了结果：准确率提高了吗？缺陷减少了吗？新版本在两两比较中表现更好吗？如果无法衡量，就无法改进结果。

If an experiment succeeds, we apply the update; if it fails, we dig into the error analysis, refine our hypotheses, and try again. Through this iterative loop, product evals becomes the data flywheel that improves our product, reduces defects, and earns user trust.如果实验成功，我们就应用更新；如果失败，我们就深入分析错误，修正假设并再次尝试。通过这个迭代循环，产品评估就成了驱动产品改进、减少缺陷并赢得用户信任的数据飞轮。

Applying the scientific method to building AI products.将科学方法应用于 AI 产品构建。

Eval-driven development (EDD) helps us build better AI products. It’s similar to test-driven development where we write tests before implementing software that passes those tests. EDD follows the same philosophy: Before developing an AI feature, we define success criteria, via product evals, to ensure alignment and measurability from day one. Here’s a secret: Machine learning teams have practiced this for decades, where we build models and systems against validation and test sets. The ideas are similar though they have different names.评估驱动开发 (EDD) 有助于我们构建更好的 AI 产品。它类似于测试驱动开发，即在编写通过测试的软件之前先编写测试。EDD 遵循同样的理念：在开发 AI 功能之前，我们通过产品评估定义成功标准，以确保从第一天起就具备一致性和可衡量性。告诉你一个秘密：机器学习团队几十年来一直都在这样做，通过验证集和测试集来构建模型和系统。虽然名称不同，但理念是相似的。

In EDD, evals guide our development. We start by evaluating a baseline, perhaps a simple prompt, to get an initial benchmark. From then on, every prompt tweak, every system update, every iteration, is evaluated. Did simplifying the prompt improve faithfulness? Did updating retrieval increase the recall of relevant documents? Or did the update worsen performance?在 EDD 中，评估指导着我们的开发。我们首先评估基准（例如一个简单的提示词）以获得初始基准值。此后，每一次提示词调整、每一次系统更新、每一次迭代，都要进行评估。简化提示词是否提高了忠实度？更新检索是否提高了相关文档的召回率？或者这次更新是否反而降低了性能？

Because EDD provides immediate, objective feedback, we can see what’s improving and what’s not. This cycle—write evals, make changes, run evals, integrate improvements—ensures measurable progress. Instead of relying on vague, intuition-based perceptions, we build a feedback loop grounded in software engineering practices.由于 EDD 提供了即时、客观的反馈，我们可以清楚地看到哪些方面在进步，哪些没有。这个循环——编写评估、做出更改、运行评估、整合改进——确保了可衡量的进展。我们不再依赖模糊的直觉，而是建立了一个植根于软件工程实践的反馈回路。

First, write some evals; then, build systems that pass those evals.首先，编写一些评估；然后，构建能够通过这些评估的系统。

Human oversight is still needed even with automated evaluators (aka LLM-as-judge). While automated evals help scale monitoring, they can’t compensate for neglect. If we’re not actively reviewing AI outputs and customer feedback, automated evaluators won’t save our product.即使有了自动化评估器（即“大模型裁判”），仍然需要人工监督。虽然自动化评估有助于扩展监控规模，但无法弥补疏忽。如果我们不积极审查 AI 的输出和客户反馈，自动化评估器也无法拯救我们的产品。

To evaluate and monitor AI products, we typically sample outputs and annotate them for quality and defects. With enough high-quality annotations, we can calibrate automated evaluators to align with human judgment. This could mean measuring recall or precision on binary labels, or correlation when deciding between outputs via pairwise comparisons. Once properly aligned, these evaluators help scale the continuous monitoring of AI systems.为了评估和监控 AI 产品，我们通常会抽样输出并标注其质量和缺陷。通过足够高质量的标注，我们可以校准自动化评估器，使其与人类判断保持一致。这可能意味着在二元标签上衡量召回率或精确率，或者在通过两两比较决定输出优劣时衡量相关性。一旦校准得当，这些评估器将有助于扩展对 AI 系统的持续监控。

But having automated evaluators doesn’t remove the need for human oversight. We still need to periodically sample and annotate data, and analyze user feedback. Ideally, we should design products that capture implicit feedback through user interactions. Nonetheless, explicit feedback, while less frequent and occasionally biased, can also be valuable. (Read more.)但拥有自动化评估器并不能消除对人工监督的需求。我们仍然需要定期抽样和标注数据，并分析用户反馈。理想情况下，我们应该设计能够通过用户交互捕获隐式反馈的产品。尽管如此，显式反馈虽然频率较低且偶尔带有偏见，但依然具有价值。（阅读更多。）

Also, while automated evaluators scale well, they aren’t perfect. But neither are human annotators. Nonetheless, by collecting more and higher-quality annotations, we can better align these evaluators. Organizational discipline is crucial to maintain this feedback loop of sampling data, annotating outputs, and improving automated evaluators.此外，虽然自动化评估器扩展性很好，但它们并不完美。不过，人类标注者也不完美。尽管如此，通过收集更多高质量的标注，我们可以更好地校准这些评估器。组织纪律对于维持这种“抽样数据—标注输出—改进自动化评估器”的反馈回路至关重要。

Automated evaluators amplify our existing annotation and feedback processes.自动化评估器增强了我们现有的标注和反馈流程。

• • •• • •

While building with AI can feel like magic, building AI products still takes elbow grease. If teams don’t apply the scientific method, practice eval-driven development, and monitor the system’s output, buying or building yet another evaluation tool won’t save the product.虽然用 AI 进行构建感觉像魔法，但构建 AI 产品仍然需要付出艰苦的努力。如果团队不应用科学方法、不实践评估驱动开发、不监控系统输出，那么购买或构建再多的评估工具也救不了产品。

By the way, if you want to learn more about evals, my friends Hamel and Shreya are hosting their final cohort of “AI Evals for Engineers and PMs” in July. Here’s a 35% discount code.顺便说一下，如果你想了解更多关于评估的内容，我的朋友 Hamel 和 Shreya 将于 7 月举办他们最后一期的“面向工程师和产品经理的 AI 评估”课程。这里有一个 35% 的折扣码。

If you found this useful, please cite this write-up as:如果你觉得这篇文章有用，请按以下方式引用：

Yan, Ziyou. (Apr 2025). An LLM-as-Judge Won't Save The Product—Fixing Your Process Will. eugeneyan.com. https://eugeneyan.com/writing/eval-process/.Yan, Ziyou. (2025年4月). “大模型裁判”救不了你的产品——改进流程才能. eugeneyan.com. https://eugeneyan.com/writing/eval-process/.

or

@article{yan2025eval-process,
  title   = {An LLM-as-Judge Won't Save The Product—Fixing Your Process Will},
  author  = {Yan, Ziyou},
  journal = {eugeneyan.com},
  year    = {2025},
  month   = {Apr},
  url     = {https://eugeneyan.com/writing/eval-process/}
}