Разовая оценка качества ответов показывает снимок на день запуска. Но чат-бот — живая система: промпт поправили, базу знаний обновили, провайдер сменил версию модели — и бот, который вчера отвечал нормально, сегодня уверенно выдумывает. Eval-регламент закрывает именно это: каждое изменение проходит через одинаковый прогон оценки, и результат сравнивается с порогом, а не с ощущением команды.
Регламент нужен любой компании с внешним или внутренним ботом: поддержкой, HR-ассистентом, консьержем на сайте. Это документ и одновременно автоматизированный процесс — вместе они занимают пару недель настройки. Ниже — восемь шагов построения. Настройка eval-контура с метриками и CI-прогоном у НЬЮ-ССТ — от 90 000 ₽ (сентябрь 2026). Отдельный гайд о том, как оценивать качество ответов LLM разово, — «Как оценить качество ответов LLM».
Пошаговый план
Сформулируйте, что защищает регламент
Выпишите риски, от которых защищаетесь: деградация после смены промпта, молчаливое ухудшение модели у провайдера, устаревшая база знаний, регресс отказов. Определите объекты изменений, которые требуют прогона: системный промпт, версия модели, структура базы знаний, фильтры guardrails, пороги эскалации. Всё, что влияет на ответы, получает номер версии — без версий регламент бессмыслен.
Соберите и застабилизируйте золотой набор
Основа регламента — золотой набор: 100–300 реальных пользовательских вопросов, каждый сопровождается эталоном или критериями, по которым ответ признаётся верным. Набирайте живые диалоги, не придуманные тестировщиком: редкие формулировки, опечатки, злые вопросы, пограничные сценарии. Набор версифицируется и обновляется по фиксированному правилу — например, раз в месяц добавляются новые реальные кейсы, а спорные эталоны пересматриваются.
Выберите метрики релиза
Для чат-бота работает связка из четырёх метрик: правильность сути ответа (по критериям), groundedness — опора на базу знаний без выдумок, корректность отказа (бот честно говорит «не знаю» там, где данных нет), соблюдение формата и запрещённых тем. Галлюцинации считаются отдельно от общей правильности: ответ может быть красивым и уверенным, но выдуманным — это разные дефекты с разной ценой.
Опишите цикл оценки
Зафиксируйте триггеры: любой релиз из списка объектов изменений запускает полный прогон; инцидент в эксплуатации — точечный прогон по затронутой категории; плановая проверка — раз в месяц даже без изменений. Установите сроки: полный прогон автоматический — часы, не дни; вердикт и решение о релизах — за один рабочий день. Без сроков регламент превращается в очередное «когда-нибудь проверим».
Распределите роли и ответственность
Назовите владельца eval-регламента — он отвечает за набор, метрики и пороги. Автор изменений (промпт-инженер, разработчик) не может сам выпускать релиз без прогона — это фиксируется в процессе. Разделение «автор — проверяющий» обязательно: автор своего промпта видит то, что ожидал увидеть. Для внешних подрядчиков правило то же: релиз принимается только с протоколом прогона.
Автоматизируйте прогон
Прогон должен запускаться одной командой или автоматически при изменении промпта в репозитории: набор вопросов идёт в бот, ответы оцениваются моделью-судьёй по критериям, спорные и провальные случаи маркируются для ручного разбора. Модель-судья калибруется на парах «ответ — оценка человека» и периодически перепроверяется выборочно. Результаты каждого прогона сохраняются с номером версии — это история качества, которая пригодится при разборе инцидентов.
Установите пороги и правила отката
Для каждой метрики задайте порог релиза: например, правильность не ниже предыдущей версии, доля галлюцинаций не выше установленного максимума, отказы не хуже эталона. Любой провал — релиз не выходит, независимо от срочности «одной маленькой правки». Для эксплуатации определите правило отката: обнаружили деградацию на проде — возвращается предыдущая версия промпта или модели немедленно, разбор причин потом.
Разбирайте провалы эксплуатации
Диалоги, где бот ошибся в бою, еженедельно разбираются и превращаются в новые случаи золотого набора. Для каждого провала фиксируйте класс: данных не было в базе, данные были но не нашлись, ответ сформирован неправильно, фильтр сработал не так. Классы связываются с ответственными: владелец базы знаний, автор промпта, разработчик поиска. Так регламент замыкает цикл — продовые ошибки завтра становятся тестами.
Чек-лист
Eval-регламент работает, если выполнено:
- Объекты изменений определены и версируются
- Золотой набор собран из реальных диалогов (100–300 сценариев)
- Эталонные ответы и критерии правильности зафиксированы
- Набор обновляется по регулярному правилу
- Метрики включают правильность, опору на базу, отказы, формат
- Галлюцинации измеряются отдельной метрикой
- Триггеры прогона описаны для всех типов изменений
- Сроки прогона и решения о релизе установлены
- Владелец регламента назначен
- Автор изменения не выпускает релиз без прогона
- Прогон автоматизирован и запускается из репозитория
- Модель-судья калибрована и выборочно перепроверяется людьми
- Пороги релиза и правило отката зафиксированы
- Провалы эксплуатации еженедельно попадают в набор
Что влияет на результат
Живучесть регламента определяется тремя условиями. Первое — золотой набор действительно отражает живых пользователей: набор из реальных диалогов с эталонами переживает любую смену модели, набор из выдуманных вопросов устаревает за месяц. Второе — прогон достаточно быстр: если полный eval занимает часы и запускается одной командой, его делают; если дни и по договорённости — обходят. Третье — у регламента есть владелец с полномочиями остановить релиз: без права сказать «нет» процесс остаётся декорацией. Влияет и зрелость логирования: там, где каждый диалог размечен версией промпта и модели, разбор инцидентов занимает минуты. Наконец, имеет значение культура команды: относиться к оценке как к страховке, а не к бюрократии, проще там, где однажды уже откатывали неудачный релиз.
Внедрение занимает две–три недели, из которых большая часть уходит не на технику, а на эталоны: договориться, что считать правильным ответом, — главная работа. Не ждите идеального набора: стартуйте со ста вопросов и растите ежемесячно, регламент живёт вместе с набором. Автоматизацию делайте после первого ручного прогона — он покажет, какие шаги вообще стоят автоматизации. Отдельно договоритесь с бизнесом о цене ошибки: пороги для бота поддержки клиентов и для внутреннего ассистента разные, и попытка применить одни рамки ко всем системам ломает либо скорость, либо качество. Первый откатанный релиз — момент, когда регламент перестаёт быть бумагой: команда видит, как плохое изменение не доехало до пользователей, и начинает приносить спорные случаи сама.
Частые ошибки
Регламенты перестают работать по стандартным причинам:
- Набор из выдуманных вопросов. тестировщик пишет то, что и так работает; реальные пользователи ломают бота формулировками, которых нет в наборе
- Метрика «общее качество». одна агрегированная оценка скрывает рост галлюцинаций за красивым форматом — метрики разделяются
- Прогон руками по чек-листу. ручная оценка занимает дни, её пропускают под давлением сроков — только автоматизация делает регламент живым
- Релизы мимо регламента. исключение «это маленькая правка» один раз — и далее все правки маленькие; порог действует для всех изменений
- Судья без калибровки. модель-судья, не сверенная с людьми, дрейфует и начинает хвалить любые гладкие ответы
Инструменты и сроки
Понадобятся золотой набор, скрипт прогона в CI и журнал релизов; по срокам рассчитывайте 2–3 недели на первичный набор и автоматизацию, далее поддержка занимает часы в неделю. Считайте регламент окупившимся после первого откатанного релиза: деградация, пойманная до прода, дешевле разового разбора инцидента с клиентами.
- Золотой набор диалогов
- Прогон eval в CI
- Журнал релизов промптов и моделей
Что получится в итоге
Через несколько недель команда получает управляемое качество: изменения выходят предсказуемо, каждая версия бота сравнима с предыдущей числами, а инциденты превращаются в тесты. Решения «переезжать на новую модель или нет» перестают быть верой в презентацию провайдера — это вопрос одного прогона на своём наборе. И для корпоративных клиентов готовый eval-процесс — весомый аргумент: качество бота здесь проверяемо, а не обещано.