TL;DR
Молчаливые ошибки — главная проблема, когда LLM решает многошаговые задачи. Модель проходит все шаги, выдаёт красивый результат — но нарушает одно из ключевых требований задачи так, что это не видно снаружи. Нет ошибки, нет предупреждения. Просто неправильный результат.
Традиционный способ лечить это — попросить модель покритиковать себя свободным текстом. Не работает. Неструктурированная критика ненадёжна: модель не знает, что именно проверять, и делает вид, что всё хорошо. Даже реальный запуск кода и наблюдение за результатом помогает слабо — потому что ошибка проходит молча, без исключений, и обратная связь не указывает на причину.
RubricRefine решает это иначе: перед тем как что-то сделать, модель генерирует специфичный для задачи список критериев-контрактов (рубрику), оценивает черновик против каждого пункта в формате PASS/FAIL, исправляет провалы — и повторяет, пока не пройдёт всё или не кончится бюджет итераций. Никакого запуска, никакого угадывания — только структурированная проверка ДО.
Схема метода
ВХОД: Задача + список инструментов/требований
ШАГ 1: Рубрика (1 запрос)
Задача + требования → список конкретных проверяемых критериев
ШАГ 2: Черновик (1 запрос)
Задача + рубрика → первый вариант
ШАГ 3: Оценка (1 запрос)
Черновик + рубрика → PASS/FAIL по каждому пункту + причина + директива
ШАГ 4: Ремонт (1 запрос, если есть FAIL)
Черновик + FAIL-фидбэк → исправленный вариант
ШАГ 5: Стоп или петля
Все PASS или балл 10/10 → выводим лучший вариант
Иначе → возврат к ШАГ 3 (максимум 5 раундов)
Все шаги — отдельные запросы в чате, в одной сессии.
Пример применения
Задача: Написать коммерческое предложение для B2B SaaS-сервиса автоматизации документооборота. Клиент — HR-директор в торговой компании на 500 человек. Главные боли: много бумаги, долгое согласование, ошибки при ручном вводе. Бюджет на автоматизацию — до 300 тысяч рублей в год.
Промпт:
<Задача>
Написать коммерческое предложение: B2B SaaS для автоматизации документооборота.
Клиент: HR-директор, торговая компания, 500 человек.
Боли: много бумаги, долгое согласование, ошибки ручного ввода.
Бюджет: до 300 000 руб./год.
ШАГ 1 — СОЗДАЙ РУБРИКУ
Сгенерируй рубрику проверки из 6–8 пунктов, специфичных именно для этого КП.
Каждый пункт — конкретно проверяем (можно сказать PASS или FAIL).
Охвати четыре категории:
- Полнота охвата: все ли ключевые боли клиента адресованы?
- Внутренняя согласованность: нет ли противоречий между частями?
- Цепочка данных: все ли цифры и утверждения подкреплены контекстом задачи (не выдуманы)?
- Формат и структура: соответствует ли КП формату, подходящему для HR-директора?
Выведи рубрику:
R1: [Пункт]
R2: [Пункт]
...
---
ШАГ 2 — НАПИШИ ЧЕРНОВИК КП
---
ШАГ 3 — ОЦЕНИ ЧЕРНОВИК
Оцени черновик против каждого пункта рубрики:
[R1]: PASS/FAIL | Причина | Что конкретно исправить
[R2]: PASS/FAIL | Причина | Что конкретно исправить
...
Итоговый балл: X/10
---
ШАГ 4 — ИСПРАВЬ
Если есть FAIL — перепиши КП, устроняя все провалы. Выведи исправленную версию.
---
ШАГ 5 — ПОВТОРИ ОЦЕНКУ
Оцени исправленную версию по той же рубрике.
Если все PASS или балл 9–10 — выведи [ФИНАЛЬНАЯ ВЕРСИЯ].
Если есть FAIL — повтори шаг 4 (максимум 3 итерации).
Результат: Модель покажет рубрику из 6–8 пунктов, заточенных под этого клиента — например: «R4: Бюджет 300 тыс./год упомянут и предложение укладывается в него — PASS/FAIL». Черновик оценится по каждому пункту с конкретной причиной провала и директивой. Затем — исправленная версия и повторная проверка. Финальное КП пройдёт все пункты рубрики или будет лучшим из трёх итераций.
Почему это работает
Слабость LLM — модель не знает, чего не знает. Когда просишь "напиши и проверь сам" без структуры, она следует инерции первого варианта. Свободная критика ("что можно улучшить?") почти всегда косметическая — "добавь примеры", "сделай живее". Реальные пробелы — несоответствие бюджету клиента, пропущенная боль, внутреннее противоречие — остаются.
Сильная сторона LLM — модель хорошо работает против конкретных, проверяемых критериев. Если сказать "проверь, упомянут ли бюджет 300 тысяч — да или нет", точность резко растёт. Структура создаёт фокус.
Как метод использует это: Рубрика генерируется ДО черновика — и не общая, а специфичная для этой задачи. Она превращает размытый вопрос "хорошо ли?" в набор бинарных вопросов "R1: PASS или FAIL?". Модель не угадывает качество, а проверяет соответствие конкретным контрактам. Итеративный ремонт на основе PASS/FAIL — это не "придумай что улучшить", а "устрани конкретный провал R3: неверный тип данных на выходе".
Рычаги управления: - Количество итераций (3–5) → уменьши до 1–2 для простых задач, экономия токенов - Число пунктов рубрики (6–8) → сократи до 4 для быстрой проверки, увеличь до 10 для критичных документов - Категории рубрики → добавляй свои: "Тон: подходит ли для C-уровня?", "Уникальность: нет ли общих фраз без конкретики?" - Условие остановки (9–10/10) → замени на "все R1-R5 в PASS, R6-R8 не критичны" — гибкий выход
Шаблон промпта
<Задача>
{описание задачи}
<Требования>
{ключевые ограничения и условия}
ШАГ 1 — СОЗДАЙ РУБРИКУ
Создай рубрику из {число_пунктов} проверяемых критериев, специфичных для этой задачи.
Каждый критерий — бинарно проверяем: PASS или FAIL.
Охвати категории:
- Полнота: все ключевые требования задачи адресованы?
- Согласованность: нет ли внутренних противоречий?
- Провenance данных: все утверждения идут из контекста задачи (не выдуманы)?
- Формат: соответствует ли ожидаемой структуре вывода?
Формат:
R1: [Критерий]
R2: [Критерий]
...
---
ШАГ 2 — НАПИШИ ЧЕРНОВИК
Создай {тип_результата} на основе задачи и требований.
---
ШАГ 3 — ОЦЕНИ ЧЕРНОВИК
[R1]: PASS/FAIL | Причина | Директива исправления
[R2]: PASS/FAIL | Причина | Директива исправления
...
Балл: X/10
Статус: {ГОТОВО если 9–10 / ТРЕБУЕТ ПРАВКИ если ниже}
---
ШАГ 4 — ИСПРАВЬ (если есть FAIL)
Исправь черновик, устранив все FAIL-пункты. Выведи исправленную версию.
---
ШАГ 5 — ПОВТОРИ ОЦЕНКУ
Оцени исправленную версию по той же рубрике.
Если все PASS или балл 9–10 → [ФИНАЛЬНАЯ ВЕРСИЯ].
Если FAIL → повтори шаг 4 (максимум {число_итераций} раз).
Плейсхолдеры:
- {описание задачи} — что нужно создать и для кого
- {ключевые ограничения и условия} — бюджет, тон, объём, формат, аудитория
- {число_пунктов} — 5–8 для большинства задач
- {тип_результата} — КП, статья, стратегия, email, скрипт
- {число_итераций} — 2–3 для баланса качества и токенов
🚀 Быстрый старт — вставь в чат:
Вот шаблон RubricRefine. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про тип результата, аудиторию, ограничения и ключевые требования — потому что рубрика должна быть специфичной именно для этой задачи, а не общим чеклистом. Она возьмёт паттерн из шаблона и адаптирует все категории под твой контекст.
Почему ЭТО работает (механика)
Когда просишь модель "проверь и улучши" без структуры, она симулирует проверку — генерирует текст, похожий на критику, но не имеющий внешней точки опоры. Это как просить человека найти ошибку в своей же работе без чеклиста — глаз замыливается.
Рубрика создаёт внешнюю точку опоры. Модель проверяет черновик не против своего же текущего состояния, а против набора конкретных вопросов, сформулированных заранее. Это разрыв петли самоподтверждения.
Критически важна специфичность рубрики. Исследование показало: фиксированная (общая) рубрика даёт улучшение, но задача-специфичная рубрика даёт ещё +4–12% сверху — потому что критерии попадают именно в те контракты, которые может нарушить эта конкретная задача. Общий чеклист "проверь логику, стиль, структуру" — слабее, чем "R3: упомянут ли бюджет клиента 300 тыс./год".
PASS/FAIL работает лучше свободной критики. Бинарный ответ даёт точную директиву: что именно сломано и как чинить. Свободный текст "можно улучшить вот это" оставляет модели пространство для косметических правок вместо исправления реальных провалов.
Ограничения
⚠️ Не для простых задач: Если задача — одношаговая (написать короткий email, перефразировать абзац), рубрика не добавляет ценности. Метод раскрывается при наличии нескольких взаимозависимых требований.
⚠️ Риск гиперспецификации: На задачах с единственным вызовом инструмента (или единственным требованием) рубрика может быть слишком детальной и привести к чрезмерным ограничениям. API-Bank в исследовании показал нулевой или отрицательный эффект именно по этой причине.
⚠️ Стоимость токенов: Каждый раунд — несколько дополнительных запросов. Для простых задач дороже, чем полезности принесёт. Ограничивай до 2 итераций для рядовых задач.
⚠️ Меньшие модели — слабый верификатор: Маленькие модели хуже оценивают соответствие рубрике глобально. Но на уровне отдельных PASS/FAIL-пунктов они всё ещё полезны. Для серьёзных задач используй топовую модель.
Как исследовали
Идея была проверить одно конкретное: что важнее для качества ответа в многошаговых задачах — тип цикла улучшения или тип обратной связи внутри него? Исследователи взяли семь разных моделей (от GPT-4.1-mini до Claude Sonnet) и прогнали по двум бенчмаркам: M3ToolEval (сложные многошаговые задачи с API-цепочками) и API-Bank (простые одношаговые вызовы). Базовый сценарий — один проход без улучшений, 0.47–0.74 успеха в зависимости от модели.
Параллельно тестировали три вида цикла-конкурента: Self-Refine (свободная критика без структуры), Self-Debug (запуск кода + наблюдение ошибки), Best-of-N (несколько вариантов, выбрать лучший). Оказалось, что Self-Refine не просто не помогал — он ухудшал результат на пяти моделях из семи. Self-Debug давал +0.10 — но потому что 64% задач решались с первой попытки, а оставшиеся 29% проваливались все пять попыток без конверсии. Молчаливые ошибки прогонялись до конца, давали неправильный результат, и ни одна итерация не могла их поймать.
RubricRefine достиг 0.86 в среднем по всем моделям — против 0.62 у базового подхода. Самый неожиданный результат: метод практически выровнял разброс между слабыми и сильными моделями (0.85–0.88 у всех), хотя базовые показатели расходились от 0.47 до 0.74. Ещё одна находка: при сопоставимой задержке с Self-Refine (около 30 секунд на задачу) точность вдвое выше — 0.85 против 0.60.
Адаптации и экстраполяции
🔧 Адаптация: только рубрика без итерации → быстрая проверка
Если нужно проверить уже написанный текст без итераций, используй только Шаги 1+3. Попроси сгенерировать рубрику и оценить готовый черновик. Получишь структурированный аудит с конкретными провалами — дальше правь руками.
🔧 Адаптация: ролевые критерии → многопозиционная рубрика
Добавь к стандартным категориям пункты от лица разных стейкхолдеров:
R7: С точки зрения финансового директора — ясна ли ROI и срок окупаемости? PASS/FAIL R8: С точки зрения юриста — есть ли обязательства, которые нельзя выполнить? PASS/FAILЭто усиливает "цепочку данных" — каждая роль видит свои молчаливые провалы.
🔧 Экстраполяция: RubricRefine + Chain-of-Thought
Перед генерацией черновика (Шаг 2) добавь "Сначала пошагово набросай структуру, потом пиши". Рубрика проверяет финальный текст, Chain-of-Thought снижает ошибки на уровне черновика. Два уровня защиты: структурная и семантическая.
Ресурсы
RubricRefine: Improving Tool-Use Agent Reliability with Training-Free Pre-Execution Refinement
Will LeVine, Brendan Evers, Sam Saltwick, Abhay Venkatesh
Anduril Industries
wlevine@anduril.com
Связанные работы упомянутые в статье: Self-Refine (Madaan et al., 2023), Self-Debug (Chen et al., 2023), Reflexion (Shinn et al., 2023), LLM-as-a-Judge (Zheng et al., 2023), M3ToolEval (Wang et al., 2024), API-Bank (Li et al., 2023)