Jev ou embeddings: quando a similaridade não é suficiente para classificar?

Fala aí, beleza? Sua busca vetorial acha o documento mais parecido, e aí você percebe que "parecido" não é a mesma coisa que "é isso mesmo"

É um problema clássico de quem monta pipeline de classificação com embeddings: o vetor mede proximidade semântica, não critério de negócio

Se a sua regra é "ticket de cobrança duplicada vai pro time financeiro, mas só se o cliente for enterprise", nenhum cosseno vai te entregar isso, porque essa regra não está escrita no texto do ticket

É aí que entra a outra abordagem: o Jev, primeiro modelo público da TypeSafe AI, que estreia a categoria dos System One models. Ele não gera prosa, não escreve código e não mantém conversa: ele recebe um state, recebe perguntas tipadas e devolve dados estruturados com confiança

Segundo o anúncio da própria TypeSafe, a categoria e o modelo foram apresentados em 15/09/2026, quando a empresa saiu do stealth (e, pela página de time da TypeSafe, ela foi fundada em 2024 em San Francisco por Diogo Almeida, Erik Gafni e Sasha Sheng)

Bora comparar as duas camadas de verdade, sem fanatismo? 🙂

Jev x embeddings: comparativo lado a lado

Antes da tabela, uma coisa precisa ficar clara: embeddings e Jev não competem pelo mesmo lugar na arquitetura

Embedding é recuperação: ele pega um corpus gigante e reduz o espaço de busca

Jev é decisão: ele pega um state pequeno e responde perguntas fechadas sobre ele

A tabela abaixo usa o text-embedding-3-small da OpenAI como referência do lado da similaridade e o jev-1.13 do lado da decisão tipada

Repara no detalhe do custo: a diferença por milhão de tokens de entrada é pequena em valor absoluto, mas o volume é que muda tudo

No embedding você paga a indexação uma vez por documento e depois só paga a consulta

No Jev você paga toda vez que faz uma pergunta sobre um state, e o state inteiro entra como entrada

Por isso jogar Jev em cima de 3 milhões de documentos é economicamente burro, e jogar Jev em cima de 30 candidatos já filtrados é barato demais pra não testar

E aquela coisa de perguntar várias coisas de uma vez?

Esse é o truque que muda a conta

Perguntas sobre o mesmo state são avaliadas de forma independente e em paralelo, na mesma chamada. A TypeSafe chama isso de speculative fan-out

Em um cookbook da própria empresa, 13 perguntas em uma única chamada saíram 12,2x mais baratas e 10x mais rápidas que 13 chamadas sequenciais

Ou seja: se você vai classificar um ticket em categoria, urgência, idioma e risco de churn, não faz 4 requisições, faz 1 com 4 perguntas

Modelo maior de embedding resolve?

Parcialmente

O text-embedding-3-large gera vetores de 3072 dimensões e marca 64,6% no MTEB, então ele recupera melhor

Mas melhor recuperação continua sendo recuperação. Se o seu critério de decisão não está expresso no texto do documento, nenhuma dimensão a mais vai adivinhar ele

Quando escolher cada um: 5 cenários de classificação e roteamento

Pra ficar prático, cinco situações reais e um veredito curto em cada uma

1. Busca semântica em base grande

Você tem dezenas de milhares de documentos e precisa achar os relevantes pra uma consulta

Aqui não tem discussão: embedding sozinho

Os vetores já vêm normalizados pra comprimento 1, então o cosseno sai direto, e você paga a indexação uma vez por documento

Veredito: embeddings. Rodar decisão tipada em cima do corpus inteiro é desperdício puro

2. Roteamento de ticket por política interna

Agora o jogo vira

O critério não está no texto do ticket, está na sua política: quem atende o quê, em qual fila, sob qual condição

Esse é o caso do Choice: você monta o conjunto de destinos e o modelo devolve uma chave, uma probabilidade por opção e um score de confiança

O Choice aceita até 255 opções, o que cobre a maioria das árvores de roteamento. Quando a lista de destinos estoura esse teto, dá pra quebrar a decisão em etapas em vez de forçar tudo numa pergunta só

E como o Choice retorna confiança, o seu código decide o que fazer: acima do limiar roteia sozinho, abaixo manda pra fila humana

Já que estamos falando de decisão em tempo real, vale pensar antes no caminho quando a resposta não chega, porque 429 existe e a sua fila não pode parar por causa disso

Veredito: Jev com Choice. Embedding aqui só te daria "esse ticket parece com aquele outro", e parecer não é política

3. Moderação com limiar de risco

Pergunta fechada, sim ou não: esse conteúdo viola a regra X?

Esse é o Noul, que devolve a probabilidade de uma proposição ser verdadeira. Repara que o Noul não tem campo de confiança separado, porque a própria probabilidade já descreve a incerteza

Aí você escolhe onde corta: 0,95 bloqueia, entre 0,6 e 0,95 manda pra revisão, abaixo disso passa

Tome cuidado com um detalhe: a documentação é explícita em dizer que a resposta do Jev não substitui checagens determinísticas, permissões, orçamentos nem aprovação humana

Se existe regra dura (usuário banido, domínio bloqueado), isso é if, não é modelo

Veredito: Jev com Noul, com regra determinística antes

4. Avaliação de qualidade por rubrica

Você quer nota, não etiqueta: quão completa está essa resposta? quão bem escrito está esse resumo?

O Score existe exatamente pra isso: posição em uma rubrica descrita em palavras, de 2 a 10 níveis, incluindo posições fracionárias entre eles

E ele também retorna confiança, então dá pra separar "nota 3 com certeza" de "nota 3, mas o modelo está em cima do muro"

Veredito: Jev com Score. Embedding não tem como te dar gradação de qualidade, ele só mede proximidade

5. Ranqueamento de alta precisão (as duas juntas)

Esse é o cenário onde a resposta pra "Jev ou embeddings" é: os dois, nessa ordem

A própria documentação da TypeSafe posiciona o Jev como complemento em pipelines de busca. A busca rápida produz a shortlist, e o re-ranking coloca essa shortlist em melhor ordem, pontuando cada par consulta + candidato

No cookbook oficial de re-ranking eles usaram o dataset jurídico CLERC, com 3.565 trechos de decisões judiciais e 40 consultas

A shortlist veio de BM25, com 30 candidatos por consulta, uma pergunta por par, totalizando 1.200 chamadas independentes

O resultado: top-1 subiu de 5% para 18% e top-10 subiu de 38% para 62%

Um porém honesto: essa shortlist é lexical (BM25), então eu não vou afirmar que o mesmo ganho se repete numa shortlist vetorial. A mecânica é a mesma, o número não é transferível

Veredito: embeddings recuperam, Jev reordena. É a combinação com melhor relação custo x precisão das cinco

Como começar sem reescrever o pipeline

A boa notícia é que dá pra plugar por cima do que você já tem, sem mexer na busca

1. Instale o SDK oficial da TypeSafe na linguagem que você já usa

# Python (requer 3.10+)
uv add typesafe-sdk
# ou
pip install typesafe-sdk

# JavaScript / TypeScript (requer Node.js 20+)
npm install @typesafe-ai/sdk

2. Crie a conta no console e gere a chave na seção API Keys

Não tem mais lista de espera: o cadastro é aberto em console.typesafe.ai

O erro comum aqui é esquecer de exportar a variável de ambiente. Os dois SDKs leem TYPESAFE_API_KEY do ambiente e usam jev-latest por padrão (hoje o alias aponta pra versão jev-1.13.0)

3. Monte a requisição contra o endpoint único da API System One

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "...aqui vai o texto do candidato ou do ticket...",
    "model": "jev-latest",
    "questions": {
      "...": "...suas perguntas tipadas: Noul, Choice ou Score..."
    }
  }'

4. Respeite o orçamento de contexto

State e todas as perguntas compartilham cerca de 64.000 tokens por requisição, e o state mais a maior pergunta isolada precisam caber em cerca de 32.000

O erro comum deste passo é empurrar o documento inteiro como state quando um trecho já resolve. Contexto inflado é conta inflada, já que a cobrança é toda no token de entrada

5. Se você não quer gerenciar mais uma chave, dá pra entrar por outra porta: o Jev está disponível no Vercel AI Gateway e listado na Cloudflare como typesafe/jev

Vídeo: como manter a IA sob controle no fluxo de desenvolvimento

Pra começar do zero na disciplina de usar IA dentro do seu fluxo sem quebrar nada, este vídeo do canal mostra o conceito de loop engineering aplicado ao dia a dia de desenvolvimento

Veredito: similaridade recupera, decisão tipada classifica

A pergunta "Jev ou embeddings" está mal formulada na maioria das vezes que aparece, e tudo bem, eu entendo o porquê: as duas coisas tocam texto e devolvem algo numérico

Mas o papel delas é diferente

Embeddings ganham em custo bruto e escala de recuperação. US$ 0,02 por milhão de tokens de entrada, mais 50% de desconto na Batch API, e uma indexação que você paga uma vez por documento. Pra reduzir um corpus gigante a 20 ou 30 candidatos, não tem discussão

Jev ganha quando o critério de decisão não está expresso no texto e quando você precisa de confiança acionável. Cosseno não te dá limiar interpretável, e a calibração via RLCD existe justamente pra que 0,9 signifique alguma coisa em agregado

E tem os limites, que a própria documentação lista sem enfeite: o Jev não gera texto, não escreve código, não mantém conversa, não substitui regra determinística nem um classificador treinado nos seus dados rotulados

Contar, comparar números e ordenar datas são fraquezas documentadas dele. Se a sua "classificação" na verdade é aritmética, isso é código, não modelo

Ele também não é substituto direto do LLM por trás de Claude Code, Cursor, opencode ou Copilot. O que ele é candidato a substituir são as pequenas decisões ao redor: classificar, ranquear, julgar, rotear

Última coisa, e essa é importante: aqueles números de 193x mais rápido e 445x mais barato que modelos de fronteira, que circularam bastante, são benchmark da própria TypeSafe, não auditoria independente

É claim de fornecedor. Trate como marketing até alguém de fora reproduzir, beleza?

Conclusão

Embeddings são a camada que reduz o espaço de busca, e fazem isso barato e em escala

Jev é a camada que toma a decisão tipada em cima do que sobrou, com Noul, Choice ou Score, e devolve confiança que o seu código consegue usar pra escolher entre agir sozinho ou chamar um humano

No mesmo pipeline, um não briga com o outro: a similaridade recupera, a decisão tipada classifica

O próximo passo é chato e é o certo: meça a precisão atual do top-1 da sua busca hoje, do jeito que ela está

Depois plugue uma pergunta tipada em cima da shortlist que ela já produz, meça de novo e compare antes de trocar qualquer coisa de lugar

Sem baseline, você não está avaliando modelo, está apostando 😛

Boa leitura e até o próximo post!