Como rodar o Jev em lote sobre uma base de dados que já existe (e reprocessar só o que mudou)

Fala aí, beleza? Sabe aquela base antiga com um monte de registros que ninguém nunca classificou direito? Esse é justamente o cenário onde o Jev mais rende 😀

E o motivo é simples: ele não te devolve um textão pra você ficar parseando com regex

Ele devolve resposta tipada, com probabilidades

Pra situar rapidinho: o Jev é o modelo de decisão estruturada da TypeSafe AI, empresa fundada pelo Diogo Almeida (ex-pesquisador da OpenAI)

Ele é o primeiro System One Model público, uma categoria que a TypeSafe criou pensando em automação, e está em acesso antecipado desde 15 de setembro de 2026

Na prática funciona assim: entra o estado da aplicação + perguntas tipadas, sai resposta tipada com probabilidades

Se você ainda está na dúvida se o Jev vale a pena pro seu caso, resolve isso antes de apontar ele pra base inteira

Agora, rodar o Jev em lote sobre um histórico grande traz três problemas que SEMPRE aparecem:

• como fatiar o trabalho sem tomar 429 na cara
• o que fazer com os itens de baixa confiança
• como reprocessar só o que mudou depois de ajustar uma pergunta

Bora por partes!

O que você precisa antes de processar a base?

Primeiro, o SDK oficial. São dois, e tu escolhe pela stack:

• typesafe-sdk, pra Python 3.10+
• @typesafe-ai/sdk, pra JS/TS com Node 20+

Os dois leem a chave da variável TYPESAFE_API_KEY e usam o jev-latest como modelo padrão (guarda essa informação, ela vai importar já já)

# Python 3.10+
pip install typesafe-sdk

# ou JS/TS (Node 20+)
npm install @typesafe-ai/sdk

# chave lida pelos dois SDKs
export TYPESAFE_API_KEY="sua-chave-aqui"

Segundo: as perguntas já precisam estar tipadas. O Jev trabalha com três tipos:

• Choice: escolhe uma opção de um conjunto definido (até 255 opções)
• Score: posiciona o registro numa escala ordenada
• Noul: uma proposição de sim/não, com valor entre 0 e 1

Se a pergunta ainda está em formato de "me explica o que acha desse registro", ela não está pronta pro lote 😛

Terceiro: o limite de contexto. A janela do Jev é limitada, e o valor exato fica na página Models da documentação da TypeSafe. Confere lá antes de decidir o tamanho de cada fatia

E, por fim, os rate limits. Eles são medidos em tokens por segundo e em requisições por minuto, e estão sendo ajustados dinamicamente por causa da alta demanda

Ou seja: podem mudar sem aviso

Se o seu volume for grande de verdade, limites maiores existem nos planos custom e enterprise, via [email protected]

Se liga: os blocos de código daqui pra frente (fora a instalação) são pseudocódigo, só o esqueleto da lógica. O nome real dos métodos e o formato do payload estão na documentação do SDK, não chuta isso

Passo a passo: processar o histórico inteiro com o Jev

1. Fixe a versão do modelo no campo model

Como os SDKs usam jev-latest por padrão, se o modelo for atualizado no meio do processamento, metade da base foi decidida por uma versão e metade por outra

Num lote longo, você quer resultados comparáveis. Então usa um ID versionado, tipo jev-1.13.0

Detalhe: hoje o jev-preview aponta pro mesmo modelo que o jev-latest, então trocar um pelo outro não resolve o problema de fixar versão

Erro comum deste passo: deixar o padrão e descobrir depois que misturou versões na mesma base

2. Estime o custo antes de rodar

A cobrança do Jev é só por token de entrada. O preço publicado na página Models é US$ 0,042 por milhão de tokens de entrada, e os tokens de saída são grátis

Confirma na página Models se esse valor vale pra versão que você fixou, beleza?

A conta fica assim:

custo estimado (US$) = (total de tokens de entrada / 1.000.000) * 0,042

Como o que pesa é a entrada, o que manda no custo é o tamanho do estado que você envia por registro

Erro comum deste passo: calcular custo pela saída, que no Jev não é cobrada

3. Agrupe todas as perguntas de cada registro numa chamada só

Aqui mora a maior economia do lote

Quando você manda várias perguntas numa mesma chamada, o estado é ingerido uma vez e as perguntas rodam em paralelo contra ele. E a resposta de cada pergunta não depende das outras que estão na requisição

No cookbook oficial, 13 perguntas sobre um artigo de cerca de 54.000 caracteres ficaram 12,2x mais baratas e 10,0x mais rápidas numa única chamada do que em 13 chamadas separadas, sem mudança nas respostas

É tipo ir no mercado com a lista inteira em vez de fazer 13 viagens, uma pra cada item haha

Erro comum deste passo: fazer uma chamada por pergunta, pagando o mesmo estado várias vezes

4. Fatie a base em lotes que caibam no contexto e no ritmo dos rate limits

São duas restrições ao mesmo tempo: cada chamada precisa caber na janela de contexto, e o volume total por segundo/minuto precisa respeitar os limites de tokens e de requisições

Em vez de disparar a base inteira, processa em fatias e controla a vazão. Se ainda está decidindo entre chamar na hora ou em fila, pra histórico grande a lógica de fila costuma casar melhor com esse controle

A TypeSafe declara que o Jev conclui decisões entre 70 e 500 milissegundos, mas isso é número dela, não garantia pra planejar o seu lote. Quem vai ditar o ritmo é o rate limit da sua conta

Erro comum deste passo: soltar tudo de uma vez e tomar 429 Too Many Requests em cascata

5. Trate 429 e 529 com retry e backoff exponencial

Mesmo com fatiamento, vai ter 429 (Too Many Requests) ou 529 (Overloaded) em algum momento, ainda mais com limites dinâmicos

A orientação da documentação é tentar de novo com backoff exponencial: a cada falha, espera mais tempo antes da próxima tentativa

# pseudocódigo: não são métodos reais do SDK
para cada fatia de registros:
    para cada registro da fatia:
        requisicao = estado do registro + TODAS as perguntas
        model = "jev-1.13.0"
        tentativa = 0
        repetir:
            resposta = enviar(requisicao, model)
            se status for 429 ou 529:
                esperar(espera_base * 2 ^ tentativa)
                tentativa = tentativa + 1
            senao:
                sair do repetir
        gravar(registro, resposta, model)

Erro comum deste passo: repetir na hora, o que só aumenta a pressão sobre o limite e gera mais 429

6. Grave tudo que vai precisar depois, não só a resposta

Esse passo é o que viabiliza a triagem e o reprocessamento seletivo lá na frente

Erro comum deste passo: salvar só a resposta final e depois não ter como separar o que é confiável do que não é

O que fazer com os itens de baixa confiança?

As respostas Choice e Score trazem dois campos importantes:

• probabilities: a distribuição sobre as opções ou níveis
• confidence: um número de 0 a 1, derivado do formato dessa distribuição

E o que isso significa na prática?

Significa que o Jev te diz não só qual opção ele escolheria, mas o quanto essa escolha está firme

A documentação sugere dividir a confiança em três faixas:

Se liga num detalhe: a doc define as faixas, mas os valores de corte quem define é você. Não existe um número mágico, depende do custo de errar no seu caso

1. Separe a base pelas faixas depois do processamento, usando o confidence que você gravou
2. Mande a faixa alta direto pra ação (atualizar status, classificar, arquivar e etc)
3. Coloque a faixa média numa fila de revisão ou busque mais informação pra enriquecer o estado
4. Escale a faixa baixa, seguindo o padrão de roteamento por confiança da TypeSafe: os casos incertos vão pra uma pessoa ou pra um modelo de raciocínio mais caro

Essa é a graça do combo: o Jev resolve o grosso rápido e barato, e só a parte cabeluda sobe pro modelo caro ou pro humano =)

E o Noul?

O Noul não tem confidence separado. Como a resposta já é um valor de 0 a 1, a triagem usa esse próprio valor: você decide a partir de onde conta como sim, a partir de onde conta como não, e o que fica no meio vira zona de revisão

Erro comum desta etapa: tratar a opção mais provável como verdade mesmo quando a distribuição está espalhada. A opção "vencedora" com as outras quase empatadas não é decisão, é chute educado 😅

Pra começar do zero com o outro lado dessa história, os modelos grandes de IA pra onde os casos incertos podem ser escalados, este vídeo do canal mostra um teste do GPT-5.5 e como ele mudou a forma de enxergar IA:

Como reprocessar só o que mudou depois de ajustar a pergunta?

Você rodou a base, olhou os resultados e percebeu que uma pergunta estava mal formulada. Acontece com todo mundo, já me ferrei assim também haha

A boa notícia: não precisa rodar tudo de novo

O porquê: cada pergunta é avaliada de forma independente das outras da mesma requisição. Então alterar uma pergunta não mexe na resposta das demais

O que decide o tamanho do reprocessamento é O QUE mudou:

1. Versione suas perguntas do seu lado. Guarde algo como um identificador + uma versão da pergunta junto dos resultados. Isso é lógica da sua aplicação, não recurso do Jev: a API não controla mudança pra você

2. Filtre o que precisa rodar de novo usando o identificador da pergunta e a versão do modelo que você gravou no passo 6 lá de cima

3. Reenvie só a pergunta alterada pros registros afetados, mantendo o mesmo modelo fixado

4. Se o registro mudou, mande o estado inteiro com todas as perguntas agrupadas, igual no processamento original

5. Trocou de versão do modelo? Trate como reprocessamento completo, senão você volta pro problema de base misturada

# pseudocódigo: filtro de reprocessamento (lógica da sua aplicação)
para cada resultado gravado:
    se resultado.versao_modelo != versao_fixada_atual:
        marcar registro pra reprocessamento completo
    senao se resultado.versao_pergunta != versao_atual_da_pergunta:
        marcar (registro, pergunta) pra reenvio só dessa pergunta
    senao se registro foi alterado depois do processamento:
        marcar registro pra reenvio com todas as perguntas

Erro comum desta etapa: rodar a base inteira de novo por causa de uma pergunta, pagando de novo por tudo que já estava certo

Próximo passo: rode uma fatia pequena antes da base inteira

Recapitulando o roteiro pra rodar o Jev em lote sem dor de cabeça:

• versão do modelo fixa (nada de depender do jev-latest no meio do lote)
• todas as perguntas de cada registro agrupadas numa chamada
• lotes fatiados, com retry e backoff exponencial em 429/529
• triagem por confiança, com escalonamento dos incertos
• reprocessamento seletivo, guiado pelo que você gravou

O próximo passo concreto é simples: pega uma amostra pequena da base e processa primeiro

Olha a distribuição de confidence dessa amostra, calibra os cortes das suas três faixas e só então solta o histórico completo

E lembra: o Jev está em acesso antecipado, os rate limits são dinâmicos e o produto pode mudar. Confere a documentação antes de cada rodada grande, beleza?

Até o próximo post! 🙂