TL;DR
Semi-formal Reasoning — это техника, которая меняет не вопрос к модели, а то, как модель должна на него отвечать. Вместо свободного рассуждения ("думай и отвечай") модель получает структурированный шаблон-сертификат с обязательными полями: предпосылки → трассировка по каждому пункту → альтернативные гипотезы → вывод. Заполнить все поля, не собрав доказательства, невозможно — структура заставляет двигаться по шагам.
Главная боль: Попроси LLM "проанализируй это и скажи, всё ли ок" — и она даст уверенный ответ, не проверив допущения. Не потому что ленится. Потому что генерирует текст в порядке вероятности: начала с вывода — значит продолжит его подтверждать. Это как написать заключение аудита до просмотра документов. Модель в таком режиме регулярно упускает скрытые зависимости — те, что не лежат на поверхности, а требуют проследить цепочку.
Шаблон-сертификат обходит это через структуру. Пока не заполнены поля с доказательствами — до вывода просто не добраться. Модель вынуждена сначала перечислить, что именно она проверила, откуда взяла данные, какая альтернативная гипотеза существует и почему она неверна. Только после этого — итоговое суждение.
Схема метода
Всё выполняется в одном промпте:
ВХОД: задача + шаблон-сертификат с обязательными полями
ШАГ 1: Предпосылки → что модель проверила явно, что приняла без проверки
ШАГ 2: Трассировка по критериям → для каждого пункта: источник + факт + риск
ШАГ 3: Альтернативная гипотеза → формулировка + проверка "а что если я ошибаюсь?"
ШАГ 4: Вывод → только после заполнения всех полей выше
ВЫХОД: вывод с явными ссылками на собранные доказательства
Пример применения
Задача: Ты наконец-то нашёл двух подрядчиков на редизайн сайта для своего интернет-магазина. Оба прислали КП. Цены похожие, оба обещают "современный дизайн и быстрый результат". Нужно выбрать одного — и не пожалеть. Просишь Claude разобрать.
Промпт:
Проанализируй два коммерческих предложения от подрядчиков на редизайн сайта.
Перед выводом заполни сертификат анализа — все поля обязательны.
[КП Подрядчик 1]:
{текст КП первого}
[КП Подрядчик 2]:
{текст КП второго}
<Сертификат-анализа>
<Предпосылки>
Явно проверено: [перечисли конкретные факты из текста КП]
Принято без проверки: [что пришлось допустить и почему]
<Трассировка-по-критериям>
Для каждого из критериев — сроки, стоимость, состав работ, гарантии, риски:
- Критерий: [название]
- Что заявлено в КП 1: [цитата или факт]
- Что заявлено в КП 2: [цитата или факт]
- Расхождение или скрытый риск: [что не совпадает или чего нет]
<Альтернативная-гипотеза>
Гипотеза, противоречащая моему выводу ниже: [сформулируй]
Проверка: [почему она верна или неверна по данным из КП]
<Вывод>
Рекомендация: [Подрядчик 1 / Подрядчик 2 / нужно уточнить]
Уверенность: [высокая / средняя / низкая]
Что не смог проверить: [чего не хватает для полного вывода]
Результат: Модель не напишет просто "Подрядчик 2 лучше, потому что опытнее". Она сначала заполнит поля трассировки — и в процессе может обнаружить, что в КП 1 не указан состав работ по мобильной версии, а в КП 2 нет ни слова про правки после сдачи. Альтернативная гипотеза заставит явно проверить "а что если я предвзят в пользу более дешёвого варианта?". В поле "что не смог проверить" появится конкретный список вопросов для уточнения — вместо ощущения "ну вроде всё норм".
Почему это работает
LLM генерирует текст слева направо, предсказывая следующий токен по уже написанному. Если в начале ответа появился уверенный вывод — всё что дальше будет его подтверждать, а не проверять. Это не ошибка, это архитектура.
У модели есть настоящая сильная сторона: она отлично заполняет структуры. Словарный и логический аппарат огромный — если дать чёткий шаблон с полями, она их заполнит тщательно. Проблема не в способности анализировать, а в порядке: без шаблона она начинает с конца.
Сертификат переворачивает порядок принудительно. Поле "вывод" стоит последним — дойти до него без заполнения предыдущих невозможно структурно. Модель вынуждена сначала произвести доказательства, а потом заключение — не наоборот. Блок "Альтернативная гипотеза" добавляет проверку от противного: модель не просто защищает позицию, но и явно пытается её опровергнуть.
Рычаги управления: - Количество критериев в трассировке → больше критериев = глубже анализ, но длиннее ответ. Для быстрых задач — оставь 2-3 ключевых - Поле "принято без проверки" → самый ценный блок для сложных задач. Хочешь видеть скрытые допущения — оставь. Хочешь короче — убери - Уровень уверенности в выводе → добавь вариант "недостаточно данных" — и модель чаще будет честно говорить "не знаю" вместо додумывания - Именованные роли вместо безликих → если задача требует нескольких углов зрения, замени "альтернативная гипотеза" на "взгляд скептика [имя]" — острее и конкретнее
Шаблон промпта
Проанализируй {задача}.
Перед выводом заполни сертификат — все поля обязательны.
<Сертификат-анализа>
<Предпосылки>
Явно проверено: [конкретные факты из предоставленных данных]
Принято без проверки: [допущения и почему они приемлемы]
<Трассировка-по-критериям>
Для каждого из критериев — {критерии}:
- Критерий: [название]
- Источник: [откуда данные]
- Что проверено: [конкретный факт]
- Скрытый риск: [что может быть не так]
<Альтернативная-гипотеза>
Гипотеза, противоречащая моему выводу: [сформулируй]
Проверка: [почему верна или неверна по данным]
<Вывод>
Ответ: [чёткий вывод]
Уверенность: [высокая / средняя / низкая]
Что не смог проверить: [список пробелов]
Плейсхолдеры:
- {задача} — что анализируем: "два КП", "три кандидата", "бизнес-идею", "условия договора"
- {критерии} — по каким осям сравниваем: "цена, сроки, риски" / "опыт, мотивация, культурный fit"
🚀 Быстрый старт — вставь в чат:
Вот шаблон Semi-formal Reasoning. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит что именно анализируем и по каким критериям — потому что без этого нельзя заполнить поля трассировки. Она возьмёт XML-структуру из шаблона и подставит твои данные.
Ограничения
⚠️ Задачи без поддающихся проверке данных: Если исходных материалов недостаточно — модель заполнит поля допущениями, не фактами. Сертификат создаёт иллюзию строгости, но не заменяет реальные данные.
⚠️ Простые задачи: На коротких вопросах ("какой из двух заголовков лучше?") сертификат — лишний шум. Метод окупается только на задачах со скрытыми зависимостями и неочевидными рисками.
⚠️ Цена — больше токенов в ~2-3 раза: Структура вынуждает модель писать подробнее. Для больших задач это норма, для быстрых итераций — замедление.
⚠️ Сильные модели выигрывают больше: На более слабых моделях прирост скромнее или не проявляется совсем — они хуже следуют сложным шаблонам.
⚠️ Уверенный, но неполный анализ: Если модель систематически не замечает цепочку зависимостей (например, что функция вызывает другую функцию с другой логикой), структура не помогает — она трассирует только те пути, которые "видит".
Как исследовали
Идея простая: взяли две версии анализа кода — свободное рассуждение и структурированный шаблон — и проверили на трёх разных задачах. Для первой задачи (сравнение двух патчей кода) собрали 170 намеренно сложных примеров: выбирали пары, где код похож на вид, но ведёт себя по-разному. Почему намеренно сложных? Потому что на лёгких любой метод даёт 95%+ — разницы не увидишь. На этой выборке стандартное рассуждение дало 78%, полуформальное — 89%. Почти вдвое меньше ошибок.
Но самый интересный эксперимент — 200 реальных патчей от живого агента (Gemini-3-Pro), решавшего задачи из SWE-bench. Здесь сравнивали не только два стиля рассуждения, но и простой текстовый алгоритм (difflib), один вызов LLM без изучения кода, и полноценного агента с изучением репозитория. Difflib дал 73%, один вызов LLM — 86%, агент со стандартным рассуждением — 87%, агент с сертификатом — 93%. Три процентных пункта сверху дала именно структура, не более умная модель.
Дополнительно проверили на поиске багов (Defects4J, 100 реальных Java-проектов) и ответах на вопросы по коду (RubberDuckBench). Везде прирост от сертификата составил 5-11 процентных пунктов. Особенно любопытно, что для более сильной модели (Opus) структура дала +8.7 пп, а для более слабой (Sonnet) — почти ноль. Как будто сертификат не добавляет знания, а разблокирует то, что у сильной модели уже есть, но без структуры не проявляется.
Адаптации и экстраполяции
1. Прозрачность допущений как отдельный инструмент
🔧 Поле "принято без проверки" → список скрытых допущений
Если тебе не нужен полный сертификат, но ты хочешь знать, на чём держится вывод модели:
Ответь на {вопрос}.
Перед ответом выпиши:
- Что ты проверил явно (есть в тексте/данных)
- Что ты допускаешь без проверки (и почему это допущение приемлемо)
Потом — ответ.
Одно поле вместо полного сертификата. Часто достаточно, чтобы увидеть где модель "гадает".
2. Сертификат для сравнения вариантов (матрица решений)
🔧 Трассировка по критериям → N вариантов × M критериев
Когда сравниваешь больше двух вариантов (три оффера, пять идей для контент-плана):
Сравни {варианты} по критериям {критерии}.
<Матрица-решений>
Для каждой пары [вариант × критерий]:
- Факт из источника: [цитата или данные]
- Оценка: [сильно / нейтрально / слабо]
- Неочевидный риск: [что может быть не так]
<Альтернативная-гипотеза>
[почему лидер может оказаться не лучшим выбором]
<Рекомендация>
Лучший вариант: [с обоснованием через ячейки матрицы выше]
Ресурсы
Название работы: AgenticCode Reasoning (рабочее название, точное название не указано в тексте)
Бенчмарки упомянутые в статье: - SWE-bench-Verified: swebench.com - Defects4J: база реальных Java-багов - RubberDuckBench: 15 вопросов на понимание кода (Python, Java, C++)
Смежные работы: - SWE-agent, Yang et al. (2024) - CodeJudge, Tong and Zhang (2024) - Agentic Rubrics, Raghavendra et al. (2026)