Оценка качества AI-ассистента: как собрать eval-набор и критерии

Что важно понять до начала

Eval — воспроизводимая проверка поведения AI-системы на наборе заданий. Для корпоративного ассистента важно оценивать не только фактическую точность, но и полноту, ссылки на источники, соблюдение политики, формат ответа и корректный отказ.

Набор должен отражать реальный трафик и редкие опасные случаи. Его разделяют на рабочую выборку для итераций и скрытую контрольную, иначе команда невольно подстраивает промпт под знакомые примеры.

Как закрепить результат

Разовая настройка быстро устаревает. Правила, тесты и владельцы нужны, чтобы качество сохранялось при следующих релизах и новых интеграциях.

• Каждый инцидент добавляет обезличенный регрессионный пример.
• Изменения сравниваются на одном и том же скрытом наборе.
• Рубрика и эталон пересматриваются предметным экспертом.
• Результаты хранятся с версией модели, промпта, инструментов и базы знаний.

Что подготовить

До изменений зафиксируйте границы задачи, исходные данные, ответственных и критерий готовности. Это делает проверку воспроизводимой и защищает рабочие процессы.

• Определить сценарии, пользователей и цену неверного ответа или действия.
• Собрать обезличенные примеры реальных вопросов и экспертные эталонные признаки.
• Описать допустимый ответ, обязательный отказ и правила использования источников.
• Разделить тесты по языку, сложности, типу данных и уровню риска.

Пошаговый план

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

• Создать компактную рубрику с отдельными критериями и понятной шкалой.
• Добавить позитивные, пограничные, провокационные и многошаговые примеры.
• Запустить baseline текущей модели и сохранить версию промпта, данных и параметров.
• Совместить программные проверки, модель-судью и выборочную экспертную оценку.
• Разобрать провалы по типам причин: поиск, инструкция, инструмент, модель или данные.
• Запускать регрессию перед релизом и мониторить производственные сигналы после него.

Что измерять

Набор метрик должен одновременно показывать техническое качество, пользовательский результат и скорость реакции команды на отклонение.

• Успешность по каждому сценарию и критерию, а не только среднее значение.
• Доля неподтверждённых фактов и корректных ссылок на источники.
• Частота правильного отказа в запрещённых или неуверенных случаях.
• Регрессии между версиями, стоимость и задержка успешного ответа.

Типичные ошибки

Большинство сбоев возникает на границах ответственности: когда техническая проверка не связана с бизнес-сценарием, данными и действиями пользователя.

• Оценивать систему только на удобных придуманных запросах.
• Смешивать точность, стиль и безопасность в один субъективный балл.
• Использовать один и тот же набор для настройки и финальной проверки.
• Считать модель-судью единственным источником истины в высокорисковом сценарии.

Результат работы

Качество AI нельзя свести к одному проценту: критерии зависят от задачи, цены ошибки и допустимого поведения системы.

Готовое решение включает не только исправление или настройку, но и документированный способ повторной проверки. Так команда может безопасно развивать продукт без возврата прежней проблемы.