O que é o Jev, e o que eu aprendi construindo uma cidade inteira com ele

Semana passada, do nada, a empresa TypeSafe AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → (criada por um ex-funcionário da OpenAI que participou dos papers do InstructGPT e outros) saiu do stealth e fez bastante barulho com o lançamento do Jev. Com todo o hype, a reação da galera, como sempre, se dividiu rápido entre o pessoal do “é 100x mais rápido, 100x mais barato, não alucina” e o pessoal do “é só um BERT com marketing de 2026”. As duas coisas têm um pedaço de razão e nenhuma das duas te diz se vale a pena usar.

Se você ainda não viu o que ele é, a demo oficial é um bot jogando Doom a 10 consultas por segundo, lendo o estado do jogo como texto estruturado e não como imagem, a uns 7 dólares por hora. Beeeeem legal e impressionante:

Pra entender melhor o que o Jev é (e não é), eu passei o meu domingo construindo um projetinho: uma cidade simulada com 50 pessoas que vivem 24 horas por dia, formam casais, traem, fofocam, adoecem e morrem. Rodou 14 horas seguidas, 74 dias simulados, quase 11 mil requisições, e custou $1,05 contando os dois modelos que usei.

Mas, afinal, o que é o Jev?

A discussão toda é sobre em qual dessas três caixas o Jev cabe, e a resposta honesta é que ele não cabe direito em nenhuma. É isso que eu tento explorar no artigo abaixo.

O que ele é (e o que ele não é)

O Jev não é um LLM como o GPT, Claude ou Gemini. Ele não gera texto nenhum.

Você manda duas coisas: um estado (qualquer JSON, o que a sua aplicação souber) e um conjunto de perguntas tipadas. Ele responde todas de uma vez, numa passada paralela, e devolve valores tipados com distribuição de probabilidade.

Não tem parsing nem “por favor responda em JSON”, e ele não tem como devolver uma opção que você não ofereceu. O Jev produz todas as respostas ao mesmo tempo, porque elas não dependem umas das outras.

A TypeSafe chama isso de “System One model”, numa referência ao pensamento rápido e automático do Kahneman. Já adianto que, sim, o nome é marketeiro.

Uma coisa interessante é o custo: o modelo não é aberto, mas via API, eles cobram $0.042 por 1 milhão de tokens de entrada e ZERO pela saída (eles dizem que é tão barato que nem vale a pena cobrar). É BEEEEEM barato.

Como se usa

São só três tipos possíveis de pergunta (e combinações delas):

• Choice escolhe um rótulo de um mapa que você define:

from typesafe_sdk import Choice, TypeSafeClient

client = TypeSafeClient()
r = client.system_one(
    state={"ticket": "fui cobrado duas vezes no pedido A-104"},
    questions={
        "time": Choice(
            instructions="Qual time deve tratar isso?",
            criteria={
                "billing":   "problemas de pagamento ou assinatura",
                "technical": "bugs ou problemas de integração",
                "sales":     "dúvidas de preço ou conta",
            },
        ),
    },
)

r.answers["time"].choice         # "billing"
r.answers["time"].confidence     # 0.85
r.answers["time"].probabilities  # {"billing": 0.90, "technical": 0.07, ...}

• Score posiciona numa régua ordenada, e a resposta vem entre os níveis:

Score(
    instructions="Baseado no texto, quão irritado o cliente parece estar?",
    criteria=["calmo", "incomodado", "irritado", "furioso"],
)

# .score -> 2.4

• Noul é uma afirmação e devolve a probabilidade dela ser verdadeira:

Noul(
    instructions="O cliente está pedindo reembolso explicitamente",
    criteria={"true": "pede devolução do dinheiro",
              "false": "reclama mas não pede"},
)

# .noul -> 0.97

Pra usar, eles oferecem uma API HTTP crua ou um SDK próprio (typesafe-sdk), e por baixo são modelos pydantic. Essas classes Choice, Score e Noul que eu mostrei acima você instancia na hora da chamada, e a validação acontece na construção. Se você passar uma chave que não existe, estoura ali, não no servidor.

Os critérios são definidos por requisição. Não tem etapa de configuração nem treino.

No meu projeto da cidade, uma das perguntas é “com quem essa pessoa vai falar?”, e as opções são exatamente quem está naquela sala naquele segundo. A cada chamada é uma lista diferente. Outra pergunta remove a opção “fofocar” de quem não sabe de nenhum rumor ainda.

O projeto da cidade

Pro projetinho, eu queria alguma coisa mais criativa, em vez de só fazer um classificador de tickets. Lembrei do paper de generative agents de Stanford, que rodou 25 agentes numa cidade simulada por vários dias.

O problema lá é que, rodando cada decisão como uma completion de um LLM, ele acabava rodando devagar e caro. Se o Jev for o que ele diz ser, essa latência e custo deveriam praticamente sumir. Será?

Com a ajuda do Claudinho, construí uma cidade com 18 lugares (taverna, capela, cais, praça, mercado) e 50 pessoas. Cada uma com uma idade, ofício, dois traços de personalidade, um objetivo de vida, memória, um grafo de confiança com as outras, e às vezes um segredo (como um affair que ela estivesse tendo ou algo ruim que ela fez na cidade).

A cada segundo de tempo real o relógio da cidade avança dois minutos. As pessoas trabalham, caminham, envelhecem, adoecem, morrem. Chegam forasteiros. E quando as pessoas se juntam num lugar, o Jev decide o que acontece. Segue um vídeo do projeto final:

Mas pra rodar bem, tem alguns detalhes. O jeito ingênuo seria rodar cada requisição por agente, o que daria cinquenta pessoas e cinquenta requisições por rodada (ouch). Mas como o estado (que horas são, onde os agentes estão, quem está presente, o que acabou de acontecer ali) já é compartilhado por todo mundo naquela sala, dá pra só mandar as perguntas de todo mundo juntas de uma vez.

Assim, se tem 8 pessoas numa taverna, isso vira uma requisição pro Jev, com 64 perguntas. Cinquenta pessoas espalhadas em 18 lugares viram umas 12 cenas por rodada, não 50 requisições. Isso só funciona porque a passada é realmente paralela. O que eu medi:

O que é ótimo é que a latência não muda com o número de perguntas, então vale juntar o máximo de gente numa cena. Eu parei em 8 pessoas porque a documentação avisa que a precisão cai quando o estado incha.

Dessa forma, numa interação, o que pode rolar é que o Jev responde “Iris conversa com John, sobre uma fofoca, e sai se sentindo 0.31 atraída”, e depois disso é código determinístico Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → (pra aplicar o novo valor de confiança entre essas pessoas, o rumor se espalhando pra quem estava na sala, a atração se acumulando, e se ela cruzar um limiar com reciprocidade, nasce um casal).

O limite da conta é 1.200 requisições por minuto (ou seja, 20 por segundo), e eu achei que isso poderia ser um gargalo, mas longe disso. Com o agrupamento por sala e o teto que eu coloquei de 2 dólares por dia, eu uso 0.21 requisição por segundo, quase cem vezes abaixo do limite.

Os números finais da simulação

Rodei a simulação da cidade por ~14 horas de servidor no ar, o que deu 74 dias da cidade simulados.

Esse “LLM (narração)” foi só um GPT-4.1-nano sem thinking que eu deixei rodando pra traduzir melhor cada ação e consequência. Isso daria $1,72 por dia se deixar rodando. A latência p50 ficou entre 289 e 363 ms ao longo das 12 horas que eu monitorei, com mediana de 315 ms.

Como o Jev só cobra a entrada e a saída é de graça, os 22,7 milhões de tokens são todos do que eu mandei pra ele. E dentro do que eu mando, o que pesa é mais os critérios do que os estados. Por exemplo, numa requisição de 8 pessoas, o estado dá 689 tokens (17%) e as perguntas 3.321 (83%), porque as descrições das opções se repetem uma vez por pessoa.

De onde vem a probabilidade do Jev

O que a TypeSafe diz é que o Jev é treinado com RLCD, sigla de “Reinforcement Learning for Calibrated Decisions”. Enquanto o RLHF treina o modelo pra dar respostas que avaliadores humanos aprovam, o RLCD treinaria pra que a probabilidade corresponda à frequência real de acerto. Ou seja: entre todas as respostas que ele dá com 90% de probabilidade, cerca de 90% deveriam estar certas.

Isso é diferente de um LLM e diferente de um classificador comum. Um LLM te dá logprobs de tokens, e dá pra extrair deles algo parecido com confiança. A TypeSafe argumenta que, mesmo quando você pede uma estimativa de confiança, os LLMs tendem a ser confiantes demais e inconsistentes. Já um classificador treinado costuma ter probabilidades razoáveis pras classes em que foi treinado, e dá pra calibrar com temperature scaling em cima de um conjunto de validação. O que ele não faz é dar probabilidade calibrada pra classes que você inventou agora.

Na prática isso é o que permite usar a confiança como regra de negócio. No meu projeto, uma briga só acontece acima de 0.45 de confiança, senão vira mal-estar. Só faz sentido se o número significar alguma coisa.

Porém, a TypeSafe descreveu o que o RLCD deveria fazer sem realmente abrir o modelo ou publicar o suficiente pra alguém avaliar o algoritmo. Você tem que confiar, ou medir você mesmo nos seus próprios exemplos.

Na minha cidade eu não consigo medir isso, porque pra calibrar, você precisa comparar a probabilidade com a frequência de acerto, e pra isso você precisa saber qual era a resposta certa. Não tem resposta certa no meu caso de saber se a Iris deveria ter conversado com o John ou não.

Quem mediu de verdade foi o decision-model-benchmark, que colocou o Jev contra oito LLMs e três baselines, com gabarito e com os dados brutos publicados. Na tabela de calibragem dele, o Jev aparece como o pior dos modelos em duas baterias.

Eu baixei os dados brutos e recalculei tudo com a própria função de ECE deles. Reproduzi a tabela publicada exatamente, o que quer dizer que a conta está certa, e a história se divide em duas.

Na bateria de spam, que é binária, o número ruim vem de ler o campo errado. O adaptador do benchmark usa confidence como se fosse a probabilidade de acerto, mas não é: é a probabilidade da opção escolhida reescalada pra que um chute ao acaso dê 0 e a certeza dê 1 (no exemplo lá do começo, 0,90 vira 0,85), e com duas opções essa diferença pesa muito. Recalculando com a probabilidade da opção escolhida, o ECE do Jev cai de 0,249 pra 0,090, e ele sai de último pra terceiro melhor entre os nove modelos, na frente do Claude Haiku e do Claude Sonnet. Nas baterias de 77 opções a troca quase não muda nada, porque com muitas opções os dois números quase coincidem.

Na bateria que testa se o modelo admite que não sabe, o número ruim é real, e o campo certo deixa ele pior. Os itens dessa bateria são montados pra não ter resposta: ou a opção correta nem está na lista, ou nada no texto permite decidir. O comportamento honesto é confiança baixa. Usando a probabilidade, o ECE do Jev vai de 0,246 pra 0,347. Quando nenhuma das opções estava certa, ele colocou 90% ou mais numa opção errada em 59 de 300 casos. Os LLMs do mesmo estudo admitiram que não sabiam entre 65% e 100% das vezes. O Jev, entre 35% e 50%, dependendo do campo que você lê.

Juntando as duas coisas: nas perguntas que têm resposta, a probabilidade do Jev é razoavelmente calibrada. Quando não existe informação nenhuma, ele não percebe, escolhe uma opção e às vezes escolhe com convicção. Pro tipo de uso que eu defendo neste post isso importa, e eu volto a esse ponto na conclusão.

E a arquitetura? Usa embeddings?

Resposta curta: ninguém de fora sabe. O que está publicado é que ele não é autoregressivo, que avalia as perguntas de forma independente e em paralelo (uma resposta não vira contexto da outra), e que o treino é RLCD, só isso. Não tem paper, não tem detalhe de arquitetura, não diz se é encoder ou decoder, não diz como as respostas são lidas do modelo.

Tem um projeto tentando reconstruir a ideia em cima de um Qwen3.5 de 0.8B, com uma arquitetura de “prefix-fork” que avalia várias perguntas contra um estado compartilhado numa passada. Mas os próprios autores são explícitos que é engenharia reversa a partir de hipótese, porque “a TypeSafe não publicou a arquitetura do Jev”.

O palpite mais bem fundamentado que eu vi é do Sebastian Raschka, PhD, e ele fez questão de dizer que é só um palpite. A aposta dele é um modelo pequeno no estilo encoder, tipo ModernBERT, treinado com algo parecido com o RLCR, um método do paper Beyond Binary Rewards que soma à recompensa de acerto um termo que pune a confiança mal calibrada. Vem de alguém que treina esse tipo de modelo há anos, é plausível, mas continua sendo “só” uma hipótese.

Tem outro bem parecido que dizem que fizeram o Jev antes do Jev, e perderam a briga do marketing. O Laya, da ConvAI Innovations, é um ModernBERT de 421M com os mesmos três tipos de pergunta do Jev, pesos abertos em Apache 2.0, rodando local. É a reimplementação aberta mais completa que eu encontrei e mostra que dá pra montar algo com o formato do Jev em cima de um encoder (mas claro, não mostra que o Jev é isso).

Serve pro meu caso? Depende…

Avaliar rubricas em treino de RL

Acho que sim, e é provavelmente um dos melhores encaixes que existem pra ele, com uma ressalva. O formato bate, ou seja, você tem um critério, quer uma nota ou um booleano, precisa disso em volume enorme e barato, e quer a probabilidade pra ponderar em vez de só o rótulo. A ressalva é que o item da rubrica precisa ser atômico. O Jev lê ao pé da letra, e a própria página de pontos fracos do modelo avisa que negações e condições implícitas são lidas literalmente e que raciocínio de múltiplos passos custa precisão. “Esta resposta está correta e bem escrita” vai dar ruim. “Esta resposta contém a fórmula pedida” vai bem.

Comparando: um LLM como juiz aguenta rubricas mais complexas, mas custa beeem mais. Um classificador treinado é mais barato ainda, mas você precisa de dados rotulados por rubrica, e rubrica muda o tempo todo.

Se eu fosse montar um pipeline de RLVR hoje, testaria o Jev pros itens verificáveis e objetivos, e deixaria o LLM pros que exigem julgamento composto.

Rodar num pipeline junto com um SLM

A pergunta que eu vi muita gente fazendo foi: “usar o Jev ou um SLM?”. A documentação da própria TypeSafe propõe usar “Jev + SLM”, e acho que pode fazer sentido em alguns casos:

1. Extrair com um modelo pequeno e barato
2. Verificar com o Jev, com perguntas específicas pra cada campo, e devolver a probabilidade de cada um estar errado
3. Escalar pra um modelo mais poderoso (e mais caro) só os campos onde a verificação apontar alguma coisa

O resultado que eles publicam em 100 prompts é ficar com quase toda a qualidade do modelo top, mas com um custo (computacional e financeiro) bem menor.

Eles deram um caso de uso de raspagem de dados da internet, de achar numa página da NYU a data de abertura das matrículas do semestre de outono de 2024-2025, devolvendo dois campos, a data e uma descrição. O detalhe é que a página não tem essa informação.

O modelo pequeno (gpt-5.4-mini) devolve isso:

{
    "registration_open_date": "",
    "description": "Registration opens for the fall semester"
}

A data veio vazia, que é o certo. Mas a descrição é inventada, e ele parece ter copiado o texto de exemplo que estava na documentação daquele campo no schema. A saída é válida no tipo, mas é falsa, que é o problema do “não alucina” que eu comento mais adiante.

Aí entra o Jev, com uma bateria de Noul por campo, onde true significa “tem alguma coisa errada aqui”:

• hallucinated: o valor extraído não tem apoio no texto de origem?
• off_target: a origem não reporta de verdade a coisa que o campo descreve, e o valor foi puxado de texto incidental?
• absence_wrong: o campo veio vazio, e a origem contém algo que torna esse vazio errado?

E as respostas:

description::hallucinated                 0,95      # dispara
description::off_target                   0,85      # dispara
description::unreasonable                 0,58
registration_open_date::absence_wrong     0,14

Eles colocaram que qualquer métrica acima de 0.7 dispara. Duas passaram, então a extração vai pra um modelo mais poderoso, como o gpt-5.5 com esforço alto, que devolve os dois campos vazios, que é a resposta correta. Repare que ele não disse só “isso está errado”: deu 0,95 pra alucinação e 0,14 pro campo vazio, ou seja, separou qual dos dois campos era o problema.

Na conta deles, o modelo de raciocínio sai a uns $0,10 por extração e o pequeno a uns $0,001. O Jev cobra $0,042 por 1 milhão de tokens de entrada, então você teria que mandar 2,4 milhões de tokens de verificação pra gastar o que custa uma única chamada ao modelo caro.

Lendo isso, o Jev deixa de ser concorrente do SLM e passa a ser uma peça num pipeline que torna o SLM mais útil pra vários casos de uso.

Eles também dão o exemplo de usar como guardrail num pipeline, ou seja, colocar o Jev como camada de triagem na entrada e na saída de um LLM, com todas as perguntas de risco numa requisição só, em vez de um segundo LLM vigiando o primeiro.

Se eu tivesse que apontar o encaixe mais forte do Jev hoje, seria esse. Não substituir modelo nenhum, e sim ser o juiz barato entre modelos.

Robótica

Não sei dizer porque não é exatamente a minha área, mas acredito que por não rodar localmente, perde a grande vantagem. Porém, além do exemplo do Doom, outras coisas bem divertidas apareceram nas redes, como o Jev jogando Minecraft e usando o sistema de direção automática da Tesla:

As críticas

Eu concordo com várias delas, pelo menos em parte.

“O Jev é só um classificador”

Essa é a crítica mais repetida, e ela está certa sobre o mecanismo: toda resposta é uma seleção de uma lista. Se as suas classes são fixas e você tem dados rotulados, daria, sim, pra simplesmente usar um classificador como um DeBERTa, porque vai sair mais barato e você fica com os pesos.

O porém, que é algo que o Sebastian Raschka também mencionou no post dele, é que um classificador encoder comum é um modelo de propósito único, específico. Você geralmente treina um pra análise de spam, outro pra sentimento, outro pra roteamento de tickets, etc.

Já o Jev é bem mais generalista. A mesma chamada classifica e-mail, joga Doom e, no meu caso, decide o que uma pessoa faz numa taverna. Na cidade simulada, as opções de com quem conversar mudam a cada chamada, e não tinha conjunto de treino pra isso, ele funcionou do zero.

A aposta do Raschka é que o segredo está mais nos dados do que no algoritmo de treino, com um bom design de API por cima. Ele compara com o ChatGPT de 2022, que era uma versão melhorada do InstructGPT, onde o que fez diferença foram os dados.

“Um SLM de 200M de parâmetros faria o que o Jev faz”

Essa é outra crítica que vi bastante.

O meu amigo Luciano Martins da Google DeepMind (que está no time dos que acham o Jev um classificador com marketing) testou uma versão dessa crítica, e o experimento dele vale ser contado inteiro.

Ele pegou o Gemma-3-1b, um modelo de 1 bilhão de parâmetros, e fez com ele o que o Jev faz: montou o prompt com o contexto, a pergunta e as opções, rodou uma única passada, olhou só os logits das palavras permitidas e aplicou softmax neles. Assim o modelo não tem como responder fora da lista. Rodou em 50 perguntas de classificação de oito tipos (churn, sentimento, departamento de suporte, prioridade, spam, moderação, tópico e inferência lógica) e acertou 43.

O ponto dele está certo, e é o mais importante do experimento: a garantia de saída tipada não é mágica. Um modelo pequeno com umas quinze linhas de código entrega a mesma garantia de nunca responder fora do schema.

Eu rodei as mesmas 50 perguntas no Jev, com os mesmos gabaritos. Ele acertou todas as 50, inclusive quando recebeu só as palavras das opções, sem nenhuma descrição, que é exatamente o que o Gemma recebeu. Com as 50 perguntas numa requisição só, também acertou todas, gastando 65% menos tokens do que mandando uma por vez. O teste inteiro custou menos de um centavo.

Os sete erros do Gemma ficaram em duas tarefas. Dois foram em departamento, dois tickets sobre a conta que ele mandou um pro time técnico e outro pra vendas. Cinco foram em prioridade, todos errando por exatamente um nível (e ele nunca respondeu Low, nem pra um erro de digitação no rodapé do site).

Comparar logits crus de palavras diferentes favorece as palavras mais comuns, um viés descrito no paper Calibrate Before Use, que também propõe uma correção barata chamada calibragem contextual. Eu reproduzi o método do Luciano, com as minhas predições batendo com as dele nas 50 perguntas, e apliquei a correção. A tarefa de prioridade foi de 1 pra 4 acertos em 6, o que confirma o diagnóstico. Só que a mesma correção custou um acerto em sentimento e outro em moderação, e o total foi de 43 só pra 44. Dar a ele descrições das opções, que é o que a API do Jev pede, piorou o Gemma.

Ou seja, a distância em acurácia sobrevive às correções conhecidas. Mas a diferença maior está no número que o notebook calcula e depois descarta: a probabilidade.

A do Gemma quase não carrega informação. Nas 50 perguntas, ele deu em média 0,96 de probabilidade pra resposta escolhida, acertando 86%, e quando errava ainda dava 0,90. Pra olhar isso de perto, eu escrevi 14 frases novas, 8 pensadas pra não terem uma decisão possível e 6 pra serem óbvias, e mandei pros dois sem dizer qual era qual. Comparando a probabilidade da opção escolhida nos dois modelos, o Jev deu 1,00 nas óbvias e 0,82 em média nas ambíguas. O Gemma deu 1,00 e 0,93, e depois da calibragem contextual a diferença entre os dois grupos praticamente sumiu.

Dois exemplos resumem bem. Pra frase “It works, I suppose.”, o Gemma respondeu Positive com 1,00. O Jev respondeu Negative com 0,59 e Neutral com 0,40, que é honestamente o que essa frase é. E pra frase “All production databases are unreachable and every customer is offline.”, que era uma das óbvias, o Gemma respondeu “High” com 1,00. A resposta certa é Critical, e ele errou sem nenhum sinal de dúvida.

Isso casa com o benchmark independente lá de cima: a probabilidade do Jev acompanha o quanto a pergunta é ambígua. O que ela não detecta é a falta total de informação.

Os limites desse teste também precisam ser ditos. São 50 perguntas sintéticas, várias fáceis demais, e o Jev bateu no teto de 100%, então o teste não mede o quanto ele é melhor. É um modelo de 1B contra um de tamanho não divulgado. Latência também é difícil comparar, porque o Jev fica na casa dos 300 ms (mas via API saindo do Brasil), e o Gemma de 1B depende da GPU que você tiver rodando local. E o Gemma continua tendo uma coisa que o Jev não tem: roda local, sem depender de rede, com custo marginal zero depois que você tem a GPU.

“O Jev não alucina”

Não é bem assim. É verdade que o Jev não pode devolver um valor fora do schema. Mas ele pode estar completamente errado dentro do schema, e esteve em vários casos que eu testei, alguns que eu já mostrei acima.

Então, torcedores calma.

Conclusão

O Jev é uma peça com um formato de saída específico que resolve bem um problema específico: decisão tipada, com probabilidade, sobre estado que você monta em runtime, barata o suficiente pra rodar num laço. A probabilidade se sustenta quando a pergunta tem resposta e falha quando não tem, porque ele não percebe a ausência de informação.

Se o seu problema é esse, ele é muito bom nesse contexto mais generalista. Já se as suas classes são fixas e você tem dados, treine um classificador. Se você precisa que o modelo escreva alguma coisa, use um SLM ou LLM.

E a pergunta “Jev ou um modelo pequeno?” provavelmente está mal formulada. O uso mais forte que eu vi pra ele não é substituir modelo nenhum, é funcionar dentro de um pipeline com um modelo menor e mais barato, verificando o que um modelo pequeno extraiu ou decidindo o que um modelo pequeno depois vai escrever, como na minha cidade.

O código está aberto em github.com/fabriciocarraro/smallville-247, com os scripts de medição que produziram os números da cidade.