Тестовые стенды LLM завышают точность оценок из-за подставных нулей в коде
Скрытые дефекты языковых моделей в реальной эксплуатации перекладывают операционные риски на конечных пользователей, пока внутренние отчеты демонстрируют мнимое благополучие. Практика применения систем автоматической оценки показывает, что за красивыми цифрами бенчмарков кроются банальные инженерные ошибки тестовых сред. В апреле 2026 года тестовый бот по проверке второй части единого государственного экзамена (ЕГЭ) ставил тот же балл, что эксперт, лишь в 50% ответов и завышал оценку каждому третьем.
Красивые метрики точности языковых моделей часто оказываются статистической иллюзией, маскирующей реальное качество сервиса. Разработчики месяцами опираются на показатели, которые не имеют отношения к тому, что отдается клиентам. Выяснить это удается только после жесткого аудита инфраструктуры замеров.
Расхождение тестового стенда и боевой среды
Главный источник управленческих заблуждений — несоответствие тестового окружения реальной конфигурации сервиса. Замеры точности часто ведутся по цепочке вызовов, которая полностью оторвана от боевого интерфейса.
«Почти каждая строка в ней — след какого-то из самообманов, о которых дальше».
Проблема расхождения конфигураций проявилась в системе проверки напрямую: все прогоны на моделях семейства Claude до 30 июля шли на Sonnet 5, тогда как боевой системой служила Sonnet 4.6. Позже, 9 октября, прод переключили на Sonnet 5.5 вообще без проведения регрессионного тестирования. В итоге точное совпадение с эталоном составило 71,5% против 74,2% на прежней версии, а доля занижений оценок выросла с 14,4% до 19,1%. Почти месяц сервис работал на непроверенной архитектуре. При этом в задании 19 текст задания вовсе не доходил до кодовых проверок в тестовом харнессе, хотя в самом боте работал штатно; после исправления стенда точность на том же наборе выросла с 34,9% до 48,8%. В задании 22 из-за отсутствия файла с ключами Федерального института педагогических измерений (ФИПИ) на машине замеров 36,7% завышений оказались артефактом, тогда как с ключами их было 6,7%.
Тихие нули и слепые зоны выборки
Второй пласт рисков кроется в обработке внутренних ошибок, когда падение пайплайна подменяется фиктивными успешными значениями. Защитные механизмы кода способны искусственно завышать точность, скрывая деградацию бизнес-логики.
«В задании 25 при сбое разбора ответа модели код молча подставлял ноль баллов».
В октябрьском тестовом прогоне накопилось 16 подобных скрытых нулей на 110 кейсов. Из них восемь пришлись на ответы, где эксперт действительно поставил ноль, что тестовый раннер записал в категорию точных совпадений, а остальные восемь ушли в занижения. Подставной ноль не позволял зафиксировать завышение оценки, скрывая ключевую операционную проблему.
Можно возразить, что любые тестовые метрики несовершенны, а постепенная отладка промптов и очистка датасета представляют собой стандартный процесс разработки. Но если замер строится на неочищенных выборках и фальшивых ответах, бизнес слепо накапливает технический долг. В наборе из 433 кейсов по заданиям с 17 по 25 у 40 не было надежного эталона — раннер их пропускал, поэтому оценивалось 393. Из них 343 представляли реальные экзаменационные работы, 33 были синтетическими тестами под специфические правила, а 17 составили самостоятельно переразмеченные автором работы и проверки из режима учителя. Лишь систематическая чистка процессов позволила сократить долю завышений баллов: в ноябре бот совпадает с экспертом в 71,5% случаев и завышает балл в 9,4%.
Проверьте имя модели и параметры непосредственно в боевых ответах программного интерфейса (API), изолировав статус сбоя парсинга от расчетного бизнес-результата.
Что это значит
Пропажа файла с ключами ФИПИ на тестовом сервере превратила треть результатов в фиктивные завышения, обнажив системную дыру в процедуре аудита ИИ-проверки. Автоматический раннер легко маскирует падения пайплайна под валидные экспертные ответы, создавая видимость благополучия в сводных таблицах. Защитные механизмы вместо аварийной остановки тихо искажают статистику сервиса проверки ЕГЭ, перекладывая технический брак на пользователей. Сколько скрытых отказов всё ещё прячется в отчётах системы, если банальная поломка кода разметки способна случайно совпасть с оценкой эксперта?
Источник: Хабр ML