O que é o sampler paralelo do Jev e por que ele resolve tudo em uma única chamada?

Fala aí, beleza? Se você já montou qualquer coisa que extrai vários campos de um mesmo documento, conhece a cena: um PDF gigante, dez perguntas diferentes, dez chamadas encadeadas, e o mesmo documento sendo pago dez vezes

O Jev chegou em 15 de setembro de 2026 como o modelo System One da TypeSafe AI, e a peça que interessa pra esse problema tem nome: o sampler paralelo

Em vez de gerar token a token de forma autoregressiva, ele emite todas as probabilidades de uma vez, em paralelo. Todas as saídas em uma única query

Isso não é só uma economia de fatura. Muda o DESENHO da chamada, e é aí que o post quer chegar 🙂

De onde vem o Jev e por que a TypeSafe reconstruiu o stack

A TypeSafe AI foi fundada por Diogo Almeida, ex-pesquisador da OpenAI, e anunciou uma rodada de US$ 40 milhões liderada pela DCVC junto com o lançamento do modelo

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

E não foi fine-tune em cima de coisa pronta: a empresa montou um stack próprio, com nova arquitetura de modelo, o tal sampler paralelo e um método de treino chamado RLCD (Reinforcement Learning for Calibrated Decisions)

O Jev é o primeiro da categoria que eles chamam de System One model: a ideia é devolver decisão estruturada que o código consome direto, sem geração de texto no meio

Você manda um estado e perguntas tipadas. Ele devolve valores tipados e distribuições de probabilidade

Sacou a diferença? Não tem prompt pedindo "responda em JSON, por favor", não tem parse de texto, não tem aquele ritual de rezar pro modelo não inventar uma vírgula a mais

Status hoje: early access com lista de espera, com as chaves saindo pelo console da TypeSafe. Não é disponibilidade geral ainda, então calma com o roadmap

Como funciona uma requisição com várias perguntas na prática

O que resolve o problema é o formato da chamada, então bora dissecar ele por partes

1. Monte o corpo da requisição: state, questions e model

O corpo tem três partes: um state (o contexto que vai ser avaliado), um objeto questions onde VOCÊ nomeia cada pergunta, e um campo model opcional

O state aceita string, objeto JSON ou array. Ou seja, dá pra jogar o texto cru do documento ou o registro estruturado que você já tem em mãos

{
  "state": "<seu documento, objeto JSON ou array>",
  "questions": {
    "categoria_do_ticket": { ... },
    "clareza_da_descricao": { ... },
    "precisa_de_escalonamento": { ... }
  },
  "model": "jev-1.13"
}

Erro comum deste passo: tratar questions como uma lista anônima e depois se perder pra saber qual resposta é qual. É um record nomeado por um motivo, o nome que você escolher é a chave que volta na resposta

2. Escolha a primitiva certa pra cada pergunta

A API System One tem três tipos de pergunta:

• Choice: escolhe uma opção dentro de um conjunto
• Score: dá uma nota contra níveis descritos
• Noul: julgamento sim/não numa escala de 0 a 1

Erro comum deste passo: usar Choice pra tudo. Quando a pergunta é de grau ("quão completa está a descrição?"), Score com níveis descritos te dá muito mais informação do que um menu de opções

3. Dispare um POST único

Todas as perguntas vão no mesmo request, pro mesmo endpoint:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @request.json

Erro comum deste passo: estourar o orçamento de tokens sem perceber que ele é COMPARTILHADO. São 64k pro estado mais todas as perguntas somadas, e um limite mais apertado de 32k pro estado mais a pergunta mais longa. Documento gordo + uma pergunta muito verbosa é a combinação que te derruba primeiro

4. Leia a resposta pelo nome da pergunta

Cada answer volta sob o mesmo nome que você deu lá no questions. Nada de casar índice de array com índice de resposta

E em Choice e Score não vem só o vencedor: vem probabilidade pra cada opção ou nível, mais um valor de confidence derivado do formato da distribuição, de 0 a 1

Erro comum deste passo: ler só o topo da distribuição e ignorar o confidence. Falo disso na seção de casos de uso, porque é ali que mora a parte mais útil da coisa

O que muda para quem hoje encadeia uma chamada por campo

Se liga na conta, que é o coração do assunto

Com N chamadas de uma pergunta cada, você paga o documento N vezes e faz N round trips. O estado domina a requisição, as perguntas são o troco

Com a chamada em lote, o documento é cobrado UMA vez

E tem uma consequência bonita disso: quanto maior o documento, mais a economia se aproxima de N vezes. Não é um ganho fixo, é um ganho que cresce junto com o seu pior caso

Agora a parte que o pessoal esquece: toda pergunta do mesmo request é avaliada em paralelo e em isolamento contra o mesmo estado

Uma resposta não vira contexto da outra. Não tem aquele efeito de context-rot em que a pergunta 7 fica contaminada pelo que o modelo respondeu na 3

E adicionar perguntas quase não mexe no tempo de resposta

No código, o que some é justamente o encanamento: a orquestração de fan-out, o merge de respostas, o controle de ordem das chamadas, o retry por item. Se você já montou um agente rodando tarefa de verdade, sabe exatamente qual camada de gambiarra eu tô falando haha

Vira um POST e um dicionário de respostas. Só isso

Onde o ganho de uma única query aparece de verdade

Briefing sobre documento longo. É literalmente o cookbook oficial Parallel questions: 13 perguntas de um briefing regulatório em cima do artigo da Wikipedia sobre GDPR. Mesmo documento, treze recortes diferentes, uma chamada

Roteamento com Choice e leitura de confidence. O exemplo da doc é ótimo pra entender por que a distribuição importa: billing vence com 0,84, mas o confidence fica em 0,596, porque technical ainda segura 0,159

Repara: a resposta "certa" saiu, mas o modelo tá te avisando que o caso é ambíguo. Com isso você monta um limiar de escalonamento humano de um jeito que um texto gerado nunca te daria

Avaliação por níveis com Score. Rubrica com níveis descritos, várias dimensões do mesmo artefato, todas no mesmo request. Serve bem pra aquele trabalho chato de conferir aderência à spec sem reler tudo na mão

E onde NÃO se aplica: qualquer coisa que peça texto gerado. Resumo, redação, refatoração de código, explicação pro usuário final. O Jev não gera texto, ele decide. Ferramenta diferente pra trabalho diferente

Vale a pena redesenhar sua chamada agora?

Vamos separar o que tá medido do que é alegação, porque as duas coisas costumam vir grudadas em post de lançamento

Medido no cookbook oficial: 13 perguntas, batch contra uma chamada por pergunta, 12,2x mais barato e 10,0x mais rápido, sem mudança nas respostas. Isso é um cenário específico, com um documento específico, e é honesto tratar como tal

Alegação da fabricante: cerca de duas ordens de magnitude em velocidade e eficiência pra tarefas System One, mantendo nível de inteligência comparável ao de LLMs nessas tarefas. Pode ser, mas é a empresa falando dela mesma, então fica anotado como alegação

Sobre preço, o anúncio de lançamento fala em US$ 0,042 por milhão de tokens de entrada, com saída sem cobrança. Faz sentido com o modelo: a saída é uma distribuição, não um texto quilométrico

As ressalvas de verdade:

• Ainda é early access com waitlist, chave sai no console da TypeSafe. Não dá pra prometer entrega pro cliente em cima disso hoje
• jev-latest é um alias móvel e é o padrão do SDK. Ele se move quando sai release nova, ou seja, suas respostas podem mudar sem você encostar em uma linha de código

Essa segunda é a que morde. Se o comportamento importa pro seu pipeline, fixe a versão: a mais recente documentada é a jev-1.13

Tome cuidado aqui, é o tipo de coisa que passa batido no piloto e vira mistério três meses depois

Conclusão

O sampler paralelo do Jev muda o desenho da chamada antes de mudar a conta

A conta cai como consequência de você parar de pagar o mesmo documento N vezes, mas o que realmente melhora é o código: um POST, perguntas nomeadas, respostas nomeadas, zero orquestração de fan-out

Se o seu caso é decisão estruturada em cima de documento grande, o próximo passo concreto é entrar na lista de espera e ir preparando o terreno

Dá pra chamar direto no HTTP com POST /v1/systemone ou usar os SDKs oficiais de Python e JavaScript

No Python é pip install typesafe-sdk ou uv add typesafe-sdk, com Python >= 3.10, e o cliente lê a chave de TYPESAFE_API_KEY no ambiente

pip install typesafe-sdk
export TYPESAFE_API_KEY="sua-chave"

E já deixa a versão fixada na cabeça, beleza? 😀

até o próximo post!