A Hugging Face publicou um post que descreve os modelos de decisão e as ferramentas que ela adicionou em torno deles. A ideia é ter uma interface comum que qualquer modelo desse tipo possa implementar, seja qual for a arquitetura por baixo.
O que um modelo de decisão faz
Um modelo de decisão recebe um estado, que pode ser uma string ou um objeto JSON estruturado. Também recebe uma ou mais perguntas nomeadas, cada uma com um conjunto fixo de respostas permitidas. Ele devolve uma decisão tipada com as probabilidades e não gera texto no processo. A resposta de exemplo do post mostra zero tokens de saída.
São três tipos de pergunta:
- Choice escolhe uma opção, como qual equipe deve cuidar de um ticket, e devolve a probabilidade de cada opção.
- Score avalia algo em uma escala ordenada, como urgência baixa, média ou alta, e devolve o valor esperado do nível.
- Noul, nome inspirado em Bernoulli, responde a uma pergunta de sim/não com uma única probabilidade, por exemplo se o cliente está pedindo reembolso.
As respostas de Choice e Score também trazem um valor de confiança, que indica o quanto as probabilidades estão concentradas.
O exemplo que atravessa o post é uma mensagem de suporte sobre uma cobrança em duplicidade. Uma única requisição pode pedir o departamento, a urgência e a intenção de reembolso ao mesmo tempo. O departamento volta como cobrança (billing), com probabilidade próxima de um.
Em que difere do que você talvez já use
O post compara os modelos de decisão com duas abordagens mais antigas. Num classificador convencional, os rótulos ficam fixos no modelo, então criar uma categoria exige retreinar. A classificação zero-shot recebe os rótulos na hora da requisição, mas lida com um só tipo de pergunta. A Hugging Face diz que os modelos de decisão não inventaram rótulos em tempo de execução nem a saída probabilística. O que eles acrescentam é uma interface única que cobre escolhas, notas em escala ordenada e perguntas de sim/não ao mesmo tempo.
O post também lista os pontos fracos de pedir JSON a um LLM. A saída pode não seguir o esquema, a decodificação restrita ainda acrescenta processamento, e gerar uma resposta inteira é trabalho extra quando o aplicativo só precisa escolher uma opção.
O que foi lançado
- Transformers ganha um pipeline de decisão, uma classe AutoModelForDecision e uma classe DecisionConfig. Também consegue servir localmente um endpoint /v1/systemone.
- llama.cpp serve modelos de decisão em GGUF pela mesma API /v1/systemone.
- O Hub tem uma tag para modelos de decisão. Os modelos listados usam backbones diferentes, de encoders no estilo ModernBERT a modelos generativos maiores.
- Treinamento: os modelos de decisão podem passar por fine-tuning com a API Trainer. O post mostra um exemplo propositalmente pequeno que roteia pedidos de suporte com uma perda de entropia cruzada sobre as opções.
O post acrescenta que modelos de linguagem autorregressivos compatíveis também podem rodar pela interface de decisão. O Transformers monta os prompts, lê os logits dos rótulos de resposta e aplica softmax sem gerar texto, então dá para testar a interface sem treinar um modelo novo.
Ressalvas
A Hugging Face descreve os modelos de decisão como um campo jovem e em rápida mudança, e o post não traz nenhuma comparação de benchmark com prompts em LLMs. Os exemplos usam modelos publicados sob os nomes autotrust e ggml-org. A acurácia nos seus tickets continua sem teste até você rodar.