Jev: o hype faz sentido ou estamos apenas colocando um nome novo em um problema antigo?

Uma análise sobre o lançamento da TypeSafe, o hype das últimas semanas, os benchmarks e o que realmente muda na arquitetura de sistemas com IA.

Nas últimas duas semanas começou a aparecer um nome com uma frequência incomum entre desenvolvedores, pesquisadores e investidores de IA: Jev.

O modelo foi lançado pela TypeSafe AI em 15 de setembro e conseguiu algo que hoje é quase tão importante quanto performance técnica: chamou atenção muito rápido. Em 24 horas, quase 13% das equipes pagantes que utilizavam o AI Gateway da Vercel já tinham experimentado o modelo. Segundo a própria Vercel, foi a adoção mais rápida de um modelo na história do serviço.

Poucos dias depois começaram a aparecer vídeos, benchmarks, hackathons, experimentos com agentes e até um projeto no qual Jev terminou Pokémon Red em menos de uma semana. Ao mesmo tempo, investidores passaram a discutir uma avaliação superior a US$ 10 bilhões para a TypeSafe, empresa que pouco antes era avaliada em aproximadamente US$ 200 milhões.

É o tipo de combinação que produz hype muito rapidamente.

Só que, dessa vez, existe uma discussão técnica por trás do barulho que considero bem mais interessante do que a narrativa de “novo modelo que vai destruir OpenAI e Anthropic”.

Jev não foi criado para competir com ChatGPT ou Claude em conversa, escrita ou raciocínio aberto.

Ele foi criado para decidir.

E essa diferença muda bastante a discussão.

O que o Jev faz de diferente

Uma LLM tradicional recebe tokens e gera novos tokens.

Mesmo quando queremos apenas classificar alguma coisa, normalmente fazemos algo parecido com isto:

Classifique esta mensagem como:
financeiro
suporte
fraude
cancelamento

O modelo processa o contexto e então gera uma resposta textual.

Pode ser apenas:

{
  “categoria”: “financeiro”
}

Mas continua existindo geração.

Depois disso o software precisa interpretar aquela saída, validar formato, verificar se a resposta pertence ao conjunto esperado e tratar eventuais erros.

O Jev elimina parte desse caminho.

Você fornece um estado, define previamente quais perguntas quer fazer e quais respostas são válidas. O modelo devolve escolhas, scores ou valores booleanos acompanhados de probabilidades.

Na prática, ele não precisa escrever “financeiro”.

Ele precisa decidir qual das opções disponíveis possui maior probabilidade.

A API deixa isso explícito. O modelo trabalha com estado compartilhado e perguntas tipadas, podendo avaliar várias delas em paralelo.

Essa diferença parece pequena quando pensamos em uma única chamada.

Ela deixa de ser pequena quando um sistema precisa tomar milhões de decisões.

O número de 193 vezes mais rápido precisa ser lido com cuidado

Grande parte do hype começou pelos benchmarks divulgados pela TypeSafe.

A empresa reportou resultados chegando a 193,6 vezes mais velocidade e 444,6 vezes menos custo em determinadas avaliações quando comparado com LLMs tradicionais.

É um número impressionante.

Também é um benchmark produzido pela própria empresa, comparando um modelo especializado em decisões estruturadas com modelos generalistas em tarefas exatamente desse tipo.

Isso precisa aparecer junto do número, não três páginas depois.

Se eu construo uma ferramenta especificamente para classificação, roteamento e scoring, espero que ela seja muito eficiente nessas tarefas.

O teste realmente importante não é descobrir se Jev consegue classificar mais rápido do que uma frontier LLM.

Provavelmente consegue.

A pergunta melhor é:

quanto de precisão eu perco em troca dessa velocidade e desse custo?

E uma segunda pergunta vem logo depois:

eu realmente precisava de uma LLM antes?

Essa talvez seja a comparação mais incômoda para o Jev.

O concorrente do Jev talvez não seja o GPT

Grande parte das comparações coloca Jev de um lado e GPT, Claude, Gemini ou Qwen do outro.

Mas existe uma categoria inteira sendo ignorada nessa discussão: classificadores tradicionais.

Antes de transformarmos qualquer problema em prompt, já existiam modelos de classificação.

Logistic regression.

SVM.

BERT ajustado para uma tarefa específica.

spaCy.

Modelos pequenos treinados internamente.

Regras.

Keywords.

Em muitos problemas estáveis, um classificador tradicional continua sendo absurdamente barato, rápido e previsível.

Então por que utilizar Jev?

Porque existe uma diferença importante.

Um classificador tradicional normalmente exige dados rotulados, treinamento, validação e manutenção. Se amanhã as categorias mudarem, pode ser necessário retreinar o modelo ou reconstruir parte do pipeline.

Jev tenta ocupar um espaço intermediário.

Ele oferece parte da flexibilidade que tornou LLMs tão atraentes, mas sem carregar todo o custo da geração textual.

Isso começa a fazer sentido em situações nas quais as decisões mudam frequentemente ou dependem de bastante contexto não estruturado.

Um sistema de atendimento poderia, por exemplo, analisar histórico do cliente, mensagem atual, dados do pedido, regras internas e decidir simultaneamente prioridade, departamento responsável, risco e necessidade de revisão humana.

Não precisamos necessariamente de uma resposta em linguagem natural para nenhuma dessas coisas.

Precisamos de decisões.

É aí que o Jev começa a parecer menos com uma “LLM pequena” e mais com outra peça de infraestrutura.

O melhor argumento a favor do Jev está nos sistemas com agentes

Um chatbot normalmente faz poucas chamadas por interação.

Um agente pode fazer dezenas.

Ele precisa decidir qual ferramenta utilizar, qual documento consultar, se deve continuar executando, se precisa chamar outro modelo, se determinada resposta está suficientemente fundamentada e quando deve parar.

Se cada uma dessas decisões exigir uma chamada para uma frontier LLM, o problema começa a ficar caro e lento rapidamente.

Nesse cenário, uma arquitetura que me parece bastante plausível seria:

Jev decide. Código executa. Uma LLM mais poderosa raciocina quando necessário.

Isso não coloca Jev contra GPT ou Claude.

Coloca os dois trabalhando em camadas diferentes.

Inclusive existe evidência preliminar apontando justamente nessa direção. Uma revisão publicada poucos dias após o lançamento analisou os primeiros estudos sobre Typed Decision Models e concluiu que ainda não existe evidência de que esse formato produza, sozinho, uma vantagem de precisão em relação a técnicas comparáveis. Os ganhos mais claros até agora estão em latência e custo.

Isso muda bastante a leitura.

A tese não precisa ser:

“Jev é mais inteligente.”

Pode ser simplesmente:

“Jev é inteligente o suficiente para decisões que não justificam chamar um modelo muito maior.”

Essa é uma tese tecnicamente muito mais defensável.

Os primeiros testes independentes são mais interessantes que o marketing

Depois do lançamento começaram a aparecer avaliações que não foram feitas pela TypeSafe.

Uma delas, o PriorBench, realizou 5.721 chamadas em 21 experimentos diferentes e gastou US$ 0,176.

Os pesquisadores mediram aproximadamente 430 ms de latência mínima e conseguiram executar 800 julgamentos tipados em uma única chamada em menos de um segundo.

No benchmark de classificação criado por eles, Jev atingiu 95,9% de acurácia zero-shot, contra 77,2% de um sistema baseado em palavras-chave e 66% de TF-IDF com regressão logística.

Esses números são interessantes principalmente porque deixam a comparação menos artificial.

Agora não estamos colocando Jev somente contra um modelo enorme.

Estamos comparando com alternativas simples que alguém poderia realmente utilizar em produção.

Só que o mesmo experimento revelou uma característica bem menos agradável.

Jev sempre responde.

Os pesquisadores deram ao modelo uma receita de bolo em uma tarefa de classificação de problemas técnicos.

Ele classificou aquilo como problema técnico com 94% de confiança.

Depois enviaram letras aleatórias.

O modelo respondeu com 97% de confiança.

Para mim, esse resultado é muito mais importante do que boa parte das demos virais.

Porque ele expõe uma diferença fundamental entre probabilidade fornecida pelo modelo e confiabilidade real da decisão.

Um sistema automatizado que recebe uma resposta errada com baixa confiança pode encaminhar aquilo para revisão.

Um sistema que recebe uma resposta absurda com 97% de confiança tem um problema bem mais complicado.

“Jev não alucina” é uma frase boa de marketing e ruim de engenharia

A TypeSafe utiliza como argumento que Jev elimina hallucinations.

Eu teria muito cuidado com essa afirmação.

Existe uma interpretação técnica válida.

Se você define apenas três respostas possíveis:

A
B
C

Jev não vai inventar:

D

Também não vai devolver uma história, um JSON quebrado ou uma resposta fora do schema.

A estrutura da saída impede isso.

Mas nada impede o modelo de responder B quando a resposta correta era A.

Pior ainda, como vimos nos testes independentes, ele pode fazer isso com confiança elevada.

Então existe uma diferença enorme entre:

não gerar uma resposta inválida

e

não gerar uma decisão errada.

Type safety resolve a primeira.

Não resolve automaticamente a segunda.

Para engenharia de software, a primeira propriedade já é extremamente útil.

Não precisamos exagerá-la para reconhecer seu valor.

O benchmark de 346 mil chamadas traz uma imagem mais equilibrada

Outro trabalho independente publicado em 29 de setembro avaliou a versão jev-1.13.0 em 37 datasets diferentes.

Foram 346.009 requisições.

O custo total ficou abaixo de US$ 10.

Esse número sozinho ajuda a explicar por que desenvolvedores começaram a prestar atenção.

No benchmark, Jev atingiu entre 95% e 99% de acurácia em conjuntos como IMDB, SST-2, HellaSwag e ARC. Também superou Qwen em 27 dos 37 datasets avaliados.

Mas os resultados pioraram em idiomas com poucos dados, classificações com labels muito próximos, dados ruidosos e avaliações baseadas em rubricas subjetivas.

Esse é exatamente o tipo de resultado que eu esperaria de uma tecnologia dessas.

Quanto mais o problema se aproxima de:

“Escolha uma opção bem definida entre algumas alternativas”

melhor a proposta parece funcionar.

Quanto mais o problema exige interpretação subjetiva, raciocínio aberto ou compreensão profunda de nuances, mais as vantagens diminuem.

Isso também ajuda a definir onde eu não usaria Jev.

Onde Jev provavelmente não é a ferramenta certa

Eu não colocaria Jev como primeira escolha para diagnóstico complexo, análise jurídica aberta, produção de texto, raciocínio longo, pesquisa, planejamento, tarefas em que as opções não podem ser conhecidas previamente ou decisões nas quais o próprio sistema precisa descobrir quais alternativas existem.

Também teria bastante cautela em decisões críticas automatizadas somente porque a probabilidade retornada parece alta.

Probabilidade não é garantia.

O modelo está dizendo algo sobre sua distribuição interna, não assinando um contrato de que aquela decisão está correta.

Por outro lado, existem casos em que a proposta parece encaixar muito bem: roteamento, moderação, triagem, priorização, detecção de intenção, seleção de ferramentas, avaliações simples, controle de fluxo em agentes, classificação de documentos e verificação preliminar antes de chamar modelos maiores.

Isso já representa uma quantidade enorme de software.

O Pokémon Red mostrou mais sobre arquitetura do que sobre inteligência

Um dos experimentos que mais ajudou o Jev a viralizar foi Pokémon Red.

O modelo conseguiu terminar o jogo em menos de uma semana, algo que gerou comparações imediatas com experimentos anteriores envolvendo LLMs.

Só que existe uma informação importante.

Jev não fez tudo sozinho.

Claude Opus 5 foi utilizado como uma espécie de treinador. Ele analisava logs e ajudava a ajustar as opções quando o sistema ficava preso ou entrava em loops. O próprio harness também passou por várias alterações durante o experimento.

Algumas pessoas podem olhar para isso e diminuir o resultado.

Eu vejo de outra forma.

O experimento mostra exatamente o tipo de arquitetura que pode acabar ficando comum.

Um modelo mais poderoso resolve situações excepcionais.

Um modelo barato executa milhares de decisões simples.

Código tradicional mantém estado e executa ações.

Não existe obrigação nenhuma de encontrar um único modelo capaz de fazer tudo.

Essa obsessão por “qual é o melhor modelo?” provavelmente vai parecer cada vez mais limitada conforme sistemas de IA ficarem mais complexos.

O hype também é financeiro

A parte técnica explica apenas metade do que aconteceu.

A outra metade é narrativa.

Segundo o Financial Times, o lançamento acumulou dezenas de milhões de visualizações e levou investidores a discutir uma avaliação superior a US$ 10 bilhões para a TypeSafe.

O Business Insider encontrou mais de 100 mil pessoas no Discord da empresa poucos dias depois do lançamento e relatou forte interesse de investidores e desenvolvedores em San Francisco.

Não é difícil entender por quê.

Durante anos a principal narrativa de IA foi: modelos maiores, mais parâmetros, mais computação, mais contexto e mais raciocínio.

A TypeSafe apareceu com uma história praticamente oposta.

Talvez grande parte das decisões de software não precise de toda essa inteligência.

É uma narrativa muito boa.

E narrativas muito boas atraem capital rapidamente.

Isso não significa que a tecnologia seja ruim.

Significa apenas que precisamos separar duas coisas que frequentemente andam juntas no Vale do Silício: uma boa ideia técnica e uma avaliação financeira completamente antecipada sobre o tamanho que essa ideia poderá ter.

US$ 10 bilhões não é um benchmark.

É uma aposta.

O nome Jev também carrega uma tese

Jev é uma referência a William Stanley Jevons e ao chamado Paradoxo de Jevons.

A ideia, simplificando bastante, é que ganhos de eficiência nem sempre reduzem o consumo de determinado recurso.

Às vezes acontece o contrário.

Quando algo fica muito mais eficiente e barato, surgem tantos novos usos que o consumo total aumenta.

A TypeSafe está fazendo essa aposta com inteligência artificial.

Se uma decisão de IA custar quase nada, não utilizaremos IA apenas nos lugares em que já usamos hoje.

Vamos começar a colocar inteligência em decisões onde atualmente sequer vale a pena chamar um modelo.

Esse raciocínio faz sentido.

Mas também tem um lado menos conveniente.

Se cada aplicação começar a executar centenas ou milhares de decisões que antes simplesmente não existiam, eficiência por chamada não significa necessariamente menor consumo total de computação.

O próprio paradoxo usado para batizar o modelo serve como alerta.

Podemos tornar a inteligência muito mais eficiente e, justamente por isso, consumir muito mais dela.

Ainda não testei o Jev e isso importa

Existe uma coisa que eu prefiro deixar clara.

Eu ainda não rodei um benchmark próprio do Jev.

Então não vou escrever que “testei”, “medi” ou “comprovei” alguma coisa que eu não fiz.

O que temos hoje são resultados publicados pela TypeSafe, dados da Vercel, experimentos de terceiros e alguns trabalhos independentes que surgiram em pouquíssimos dias.

É cedo.

Muito cedo.

Inclusive boa parte da literatura disponível foi produzida praticamente na mesma semana do lançamento.

Então minha leitura hoje não é uma recomendação de produção.

É uma leitura de arquitetura.

E nesse aspecto eu acho que existe algo importante acontecendo.

O verdadeiro impacto do Jev talvez não seja o próprio Jev

Pode acontecer de Jev crescer absurdamente.

Pode acontecer de desaparecer em dois anos.

Pode acontecer de OpenAI, Anthropic, Google e outras empresas criarem produtos semelhantes e absorverem essa categoria.

Pode acontecer inclusive de “System One Model”, nome criado pela TypeSafe, nunca virar uma categoria reconhecida pela indústria.

Nada disso elimina a discussão que o lançamento colocou na mesa.

Durante alguns anos nós transformamos praticamente qualquer problema envolvendo linguagem em uma chamada para uma LLM.

Funcionou porque era fácil.

O modelo entendia contexto, não exigia treinamento específico e devolvia alguma coisa útil.

Só que facilidade arquitetural não significa eficiência arquitetural.

Agora começamos a ter volume suficiente para perceber isso.

Se um agente precisa tomar 100 decisões para concluir uma tarefa, talvez não faça sentido utilizar o modelo mais poderoso disponível nas 100.

Se 90 dessas decisões são simples, previsíveis e possuem opções conhecidas, existe espaço para outra classe de modelo.

É aí que Jev fica interessante.

Não como substituto do GPT.

Não como “o fim das LLMs”.

E definitivamente não porque seja 193 vezes melhor do que qualquer coisa.

Ele é interessante porque força uma pergunta que deveríamos ter feito antes:

por que estamos usando modelos capazes de escrever livros inteiros para tomar decisões que cabem em um if?

Se a TypeSafe estiver certa, o futuro não será formado por uma IA fazendo tudo.

Será formado por várias inteligências diferentes, cada uma utilizada onde o custo, a velocidade e a capacidade realmente fazem sentido.

E, se isso acontecer, talvez o maior mérito do Jev não tenha sido construir o modelo mais inteligente.

Talvez tenha sido lembrar a indústria de que inteligência sem eficiência também é uma forma de desperdício.

Fontes e leituras

Vercel. TypeSafe AI Jev now available on AI Gateway. Acessar fonte

Vercel. AI Gateway: Jev model launch. Acessar fonte

Tom’s Hardware. Jev decision model and Pokémon Red experiment. Acessar fonte

Financial Times. TypeSafe investor interest and valuation discussion. Acessar fonte

Business Insider. Developer and investor attention around Jev. Acessar fonte

arXiv. Early review of Typed Decision Models. Acessar fonte

PriorBench / GitHub. Independent Jev benchmark and confidence tests. Acessar fonte

arXiv. Evaluation of Jev 1.13 across 37 datasets. Acessar fonte