Seu agente não precisa de um LLM de fronteira para cada pergunta pequena. O Clef da Cloudflare explica por quê

Dentro de um loop de agente típico, um modelo grande recebe muitas perguntas pequenas: esta mensagem é urgente, qual time cuida disso, este pedido é permitido, alguém precisa olhar. Cada resposta volta como texto, que a aplicação ainda precisa interpretar. Funciona, mas é lento, caro e difícil de medir.

Em 1º de outubro, a Cloudflare lançou outro tipo de modelo justamente para essas perguntas.

O que a Cloudflare lançou

Clef e Clef-flash são o que a Cloudflare chama de modelos de decisão. Eles recebem um estado de entrada e um conjunto de perguntas tipadas e devolvem uma probabilidade para cada resposta permitida, em vez de gerar texto livre. Há três tipos de pergunta: sim ou não, escolha de uma opção numa lista e nota segundo uma rubrica.

• O Clef tem 27 bilhões de parâmetros; o Clef-flash, 9 bilhões. Os dois aceitam 64 mil tokens de contexto, texto e até quatro imagens, e foram lançados sob Apache 2.0, com pesos no Hugging Face.
• Os dois estão em disponibilidade geral no Workers AI.
• A Cloudflare cita como usos a triagem de atendimento, inteligência de ameaças e classificação de sites, pontuação de trust and safety, guardrails de agentes e classificação visual.
• O fine-tuning com aprendizado por reforço começa como programa com parceiros de design; a versão self-service vem depois.

A Cloudflare informa que o Clef-flash teve latência mediana de 38,8 milissegundos na comparação com outro modelo de decisão, cerca de 13 vezes mais rápido, e que o Clef liderou 7 de 10 benchmarks de decisão. São medições da própria Cloudflare; o material de lançamento não cita avaliador independente, e vale testar com seus dados antes de contar com esses números. A empresa também registra o trade-off óbvio: o Clef-flash troca um pouco de precisão por velocidade. Nem o changelog nem o post de lançamento que analisamos trazem preço; confira a página de preços do Workers AI.

Por que uma camada de decisão importa

O mais interessante não é a velocidade. É o formato da saída.

Uma probabilidade carrega uma política. Quando o modelo devolve “escalar: 0,83”, você pode definir que tudo abaixo de 0,9 vai para uma pessoa e tudo acima de 0,97 segue. Esse limite é uma decisão de negócio escrita em configuração, não a esperança de que o prompt seja obedecido.

Respostas tipadas são mensuráveis. Com respostas permitidas, avaliar vira um problema de classificação, com precisão, recall e matriz de confusão que times de risco e auditoria já conhecem. Roteamento em texto livre precisa de um juiz para ser avaliado.

Modelos pequenos e rápidos cabem no caminho crítico. Roteamento e triagem acontecem em toda requisição. Tirá-los do modelo de fronteira deixa esse modelo para as etapas que exigem raciocínio, a mesma lógica de custo que tratamos na análise do roteamento por tarefa no guia do GPT-6.

Pesos abertos mantêm as opções abertas. Com Apache 2.0, o mesmo modelo de decisão pode rodar fora da Cloudflare se custódia ou latência exigirem, inclusive em infraestrutura no Brasil.

1. Buscar contexto
2. Raciocinar e planejar (modelo grande)
3. Decidir: rotear, bloquear, aprovar, escalar
4. Checagem de política determinística
5. Executar ferramenta ou passar a uma pessoa

• Generativo: Buscar contexto · Raciocinar e planejar (modelo grande)
• Probabilístico e tipado: Decidir: rotear, bloquear, aprovar, escalar
• Determinístico: Checagem de política determinística · Executar ferramenta ou passar a uma pessoa

Raciocínio abertoProbabilidades sobre respostas permitidas

O que um modelo de decisão não substitui

Probabilidade não é permissão. Se o modelo de decisão diz “aprovar” com alta confiança, uma camada de política determinística ainda verifica se esse usuário, esse agente e essa ação são permitidos. O modelo estreita as opções; as regras decidem. Defendemos o mesmo ponto ao analisar o que deve continuar determinístico no sistema de contas a pagar da Snowflake.

A calibração também precisa de prova. Um modelo que diz 0,9 deveria acertar umas nove vezes em dez no seu tráfego. Meça isso antes de definir limites, e de novo depois de qualquer fine-tuning ou atualização de modelo.

E algumas decisões têm peso jurídico. Se um modelo de decisão bloqueia, aprova ou classifica clientes com base em dados pessoais, o artigo 20 da LGPD garante ao titular o direito de pedir revisão de decisões tomadas unicamente com base em tratamento automatizado, e de receber informações claras sobre os critérios usados. Uma probabilidade não é um critério explicável por si só; o sistema precisa registrar por que o resultado aconteceu. No atendimento, onde a triagem automática é o primeiro uso natural, o Decreto do SAC exige acesso a atendimento humano: a faixa de incerteza que vai para uma pessoa não é só boa prática, é parte do desenho.

O que fazer agora

1. Liste as decisões pequenas dos seus agentes: roteamento, escalonamento, moderação, escolha de ferramenta, classificação do próximo passo.
2. Estime a fatia delas nas chamadas e no custo. Em muitos agentes, são a maioria das chamadas.
3. Faça um piloto com um modelo de decisão em uma delas, usando um conjunto rotulado do seu histórico, e compare com o prompt atual em precisão, latência e custo.
4. Defina limites como configuração, com uma faixa explícita que vai para uma pessoa.
5. Mantenha a checagem de política separada e registre tanto a probabilidade quanto a regra que permitiu ou bloqueou a ação.
6. Acompanhe a calibração ao longo do tempo, como em qualquer classificador em produção.

Em resumo

O Clef é um produto, mas o padrão é maior: agentes estão virando sistemas compostos, em que modelos diferentes respondem tipos diferentes de pergunta. Deixe as decisões estreitas e frequentes com um modelo feito para decidir, o modelo de raciocínio com o raciocínio, e a palavra final com a política determinística.