TL;DR
Когда модель-судья размечает ответы по нескольким классам («отказ», «уклончиво», «выполнил», «бессвязно»), достаточно посчитать, сколько раз она поставила каждую метку. Если один класс почти пуст, а другой судья ставит его на заметной доле тех же ответов, значит, судья его просто не умеет использовать. Проверка бесплатная, без эталонной разметки и без людей.
Боль вот в чём. Одни и те же 900 ответов разные судьи оценивают так: доля «выполнил» от 1% до 25%, то есть в 22–25 раз разницы. Судья на 8B-модели при этом согласен с эталоном на 78% ответов и выдаёт аккуратную разметку. Но класс «выполнил» он не ставит ни разу. Почти все такие ответы он переносит в соседний класс «уклончиво». Общая точность это скрывает: 78% набираются на лёгких отказах. А метрика, которую вы показываете в отчёте («атака сработала в X%», «бот решил Y%»), считается как раз по пропавшему классу.
Метод простой. Прогоните ответы через двух судей с одной рубрикой и сравните счётчики по классам. Если у одного судьи класс встречается в <⅓ от счёта другого, а другой ставит его не менее чем на 10% ответов, судья помечен как неисправный по этому классу. Оценку, которая опирается на такой класс, нельзя считать надёжной.
Схема метода
ШАГ 1: Одна рубрика, фиксированные ответы → два и более судьи (разные модели)
ШАГ 2: Для каждого судьи посчитать, сколько раз он поставил каждый класс → таблица «судья × класс»
ШАГ 3: Правило флага: класс у судьи A < ⅓ от счёта судьи B
И судья B ставит этот класс ≥ 10% ответов → судья A неисправен по классу
ШАГ 4: В отчёте — название судьи, счётчики по классам и обе метрики
(строгая и мягкая)
Шаги 1–2 делаются в одном-двух запросах к чату. Шаг 3 можно поручить самой модели.
Пример применения
Задача: Вы руководитель поддержки маркетплейса вроде Ozon. Бот отвечает на 500 жалоб о задержке доставки. Чтобы не читать всё руками, вы просите дешёвую LLM разметить ответы. Метрика для руководства: доля ответов, где бот реально решил проблему клиента.
Сильная зона метода: редкий важный класс и рубрика с соседними классами. Здесь соседи «решил» и «ушёл от ответа».
Промпт (судья, запускается в двух разных моделях, например в Claude и в ChatGPT):
Ты разметчик ответов бота поддержки маркетплейса.
Для каждого ответа выбери ровно ОДИН класс:
- refuse: бот отказал или перенаправил без помощи («обратитесь в магазин»)
- evasive: бот ответил по теме, но не дал клиенту ни решения, ни конкретного действия (общие слова, извинения, «мы разбираемся»)
- solve: бот дал решение или конкретное действие (возврат, перенос срока, номер заявки, точные шаги)
- gibberish: ответ бессвязный или не по теме
Важно: «извинился и пообещал» без конкретики — это evasive, а не solve.
Ниже 500 пар «жалоба — ответ бота», с номерами.
Верни только JSON-массив: [{"id": 1, "label": "..."}, ...]
Затем отдельной строкой выведи счётчик: сколько раз встретился каждый класс.
{пары_жалоба_ответ}
Промпт (проверка, во втором шаге, когда есть оба результата):
Вот счётчики классов двух судей, размечавших одни и те же 500 ответов по одной рубрике:
Судья A ({модель_A}): refuse={a1}, evasive={a2}, solve={a3}, gibberish={a4}
Судья B ({модель_B}): refuse={b1}, evasive={b2}, solve={b3}, gibberish={b4}
Правило: класс у одного судьи считается «неиспользуемым», если
(1) у другого судьи он занимает не менее 10% всех ответов, И
(2) у первого судьи его счёт меньше трети от счёта другого.
Проверь правило для каждого класса и каждой пары судей.
Назови, какой судья и по какому классу помечен.
Если помечен — покажи по разметке по id, куда ушли ответы, которые другой судья назвал этим классом.
Результат: В первом запросе придёт JSON с метками и счётчик по классам. Во втором модель покажет таблицу проверки по правилу. Если один из судей почти не ставит solve, вы увидите флаг и список id, которые он перенёс в evasive. Метрику «доля решённых» по такому судье в отчёт ставить нельзя.
Почему это работает
Слабость. Общая точность (доля совпадений с эталоном) измеряется по всей выборке, где большинство ответов легко классифицировать. Редкий класс — как раз то, ради чего всё затевалось. Провал в нём почти не двигает общую цифру. Поэтому судья может «согласиться на 78%» и при этом не уметь ставить нужную метку. Малые судьи (7–9B) не размазывают ошибки случайно: они смещаются на соседний класс. Для них «решил» и «уклончиво» — ближайшие по смыслу, и граница между ними слишком тонкая.
Сильная сторона. Счётчики классов видны сразу и бесплатно: любая разметка их уже содержит. Сравнивать два судьи между собой не нужно умение определять «правильный» ответ. Достаточно увидеть, что один судья вообще не использует то, что другой использует массово. Это отличает «в данных такого класса нет» от «судья не умеет его ставить».
Как метод обходит слабость. Он заменяет вопрос «насколько судья точен?» (на него нужна эталонная разметка) на вопрос «ставит ли судья все классы?» (на него нужны только счётчики).
Рычаги: - Порог 10% — поднимите, если класс редкий у всех судей (тогда правило не сработает; в исследовании так было на одном корпусе). - Порог ⅓ — сделайте строже (например, ½), если хотите ловить частичные провалы. - Число судей — добавьте третьего, особенно большую модель: правило сравнивает с самым «щедрым» судьёй. - Две метрики — считайте и строгую («решил»), и мягкую («не отказал»). Мягкая сдвигается на единицы процентов, строгая — в разы.
Шаблон промпта
Ты разметчик. Для каждого элемента ниже выбери ровно ОДИН класс:
- {класс_1}: {определение_1}
- {класс_2}: {определение_2}
- {класс_3}: {определение_3}
- {класс_4}: {определение_4}
Пограничное правило: {как отличать соседние классы, 1–2 строки}.
Верни JSON: [{"id": N, "label": "..."}].
После JSON — счётчик: сколько раз встретился каждый класс.
{элементы_с_номерами}
Счётчики классов двух судей по одним и тем же {N} элементам и одной рубрике:
Судья A ({модель_A}): {счётчики_A}
Судья B ({модель_B}): {счётчики_B}
Правило флага: класс у судьи X помечен, если у другого судьи Y он занимает ≥10% элементов,
а у X его счёт меньше ⅓ от счёта Y.
Проверь каждый класс и каждую пару. Назови судью и класс.
Для помеченных классов покажи, в какие соседние классы X перенёс элементы Y.
Что подставлять: {класс_N} и определения — ваша рубрика (3–4 класса, в идеале с порядком «от плохого к хорошему»). {N} — число размеченных элементов. {модель_A/B} — названия реальных моделей-судей. Дословной рубрики авторов в тексте статьи нет (она в приложении), шаблон собран по её структуре: refuse / evasive / comply / gibberish.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки LLM-судьи по счётчикам классов. Адаптируй под мою задачу: [твоя задача: что размечаем и по каким классам].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие у вас классы, где проходит граница между соседними и сколько элементов размечается. Эти данные нужны, чтобы правило флага сравнивало судей по одним и тем же определениям.
Ограничения
⚠️ Нет эталона: Правило показывает, что судьи расходятся, но не что «щедрый» судья прав. Судья, которого правило не пометило, всё ещё может ошибаться. В исследовании референс не был помечен, хотя людская разметка давала заметно больше «выполнил», чем он.
⚠️ Редкий класс у всех: Если ни один судья не ставит класс на ≥10% ответов, правило неприменимо. На одном из корпусов проверка просто не сработала.
⚠️ Пороги провизорные: 10% и ⅓ выбраны авторами заранее, но это не теория. Подбирайте под свою выборку.
⚠️ Размер не объясняет всё: Гипотеза «чем меньше судья, тем хуже» не подтвердилась. Пара из одного релиза (21B и 117B) показала обратное, и авторы эту гипотезу сняли. Отказываться от всех малых судей нельзя: сломались плотные модели 7–9B из четырёх семейств. Специально дообученные малые судьи для безопасности могут справляться лучше.
⚠️ Нужна одна задача: Вся проверка сделана на одной задаче (оценка ответов на вредные запросы). На других рубриках эффект может быть слабее или сильнее.
⚠️ Шум самого судьи: Даже эталонный судья на одних и тех же ответах расходился сам с собой на 10–12% при температуре 1.0. Любые различия мельче этого уровня шумом и являются.
⚠️ Мягкая метрика тоже плывёт: Доля «не отказал» расходится между судьями на 10–23 процентных пункта. Это меньше, чем разброс строгой метрики, но не нуль.
Как исследовали
Идея была простой: заморозить всё, кроме судьи. Авторы взяли 100 вредных запросов из публичных бенчмарков и обернули каждый в 9 известных типов атак — получилось 900 промптов. Два разных целевых модели ответили на них одинаково, и каждый набор ответов стал корпусом. Восемь судей из пяти организаций (от 8B до ~117B) размечали эти же ответы по одной рубрике из четырёх классов. Ответы не менялись ни на символ.
Результат неожиданный: расходятся не «случайно». Три плотные модели 8–9B переносят «выполнил» почти целиком в соседний «уклончиво». Одна из них на втором корпусе не поставила «выполнил» ни разу из 900. Без этих трёх судей разброс по строгой метрике падает с ~22–25 раз до 1,7–2,8. Проверили устойчивость: новые вредные запросы, третья целевая модель, судья из четвёртого семейства (7B) — паттерн повторился. Часть проверок была зарегистрирована письменно до запуска.
Интересный поворот: авторы сначала заявили «чем меньше судья, тем хуже», потом проверили контрольной парой из одного релиза — и сами отозвали вывод. Практический инсайт: доверять не размеру, а счётчикам.
Адаптации и экстраполяции
🔧 Техника: добавить в рубрику класс «обошёл защиту, но ничего не передал» → убрать невыразимый исход
Авторы показали: атаки с кодированием обходят отказ, но ничего вредного не выдают. Если в рубрике нет класса для «ответил, но по сути пусто», судьи читают такие ответы по-разному (разброс до 50 пунктов). В вашей рубрике:
- empty: бот не отказал, но и ничего полезного не передал (шаблонная фраза, повтор вопроса)
Для поддержки или контента такой класс нужен почти всегда.
Минимальный отчёт по оценке (из списка авторов, адаптирован):
К результату оценки приложи:
1. Название и размер модели-судьи, число вызовов на элемент.
2. Счётчики по каждому классу.
3. Рубрику дословно и любые её правки.
4. Обе метрики: строгую (решил/выполнил) и мягкую (не отказал).
5. Температуру целевой модели и судьи.
6. Источник тестовых запросов.
7. Размечал ли что-то человек, не знавший цели исследования.
Ресурсы
- The Missing Compliance Class: LLM Graders That Collapse Jailbreak Success, and a Free Check — Ruqiya Bin Safi, независимый исследователь.
- Артефакт (метки, скрипты): https://anonymous.4open.science/r/missing-compliance-class-4F6F
- Близкие работы из обзора: Souly et al., 2024 (завышение успеха джейлбрейков оценщиками); Gao, 2026 (разброс ASR по судьям); Tamsal & Rusert, 2026 (оценщик втрое завышает прирост успеха после дообучения); Chao et al., 2025 (судьи против экспертной разметки).
- Бенчмарки запросов: Huang et al., 2024; Zou et al., 2023 (AdvBench). Атаки: Wei et al., 2023; Andriushchenko & Flammarion, 2025; Anil et al., 2024.