Что это такое
Тесты раньше системы — это спецификация поведения AI-процесса. Eval-набор фиксирует, какое поведение считается работающим, ещё до того как процесс собран: 50–500 размеченных примеров «правильный ответ для нашего процесса», ведутся параллельно версиям системы и обновляются каждую неделю из реальных решений.
Принцип напоминает привычное в разработке «сначала тест, потом код», но обманчиво. В разработке тест бинарный — прошёл или нет. В eval-наборе цель сложнее: распределение результатов по трём корзинам. 60 % кейсов с эталонным ответом, 30 % с допустимым отклонением, 10 % крайних случаев и провокаций.
Используется на фазе проектирования (DESIGN) до запуска процесса и продолжает работать всю фазу эволюции (EVOLVE). Без этой практики невозможен переход AI-процесса с уровня A2 на A3+ по шкале уровней автономии — человек так и останется проверять каждое решение вручную.
Как делать
1. Собрать первый набор: 50 эталонных кейсов
На неделе 1 — владелец процесса плюс один доменный эксперт разбирают 40–50 реальных решений из истории прошлого месяца. На каждый кейс — ожидаемый ответ. 50 примеров за один присест не делать: разметчики устают и начинают копировать. Лучше 40 за два часа, добить до 60 за следующие 2 недели.
2. Прогнать опорную точку
Опорная точка 0 % — это норма: исходный уровень, от которого мы измеряем рост. На неделе 2 хватает одного часа на прогон ручной или через простой скрипт.
3. Написать прогонщик
Прогонщик для eval-набора пишется за пару часов с AI-ассистентом. Главное — что это версионируемый код, а не одноразовая формула в табличке: иначе прогон не переживёт первую итерацию.
4. Итерировать контекст и промпт
Через 4–6 недель работы — рост с 0 % до 70–80 %. На каждое расхождение в продакшене — новый кейс в набор. Если в реальности 8 % обращений — праздничные заказы, а в наборе их нет, добавляем 12 кейсов и догоняем метрику.
5. Назначить владельца качества
Без человека, чьё имя стоит рядом с eval-набором, через 2 месяца команда привыкает к красной метрике и перестаёт реагировать. Это переход от практики к ритуалу — и самая частая причина провала.
Когда применяется
Запускаем тесты раньше системы на каждом AI-процессе, который должен дойти до автономии выше A2. Без eval-набора процесс остаётся на ручной проверке навсегда.
Не запускаем — на двух типах процессов. Первый: творческие задачи (написание текстов, исследовательский поиск), где «правильного ответа» нет. Там работает выборочная экспертная оценка 10–20 % выходов. Второй: долгосрочные стратегические решения, где обратная связь приходит через годы, а к тому моменту контекст изменился. Такие решения остаются на A1, потому что обратной связи в принципе нет.
В SMB (до 100 человек) запускаем на неделе 1 — пока процесс простой, разметка дешёвая. В Enterprise — после процесс-аудита, потому что часто eval нужно делить по подразделениям и юрисдикциям сразу.
Кто отвечает
Функция владения качеством — отдельная роль или часть роли владельца процесса. Без имени рядом с eval-набором практика не работает.
В Enterprise (1000+) — это специалист по проверке качества (англоязычный термин — Eval Specialist), отдельная штатная роль. Он работает со службой комплаенса по проверке безопасности и с доменным экспертом по точности.
В Mid-market (100–1000) эта роль часто вырастает из QA-инженера. По нашим наблюдениям, зарплата 150–400 тыс ₽/мес, защищённое время 30 % ставки.
В SMB (10–100) — функция совмещается с владельцем процесса. Минимум 4 часа в неделю защищённого времени плюс внешний эксперт-аудитор на 2 часа в месяц (15–30 тыс ₽/мес). Это нижняя граница, при которой практика ещё работает; ниже — методика технически выполняется, по существу нет.
Типичные ошибки
Театр качества. Eval-набор собрали один раз на запуске, через 3 месяца процесс обрабатывает новые типы запросов, в наборе их нет. Метрика на eval-наборе показывает 95 %, реальный поток держится на 70 %, дашборд при этом зелёный. Признак — версия набора не менялась 2+ месяца. Лечение — обновление набора как отдельный пункт в недельном плане владельца качества.
Eval написан после прода, не до. «Сначала запустим, потом покроем» превращает тесты в QA-постфактум. Спецификация перестаёт существовать: что считается работающим, определяется тем, что работает прямо сейчас. Лечение — дисциплина первой итерации: на пустом наборе результат 0 %, и это нормально.
Подгонка под набор. Команда оптимизирует под eval-набор, агент идеально его проходит, в продакшене качество не растёт. Eval из спецификации превращается в модель реальности, и эту модель никто не сверяет с реальностью. Признак — eval-метрика растёт, бизнес-метрики стоят или падают. Лечение — два независимых сигнала: статистический (eval) и поведенческий (бизнес-метрика). Если расходятся 2 недели подряд — набор обновляется под актуальный поток.
