Почему eval для LLM может врать даже при 96%
LLM‑тесты могут показывать почти идеальный результат, а после релиза ассистент всё равно ошибается в важном месте. В материале разбирается, как такие провалы возникают и почему оценке LLM‑функций нельзя слепо доверять.
Почему высокий балл не гарантирует качество
В статье описан типичный сценарий: команда тестирует AI‑ассистента поддержки, получает 96% по eval, выпускает релиз, а затем бот пообещал клиенту возврат, которого в правилах компании не было. При повторной проверке тот же запрос уже дал правильный ответ, и ошибку сначала посчитали случайной и даже закрыли как неповторяемую.
Автор объясняет, что проблема часто не в самой модели и не в конкретном тестировщике, а в способе проверки. Для генеративной функции сравнение с одной «правильной» фразой легко промахивается мимо сути: важно не только как ответ выглядит, но и какое решение он фактически содержит.
Какие ошибки чаще всего ломают eval
Первая распространённая ошибка — проверять форму ответа вместо смысла. Тогда тесты либо краснеют без реального бага, либо, наоборот, пропускают опасные формулировки, если ищут лишь отдельные слова. В статье отдельно подчёркивается, что даже при температуре 0 ответы LLM не всегда одинаковы: на практике воспроизводимость зависит ещё и от реализации инференса и окружения.
Вторая проблема — ставить один общий процент на всё подряд. Мягкие вещи вроде тона, полноты и общей корректности можно мерить порогом, а вот жёсткие правила — например, не обещать деньги, не раскрывать данные и не запускать запрещённые действия — должны проверяться без допуска к ошибке. Иначе 96% в отчёте легко скрывают один критический ответ, который нарушает политику компании.
Что делать команде, чтобы тестам можно было верить
Практический вывод простой: сначала нужно разделить, что именно делает модель, а что должно оставаться в обычной бизнес-логике. Если решение связано с деньгами или политиками компании, надёжнее отдать его правилам и тестировать как обычный код, а LLM оставить только генерацию текста. Если же решение всё-таки принимает сама модель, его лучше оценивать как вероятностное — с повторами, порогами и отдельной защитой опасных исходов.
Для бизнеса это полезно не только в поддержке, но и в любом продукте, где LLM классифицирует обращения, выбирает маршрут или возвращает структурированные данные. Такой подход снижает риск релиза «красивого, но опасного» ассистента и помогает строить eval, который показывает реальную, а не мнимую надёжность.