TL;DR
Controlled LLM Workflow — это связка из трёх этапов. Сначала обычные скрипты (не LLM) отбирают похожие случаи и готовят проверенные факты, каждому факту присваивается ID. Затем LLM объясняет разницу, опираясь только на эти факты и ссылаясь на их ID. В конце программный валидатор проверяет формат и ссылки. Если проверка не пройдена, модель получает список ошибок и один раз переделывает ответ.
Главная находка: если не прописать процедуру, агент её не соблюдает. В исследовании агенту дали простой вопрос: «почему у этой транзакции оценка риска отличается от похожих?» Без инструкций по шагам он в большинстве прогонов подбирал «похожие» случаи с почти такой же оценкой. Из-за этого вопрос подменялся: вместо «чем отличается» он отвечал «почему оценка высокая». Ссылок на источники не было ни в одном ответе, а сравнение с общей картиной почти никогда не делалось. С инструкциями (в виде скила) все 900 прогонов шли строго по процедуре.
Суть метода в разделении ролей. Скрипты делают то, что должно быть точным: отбор, расчёты, проверки. LLM делает то, что умеет хорошо: связывает факты в объяснение. Валидатор не выпускает ответ без ссылок на доказательства.
Схема метода
ЭТАП 1 (скрипты, не LLM): отобрать похожие случаи с заданной разницей
в оценке → собрать факты, проверить расчёты, выдать каждому
факту ID и пометку об ограничениях → «пакет доказательств»
ЭТАП 2 (LLM): объяснить разницу ТОЛЬКО по пакету →
сравнить конкретный случай с эталонами, затем с общей картиной →
каждое утверждение с ID факта → диагноз в заданном формате
ЭТАП 3 (валидатор, не LLM): проверить формат, существование ID,
что утверждения подкреплены, что указаны ограничения →
если провал: ошибки обратно в LLM, ОДНА правка, повторная проверка →
если снова провал: диагноз не выдаётся
Всё это упаковано в Codex Skill: готовый набор инструкций и инструментов, который агент подключает сам.
Пример применения
В статье сценарий узкий: антифрод и SHAP (метод, показывающий вклад каждого признака в оценку модели). Сама идея шире: «объясни, почему у моего объекта результат хуже/лучше, чем у похожих». Сильная зона метода — когда у вас есть таблица с числами, из неё можно отобрать похожие случаи, а ответ нужен с опорой на данные.
Задача: Селлер на Wildberries не понимает, почему карточка «Худи оверсайз, 3 490 ₽» продаётся втрое хуже, чем похожие карточки конкурентов. Он выгрузил таблицу по 40 карточкам: цена, рейтинг, число отзывов, позиция в выдаче, доля фото, наличие видео, конверсия в заказ.
Ниже перенос паттерна в чат. Этап 1 селлер делает вручную в таблице: отбирает 10 похожих карточек с конверсией выше на 30% и больше и нумерует факты.
Промпт:
Ты аналитик маркетплейса. Объясни, почему конверсия моей карточки
ниже, чем у похожих.
ПАКЕТ ДОКАЗАТЕЛЬСТВ (используй только его, ничего не додумывай):
[E1] Моя карточка: цена 3 490 ₽, рейтинг 4,3, отзывов 58, позиция
в выдаче 47, фото 4, видео нет, конверсия 1,9%.
[E2] Эталон 1: цена 3 290 ₽, рейтинг 4,8, отзывов 1 240, позиция 6,
фото 9, видео есть, конверсия 6,1%.
[E3] Эталон 2: ...
...
[E11] Среднее по всем 40 карточкам: рейтинг 4,6, отзывов 410,
конверсия 3,8%.
[E12] Ограничения: выгрузка за 14 дней; рекламные расходы
не учтены; категория «худи» без разбивки по сезону.
ПРАВИЛА:
1. Сначала сравни мою карточку с эталонами, затем с общей картиной (E11).
2. Раздели причины на «главные отличия» (резко отличаются от эталонов)
и «общие факторы» (одинаковы у меня и у эталонов).
3. Каждое утверждение — со ссылкой на ID в квадратных скобках.
Если ссылки нет, утверждение не пиши.
4. В конце обязательно блок «Ограничения» (по E12 и что ещё
не покрыто данными).
ФОРМАТ: «Главные отличия», «Общие факторы», «Сравнение с общей
картиной», «Ограничения».
После ответа проверь себя по списку: у каждого утверждения есть
существующий ID? Все четыре блока на месте? Если нет, исправь
один раз и выдай финальную версию.
Результат: Модель выдаст отчёт из четырёх блоков. Каждая фраза будет со ссылками вида [E1], [E2]. Главные отличия вынесены отдельно от факторов, общих для всех карточек. Отдельно будет сравнение с рынком и честный блок ограничений. Если модель попытается написать что-то без опоры на данные, самопроверка должна это поймать. Это слабее, чем программный валидатор, но уже сильно дисциплинирует ответ.
Почему это работает
Слабость LLM. Если сказать агенту «объясни разницу» и не дать процедуры, он выберет самый лёгкий путь. Он возьмёт «похожие» случаи на глаз и объяснит только сам случай. Шаги вроде SHAP или сравнения с общей картиной он то делает, то нет. Ссылок на источники нет, поэтому проверить ответ нельзя.
Сильная сторона LLM. Она хорошо связывает готовые факты в понятное объяснение и умеет следовать формату, если он задан. Точные операции (расстояния, фильтры, проверка сумм) лучше отдать скриптам.
Как метод это использует. Он забирает у LLM всё, где нужна точность, и оставляет ей интерпретацию. ID превращают «правдоподобный текст» в проверяемый: любое утверждение можно проследить до факта. Порог разницы в оценке (в статье 0,2) закрывает конкретную дыру: без него «похожие случаи» подменяют вопрос.
Рычаги управления: - Порог контраста (в статье 0,2 по шкале 0–1): задаёт, насколько эталон должен отличаться по результату. Подберите под свою шкалу и не снижайте ради числа эталонов. Если подходящих меньше десяти, берите все. - Число эталонов (в статье 10): меньше ведёт к зависимости от одного случая, больше размывает картину. - Число попыток правки (в статье одна): увеличьте, если ошибки формата частые. - Формат вывода и обязательные блоки: определяют, что валидатор может проверить. - Запрет на внешние знания: «только по пакету» повышает прослеживаемость, но снижает полноту.
Шаблон промпта
Этот шаблон повторяет структуру из статьи: три этапа, доказательства с ID, запрет выходить за пакет, один круг правки.
РОЛЬ: ты аналитик, который объясняет, почему у объекта {объект}
результат {метрика} отличается от результата похожих объектов.
ВОПРОС АНАЛИТИКА: {вопрос}
ЭТАП 1. ПОДГОТОВКА ДОКАЗАТЕЛЬСТВ
(выполняется скриптами или вручную до обращения к тебе)
- Выбраны {K} похожих объектов с разницей в {метрика} не менее {порог}.
- Если подходящих меньше {K}, взяты все подходящие. Порог не снижать.
- Все расчёты проверены. Каждому факту присвоен ID.
ПАКЕТ ДОКАЗАТЕЛЬСТВ:
[E1] {факты по целевому объекту}
[E2..E{N}] {факты по эталонам}
[E{N+1}] {общая статистика по всей выборке}
[E{N+2}] {известные ограничения данных}
ЭТАП 2. ДИАГНОЗ (твоя часть)
1. Сравни целевой объект с эталонами: найди признаки,
чей вклад отличается сильнее всего («главные отличия»).
2. Отдельно выдели «общие факторы»: важны и у целевого объекта,
и у эталонов, направление одинаковое.
3. Сравни локальную картину с общей ({общая статистика}):
подтверждает она локальные выводы или противоречит.
4. Используй ТОЛЬКО пакет доказательств. Каждое утверждение
сопровождай ID: [E…]. Нет ID — не пиши.
5. Укажи ограничения.
ФОРМАТ ОТВЕТА (обязательные блоки):
{главные отличия} / {общие факторы} / {локальное и общее} / {ограничения}
ЭТАП 3. ВАЛИДАЦИЯ
Проверка: (а) все блоки на месте; (б) все ID существуют в пакете;
(в) каждое утверждение подкреплено указанным ID;
(г) локальные и общие оценки помечены; (д) ограничения указаны.
Если есть ошибки, они будут возвращены тебе списком. Исправь
диагноз ОДИН раз и представь заново. Если ошибки остались,
диагноз не принимается.
Что подставлять: {объект} — то, что объясняем (транзакция, лид, карточка, тикет). {метрика} — по чему считается «разница» (оценка, конверсия, срок). {K} — число эталонов, {порог} — минимальная разница. Факты и числа подготовьте заранее: в таблице, скриптом или поручите агенту отдельным шагом.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Controlled LLM Workflow. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно сравниваем, по какой метрике и какой порог разницы считать значимым. Это нужно, чтобы эталоны действительно отличались по результату и вопрос не подменялся. Ещё она спросит, какие данные у вас есть для пакета доказательств, чтобы корректно расставить ID. Дальше она возьмёт структуру из шаблона и соберёт рабочий промпт под ваш случай.
Адаптации (мои, не из статьи)
- Без кода в чате: этап 1 делается вручную в таблице, этап 3 заменяется самопроверкой по чек-листу. Это слабее программной проверки, поэтому её надёжность стоит проверить на своих данных.
- В агенте (Claude Code, Cursor): оформите этапы как скил или раздел CLAUDE.md и попросите агента самого написать скрипт отбора и проверки. Так вы получите настоящий валидатор без ручного кодинга.
- Другие домены: причины отказа по заявкам, разброс времени решения тикетов, почему один лид «горячий», а похожий нет.
Ограничения
⚠️ Слабое сравнение: Контрольная группа получила только вопрос и файлы, без каких-либо инструкций по шагам. Поэтому разрыв огромный. Это показывает «процедура нужна», но не «именно эта процедура лучшая». Влияние отдельных частей (ID, валидатор, порог) не проверяли.
⚠️ Валидатор проверяет форму, не истину: Он убеждается, что ссылки существуют и формат соблюдён. Правильно ли объяснение по сути, он не оценивает. Авторы это прямо признают.
⚠️ Нужна инженерия: Рабочая версия требует кода: отбор похожих случаев, расчёт SHAP, проверки. В чате воспроизводится только упрощённая часть.
⚠️ Узкая проверка: Один синтетический датасет, одна модель риска, одна LLM-конфигурация, по три прогона на транзакцию. Живые аналитики полезность диагнозов не оценивали.
⚠️ Нет готового промпта: Текст самого скила в статье не приведён. Шаблон выше — реконструкция по описанию этапов.
Как исследовали
На симулированных платёжных данных (около 200 тыс. транзакций, меньше 1% мошеннических) обучили XGBoost. Для 300 тестовых транзакций (по 100 с низким, средним и высоким риском) запускали агента Codex дважды: с подключённым скилом и без. Каждый вариант прогнали по три раза, итого по 900 запусков. Вопрос один и тот же. Без скила валидный набор контрастных эталонов нашёлся в 1,8% запусков, SHAP использован в 52,8%, сравнение с общей картиной сделано в 0,8%, ссылок на доказательства не было вовсе. Со скилом все показатели были 100%. Отдельно проверили, что подобранные эталоны заметно ближе к цели, чем случайные, и что SHAP-значения совпадают с выходом модели.
Ресурсы
- Работа: A Controlled LLM Workflow for Evidence-Grounded Diagnosis of Risk Score Differences, ICECER 2026, Стамбул.
- Авторы: Hanqing Dou (University of California San Diego), Zijia Cao (The University of Chicago).
- Данные: Fraud Detection Handbook (Le Borgne et al., Université Libre de Bruxelles) — https://fraud-detection-handbook.github.io/fraud-detection-handbook/
- Связанные работы: XAIstories, Explingo (LLM-пересказ объяснений моделей), Lundberg et al. 2020 (Tree SHAP).