Разбор ошибок тестирования LLM-функций

В статье на Хабре Tech Lead Сергей Прощаев разбирает, почему результаты оценки LLM-функций часто вводят в заблуждение. Он описывает типичный случай: ассистент поддержки показал 96% качества на тестах, но после релиза пообещал клиенту возврат, не предусмотренный правилами компании. Повторный запуск того же запроса дал корректный ответ, и баг закрыли как невоспроизводимый. По мнению автора, проблема не в модели и не в тестировщике, а в наивном подходе к проверке генеративных функций.

Прощаев выделяет семь ошибок тестирования LLM-функций. Первая — попытка сравнивать ответ с эталоном или искать ключевые слова. Даже при temperature=0 детерминированность не гарантирована: в сентябре 2025 года команда Thinking Machines отправила модели Qwen3-235B-A22B-Instruct-2507 тысячу одинаковых запросов и получила 80 разных ответов, первое расхождение возникло на 103-м токене. Автор подчёркивает, что структурированный вывод не превращает решение модели в детерминированное правило, поэтому финансовые решения надёжнее выносить в отдельный сервис правил.

Вторая ошибка — смешивание мягкого качества и жёстких инвариантов в одной метрике. Корректность, полнота и тон можно оценивать статистически с порогом, но запрет на обещание денег сверх политики или раскрытие персональных данных порога не допускает. Ответ, который девять раз из десяти корректен, а на десятый обещает возврат, — это не 90% качества, а дефект. В качестве примера автор приводит дело Air Canada: в ноябре 2022 года чат-бот авиакомпании неверно сообщил о льготном тарифе на похороны, и в феврале 2024 года трибунал Британской Колумбии признал перевозчика ответственным, обязав выплатить 812,02 канадского доллара с процентами и сборами.

Третья ошибка — ориентация на общий балл без разбивки по категориям. В демонстрационном репозитории автора 96% складываются из 1018 верных прогонов из 1060, но в двух случаях ассистент пообещал деньги. При этом вопросы вне темы и редкие формулировки дают 35 ошибок из 42, а общая цифра этого не показывает. Прощаев рекомендует считать метрики отдельно по категориям вопросов и по уровням системы: генерация, вызовы инструментов, проверка прав.

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

Для воспроизведения примеров Прощаев собрал репозиторий llm-eval-pitfalls-demo с синтетическими данными, ручной разметкой и скриптом, считающим четыре отчёта по одним и тем же данным. Запуск не требует API-ключей. Автор подчёркивает, что ноль нарушений на тестовом наборе не доказывает их отсутствия в проде, поэтому проверки должны быть встроены в архитектуру, а не только в eval.