Семь способов обмануть себя метриками: как я измерял точность ИИ-проверки ЕГЭ

В первой части я рассказал, как устроена проверка второй части ЕГЭ по обществознанию в моём боте: модель размечает ответ, код считает балл. Закончил обещанием рассказать, насколько точно это работает и сколько раз я обманывал себя метриками. Насчитал семь.

Сначала итог. В апреле 2026 года бот ставил тот же балл, что эксперт, в 50% ответов и завышал балл каждому третьему. В ноябре совпадает в 71,5% и завышает в 9,4%. Между этими цифрами полгода, четыре модели и семь случаев, когда число в отчёте означало не то, что я думал.

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

Что и как я меряю

Эталон — балл эксперта по критериям ФИПИ. Каждый кейс лежит в репозитории отдельным JSON-файлом: условие, ответ ученика, ожидаемый балл, допуск, категории ошибок. В наборе 433 кейса по заданиям 17–25. У 40 из них нет надёжного эталона, раннер их пропускает, поэтому оценивается 393.

Источников три:

• 343 кейса — реальные экзаменационные работы с эталонным баллом. Это рукописные сканы, пропущенные через распознавание, со всеми его артефактами;

• 33 — синтетические кейсы, которые я писал под конкретные правила: пример про «государство Z» там, где требуется Россия, отказ отвечать, ответ не по теме;

• 17 — работы, которые я переразметил сам, и проверки из режима учителя.

Для каждого кейса считается одна разность, и все метрики строятся из неё:

delta = got_score - expected_scoredirection = "overscore" if delta > 0 else ("underscore" if delta < 0 else "exact")overscoring_rate = over / n   # over — число кейсов с direction == "overscore"

Доля считается в кейсах, а не в баллах: ошибка на +1 и на +4 весят одинаково. Размер ошибки показывает MAE, среднее |delta|.

Главным показателем я считаю долю завышений. Заниженный балл ученик заметит и придёт спорить. Завышенный он примет с удовольствием и узнает правду на экзамене.

Вот все полные замеры по порядку:

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

Самообман 1. Харнесс мерил не то, что работает в проде

Самая глупая история, и повторялась она чаще всех.

Не та модель. Скрипт замера не загружал .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. Бот проверяет планы другим кодом. Когда я впервые прогнал десять планов по пути бота, совпали четыре, а на разметке из десяти планов два пути разошлись в итоговом балле в четырёх. Цифра по заданию 24 в таблицах ниже до сих пор относится к сайту, а не к боту.

Вывод: замер должен идти тем же путём, что и ответ пользователя, и сам доказывать, что шёл именно им. Теперь отчёт берёт имя модели не из конфига, а из ответов API: в ноябрьском прогоне это 497 вызовов из 497.

Самообман 2. Тихие нули прятали завышения

В первой части я упоминал это в разделе про отказоустойчивость, здесь расскажу со стороны метрик. В задании 25 при сбое разбора ответа модели код молча подставлял ноль баллов. В октябрьском прогоне таких нулей было 16 на 110 кейсов.

Восемь из них пришлись на ответы, где эксперт тоже поставил ноль, и засчитались как точное совпадение. Остальные восемь записались в занижения. После исправления картина по заданию стала такой:

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

У YandexGPT была родственная беда. На часть обычных экзаменационных заданий модель отвечала «Я не могу обсуждать эту тему», и отказ превращался в ноль баллов. На малом банке экспертных кейсов просадка задания 19 у YandexGPT была вызвана именно отказами, а не качеством оценки.

Лечится это одним правилом: статус проверки хранится отдельно от балла, и сбойный кейс в метрики не попадает вообще.

scored = [r for r in results if r.error != AI_UNAVAILABLE_ERROR]

В ноябрьском прогоне сбойных кейсов ноль, отказов модели ноль, тихих нулей ноль. Один кейс упал на первой попытке и прошёл на второй. Отдельной строкой в отчёте теперь идут нули с пустым или подозрительно коротким разбором: это почерк тихого нуля, который видно без эталона.

Самообман 3. 97%, которые ничего не измеряли

Задание 17 в отчётах выглядело образцово: 96,7% точного совпадения. Потом я посмотрел на эталоны. В 29 кейсах из 30 эксперт поставил максимум. Заглушка, которая не читает ответ и всегда ставит «2», набрала бы те же 96,7%. Коммит с исправлением так и называется: «task17: 96.7% was measuring nothing».

В набор пошли три синтетических кейса с нулевым эталоном: отказ отвечать, ответ не по теме, выдумка. А я с тех пор сравниваю точность не с нулём, а с лучшей константой, то есть с заглушкой, которая всем ставит самый частый в эталонах балл. На ноябрьском прогоне это выглядит так:

Считается это несколькими строками по сырым результатам прогона, модель для этого вызывать не нужно:

import jsonfrom collections import Counterrows = [json.loads(line) for line in open("raw_results.jsonl", encoding="utf-8")]for task in sorted({r["task"] for r in rows}):    rs = [r for r in rows if r["task"] == task]    score, hits = Counter(r["expected_score"] for r in rs).most_common(1)[0]    exact = sum(r["delta"] == 0 for r in rs)    print(task, f"бот {exact / len(rs):.1%}", f"всегда {score}: {hits / len(rs):.1%}")

В целом бот обгоняет константу вдвое. Но в трёх заданиях точное совпадение почти ничего не говорит. В 17-м и 25-м отрыв от заглушки составляет три и семь пунктов. В 18-м отрыва нет вовсе: бот, который всем ставит один балл из двух, показал бы ту же точность.

Это не значит, что проверка в этих заданиях бесполезна. Бот ошибается на других кейсах, чем заглушка, и объясняет, за что снял балл. Это значит, что мой набор для них не отличает хорошую проверку от никакой, и чинить тут надо набор.

Самообман 4. Точность без направления ошибки

Бот запустился летом 2025 года, а первый полный замер я сделал 22 апреля 2026-го. До этого у меня было ощущение «проверяет нормально». Замер показал 50,0% точного совпадения и 33,6% завышений.

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

Ещё раньше то же самое показывал маленький банк из 26 разобранных вручную расхождений с экспертом: в 21 случае бот завысил, в 4 занизил, в 1 совпал. Чаще всего он:

• не замечал фактическую ошибку (7 случаев);

• засчитывал некорректное суждение или обратную логику (6);

• принимал пересказ условия за аргумент (4);

• подменял контекст задания (4);

• засчитывал абстрактную формулировку вместо примера (4).

Два примера из синтетики, чтобы было понятно, о чём речь. Ответ «В России полиция поддерживает общественный порядок и борется с преступностью» описывает функцию органа, а не его действие. Эталон 0 из 3, YandexGPT поставил 3 из 3. Пример «Суд государства Z вынес решение о взыскании долга» конкретен, но задание требовало примеров про Россию.

Подозреваю, что перекосу помогал и мой собственный промпт. В нём стоит экспертное правило «снижай балл только при наличии явной, бесспорной ошибки». Человек применяет его в пограничных случаях. Модель, похоже, читает его как презумпцию в пользу балла.

И отдельный штрих к теме самообмана. В этом банке один кейс помечен как «крупнейшее занижение, сдвиг −4». По цифрам в нём эксперт поставил 1, бот 5. Это завышение на 4 балла: знак перепутан уже в разметке.

Самообман 5. Защита от завышений рождает занижения

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

• Задание 19. Перепроверка «показано ли конкретное действие органа» в первой версии срабатывала на всех вариантах задания, хотя нужна примерно для трети. Там, где по условию действует семья или гражданин, она снимала до двух баллов с верных ответов.

• Задание 25. Перепроверка конкретности примеров обнулила синтетический ответ с двумя верными примерами. Помог подтверждающий проход поверх перепроверки: с ним тот же ответ получает свои 2 балла.

• Задание 24. После правок разбора плана завышения упали с 13,5% до 5,4%, а занижения выросли с 29,7% до 35,1%.

• Снова задание 19. В сообщении одного коммита значилось «завышения 30,0% → 16,7%». Разбор показал, что на чистых кейсах, без артефактов распознавания, точность не выросла: 75,0% до и 71,4–75,0% после. В репозитории осталась поправка: цитировать эту пару цифр как достижение нельзя.

Самый крупный случай — ноябрьский прогон на новой модели. По главному показателю это лучший результат за всю историю: 9,4% завышений. А вот что за ним стоит:

Бот стал заметно строже. В 134 кейсах, где эксперт поставил ноль, он соглашается в 91%. В 99 кейсах, где эксперт поставил максимум, он снимает баллы в 27. В среднем по набору бот недодаёт 0,16 балла на ответ. Четыре синтетических ответа на задание 19, написанные как образцовые, получили 2 из 3.

Для тренажёра такая ошибка безопаснее завышения, но ученик теперь чаще недополучает баллы за верный ответ. По одной доле завышений этого не видно. Правку стоит считать удачной, только если завышений стало меньше, а занижений не стало больше.

Самообман 6. Два прогона одной модели — не два мнения

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

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

В коде это хвост перепроверки К2, здесь в сокращении, без логирования:

    agreed = _agreed_finding(candidates, _deductible_findings(second, plan_text))    if agreed is None:        return k2, payload    # Четвёртый фильтр (калибровка 14.08.2026): согласие двух прогонов ловит    # общий ложный стереотип модели, а не только ошибку ученика — на эталонных    # планах банка оба прогона дружно «находили» несуществующую ошибку.    # Отдельный верификационный прогон обязан подтвердить, что названного    # вида/функции действительно не существует в школьном курсе; не смог    # прогон состояться или не подтвердил — балл сохраняется.    verified = await _verify_k2_finding(plan_text, topic, agreed, llm_client)    if verified is not True:        return k2, payload    return 0, payload

Самый дешёвый тест: эталон как ответ

Из этой истории вырос приём, который я советую всем. Берём эталонные ответы из банка и подаём их в проверку как ответы ученика. Все обязаны получить максимум. Разметка не нужна, эксперт не нужен, для детерминированной части не нужна даже модель.

В задании 24 этот тест работал трижды:

• в июле максимум по К1 получали 163 эталонных плана из 199; после двух правок сопоставления — 183, потом 195;

• позже, когда в банке осталось 185 тем, проходили все 185, и тест казался закрытым;

• в октябре я заменил в заголовках эталонов слова на синонимы, «Признаки» на «Особенности». Максимум получили 147 планов, ещё 24 получили 2 балла из 3, а 14 — ноль. После правки с группами синонимов снова проходят все 185.

Третий пункт появился не сам. На аудите три верных синтетических плана получили в боте ноль во всех 12 оценках из 12. Причины были прозаичные: синоним в заголовке и парсер, который ломался на подпунктах через тире. Разбор при этом уверенно называл «пропущенный аспект» и ссылался на учебник, которого в источниках нет.

У теста есть предел: он ловит только занижения. Система, которая ставит максимум всему подряд, пройдёт его идеально. И он проверяет только те формулировки, которые вы в него положили, что и показала история с синонимами.

Самообман 7. Сравнения, в которых поменялось всё сразу

В первой части я написал, что на одних и тех же 202 ответах Claude совпал с экспертом в 65,8% случаев, а YandexGPT в 54,5%. Это правда, и вот полная таблица:

Ответы действительно одни и те же. Но прогон YandexGPT сделан 20 мая, а прогон Claude 5 августа. Между ними два с половиной месяца правок промптов, и у Claude уже были подключены ключи ФИПИ. Так что таблица сравнивает не две модели, а две версии всей системы. Чистое сравнение на одном коммите я так и не сделал.

Ровно та же проблема у свежего сравнения «октябрь против ноября». Между прогонами изменились четыре вещи:

1. модель: Sonnet 4.6 → Sonnet 5.5;

2. промпты: из семи заданий убран блок с чек-листом типичных ошибок и допусками;

3. код задания 24;

4. сам набор: удалены три кейса.

Задание 18 за это время упало с 97,4% до 64,1%. Виновата модель или убранный блок с допусками, по этим данным сказать нельзя. Нужен ещё один прогон: новая модель на старых промптах. Он стоит около 9 $, и его надо было сделать до переключения прода, а не после.

Шум, который легко принять за результат

Каждая цифра выше — один прогон. Насколько ей можно верить, зависит от задания. В задании 19 два независимых прогона одного кода дали одинаковые баллы во всех 43 кейсах. В задании 25 при одном коде меняются 3 кейса из 35, это ±8,6 пункта. В задании 24 — 6 из 37.

Поэтому красивый результат одной из правок задания 25, «0,0% завышений», в отчёте сопровождается пометкой «публиковать нельзя»: соседний прогон того же кода дал 5,7%. А разница в 5,4 пункта по завышениям в задании 24 — это два кейса.

Колонка, которая называлась не так

Последнее в этом ряду. В отчётах есть колонка «±1 tolerance», в ноябре в ней 84,0%. На деле раннер проверяет условие abs(delta) <= fixture.tolerance.score_delta, то есть попадание в допуск конкретной фикстуры, а у 205 фикстур из 436 допуск нулевой. Настоящая доля ответов, где бот ошибся не больше чем на балл, в ноябрьском прогоне равна 92,6%. Здесь я обманывал себя в худшую сторону, но причина та же: подпись разошлась с формулой.

Ноябрь: где всё это сейчас

Полный прогон 3 ноября, боевая конфигурация: Claude Sonnet 5.5, все перепроверки включены, кэш ответов выключен. 393 оценённых кейса, 497 вызовов модели, 59 минут, 8,87 $.

python -m tests.regression.runners.run_regression --model claude --subject social --no-cache

* Задание 24 измерено по пути сайта и B2B API, не бота.

То же по источникам кейсов:

Что здесь видно.

Сильнее всего задание 22. Оно же сильнее всех оторвалось от константной заглушки: 97,0% против 42,4%. Это задача-ситуация с ключом ФИПИ, и модели есть с чем сверяться.

Слабее всего задание 23. Половина совпадений и единственное место, где завышений больше четверти. Нужно найти норму Конституции и не перепутать, кому она адресована, и здесь бот ошибается в обе стороны.

Синтетика не дала ни одного завышения. Все восемь промахов на ней — занижения, пять из них на ответах, которые я писал как полностью верные. Кейсы-ловушки бот теперь отлавливает без промахов, а хорошие ответы иногда режет.

Хуже всего дела на 17 кейсах с моей разметкой. Их слишком мало для выводов, но 41% там, где эталон ставил я сам, — повод расширять именно эту часть набора.

Что сработало и что нет

За полгода набрался список правок с измеренным эффектом. В таблице точное совпадение и завышения до и после, каждая правка проверялась на кейсах своего задания.

К таблице три наблюдения.

Лучше всего работало то, что забирало работу у модели. Ключ ФИПИ вместо «общего понимания обществознания», арифметика штрафа в коде вместо промпта, сверка плана по леммам. Подключение ключей по всему набору в один день подняло точность с 65,7% до 70,7%.

Few-shot помогает, где граница фактическая, и вредит, где она в рассуждении. В задании 23 примеры помогли. В 18 и 20 модель начинала противоречить собственным примерам, и завышений становилось больше.

Старшая модель не значит более строгая, а промпты не переносятся между версиями. Opus в задании 18 оказался щедрее Sonnet. А одна попытка добавить в промпт задания 19 большой методический блок дала минус три пункта точности и 11 отказов модели на 44 кейса.

Чего эти цифры не показывают

После семи историй самообмана было бы странно выдать восьмую цифру за окончательную. Вот что в ноябрьских 71,5% слабого.

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

• В наборе много мусора распознавания. На августовском срезе метки «нечитаемо» и «зачёркнуто» несли 82 кейса из 376. На них бот совпадал с экспертом в 52,4% случаев, на чистых в 75,9%. Доля завышений при этом почти одинаковая, 14,6% и 13,9%: главный показатель к качеству набора устойчив, точность нет.

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

• Мало кейсов на задание. Везде, кроме 25-го, их от 27 до 43. Один кейс сдвигает показатель задания на 2,3–3,7 пункта.

• Эталоны не безупречны. У части фикстур есть известные дефекты разметки, а люди на экзамене сами расходятся: не зря работу проверяют два эксперта, а при существенном расхождении назначают третьего. Сто процентов совпадения с одним эталоном здесь не потолок и не цель.

• Часть путей не покрыта. Задание 24 измерено по пути сайта, задания 21 и 22 в харнессе идут через оценщик режима учителя, а не ученика. Фотографии и распознавание в боте не измеряются вовсе.

• Один прогон — одно измерение. Про шум между прогонами см. выше; прогон, который отделит эффект новой модели от эффекта новых промптов, не сделан, так что этот вопрос остаётся открытым.

Что бы я сделал иначе

Если бы я начинал измерять точность сначала:

• Замер по боевому пути с первого дня. Харнесс должен вызывать тот же код и ту же модель, что прод, и писать в отчёт имя модели из ответа API. У меня на это ушло несколько отдельных исправлений, и задание 24 до сих пор мерится не по пути бота.

• Статус проверки отдельно от балла. Сбойный кейс не должен попадать ни в точность, ни в занижения. Шестнадцать тихих нулей прожили в метриках до октября.

• Константная заглушка рядом с каждой цифрой точности. Если она набирает столько же, чинить надо набор, а не промпт.

• Три числа вместо одного. Совпадения, завышения и занижения. Правка, которую оценивают по одному из них, портит остальные незаметно.

• Кейсы, на которых защита обязана промолчать. Перепроверки в заданиях 19 и 25 сначала ломали верные ответы, и видно это было только на таких кейсах.

• Эталоны как ответы. Бесплатный тест на занижения, который стоило завести раньше первого промпта.

• Одна перемена за прогон. Сейчас я не могу сказать, что уронило задание 18, потому что модель и промпты поменялись одновременно.

И последнее. Свежая цифра в этой статье хуже предыдущей: 71,5% после 74,2%. При этом она кажется мне самой полезной в таблице: она измерена на боевой модели, без тихих нулей, с разбивкой по направлению ошибки, и я знаю, чего она не показывает.