TL;DR
Когда вы просите LLM оценить риск ("какая вероятность, что это провалится?") и сразу же сообщаете, во сколько раз одна ошибка дороже другой, модель меняет саму цифру риска — не только решение. Причина одна: и вероятность, и действие модель генерирует в одном ответе, и информация о цене ошибки просачивается в оценку, хотя факты о самой задаче не изменились.
Представьте: вы просите оценить риск сделки на 20%. Потом говорите "если одобрим плохую сделку — потеря в 10 раз больше, чем если откажем от хорошей". По логике вероятность 20% должна остаться той же — изменился только порог, при котором стоит отказывать. Но на практике модель начинает называть то 5%, то 35% — цифра "гуляет" в зависимости от того, что ей сказали про цену ошибки, а не от новых фактов.
Решение простое: спрашивать вероятность отдельно, без единого упоминания цены ошибки, а порог решения ("одобрить/отклонить") применять отдельным шагом — вручную или в отдельном запросе, используя явную формулу из цены ошибок. Дополнительно исследование показало: если у вас есть второе, независимое мнение (второй эксперт/модель), точнее объединять его с первым через простую формулу, а не просить модель "учесть, что второе мнение надёжно на 80%, и подправить свою оценку".
Схема метода
ШАГ 1 (отдельный запрос, без упоминания цены ошибки):
Дай модели только факты → получи чистую вероятность риска (0-100%)
ШАГ 2 (отдельный запрос или расчёт вручную):
Задай явный порог решения = Цена_ложного_отказа / (Цена_ложного_одобрения + Цена_ложного_отказа)
Сравни вероятность из ШАГА 1 с порогом → получи решение (одобрить/отклонить)
(опционально) ШАГ 3 — второе мнение:
Получи вероятность от второго, независимого источника (другая модель/сессия без контекста первой)
Объедини две вероятности формулой (не проси модель "поверить и подправить себя")
Пример применения
Задача: Владелец интернет-магазина оценивает риск сотрудничества с новым поставщиком перед крупной предоплатой.
Промпт (Шаг 1 — отдельное сообщение или новый чат):
Вот факты о поставщике: работает на рынке 1 год, три отзыва в интернете —
два положительных, один про задержку поставки на 2 недели. Готов дать скидку 15%
за предоплату 100%. Документы ИП в порядке, ИНН проверен.
Оцени вероятность (от 0 до 100%), что поставщик не выполнит обязательства
(не привезёт товар или сильно задержит).
Важно: оценивай только на основе этих фактов. Не учитывай никакие финансовые
последствия ошибки — только вероятность самого события.
Промпт (Шаг 2 — отдельное сообщение):
У меня есть вероятность невыполнения обязательств поставщиком: {вероятность из шага 1}.
Цена ошибок:
- Если одобрю предоплату, а поставщик подведёт — потеряю 300 000 руб.
- Если откажу, а поставщик был надёжным — потеряю выгоду в 30 000 руб (скидка + время).
Посчитай порог по формуле: порог = 30000 / (300000 + 30000).
Сравни вероятность с порогом и скажи: одобрять предоплату или отказать.
Результат: В первом ответе — чистое число вероятности без всякого влияния денег на кону. Во втором — расчёт порога (около 9%) и однозначный вывод "одобрить" или "отказать" на основе сравнения. Если позже цена ошибки изменится (например, сумма сделки другая), вероятность из шага 1 останется валидной — пересчитать нужно только шаг 2.
Почему это работает
LLM не хранит вероятность и решение как две разные внутренние переменные — она генерирует текст, который зависит от всего, что видит в промпте. Если в одном запросе одновременно лежат факты о задаче и информация о цене ошибки, модель "смешивает" их при формировании числа, даже если её просили оценивать только факты.
Зато LLM неплохо справляется с изолированной задачей: когда в контексте нет ничего про стоимость ошибок, она честнее оценивает именно вероятность. А явную математическую формулу (порог = цена/(сумма цен)) она способна точно применить, если её попросили сделать это как отдельный, чистый расчёт — без параллельного "взвешивания" рисков в уме.
Метод разрывает эту связь физически: факты и цена ошибки никогда не оказываются в одном запросе одновременно с просьбой "оцени риск". Числа остаются переиспользуемыми — можно взять один и тот же риск-скор и применить к нему разные пороги для разных ситуаций.
Рычаги управления: - Формула порога → меняйте цифры цены ошибки под свою ситуацию (10:1, 3:1, 20:1) — порог пересчитывается математически, вероятность не трогаем. - Второе независимое мнение → просите вторую модель (или новый чат без контекста первого) дать свою оценку, потом объединяйте формулой правдоподобия, а не текстовой просьбой "учти это и поправь себя". - Разделение на сессии → чем чище "клетка" для первого запроса (без единого слова про деньги, риски бизнеса, последствия), тем честнее число.
Шаблон промпта
ЗАПРОС 1 (только оценка риска):
Вот факты: {факты о ситуации/объекте оценки}.
Оцени вероятность (0-100%) события: {описание негативного события}.
Оценивай только на основе фактов выше. Не учитывай финансовые или другие
последствия ошибки — они появятся позже отдельно.
---
ЗАПРОС 2 (применение решения, отдельным сообщением):
Вероятность события: {число из Запроса 1}.
Цена ошибок:
- Если одобрю, а событие произойдёт — потеря {цена_A}.
- Если откажу, а событие бы не произошло — потеря {цена_B}.
Посчитай порог = {цена_B} / ({цена_A} + {цена_B}).
Сравни вероятность с порогом и дай итоговое решение: одобрить или отказать.
Подставьте: {факты} — то, что вы знаете о ситуации; {описание негативного события} — что именно оценивается (провал, невыполнение, брак и т.д.); {цена_A} и {цена_B} — стоимость каждого типа ошибки в рублях или условных единицах.
🚀 Быстрый старт — вставь в чат:
Вот принцип разделения оценки риска и решения. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про факты ситуации и про цену двух видов ошибок отдельно — потому что метод требует, чтобы вероятность и решение никогда не смешивались в одном запросе.
Ограничения
⚠️ Не спасает от плохой оценки риска саму по себе: разделение убирает искажение от цены ошибки, но если модель в принципе плохо различает "рискованное" и "надёжное" — решения всё равно будут слабыми. В исследовании при очень высокой цене ошибки даже "очищенная" вероятность заставляла модель отказывать всем подряд — то есть решения были не лучше, чем просто отказать всем без всякого анализа.
⚠️ Нужно два отдельных запроса, а не один: это не однострочный промпт — метод требует дисциплины: не смешивать факты и цену ошибки в одном сообщении, даже если хочется сэкономить время.
⚠️ Формула порога — это упрощение: реальные решения часто зависят не только от денег, но и от репутации, юридических рисков и т.д. Формула из статьи — это стартовая точка, не универсальный калькулятор для всех ситуаций.
Как исследовали
Команда взяла 720 патчей кода (по одному прошедшему и одному провалившему тесты на 360 issue из реальных репозиториев) и заставила четыре разные LLM ("ревьюеры": DeepSeek, Grok, Mistral, GPT/Codex) оценивать риск и принимать решение "одобрить/отклонить" в одном промпте. Ключевой трюк: одни и те же патчи и факты показывали модели дважды — с равной ценой ошибок и с ценой "ошибочное одобрение в 10 раз дороже" — и сравнивали, изменится ли число вероятности, хотя факты не менялись.
Результат: вероятность менялась на 13.6–16.9 процентных пунктов в среднем — значительно больше, чем при простом повторе одного и того же запроса. Хуже того: решения, которые модели выдавали под "дорогим" промптом, были хуже, чем если бы вообще всё отклоняли без анализа. А когда исследователи взяли те же самые вероятности из "дешёвого" промпта и применили к ним ту же самую дорогую формулу порога — потери снизились для всех четырёх моделей. Это доказывает: проблема не в правиле принятия решения, а в том, что сама вероятность портится, когда рядом лежит информация о цене ошибки.
Отдельно проверили модульный подход — вероятность спрашивали без единого слова про политику решений, добавляли независимую вторую оценку ("монитор") и порог применяли кодом. Это снизило средние потери и повысило точность вероятности по сравнению с обычным одношаговым ревью — хотя при очень высокой цене ошибки даже такой чистый подход не находил ни одного патча, который стоило одобрить.
Ресурсы
When Policies Change Probabilities: Modular Decision-Making for LLM Code Review — Rasvik Kudum, Max Corbett, Hitansh Paliwal, Romaisa Fatima, Thomas Jiralerspong, Sneheel Sarangi (июль 2026). Код и данные: github.com/rasvik/when-policies-change-probabilities.