Надежность оценки LLM: семь ловушек тестирования и как их обойти

# Надежность оценки LLM: почему «зеленый» eval может быть обманчив

В продукте появился AI-ассистент поддержки. Тестировщики собрали кейсы, подключили LLM-судью, получили общий балл в 96% и прошли релиз. Через неделю в поддержку приходит скриншот: бот уверенно пообещал клиенту возврат денег, которых согласно политике компании не существует. Повторный запуск того же вопроса дает правильный ответ, и баг закрывают как «не воспроизводится». Проблема кроется не в модели или тестировщике, а в самом методе измерения: проверка одного запроса на один ожидаемый ответ не подходит для генеративных систем.

Под LLM-функцией здесь понимается приложение, где модель выступает одним из компонентов: она генерирует текст, классифицирует обращение или выбирает действие, но это не полноценный агент с многошаговыми вызовами инструментов. Цель статьи — разобрать, почему популярные подходы к тестированию дают сбой, и как выстроить систему проверок, результаты которой действительно можно доверять.

Форма ответа вместо принятия решения

Самая распространенная ошибка — проверка текста ответа на точное совпадение с эталоном или наличие ключевых слов. Команды привыкли к детерминированной автоматизации, где код всегда дает один и тот же результат. Однако большие языковые модели по природе стохастичны. Даже при установке температуры (temperature) на ноль, в зависимости от реализации инференса, окружения и даты запуска, модель может выдавать разные токены в ответ на идентичный запрос.

Сравнение ответов по символу или подстроке приводит к тому, что тесты начинают «плавать»: они краснеют из-за стилистических расхождений, которые не влияют на смысл, или зеленеют, пропуская опасные ошибки, просто потому что в ответе случайно упало нужное слово (например, «нет» в начале фразы «нет проблем, деньги вернем»).

Решение лежит в разделении ответственности. Для принятия бизнес-решений (возврат средств, доступ к функциям) модель не должна быть единственным источником истины. Эти логики следует выносить в детерминированные сервисы правил, которые проверяются обычными юнит-тестами. Модель же может оставаться лишь генератором формулировок этого решения.

*Пример архитектуры:* 1. Запрос попадает в сервис правил, который принимает решение (ОДОБРИТЬ/ОТКАЗАТЬ) на основе жесткого кода. 2. Модель получает это решение и генерирует вежливую текстовую формулировку. 3. Tест проверяет результат действия сервиса правил детерминированно, а формулировку модели оценивает только как текст (судья или человек).

Жесткие инварианты нельзя мерить процентами

В отчетах часто встречается метрика «корректность 96%», что воспринимается как зеленый свет. Однако среди этих четырех процентов брака могут содержаться критические нарушения, такие как обещание денег сверх политики или раскрытие персональных данных.

Если тест показывает 95% успешных прогонов из 1000, но в двух прогонах бот нарушил финансовые правила, это не вопрос качества, а дефект системы. Психологически допустимы ошибки в стиле, тональности или полноте ответа — они статистичны. Но жесткие инварианты (не обещать несуществующих льгот, не давать пароли) не должны иметь процентный порог провала.

Один случай нарушения в критическом классе для теста — это провал всей релизной ветки. Защита таких правил требует двух слоев: eval-система должна искать нарушения в выборке, а приложение должно иметь встроенные фильтры (проверку прав, блокировку действий), которые физически предотвратят выполнение запрещенной операции, даже если модель ошиблась.

Иллюзия единственной цифры

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

Разбивка метрик по категориям раскрывает реальную картину. Типовые вопросы могут демонстрировать 99,5% успеха, в то время как вопросы вне тематики или связанные с редкими формулировками могут проваливаться с частотой 30–40%. Общие цифры маскируют эти провалы, создавая видимость стабильности там, где на самом деле система хрупка.

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

Судья как измерительный прибор с погрешностью

Использование другой LLM в качестве судьи (LLM-as-a-judge) стало стандартом, однако сам «судья» подвержен систематическим ошибкам. Исследования показывают, что модели-судьи могут предпочитать ответы, расположенные первыми, более длинные тексты или ответы, сгенерированные их же моделью-родителем.

Простое совпадение вердикта судьи с ручной разметкой на 97% не гарантирует, что он поймал все критические нарушения. Более того, при малом количестве примеров в тестовой выборке точность (precision) может быть высокой, а полнота (recall) — низкой. Это означает, что судья уверенно говорит «всё хорошо», пропуская значительную часть опасного контента.

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

Данные для обучения и проверки должны разделяться

Команды часто разбирают реальные ответы на ошибки, выписывают новые критерии, пишут промпты для судьи и затем проверяют систему на тех же самых данных. Это приводит к переобучению: метрика адаптируется под известные ошибки в выборке, а новые, ранее неизвестные типы сбоев остаются незамеченными.

Правильный подход требует разделения данных на несколько ролей: разведочная выборка для поиска паттернов, рабочий набор для итеративной правки, и отдельный, замороженный набор (holdout) для финальной приемки и регрессионного тестирования. Если промпт улучшили и набрали 98% на рабочей выборке, но на отложенной — только 85%, это свидетельствует о подгонке, а не о реальном росте качества.

Граница между моделью и кодом

Часто возникает спор: «Это баг модели или баг нашего кода?». В LLM-функциях важно четко провести границу. Поведение модели включает выбор инструмента и аргументов для его вызова. Однако сам вызов инструмента, проверка прав доступа и обработка результата — это обычный код.

Если сломанный парсинг JSON списать на «капризность модели», баг в коде может жить месяцами. Защита должна стоять между выбором модели и исполнением действия: обычный код должен проверять права пользователя и корректность данных до того, как действие произойдет, используя заглушки для модели при тестировании логики.

Экосистема больше, чем промпт и модель

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

Для надежного тестирования необходимо версионировать всё окружение: параметры вызова, схему инструментов, снимки баз знаний и конфигурации поиска. Каждое изменение компонента должно запускать соответствующий гейт оценки (например, обновление базы знаний — проверка groundedness и соблюдения политики). Только так можно быстро диагностировать регрессию и понять, какое именно изменение вызвало сбой.

Итог

Семь описанных ошибок указывают на одну корневую проблему: неумение построить измерительный прибор, которому можно доверять. LLM-функция требует гибридного подхода: вероятностные метрики качества для текстовой генерации (с повторами, проверенными судьей и отложенной выборкой) и жесткие инварианты для бизнес-логии, которые eval лишь сигнализирует, а код приложения гарантирует на уровне прав и проверок.

Тестирование LLM — это не поиск единственно верного ответа, а построение системы безопасности, где измерительные приборы сами проходят строгую валидацию.