Como usar o Jev para triar candidaturas sem transformar a triagem em caixa-preta?

Trocar uma triagem opaca de currículos por outra caixa-preta, só que mais rápida, é o pior negócio possível

O Jev é o primeiro modelo da classe que a TypeSafe AI chama de System One models: ele recebe um estado não estruturado e devolve respostas tipadas com probabilidades, em vez de gerar texto. Ele foi apresentado em 15 de setembro de 2026 em early access, junto do anúncio de uma rodada seed de US$ 40 milhões liderada pela DCVC

O detalhe que muda tudo no RH: como o Jev não gera string, ele também não devolve justificativa escrita junto da resposta. Ou seja, a explicabilidade não vem do modelo, vem do SEU desenho de perguntas

Então a pergunta deste post é essa: como montar uma triagem que devolve aderência a requisitos objetivos e confiança, e não um número mágico sobre a pessoa? Bora ver na prática?

O que você precisa antes de começar

Primeiro o acesso, que hoje é o ponto chato. O cadastro direto abriu para todo mundo em 20/09/2026 no console, com US$ 5 de crédito inicial (estimados pela própria empresa em cerca de 120 milhões de tokens de input), mas em 22/09/2026 a TypeSafe pausou novos signups por causa da demanda

A empresa afirma que as contas existentes seguem funcionando e que trabalha para reabrir

Se você não tem conta direta, existe caminho por gateway de terceiros:

• Cloudflare Workers AI, com o identificador typesafe/jev
• Vercel AI Gateway
• OpenRouter, com typesafe/jev-1.13

Do lado do código, o SDK Python exige Python 3.10 ou superior e sai do índice da própria TypeSafe:

pip install ipython "typesafe-sdk>=0.5.7" cooksafe --extra-index-url https://pypi.typesafe.ai/

O client Python lê a variável de ambiente TYPESAFE_API_KEY e chama jev-latest por padrão. No JavaScript, o pacote é @typesafe-ai/sdk

O endpoint é um só: POST https://api.typesafe.ai/v1/systemone, com header Authorization: Bearer <API_KEY> e Content-Type: application/json

E se quiser conferir quais nomes a sua conta pode mandar no campo model, tem o GET /v1/models, que traz descrição e data de lançamento de cada um:

curl https://api.typesafe.ai/v1/models \
  -H "Authorization: Bearer $TYPESAFE_API_KEY"

A versão documentada é a jev-1.13, jev-preview aponta para o mesmo modelo de jev-latest e IDs versionados tipo jev-1.13.0 também são aceitos

Agora o pré-requisito que ninguém gosta de ouvir, e que é o mais importante: ter os critérios da vaga escritos ANTES de escrever qualquer pergunta

Se o critério não existe em texto, a pergunta que você vai mandar pro modelo vira achismo com cara de API 🙂

Passo a passo: desenhando a triagem auditável

1. Traduza cada requisito da vaga em uma pergunta explícita e ligada à vaga

Tem três primitivas e elas podem ser misturadas no mesmo request:

Requisito formal ("o material apresenta experiência profissional com Python") é Noul. Evidência de competência ("quanta evidência de liderança técnica o material apresenta") é Score com levels

O erro comum deste passo: escrever pergunta com dupla negativa, escopo vago ou condição implícita. A própria doc de limites do jev-1.13 avisa que o modelo responde a pergunta que você escreveu, não a que você quis dizer: palavras de escopo e negações são lidas literalmente, e instruções com dupla negativa ou indireção complexa saem com menos confiabilidade

2. Monte o state só com o que a decisão precisa

O state é o conteúdo que você pede pro modelo avaliar, e vai no campo state do request junto com as questions

O erro comum deste passo: jogar o PDF inteiro, carta de apresentação, anexos e o histórico do ATS lá dentro. A TypeSafe documenta que a acurácia do jev-1.13 cai conforme o state cresce com conteúdo não relacionado à decisão, porque detalhe irrelevante age como distrator

E tem o efeito colateral que dói depois: com um state gigante fica MUITO mais difícil identificar qual pedaço da entrada produziu uma resposta errada. Lá se vai a auditabilidade

3. Mande todas as perguntas num único request

As perguntas são avaliadas em paralelo e isoladamente contra o mesmo state, numa chamada só, e adicionar pergunta quase não muda o tempo de resposta

import os
import requests

API_KEY = os.environ["TYPESAFE_API_KEY"]

payload = {
    "model": "jev-latest",
    "state": state_da_candidatura,   # só o material ligado aos critérios da vaga
    "questions": questions,          # Noul + Score + Choice na mesma chamada
}

resp = requests.post(
    "https://api.typesafe.ai/v1/systemone",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json=payload,
    timeout=30,
)
resp.raise_for_status()
data = resp.json()

No JavaScript o SDK resolve o transporte:

import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const resultado = await client.systemOne({
  state: candidatura,
  questions: perguntas,
});

O formato exato de cada pergunta muda conforme a primitiva, então confira o shape na documentação de primitivas antes de sair montando o payload na mão

O erro comum deste passo: disparar uma chamada por pergunta. Além de jogar fora o paralelismo, você paga o mesmo state de novo a cada request, e a cobrança do Jev é por token de entrada (US$ 0,042 por 1 milhão de tokens de input, com tokens de saída gratuitos). O contexto é de até 64K tokens, com até 1K tokens de saída por resposta

Se você for rodar lote grande, se liga: os rate limits são medidos em tokens por segundo e requests por minuto, e passar de qualquer um deles devolve 429 Too Many Requests. Backoff e fila, sempre

4. Leia probabilities e confidence por dimensão, não um número só

Aqui mora a diferença entre triagem auditável e caixa-preta

A propriedade confidence colapsa a distribuição de probabilidades num único valor de 0 a 1, justamente pra você aplicar threshold sem fazer a matemática na mão. Distribuição concentrada indica resposta confiante, distribuição espalhada indica resposta incerta

Guarde isso por pergunta. "Requisito X: 0.91 de confiança" é uma frase que um recrutador consegue contestar. "Nota 7.4" não é

5. Componha a nota com pesos no SEU código

O padrão Composite scoring recomenda quebrar um julgamento complexo em uma pergunta Score por dimensão e combinar os resultados com pesos controlados na aplicação, sem perder a nuance de cada score individual

O exemplo da própria doc:

nota = 0.6 * 0.62 + 0.3 * 0.64 + 0.1 * 1.0   # 0.664

O erro comum deste passo: deixar o peso implícito dentro da pergunta, escrevendo coisas como "considerando principalmente a experiência". Aí o peso vira opinião do modelo e some do seu log. Peso é política de contratação, e política de contratação tem que estar versionada no repositório, não escondida numa string

6. Roteamento por confiança, com threshold por risco

O padrão de confidence-gated routing deixa o código tomar caminhos diferentes pra resposta confiante e pra resposta incerta, escalando o caso duvidoso pra uma pessoa ou pra um modelo de raciocínio mais caro. E isso é lógica de aplicação sobre as probabilidades retornadas, sem nova pergunta nem segunda chamada de API

MIN_CONFIANCA = 0.8   # threshold seu, calibrado nos seus dados

incertas = [q for q in respostas if q["confidence"] < MIN_CONFIANCA]

if incertas:
    encaminhar_para_recrutador(candidatura, incertas)
else:
    seguir_fluxo(candidatura, nota)

A doc orienta testar thresholds plotando confidence contra acurácia nos seus próprios dados, e diz que o threshold pra agir sem confirmação é maior em operação destrutiva do que em leitura. O piso de 0.5 captura o que o modelo reporta como genuinamente incerto

O erro comum deste passo: usar o mesmo threshold pra "marcar uma tag no perfil" e pra "mover pra reprovado". Não é o mesmo risco, não pode ser o mesmo número

7. Registre pergunta, state usado e probabilidades

Como o modelo não devolve justificativa escrita, o log é a sua trilha. Guarde o texto exato da pergunta, a versão do modelo, o state enviado (ou um hash dele mais a referência do documento), o valor retornado, as probabilities e o confidence

Seis meses depois, quando alguém perguntar por que o candidato caiu na etapa 1, essa tabela é a única resposta possível

Se o seu caso de uso é mais roteamento do que nota, o mesmo desenho aparece na triagem e roteamento de tickets, com a mesma lógica de confiança na porta

O que perguntar ao Jev (e o que deixar de fora do state)

Perguntas que funcionam bem porque são verificáveis no material enviado:

• Requisito verificável: "o material apresenta experiência profissional com a tecnologia X" (Noul)
• Evidência de competência exigida: "quanta evidência de experiência liderando projetos o material apresenta" (Score com levels descritos por você)
• Aderência a critério explícito da vaga: "em qual faixa de senioridade descrita na vaga o material se encaixa melhor" (Choice, com as faixas que a vaga já define)

O mapa oficial de casos de uso da TypeSafe já cita avaliar currículos, candidaturas e feedback de entrevista contra critérios explícitos e ligados à vaga, identificando experiência relevante e pontuando evidência para competências exigidas, com roteamento pra recrutador ou gestor e casos incertos escalados pra revisão humana

Agora o que NÃO entra:

• Dados sensíveis e atributos pessoais que não têm relação com os requisitos da vaga. Fora do state, ponto
• Qualquer pergunta que peça um veredito sobre a pessoa ("esse candidato é bom?", "ele se encaixa na cultura?"). Isso não é requisito objetivo, é opinião fantasiada de score
• Tarefas que a própria doc de limites diz que o modelo não faz bem: contar caracteres, ocorrências de um termo ou itens de uma lista longa, e raciocínio com múltiplos saltos encadeados

Aquela pergunta clássica de RH "quantos anos de experiência ele tem?" cai exatamente no buraco da contagem. Se o dado precisa ser contado, conte no seu código e mande o resultado pronto no state

Quando a triagem começa a virar caixa-preta de novo

Sintoma: candidatos parecidos recebem respostas inconsistentes

Causa provável: state inflado. Conteúdo não relacionado à decisão age como distrator e derruba a acurácia

Solução: cortar o state até sobrar só o que os critérios pedem. Prevenção: montar o state por extração de campos, nunca por "colar o documento inteiro e deixar o modelo se virar"

Sintoma: confiança alta numa resposta claramente errada

Causa provável: a pergunta está ambígua e foi lida literalmente. O modelo respondeu com segurança a pergunta que estava escrita, e não a que você tinha na cabeça

Solução: reescrever a pergunta sem negação e sem condição implícita, uma afirmação por pergunta. Prevenção: revisar as perguntas com outra pessoa, tipo code review, antes de subir

Sintoma: as probabilidades ficam todas empilhadas perto do meio

Causa provável: calibração. Um teste independente de calibração em tarefa inédita (900 tickets de suporte gerados por regra, via Vercel AI Gateway) mediu erro de calibração de 0,107 contra um piso de ruído de 0,024, ou seja, 4,4x o piso, com distorção por compressão em direção ao meio: probabilidades baixas superestimadas, altas subestimadas, cruzando perto de 0,5

Solução: tratar a saída como score monótono e calibrar localmente, nos seus dados. Prevenção: nunca importar threshold de tutorial (inclusive deste aqui) sem validar no seu histórico

Sintoma: ninguém consegue explicar uma decisão específica

Causa: o Jev não gera texto, logo não existe justificativa escrita vindo junto da resposta

Solução: a explicação tem que estar no desenho. Pergunta explícita + state enxuto + log completo = você consegue dizer qual requisito puxou o resultado pra baixo. Prevenção: se você não consegue nomear a pergunta que derrubou o candidato, sua triagem já é caixa-preta 😛

Os limites éticos: por que a decisão final continua humana

Vou ser direto aqui

O Jev é ótimo no que ele se propõe: decisão tipada, barata e paralela, com probabilidade em cima. A página inicial da TypeSafe fala em 193,6x mais rápido e 444,6x mais barato, números autodeclarados, medidos pela própria empresa contra modelos de fronteira, e a empresa mesma diz esperar que estejam na ponta alta dos ganhos do mundo real

Só que velocidade e preço não resolvem o problema de RH. Os dois limites que importam são outros:

• Rastreabilidade não vem de fábrica, porque não existe justificativa em texto na resposta. Ela vem das suas perguntas e do seu log
• Calibração não é confiável fora da caixa, como mostrou o teste independente. Sem ajuste local, o número que volta não pode ser lido como a chance literal de a resposta estar certa

Por isso a saída correta de uma triagem com Jev é aderência a requisitos objetivos mais confiança, por dimensão. Não é um veredito único sobre a pessoa

Caso incerto vai pra gente

E reprovação automática por causa de um número composto é exatamente o tipo de atalho que transforma sua triagem em caixa-preta de novo, só que agora com API

Sobre dados: a TypeSafe declara que não treina nem faz fine tuning com inputs de clientes e que não divulga esses inputs a terceiros além de prestadores de serviço, e oferece zero data retention (ZDR) para clientes enterprise. Isso é parte da responsabilidade, não uma garantia jurídica do seu processo

Quem decide o que é aceitável mandar pra fora é você e o jurídico da sua empresa

Vídeo: transformar JSON em variável em JavaScript

A resposta do Jev volta como JSON, e é ela que você vai consumir no script de composição ou no front do painel de triagem. Pra começar do zero nessa parte, este vídeo do canal mostra como transformar JSON em variável em JavaScript:

Conclusão

O princípio é curtinho e cabe numa linha: pergunta explícita, state enxuto, peso no seu código, confiança como porta

Se esses quatro estiverem no lugar, a triagem fica auditável mesmo com um modelo que não escreve uma palavra de justificativa

O próximo passo prático é este: escreva os critérios da vaga em forma de perguntas ANTES de chamar a API, rode contra um lote de candidaturas que já foram decididas por humanos e compare confidence com acerto, dimensão por dimensão

Daí você calibra os thresholds com dado seu, e não com chute. E já aproveita pra medir acerto e custo por decisão antes de colocar isso na frente de gente de verdade

Até o próximo post! =)