Проблема: LLM как уверенный дилетант
Спроси у ChatGPT: "Стоит ли внедрять Kubernetes в стартап из пяти человек?" Получишь развернутый, убедительный, абсолютно уверенный ответ. Он будет звучать логично, подкреплен аргументами, но будет одним вариантом. Единственным. Без "а если", без "но", без "вероятность успеха 60%".
Это главная проблема современных LLM в контексте принятия решений. Они выдают монолитный ответ, скрывая за красивой упаковкой фундаментальную неопределенность реального мира. Они не умеют говорить "не знаю" в сложных вопросах — вместо этого генерируют наиболее правдоподобное продолжение текста. Это делает их опасными советчиками в бизнесе, инженерии, медицине — везде, где цена ошибки высока.
Самый опасный ответ LLM — тот, который выглядит абсолютно правильным, но игнорирует альтернативные сценарии. Вы получаете иллюзию знания вместо карты вероятностей.
Традиционные подходы вроде RAG решают проблему достоверности фактов, но не проблему когнитивных искажений самой модели. Даже с идеальными данными LLM склонна к confirmation bias — подбирать аргументы под самый вероятный сценарий, игнорируя маловероятные, но катастрофические варианты.
Решение: думать не ответами, а распределениями вероятностей
Probabilistic Multi-Variant Reasoning (PMR) — это не новый алгоритм, а методология промптинга. Ее суть в том, чтобы заставить LLM генерировать не один ответ, а множество взаимосвязанных сценариев с явными вероятностями и зависимостями.
Вместо вопроса "Что делать?" PMR задает целый каскад уточняющих промптов:
- Сгенерируй 5-7 принципиально разных сценариев развития ситуации
- Для каждого сценария оцени вероятность реализации (сумма вероятностей может быть не 100% — это важно)
- Определи триггеры — какие события переключают нас между сценариями
- Оцени ущерб/выгоду для каждого варианта
- Выяви скрытые зависимости между факторами
Результат — не решение, а карта принятия решений. Вы видите не только куда идти, но и какие развилки встретятся на пути, и что будет если свернуть не туда.
Как это работает на практике: пошаговый разбор
1 Формулируем проблему как систему, а не как вопрос
Неправильно: "Какой фреймворк для ML выбрать?"
Правильно: "У нас команда из 3 человек, преимущественно с опытом в PyTorch. Нужно развернуть модель для предсказания оттока клиентов. Критичны: время вывода < 100мс, возможность A/B тестирования, стоимость инфраструктуры < $500/мес. Сгенерируй варианты архитектурных решений с оценкой рисков для каждого."
Разница фундаментальна. В первом случае LLM начнет перечислять фреймворки с их фичами. Во втором — должна анализировать компромиссы между скоростью, стоимостью и сложностью поддержки.
2 Генерация ортогональных сценариев
Ключевое слово — ортогональных. Не "вариант А, вариант А немного измененный, вариант А с другой библиотекой". Нужны принципиально разные подходы.
Промпт: "Для описанной задачи предложи три принципиально разных архитектурных подхода, которые отличаются по: 1) разделению ответственности между компонентами, 2) способу обработки данных, 3) модели развертывания."
Пример для задачи ML-пайплайна:
| Сценарий | Суть | Критический риск |
|---|---|---|
| Монолит на FastAPI | Вся логика в одном сервисе, прототип за 2 дня | Масштабирование по памяти при росте моделей |
| Микросервисы + очередь | Отдельные сервисы для предобработки, инференса, постобработки | Сложность отладки распределенной системы |
| Serverless на AWS Lambda | Платим только за время выполнения, автоматическое масштабирование | Холодный старт лямбд > 10с, что неприемлемо для 100мс SLA |
3 Присвоение вероятностей и выявление зависимостей
Самый тонкий момент. LLM по своей природе не умеет оценивать вероятности — у нее нет доступа к статистике реального мира. Но она может оценивать относительные вероятности в рамках заданного контекста.
Промпт: "Для каждого сценария оцени вероятность успешной реализации в срок до 2 месяцев, учитывая что у команды нет опыта с микросервисами. Оцени как внутренние факторы (навыки команды), так и внешние (ограничения облачных провайдеров). Укажи, какие факторы могут изменить вероятность в процессе реализации."
Не заставляйте LLM давать абсолютные вероятности ("шанс успеха 73.5%"). Просите относительные оценки: "высокая/средняя/низкая" или сравнивайте сценарии: "вариант А имеет бóльшие шансы на успех, чем вариант Б, потому что...".
4 Анализ цепных реакций и black swan событий
Здесь PMR расходится с традиционным анализом рисков. Вместо "оцени риски для каждого сценария" мы спрашиваем: "Какие маловероятные события могут полностью изменить ситуацию?"
Промпт: "Для сценария с микросервисами: предположи три маловероятных события (вероятность < 5%), которые в случае реализации сделают этот вариант катастрофически невыгодным. Оцени ущерб для каждого такого события."
Пример ответа LLM:
- "Выход из строя managed Kafka в облаке на 4+ часа (вероятность 1%, ущерб — простой всей системы, потеря данных в очереди)"
- "Обнаружение критической уязвимости в выбранном фреймворке для gRPC, требующее полного переписывания коммуникации (вероятность 3%, ущерб — 2 недели работы senior разработчика)"
- "Изменение pricing policy облачного провайдера, увеличивающее стоимость передачи данных между availability zones в 5 раз (вероятность 2%, ущерб — рост месячных расходов на $800)"
Технические нюансы: почему PMR не работает из коробки
Основная модель, с которой вы пытаетесь применить PMR, скорее всего, откажется работать. Причины:
- Склонность к единственному ответу: Даже при явном указании "сгенерируй 5 вариантов" модель часто выдает один вариант и четыре его вариации.
- Проблема с вероятностями: Модели обучены на текстах, где вероятности либо не упоминаются, либо упоминаются некорректно. Они не калиброваны для вероятностных суждений.
- Иллюзия понимания: LLM может красиво рассуждать о вероятностях, не имея реальных данных для их оценки.
Решение? Комбинация техник:
Температура sampling и multiple generations
Не просите одну генерацию с пятью вариантами. Делайте пять отдельных запросов с высокой температурой (0.8-1.0), каждый раз немного меняя формулировку вопроса. Затем анализируйте пересечения и различия.
Использование специализированных reasoning-моделей
Модели вроде тех, что обсуждались в сравнении KEF и OpenAI o3, специально заточены под многошаговые рассуждения. Они дороже, но дают более структурированный вывод.
Контрольные вопросы для валидации
После генерации сценариев задайте модели:
# Пример промпта для валидации
validation_prompt = """
Для сгенерированного сценария 'Микросервисы + очередь' ответь:
1. Какие три предположения являются наиболее спорными?
2. Какие данные нужны, чтобы проверить эти предположения?
3. Если предположение №2 окажется ложным, как изменится вероятность успеха?
"""Распространенные ошибки при внедрении PMR
Ошибка 1: Слепая вера в числовые вероятности
Если модель говорит "вероятность успеха 85%" — это не значит, что успех наступит в 85 случаях из 100. Это значит, что в ее обучающих данных подобные утверждения часто сопровождались такой цифрой. Цифры от LLM — это лингвистические паттерны, не статистические оценки.
Ошибка 2: Игнорирование мета-рисков
PMR хорошо выявляет риски внутри системы, но плохо справляется с рисками самой методологии. Например, риск того, что команда неправильно интерпретирует выводы LLM. Или риск того, что ключевое ограничение не было упомянуто в промпте.
Ошибка 3: PMR как замена экспертизы
Это инструмент для структурирования мышления, не для генерации истины. Если вы не знаете предметной области, PMR не сделает вас экспертом. Она лишь систематизирует ваши незнания.
Интеграция PMR в рабочие процессы
PMR не существует в вакууме. Вот как встроить ее в реальные процессы:
Для инженерных решений
Перед выбором архитектуры проведите PMR-сессию с моделью. Зафиксируйте сценарии в ADR (Architecture Decision Record). Укажите не только выбранный вариант, но и отвергнутые сценарии с причинами отказа. Через полгода вернитесь и проверьте, сбылись ли прогнозы о рисках.
Для продуктовых решений
Приоритизация фич через PMR: вместо "делаем фичу А" → "если делаем фичу А, вероятные outcomes: X (40%), Y (30%), Z (30%). Для фичи Б распределение другое...". Это превращает roadmap из списка хотелок в дерево решений с явными компромиссами.
Для инцидент-менеджмента
Во время серьезного инцидента вместо "пробуем решение А" → "решение А имеет 70% шанс исправить проблему за 30 минут, но 5% шанс усугубить. Решение Б имеет 50% шанс исправить за 2 часа, но почти нулевой шанс усугубить".
Будущее: PMR как стандарт взаимодействия с ИИ
Судя по трендам, обсуждаемым в итогах 2025 года в мире LLM, мы движемся к тому, что модели будут явно указывать неопределенность в своих ответах. PMR — шаг в этом направлении.
Но главный сдвиг произойдет не в моделях, а в нас. Мы перестанем спрашивать у ИИ "что делать", и начнем спрашивать "какие варианты у меня есть, и чем я рискую в каждом случае". Это превращает ИИ из гадалки в инструмент для раскрытия слепых пятен в нашем мышлении.
Попробуйте на следующем же сложном решении. Сформулируйте проблему как систему. Запросите ортогональные сценарии. Оцените вероятности. Выявите триггеры. Вы удивитесь, сколько альтернативных путей вы не рассматривали, пока ИИ не показал их вам в явном виде.
И помните: лучший результат PMR — не когда модель подтверждает вашу интуицию, а когда она показывает вариант, о котором вы даже не думали. Вот тогда вы действительно используете ИИ, а не ищете в нем свое отражение.
