Jev promete zero alucinações: o que isso significa na prática?

Fala aí, beleza? A TypeSafe saiu do stealth dizendo uma frase que normalmente faz qualquer dev revirar os olhos: o modelo dela não pode alucinar

Jev é o primeiro modelo da classe System One da empresa, segue em early access com lista de espera e ainda não teve data de disponibilidade geral anunciada

E aqui vai o ponto que vale o post inteiro: a promessa existe, é real, mas ela é MUITO mais estreita do que a manchete faz parecer

Bora destrinchar isso? 🙂

O que a TypeSafe está dizendo de fato

A afirmação oficial não é "o modelo sempre acerta"

A afirmação é outra: a saída do Jev fica restrita a um schema definido antes, então o modelo escolhe entre opções previamente definidas em vez de gerar texto livre

Como o schema matching é garantido, a empresa coloca 0% nos gráficos de alucinação. Sacou a jogada? O que foi eliminado é a categoria de erro em que o modelo inventa um campo, muda o nome da chave ou devolve um JSON quebrado

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Que tipo de alucinação isso mata? A de formato. A de conteúdo continua viva e passando bem

Junto disso, toda decisão vem acompanhada de uma estimativa de confiança, pra você agir quando a confiança é alta e escalar quando não é

O treino é com RLCD, justamente pra devolver decisões calibradas. A versão documentada no momento é a jev-1.13

Quem está por trás, segundo a página oficial do time: Diogo Almeida é cofundador e CEO da TypeSafe AI, ex-OpenAI e ex-Google, coinventor do RLHF e do InstructGPT. Erik Gafni é CTO e Sasha Sheng é COO

Gente que conhece o assunto de perto, o que torna a escolha de restringir a saída ainda mais interessante: é uma decisão de arquitetura, não de marketing

O que muda no seu código quando a saída não é texto livre

Se você já integrou LLM em produção, conhece a camada chata: pega a string, tenta json.loads, deu ruim, tenta limpar as crases de markdown, deu ruim de novo, retry com temperatura menor, valida com schema, e por aí vai

Essa camada some

Se a opção escolhida só pode vir de uma lista que VOCÊ definiu, não existe o cenário do modelo responder "acho que seria mais ou menos a opção B, mas depende"

Só que o trabalho não evapora, ele muda de lugar

Entra uma camada nova: decidir o que fazer com a confiança

Antes você perguntava "esse texto é parseável?". Agora a pergunta é "esse número é alto o bastante pra eu deixar o software agir sozinho nessa ação específica?"

E essa segunda pergunta é MUITO mais difícil, porque ela não é técnica, é de produto. Depende de quanto custa errar

Antecipando o erro clássico aqui: tratar a saída do Jev como se fosse verdade só porque ela veio bem formatada. Schema válido e resposta correta são coisas diferentes, e o post inteiro gira em torno disso

Confiança por primitivo: o que Choice, Score e Noul devolvem

Aqui tem uma pegadinha que pode te ferrar se você não ler a doc com atenção

Os primitivos não devolvem a mesma coisa

O confidence de Choice e Score é derivado da distribuição de probabilidades da própria resposta

Já o Noul devolve só a probabilidade de "sim", e ponto

Tome cuidado! Se o seu fluxo depende de ler confidence pra decidir entre agir e escalar, o Noul simplesmente não serve. Você vai escrever um if num campo que não existe

É o tipo de coisa que passa batido no protótipo e aparece em produção no pior horário possível 😛

Como transformar confiança em decisão no seu sistema

A documentação é bem direta sobre como usar isso, e ela NÃO entrega um número mágico pronto

1. Pense em três faixas, não em um interruptor. A doc recomenda tratar a confiança em três níveis: alta, o software age sem humano; média, você confirma, sinaliza pra revisão ou busca mais informação; baixa, não age, e aí roteia pra humano, pede esclarecimento ou usa outro sistema. O erro comum deste passo é modelar só dois estados (age ou não age) e jogar toda a zona cinzenta pra um dos lados

2. Defina o threshold POR AÇÃO, conforme a consequência do erro. A doc é explícita: o threshold não é um número único, e ações diferentes dentro do mesmo sistema devem ser travadas em níveis diferentes. Marcar um ticket como "dúvida de cobrança" e emitir um reembolso não podem ter a mesma régua. O erro comum aqui é definir uma constante global no config e usar ela no sistema inteiro

3. Escreva a bifurcação explícita no código. O exemplo que aparece na própria documentação é rotear pra revisão humana quando a confiança fica abaixo de 0.8:

# exemplo de corte citado na doc da TypeSafe
if answer.confidence < 0.8:
    enviar_para_revisao_humana(answer)
else:
    aplicar_decisao(answer)

4. Calibre o corte com os SEUS dados. A orientação é plotar confiança contra acurácia no seu próprio conjunto e achar onde o corte faz sentido pro seu caso. O erro comum deste passo é adotar o 0.8 do exemplo como se fosse lei universal: ele é ilustração, não recomendação pro seu domínio

5. Guarde a confiança junto com a decisão no seu log. Sem histórico de confidence versus resultado real, você não tem como plotar nada depois e vai ficar chutando threshold pra sempre

O que continua sendo problema mesmo com schema garantido

Um ponto que eu acho muito massa da TypeSafe: eles publicam uma página de jaggedness (irregularidade) listando onde o modelo falha. Dá pra ler a documentação de limitações da jev-1.13 e ver preto no branco

Vamos por sintoma, causa e o que fazer

Sintoma: a resposta está certa pra outra pergunta

Causa: interpretação literal. Escopo, negações e condições implícitas são lidos ao pé da letra

Solução: escrever a pergunta sem depender de subentendido. Se a condição é implícita na sua cabeça, ela precisa estar explícita no texto

Prevenção: revisar toda pergunta que tenha "não", "exceto", "apenas quando". É onde a leitura literal mais morde

Sintoma: contagem e conta batendo errado

Causa: falta de precisão numérica. A doc diz que o modelo não é calculadora e não conta de forma confiável caracteres, ocorrências ou itens de lista

Solução: conta é trabalho do seu código. Você conta, e entrega o número pronto pro modelo decidir em cima

Prevenção: nenhuma regra de negócio crítica deve depender do modelo contar alguma coisa

Sintoma: lógica de data dando resultado doido

Causa: datas são lidas como texto, não como quantidades ordenadas. Comparar datas, calcular a distância entre elas ou checar se cai numa janela é não confiável

Solução: faça o cálculo de data em código e entregue o resultado já resolvido (tipo dentro_da_janela: true) pro modelo

Prevenção: trate qualquer comparação temporal como responsabilidade sua, não dele

Sintoma: a acurácia cai quando você enche o contexto

Causa: Jev não tem conhecimento do mundo além do estado que você entrega e não consulta nada. E a doc avisa: a acurácia cai conforme o estado é enchido com material que a pergunta não precisa

Solução: mandar só o necessário. Aqui a lógica é o contrário da corrida por contexto gigante, e vale comparar com a discussão sobre janelas de contexto de 1M de tokens, onde o ganho vem de caber mais coisa. Aqui o ganho vem de caber menos

Prevenção: montar o state com curadoria, não com dump

Sintoma: usar Score pra extrair um número exato

Causa: os níveis de Score da jev-1.13 são fracos em calibração numérica

Solução: usar Score pra ordenar e graduar (isso é maior que aquilo), nunca pra reconstruir magnitude interpolando entre níveis. A doc desaconselha explicitamente

Prevenção: se você precisa de um valor exato, ele tem que vir de cálculo, não de modelo

Vale acreditar no zero alucinação?

Vale acreditar no que foi prometido, que é FORMATO

O que não vale é traduzir isso pra "não erra"

A própria documentação da TypeSafe entrega o argumento contra a leitura otimista: calibração é medida em grupos de previsões e não garante que uma resposta individual esteja correta. É propriedade estatística agregada

Ou seja, em mil decisões com confidence alto, a taxa de acerto tende a bater com o número. Naquela decisão específica que virou um reembolso indevido? Nenhuma garantia

Sobre performance, o número que circula é da própria casa: cerca de 67,8% de acurácia num benchmark interno de quatro fluxos de produção, que a empresa diz ser comparável ao GPT-5.6 Terra. É autoavaliado e ainda sem verificação de terceiros, então trate como sinal, não como prova

O resto da ficha técnica:

• Preço: US$ 0,042 por milhão de tokens de entrada (US$ 42 por bilhão), com tokens de saída gratuitos
• Latência anunciada: 70 a 500 milissegundos
• Acesso: API fechada e gerenciada, sem pesos abertos e sem opção de rodar local

Esse último item é decisivo pra quem tem restrição de dado. Se o seu cenário é aquele em que o código não pode sair da máquina, Jev está fora da conversa por definição, porque o estado que ele decide em cima é o estado que você manda pra fora

Meu veredito honesto: a promessa é legítima e resolve uma dor real de integração, mas ela foi comunicada de um jeito que convida ao mal-entendido. Zero alucinação aqui significa zero surpresa no formato da resposta, não zero erro de julgamento

Expectativa realista e próximo passo

Resumo da ópera: o Jev troca o problema de "a saída veio quebrada" pelo problema de "quanto de confiança eu exijo pra deixar isso rodar sozinho"

O segundo problema é melhor que o primeiro, mas continua sendo trabalho seu

Pra quem entrar no early access, o caminho é a API HTTP da TypeSafe, descrita na documentação da API:

POST https://api.typesafe.ai/v1/systemone

O campo model aceita o alias jev-latest, que é o modelo de referência da casa

Tem SDK oficial em Python e em JavaScript. Pela doc do SDK Python, ele exige Python 3.10 ou superior e o cliente lê a chave da variável de ambiente, chamando jev-latest por padrão:

export TYPESAFE_API_KEY="sua-chave-aqui"

E um detalhe que a doc recomenda e que muita gente vai descobrir tarde: depois que você calibrar seus thresholds de confiança contra uma versão específica, pina o ID versionado em vez de usar o alias

O jev-latest resolve pra um ID versionado, e se esse ID mudar embaixo de você, seus cortes calibrados viram chute de novo. Pinando, você migra no seu ritmo

É um cuidado bobo de implementar e que economiza uma madrugada de debug…

Até o próximo post! 😀