Cloudflare lança o Clairic, modelo de extração de dados sem tokens de saída

A Cloudflare lançou em preview o Clairic, o primeiro modelo de uma nova classe, a System One extraction. Ele está disponível no Workers AI como @cf/cloudflare/clairic, e a empresa promete liberar os pesos abertos em breve. O Clairic extrai valores de entradas não estruturadas, faz cálculos com eles, estima e prevê. Tudo isso acontece em uma única passada paralela, sem raciocínio e sem tokens de saída. A resposta costuma levar menos de um segundo, enquanto uma LLM que raciocina sobre o mesmo passo gasta alguns segundos. A cobrança é apenas pela entrada.

O terceiro tipo de modelo da família System One

O conceito de System One (o modelo rápido e preciso, na terminologia de Kahneman, em oposição à lenta System Two, como as LLMs) foi apresentado um mês antes pela TypeSafe, com o modelo Jev. Jev e Clef são modelos de decisão: recebem um estado e uma lista de perguntas e devolvem probabilidades para opções enumeradas previamente. A Cloudflare identificou uma lacuna.

Grande parte das chamadas a LLMs de fronteira com saída estruturada se resume às mesmas perguntas: qual o valor da fatura, quando a entrega foi feita, quantos dias de atraso, quanto custará o reparo, qual será o tráfego nas próximas 24 horas. Não dá para listar de antemão as respostas a perguntas assim, então o modelo de decisão não serve nesses casos.

A divisão de trabalho fica assim. O Clairic transforma a entrada bruta em valores tipados, Clef e Jev transformam valores em decisões, e a LLM transforma decisões em palavras. O espaço de saída do Clairic é contínuo, mas limitado pelo seu esquema, e cada resposta é um valor do tipo declarado ou null.

Como é a requisição e o que ela retorna

A requisição tem um state (texto mais até quatro imagens) e um mapa de campos tipados. Cada campo recebe um nome, um tipo e uma instrução opcional em linguagem simples. Se os campos não couberem junto com a entrada em uma única passada, o servidor os divide por conta própria em passadas paralelas, cada uma com acesso a toda a entrada, e depois junta as respostas. Por isso, trinta campos custam aproximadamente o mesmo que três.

Os tipos suportados são:

• text: trecho da entrada com deslocamentos de caracteres (span) • number: número lido ou calculado, respeitando integer e decimals • date, time, datetime: datas de calendário e horários válidos no formato ISO • duration: duração na unidade escolhida • list: lista de textos, números ou datas na ordem em que aparecem na entrada • estimate: distribuição dentro dos seus [min, max] em uma grade definida, linear ou logarítmica • forecast: uma estimativa para cada passo futuro da série, cada uma com seu próprio intervalo de 80%

Toda resposta escalar vem com p_null (a probabilidade de o valor não existir na entrada) e confidence. As estimativas trazem mediana e intervalo p10–p90, e, sob demanda, todos os 99 percentis.

Tomemos o e-mail de uma cliente: pedido A-88412 entregue em 28 de setembro, pagamento de $649.00 mais $52.10 de imposto, e-mail escrito em 9 de outubro. O Clairic soma preço e imposto por conta própria e devolve 701.10, e calcula 11 como o número de dias desde a entrega. Os danos (cracked screen, dented corner) voltam como spans exatos, que podem ser destacados no texto original. O e-mail não tem código de rastreio, então o campo retorna null com p_null = 1, e o guess ($52.10) mostra o que o modelo escolheria se não pudesse deixar a resposta vazia. A confiança nesse valor é de apenas 0,416.

O mesmo mecanismo funciona com a foto de um recibo tirada em ângulo ruim. O modelo extraiu o número do pedido 77245, o horário da compra 2026-07-01T13:34:00, dois itens de 7.99, subtotal de 15.98, gorjeta de 2.39 e imposto zero. O desconto foi corretamente retornado como null, com p_null em torno de 0,9994. A confiança no número do pedido e no horário é menor (0,78 e 0,83) do que no valor total (0,99999), e é justamente essa diferença que se sugere usar para encaminhar casos à revisão manual.

Onde isso muda a economia dos pipelines

Um pipeline típico de extração com LLM acumula camadas: parsing, validação de esquema, retentativas, amostragem para controle. Paga-se por raciocínio e tokens de saída em cada campo de cada documento. Os erros, além disso, são traiçoeiros. O JSON pode vir inválido, um número pode se distorcer durante a geração, e o trecho encontrado não fica vinculado ao original. O Clairic não gera texto, então não há números alterados. Ele pode errar, mas o erro será um valor do tipo correto com confidence baixa ou intervalo largo, e não uma string quebrada.

Com estimativas, a vantagem é ainda maior. A LLM devolve um único número, e por ele não dá para distinguir um $180 confiante de um incerto. As faixas de um modelo de decisão são grosseiras, e cada uma acrescenta tokens de entrada e confusão. No Clairic, um intervalo estreito indica confiança, e um intervalo largo indica que vale mandar o valor para uma segunda checagem.

Na prática, os usos são a análise de faturas, recibos e chamados de suporte, a estimativa de custo de reparo ou de preço com base em vendas comparáveis e a previsão de carga para as próximas 24 horas. Em todas essas tarefas, o limite de automação pode ser definido por um número, por exemplo aceitar valores com confidence acima de 0,95 e enviar o restante a uma pessoa ou a uma LLM. O Clairic ainda está em preview, mas os pesos abertos devem permitir testá-lo com documentos próprios e, possivelmente, hospedá-lo internamente.