Ассистент отвечает красиво, но проверять его качество «на глаз» невозможно: сегодня он ответил правильно, завтра придумал пункт регламента, и разницу вы заметите по жалобе клиента. Протокол оценки ответов (evals) превращает качество из ощущения в число: одна и та же методика измеряет модель до запуска, после каждой доработки и после смены версии. Гайд описывает, как собрать такой протокол за неделю — силами вашей команды.
Методика работает для любого контура: RAG-ассистент по документам, генерация черновиков писем или классификация обращений. База для оценки — правильно собранные данные; как их подготовить, разобрано в гайде подготовки данных для RAG, а технические ограничители поведения — в гайде по настройке guardrails.
Ориентиры стоимости на сентябрь 2026: аудит готового LLM-решения перед запуском — 150 000 ₽ за 1–2 недели, ревизия ИИ-активов и Shadow AI — от 70 000 ₽, прототип с проверкой гипотезы — 90 000 ₽. Собственный протокол evals дешевле: он строится один раз и дальше работает на каждой итерации.
Протокол evals окупается с первой итерации: доработка без прогона ломает работающее, а запуск без порогов переносит спор «хорошо или плохо» на живых клиентов. Ниже — семь шагов: от эталонного набора до постоянной человеко-оценки. Каждый шаг завершается артефактом — таблицей, журналом, порогом, — которые вместе и составляют систему качества.
Пошаговый план
Соберите эталонный набор вопросов
Основа протокола — golden set: 100–300 реальных вопросов пользователей с эталонными ответами или критериями правильности. Берите вопросы из журнала поддержки, переписки и поисковых запросов, а не сочиняйте за столом: тест на выдуманных примерах меряет не вашу задачу. Для каждого вопроса зафиксируйте источник правильного ответа — документ и пункт, чтобы проверяющий мог сверить факт. Набор обновляйте: каждая сложная ошибка продакшена становится новым вопросом набора.
Определите метрики под тип задачи
Универсальной метрики нет: для ответов по документам меряют фактическую точность и ссылку на источник, для генерации — соответствие стиле и полноту, для классификации — долю верных ярлыков. Зафиксируйте 3–5 метрик на сценарий и их формулы. Обязательно включите полноту: ассистент, который честно отвечает «не знаю» на сложное, полезнее того, кто уверенно выдумывает. Формулы запишите в документ протокола — они не должны меняться от прогона к прогону под влиянием результата.
Измеряйте галлюцинации отдельно
Ошибку факта скрывает самая гладкая формулировка, поэтому доля выдуманных утверждений — отдельная метрика. Считайте её так: ответ верен, только если каждое утверждение подтверждается источником из базы знаний. Прогоняйте вопросы, на которые в базе нет ответа: правильное поведение — отказ или эскалация, а не фантазия. Высокая доля галлюцинаций на «пустых» вопросах — сигнал, что ассистенту не хватает отказоустойчивости, а не данных.
Автоматизируйте скоринг
Ручная проверка 300 ответов занимает день и не повторяется точно. Автоматизируйте: правила проверяют формат, ссылки и длину, а модель-судья (LLM-as-judge) сверяет ответ с эталоном по вашей шкале. Судью калибруют на 30–50 вопросах, размеченных людьми: если автоматический вердикт расходится с человеческим чаще, чем на каждом пятом примере, шкалу уточняют. Результат каждого прогона сохраняйте с версией модели и промпта — это журнал качества системы.
Заведите регресс-тесты
Любое изменение — новый промпт, обновление базы знаний, смена версии модели — способно сломать то, что работало. Поэтому перед каждым изменением гоняйте полный набор: сравнение прошло, если метрики не упали ниже порогов и ни один класс вопросов не деградировал. Регресс-тест встраивается в процесс доработки контура так же, как тесты в разработку: без зелёного прогона изменение не уходит в продакшен. Это защищает от тихих деградаций, которые замечают через месяц по жалобам.
Назначьте пороги приёмки
Определите, какие значения метрик достаточны для запуска и для продолжения работы: например, фактическая точность не ниже согласованного уровня, доля галлюцинаций — не выше допустимой, отказы корректны. Пороги задаёт владелец процесса вместе с заказчиком, исходя из цены ошибки: медицинская консультация и подбор тарифа требуют разной строгости. Прогон против порогов делает решение о запуске прозрачным: цифры либо прошли, либо нет.
Оставьте человеко-оценку в контуре
Автоматика дешёвая, но мёртвая к нюансам: тон, уместность, переход на человека. Пусть операторы раз в неделю размечают случайную выборку ответов по короткой шкале, а разборы спорных случаев идут в журнал протокола. Это и калибровка судьи, и раннее обнаружение новых классов ошибок. Человеческая оценка не заменяет автоматическую — они дополняют друг друга: автоматика ловит объём, человек ловит смысл.
| Метрика | Что измеряет | Как считается |
|---|---|---|
| Фактическая точность | ответ верен и подтверждён источником | доля верных ответов на эталонном наборе |
| Доля галлюцинаций | выдуманные факты и пункты | экспертная сверка утверждений с источником |
| Корректный отказ | поведение при отсутствии ответа в базе | доля честных «не знаю» на пустых вопросах |
| Полнота | все ли части вопроса раскрыты | сверка с чек-листом эталона |
| Формат и стиль | структура, длина, тон | правила и выборочная разметка |
| Стабильность версий | нет деградации после изменений | регресс-прогон полного набора |
Что влияет на результат оценки
Точность протокола зависит от качества набора (реальные вопросы, а не выдуманные), стабильности метрик (одни формулы от прогона к прогону) и калибровки автоматики (судья сверён с людьми). Второй фактор — дисциплина: прогон перед каждым изменением и разбор ошибок продакшена. Третий — адекватность порогов цене ошибки: строгие там, где ошибка дорога, и практичные там, где черновик проверяет человек.
Чек-лист
Пройдитесь по списку перед запуском и перед каждой итерацией: протокол работает, только если все пункты выполняются регулярно.
- Эталонный набор собран из реальных вопросов, не выдуман
- Для каждого вопроса зафиксирован источник правильного ответа
- Метрики и формулы описаны в документе протокола
- Галлюцинации и корректные отказы измеряются отдельно
- Модель-судья откалибрована на ручной разметке
- Регресс-прогон обязателен перед каждым изменением
- Пороги приёмки согласованы с владельцем процесса
- Журнал прогонов хранит версии модели, промпта и базы
- Ошибка продакшена становится новым вопросом набора
- Человеко-оценка идёт выборочно, но постоянно
- Набор хранится в системе контроля версий вместе с промптами
- Метрики сравнимы между прогонами — формулы не меняются
Ошибки новичков
Эти ошибки превращают оценку качества в ритуал, который ничего не ловит.
- Тест на приятных примерах. в набор берут простые вопросы, сложные и пограничные не попадают — метрики высокие, продакшен сыплется
- Оценка один раз до запуска. после первой же доработки метрики устаревают; без регресс-прогонов качество деградирует незаметно
- Слепая вера в модель-судью. судья без калибровки на ручной разметке сам галлюцинирует и занижает или завышает вердикты
- Одна общая метрика «правильно/неправильно». смешение фактов, тона и полноты скрывает причину ошибки — непонятно, что чинить
- Проверка только содержательного ответа. забывают поведение при отсутствии данных: ассистент, не умеющий отказываться, опаснее неточного
Инструменты и сроки
Достаточно таблицы для набора, скрипта прогона и журнала результатов; у крупного контура оценку встраивают в конвейер доработки. Срок: неделя на первый протокол. Если контур делает подрядчик, требуйте включить регресс-тесты в состав поставки — методику приёмки фиксируют ещё в ТЗ.
- Эталонный набор вопросов с источниками
- Скрипт прогона: правила + модель-судья
- Журнал результатов с версиями
Что получится в итоге
Итог — работающий протокол: набор вопросов с эталонами, автоматический скоринг, пороги приёмки и регресс-прогоны в процессе доработки. Качество перестаёт быть мнением: у вас есть цифры до запуска, после каждого изменения и тренд по месяцам. А каждая найденная ошибка делает протокол сильнее — она попадает в набор и больше не повторяется незамеченной.