Модели для принятия решений появились в Hugging Face

Решение вместо текстового ответа

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

Обычный вариант — попросить языковую модель сформировать JSON с ответами. В примере с llama cli и моделью ggml-org/gemma-4-e4b-it-GGUF:Q4_0 модель выбирает отдел Billing, присваивает обращению высокую срочность и отмечает, что клиент просит возврат.

Hugging Face предлагает другой подход: модель напрямую оценивает заданные ответы и возвращает распределение вероятностей, не генерируя текст. В примере с autotrust/GEV-26B-Decide вероятность отнести обращение к оплатам и возвратам составляет около 0,998, а итоговая уверенность — около 0,997.

Источник: huggingface.co

Как устроены модели для принятия решений

Запрос состоит из контекста — состояния — и одного или нескольких вопросов с допустимыми типами ответа. Модель возвращает структурированные решения и вероятности. В основе подхода — интерфейс: состояние, вопросы и возможные ответы на входе; решения и вероятности на выходе.

TypeSafe AI представила Jev как модель системы 1 — по аналогии с быстрым, интуитивным мышлением, противопоставляемым более медленному и вдумчивому мышлению системы 2. Однако в сообществе закрепился термин «модель для принятия решений»: он описывает вычислительную роль модели, а не связывает её с конкретной теорией мышления.

Обычную языковую модель можно попросить вернуть JSON, но она не всегда соблюдает схему: может выдать некорректный JSON, добавить неожиданные поля или выбрать ответ за пределами разрешённых вариантов. Библиотеки Outlines и XGrammar ограничивают генерацию допустимыми токенами и помогают соблюдать заданную структуру, но требуют дополнительных вычислений. Если приложению нужно только выбрать один из вариантов, генерация целого ответа может быть лишней.

Чем подход отличается от классификации

В традиционной классификации модель обучают выбирать из заранее определённого набора меток. Например, обращения можно распределять между Billing, Technical support и Sales. Обычно классификационная часть модели выдаёт по одному значению для каждого класса, а функция softmax преобразует их в вероятности.

Список классов закреплён в классификационной части модели. Если добавить отдел Legal, существующая модель не получит новый класс автоматически: может потребоваться изменить эту часть, собрать данные и дообучить или адаптировать модель.

Классификация с нулевым примером позволяет передавать категории при каждом запросе. В примере с facebook/bart-large-mnli текст «My payment was deducted twice» сравнивается с метками billing, technical support и sales. Их оценки составляют соответственно 0,847, 0,096 и 0,057. Если добавить legal, модель пересчитает распределение: оценки составят 0,819, 0,093, 0,055 и 0,033. Один из распространённых способов реализации использует модель, обученную на задаче вывода на естественном языке: каждая метка становится гипотезой, а модель оценивает, насколько исходный текст её подтверждает.

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

Три типа вопросов

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

Для вопросов предусмотрены три типа ответа:

В примере с Choice модель выбирает отдел Billing из трёх вариантов — Billing, Technical support и Sales — и возвращает вероятности для каждого. Для значений модели вычисляют вероятности с помощью softmax; их сумма равна единице, а итоговым выбором становится вариант с наибольшей вероятностью. Остальные оценки тоже полезны: они показывают, как модель распределяет уверенность между альтернативами.

Score подходит для оценки по шкале. Для срочности обращения можно задать уровни 0 — низкая, 1 — средняя и 2 — высокая. В примере вероятности этих уровней равны примерно 0,015, 0,265 и 0,720. Вместо выбора наиболее вероятного уровня модель возвращает математическое ожидание индекса — около 1,7. Это не отдельный уровень «между средним и высоким», а сводное значение распределения вероятностей.

Noul отвечает на вопрос, который можно выразить как «да» или «нет». Для вопроса, просит ли клиент возврат, модель возвращает вероятность ответа «да» около 0,995. Если результат равен 0,92, это означает вероятность 0,92 для «да» и 0,08 для «нет». Модель возвращает саму вероятность, а приложение решает, как на неё реагировать.

Как рассчитывается уверенность

Для ответов Choice и Score интерфейс также возвращает поле confidence. Оно помогает оценить, насколько распределение сосредоточено вокруг одного ответа. Для Choice уверенность рассчитывается по максимальной вероятности и числу доступных вариантов.

Если вероятности всех вариантов одинаковы, уверенность равна нулю. Если вся вероятность приходится на один вариант, она равна единице. Чем выше вероятность лидирующего ответа по сравнению с равномерным распределением, тем выше показатель.

В примере с тремя вариантами при вероятности лидирующего ответа 0,99 уверенность составляет 0,98: показатель учитывает число доступных ответов. В приведённом примере Score уверенность ниже — 0,558.

Поддержка в экосистеме Hugging Face

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

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

Transformers

Transformers поддерживает DecisionPipeline, AutoModelForDecision и DecisionConfig. Они устроены по общему принципу с другими конвейерами и классами моделей в библиотеке, но предназначены для моделей решений. Например, загрузив autotrust/GEV-26B-Decide, можно увидеть, что модель JevForDecision работает с типом данных bfloat16 на cuda и принимает текстовый ввод.

Параметры модели и саму модель можно загрузить через DecisionConfig.from_pretrained и AutoModelForDecision.from_pretrained. Transformers также поддерживает конечную точку /v1/systemone. Для локального сервера нужно установить зависимости командой pip install "transformers[serving]", а затем запустить transformers serve.

Запрос к локальному серверу на http://localhost:8000/v1/systemone может включать сразу три вопроса: отдел, срочность и запрос на возврат. В опубликованном ответе отделом становятся Billing с вероятностью около 0,998; оценка срочности составляет около 1,75, а вероятность того, что клиент просит возврат, — около 0,995. В ответе указаны 148 входных токенов и ноль выходных.

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

llama.cpp

llama.cpp поддерживает тот же API /v1/systemone. Модель для принятия решений в формате GGUF можно запустить командой llama serve -hf ggml-org/Kev-4B-GGUF. Затем запрос с теми же состоянием и вопросами отправляется на http://localhost:9931/v1/systemone. Если модель уже выбрана сервером, поле model можно не передавать.

Поиск моделей на Hub

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

Обучение моделей решений

Модели можно дообучать через API Trainer в Transformers. В учебном примере JEV-9B обучают распределять обращения по трём категориям: возвраты, доставка и технические проблемы. Для этого:

В примере используются шесть обращений: о двойном списании и возврате денег, недоставленной посылке, сбое приложения, возврате денег, местонахождении доставки и невозможности войти в аккаунт. Они распределяются между вариантами «проблемы с оплатой и возвраты», «заказы и доставка» и «проблемы с программами и учётными записями». Обучение настроено на 30 шагов, размер пакета на устройстве — 1, скорость обучения — 0,001, журналирование включается каждые пять шагов; сохранение модели и отправка отчётов отключены.

Поддержка обучения моделей решений непосредственно в TRL тоже готовится. На момент публикации соответствующий запрос на изменение huggingface/trl#8040 оставался открытым. Для преобразования генеративной языковой модели в модель решений Unsloth предлагает рецепт дообучения таких моделей, как Qwen, с LoRA и специальной оценочной частью.

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