Мало спросить, хорошо ли модель смотрится в демо. Полезнее спросить, переживёт ли система замену модели, правку промпта и плохой вторник так, чтобы никто не заметил деградацию слишком поздно.
Цикл evals
Нормальный контур простой: определили, что считаем успехом, измерили, аккуратно выкатили, вернули реальные продовые сбои обратно в наборы.
Evals это не хобби для бенчмарков
Много команд говорят об evals так, будто это приятная исследовательская надстройка. Это можно было терпеть, когда система состояла из одного промпта и одной модели.
В продукте, где уже есть поиск по базе, инструменты, политики, выходные контракты, несколько классов ошибок и пользователи, которые замечают поломки, этот подход перестаёт работать.
Текущие материалы OpenAI по evaluation best practices и evals для агентных систем говорят об одном. Evals нужны не для красоты. Чтобы работать с недетерминированной системой как с инженерным объектом, а не как с источником ощущений.
Anthropic пишет о том же применительно к агентам. Как только система живёт дольше одного шага, нужен внятный способ определить успех. Иначе любой спор скатывается к «кажется, стало хуже».
Начинать с маленького опорного набора
Самый полезный eval-набор меньше, чем хочется, и аккуратнее проверен, чем удобно.
Я делю его на два уровня.
Trusted set
Это набор, на который вы готовы опираться при релизном решении.
Он должен быть:
вручную проверенным
похожим на реальную работу
небольшим и поддерживаемым
достаточно чётким, чтобы и человек, и оценщик в целом сходились в выводах
Monitoring set
Он шире, шумнее и ближе к реальному трафику.
Он нужен для:
отслеживания дрейфа
поиска новых классов ошибок
проверки побочных эффектов после смены модели, промпта или роутинга
понимания, что происходит в живой системе
Но это не значит, что его нужно бездумно использовать как жёсткий релизный гейт.
Именно здесь многие команды начинают путаться: сваливают всё в один огромный мешок и потом удивляются, что половине набора сами не доверяют.
Оценивать ту часть системы, которая реально подвела
Один общий score выглядит опрятно. Польза от него часто скромнее.
Гораздо полезнее разносить оценки по конкретным слоям.
Для RAG или юридической системы мне нужны отдельные сигналы для:
корректности ответа
качества опоры на источники
целостности цитат и привязки к источнику
поведения при нехватке оснований
соблюдения формата
задержка
Для агентной системы этого обычно тоже мало. Материалы OpenAI по trace grading и недавние тексты Anthropic про evals сходятся в одном: если поведение внутри трассы влияет на исход, нельзя оценивать только финальный ответ.
Тогда приходится спрашивать уже так:
правильный ли инструмент выбрал агент
не делал ли лишних вызовов
не пересёк ли границу согласования
нашёл ли нужные источники и не испортил ли их по дороге
Если сбой случился в середине контура, финальная оценка ответа часто только замаскирует причину.
Judge-модели работают в узкой зоне ответственности
Judge-модели полезны там, где ответ открыт, а критерии можно внятно записать.
Они слабее, когда рубрика расплывчата, когда формат по-хорошему должен был быть детерминированным, или когда один факт может испортить весь ответ.
Рабочее правило. Где можно, кодовые проверки. Где нельзя, модельные. Вторые периодически сверять с первыми и с человеческой выборочной проверкой.
Anthropic пишет о том же. Автоматизация приносит пользу, пока задача сформулирована чётко. Если задача расплывчата, вы автоматизируете расплывчатость.
Продовые сигналы тоже часть evals
Много команд до сих пор оценивают только качество ответа, а всё остальное считают "опсом". На практике это искусственное разделение.
Изменение, которое сохранило красивый общий балл, но:
увеличило задержку
уменьшило долю корректных refusal
повысило число лишних tool calls
сделало систему дороже
всё равно изменило продукт.
Поэтому рядом с качеством ответа стоит держать и другие сигналы:
time to first token
end-to-end задержка
token cost
refusal rate
долю эскалаций
число вызовов инструментов
длину трассы
retry rate
Не нужно превращать это в культ метрик. Нужно хотя бы понимать, что именно у вас поменялось.
Релизные гейты должны быть скучными
Лучший релизный гейт понятен, не философичен.
Нормальный набор правил:
жёстко блокировать релиз, если просела точность на опорном наборе
жёстко блокировать, если сломалось соблюдение формата
жёстко блокировать, если просели корректные отказы в высокорисковых сценариях
предупреждать, если вылезают за бюджет по задержке или стоимости
разбирать трассу, если заметно меняется агентное поведение
Достаточно, чтобы команда спорила о фактах, а не о впечатлениях.
Продовые инциденты быстро попадают в набор
Самый быстрый способ сделать eval-программу бесполезной. Превратить её в музей.
Здоровее цикл. Пользователь или мониторинг находит сбой. Сбой становится eval case. После фикса система обязана проходить этот кейс всегда.
На этом строится накопительный эффект. Хороший eval-контур становится ценнее с каждым неприятным багом, который он впитал.
У evals должен быть хозяин
Общий дашборд это не ответственность. Кто-то должен решать, какие evals достаточно чистые, чтобы влиять на релиз, где шум, а где сигнал, какие новые кейсы добавлять, кто подписывается под изменением рубрик.
В недавнем тексте Anthropic это формулируется здраво. Нужна центральная инфраструктура, но определять, что считать успехом, должны люди, которые отвечают за продукт и домен.
Первая версия маленькая
Если бы пришлось завтра утром ставить evals с нуля:
собрал 30–50 опорных примеров
разложил по классам ошибок
сделал оценщики под каждый класс
рядом с качеством ответа мерил задержку и долю отказов
поставил релизный гейт на маленьком наборе, не на всём мире сразу
Первая eval-система не обязана впечатлять. Обязана ловить те ошибки, которые вы и правда выпускаете. Этого хватает.
