TL;DR
Когда ты просишь модель перечислить всё — все синонимы слова, все правильные варианты ответа, весь чек-лист критериев — она тихо теряет значительную часть верных вариантов. Но если дать ей один конкретный вариант и спросить "это подходит?" — она отвечает почти безошибочно. Причина в том, что перечисление списка и проверка одного элемента — это разные задачи для модели, даже если знание внутри одно и то же: составляя список, модель пишет элементы один за другим и сама решает, когда остановиться, не видя вариантов, которые ещё не "придумала".
Главная боль в том, что модель ошибается пропуском, а не добавлением лишнего. Лишний неверный пункт в списке — это то, что видно и можно вычеркнуть при проверке. Пропущенный верный пункт — это дырка, которую не видно, если не знать заранее весь список. В исследовании модели обнаруживают "подложенные" лишние пункты в 6-7 раз чаще, чем пропуски. На задаче с кодом это доходит до абсурда: модель, которая правильно оценивает готовое решение с точностью 74-90%, при этом сама создаёт тест-кейсы, которые отбраковывают 58-81% реально верных решений — потому что придумывает требования, которых в задаче не было.
Решение простое: не проси модель перечислить всё, а проси её сформулировать правило, по которому можно проверить любой конкретный кандидат. Когда модель формулирует правило вместо списка, точность подскакивает почти до идеальной (в исследовании — с ~0.48 до ~0.99). Плюс — перед тем как доверять готовому чек-листу или рубрике, прогони через неё один заведомо правильный пример: если она его отбраковывает, правило сломано и нужно переписать.
Схема метода
ШАГ 1: Попросить модель сформулировать ПРАВИЛО (критерий), а не список → текстовое описание правила
ШАГ 2: Проверить правило на заведомо верном примере ("пройдёт ли он?") → да/нет, если нет — переписать правило
ШАГ 3: Применять правило к каждому кандидату ПО ОДНОМУ, а не одним махом → вердикт "подходит/не подходит" на каждый
Все три шага можно делать в одном диалоге — как отдельные сообщения подряд.
Пример применения
Задача: Онлайн-школа (например, формат Skillbox или Stepik) хочет автоматически проверять открытые ответы студентов на тест: "Назовите способ снижения оттока клиентов". Нужен чек-лист "приемлемых ответов" для авто-проверки.
Промпт:
Я делаю авто-проверку открытых ответов студентов на вопрос:
«Назовите способ снижения оттока клиентов».
Шаг 1. Не пытайся перечислить все возможные правильные ответы.
Сформулируй ОБЩЕЕ ПРАВИЛО: по каким признакам понять, что ответ студента
засчитывается как верный, а по каким — нет.
Шаг 2. Проверь своё правило на этом заведомо правильном ответе:
«Внедрить программу лояльности с персональными скидками для постоянных клиентов».
Проходит ли он по правилу? Если нет — перепиши правило так, чтобы он проходил.
Шаг 3. Теперь по очереди прогони через готовое правило каждый из этих ответов
и дай вердикт «засчитано / не засчитано» с коротким объяснением:
1. «Улучшить качество поддержки клиентов»
2. «Снизить цены на 50%»
3. «Ввести систему бонусов за долгосрочное использование сервиса»
4. «Провести опрос удовлетворённости»
Результат: Модель сначала выдаст словесное правило-критерий (например: "ответ засчитывается, если предлагает конкретный механизм удержания клиента, а не общую декларацию"). Затем проверит его на контрольном примере и, если нужно, скорректирует формулировку. В финале — по каждому из 4 ответов отдельный вердикт с объяснением, а не один общий список "правильных ответов", составленный сразу.
Почему это работает
Модель плохо справляется с задачей "составь список всех вариантов", потому что список она пишет по одному элементу, не видя остальные, и сама решает, когда остановиться — это похоже на то, как если бы тебя попросили назвать все слова на "К", не дав словаря. Ты остановишься гораздо раньше, чем закончится реальный список, просто потому что перестанешь вспоминать новые варианты.
Зато модель отлично умеет оценивать один конкретный вариант — здесь ей не нужно "вспоминать всё", достаточно сравнить один пример с критерием. Это её сильная сторона, и метод её использует: вместо того чтобы заставлять модель придумывать весь список сразу, мы разбиваем задачу на "сформулируй критерий" (с этим модель справляется почти идеально) и "проверь один кандидат по критерию" (с этим — тоже отлично).
Рычаги, которые можно крутить: - Добавь шаг с рассуждением ("подумай пошагово, какие есть варианты, до того как формулировать правило") — исследование показывает, что это заметно закрывает разрыв, если у задачи есть чёткое правило-критерий. - Проверяй правило не на одном контрольном примере, а на 2-3 — чем больше "заведомо верных" тест-кейсов, тем надёжнее фильтр. - Если задача принципиально "размытая" (нет чёткого правила, только текстовое описание, как в оценке кода по докстрингу) — метод помогает частично, но не решает проблему полностью. В таких случаях особенно важен шаг 2 (проверка на известном примере).
Шаблон промпта
Мне нужен {чек-лист / рубрика / список критериев / ответ-ключ} для проверки {задача}.
Шаг 1. Не перечисляй сразу все возможные варианты. Сформулируй ОБЩЕЕ ПРАВИЛО —
по каким признакам можно понять, подходит кандидат или нет.
Шаг 2. Проверь это правило на заведомо верном примере: {известный_правильный_пример}.
Проходит ли он? Если нет — перепиши правило.
Шаг 3. Теперь примени это правило к каждому кандидату по одному и дай вердикт
"подходит/не подходит" с объяснением:
{кандидат_1}
{кандидат_2}
{кандидат_3}
Подставляй в {задача} — что именно проверяешь (эссе, резюме, код, ответы теста), в {известный_правильный_пример} — заведомо верный вариант, который правило обязательно должно принять, в {кандидат_N} — конкретные варианты для проверки.
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода "правило вместо списка" для проверки чек-листов и критериев.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой у тебя контрольный пример и какие конкретно кандидаты нужно проверить — потому что без этого шаг 2 (проверка правила) и шаг 3 (применение правила) не сработают.
Ограничения
⚠️ Не универсальное лекарство: если правильный ответ нельзя описать чётким критерием (например, оценка "качества кода" по общему текстовому описанию задачи, а не по формальным правилам), метод снижает количество ошибок, но не убирает разрыв полностью — модель всё равно может придумывать лишние требования.
⚠️ Пошаговая проверка кандидатов работает медленнее одного запроса: если у тебя сотни кандидатов, проверка "по одному" займёт много сообщений или один длинный промпт со списком — это плата за точность.
⚠️ Контрольный пример должен быть по-настоящему репрезентативным: если твой "заведомо верный" пример нетипичный, правило может пройти проверку, но остаться дырявым на реальных кандидатах.
Как исследовали
Команда специально построила задачи, где правильный ответ можно проверить механически, без участия другой модели — иначе получилось бы, что судью проверяет такой же ненадёжный судья. Например: дали модели список из 15 слов и правило "выбери слова с двойной буквой" — здесь ответ полностью вычисляем, никакой неопределённости.
Проверили шесть семейств моделей (Qwen2.5 от 3B до 72B, Qwen3, Llama, Mistral, gemma, Phi-4) на четырёх типах задач: списки слов с чётким правилом, программный код с эталонными тестами, и словарные синонимы. Во всех случаях модель проверяет отдельный кандидат гораздо точнее, чем составляет весь список сама — и разрыв не закрывается даже у самых крупных моделей.
Самое неожиданное: когда исследователи попросили модель не составлять список, а просто сформулировать правило, точность подскочила почти до идеала — то есть модель прекрасно знает критерий, просто плохо справляется с его "материализацией" в полный список. Это и есть ключевой инсайт для практики: не заставляй модель угадывать весь список сразу — пусть сначала назовёт правило.
Ресурсы
Judging Is Not Enumerating: Silent Omissions in LLM-Authored Acceptable Sets — Wenhui Chen, Jianlin Chen, Ziyao Lin, Peiji Long, Chi Man Vong (University of Macau, South China University of Technology). Построено на четырёх контролируемых конструкциях истинности (алгоритмическая, исполняемый код через HumanEval+/MBPP+, лексическая через WordNet).