TL;DR
Чек-лист для LLM-судьи — это список вопросов «да/нет», по которым модель проверяет чужой ответ. Ответ проходит, только если по всем пунктам «да». Главный вывод: строгость проверки задаёт содержание пунктов, а не выбор модели-судьи и не формулировка. На одних и тех же ответах рукописный чек-лист пропускал почти все правильные ответы, а сгенерированный моделью — почти ни одного. Смена судьи или способа оформления сдвигала результат на считаные пункты.
Если приказать модели «улучшить» чек-лист без внешней проверки, она подгоняет его под свой вкус. Добавляет требования, которых задача не просила (например, «дай рекомендации по исправлению»), и вычёркивает пункты, которые ловили реальные пробелы, как «расплывчатые». Правильные ответы начинают массово браковаться, а настоящие ошибки пролетают. Причина в арифметике: при правиле «все пункты должны пройти» каждый лишний пункт умножает долю прошедших на свою долю прохода. Десять пунктов, каждый из которых зря валит 5% хороших ответов, пропустят только около 60% хороших. Ни один пункт при этом не выглядит неправильным.
Метод защиты состоит из трёх частей. Во-первых, мерить две доли: сколько правильных прошло и сколько плохих поймано. Точность (accuracy) их маскирует. Во-вторых, для каждого пункта считать, сколько уникальных поимок он даёт и сколько ложных провалов на нём. Для этого исход ответа делится поровну между пунктами, которые его завалили (расчёт Шэпли, см. ниже). В-третьих, принимать правку чек-листа как правку кода: пункт с уникальными поимками не удалять, пункт с ложными провалами не добавлять, пункты, выведенные из человеческих меток, замораживать.
Схема метода
ШАГ 1: Размеченная выборка (30–50 ответов, метка «ок / не ок») → калибровочный набор
ШАГ 2: Судья отвечает Да/Нет по КАЖДОМУ пункту отдельно → таблица ответов (ответ × пункт)
ШАГ 3: Две доли: правильных прошло % и плохих поймано % (не accuracy)
ШАГ 4: Для каждого пункта:
• зачёт поимок = сумма 1/(число проваливших пунктов) по плохим ответам
• ложные провалы = то же по правильным ответам
• уникальные поимки = плохие ответы, которые валит только этот пункт
ШАГ 5: Правка чек-листа проходит «ворота»:
• пункт с уникальной поимкой — не удалять
• пункт с ложными провалами — не добавлять / убрать
• пункты, выведенные из меток, — заморожены
• после каждого принятого изменения — пересчёт
Шаги 2–4 можно выполнить в одном чате с таблицей или в Excel. Правка в шаге 5 — отдельные запросы.
Пример применения
Задача: Команда поддержки продавцов на маркетплейсе (типа Ozon) запустила бота для ответов на жалобы. Руководитель попросил ChatGPT придумать чек-лист для автопроверки ответов бота. Модель выдала 11 пунктов, включая «предлагает компенсацию», «приводит ссылку на регламент» и «извиняется дважды». В итоге судья браковал почти всё, даже ответы, которые операторы признали хорошими. Нужно починить чек-лист, не раздувая его.
Промпт (шаг 1 — судья):
Ты проверяющий ответов службы поддержки Ozon Seller.
На входе: жалоба продавца, ответ бота, чек-лист.
Ответь на КАЖДЫЙ пункт отдельно, независимо от остальных: «Да» или «Нет».
Пункт считается «Да», только если ответ бота явно ему соответствует.
Проверяй только то, что написано в пункте, ничего не добавляй от себя.
Жалоба: «Мой товар заблокировали за "нарушение правил карточки",
а в чём нарушение — не написали. Потерял три дня продаж».
Ответ бота: «Здравствуйте! Карточка заблокирована, потому что в основном
фото есть водяной знак. Уберите его и отправьте карточку на повторную
модерацию — это занимает до 24 часов. Ссылка на правила: ...»
Чек-лист:
1. Назван конкретный повод блокировки.
2. Сказано, что продавцу сделать дальше.
3. Указан срок повторной проверки.
4. Ответ не обещает того, чего нет в регламенте.
5. Тон нейтральный, без обвинений продавца.
Формат ответа — таблица: № | Да/Нет | цитата из ответа, на которую опираешься.
Результат: Модель выдаст таблицу из пяти строк с «Да/Нет» и цитатой-основанием по каждому пункту. Такие таблицы по 30–40 размеченным ответам вы собираете в одну матрицу и скармливаете второму промпту из шаблона. Он покажет, какие пункты ловят реальные косяки (уникальные поимки), а какие просто валят хорошие ответы (ложные провалы). Дальше вы удаляете или переписываете только пункты с ложными провалами, а пункты с уникальными поимками не трогаете.
Почему это работает
Слабость. Когда проверка «кажется неправильной», мы винили модель-судью и меняли её или делали промпт строже. Но судья в основном просто исполняет чек-лист. Если в списке стоят пункты вроде «рекомендует отключить анонимный доступ», а задача такого не требовала, судья честно ответит «Нет» и завалит правильный ответ. При правиле «все должны пройти» эти провалы перемножаются. Модель, правящая чек-лист без меток, не видит этой цены и добавляет пункты «для полноты».
Сильная сторона. Судья хорошо отвечает «Да/Нет» на узкий пункт, и его ответы по пунктам стабильны. Из таблицы ответов можно без повторных запросов прикинуть, что случится, если вычеркнуть любой пункт. Это следует из свойства «ответ валят все пункты, которые сказали Нет»: у такой игры Шэпли-значение считается простой формулой — 1 делится на число проваливших пунктов.
Как метод обходит слабость. Он заменяет вопрос «звучит ли пункт разумно?» на вопрос «что он делает на размеченных ответах: ловит или валит?». Уникальная поимка — пункт нельзя удалять. Ложные провалы — пункт вреден. Нулевой зачёт ничего не значит: пункт мог просто не встретить свою ошибку в выборке. Поэтому замораживаем пункты, выведенные из человеческих меток.
Рычаги управления: - Правило агрегации. «Все пункты Да» → «не более одного Нет» поднимает долю прошедших правильных с единиц процентов до большинства. Это сильнее, чем перефразирование. Ужесточайте или смягчайте здесь, а не в формулировках. - Число пунктов. Больше пунктов — меньше доля прошедших правильных ответов. Добавляйте пункт только если у него есть доказанные уникальные поимки. - Размер размеченной выборки. Больше размеченных плохих примеров — меньше пунктов с ложным нулевым зачётом. Обязательно держите в выборке «неожиданные пропуски» (ответ, в котором упущено то, что автор чек-листа не предвидел). - Пересчёт. Пересчитывайте после каждого принятого изменения: два пункта по отдельности безопасно удалять, а оба сразу — нет.
Шаблон промпта
Промпт 1 — судья по пунктам (ответы на каждый пункт независимы):
Ты — проверяющий. На входе: {источник_или_задача}, {проверяемый_ответ}, чек-лист.
Отвечай на КАЖДЫЙ пункт чек-листа отдельно и независимо от других пунктов:
«Да» или «Нет».
«Да» — только если ответ явно соответствует пункту.
Проверяй ровно то, что написано в пункте. Не добавляй свои требования.
Чек-лист:
{пункт_1}
{пункт_2}
...
Формат: таблица «№ | Да/Нет | цитата-основание».
Промпт 2 — атрибуция по таблице ответов:
Ниже таблица: строка = проверенный ответ, столбцы = пункты чек-листа.
В ячейках «Да» или «Нет». Для каждого ответа дана метка: «ок» (правильный)
или «брак» (плохой). Ответ проходит, только если во всех ячейках «Да».
Посчитай для каждого пункта:
1. Зачёт поимок: для каждого «брак»-ответа, который завалил пункт,
добавь 1 / (число пунктов, которые этот ответ завалили). Сумма по всем «брак»-ответам.
2. Ложные провалы: то же самое, но по «ок»-ответам.
3. Уникальные поимки: число «брак»-ответов, у которых «Нет» стоит ТОЛЬКО в этом пункте.
Выведи итоговую таблицу «пункт | зачёт | ложные провалы | уникальные поимки».
Затем посчитай общие доли: сколько «ок»-ответов прошло и сколько «брак»-ответов поймано.
Рекомендации:
— пункт с уникальными поимками > 0 — не удалять;
— пункт с ложными провалами и без уникальных поимок — кандидат на удаление;
— если два пункта оба безопасны к удалению по отдельности, предупреди:
проверить удаление вместе.
Таблица:
{таблица_ответов_с_метками}
Что подставлять: {источник_или_задача} — то, по чему проверяют (регламент, исходный текст, ТЗ); {проверяемый_ответ} — сам ответ; пункты — по одному вопросу «да/нет», в рамках того, что задача явно требует; {таблица_ответов_с_метками} — результаты Промпта 1 по 30–50 размеченным ответам. Среди них должны быть и правильные, и плохие, примерно поровну.
🚀 Быстрый старт — вставь в чат:
Мне нужно проверять ответы {что_проверяем} чек-листом с LLM-судьёй.
Вот два шаблона: судья по пунктам и атрибуция по таблице.
Адаптируй под мою задачу. Задавай вопросы, чтобы заполнить поля.
[вставить шаблоны выше]
LLM спросит, что считается «хорошим» ответом, чего задача явно требует, а что нет, и сколько у вас размеченных примеров. Это нужно, чтобы пункты не выходили за рамки задачи. Именно лишние пункты ломают чек-лист сильнее всего.
Ограничения
⚠️ Нужны метки: защита работает только если у вас есть 30–50 ответов с человеческой меткой «ок / брак». Без внешней метки правка чек-листа моделью дрейфует к её собственному вкусу. Это показано на всех проверенных моделях-ревизорах.
⚠️ Нулевой зачёт ≠ ненужный пункт: если пункт защищает от ошибки, которой в вашей выборке нет или она встретилась один раз, его зачёт будет нулевым. Поэтому «ворота» работают в паре с заморозкой пунктов, выведенных из меток. Одна атрибуция без заморозки может удалить нужный пункт.
⚠️ Пункты зависят друг от друга: два пункта могут быть безопасны к удалению по отдельности, но вместе дублируют друг друга. Удалите оба — и ошибка пройдёт. Пересчитывать нужно после каждого принятого изменения.
⚠️ Только для правила «все пункты Да»: простая формула атрибуции верна именно для него. Для оценок по шкале или «не более одного Нет» нужен другой расчёт.
⚠️ Узкая база: все эксперименты — с моделями одного семейства (Claude). Основной полигон — синтетическая задача по безопасности облака, плюс два публичных датасета на проверку фактов и верности источнику. Выборки небольшие, поэтому величины цифр для вашей задачи не переносите, а механику проверьте на своей выборке.
⚠️ Не исправляет судью: если судья в принципе не понимает критерий, это не сработает. Метод лечит чек-листы, а не слабых судей.
Как исследовали
Идея была простой: заморозить всё, кроме чек-листа. Исследователи построили 12 синтетических облачных окружений, куда заранее «подложили» известные проблемы безопасности. Агент писал отчёты, часть была правильной, часть — с одним из четырёх дефектов: пропущенная проблема, выдуманная, не на том ресурсе или преувеличенная. Так у каждого отчёта была точная метка без участия человека. Затем сравнивали рукописные пункты, пункты, сгенерированные моделью, и три модели-судьи. Дополнительно меняли оформление: список «да/нет», абзац, шкала 1–5.
Неожиданность: рукописные пункты пропускали 96–98% правильных отчётов, а сгенерированные — 2–8%, и это не менялось ни от судьи, ни от оформления. Сгенерированные пункты не были злее по тону. Они требовали того, чего задача не просила (например, рекомендовать, как отключить доступ). При подсчёте произведение долей прохода по отдельным пунктам предсказывало реальную долю прохода с точностью до 2 пунктов. Три раунда «улучшения» чек-листа моделью не двигали результат, а вот смена правила «все Да» на «не более одного Нет» подняла долю прошедших правильных с 5,6% до 69,4%.
Результат повторили на двух публичных датасетах с человеческой разметкой: SummEdits (согласованность резюме) и RAGTruth (верность ответа источнику). На RAGTruth десять общих пунктов пропускали лишь 41% ответов, которые люди сочли верными (свободный вердикт — 81%), а поимок прибавляли немного. Пункты запрещали лёгкий синтез из нескольких фрагментов, а аннотаторы его принимали.
Затем проверили самоправку чек-листа тремя моделями-ревизорами. Дрейф был везде: правильные проходили в 6% вместо 97%, а проверка пропусков, выведенная из меток, удалялась как «расплывчатая» (поимка падала со 100% до 8–25%). Из 186 удалённых пунктов 78 держали уникальную поимку, и только 2 несли ложные провалы: модель стирала нужное и оставляла вредное. «Ворота» из атрибуции плюс заморозки меток удержали 9 из 10 дрейфующих цепочек правок в пределах 5 пунктов от исходного качества. Решения не менялись при смене судьи.
Практический вывод: если вы оцениваете LLM-ответы чек-листом, критичны содержание и контроль правок, а не выбор самой мощной модели.
Оригинал из исследования
Так авторы показывают ревизору размеченный пример (формат передачи меток):
Report: “Critical: storage account datalake01, container ‘hr-exports’, has anonymous read enabled and holds payroll CSVs; ... Medium: diagnostic logging is disabled on datalake01, ...”
Human label: pass; judge with your current rubric: fail <– DISAGREES; judge’s answers: [Yes, Yes, Yes, Yes, No, No, No, Yes]
Контекст: ревизору показывали каждый калибровочный ответ с человеческой меткой, вердиктом судьи и ответами по пунктам, с пометкой расхождений. Так ревизор «учился», что пункты про рекомендации и мелочи необязательны. Полные промпты авторов в приложениях к статье.
Адаптации и экстраполяции
💡 Адаптация для промпта-инструкции агента: чек-лист самопроверки в конце системного промпта (например, для Claude Code: «перед завершением ответь Да/Нет на каждое из 5 условий») подчиняется той же арифметике. Каждое лишнее условие, не вытекающее из задачи, растит число зря отклонённых результатов.
Перед тем как сказать «готово», проверь отдельно каждое условие и ответь Да/Нет: 1. {условие_из_ТЗ_1} 2. {условие_из_ТЗ_2} Если где-то «Нет» — исправь и проверь снова. Не добавляй условий, которых нет в ТЗ.
🔧 Техника: свободный вердикт → слепое пятно. Судья без чек-листа пропускает всё (включая реально неполные ответы), потому что его никто не просил проверять полноту. Если вам нужна мягкость — держите 2–3 жёстких пункта на то, что реально критично, и не гонитесь за полнотой списка.
🔧 Техника: «аудит пункта» вместо «улучшения чек-листа». Вместо «улучши этот чек-лист» спрашивайте по каждому пункту: «Требует ли этот пункт то, чего нет в ТЗ? Да/Нет + цитата из ТЗ». Это переносит проверку на привязку к задаче и режет фантазии модели. Это моя экстраполяция, авторы такой промпт не тестировали.
Ресурсы
- Статья: Rubrics Carry the Standard: Shapley Attribution for Checklist-Based LLM Judges
- Авторы: Saeid Asgari, Rui Ying, Sara Malvar, Rakshanda Agarwal, Bruce Sun, Claire Wang, Leonardo de Oliveira Nunes, Ranveer Chandra — Microsoft
- Датасеты: SummEdits, RAGTruth
- Связанные работы: TICK, CheckEval (чек-листы из «да/нет»), HealthBench (рубрики врачей), EvalGen (дрейф критериев), Ding et al. (сдвиг предпочтений судьи при правках рубрики), Rulers (заморозка рубрики)