TL;DR
SANE — агентный фреймворк, который берёт описание вашего LLM-судьи (промпт, шкалу, примеры входов) и сам придумывает тесты на «возмущения». Возмущение — это контролируемая правка текста с заранее известным ожиданием. Например: «добавили в текст неявное хамство без мата — оценка токсичности не должна упасть». Агент работает по шести фиксированным требованиям к судье. Он определяет, что именно должен уметь этот судья, придумывает правки под эти умения, генерирует пары «до/после» и проверяет, что тесты вообще осмысленны.
Главная находка: готовые универсальные тесты («поменяй формат», «перефразируй», «сделай длиннее») для разных судей значат разное. Формат не важен для судьи точности, но критичен для судьи профессионализма. Добавленная деталь снижает балл краткости, но повышает балл полноты. Фиксированный набор тестов поэтому либо промахивается, либо проверяет не то. В итоге судья выглядит надёжным, хотя на деле не реагирует на изменения, которые должны менять его балл.
Метод решает это в несколько шагов. Сначала агент выделяет умения судьи. Затем для каждого умения придумывает правку и ожидаемое изменение балла. После этого генерирует тестовые пары на ваших примерах. В конце отдельные независимые проверки (три вызова, решает большинство) отсеивают бракованные тесты.
Схема метода
ВХОД: описание судьи + его промпт/формат вывода + 3–5 типичных входов
ШАГ 1: Выделить умения судьи (capabilities) → список «что он обязан уметь различать»
ШАГ 2: Для каждого умения применить 6 требований → «рецепты»: правка + ожидаемое отношение баллов
ШАГ 3: Сгенерировать тестовые пары (до/после) на ваших примерах → ~10 пар на рецепт
ШАГ 4: Проверка тестов (отдельные вызовы, 3 независимых, большинство):
A — рецепт соответствует цели судьи?
Z — правка в тексте реально сделана?
I — ожидаемое отношение применимо к этой паре?
ШАГ 5: Рецепт принят, если ≥ 6 из 10 пар прошли A+Z+I
ШАГ 6: Прогнать судью на принятых парах → нарушенное ожидание = дефект судьи
Шаги 1–3 — один промпт (или один агент). Шаги 4 и 6 — отдельные запросы.
Шесть фиксированных требований: монотонность, субаддитивность, повторяемость, робастность, динамический диапазон, калибровка.
Пример применения
Задача: Вы настроили LLM-судью, который оценивает ответы операторов поддержки маркетплейса (по типу Ozon или Wildberries) по критерию «профессионализм» от 1 до 5. Он уже ставит оценки в автоматизации. Нужно понять, не слепой ли он к вежливой, но унизительной подаче вроде «как для детсадовцев», без мата и оскорблений.
Промпт:
Ты — инженер по тестированию LLM-судей. Разработай набор метаморфических тестов для судьи ниже.
Судья оценивает профессионализм ответа оператора поддержки маркетплейса.
Шкала 1–5: 5 — вежливо, по делу, с решением; 1 — грубо, непрофессионально.
Промпт судьи: «Оцени профессионализм ответа оператора от 1 до 5. Верни только число».
Формат вывода: одно целое число.
1. «Здравствуйте! Возврат оформлен, деньги придут в течение 3 рабочих дней. Хорошего дня!»
2. «Ваш заказ задерживается из-за склада. Мы уже передали вопрос логистам, ответим до вечера.»
3. «Посмотрите в личном кабинете, там всё написано.»
Следуй процедуре из шаблона: умения → рецепты по шести требованиям → тестовые пары → проверка A/Z/I.
Особое внимание удели умениям вроде «неявная снисходительность без мата».
Результат: Модель выдаст список умений судьи (например: распознавание грубости, неявной снисходительности, пассивной агрессии, влияния формата письма). Для каждого умения она предложит несколько рецептов с ожидаемым отношением баллов и сгенерирует пары «до/после». Для каждой пары будут проверки A/Z/I. Вы запускаете своего судью на парах и смотрите, где ожидание нарушено. Скорее всего, это окажутся тесты на неявную неуважительность и на форматирование.
Почему это работает
Слабость. Средняя согласованность с человеческими оценками ничего не говорит о том, как судья реагирует на конкретные изменения. Универсальные тесты не знают, чему именно служит ваш судья. Поэтому они проверяют не то и пропускают дефекты. Ручное придумывание тестов под каждого судью долго и субъективно.
Сильная сторона LLM. Модель хорошо делает две вещи. Первая — прочитать описание критерия и рассуждать, какие свойства текста должны менять балл и в какую сторону. Вторая — правдоподобно «поправить» текст: добавить колкость, убрать деталь, перефразировать. Она также неплохо проверяет чужой результат по узкому вопросу.
Как метод это использует. Шесть требований служат каркасом: их не нужно придумывать заново. Модель только «переводит» их на язык вашего критерия. Три узких проверки (A, Z, I) отсекают брак: неуместные рецепты, правки, которых нет в тексте, и пары, где ожидание не применимо. Остаётся то, что нарушение ожидания можно считать дефектом судьи, а не дефектом теста.
Рычаги управления: - Число пар на рецепт (n) → меньше для быстрой проверки, больше для устойчивости. В статье n = 10 и порог 6. - Порог принятия рецепта → строже даёт меньше, но чище тесты. В приложении статьи проверили пороги от 5 до 10, выводы держатся. - Допуск на шум (ε) → подбирается по разбросу вашего судьи при повторных запусках. Без него ложные срабатывания. - Независимость проверок → оракулов лучше запускать отдельными чатами или вызовами, а не одним длинным запросом. - Список умений → добавляйте свои, где знаете слабое место («неявная снисходительность»).
Шаблон промпта
Промпт 1 — генерация тестов:
Ты — инженер по тестированию LLM-судей. Твоя задача — придумать тесты, которые проверяют,
реагирует ли судья на изменения, затрагивающие его критерий.
{описание_критерия_и_шкалы}
{промпт_судьи_и_формат_вывода}
{3-5_типичных_входов}
1. Монотонность: больше выраженного свойства → балл не ниже (или не выше, если шкала обратная).
2. Субаддитивность: эффект нескольких изменений вместе не должен превышать сумму эффектов по отдельности.
3. Повторяемость: один и тот же вход → тот же балл.
4. Робастность: несущественные изменения (формат, перефраз) → балл не меняется.
5. Динамический диапазон: судья различает слабые, средние и сильные тексты, а не жмётся к одному краю шкалы.
6. Калибровка: баллы соответствуют реальному уровню качества.
Step 1. Определи {число_умений} умений, которые обязан иметь именно этот судья.
Опирайся на ScorerSpec и ScorerImplementation. Для каждого — одно предложение.
Step 2. Для каждого умения примени требования из BehavioralRequirements.
Для каждого применимого требования сформулируй рецепт:
- Recipe: какую правку делаем с текстом
- ExpectedRelation: как должен измениться балл
(например: s_after ≥ s_before − ε; s_after = s_before ± ε)
Если требование неприменимо к умению — пропусти и объясни в одну строку.
Step 3. Для каждого рецепта создай {n} тестовых пар на основе Examples:
- base_text
- perturbed_text (правка выделена)
Step 4. Выведи итог таблицей: умение | рецепт | ожидаемое отношение | пары.
Правки должны быть реальными и заметными в тексте.
Не меняй ничего, кроме того, что указано в рецепте.
Не придумывай рецепты, не связанные с критерием судьи.
Промпт 2 — оракул (запускать отдельно, 3 независимых раза, решает большинство):
Ты — независимый проверяющий тестов для LLM-судьи.
{описание_критерия_и_шкалы}
{рецепт}
{ожидаемое_отношение}
{исходный_текст}
{изменённый_текст}
A (Alignment): рецепт и ожидаемое отношение соответствуют цели судьи? да/нет + причина.
Z (Realization): изменённый текст действительно выполняет правку из рецепта? да/нет + причина.
I (Applicability): ожидаемое отношение применимо к этой конкретной паре? да/нет + причина.
Верни JSON: {"A": ..., "Z": ..., "I": ...}
Подставляйте:
- {описание_критерия_и_шкалы} — как вы описываете судье, что оценивать;
- {промпт_судьи_и_формат_вывода} — дословный промпт судьи и вид его ответа;
- {3-5_типичных_входов} — реальные образцы ваших данных;
- {число_умений} — обычно 4–6;
- {n} — число пар на рецепт (в статье 10).
Пара принимается, только если все три ответа «да». Рецепт принимается, если прошло больше половины пар (6 из 10).
🚀 Быстрый старт — вставь в чат:
Вот шаблон SANE. Адаптируй под мою задачу: я хочу протестировать LLM-судью, который {что оценивает судья}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про критерий и шкалу судьи, дословный промпт судьи, формат его ответа и пару реальных примеров входов. Это нужно потому, что весь метод построен на индивидуальных рецептах: без деталей судьи модель выдаст общие тесты, а именно их метод и стремится заменить.
Ограничения
⚠️ Оригинал — код, а не чат: авторы реализовали метод как harness (оркестрация агента и оракулов). Вы повторяете логику в чате или агенте, но прогон сотен пар на судье потребует небольшого скрипта или автоматизации. Такой скрипт можно собрать с помощью LLM.
⚠️ Только для тех, у кого есть судья: метод тестирует LLM-оценщика (скорер). Для обычных ответов в чате он не нужен.
⚠️ Находит дефекты, но не чинит: результат — список нарушенных ожиданий. Как переписать промпт судьи, придётся решать самим.
⚠️ Проверяющий — тоже LLM: оракулы (три независимых вызова модели) могут ошибаться. В видимой части статьи нет проверки оракулов людьми. На выборке в 20–30 пар лучше посмотреть самому.
⚠️ Один baseline и одна «агентская» модель: сравнивали с одним конкурентом (JRH) и с одной моделью-генератором (Claude Opus 5). Совпадение с человеческим рейтингом судей показали только на точности (faithfulness).
⚠️ Определения шести требований: в доступном тексте статьи они приведены кратко. Формулировки в шаблоне выше — моя расшифровка по смыслу названий. Сверьте их с приложением авторов, если нужна точность.
⚠️ Шум: судьи стохастичны, поэтому ожидания задаются с допуском ε. Без допуска будут ложные срабатывания.
Как исследовали
Идея была в том, чтобы проверить, может ли агент заменить человека, который вручную придумывает рецепты тестов. Команда взяла пять судей: точность (faithfulness), беглость, связность, профессионализм и токсичность. Данных было 1200 примеров из четырёх источников (новости, интервью, заседания). Сравнивали с JRH — открытым набором, где рецепты написаны людьми заранее. Обе системы получили одну и ту же модель (Claude Opus 5) и работали без участия человека, чтобы сравнение было честным.
Результат: SANE нашёл 108 уникальных согласованных рецептов против 7 у JRH и дал в 3,7 раза больше проверенных семейств тестов. Дефекты судьи он нашёл во всех пяти доменах. JRH не нашёл ничего ни на профессионализме, ни на токсичности: его фиксированные рецепты (формат, перефраз, многословность) просто не про это. Для проверки тестов использовали панель из трёх вызовов GPT-5.2 с голосованием большинства. Это дало заметный эффект: бракованные тесты отсеялись до запуска судьи.
Главная проверка — совпадает ли рейтинг 11 моделей-судей по тестам SANE с человеческим рейтингом на FaithBench. У SANE корреляция Спирмена получилась 0,852, у JRH — 0,100. Практический вывод: тесты, написанные под критерий судьи, дают сигнал, а универсальные тесты почти нет.
Адаптации и экстраполяции
🔧 Техника: добавить свои «слабые места» в список умений → острее тесты под вашу боль
В Step 1 допишите конкретику:
Step 1. Определи 5 умений судьи. Обязательно включи:
- распознавание неявной снисходительности без мата
- реакцию на сарказм
- реакцию на формальный канцелярит вместо помощи
Модель не будет «забывать» нишевые риски вашего бизнеса. Это ускоряет поиск дефектов там, где вы и так подозреваете проблему.
🔧 Техника: оракул по принципу «три независимых вызова» → дешёвая проверка любых сгенерированных LLM данных
Принцип из статьи: проверку делает отдельный вызов, а не тот же, что генерировал. Три независимых прогона, решает большинство. Можно брать любую сгенерированную LLM-партию (тестовые диалоги, синтетические отзывы, примеры для базы знаний) и пропускать каждый элемент через промпт «правильно ли выполнено задание: да/нет + причина». Брак отсеивается до того, как вы начали на нём что-то строить.
Ресурсы
- Работа: SANE: Automated Scorer-Specific Metamorphic Testing for LLM Judges
- Авторы: Ethan Ludwick (Cisco Systems), Yu-Chung Hsiao (Anduril Industries). Короткая версия принята на воркшоп NeurIPS 2026 TAE (Trust-AI-Eval)
- Сравнение: Judge Reliability Harness (JRH, Dev et al., 2026)
- Данные: LLM-AggreFact (AggreFact-CNN, AggreFact-XSum, TofuEval-MediaS, TofuEval-MeetB), FaithBench
- Основа: CheckList (Ribeiro et al., 2020), метаморфическое тестирование (Chen et al., 1998)