TL;DR
REA — способ посмотреть на путь ответа модели в три остановки: что модель решила → дошло ли решение до программы в нужном виде → какое действие программа выполнила. Автоматизация почти всегда читает ответ модели кодом или фильтром: ищет метку, поле, последнюю строку. Если ответ выглядит не так, как ждёт этот разборщик, верное решение теряется. Точность модели при этом остаётся высокой.
Главная находка: модель часто отвечает правильно, но не в той форме. Ждёшь одно слово «Опасно», а приходит «Этот запрос является опасным, потому что…». Фильтр «ответ равен "Опасно"» не срабатывает, и в дело вступает запасной вариант: «при сбое пропускать» или «при сбое блокировать». В одном тесте из-за такого несовпадения почти все правильно найденные опасные запросы были пропущены. Модель всё поняла верно, программа просто не смогла это прочитать. Причина простая: модель генерирует текст по привычному шаблону, а привычка — отвечать предложением. Строгий формат появляется, только если его явно потребовать.
Что делать: явно прописать форму ответа в промпте, дать модели достаточно места на рассуждение, читать ответ гибким разборщиком (приводить регистр, пробелы, ловить метку в заданном блоке) и заранее решить, что происходит, когда разбор всё же не удался. Мерить стоит не только «насколько модель права», но и «какая доля правильных ответов дошла до действия».
Схема метода
ШАГ 1 (Resolve): что модель на самом деле решила? → читаем ответ глазами, игнорируя формат
ШАГ 2 (Express): дошло ли решение до разборщика в нужной форме? → доля доставленных среди верных
ШАГ 3 (Act): что сделала система, когда разбор не удался? → «пропустить» или «заблокировать» / на ручную проверку
Две цифры:
A = доля верных решений
κ = доля верных решений, которые дошли до программы (доставка)
A × κ = доля ответов, которые верны И сработали
Это порядок проверки, а не один промпт. Делается вручную на 20–50 ответах.
Пример применения
Задача: Вы ведёте магазин на Wildberries и Ozon. Автоматизация в n8n читает входящие сообщения покупателей из Telegram и раскладывает по веткам: «жалоба», «вопрос», «спам». Ветка «жалоба» сразу уведомляет менеджера. Модель определяет тип сообщения. По факту половина жалоб не доходит до менеджера: узел сравнения ждёт ровно слово «жалоба», а модель пишет «Это сообщение является жалобой, так как…».
Промпт:
Ты сортируешь сообщения покупателей интернет-магазина.
Допустимые метки (ровно одна из): жалоба | вопрос | спам
Сообщение покупателя:
«Заказ 3 недели назад, курьер не приехал, деньги не вернули. Верните деньги или напишу в Роспотребнадзор.»
Формат ответа:
1. Сначала напиши одно-два предложения рассуждения.
2. Последней строкой выведи метку строго в таком виде:
метка
После закрывающего тега не пиши ничего.
Результат: Модель выдаст короткое рассуждение и в конце строку с меткой в теге. В n8n достаточно узла, который вытаскивает текст между , приводит его к нижнему регистру и обрезает пробелы. Такой разбор переживает вариации вроде «Жалоба» или «жалоба ». Если тега нет, сообщение уходит менеджеру на ручную проверку, а не в мусор.
Почему это работает
Слабость модели. Если не сказать, в какой форме отвечать, модель выбирает привычную: полное предложение или объяснение. Смысл верный, форма не та. Инструкция, где потерялась фраза про формат (например, при переписывании промпта), даёт тот же эффект. Ещё хуже со смелым «сократим ответ»: когда лимит токенов обрывает ответ до метки, рассуждение есть, а решения нет.
Сильная сторона модели. Если форма заявлена явно, модель следует ей почти всегда. В тесте с чётким указанием формата нарушений почти не было. Без такого указания нарушали три ответа из четырёх. Рассуждение перед ответом при этом не вредит: точность держится, нужен лишь предсказуемый «якорь» для извлечения.
Как метод это использует. Мы просим решение в узнаваемом месте (последняя строка, тег), даём место на рассуждение и читаем ответ терпимо. Так форма перестаёт быть слабым звеном.
Рычаги управления: - Фраза «ничего после тега» → убери, если после метки нужен комментарий, но тогда разборщик должен искать тег, а не последнюю строку. - Место метки (первая строка или последняя) → для рассуждающих ответов надёжнее конец, для коротких — начало. - Лимит токенов → увеличь, если ответ обрывается. Проверяй, доходит ли модель до метки, а не только правильна ли она. - Запасное действие при сбое разбора → для рискованных решений «заблокировать/на проверку человеку», для безобидных «пропустить». - Строгость разборщика → мягче (приведение регистра, лишние пробелы) вернёт почти все потерянные ответы.
Шаблон промпта
Ты {роль_задачи}.
Допустимые метки (ровно одна из): {метка_1} | {метка_2} | {метка_3}
{входные_данные}
Формат ответа:
1. Сначала напиши {объём_рассуждения}.
2. Последней строкой выведи решение строго в таком виде:
метка
После закрывающего тега не пиши ничего.
Что подставлять: {роль_задачи} — что именно классифицируешь или решаешь; {метки} — закрытый список вариантов; {входные_данные} — сообщение, текст или запрос; {объём_рассуждения} — «одно-два предложения» или «до трёх коротких шагов».
🚀 Быстрый старт — вставь в чат:
Вот шаблон ответа с меткой в теге. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля. Потом предложи, как мне настроить разбор ответа
в моей автоматизации и что делать, если метка не найдена.
[вставить шаблон выше]
LLM спросит, какие метки допустимы, куда пойдёт ответ (n8n, Make, таблица) и что произойдёт при сбое. Эти три вещи определяют, будет ли формат ловиться без потерь.
Ограничения
⚠️ Малая выборка в части тестов: классификацию новостей и тональности проверяли на очень небольшом наборе текстов. Это иллюстрация эффекта, а не точная оценка частоты в вашей задаче.
⚠️ Небольшие специализированные модели: главные цифры про безопасность получены на двух маленьких моделях-охранниках. Для универсальных чатов (ChatGPT, Claude, Gemini) направление вывода, скорее всего, то же, но масштаб эффекта другой.
⚠️ Жёсткая JSON-схема может ухудшить сам ответ: в их тесте при требовании структурированного JSON с рассуждением ответ принимался почти всегда, но точность решений упала сильно. Строгая форма — не бесплатная защита, проверяйте оба показателя.
⚠️ Формат ≠ качество: гибкий разбор доставляет ответ, но не доказывает, что рассуждение хорошее. Метод чинит доставку, не ошибки модели. Часть пропущенных опасных запросов осталась и после починки — это были реальные промахи модели.
⚠️ Гибкий поиск слова опасен: простая проверка «метка где-то есть в тексте» ловила и случайные упоминания в объяснении. Нужен разбор по заданному месту (тег, последняя строка), а не поиск по всему тексту.
⚠️ Неполный текст: часть приложений и один из сравнений (восстановление ответа второй моделью) в доступном материале не видны полностью.
Как исследовали
Идея была простой: взять один и тот же ответ модели и показать его разным «читателям» — строгому и гибкому разборщику. Сначала проверили четыре современные модели (GPT-4.1-mini, GPT-4o-mini, Claude Haiku 4.5, Claude Sonnet 4.5) на простой классификации новостей и тональности. Все 480 ответов были правильными по смыслу, но 93 не соответствовали формату «только метка». Почти все нарушения случились там, где в инструкции не было фразы про форму ответа: нарушили 75,8% против 0,6% с такой фразой. Это самый практичный вывод статьи.
Затем взяли 196 запросов из набора XSTest (безопасные и опасные) и сравнили два фильтра: Llama Guard 3 (отвечает одним словом) и GuardReasoner (сначала рассуждает). Рассуждающий оказался точнее (93,4% против 87,2%), но старый разборщик, ждавший метку в первой строке, отклонил все 588 его ответов. При режиме «пропускать при сбое» пропустились все опасные запросы. При «блокировать при сбое» блокировалось вообще всё, включая безопасное. Подключили разборщик, который читает блок ответа, и почти всё восстановилось. Если дополнительно требовать полную структурированную цепочку рассуждений, доля годных ответов падала (80,1%), а мягкая проверка этого же формата возвращала её (91,8%).
Отдельно проверили лимит длины на 254 новых запросах. Урезание ответа с 700 до 256 токенов уронило точность лишь на 1,2 пункта, зато доставку — на 25 пунктов. При 192 токенах ответы почти все обрывались до метки (доставка 3,1%). Вывод: если смотреть только на точность, потерю на выходе не заметишь.
Адаптации и экстраполяции
💡 Адаптация: проверка своей автоматизации за 15 минут. Возьмите 30 реальных входов, прогоните через свой промпт и посчитайте две доли: сколько ответов верны по смыслу (читаете глазами) и сколько из верных прошли ваш фильтр. Если вторая цифра сильно ниже первой, чинить надо формат или разбор, а не модель.
Вот 30 пар «ответ модели → что поймал мой фильтр». Для каждой пары скажи:
1) верен ли ответ по смыслу, 2) принял ли его фильтр.
Посчитай долю верных ответов и долю верных, которые фильтр принял.
Покажи примеры форм, которые фильтр отклоняет, и предложи правила нормализации.
🔧 Техника: добавить явную строку «при ошибке формата» → предсказуемый сбой. В автоматизации задай запасное действие заранее: для рискованных решений (возврат денег, блокировка) — на ручную проверку, для безобидных (сортировка по папкам) — в ветку по умолчанию. Статья показывает, что одна и та же правильная метка приводит к разным действиям в зависимости от этого выбора.
Ресурсы
- Работа: REA: From Correct LLM Judgments to Safe Decision Delivery
- Авторы: Jingxiang Meng (University of Chicago), Aofan Liu (Peking University), Yaoshuai Ma (Southern University of Science and Technology), Fangxin Liu и Yongbiao Chen (Shanghai Jiao Tong University)
- Упомянутые в тексте: Llama Guard, WildGuard, GuardReasoner, XSTest, IFEval