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