---
title: "Evals как инфраструктура: CI, датасет, гейты"
description: Что входит в eval-инфраструктуру, как вести датасет и запускать проверки по каденции, и какие ошибки измерения обходятся дороже всего.
---

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

В обычной разработке качество защищают тесты, в 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](https://habr.com/ru/articles/1050736/) — Артем Тарасов, evals как инфраструктура и типовые ошибки
- [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) — владение evals и кейс CORE-Bench
- [OpenAI: How evals drive the next chapter in AI](https://openai.com/index/evals-drive-next-chapter-of-ai/) — golden set и ценность собственного датасета
- [Evidently AI: 30 LLM benchmarks](https://www.evidentlyai.com/llm-guide/llm-benchmarks) — контаминация бенчмарков
- [What is an evaluation and why this definition matters](https://www.alignmentforum.org/posts/E9fvqHEDzfLDJTGyq/what-is-an-evaluation-and-why-this-definition-matters) — осведомлённость модели о тестировании