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

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

Представьте себе систему поддержки клиентов, которая получает следующее сообщение:

"С моей подписки списали деньги дважды. Мне нужен возврат средств сегодня."

Система должна определить, какая команда должна обработать этот запрос, насколько он срочен и запрашивает ли клиент возврат средств.

Мы могли бы попросить LLM вернуть объект JSON, содержащий эти ответы.

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

В этом заключается ключевая идея моделей принятия решений.

Что такое модели принятия решений?

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

TypeSafe AI представила Jev, описав ее как модель Первой системы. Это название навещено разграничением между быстрым, интуитивным мышлением (Система 1) и более медленным, обдуманным мышлением (Система 2).

Сообщество сошлось на термине «модель принятия решений», поскольку он описывает вычислительную роль модели, а не отсылает к конкретной теории познания. В оставшейся части статьи мы будем называть эти модели «моделями принятия решений», а не «моделями первой системы». (Опрос в твиттере о том, как нам следует называть такие модели)

Сообщество сошлось на термине «модель принятия решений», поскольку он описывает вычислительную роль модели, а не отсылает к конкретной теории познания. В оставшейся части статьи мы будем называть эти модели «моделями принятия решений», а не «моделями первой системы». (Опрос в твиттере о том, как нам следует называть такие модели)

Для модели принятия решений основным интерфейсом является:

Почему бы не использовать LLM для всего?

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

Тем не менее, с этим подходом связано несколько проблем.

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

Чем модели принятия решений отличаются от моделей классификации?

Прежде чем понять интерфейс модели принятия решений, полезно вспомнить два тесно связанных подхода: традиционную классификацию и классификацию в условиях нулевого обучения (zero-shot).

Традиционная классификация

Предположим, мы обучаем классификатор, который направляет запросы техподдержки в три отдела:

• Биллинг
• Техническая поддержка
• Продажи

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

Ограничение здесь заключается в том, что выходные классы зашиты в голову классификации модели.

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

Классификация в условиях нулевого обучения (Zero-shot)

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

Например:

В отличие от обычного классификатора с фиксированными метками, категории могут меняться от одного запроса к другому. Давайте добавим другой отдел, например «Юридический», и посмотрим на выводы модели.

Одна из распространенных реализаций использует модель, обученную для задачи естественного языкового вывода (NLI). Каждая кандидатная метка преобразуется в гипотезу, и модель измеряет, насколько сильно входные данные подтверждают эту гипотезу.

Это уже звучит очень похоже на модель принятия решений. Во многом так оно и есть.

В чем отличия моделей принятия решений

Модели принятия решений расширяют эту идею за пределы простого отнесения входных данных к категории. Модель принятия решений может принимать несколько именованных вопросов об одном и том же состоянии с разными типами ответов. Типы могут представлять собой выбор между альтернативами (выбор), оценку по упорядоченной шкале (оценка) или оценку вероятности того, что утверждение истинно (noul).

Что еще более важно, ее интерфейс построен вокруг распределения вероятностей возможных решений.

Рассмотрим эти три подхода:

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

Интерфейс модели принятия решений

Запрос к модели принятия решений состоит из следующих двух компонентов:

• состояние (state)
• вопросы (questions)

Состояние

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

Например:

Вопросы и их примитивы

Вопросы описывают то, что мы хотим узнать о состоянии. В интерфейсе моделей принятия решений три фундаментальных примитива представляют различные формы решений:

• Выбор (Choice): Выбор одного из нескольких возможных ответов.
• Оценка (Score): Оценка чего-либо по упорядоченной шкале.
• Noul: Вероятностный ответ на вопрос «да/нет».

Давайте разберем их по очереди.

Выбор: Распределение вероятностей по вариантам

Выбор — самый интуитивный примитив, наиболее близкий к традиционной классификации.

Предположим, мы спрашиваем:

Какой отдел должен обработать этот запрос клиента?

Какой отдел должен обработать этот запрос клиента?

Доступные варианты: Биллинг, Техническая поддержка и Продажи.

Модель присваивает логит каждому варианту. Для логитов ($z_1,\ldots,z_K$) (с K классами) мы можем получить вероятности с помощью функции softmax:

pi=exp⁡(zi/T)∑j=1Kexp⁡(zj) p_i=\frac{\exp(z_i/T)}{\sum_{j=1}^{K}\exp(z_j)}

Здесь (K) — количество вариантов выбора.

Рассмотрим это иллюстративное распределение:

Вероятности в сумме дают единицу:

∑i=1Kpi=1. \sum_{i=1}^{K}p_i=1.

Модель выбирает вариант с наибольшей вероятностью:

y^=arg⁡max⁡ipi \hat y=\arg\max_i p_i

В данном случае выбор — Billing (Выставление счетов) с вероятностью 0,998, однако остальные вероятности также полезны. Они показывают, как модель распределяет свою уверенность между альтернативами.

Score (Оценка): математическое ожидание упорядоченного распределения

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

Рассмотрим вопрос:

Насколько срочен этот запрос клиента?

Насколько срочен этот запрос клиента?

Мы определяем три уровня:

• 0: Низкая срочность
• 1: Средняя срочность
• 2: Высокая срочность

Модель снова выдает распределение вероятностей:

Вместо возврата только наиболее вероятного уровня примитив Score вычисляет математическое ожидание индекса уровня.

Для случайной величины (X), представляющей уровень, математическое ожидание равно:

E[X]=∑i=0K−1ipi \mathbb{E}[X]=\sum_{i=0}^{K-1}ip_i

Для нашего примера:

E[X]=0(0.10)+1(0.26)+2(0.72)=1.7 \mathbb{E}[X] = 0(0.10)+1(0.26)+2(0.72)=1.7

Таким образом, полученная оценка составляет 1,7.

Это не означает, что модель выбрала вымышленный уровень посередине между средним и высоким. Это означает, что математическое ожидание ее распределения вероятностей равно 1,7.

Noul: бинарное решение

Третий примитив — Noul, который представляет собой бинарный вопрос.

Например:

Запрашивает ли клиент возврат средств?

Запрашивает ли клиент возврат средств?

Вместо задания списка вариантов мы просим модель вернуть вероятность того, что ответ верен. Мы можем понять это с помощью распределения Бернулли (название noul происходит от имени Бернулли).

Пусть (Y) представляет собой бинарный результат:

Y∼Bernoulli⁡(p) Y\sim\operatorname{Bernoulli}(p)

где

P(Y=1)=p,P(Y=0)=1−p. P(Y=1)=p,\qquad P(Y=0)=1-p.

Если модель возвращает:

она присваивает вероятность 0,92 варианту «Да» и 0,08 варианту «Нет».

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

Confidence (Уверенность): насколько модель уверена?

До сих пор мы получали от модели распределения вероятностей. Но интерфейс моделей принятия решений также возвращает поле под названием confidence (уверенность) для Choice и Score.

Полное распределение может содержать несколько возможных ответов, и бывает полезно обобщить степень сосредоточенности уверенности модели. Именно это и позволяет сделать confidence.

Для Choice с (K) вариантами уверенность рассчитывается так:

pmax⁡−1K1−1K \frac{p_{\max}-\frac{1}{K}}{1-\frac{1}{K}}

где ($p_{\max}$) — наибольшая предсказанная вероятность.

Интуитивное понимание здесь следующее:

• Равномерное распределение имеет уверенность 0. ($p_{\max} = \frac{1}{K}$). Это означает, что модель оценивает все варианты как равновероятные.
• Распределение, полностью сосредоточенное на одном варианте, имеет уверенность 1. ($p_{\max} = 1$)
• Чем больше побеждающая вероятность по сравнению с равномерным распределением, тем выше уверенность.

В нашем предыдущем примере с тремя вариантами выбор Billing имел вероятность 0,80:

C=3(0.99)−12=0.98 C=\frac{3(0.99)-1}{2}=0.98

Обратите внимание, что побеждающая вероятность составляет 0,99, но указанная уверенность равна 0,98. Уверенность нормализует наибольшую вероятность относительно количества доступных вариантов. Напротив, в упорядоченном примере Score уверенность составляла всего 0,558.

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

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

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

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

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

1. Инференс с помощью Transformers

Библиотека Transformers теперь поддерживает классы DecisionPipeline, AutoModelForDecision и DecisionConfig. Они следуют той же общей структуре классов pipeline и model в transformers, но специально созданы для моделей принятия решений.

Конфигурацию и модель также можно изучить следующим образом:

Transformers также поддерживает эндпоинт /v1/systemone.

Мы можем запустить локальный сервер, используя зависимости для инференса:

Используя совместимую версию Transformers, мы можем отправить запрос на принятие решения:

Ответ содержит три именованных ответа с соответствующими типизированными результатами и вероятностями.

Интересная деталь заключается в том, что вышеописанные API работают и с совместимыми авторегрессионными языковыми моделями. Transformers формирует промфты для принятия решений, вычисляет логарифмы ответов (logits) за один пакетный проход (forward pass) и применяет softmax без генерации текста ответа. Это означает, что мы можем экспериментировать с интерфейсом принятия решений без обязательного обучения новой модели.

Интересная деталь заключается в том, что вышеописанные API работают и с совместимыми авторегрессионными языковыми моделями. Transformers формирует промфты для принятия решений, вычисляет логарифмы ответов (logits) за один пакетный проход (forward pass) и применяет softmax без генерации текста ответа. Это означает, что мы можем экспериментировать с интерфейсом принятия решений без обязательного обучения новой модели.

2. Инференс с помощью llama.cpp

Llama.cpp также поддерживает модели принятия решений, используя тот же API /v1/systemone.

Например, мы можем запустить модель принятия решений GGUF из Hub:

Сервер по умолчанию запускается на порту 9931.

Затем мы можем отправить запрос, содержащий те же состояние и вопросы, используя http://localhost:9931/v1/systemone. Поскольку модель выбрана сервером, мы можем опустить поле model в запросе.

Полезным свойством здесь является совместимость интерфейсов.

3. Обнаружение моделей в Hugging Face Hub

В Hugging Face добавлен специальный тег decision-model для поиска совместимых моделей. Это полезно, поскольку модели принятия решений не обязаны иметь единую базовую архитектуру.

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

4. Обучение моделей принятия решений с помощью инструментов Hugging Face

Как только мы разобрались с инференсом, возникает следующий вопрос: можем ли мы адаптировать модель принятия решений? Поскольку модели принятия решений интегрированы в transformers, мы можем дообучать (fine-tune) их с помощью API Trainer.

Ниже приведен демонстрационный пример дообучения JEV-9B для маршрутизации запросов в службу поддержки. Он намеренно прост, но демонстрирует ключевые элементы:

• каждый пример представляет собой запрос на принятие решений (состояние плюс вопросы), сопряженный с эталонным (gold) ответом.
• model.decision_config.prepare_inputs превращает запрос во входные данные модели точно так же, как это делается во время инференса.
• модель возвращает один логит на каждый вариант, поэтому вопрос типа выбор (choice) обучается с использованием стандартной функции потерь перекрестной энтропии (cross-entropy loss) по всем вариантам.

Первоклассная поддержка обучения моделей принятия решений также появится в TRL (huggingface/trl#8040), так что нам не придется писать эту связующую логику вручную. На момент написания статьи pull-request все еще открыт.

Если мы хотим пойти дальше и превратить генеративную LLM в модель принятия решений, Unsloth предлагает рецепты для тонкой настройки таких моделей, как Qwen, с помощью LoRA и головы оценки решений.

Заключительные мысли

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

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