LLM для принятия решений: когда модель должна принимать решения, а когда — нет

Спросите у практиков, что ломается в агентных системах, и ответ редко будет касаться возможностей. Отказ происходит незаметнее: модель принимает решение, и никто не способен отличить грамотное рассуждение от плавной речи.

Вывод модели — это выборка. Решение обладает свойствами, которых у выборки нет: определённость для фиксированного входа, инварианты, которым оно должно соответствовать, и след аудита, объясняющий, почему было выбрано именно это, а не альтернатива. Когда эти свойства отсутствуют, «решение» представляет собой догадку с высокой степенью уверенности, одетую в одеяние решения.

В этой статье этому разрыву даётся механическая обработка: таксономия пяти ролей принятия решений, правило маршрутизации каждого решения к наименьшей модели, компетентной для него, а также механизмы верификации, превращающие «агент принял решение X» в то, что впоследствии можно доказать как обоснованное. Статья завершается критериями оценки (rubric), которые можно применить к любому действию в вашей системе.

«Для локальных агентов разрыв, на который я постоянно натыкаюсь, — это не возможности, а верификация. Агент утверждает, что прочитал файл, вызвал инструмент или принял решение…» — r/LocalLLaMA, «Лучшие локальные агенты — июнь 2026»

«Когда агент на базе LLM терпит неудачу, это черновик, и никто не знает почему. Истинное препятствие для внедрения — это не повышение точности модели с 92% до 96%, а [понимание того, почему было принято решение X]» — r/AI_Agents, «Разрыв между решением и исполнением»

Сообщество сошлось в трёх инстинктах: не доверять модели последний звонок, маршрутизировать решение к наименьшей компетентной модели и делать решение объяснимым. Чего не хватало, так это рамки, делающей все три пункта реализуемыми одновременно.

Почему «он отвечает, но принимает ли он решения?»

Вывод модели — это распределение токенов, схлопнувшееся в одну последовательность, и один и тот же промпт, запущенный дважды, может произвести две последовательности, расходящиеся ровно на том токене, который имеет значение. Решение, напротив, является детерминированным для фиксированного входа, удовлетворяет явным инвариантам и оставляет след аудита, фиксирующий, какая ветвь была выбрана и почему.

Когда модель «принимает решение» без механизмов вокруг неё, ни одно из этих свойств не существует. Нет инварианта, которому вывод обязан соответствовать, нет лога выбранной ветви, нет способа воспроизвести решение и проверить, сохранялось ли оно. Разрыв не в интеллекте — он в том, что вероятностный вывод помещен в слот, спроектированный для детерминированного.

Практический инстинкт — полностью исключить модель из процесса принятия решений:

«LLM никогда не принимает окончательных решений в системе. Его роль чисто такова: уточнение логики, стресс-тестирование, генерация сценариев, объяснение.» — r/AI_Agents, «Использование LLM в качестве «агента рассуждений» для валидации цен…»

Это правильная позиция, выраженная как максима. Чтобы применить её, вам нужен способ классифицировать, какую роль модель должна играть для данного действия — именно это обеспечивает таксономия ниже.

Пять ролей принятия решений

Любое решение, принимаемое системой, можно присвоить одной из пяти ролей. Роль определяет, насколько можно доверять выводу модели, как он аудируется, как он терпит неудачу и должен ли человек быть в цикле.

Читайте таблицу как ограничение, а не как меню. Большинство сломанных систем имеют один общий дефект: одна модель выполняет все пять ролей одновременно, поэтому роль, требующая детерминизма (принимающий решение), обслуживается компонентом, оптимизированным для плавности речи (генератор). Там, где модель действует как генератор, механизмы принятия решений не нужны — нужна рецензия контента. Ошибку, которую нужно избежать, — это смешение этих ролей: «агент решил удалить окружение» обычно является отсутствием шлюза утверждения, а не проблемой качества решения.

Маршрутизируйте решение к наименьшей компетентной модели

Однако роль зафиксирована, вопрос маршрутизации заключается в том, какой уровень модели её обслуживает. Практики напрямую сообщают о выгоде:

«Маршрутизация моделей: Haiku для решений о классификации/маршрутизации, Sonnet для исполнения, Opus только для дизайна/планирования. Стоимость упала примерно на 60%, когда я перестал использовать Opus для всего.» — r/AI_Agents, «Каков ваш полный стек ИИ-агента в 2026 году»

Эта цифра исходит из того, что выбор модели рассматривается как решение на роль, а не на систему. Вызов маршрутизации — «это триаж email или утверждение возврата средств?» — это классификация, и для классификации не нужна фронтир-модель; ей нужна маленькая, быстрая, модель с низкой температурой, потому что она выполняется тысячи раз. Механика уровней — выбор на основе возможностей, осознание затрат и осознание задержек, плюс цепочки отката — описаны в Маршрутизация моделей: Перестаньте использовать одну модель для всего; паттерны оркестрации вокруг нескольких моделей — в Проектирование мульти-модельных систем.

Дополнение, которое вносит рамка принятия решений, — это эскалация на основе уверенности, что делает «наименьшую компетентную» измеряемой, а не предполагаемой. Начните с наименьшего уровня. Если модель выпускает калиброванную уверенность — или структурированную самооценку — и она превышает порог, остановитесь. Если нет, эскалируйте на один уровень и запишите эскалацию. Компетентность становится свойством, проверяемым при каждом вызове, а не свойством, предполагаемым для каждой модели.

Одно ограничение остается абсолютным независимо от уровня: сама роль маршрутизатора не должна быть свободным вызовом языковой модели. Детерминированный каркас — правила по типу задачи, размеру полезной нагрузки, бюджету затрат — выбирает ветвь, и модель заполняет только листовые решения внутри неё. Каркас аудируем и тестируем на юнит-уровне; модель ограничена тем, в чем она действительно хороша.

Делаем решение верифицируемым

Именно здесь закрывается разрыв «агент утверждает, что сделал X». Решение состоит в том, чтобы сделать решение первоклассным структурированным артефактом, а не побочным эффектом диалогового хода:

1. Структурированное хранилище решений. Каждое решение, которое модели разрешено принимать, записывается в таблицу, а не в строку лога: вход, роль, модель и уровень, уверенность, рассмотренные альтернативы, временная метка. Решение — это то, что можно SELECT позже. Если оно живет только в транскрипте разговора, это догадка.
2. Лог решений, отдельный от лога исполнения. Лог исполнения говорит, что произошло; лог решений говорит, что было решено и на каком основании. Разделение важно, потому что отказ обычно в решении, а не в исполнении — агент идеально выполнил удаление; багом было решение об удалении. Механика структурированного логирования с режимом только добавления (append-only) та же, что используется для следов аудита в LLM Guardrails in Practice.
3. Инварианты и утверждения (assertions). Для ролей «принимающий решение» и «оценщик» решение должно удовлетворять инвариантам, проверяемым после того, как модель его выпустила, в детерминированном коде. Рекомендатель цен может выдать что угодно; инвариант «рекомендованная цена должна быть в пределах [нижняя граница, верхняя граница]» принудительно выполняется кодом. Модель предлагает; инвариант распоряжается.
4. Шлюзы человеческого утверждения на границе необратимости. Шлюз является свойством радиуса поражения действия, а не уверенности модели. Возврат средств ниже порога может быть одобрен автоматически; выше него — нет. Модель с уверенностью 99% по-прежнему не может одобрить необратимое действие, для которого у неё нет записи аудита.

Пронизывающая линия: проталкивание точности с 92% на 96% — это не узкое место — объяснимость. Система на 92% с каждым записанным решением, проверенным инвариантами и заблокированным на границе безопасно выходит в продакшн, потому что 8% неверных решений находятся до того, как они нанесут ущерб. Система на 99% с процессом принятия решений в «черном ящике» так не работает, потому что эти 1% — это живой инцидент без следов для форензики. Где именно находится сам шлюз в ассистенте — какой компонент держит власть утверждения и как запросы доходят до него — расписано в Архитектура ИИ-ассистента: LLM, Память, Инструменты, Маршрутизация, Наблюдаемость.

Практические примеры

Три системы, по одной роли в каждой.

Валидация цен — модель как рекомендующий, никогда не как принимающий решение. Агент проверяет изменение цены поставщика и производит ранжированный список: принять, negociar по цене X, отклонить. Финальный звонок — это слот «принимающего решения», заполненный детерминированными правилами: ниже нижней границы стоимости — авто-принятие; выше верхней границы — маршрутизация к человеку; в промежутке — применение инварианта «переговорная цена должна превзойти последнюю принятую на Y%». Модель никогда не утверждает свою собственную рекомендацию, и рекомендация сидит в хранилище решений со следом критериев оценки, если она пошла не так.

Маршрутизация задач агента — каркас как принимающий решение, модель на листьях. Входящий запрос (email, тикет, команда) присваивается путем по форме полезной нагрузки и категории намерения — детерминированно, тестируемо на юнит-уровне. Малая модель заполняет только листовое решение внутри ветви. Неверная маршрутизация — это событие с радиусом поражения, и именно поэтому выбор ветви должен быть детерминированным.

LLM как судья — модель как оценщик, критерии оценки как ограничение. Одна модель оценивает вывод другой по версионируемым критериям оценки, и балл плюс след критериев сохраняются, а не просто число. Известный режим отказа — предвзятость самопредпочтения — модель оценивает собственный стиль генерации выше — и смягчение структурно: версионируйте критерии оценки, чтобы модель никогда не оценивала себя незаметно по критериям, которые она сама сформировала.

Честная граница

Существует класс решений, которые LLM не должна принимать, и это не вопрос масштаба: действия, которые необратимы, высокорисковы и не имеют отката — удаление данных, движение средств, внешние обязательства. Верификация невозможна для действия, которое нельзя откатить, и именно поэтому «автономный агент» продолжает упираться в одну и ту же стену независимо от качества модели.

Человек в цикле, который не является театральным, сидит ровно на этой границе и нигде больше. Человек, рецензирующий каждое низкорисковое решение, добавляет трение и никакой безопасности; человек, отсутствующий при каждом высокорисковом решении, — это инцидент. Тот же принцип появляется в более узкой форме в памяти агента: самоусиливающиеся циклы памяти блокируют кандидаты на запись в памяти за явным человеческим утверждением, прежде чем что-либо достигнет постоянного состояния — шлюз размерен под то, что запись может сломать. Для мульти-агентных систем соответствующий вопрос — кто может действовать от чьего имени, и механизмы идентичности, делегирования и следов аудита для этого — в A2A и MCP Безопасность агентов.

Критерии оценки решения

Примените это к любому действию в вашей системе:

1. Классифицируйте роль. Принимающий решение, рекомендующий, оценщик, генератор или маршрутизатор? Не названная роль — это баг — модель в слоте «принимающего решения», носимом с уверенностью генератора.
2. Выберите уровень для этой роли. Наименьший компетентный, с эскалацией на основе уверенности, чтобы компетентность измерялась при каждом вызове.
3. Определите верификацию. Какие инварианты должны выполняться? Что попадает в хранилище решений? Каков след аудита? Роль без пути верификации — это принимающий решение по умолчанию.
4. Установите человеческий шлюз из радиуса поражения, а не из уверенности. Необратимое или высокорисковое → заблокировано. Иначе → автоматически, с записью решения, чтобы оно было найдено.

Та же дисциплина, примененная к инженерным выборам, а не к действиям времени выполнения, — это то, что делают записи решений — Записи решений для ИИ-управляемого развития фиксирует, почему выбор был сделан, чтобы его можно было пересмотреть позже; критерии оценки выше делают то же самое для решений, которые принимает работающая система.

Что впереди: принимающий решение как продукт

Рамка предсказывает свою собственную коммодитизацию: как только «маршрутизируйте решение к наименьшей компетентной модели» стало паттерном, следующим шагом был класс моделей, который делает ничего, кроме как принимает решения. Этот шаг теперь состоялся.

В октябре 2026 года несколько вендоров выпустили модели, построенные на общем рецепте — замороженный каркас Qwen, адаптер LoRA с рангом 256 и общий заголовок схемы — которые выпускают типизированные решения за один прямой проход: выбор из перечисленного набора, да/нет или балл, с калиброванными вероятностями и без свободного текста. Нет цепи размышлений, которой нужно ждать, потому что нет генерации. Задержки, заявленные вендорами, составляют от примерно 8 до 210 мс в пределах класса — от самого малого варианта (d1-3B, около 8 мс) до самого большого (d3, около 209 мс) — и следы малы: d1-3B около 1.67 ГБ, d3-flash около 6.6 ГБ при Q4_K_M. Поддержка также быстро двигалась: llama.cpp объединила поддержку нативной архитектуры для нескольких из этих моделей в течение примерно двух недель после релиза.

Два последствия для описанной выше рамки. Во-первых, правило маршрутизации получает аппаратное выражение, которого у него не было раньше: роль «принимающего решения» может обслуживаться выделенной малой моделью, а не режимом промпта общей модели, что делает решение о наименьшем компетентном уровне частично автоматическим — уровень либо существует для вашего типа решений, либо нет. Во-вторых, ничего в части верификации не меняется. Типизированное решение за 8 мс все еще нуждается в хранилище решений, инвариантах и шлюзе на границе необратимости; то, что класс моделей устраняет, — это стоимость генерации и недетерминизм, а не бремя аудита. Быстрые решения умножают количество записей решений, которые нужно аудитировать — узким местом никогда не была скорость модели, и не является ею и интеллект модели.

Другие направления, за которыми стоит наблюдать, quieter. Надежность вызова инструментов для малых моделей приближается к насыщению — пост-обучение на использовании инструментов — самый дешевый шаг с высоким воздействием в стеке, что смещает внимание на строки выше. Надежные горизонты планирования продолжают расширяться, что делает роль «принимающего решения» достижимой для более длинных задач и растет бременем верификации с горизонтом. Оба подводят к одному и тому же выводу: дефицитным ресурсом в агентных системах являются решения, которые можно впоследствии доказать как обоснованные, и все остальное догоняет это.