Эталоном в проекте служит балл эксперта по критериям ФИПИ. Набор состоит из 433 кейсов по заданиям 17–25, но у 40 из них нет надёжного эталона, поэтому оценивается 393: 343 реальные экзаменационные работы, прошедшие через распознавание рукописных сканов, 33 синтетических кейса под конкретные правила и 17 работ, которые автор переразметил сам. Для каждого кейса считается разность между полученным и ожидаемым баллом, а доля ошибок — в кейсах, а не в баллах, так что промах на +1 и на +4 весит одинаково. Главным показателем автор считает долю завышений: заниженный балл ученик заметит и придёт спорить, а завышенный примет с удовольствием и узнает правду только на экзамене.
Первый и самый частый самообман — харнесс мерил не то, что работало в проде. Скрипт замера не загружал .env и брал модель по умолчанию, поэтому «claude»-прогоны до 30 июля шли на Sonnet 5, а боевой была Sonnet 4.6; на тех же промптах задания 20 и 21 при смене модели выросли на 5–7 процентных пунктов, а 19 и 23 упали на 14–19. Ещё раньше учеников проверял YandexGPT, а цифра точности в голове автора была измерена на Claude. Отдельно 9 октября прод переключили на Sonnet 5.5 без прогона регрессии и перемерили только 3 ноября: точное совпадение оказалось 71,5% против 74,2% на прежней модели, занижения выросли с 14,4% до 19,1%.
Были и другие расхождения входа и пути. В задании 19 текст задания не доходил до кодовых проверок именно в харнессе — после исправления точность на том же наборе поднялась с 34,9% до 48,8%. В задании 22 на машине для замеров не было файла с ключами ФИПИ, и 36,7% завышений оказались артефактом: с ключами их 6,7%. Регрессия задания 24 и вовсе мерит оценщик сайта и B2B API, а бот проверяет планы другим кодом: на десяти планах два пути разошлись в итоговом балле в четырёх случаях.
Второй тип самообмана — тихие нули. В задании 25 при сбое разбора ответа модели код молча подставлял ноль баллов; в октябрьском прогоне таких нулей было 16 на 110 кейсов. Восемь из них пришлись на ответы, где эксперт тоже поставил ноль, и засчитались как точное совпадение, остальные восемь записались в занижения. Вывод автора: замер должен идти тем же путём, что и ответ пользователя, и сам доказывать, что шёл именно им — теперь отчёт берёт имя модели не из конфига, а из ответов API, в ноябрьском прогоне это 497 вызовов из 497.
Почему это важно
История показывает типичную ловушку проектов с языковыми моделями: метрика может выглядеть убедительно и при этом измерять не ту модель, не тот вход или не тот путь обработки. Для бизнеса и владельцев сайтов это значит, что качество ИИ-функций стоит проверять на том же контуре, где работают пользователи, и фиксировать, какая именно конфигурация дала цифру. Для разработчиков урок конкретнее: тихие подстановки значений по умолчанию при сбоях искажают отчётность, а смена модели без прогона регрессии может месяцами оставаться незамеченной.
Источник: Habr. Материал пересказан ИИ-агентом.
