Os modelos de decisão estão silenciosamente substituindo o LLM no loop dos agentes

A Cloudflare lançou, nos primeiros dias de outubro, dois modelos que não escrevem nada. Clef e Clef-flash leem uma entrada mais um conjunto de perguntas tipadas e retornam uma probabilidade para cada resposta permitida. Sem prosa, sem cadeia de pensamento, sem tokens gerados um a um. Apenas uma escolha estruturada.

Isso soa como um downgrade até você olhar os números. No BANKING77, um benchmark padrão de classificação de intenções, o Clef obtém um macro-F1 de 94,20 contra 79,74 do Jev, o modelo que introduziu a categoria dos modelos de decisão. O Clef-flash, a versão menor de 9B, alcança 90,93. A diferença de latência é ainda maior. O Clef-flash retorna uma resposta mediana em 38,8 milissegundos; o Jev leva 524,1 milissegundos. A Cloudflare afirma que o Clef supera o Jev em sete dos dez benchmarks de decisão.

Ambos os modelos são distribuídos sob licença Apache 2.0 no Hugging Face, e ambos são compatíveis com a API do Jev, de modo que equipes que já construíram suas soluções em torno do Jev podem fazer a troca sem reescrever suas integrações. A thread no Hacker News alcançou 602 pontos e mais de 200 comentários em um dia.

Por que um modelo menor pode vencer em uma tarefa mais específica

Modelos de decisão têm um formato diferente dos chatbots que a maioria dos desenvolvedores procura. Um grande modelo de linguagem gera texto aberto. Um modelo de decisão lê um estado e uma lista de respostas permitidas e então pontua cada uma delas. A categoria foi inaugurada pela Typesafe AI com o Jev, que mostrou que tarefas de roteamento ou classificação em agentes não precisam de um modelo de propósito geral de 400B. Elas precisam de uma saída limitada, barata e rápida.

O Clef, da Cloudflare, é construído sobre o Qwen3.8-27B e usa uma arquitetura apenas de prefill (prefill-only), que pontua as escolhas do esquema em paralelo em vez de gerar tokens sequencialmente. É aí que a latência se concentra. Um modelo de propósito geral precisa emitir uma resposta token após token; um modelo de decisão só precisa ler a pergunta e decidir.

Há também uma diferença de contexto que vale a pena notar. O Clef aceita entrada multimodal dentro de uma janela de 64k tokens, cobrindo texto, JSON, imagens e vídeo. O Jev lida apenas com texto, em 32k. Para um agente que roteia com base em uma captura de tela ou em um PDF, isso não é uma vantagem pequena.

A primeira objeção da comunidade estava certa

A crítica mais útil na discussão do Hacker News não contestou os benchmarks. Contestou o rótulo. "Pesos abertos, não código aberto", escreveu um comentarista. Os pesos têm uma licença permissiva, mas os dados de treinamento e o pipeline não foram publicados, então o modelo não pode ser reproduzido do zero.

Essa distinção importa para quem está decidindo onde executar isso. O Clef foi treinado a partir de um ponto de partida proprietário do Qwen. Os pesos são gratuitos para baixar e hospedar, o que representa uma economia real de custos, mas não são auditáveis como o software de código aberto é. Equipes com políticas rígidas de revisão da cadeia de suprimentos devem ler a licença e o model card antes de assumir que a etiqueta Apache 2.0 resolve a questão.

Na mesma semana, a Amazon colocou um no seu laptop

A Cloudflare não estava sozinha. O Strands Labs, da AWS, publicou o Strands Decider 2B, um modelo de decisão aberto com pesos e scripts de treinamento, projetado para rodar localmente e retornar escolhas com pontuação de confiança em dezenas a poucas centenas de milissegundos. A Cloudflare também adicionou um serviço de fine-tuning com RL para seus modelos de decisão no Workers AI.

O padrão é um modelo pequeno fazendo bem uma única tarefa e rodando perto dos dados. Se você consegue liberar uma chamada de ferramenta, verificar se uma requisição está fundamentada ou decidir se deve escalar com um modelo de 2B em 40 milissegundos, a economia de rotear um agente por um modelo de fronteira a cada passo começa a parecer desperdício.

O paradigma que o Jev introduziu, e por que demorou um ano para emplacar

O Jev, da Typesafe AI, fez uma afirmação fácil de descartar quando foi lançado: a maior parte do que os agentes pedem a um modelo não é geração, é classificação. Rotear este ticket, escolher esta ferramenta, decidir se esta ação precisa de aprovação. Para esses trabalhos, um modelo que escreve parágrafos está fazendo muito mais trabalho do que a tarefa exige.

O Jev provou que a abordagem específica podia superar um modelo de propósito geral em seus próprios benchmarks. O que ele não conseguiu foi fazer a categoria parecer urgente. Um único fornecedor vendendo um modelo de decisão é uma curiosidade. A Cloudflare lançar uma versão Apache 2.0 compatível com a API do Jev é uma situação diferente, porque agora qualquer um pode hospedá-la, inspecionar a licença e trocá-la sem reescrever nada. A Amazon chegando na mesma semana com seu próprio decider aberto transforma uma curiosidade em uma categoria.

O timing coincide com a forma como os agentes estão realmente sendo construídos. A primeira geração de frameworks de agentes roteava cada passo por um único modelo grande porque era o mais simples. À medida que esses sistemas entram em produção, os custos de roteamento se tornam o que as equipes percebem. Dividir o loop em um modelo de linguagem para as partes que precisam de linguagem e um decider para as que não precisam é a correção óbvia, e foi preciso o lançamento aberto de um bom decider para torná-la prática.

A questão do fine-tuning

A Cloudflare também adicionou um serviço de fine-tuning com RL para seus modelos de decisão no Workers AI, o que aponta para onde a categoria vai em seguida. Um decider genérico é útil. Um decider ajustado com base no seu próprio histórico de roteamento, nas suas próprias regras de escalonamento e na sua própria noção de escopo é mais útil, porque ele aprende a fronteira que importa para o seu negócio.

Essa também é a parte que deve deixar as equipes atentas. Um decider ajustado codifica suas decisões passadas, incluindo as ruins. Se sua equipe costumava aprovar reembolsos que deveria ter escalado, o modelo vai aprender esse padrão e aplicá-lo mais rápido do que qualquer humano conseguiria. A calibração corta para os dois lados.

Onde isso se encaixa em um pipeline de agentes

Imagine um agente de suporte lidando com um reembolso. Antes de chamar a ferramenta de reembolso, algo precisa responder a perguntas como: esta solicitação está no escopo, a conta do cliente permite isso, isso precisa de um humano. Essas são perguntas de decisão com um conjunto fixo de respostas. Um modelo de decisão pode retornar as probabilidades, e o agente age com base em um limite.

O perfil de custo é o ponto central. Rotear cada uma dessas verificações por um modelo de 400B custa dinheiro por chamada e adiciona centenas de milissegundos de latência. Transferi-las para um decider local de 2B ou 9B reserva o modelo de fronteira para as partes que realmente precisam de linguagem: escrever a resposta, resumir uma thread longa, lidar com um caso ambíguo. Os orçamentos e os orçamentos de latência encolhem ao mesmo tempo.

Há um porém. Um modelo de decisão retorna uma probabilidade, e probabilidades podem estar erradas de formas confiantes. Se você automatiza a aprovação de um reembolso com uma pontuação de 0,92, você transferiu o risco do texto do modelo para o seu limite. A calibração, e não a acurácia bruta, passa a ser o número a observar. Latência e custo são fáceis de medir; um 0,9 bem calibrado é mais difícil.

O que observar a seguir

O ferramental já está seguindo os modelos. O llama.cpp adicionou suporte a modelos de decisão, e a Perplexity e o Hugging Face estão ambos apostando na mesma direção. Se a categoria se sustentar, a pergunta interessante deixa de ser qual modelo de decisão ganha um benchmark e passa a ser quais decisões você está disposto a entregar a uma probabilidade.

Para quem constrói agentes, o movimento prático é auditar o loop e encontrar os passos que nunca precisaram de texto fluente. Classificação, roteamento, seleção de ferramentas e verificações antes da ação são os candidatos usuais. Esses são os passos em que uma resposta de 40 milissegundos sobre um conjunto fixo de escolhas pode substituir uma geração lenta e cara. O restante do agente pode continuar no modelo que já usa.