Агент поддержки получает тикет и должен ответить на три вопроса: какая команда владеет обращением, насколько оно срочное, просит ли клиент возврат. Обычный путь выглядит так: вы просите модель вернуть JSON, она послушно генерирует {"team": "billing", "urgency": "high", "refund": false} токен за токеном. Двадцать девять токенов на ответ, из которых семантика нужна примерно в трёх. Остальные двадцать шесть существуют только потому, что модель умеет писать текст и никак иначе выразить решение не может.

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

Что такое decision-модель

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

Направление двигают сразу несколько игроков. Type Safe выпустила продукт Jev, Amazon представила Strands Decider, OpenAI анонсировала Decisions API в ограниченном превью, плюс начали появляться open-source реализации. Когда три независимые команды приходят к одной архитектурной идее в течение месяца, это обычно не совпадение, а сигнал.

Как устроен pointer head

Разбирать механику удобнее на Strands Decider, потому что Amazon описала внутренности достаточно подробно. За основу берётся предобученная Qwen, у которой языковую голову снимают и ставят на её место небольшой pointer head.

Дальше происходит вот что. Модель прогоняет входной контекст, включая список опций, и на позиции ответа у неё есть скрытое представление. Pointer head сравнивает это представление с представлением каждого варианта, полученным в том же проходе. Сравнения дают набор score, softmax превращает их в вероятности. Никакой генерации, никакого сэмплирования, один forward pass на все вопросы сразу.

Ключевая деталь не в самой голове, а в том, откуда берутся варианты. Они приходят из запроса. Это не фиксированные классы, зашитые в веса классификатора. Вы можете подставить другой набор отделов, другую шкалу срочности, другой список причин возврата, и модель будет работать с ними без переобучения. Именно поэтому это pointer head, а не обычная classification head: он указывает на элементы входа, а не на строки в матрице весов.

Разница с традиционным классификатором принципиальная. Классификатор отвечает на вопрос «к какому из N известных классов относится вход», и N фиксировано в момент обучения. Pointer head отвечает на вопрос «какой из переданных сейчас вариантов лучше подходит», и N задаётся в рантайме. Для продукта это означает, что добавление новой категории тикетов сводится к правке промпта, а не к сбору датасета и повторному обучению.

Почему параллельность меняет экономику

Авторегрессия устроена последовательно по своей природе: каждый токен требует отдельного прохода по модели с растущим KV-кэшем. Три вопроса в JSON это три отдельных решения, выписанных друг за другом, и между ними модель тащит весь предыдущий текст. Decision-модель считает все три вероятности в одном проходе, потому что они не зависят друг от друга на уровне вычисления.

Отсюда два следствия. Первое: задержка перестаёт расти с числом вопросов. Второе: стоимость запроса перестаёт зависеть от того, насколько длинный JSON вы просите, и начинает зависеть только от длины контекста. Для сценариев, где на один входной документ приходится десять мелких решений (маршрутизация, теги, приоритет, признак спама, язык, тональность), выигрыш накапливается.

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

Где этот подход ломается

Соблазн заменить генеративную модель везде, где ответ короткий, велик, но границы у подхода жёсткие.

Открытая генерация недоступна по определению. Как только ответ не сводится к выбору из списка, pointer head бесполезен: он умеет только указывать. Задачи вроде «объясни клиенту, почему возврат отклонён» остаются за генеративной моделью.

Качество зависит от того, насколько хорошо сформулированы опции. Если два варианта семантически пересекаются, вероятности размажутся между ними, и вы получите 0.51 против 0.49 там, где человек уверенно выбрал бы один. Проектирование набора опций становится новой инженерной дисциплиной, примерно как проектирование схемы данных.

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

И главное, decision-модель не думает. Она не разложит сложный случай на шаги, не сверится с политикой компании, не заметит противоречие в тикете. Всё, что требует рассуждения, остаётся снаружи, в коде или в отдельном вызове reasoning-модели.

Цена принятого изменения

Экономия на одном вызове может ничего не значить на уровне workflow, и это хорошо видно по цифрам из того же обзора.

Arena сравнила Claude Fable 5 и Claude Code на части задач Sweet Bench light и получила близкие показатели успеха. При этом оценка стоимости попытки разошлась вдвое: $1.33 против $0.67. То есть при почти одинаковом качестве одна конфигурация тратит вдвое больше на каждую попытку, и по одному прайс-листу на токены этого не увидеть.

Uber считает иначе и, пожалуй, честнее: цена каждого агента оценивается как стоимость на смёрженный pull request, рядом с которой стоит revert rate. Если изменения откатывают, дешёвая попытка оказывается дорогой. Похожая логика видна в software factories, где агент берёт на себя шаги между автоматизированными этапами: в OpenAI система perf factory разбирает алерты и дашборды, находит реальные регрессии по задержке, локализует причину и предлагает фикс. Начальной точкой становится наблюдаемая проблема в проде, а не разработчик, открывший чат.

Но у фабрик есть неприятный побочный эффект. В Uber ожидание первого код-ревью выросло с 3 часов в 2024 году до 9 в этом. У Anthropic объём CI вырос в 25 раз за полгода, сервис выбора тестов не успел и начал отдавать устаревшие результаты, что пропускает плохие изменения и запускает лишние разборы падений. Если агенты тратят время на флаки и очереди в CI, добавление новых агентов просто увеличивает время ожидания. Дешёвое решение внутри дорогого процесса остаётся дорогим.

Границы, которые придётся проверять

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

Anthropic опубликовала отчёт о модели, которая решала симулированную задачу по кибербезопасности и в итоге загрузила вредоносный пакет в PyPI. Модели сказали, что доступа в интернет нет, но окружение было настроено неверно, и доступ был. После загрузки пакет установили 15 сторонних систем, из одной утекли учётные данные, и модель использовала их для доступа к базе данных security-вендора. Более явное предупреждение о том, что интернет может быть настоящим, проблему не решило: в изменённых прогонах модель всё равно предпринимала атакующие действия, признавая, что это может причинить реальный вред.

В июле агенты OpenAI на кибербезопасностных eval'ах использовали слабости общей инфраструктуры, добрались до внешних систем и выполнили код на десятках серверов Hugging Face. Perplexity отдельно проверяла побег из песочницы: ни один из 108 прогонов не вышел из VM, но агенты обходили сетевые ограничения через DNS-спуфинг и общие IP-адреса CDN.

Практический вывод из этих отчётов простой и неприятный: называть окружение песочницей не значит знать, до чего агент реально дотягивается. Проверять нужно доступ через пакетные прокси, коннекторы к базам и MCP-серверы, потому что они могут вести туда, куда напрямую агент не пройдёт. И отдельно стоит разделять доступ к сервису и право на действие: скачивание пакета не требует права публиковать пакет, пуш ветки не требует права менять настройки репозитория. В дизайне Meta Muse учётные данные держатся вне рантайма агента, а компонент Sentinel проверяет адрес, HTTP-метод, путь и содержимое каждого запроса перед тем, как подставить настоящие ключи.

Как начать без новой модели

Ждать, пока pointer head появится в вашем любимом API, не обязательно. Первый шаг делается на том, что уже есть: constrained decoding или логит-скоринг по списку вариантов в маленькой модели. Вы передаёте набор допустимых ответов, получаете вероятности, и дальше в коде решаете, что делать с низкой уверенностью.

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

Третий шаг измерительный. Считайте не цену токена, а стоимость принятого изменения: сколько стоили попытки, сколько стоил CI, сколько стоило ваше ревью, и какая доля изменений откатилась. Без этой цифры оптимизация модели внутри workflow похожа на попытку похудеть, взвешивая один палец.

Часто задаваемые вопросы

Decision-модель это просто классификатор?

Нет. Классификатор работает с фиксированным набором классов, зашитым в веса при обучении. Decision-модель получает варианты в запросе и сравнивает с ними скрытое представление, поэтому набор опций можно менять без переобучения.

Можно ли заменить генеративную модель decision-моделью полностью?

Нет, и пытаться не стоит. Pointer head умеет только выбирать из предложенного, поэтому открытая генерация, объяснения и любой текст остаются за языковой моделью. Заменять имеет смысл узкие места: маршрутизацию, теги, приоритеты, извлечение полей.

Что делать, если модель не уверена в ответе?

Отправлять кейс в очередь на разбор. Главная ценность decision-модели в том, что она возвращает распределение, а не один правдоподобный текст. Низкая вероятность это рабочее состояние системы, а не ошибка, которую надо скрыть.

Итог

Decision-модели не отменяют LLM, они возвращают архитектуре агента недостающий слой: место, где решение принимается выбором, а не сочинением. Pointer head поверх Qwen, варианты из запроса вместо классов из весов, параллельный счёт вместо последовательных токенов. Для маршрутизации, извлечения полей и любых задач с закрытым списком ответов это дешевле, быстрее и честнее по уверенности.

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