Evals как инфраструктура: CI, датасет, гейты

Аналогия, которая задаёт масштаб

В обычной разработке качество защищают тесты, в ML — validation sets. Для AI-систем эту роль играют evals, только сложнее: поведение вероятностное, среда динамическая, а «правильно» часто не бинарно. Поэтому evals нужна статистическая дисциплина, а не true/false.

В зрелых командах evals — не research-артефакт, а CI/CD-слой: выбор модели, регрессионное тестирование, изменения промптов, архитектурные решения, safety-ревью, оптимизация стоимости, релизные гейты. Владение и развитие evals должно быть такой же рутиной, как поддержка unit-тестов.

Что входит в инфраструктуру

Часть	Что это	Признак, что её нет
Датасет	Версионированный набор задач с ожидаемым поведением	Кейсы живут в переписке и в голове владельца
Раннер	Запуск системы на датасете в изолированной среде	Прогон делается вручную и не воспроизводится
Оценщики	Детерминированные проверки, рубрики, судья	Результат читается глазами
Разбивка	Метрики по компонентам, а не один процент	Непонятно, что чинить после падения
Отчётность	История прогонов, сравнение версий	Нельзя ответить, стало ли лучше
Гейты	Правила блокировки релиза	Деградация уезжает в прод
Владелец	Человек, отвечающий за набор и его актуальность	Набор заброшен после запуска
Бюджет	Лимит на прогоны и токены	Полный набор перестали запускать из-за цены

Каденция и гейты

Триггер	Что запускается	Решение
Pull request	Smoke: 20–50 кейсов, быстрые проверки	Блокирует merge при регрессии
Ночь	Полный набор, длинные сценарии, судья	Заводит задачу на разбор
Релиз	Полный набор + execution-based на критичных путях	Блокирует выпуск
Изменение промпта или модели	Сравнение с базовой версией на одном датасете	Требует явного решения
Постоянно	Online-метрики и трассировка	Поднимает сигнал
Квартал	Red teaming и human-разметка выборки	Обновляет критерии

Гейт должен быть один и понятный. Если релиз блокируется по пяти разным метрикам без приоритета, команда научится обходить гейт, а не чинить причину.

Датасет

Датасет — главный актив, а не приложение к нему. OpenAI прямо называет eval-датасет «differentiated, context-specific dataset that is hard to copy»: его нельзя скачать вместе с весами модели.

Практика ведения:

Golden set от экспертов. Небольшой набор пар «вход → желаемый выход», принятый как эталон суждения команды. Он задаёт критерий, по которому калибруются остальные оценки.
Production-сбои. Каждый разобранный инцидент становится кейсом с типом проверки. Это единственный источник, который отражает вашу систему, а не представление о ней.
Версионирование. Датасет меняется вместе с системой; сравнение прогонов имеет смысл только на одинаковой версии набора.
Баланс сложности. Если все кейсы лёгкие, набор даёт 100% и ничего не измеряет. Если все провальные — не показывает прогресс.
Защита от контаминации. Публичные тест-сеты годами лежат в открытом доступе и попадают в обучение; высокий балл может быть выучен, а не заработан.
Старение. Задачи, которые легко решает текущая модель, перестают что-либо измерять. Набор нужно пересматривать, а не только пополнять.

Ошибки, которые обходятся дороже всего

Принимать ранг в лидерборде за качество продукта. Лидерборд отвечает про модель, а не про вашу систему.
Мерить только финальный успех. Один процент не показывает, где сломалось, и провоцирует менять всё сразу.
Менять инструменты, данные, промпт и модель одновременно. После такого изменения невозможно понять, что помогло.
Игнорировать стоимость и задержку. Улучшение на 2 п.п. при росте счёта в 5 раз — ухудшение продукта.
Слепо доверять судье. Без калибровки он измеряет сходство с собственными предпочтениями.
Винить модель, когда сломан eval. Самая коварная ошибка. На CORE-Bench Opus 4.5 подскочила с 42% до 95% после исправления багов грейдера, неоднозначных формулировок и слишком строгого scoring, который считал «96.12» ошибкой при ожидании «96.124991…». Модель не менялась.

Правило: прежде чем делать вывод про систему, проверьте, не сломан ли измерительный прибор. Прогоните несколько кейсов вручную, посмотрите на промежуточные значения, убедитесь, что эталон достижим.

Пределы подхода

Evals — необходимая опора, но не гарантия.

Модели замечают, что их тестируют, и на тесте ведут себя иначе, чем в работе. Поведенческие evals не равны поведению в проде.
Пройденные behavioral-evals не означают безопасность. Система может остаться уязвимой к джейлбрейкам и adversarial-запросам, которые не входили в набор.
Часть критериев не формализуется. Вкус, уместность, репутационный риск остаются за человеком.
Область развивается. Методологии меняются быстрее, чем успевают закрепиться практики.

Поэтому на по-настоящему рискованных кейсах решение подстраховывает живой человек — независимо от результатов прогона.

Чек-лист зрелости

Уровень	Что есть	Что это даёт
0	Демо и впечатления	Ничего не воспроизводится
1	Golden set и ручные прогоны	Есть эталон, но регрессии ловятся поздно
2	Offline smoke в CI	Регрессии блокируются до merge
3	Покомпонентные проверки и разбивка	Видно, где именно сломалось
4	Полный набор, гейты, online-метрики, red teaming	Качество управляется как инфраструктура

Переход с уровня 1 на 2 даёт больше, чем любой апгрейд модели: именно он превращает обсуждение «стало лучше» в проверяемое утверждение.

Что проверить в проекте

Кто владеет набором. Если владельца нет, набор устареет за месяц.
Запускается ли он на PR. Ручной прогон перед релизом ловит слишком поздно.
Есть ли версия датасета. Иначе сравнение прогонов бессмысленно.
Попадают ли инциденты в набор. Это главный источник роста качества.
Проверен ли сам eval. Сломанный грейдер выглядит как слабая модель.

Материалы и источники

Evals: что должен знать каждый AI-инженер в 2026 — Артем Тарасов, evals как инфраструктура и типовые ошибки
Anthropic: Demystifying evals for AI agents — владение evals и кейс CORE-Bench
OpenAI: How evals drive the next chapter in AI — golden set и ценность собственного датасета
Evidently AI: 30 LLM benchmarks — контаминация бенчмарков
What is an evaluation and why this definition matters — осведомлённость модели о тестировании