TL;DR
MABGrader — способ заставить LLM ставить оценки по шкале (в статье 0–7) стабильнее. Модель не называет балл «с ходу». Сначала она пишет защиту каждого возможного балла вместе с уверенностью. Потом та же модель в роли судьи проверяет эти защиты и оценивает каждую от 1 до 5. Какие защиты проверять чаще, решает простое правило из теории «многоруких бандитов» (UCB): чаще проверять тех, кто выглядит лучше, но периодически возвращаться к тем, кого проверяли мало. Побеждает балл с лучшей средней оценкой защиты.
Главная находка: LLM-судья нестабилен на сложных работах. Одну и ту же работу он оценивает то в 3, то в 5 баллов. Даже с эталонным решением и рубрикой (схемой начисления баллов) лучшие модели не дотягивают до согласия двух живых экспертов. Без эталона всё хуже: модель должна сама решить задачу, а потом проверить чужое решение, и качество падает сильно. Одна попытка даёт случайный разброс, а оценить готовый балл вместе с обоснованием модели проще, чем придумать балл с нуля.
Метод превращает «придумай оценку» в «выбери из готовых защищённых оценок». Для этого нужно 16 раундов выбора и оценивания. В статье метод превосходит прежний лучший подход к проверке доказательств, а ошибки в оценках заметно уменьшаются. Это цикл с запросами к модели, то есть автоматизация, а не разовый промпт. Но принципы из статьи (эталон и рубрика, несколько прогонов, защита каждого балла) можно использовать и в чате.
Схема метода
ШАГ 1 (отдельные запросы, по одному на каждый балл 0–7):
Модель получает задачу, решение, (эталон, рубрику) и «обязана» обосновать балл g
→ обоснование + самооценка уверенности
ШАГ 2 (цикл, 16 раундов):
UCB выбирает, какой балл проверять: чаще те, у кого оценка выше,
но реже проверенные тоже получают шанс
Модель-судья читает обоснование → ставит справедливость 1–5
ШАГ 3: усреднить оценки судьи по каждому баллу
→ итог: балл с лучшим средним
Шаги 1 и 2 требуют отдельных запросов. Цикл в оригинале автоматизирован кодом.
Пример применения
Задача: Вы руководите аналитикой в Авито и нанимаете продуктовых аналитиков. Приходит 60 тестовых заданий. Рубрика есть: 0–5 баллов за постановку гипотез, выбор метрик, корректность A/B-анализа, выводы. Эталонный разбор тоже есть. Одно задание вы прогнали через ChatGPT дважды и получили 2 и 4. Такой разброс не годится.
Метод в оригинале требует автоматизации. Ниже его упрощённая версия для чата: один запрос прогоняет все этапы. Она слабее оригинала, зато запускается за минуту.
Промпт:
Ты проверяешь тестовое задание кандидата на позицию продуктового аналитика в Авито.
<Рубрика>
За постановку гипотез — 0–1 балл, за выбор метрик — 0–1, за корректность расчёта эффекта A/B-теста — 0–2, за выводы и рекомендации — 0–1. Максимум 5 баллов. Ошибка в расчёте эффекта обнуляет и пункт про выводы.
<Эталон>
[вставить эталонный разбор]
<Решение_кандидата>
[вставить решение]
Работай по шагам.
ШАГ 1. Для каждого возможного итогового балла от 0 до 5 напиши защиту: 3–4 пункта, почему итог должен быть именно таким. Ссылайся на конкретные места решения и на рубрику. В конце каждой защиты укажи свою уверенность от 1 до 5.
ШАГ 2. Теперь выступи как судья. Прочитай защиты и по каждой поставь оценку справедливости от 1 до 5: насколько обоснование точно, подкреплено текстом решения и согласуется с рубрикой. Выдай короткое замечание к каждой.
ШАГ 3. Выбери балл с лучшей оценкой. Если лидеры близки, назови двух и укажи, чего не хватает для выбора. Верни итоговый балл и 2 главные причины.
Результат: Модель выдаст шесть защит (баллы 0–5), каждая с уверенностью. Потом таблицу оценок судьи по каждой защите с короткими замечаниями. В финале будет один итоговый балл с двумя причинами или два кандидата, если случай спорный. Спорные случаи сразу видны, и их стоит проверить вручную.
Почему это работает
Слабость LLM. Когда модель сразу называет балл, она не опирается ни на какие ориентиры и выдаёт то, что получилось в этом прогоне. Отсюда случайный разброс. В режиме «без эталона» всё ещё хуже: модели приходится одновременно решать задачу и оценивать чужое решение.
Сильная сторона LLM. Оценить готовый балл вместе с обоснованием проще, чем придумать балл с нуля. Обоснование служит якорем. Модель также хорошо пишет аргументы под заданную позицию и хорошо критикует чужие. Усреднение нескольких независимых оценок снижает случайные перекосы.
Как метод использует это. Каждый балл получает защиту, и судья сравнивает готовые аргументы. Чаще проверяются перспективные защиты, а очевидно слабые не тратят токены. Это дешевле, чем попарно сравнивать каждый балл с каждым (такой вариант авторы пробовали).
Рычаги управления: - Число раундов (в статье 16): меньше для простых случаев, экономия; больше для спорных. - Параметр c (в статье 0,25): балансирует «проверять лидера» против «проверять малоизвестных». Выше значение даёт больше широты, ниже даёт быстрее сходимость к лидеру. - Эталон и рубрика: самый сильный рычаг в статье. Но у слабых моделей эталон может мешать (см. ограничения). - Шкала судьи: у авторов 1–5 по «справедливости»; замените критерием под свою задачу, например «опирается на текст».
Шаблон промпта
Дословные промпты авторов в доступной части статьи не приведены. Шаблон ниже восстановлен по описанию «judgment-defense»: сначала защита балла, потом судья.
Ты — эксперт-проверяющий. Оцениваешь {тип_работы} по шкале от {мин} до {макс} баллов.
{условие_задачи}
{эталонное_решение}
{рубрика_с_баллами_и_штрафами}
{проверяемая_работа}
Для каждого возможного балла g от {мин} до {макс}:
Agent_Defender(g).justify() → 3–4 пункта: почему итоговая оценка работы = g.
Ссылайся на конкретные места в работе и на пункты рубрики.
Agent_Defender(g).confidence() → число от 1 до 5.
Agent_Judge — тот же эксперт, но теперь он судья.
For each g in [{мин}..{макс}]:
Agent_Judge.evaluate(Defense[g]) → справедливость от 1 до 5 + замечание.
(5 — обоснование точное, подкреплено текстом работы и рубрикой; 1 — выдумано или противоречит рубрике.)
Итоговый балл = g с лучшей оценкой судьи.
Если разрыв между двумя лучшими < 1 — назови обоих и укажи, чего не хватает для выбора.
Верни: итоговый балл, 2 главные причины.
Что подставлять: {тип_работы} — «тестовое задание аналитика», «доказательство», «ответ ассистента»; {мин}/{макс} — границы шкалы; {рубрика_с_баллами_и_штрафами} — главное, что вы должны подготовить заранее.
🚀 Быстрый старт — вставь в чат:
Вот шаблон MABGrader (защита каждого балла + судья). Адаптируй под мою задачу: [твоя задача проверки].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про шкалу, рубрику и эталон, потому что метод держится на рубрике и якоре-эталоне. Без рубрики защиты баллов превращаются в красивый вымысел. Она возьмёт паттерн «защитники и судья» и адаптирует под вашу задачу.
Ограничения
⚠️ Нет полного разбора в доступном тексте: материал обрывается на экспериментах. Результаты MABGrader по моделям и сравнение с другими методами я знаю в основном по аннотации.
⚠️ Оригинал — это цикл, а не промпт: 16 раундов выбора и оценки требуют автоматизации с API. Версия в чате проще и точность оригинала не гарантирует.
⚠️ Даже с эталоном модели ниже уровня экспертов: в режиме «с эталоном и рубрикой» лучшие модели так и не дотянули до согласия двух людей. В режиме «без эталона» качество падает сильно. Для олимпиадных доказательств автоматической проверке нельзя доверять без выборочной ручной проверки.
⚠️ Эталон может навредить слабым моделям: маленькие модели хуже следуют эталонному решению и начинают выдумывать. Они иногда показывают лучшую согласованность, когда эталона нет. Для слабых моделей проверяйте вручную, что эталон помогает.
⚠️ Не проверяйте моделью, которая писала работу: авторы нарочно исключили Claude Opus 4.6 из проверяющих, потому что он генерировал данные. Модель склонна завышать оценки собственной работе.
⚠️ Узкая область проверки: тестировали на 48 решениях USAMO 2025 и на синтетических данных. Перенос на тексты, код и презентации не проверен.
Как исследовали
Исследователи сначала решили проблему данных. Обычно берут решения, написанные моделями, и просят экспертов оценить. Это дорого, и нельзя контролировать, какие ошибки встретятся. Авторы пошли от обратного: взяли золотое решение USAMO 2025, сопоставили его с рубрикой и вставили ошибки, которые стоят конкретных баллов. Ошибку в фундаментальном шаге наказывали сильнее, так как она тянет за собой цепочку потерь. Получилось 48 решений, два эксперта оценили их независимо (согласие QWK 0,76; это метрика согласия оценщиков, 1 — идеал).
Чтобы масштабировать, придумали TROJAN: Claude Opus 4.6 внедряет ошибки, потом критикует себя и исправляет, пока критик не подтвердит несколько раундов подряд. Аудит 50 задач двумя экспертами показал QWK 0,78 с оценкой пайплайна.
Дальше сравнили 14 моделей в режимах «с эталоном и рубрикой» (Full) и «только задача и решение» (Blind). Методы: один ответ (CoT@1), среднее из 16 и голосование из 16. Выводы: Full легче Blind, прирост около 0,06 QWK; голосование из 16 стабильнее одного прогона (+5,5%). В Blind лучшие результаты не превышали 0,53 QWK, а в Full не дотянули до порога 0,70.
Удивило, что у некоторых малых моделей (GPT-5-mini, Qwen3-8B) согласие выше без эталона: с эталоном они пытались ему следовать и выдумывали. Практический вывод: не добавляйте эталон вслепую, проверьте на своей выборке. Затем авторы запустили MABGrader (16 итераций, c = 0,25) и получили прирост QWK на 26,4% к прежнему SOTA ProofGrader и снижение ошибки на 14%.
Адаптации и экстраполяции
🔧 Техника: другая модель в роли судьи → меньше самообмана
В шаблоне замените судью: пусть защиты пишет одна модель, а оценивает их другая (например, защиты из Claude, судья Gemini). Авторы избегали проверки той же моделью, которая генерировала данные (self-validation bias). Здесь тот же принцип: судья не должен узнавать «свой» стиль.
🔧 Техника: убрать шаг «Decision» → видеть спорные случаи
Не просите единый итог. Пусть модель выдаёт таблицу «балл → оценка судьи». Если два соседних балла почти равны, пометьте работу «на ручную проверку». В реальной работе это экономит время: вы просматриваете только неоднозначные случаи.
Ресурсы
- Статья: Can LLMs Reliably Grade Olympiad Proofs? A Study of Mathematical Verification with LLMs (NeurIPS 2026)
- Код и данные: https://github.com/aziksh-ospanov/TROJAN
- Авторы: Azim Ospanov, Zijin Feng, Ding Ding, Chengwu Liu, Haoli Bai, Jiacheng Sun, Lifeng Shang, Farzan Farnia; Huawei Foundation Model Department, Chinese University of Hong Kong, HKUST
- Упомянутые работы: MathArena (источник задач и рубрик), ProofGrader, ProofAutoGrader, UCB1 (Auer et al.)