Como montar uma fila de revisão humana usando a confiança do Jev?

Automatizar tudo dá erro caro

Revisar tudo na mão mata a automação antes dela nascer

O caminho do meio tem nome: human-in-the-loop, ou seja, a máquina decide o que dá pra decidir sozinha e chama uma pessoa quando o chão fica escorregadio. O problema sempre foi o mesmo: como a máquina sabe que o chão está escorregadio?

É aí que entra o Jev, o primeiro modelo público da classe System One da TypeSafe AI. Ele não gera texto: recebe um estado e perguntas tipadas e devolve decisões estruturadas com distribuição de probabilidade. E junto com a decisão vem um valor de confiança entre 0 e 1, que é exatamente o gancho que você precisa pra montar a fila

Neste post a gente desenha esse fluxo: quais perguntas devolvem confiança, como escolher o corte por tipo de decisão, como calibrar o número e como a fila devolve informação pro processo melhorar

Bora?

O que você precisa antes de montar a fila

Antes de sair codando o roteador, junta as peças

• Chave da API na variável TYPESAFE_API_KEY: o cliente oficial lê essa variável de ambiente
• Acesso ao endpoint: todos os modelos da TypeSafe são servidos pelo mesmo POST /v1/systemone, com autenticação Bearer usando a chave
• Escolha do modelo: o cliente chama jev-latest por padrão, e IDs versionados como jev-1.13 também são aceitos no campo model
• Um conjunto de exemplos rotulados: entradas cuja resposta correta você já conhece. Sem isso não existe calibragem, existe achismo

O esqueleto da chamada é esse:

POST /v1/systemone
Authorization: Bearer $TYPESAFE_API_KEY

Boa notícia pra quem ficou de fora no início: o Jev foi lançado em early access em 15 de setembro de 2026 e hoje está aberto a todos, sem lista de espera. A própria TypeSafe anunciou assim: "Jev is now available to everyone. No waitlist."

E não precisa nem ficar preso ao console deles: o mesmo modelo pode ser chamado por plataformas de terceiros como OpenRouter e Cloudflare Workers AI

Uma decisão que vale resolver antes de escrever a fila é se cada pergunta vai rodar na hora ou em lote, porque isso muda o formato do seu worker. Se esse ponto ainda está em aberto no teu projeto, dá uma olhada em chamar o Jev na hora ou em lote antes de seguir

Passo a passo para montar a fila de revisão humana

1. Mapear as decisões do fluxo e escrever cada uma como primitiva: o Jev trabalha com Choice (escolhe uma opção de um conjunto definido), Score (classifica em níveis ordenados e descritivos) e Noul (avaliação sim/não). Pega teu fluxo e pergunta, decisão por decisão: isso é escolha, é classificação ou é sim/não? Erro comum deste passo: escrever a decisão como Noul e depois procurar o campo de confiança pra rotear. Ele não existe ali, e o motivo é bom: a distribuição do Noul tem só dois resultados, e o próprio valor do noul já descreve ela por completo. Se você quer roteamento por confiança naquela decisão, ela precisa nascer como Choice ou Score. Vale lembrar também que a qualidade da decisão começa no state que você manda como entrada, não no threshold

2. Ler o campo confidence na resposta: a resposta de Choice inclui a opção selecionada, a probabilidade de cada opção e a confiança. A de Score inclui o score, a probabilidade de cada nível e a confiança. O confidence resume a distribuição num único número justamente pra você aplicar um corte sem fazer a conta na mão. Erro comum deste passo: ler esse número como "probabilidade de estar certo". A documentação é explícita: confiança é uma margem, não a probabilidade de a resposta estar correta, e valor alto não garante decisão certa. Quem confunde isso monta uma fila que nunca recebe os casos que mais importam

3. Definir as três faixas padrão: a doc sugere como padrão inicial dividir a confiança em alta (agir automaticamente), média (seguir com cautela, pedir confirmação do usuário ou sinalizar pra revisão) e baixa (não agir, encaminhar pra uma pessoa ou pedir esclarecimento). Começa por aí, é um ponto de partida honesto. Erro comum deste passo: tratar a faixa média como se fosse alta só porque "o modelo quase sempre acerta". Média existe pra sinalizar, não pra agir escondido

4. Ajustar o corte por tipo de decisão: aqui mora a parte que quase todo mundo pula. A documentação afirma que o limite de confiança não é um número único: ações diferentes dentro do mesmo sistema devem ser liberadas em níveis diferentes conforme a consequência do erro. Etiquetar um ticket errado custa um clique, cancelar uma assinatura errada custa um cliente. Erro comum deste passo: definir um threshold global no .env e sair usando ele no sistema inteiro

5. Calibrar o threshold contra o conjunto rotulado: a orientação da TypeSafe é testar o corte contra exemplos rotulados antes de confiar nele. Roda entradas cuja resposta você conhece e observa onde confiança e acurácia divergem. É justamente nesse cruzamento que você descobre em qual faixa o teu domínio realmente aguenta automação. Erro comum deste passo: adotar um número vindo de benchmark do fornecedor. Benchmark é o domínio deles, o teu conjunto é o teu domínio, e os dois não têm obrigação nenhuma de concordar

6. Implementar o escalonamento: a doc orienta escalar casos incertos pra uma pessoa ou pra um modelo de raciocínio mais caro. Ou seja, a faixa baixa não precisa ir SEMPRE pro humano: dá pra ter um degrau intermediário, onde um modelo mais caro opina antes de gastar tempo de gente. Erro comum deste passo: criar a fila e não criar o caminho de volta. Se a decisão do humano não volta pro fluxo, você construiu um depósito de pendências, não uma fila de revisão

7. Concentrar perguntas e limites em um único arquivo: essa recomendação tem um motivo bem prático, e a própria doc diz qual é: essa é a parte que um humano precisa revisar. Pergunta espalhada em cinco serviços e threshold escondido em três funções vira um sistema que ninguém audita. Erro comum deste passo: hardcodar o corte dentro do if do serviço, porque "é só um número"

A lógica do roteador, no fim, é boba. O trabalho está nas faixas, não no código:

# pseudocódigo: a lógica de roteamento é sua,
# o que vem do modelo é o campo confidence

resposta = perguntar_jev(state, pergunta)

if resposta.confidence >= corte_alto(pergunta):
    agir_automaticamente(resposta)
elif resposta.confidence >= corte_baixo(pergunta):
    agir_com_confirmacao(resposta)   # ou sinalizar pra revisão
else:
    fila_de_revisao.enfileirar(state, pergunta, resposta)

Repara que corte_alto e corte_baixo recebem a pergunta como argumento

Isso não é firula, é o passo 4 virando código 🙂

Como escolher o corte por tipo de decisão

A régua é uma só: proporcional à consequência do erro

Pergunta simples pra cada decisão do teu fluxo: se isso sair errado, quanto custa pra desfazer? Se a resposta for "um clique", você pode ser permissivo. Se for "um email pedindo desculpas pro jurídico", não pode

E quais são esses pontos fracos conhecidos? A documentação do jev-1.13 lista limitações do modelo, e elas são ouro puro pra quem está desenhando fila:

• Leitura literal da pergunta: escopo, negação e condições implícitas são lidos ao pé da letra
• Contagem e precisão numérica pouco confiáveis
• Comparação de datas lida como texto, não como quantidade ordenada

Se a tua pergunta tem um "exceto quando", um "não", uma contagem ou um "é anterior a", trata ela como candidata natural a corte mais conservador ou a revisão obrigatória. Não porque o modelo é ruim, mas porque você já sabe onde ele escorrega, e ignorar isso é escolher o erro caro de olhos abertos

Tome cuidado com um detalhe: confiança alta numa pergunta com negação não te salva. A página sobre confiança já avisou que valor alto não garante decisão certa. Ele pode estar confiantemente lendo a tua pergunta do jeito errado

Como a fila alimenta o ajuste do processo

A fila não é só um pronto-socorro

Ela é a tua fonte de dados rotulados, de graça, todo dia. Cada item que uma pessoa revisa vira um exemplo com resposta conhecida, que é exatamente o insumo que o passo 5 pediu

O loop funciona assim:

1. Guardar o pacote completo do item revisado: o state que entrou, a pergunta, a resposta do modelo, a confiança e a decisão do humano. Guardar só "aprovado/reprovado" não serve, você perde o contexto
2. Comparar decisão humana com resposta e confiança: separa em quadrantes. Modelo certo com confiança alta é o caso feliz. Modelo errado com confiança alta é o alerta vermelho, e é ali que a pergunta ou o corte precisa mudar. Modelo certo com confiança baixa significa que você está gastando tempo de gente à toa
3. Reescrever as perguntas que geram desacordo: quando muitos itens da mesma pergunta viram discordância, quase sempre o problema é a pergunta, não o modelo. Ambiguidade, escopo mal delimitado, opção de Choice que se sobrepõe a outra
4. Mover o threshold com base no acumulado: com volume suficiente, você vê onde confiança e acurácia divergem no teu domínio e ajusta o corte daquela decisão específica, não de todas
5. Reavaliar quem merece escalonamento: decisão que nunca é revertida pelo humano talvez possa subir de faixa. Decisão que é revertida direto talvez devesse ir pro modelo de raciocínio mais caro antes de chegar na pessoa

E é aqui que o arquivo único paga a fatura: quando pergunta e limite estão no mesmo lugar, esse ajuste é um diff que dá pra revisar numa PR. Quando estão espalhados, o ajuste vira arqueologia

E o custo de deixar isso rodando?

Esse desenho gera MUITA chamada, porque cada decisão do fluxo vira uma pergunta

O preço do Jev 1.13 na API cobra só a entrada: US$ 0,042 por 1 milhão de tokens de entrada e US$ 0,00 por 1 milhão de tokens de saída. A TypeSafe também informa latência ponta a ponta de 70 a 500 milissegundos pro Jev, resultado de amostragem paralela em vez de geração sequencial de tokens (esse número é do fornecedor, vale medir no teu caso)

Falando em cortar gasto com IA, pra começar do zero com esse assunto, este vídeo do canal mostra como reduzir o custo usando o Fable 5:

Conclusão

Recapitulando o que sustenta a fila inteira: o confidence de 0 a 1 vem nas respostas de Choice e Score, o Noul não expõe esse campo, as três faixas (alta, média, baixa) são o ponto de partida sugerido pela doc, e o corte é por tipo de decisão, proporcional ao custo do erro

E o aviso que vale mais que todos os outros: confiança é margem, não é probabilidade de acerto. Valor alto não garante decisão certa, e desenhar a fila esquecendo disso é construir uma automação que erra com convicção

O próximo passo concreto é esse, nessa ordem:

1. Montar o conjunto de exemplos rotulados do teu domínio
2. Rodar o corte em modo sombra, ou seja, o sistema calcula a faixa, registra tudo e não age em nada
3. Comparar o que teria acontecido com o que a pessoa decidiu
4. Só depois ligar a automação da faixa alta, uma decisão de cada vez, começando pelas reversíveis

É menos glamouroso que ligar tudo de uma vez, e é justamente por isso que funciona 😀

Até o próximo post!