An LLM-as-Judge Won't Save The Product—Fixing Your Process Will

eugeneyan

eugeneyan

Начните здесь Статьи Выступления Прототипирование Об авторе

An LLM-as-Judge Won't Save The Product—Fixing Your Process Will

LLM-as-Judge не спасёт продукт — спасёт налаживание вашего процесса

[ eval llm engineering ] · 5 min read

[ eval llm engineering ] · 5 мин чтения

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.

Продуктовые evals понимают неправильно. Некоторые думают, что добавление ещё одного инструмента, метрики или LLM-as-judge решит проблемы и спасёт продукт. Но это обходит ключевую проблему стороной и избегает настоящей работы. Evals — это не статичные артефакты и не быстрые решения; это практики, применяющие научный метод, eval-driven development и мониторинг выводов ИИ.

Building product evals is simply the scientific method in disguise. That’s the secret sauce. It’s a cycle of inquiry, experimentation, and analysis.

Построение продуктовых evals — это попросту научный метод в замаскированном виде. В этом и состоит секретный ингредиент. Это цикл исследования, экспериментирования и анализа.

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.

Всё начинается с наблюдения, иначе говоря — Look at The Data™ (смотрите на данные). Это значит изучать наши входные данные, выводы ИИ и то, как пользователи взаимодействуют с нашими системами. Глядя на данные, мы узнаём, где система работает хорошо и — что, пожалуй, ещё важнее — где она даёт сбой. Выявление этих режимов отказа и есть отправная точка для осмысленного улучшения.

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 между прохождениями и провалами, охватывающее распределение входных данных. Этот датасет образует фундамент для целевых evals, которые отслеживают качество по выявленным нами проблемам.

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.

Измерение исходов и анализ ошибок — зачастую самый сложный шаг. В отличие от поверхностных «vibe checks», это требует количественной оценки того, действительно ли изменения в эксперименте улучшили результаты: повысилась ли точность? Стало ли меньше дефектов? Лучше ли новая версия в попарных сравнениях? Мы не можем улучшить результаты, если не можем их измерить.

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.

Если эксперимент удался, мы применяем изменение; если провалился — углубляемся в анализ ошибок, уточняем гипотезы и пробуем снова. Через этот итеративный цикл продуктовые evals становятся маховиком данных, который улучшает наш продукт, снижает количество дефектов и завоёвывает доверие пользователей.

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.

Eval-driven development (EDD) помогает нам создавать более качественные AI-продукты. Это похоже на test-driven development, где мы пишем тесты до реализации софта, который эти тесты проходит. EDD следует той же философии: прежде чем разрабатывать AI-фичу, мы определяем критерии успеха через продуктовые evals, чтобы обеспечить согласованность и измеримость с первого дня. И вот секрет: команды по машинному обучению практикуют это десятилетиями, создавая модели и системы относительно валидационных и тестовых наборов. Идеи похожи, хотя и носят разные названия.

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 evals направляют нашу разработку. Мы начинаем с оценки базовой линии — возможно, простого промпта — чтобы получить начальный бенчмарк. С этого момента каждая правка промпта, каждое обновление системы, каждая итерация оцениваются. Улучшило ли упрощение промпта точность следования контексту (faithfulness)? Повысило ли обновление ретривала полноту (recall) релевантных документов? Или же обновление ухудшило качество?

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 даёт немедленную, объективную обратную связь, мы видим, что улучшается, а что нет. Этот цикл — пишем evals, вносим изменения, прогоняем evals, интегрируем улучшения — обеспечивает измеримый прогресс. Вместо опоры на расплывчатые, интуитивные ощущения мы выстраиваем петлю обратной связи, основанную на практиках программной инженерии.

First, write some evals; then, build systems that pass those evals.

Сначала напишите несколько evals; затем стройте системы, которые эти 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.

Человеческий надзор по-прежнему необходим даже при наличии автоматических оценщиков (то есть LLM-as-judge). Хотя автоматические evals помогают масштабировать мониторинг, они не способны компенсировать небрежность. Если мы активно не просматриваем выводы ИИ и обратную связь клиентов, автоматические оценщики не спасут наш продукт.

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-продукты, мы обычно сэмплируем выводы и размечаем их по качеству и дефектам. Имея достаточно качественных разметок, мы можем откалибровать автоматических оценщиков так, чтобы они согласовывались с человеческим суждением. Это может означать измерение recall или precision на бинарных метках либо корреляции при выборе между выводами через попарные сравнения. После должной калибровки такие оценщики помогают масштабировать непрерывный мониторинг 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-продуктов всё ещё требует упорного труда. Если команды не применяют научный метод, не практикуют eval-driven development и не мониторят выводы системы, покупка или создание ещё одного инструмента оценки не спасёт продукт.

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.

Кстати, если вы хотите узнать больше про evals, мои друзья Hamel и Shreya проводят финальный поток курса «AI Evals for Engineers and PMs» в июле. Вот промокод на скидку 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. (Apr 2025). An LLM-as-Judge Won't Save The Product—Fixing Your Process Will. 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/} }

@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/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателей, получающих новости о машинном обучении, RecSys, LLM и инженерии.