An LLM-as-Judge Won't Save The Product—Fixing Your Process Will
Юджин Ян утверждает, что добавление ещё одного инструмента, метрики или LLM-as-judge не спасёт AI-продукт — нужно наладить сам процесс. Продуктовые evals — это не статичные артефакты, а практика, опирающаяся на научный метод: наблюдение за данными, разметка проблемных выводов (в идеале баланс 50:50 успехов и провалов), формулирование гипотез о причинах сбоев, постановка экспериментов и измерение результатов. Автор продвигает eval-driven development (EDD) по аналогии с test-driven development: критерии успеха задаются заранее, а каждое изменение промпта, ретривера или модели оценивается относительно базовой линии. Даже при наличии автоматических оценщиков (LLM-as-judge) сохраняется потребность в человеческом контроле: нужно периодически сэмплировать и размечать данные, калибровать оценщиков под человеческие суждения и анализировать обратную связь пользователей. В конце упоминается финальный поток курса «AI Evals for Engineers and PMs» от Hamel и Shreya в июле со скидкой 35%.
LLM-as-Judge не спасёт продукт — спасёт налаживание вашего процесса
[ eval llm engineering ] · 5 мин чтения
Продуктовые evals понимают неправильно. Некоторые думают, что добавление ещё одного инструмента, метрики или LLM-as-judge решит проблемы и спасёт продукт. Но это обходит ключевую проблему стороной и избегает настоящей работы. Evals — это не статичные артефакты и не быстрые решения; это практики, применяющие научный метод, eval-driven development и мониторинг выводов ИИ.
Построение продуктовых evals — это попросту научный метод в замаскированном виде. В этом и состоит секретный ингредиент. Это цикл исследования, экспериментирования и анализа.
Всё начинается с наблюдения, иначе говоря — Look at The Data™ (смотрите на данные). Это значит изучать наши входные данные, выводы ИИ и то, как пользователи взаимодействуют с нашими системами. Глядя на данные, мы узнаём, где система работает хорошо и — что, пожалуй, ещё важнее — где она даёт сбой. Выявление этих режимов отказа и есть отправная точка для осмысленного улучшения.
Затем мы размечаем часть данных, отдавая приоритет проблемным выводам. Это значит разметить выборку успехов и провалов, чтобы построить сбалансированный и репрезентативный датасет. В идеале у нас должно быть разделение 50:50 между прохождениями и провалами, охватывающее распределение входных данных. Этот датасет образует фундамент для целевых evals, которые отслеживают качество по выявленным нами проблемам.
Далее мы выдвигаем гипотезу о том, почему происходят конкретные сбои. Возможно, ретривал нашего RAG не возвращает релевантный контекст, или, может быть, модель с трудом следует сложным — а порой и противоречивым — инструкциям. Изучая такие данные, как извлечённые документы, цепочки рассуждений и ошибочные выводы, мы можем приоритизировать сбои для исправления и гипотезы для проверки.
Затем мы проектируем и проводим эксперименты, чтобы проверить наши гипотезы. Эксперименты могут включать переписывание промптов, обновление компонентов ретривала или переход на другую модель. Хороший эксперимент определяет исходы, которые подтверждают или опровергают гипотезы. В идеале он также должен включать базовую линию или контрольное условие, с которым можно сравнивать.
Измерение исходов и анализ ошибок — зачастую самый сложный шаг. В отличие от поверхностных «vibe checks», это требует количественной оценки того, действительно ли изменения в эксперименте улучшили результаты: повысилась ли точность? Стало ли меньше дефектов? Лучше ли новая версия в попарных сравнениях? Мы не можем улучшить результаты, если не можем их измерить.
Если эксперимент удался, мы применяем изменение; если провалился — углубляемся в анализ ошибок, уточняем гипотезы и пробуем снова. Через этот итеративный цикл продуктовые evals становятся маховиком данных, который улучшает наш продукт, снижает количество дефектов и завоёвывает доверие пользователей.
Применение научного метода к созданию AI-продуктов.
Eval-driven development (EDD) помогает нам создавать более качественные AI-продукты. Это похоже на test-driven development, где мы пишем тесты до реализации софта, который эти тесты проходит. EDD следует той же философии: прежде чем разрабатывать AI-фичу, мы определяем критерии успеха через продуктовые evals, чтобы обеспечить согласованность и измеримость с первого дня. И вот секрет: команды по машинному обучению практикуют это десятилетиями, создавая модели и системы относительно валидационных и тестовых наборов. Идеи похожи, хотя и носят разные названия.
В EDD evals направляют нашу разработку. Мы начинаем с оценки базовой линии — возможно, простого промпта — чтобы получить начальный бенчмарк. С этого момента каждая правка промпта, каждое обновление системы, каждая итерация оцениваются. Улучшило ли упрощение промпта точность следования контексту (faithfulness)? Повысило ли обновление ретривала полноту (recall) релевантных документов? Или же обновление ухудшило качество?
Поскольку EDD даёт немедленную, объективную обратную связь, мы видим, что улучшается, а что нет. Этот цикл — пишем evals, вносим изменения, прогоняем evals, интегрируем улучшения — обеспечивает измеримый прогресс. Вместо опоры на расплывчатые, интуитивные ощущения мы выстраиваем петлю обратной связи, основанную на практиках программной инженерии.
Сначала напишите несколько evals; затем стройте системы, которые эти evals проходят.
Человеческий надзор по-прежнему необходим даже при наличии автоматических оценщиков (то есть LLM-as-judge). Хотя автоматические evals помогают масштабировать мониторинг, они не способны компенсировать небрежность. Если мы активно не просматриваем выводы ИИ и обратную связь клиентов, автоматические оценщики не спасут наш продукт.
Чтобы оценивать и мониторить AI-продукты, мы обычно сэмплируем выводы и размечаем их по качеству и дефектам. Имея достаточно качественных разметок, мы можем откалибровать автоматических оценщиков так, чтобы они согласовывались с человеческим суждением. Это может означать измерение recall или precision на бинарных метках либо корреляции при выборе между выводами через попарные сравнения. После должной калибровки такие оценщики помогают масштабировать непрерывный мониторинг AI-систем.
Но наличие автоматических оценщиков не отменяет потребности в человеческом надзоре. Нам всё равно нужно периодически сэмплировать и размечать данные, а также анализировать обратную связь пользователей. В идеале стоит проектировать продукты так, чтобы они улавливали неявную обратную связь через взаимодействия пользователей. Тем не менее явная обратная связь, хоть и менее частая и порой смещённая, тоже может быть ценной. (Подробнее читайте здесь.)
Кроме того, хотя автоматические оценщики хорошо масштабируются, они не идеальны. Но и человеческие разметчики тоже. Тем не менее, собирая больше и более качественных разметок, мы можем лучше калибровать этих оценщиков. Организационная дисциплина критически важна для поддержания этой петли обратной связи: сэмплирования данных, разметки выводов и улучшения автоматических оценщиков.
Автоматические оценщики усиливают наши существующие процессы разметки и обратной связи.
• • •
Хотя разработка с ИИ может ощущаться как волшебство, создание AI-продуктов всё ещё требует упорного труда. Если команды не применяют научный метод, не практикуют eval-driven development и не мониторят выводы системы, покупка или создание ещё одного инструмента оценки не спасёт продукт.
Кстати, если вы хотите узнать больше про evals, мои друзья Hamel и Shreya проводят финальный поток курса «AI Evals for Engineers and PMs» в июле. Вот промокод на скидку 35%.
Если этот материал оказался полезным, пожалуйста, цитируйте его так:
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/.
или
@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/} }
Присоединяйтесь к 11 800+ читателей, получающих новости о машинном обучении, RecSys, LLM и инженерии.