O modelo de IA Jev não consegue alucinar. Ainda assim errou 37% dos e-mails.

A matéria da TechCrunch na semana do lançamento sobre o modelo de IA Jev, da TypeSafe, resumiu o discurso em uma linha: "como os usuários definem as saídas de antemão, ele não consegue alucinar". No dia anterior, um benchmark independente fez ao Jev uma única pergunta sobre 2.000 e-mails — se cada um era phishing — e ele errou 37,4% deles. As duas afirmações são verdadeiras.

O Jev garante o formato de uma resposta, não a sua veracidade. Ele é uma função de decisão rápida e barata para perguntas pequenas e delimitadas que eu consigo rotular e para as quais consigo definir um threshold. Não é um modelo de linguagem mais inteligente, nem um chatbot que por acaso é rápido. Desde que a TypeSafe AI abriu o acesso antecipado em 15 de setembro, li o material de lançamento, a documentação, os primeiros testes independentes e o código-fonte do adaptador do Pydantic AI, que instalei e rodei. O que vem a seguir é onde as afirmações do lançamento se sustentam e onde elas param.

Para que o modelo de IA Jev foi construído

A TypeSafe chama o Jev de um modelo System One, tomando emprestada a divisão de Kahneman entre julgamento rápido e intuitivo e deliberação lenta. O post de lançamento o descreve como um modelo que recebe estado não estruturado e devolve decisões tipadas com probabilidades. Ele não foi construído para devolver prosa. São três tipos de pergunta:

• Noul: uma pergunta sim/não, respondida com a probabilidade de sim.
• Choice: escolher uma entre até 255 opções, com uma probabilidade para cada.
• Score: posicionar a entrada em uma rubrica de até 10 níveis.

Como o espaço de respostas é fixado de antemão, o Jev não gera token a token. Ele responde a todas as perguntas de uma requisição em uma única passada paralela. É daí que vem a velocidade: de 70 a 500 ms de ponta a ponta, segundo os números da TypeSafe, a US$ 0,042 por milhão de tokens de entrada, com tokens de saída gratuitos.

Os trabalhos pretendidos são os que um programa precisa, não os que uma pessoa pede. A TypeSafe lista roteamento, classificação, scoring, condicionais inteligentes dentro de workflows, rotulagem map-reduce sobre grandes conjuntos de dados e verificação ou guardrails sobre a saída de outros modelos. O mesmo post de lançamento admite que modelos de linguagem continuam sendo a melhor ferramenta para chat, copilots e agentes de código. Os criadores não afirmaram que ele podia fazer tudo. Partes da cobertura pesaram nessa direção: um texto sobre o hype do lançamento registra uma newsletter chamando-o de um "momento ChatGPT para decisões" e, nas discussões que acompanhei desde então, isso se esticou até tratar o Jev como um substituto mais rápido para um modelo de linguagem.

A adoção foi rápida. A Vercel reportou que quase 13% dos times pagos do AI Gateway estavam chamando o Jev em 24 horas, mais que o dobro de qualquer lançamento anterior. É por isso que vale checar as afirmações abaixo agora, antes que uma onda de integrações as consolide.

Quatro afirmações da semana de lançamento contra as evidências

"Não consegue alucinar" significa que a resposta faz parse, não que ela está certa

Isso é verdade em um sentido estreito que importa. O Jev não consegue devolver um valor fora do schema. O adaptador do Pydantic AI impõe isso antes de a requisição sair da máquina. Aqui está um tipo de saída de triagem de tickets em Python, com um campo tipado como string livre:

from pydantic import BaseModel, Field
from pydantic_ai import Agent
from pydantic_ai.exceptions import UserError


class Triage(BaseModel):
    """How to handle an inbound support ticket."""

    queue: str = Field(description="Which team should own this ticket?")
    urgent: bool = Field(description="Does it need a reply within an hour?")


agent = Agent("typesafe:jev-latest", output_type=Triage)

try:
    agent.run_sync("I was billed twice for invoice 4411.")
except UserError as err:
    print(str(err).split(". ")[0])

pip install "pydantic-ai-slim[typesafe]"
PYDANTIC_AI_NO_BANNER=1 TYPESAFE_API_KEY=unused python triage.py

No pydantic-ai-slim 2.48.0 isso imprime Output field 'queue' is not supported by this model. A chave de API falsa nunca chega à TypeSafe, porque o adaptador recusa o schema antes. A correção é declarar o espaço de respostas: queue: Literal["billing", "bugs", "sales"]. Na minha execução, o adaptador também recusou, antes de enviar qualquer coisa, uma saída str pura, um campo int e um campo com 256 opções. Um schema válido seguiu para o servidor e voltou com um 401.

Então a garantia de não alucinação significa que a resposta sempre vai fazer parse, e eu valorizo isso. Não significa que a resposta está certa. Na execução do jev-phishing-bench sobre o jev-1.13.0, perguntar se cada e-mail era phishing rendeu 62,6% de acurácia contra 81,3% do Claude Haiku 4.5. O Jev pegou 43,2% dos e-mails de phishing; o Haiku pegou 76,4%. O resumo do autor do benchmark é direto: "o veredito do próprio Jev perde claramente em acurácia". Uma resposta errada escolhida de um conjunto válido é mais difícil de notar do que uma malformada, porque nada mais adiante reclama.

O viés recebe a mesma proteção. Simon Willison pediu ao Jev que pontuasse cidades da Bay Area em "boa cidade?" e ele colocou Cupertino em primeiro e East Palo Alto em último. Toda resposta era bem tipada. O preconceito estava dentro da probabilidade, onde nenhum schema consegue enxergar.

193,6 vezes mais rápido, contra modelos de fronteira nos workflows da própria TypeSafe

O post de lançamento diz que os multiplicadores de 193,6x em velocidade e 444,6x em custo vêm de seus evals de workflow, e que a TypeSafe espera que eles fiquem no topo dos ganhos do mundo real. Nessa tabela, as execuções de workflow dos outros modelos levaram de 10,1 a 86,5 segundos por caso, contra 0,4 segundo do Jev, a US$ 0,0004 por caso. O Claude Sonnet 5 empatou com o Jev em 67,8% e levou 78,1 segundos, cerca de 195 vezes os 0,4 do Jev, perto da razão de velocidade da manchete. Esses 67,8% são concordância com rótulos de referência feitos pela média entre GPT-6 Astra e Claude Fable 5.1, não concordância com ground truth, e o post de lançamento admite que a escolha enviesa os resultados a favor dos modelos desses dois fornecedores.

O multiplicador depende de quem está do outro lado. O Claude Haiku 4.5 aparece na mesma tabela com 12,5 segundos e US$ 0,0195 por caso de workflow, cerca de 31 vezes mais lento e 49 vezes mais caro que o Jev. No benchmark de phishing de pergunta única, a diferença encolhe de novo: a latência mediana do Jev foi de 239 ms contra 687 ms do Haiku, cerca de 2,9 vezes mais rápido, e custou US$ 0,038 por 1.000 e-mails contra US$ 0,462, cerca de 12 vezes mais barato. A rede importa nessa escala. De onde esse benchmark rodou, 163 ms dos 239 ms do Jev eram piso de rede, contra 18 ms do Haiku. Tire os pisos e a diferença do lado do modelo é de cerca de 9 vezes, não 2,9.

Probabilidades calibradas ainda precisam de um threshold ajustado em dados rotulados

A TypeSafe treina o Jev com um método que chama de Reinforcement Learning for Calibrated Decisions, e as probabilidades são a coisa mais útil que ele devolve. Elas ainda precisam ser verificadas antes do uso. No veredito único de phishing, o benchmark mediu um erro de calibração esperado de 0,154 para o Jev contra 0,097 do Haiku, ou seja, as probabilidades declaradas pelo Jev ficaram mais distantes das taxas de acerto observadas do que as do Haiku naqueles dados. As notas de jaggedness do jev-1.13 da própria TypeSafe acrescentam que a probabilidade de sim e a probabilidade de não não têm garantia de somar um. Elas também dizem que uma resposta Choice e uma resposta Noul sobre o mesmo fato podem discordar, então um threshold ajustado em uma primitiva não se transfere para a outra.

O adaptador traz uma armadilha própria. Um campo bool arredonda a probabilidade em um threshold padrão de 0,5. Quando chamei a função de arredondamento do adaptador diretamente, tanto 0,51 quanto 0,99 voltaram como True. Pelo código-fonte do adaptador, a margem sobrevive apenas como uma "confidence" nos provider details da resposta: 0,02 para o primeiro, 0,98 para o segundo. Se a probabilidade é o que vou usar para agir, declaro o campo como um float limitado entre 0 e 1, que o código repassa sem arredondar.

A docstring do adaptador também diz que um id de modelo versionado, como jev-1.13.0, é o que se deve usar depois que um threshold de confiança foi ajustado contra ele. Thresholds pertencem a uma versão de modelo, não a uma família de modelos.

O que ele não consegue fazer, segundo a própria documentação

A documentação é a melhor refutação ao enquadramento de substituto direto, porque foi o fornecedor que a escreveu. A página de jaggedness abre sua lista com uma frase que eu imprimiria acima de qualquer integração: o Jev "responde à pergunta que você escreveu, não à que você quis dizer". O resto da lista cobre contagem e aritmética, valores hexadecimais e triplas RGB, ordenação de datas e durações, dupla negação e raciocínio de múltiplos saltos, estado longo cheio de detalhes irrelevantes, instruções injetadas contra as quais ele não é endurecido, critérios contraditórios e geração de texto, para a qual ele não foi treinado e na qual é lento quando forçado.

Sean Goedecke acrescenta o limite estrutural. Um modelo que responde em uma única passada não consegue gastar raciocínio em tempo de inferência, então seu julgamento tem como teto o de um modelo de linguagem sem reasoning. O profile de modelo do adaptador concretiza o resto: 64.000 tokens de contexto no total, dos quais o estado mais a pergunta mais longa devem caber em 32.000. Ele não tem saída de texto e não aceita imagens nem arquivos.

Onde ele conquista um lugar no pipeline

O resultado mais útil do benchmark de phishing não são os 62,6%. O mesmo autor passou a fazer ao Jev cinco perguntas estreitas sobre cada e-mail em vez de uma ampla: há incompatibilidade de domínio, um link em hospedagem gratuita, uma isca, pressão de urgência, um remetente genérico. Uma regressão logística com validação cruzada sobre essas cinco probabilidades, ajustada nos rótulos do benchmark, chegou a 95,1% de acurácia, com AUROC de 0,988 e erro de calibração de 0,027. Só o sinal de hospedagem gratuita, usado como regra fixa, chegou a 89,5%.

O diagrama abaixo mostra os dois formatos lado a lado. Repare onde a composição acontece: no segundo formato, o Jev só responde perguntas atômicas, e o veredito é montado em código.

É esse o formato em torno do qual eu projetaria. O Jev é uma condição de desvio dentro de um fluxo determinístico, o padrão que defendi em The Deterministic Backbone. Cada resposta cai em uma de três faixas. Acima de um threshold ajustado, o código age. Na faixa incerta do meio, ele passa a bola para um modelo de linguagem ou para uma pessoa. Abaixo do limite inferior, segue o caminho padrão. O adaptador já suporta esse repasse. Quando o Jev escolhe uma ferramenta cujos argumentos não consegue preencher, o adaptador levanta ToolCallProposed, e um FallbackModel que coloque um modelo de linguagem atrás do Jev pode assumir a chamada.

A US$ 0,042 por milhão de tokens de entrada, um julgamento de 500 tokens custa cerca de dois milésimos de centavo. Isso muda onde um julgamento pode entrar: em lugares que antes abrigavam um if sobre uma regex. É o argumento de Engineering Before Inference, invertido. Toda chamada de IA continua sendo uma decisão arquitetural. O custo migrou da fatura para a acurácia que agora eu preciso medir.

Quando usar o Jev:

• Rotear um ticket, mensagem ou requisição para um entre um conjunto fixo de filas, agentes ou ferramentas.
• Decidir se um workflow deve continuar, tentar de novo, perguntar ao usuário ou parar — um dos usos que a Vercel cita na sua nota de lançamento.
• Guardrails e verificações sobre a saída de outro modelo: um sim/não sobre um critério específico e escrito.
• Triagem e priorização, mantendo a probabilidade como score.
• Reordenar resultados de busca ou candidatos por uma pergunta de relevância declarada.
• Rotular milhões de linhas onde o preço ou a latência de um modelo de linguagem inviabilizaria o trabalho.

Quando não usar o Jev:

• Qualquer coisa cuja saída seja prosa, código ou resumo. Esse é o trabalho de um modelo de linguagem.
• Aritmética, contagem e lógica de datas. Calculo isso em código e passo o resultado ao Jev.
• Entrada controlada por um atacante, quando a decisão concede acesso ou movimenta dinheiro. A verificação de permissão fica no código.
• Decisões sobre pessoas, como contratação, crédito ou moderação de indivíduos. Scores opacos escondem viés, como o teste das cidades mostrou.
• Raciocínio de múltiplos passos, ou uma pergunta cujo espaço de respostas eu não consigo listar de antemão.
• Estado que precise de mais de 32.000 tokens de contexto majoritariamente irrelevante. Eu filtro antes.

O que eu mediria antes de deixá-lo agir sozinho

Se eu ligasse o Jev a um pipeline amanhã, rodaria primeiro em shadow mode e mediria cinco coisas antes de deixar uma única resposta produzir efeito.

• Acurácia nas minhas próprias decisões rotuladas, não nos evals do fornecedor. Mil decisões de 500 tokens cada custam cerca de dois centavos para reexecutar.
• Calibração por faixa. Das respostas que voltaram com 0,9 ou mais, que fração estava certa? O threshold sai desse número, não de 0,5.
• Uma pergunta ampla contra a sua decomposição. A diferença no phishing foi de 32,5 pontos, e eu esperaria uma diferença desse tipo sempre que um veredito for, na verdade, a combinação de fatos separados.
• A fatia do passo de decisão na latência ponta a ponta. Se ele é 20% de uma requisição, uma decisão instantânea torna a requisição inteira no máximo 1,25 vez mais rápida. É o único ganho de velocidade que os usuários vão perceber.
• Discordâncias com o modelo de linguagem que já está no loop, lidas por uma pessoa. As discordâncias são onde a lista de jaggedness vira casos concretos.

Eu também fixaria jev-1.13.0 em vez de jev-latest no momento em que um threshold fosse ajustado, e reexecutaria o conjunto de shadow a cada mudança de versão. É a mesma disciplina que a execução do TimesFM 2.5 me ensinou: um modelo que supera um baseline em dados estáveis pode perder para um baseline de uma linha depois de uma única mudança realista. O sistema de tipos me diz que toda resposta vai fazer parse. Só o log rotulado me diz se ela está certa.