TL;DR
Когда просишь LLM проанализировать ситуацию, модель тяготеет к наиболее вероятному ответу — и молча пропускает редкие, но катастрофические варианты. Исследователи из Йеля построили фреймворк AegisDx, который принудительно делит анализ на два независимых списка: наиболее вероятные объяснения и отдельный список «must-not-miss» — вещей с низкой вероятностью, но с высокой ценой ошибки.
Главная находка: LLM в режиме «один запрос — один ответ» оптимизирует под наибольшую вероятность. Редкие, но смертельно опасные варианты она систематически пропускает — не потому что не знает, а потому что они статистически невыгодны при генерации. В медицинских кейсах это означало, что модель называла правильный диагноз, но не называла тот, который убьёт пациента, если его не исключить. В бизнесе — то же самое: модель найдёт три очевидных риска, но промолчит о редком, который обнулит всё.
Решение — четыре обязательных блока в одном промпте: широкий список гипотез → явный must-not-miss список → проверка каждой гипотезы по известным фактам → конкретные следующие шаги. При вызове четырёх специализированных ролей (терапевт, кардиолог, инфекционист и т.д.) точность выросла на 7–17 процентных пунктов, а покрытие опасных пропусков — на 26 пунктов по сравнению с обычным запросом к той же модели.
Схема метода
Один промпт — четыре обязательных блока:
БЛОК 1: ШИРОКАЯ ГИПОТЕЗА
→ 3–5 вариантов объяснения/причины
→ Для каждого: какие факты поддерживают, какие противоречат
БЛОК 2: MUST-NOT-MISS (обязательный отдельный список)
→ 3–5 редких/нетипичных вариантов с высокой ценой пропуска
→ Почему каждый опасен, если его проигнорировать
БЛОК 3: ПРОВЕРКА
→ Сопоставление каждой гипотезы с известными данными/фактами
→ Что нужно, чтобы подтвердить или исключить
БЛОК 4: СЛЕДУЮЩИЕ ШАГИ
→ Конкретные действия в порядке приоритета
Все четыре блока — в одном промпте, в одном ответе
Пример применения
Задача: Антон ведёт переговоры о партнёрстве с венчурным фондом. Фонд предлагает 15 млн рублей за 25% доли с правом veto на стратегические решения. По ощущениям — нормально, надо проверить.
Промпт:
Ты — опытный корпоративный советник, который видел десятки инвестиционных сделок.
Вот условия: венчурный фонд входит за 25% доли, вкладывает 15 млн рублей,
получает право veto на стратегические решения (найм C-level, новые продукты,
привлечение следующих раундов). Мой стартап — B2B SaaS, ARR 4 млн руб.,
команда 5 человек, работаем 2 года.
Проведи анализ по четырём блокам:
**БЛОК 1 — ВЕРОЯТНЫЕ СЦЕНАРИИ**
Назови 3–5 реалистичных результата этой сделки через 3 года (хорошие и плохие).
Для каждого — какие факты поддерживают этот сценарий.
**БЛОК 2 — MUST-NOT-MISS: ЧТО НЕЛЬЗЯ ПРОПУСТИТЬ**
Это отдельный список. Назови 3–5 редких или неочевидных рисков, которые
маловероятны, но если произойдут — будут катастрофическими.
Почему каждый опасен. Что именно нужно проверить в договоре.
**БЛОК 3 — ПРОВЕРКА ФАКТАМИ**
Что из условий сделки настораживает с точки зрения рыночной нормы?
Что нужно уточнить у юриста и у других основателей, работавших с этим фондом?
**БЛОК 4 — СЛЕДУЮЩИЕ ШАГИ**
3–5 конкретных действий до подписания, в порядке приоритета.
Результат: Модель выдаст четыре чётких блока. В первом — привычные сценарии: рост с поддержкой фонда, конфликт по стратегии, проблемы с ликвидностью. Ценность — во втором блоке: там появятся нетипичные риски вроде clauses об антиразводнении при down-round, right of first refusal при продаже компании, или сценарий где право veto заблокирует привлечение стратегического инвестора в нужный момент. Именно эти пункты обычно не всплывают при обычном «проверь условия сделки».
Почему это работает
Слабость LLM — генерация текста оптимизирована под вероятность. Модель выдаёт наиболее статистически ожидаемое продолжение. Редкие катастрофические варианты «весят» меньше в распределении — и естественным образом вытесняются. Это не баг, это фундаментальная механика генерации.
Сильная сторона LLM — модель знает огромный корпус прецедентов: юридических, медицинских, бизнесовых, инженерных. Все редкие, но важные случаи там есть. Проблема не в незнании — проблема в том, что без явного запроса модель их не вычленяет.
Как метод использует это: Явный блок «MUST-NOT-MISS» — это инструкция принудительно активировать ту часть знании, которая при свободной генерации остаётся в тени. Ты буквально говоришь модели: «я знаю, что это редко — назови именно это». Это меняет задачу с «генерируй вероятное» на «сгенерируй важное, даже если маловероятное». И модель справляется — она знает что это.
Рычаги управления: - Количество в must-not-miss: 3 — для быстрой проверки, 7–10 — для критически важных решений - Специализация ролей: вместо «опытный советник» пиши «опытный M&A-юрист» или «бывший инвестор с опытом down-round» — острее выpolнение роли, точнее нетипичные риски - Уровень детализации в блоке 3: добавь «с конкретными формулировками для юриста» — получишь готовые вопросы к специалисту - Блок 4: замени «следующие шаги» на «красные флаги, при которых сделку не стоит закрывать» — переключит режим с action plan на go/no-go checklist
Шаблон промпта
Ты — {роль_эксперта} с опытом {область_экспертизы}.
Вот ситуация: {описание_ситуации_с_ключевыми_фактами}
Проведи анализ по четырём блокам:
**БЛОК 1 — ВЕРОЯТНЫЕ СЦЕНАРИИ**
Назови {число_3_5} наиболее вероятных результата.
Для каждого — какие из известных фактов его поддерживают.
**БЛОК 2 — MUST-NOT-MISS (ОБЯЗАТЕЛЬНО)**
Это отдельный список. Назови {число_3_5} редких или неочевидных {риска/причины/варианта},
которые маловероятны, но имеют высокую цену ошибки, если их пропустить.
Для каждого: почему опасен и что нужно проверить.
**БЛОК 3 — ПРОВЕРКА**
Что из {ситуации} требует дополнительной проверки?
Что именно нужно уточнить и у кого?
**БЛОК 4 — СЛЕДУЮЩИЕ ШАГИ**
{число_3_5} конкретных действий в порядке приоритета.
Что подставлять:
- {роль_эксперта} → «опытный кардиолог», «M&A-юрист», «продакт с 10 годами в SaaS», «финансовый директор»
- {область_экспертизы} → «венчурных сделок», «медицинской диагностики», «запуска новых продуктов»
- {описание_ситуации} → ключевые факты, цифры, условия — чем конкретнее, тем точнее must-not-miss
- {число_3_5} — для быстрой проверки ставь 3, для важного решения — 5–7
🚀 Быстрый старт — вставь в чат:
Вот шаблон анализа с обязательным must-not-miss блоком.
Адаптируй под мою задачу: {твоя задача одним предложением}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит роль эксперта и ключевые факты ситуации — потому что без контекста must-not-miss список будет слишком общим и не попадёт в специфику твоего случая.
Ограничения
⚠️ Качество must-not-miss зависит от деталей: Чем беднее описание ситуации, тем более общими будут «редкие риски». С размытым запросом («проверь мою идею») модель выдаст стандартные чеклисты вместо специфических пропусков. Давай конкретные цифры, условия, контекст.
⚠️ Читаемость против полноты: Исследователи сами обнаружили: чем полнее и безопаснее ответ, тем он длиннее и труднее для быстрого чтения. Если нужен компактный ответ — явно добавь в промпт «каждый пункт — не более двух предложений».
⚠️ Не замена специалисту в критических областях: Для медицинских симптомов и юридических документов must-not-miss от LLM — это стартовая точка для разговора с врачом или юристом, не финальное решение. Фреймворк помогает сформулировать правильные вопросы, не заменяет профессиональную экспертизу.
⚠️ Блок 2 требует явного запроса каждый раз: Модель не будет автоматически добавлять must-not-miss без инструкции. Это нужно прописывать в промпте намеренно — иначе возвращаемся к стандартной генерации по вероятности.
Как исследовали
Команда из Йельской школы медицины собрала клинические кейсы из четырёх источников: разборы из NEJM и JAMA (782 случая), экстренные случаи из Annals of Emergency Medicine (50 случаев) и реальные деобезличенные карточки пациентов из йельской больницы (43 случая). Для каждого кейса запускали и обычный LLM-запрос, и AegisDx на одинаковой базовой модели — чтобы разница в результатах была точно от архитектуры фреймворка, а не от более умной модели. Проверяли на четырёх разных LLM: Qwen3-32B, LLaMA-3.1-70B, GPT-4.1 и GPT-oss-120B.
Самый интересный результат — не общий прирост точности, а именно must-not-miss покрытие. Обычная модель называла хотя бы одно «нельзя пропустить» состояние в 52% случаев. AegisDx — в 78%. Это +26 процентных пунктов на одних и тех же данных, с той же базовой моделью. Разница только в том, что фреймворк принудительно требует отдельного прохода по опасным сценариям.
Врачи оценивали 43 реальных случая вслепую: не знали, который ответ от AegisDx, который от GPT-5. По безопасности AegisDx выиграл с p < 0.001. Но — любопытный контраргумент — по читаемости проиграл. Полный структурированный ответ с доказательствами оказался слишком длинным для врача в приёмном покое. Из чего следует важный вывод для промптинга: безопасность и лаконичность в конфликте, нужно явно управлять балансом.
Адаптации и экстраполяции
1. Must-not-miss для любого анализа без медицинского контекста:
Принцип «явный список неочевидных катастроф» универсален. Вот как это выглядит в чистом виде:
🔧 Техника: добавить один параграф в любой аналитический промпт
К любому запросу типа «проанализируй X» / «оцени Y» / «проверь Z» добавь:
Отдельным блоком: назови 3–5 сценариев с низкой вероятностью, но высокой ценой ошибки, если их проигнорировать. Это именно те варианты, которые легко упустить при стандартном анализе.Этот один абзац меняет режим генерации с «вероятное» на «важное».
2. Комбинация с ролевыми дебатами:
Для сложных решений — запусти must-not-miss через двух антагонистов:
Агент А (оптимист): назови топ-3 вероятных позитивных сценария с обоснованием. Агент Б (скептик-параноик): назови топ-5 редких, но катастрофических рисков, которые оптимист в блоке А скорее всего проигнорирует. Будь конкретен. Итог: что из этого критично проверить до принятия решения?Конфликт ролей активирует более sharp must-not-miss список — скептик не заинтересован в «вероятных» рисках, он ищет именно пропущенное.
Ресурсы
Статья: A safety-oriented hypothetico-deductive framework for AI-assisted differential diagnosis
Авторы: Fan Ma, Mauro Giuffrè, Donald Wright, Kent McCann, Mark Iscoe и др.
Аффилиация: Yale School of Medicine (Department of Biomedical Informatics and Data Science), Vanderbilt University, Università degli Studi di Trieste
Контакт: hua.xu@yale.edu