Confiança do Jev: como definir thresholds para agir, escalar para humano ou recusar?

Toda resposta de Choice e Score do Jev chega com um número de confiança entre 0 e 1, e o que você faz com esse número não é decisão do modelo, é decisão sua

O Jev é o primeiro modelo da classe System One da TypeSafe AI, e a proposta dele é bem diferente de chat: em vez de gerar texto livre, ele devolve uma decisão tipada dentro do schema que você declarou (a opção escolhida, uma nota ou uma probabilidade) e o software consome aquilo direto, sem parser gambiarra no meio

Só que decisão tipada não elimina incerteza, ela só deixa a incerteza mensurável

E aí nasce a pergunta que vale o post: a partir de qual confiança o sistema age sozinho, a partir de qual ele chama uma pessoa, e onde ele simplesmente se recusa a agir? Bora desenhar essa política de três faixas sem transformar seu produto numa fila infinita de revisão humana

O que você precisa antes de calibrar os thresholds

Parte técnica primeiro, que é a rápida

• Acesso ao Jev: o modelo está em early access com lista de espera em typesafe.ai desde o lançamento, em 15 de setembro de 2026, com desenvolvedores sendo liberados aos poucos
• SDK Python, instalado a partir do índice próprio da TypeSafe
• TYPESAFE_API_KEY no ambiente, que é a variável que o cliente oficial lê, chamando jev-latest por padrão
• Ou, se tu preferir bater na API na unha: POST https://api.typesafe.ai/v1/systemone, com header Authorization Bearer e Content-Type: application/json

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

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

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

Agora a parte que a galera pula e depois reclama que "o threshold não funcionou"

Você precisa de um conjunto de exemplos rotulados do seu próprio domínio. Sem rótulo não existe calibração, existe achismo com casas decimais

A própria documentação da TypeSafe orienta isso: testar os cortes nos seus dados, comparando confiança contra acurácia observada, porque os valores certos dependem do domínio e do desempenho do modelo naquele caso de uso específico

E você precisa de clareza sobre quais ações o sistema pode executar sozinho. Se essa lista não existe escrita em algum lugar, você não tem política, tem sorte

Um detalhe que ajuda: o preço anunciado do Jev é de US$ 0,042 por milhão de tokens de entrada, com a saída sem custo. Rodar um lote de teste em cima do seu conjunto rotulado sai barato, então não tem desculpa de "vou calibrar no olho pra economizar" 🙂

Passo a passo: desenhando a política de confiança do Jev

1. Liste as ações e o custo do erro de cada uma

Antes de olhar qualquer número, escreve numa tabela tudo que o sistema faz sozinho e responde: se isso der errado, quanto dói? Errar o roteamento de um ticket interno é barato e reversível, alguém move de fila e segue o baile. Cancelar uma assinatura por engano é outra história

A documentação é explícita nisso: threshold 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

O erro comum deste passo: definir um corte global pro sistema inteiro e colar ele em todo lugar. Isso te dá o pior dos dois mundos, permissivo demais no que é caro e paranoico demais no que é barato

2. Escolha a primitiva certa e saiba qual sinal você vai ler

A API expõe três tipos de pergunta, e elas não te dão o mesmo sinal de incerteza

Se liga nisso, porque pega muita gente de surpresa: respostas do tipo Noul não carregam a propriedade de confiança. O sinal de incerteza ali é a própria probabilidade de sim, e a leitura muda (algo perto do meio é o caso ambíguo)

A confidence de Choice e Score é derivada do formato da distribuição de probabilidades da resposta: distribuição concentrada indica resposta confiante, distribuição espalhada indica incerteza

O erro comum deste passo: escrever a política inteira lendo confidence e depois trocar a pergunta pra Noul, quebrando o roteamento sem entender por quê

3. Rode o lote rotulado e cruze confiança contra acurácia observada

Aqui é onde o post vira medição e para de ser opinião. Você roda o seu conjunto rotulado contra jev-latest, guarda a resposta e a confiança de cada item, agrupa por faixa de confiança e olha a acurácia real dentro de cada faixa

from collections import defaultdict

def acuracia_por_faixa(resultados, largura=0.05):
    """resultados: lista de (confidence, acertou_bool)"""
    baldes = defaultdict(lambda: [0, 0])
    for confidence, acertou in resultados:
        chave_faixa = round(confidence // largura * largura, 2)
        baldes[chave_faixa][0] += int(acertou)
        baldes[chave_faixa][1] += 1
    for faixa_inf in sorted(baldes):
        acertos, total = baldes[faixa_inf]
        print(f"faixa {faixa_inf:.2f} | n={total:4d} | acuracia={acertos/total:.3f}")

O que tu quer enxergar é a curva: a acurácia sobe conforme a confiança sobe? Em quais faixas ela desaba? Quanto do seu volume mora em cada pedaço?

O erro comum deste passo: rodar o lote com perguntas que caem nas limitações conhecidas da versão. A página de model jaggedness que a documentação mantém é da versão jev-1.13, e ali está registrado que essa versão não conta de forma confiável (caracteres, ocorrências, itens de lista longa) e tem dificuldade com precisão numérica. Como o cliente oficial chama jev-latest por padrão, vale conferir qual versão esse apelido está resolvendo no teu acesso antes de assumir que essa limitação se aplica (ou não) ao modelo que tu está chamando de verdade. Se a sua pergunta depende de contagem, o número de confiança vai estar medindo outra coisa e a sua curva sai poluída

4. Fixe o corte alto

O corte alto é o ponto onde a acurácia observada naquela faixa já paga o custo do erro daquela ação

Repara que é uma conta de negócio, não de estatística pura: a mesma acurácia que é ótima pra rotear ticket é inaceitável pra mexer em cobrança

Não vou te dar número aqui, e desconfia de quem der. A documentação oficial não prescreve valores de corte, ela manda medir no seu domínio, justamente porque o número certo depende do seu caso de uso

O erro comum deste passo: tratar confiança alta como sinônimo de resposta correta. Calibração no Jev é propriedade de população, medida sobre grupos de previsões, e não garante que aquela resposta individual específica esteja certa. Confiança alta quer dizer "nesse grupo de casos, o modelo erra pouco", não "esse caso aqui está certo"

5. Fixe o corte baixo

O corte baixo é onde a taxa de acerto deixa de justificar qualquer automação. Abaixo dele, o padrão sugerido pela documentação é não agir: rotear pra um humano, pedir esclarecimento ou cair em outro sistema

E tem um ganho escondido aqui: recusar explicitamente é MUITO melhor que agir errado e descobrir depois pelo suporte

6. Defina o destino da faixa do meio

Essa é a decisão que separa política boa de fila infinita

A documentação chama a faixa média de "prosseguir com cautela" e lista caminhos: pedir confirmação do usuário, marcar para revisão ou buscar mais informação. A TypeSafe também posiciona a escalada por confiança como uma escolha entre agir, chamar uma pessoa ou chamar um modelo de raciocínio mais caro e lento

Ou seja: humano não é o único destino da dúvida, e nem deveria ser o primeiro

CORTE_ALTO = ...   # você mede isso nos seus dados, por ação
CORTE_BAIXO = ...  # idem

def rotear(confidence, acao):
    if confidence >= CORTE_ALTO:
        return "executar"
    if confidence >= CORTE_BAIXO:
        return acao.destino_da_duvida  # confirmar com usuário, mais contexto, reasoning ou revisão
    return "recusar"

O erro comum deste passo: mandar 100% da faixa do meio pra revisão humana por padrão. Você acabou de criar um backlog que ninguém vai zerar, e o pior é que o time vai começar a aprovar em lote sem ler, o que é exatamente o contrário do que você queria

7. Meça o volume por faixa e reajuste

Depois de publicar, acompanha quanto do tráfego real caiu em cada faixa e qual foi o acerto observado em cada uma. Threshold não é constante sagrada, é parâmetro

E lembra sempre do enquadramento: calibração é medida em grupos de predições. Você avalia a política olhando população, não anedota

Tome cuidado com mais uma coisa antes de automatizar. O Jev não é fine-tuned nem adaptado com dados do cliente, os mesmos pesos servem todas as contas, e é justamente por isso que o contexto do seu domínio entra pelo campo state da requisição, junto da pergunta. Só que a documentação de limitações da jev-1.13 registra que o state não é tratado como hostil por padrão. Conteúdo adversarial ali dentro pode mover a resposta

Se o seu state carrega texto que veio do usuário, isso é superfície de ataque e a sua política de confiança não te protege disso

Thresholds diferentes para ações diferentes: três exemplos

Roteamento interno de ticket: corte permissivo

Erro barato, reversível, invisível pro cliente final

Um Choice entre as filas possíveis resolve, e aqui você pode deixar quase tudo automático. O custo de mandar o chamado pra fila errada é alguém arrastar de volta em dez segundos

A faixa do meio nem precisa de humano dedicado: pode ir pra uma fila genérica de triagem, que é o comportamento que já existia antes do modelo entrar

Moderação ou bloqueio de conteúdo do usuário: corte alto

Aqui o erro é visível e caro nos dois sentidos: bloquear conteúdo legítimo queima confiança do usuário, e deixar passar o que não devia queima a plataforma

Corte alto pra ação automática, e a faixa média vai pra revisão humana de verdade, com gente olhando

Um Score contra níveis ordenados e descritivos costuma encaixar melhor que Choice binário nesse cenário, porque ele te devolve a probabilidade de cada nível junto com a confiança, e você enxerga se a dúvida é entre "tudo certo" e "limítrofe" ou entre "limítrofe" e "grave"

São duas dúvidas bem diferentes, e merecem tratamento diferente

Ação financeira ou irreversível: corte muito alto e recusa explícita

Estorno, cancelamento, exclusão, envio de dinheiro, os rm -rf da vida

Corte muito alto pra agir sozinho, faixa média vai pra pessoa ou pra um modelo de raciocínio mais caro e lento, faixa baixa recusa e devolve o caso pro fluxo normal

E aqui vale reforçar o ponto do jaggedness: se a decisão depende de precisão numérica ou de contagem, a jev-1.13 tem limitação conhecida nisso. Nesse caso, a conta você faz em código determinístico e usa o modelo só pra parte de julgamento

E se a faixa do meio engolir tudo?

Se metade do seu volume está caindo na zona cinzenta, o problema quase nunca é o threshold

Geralmente é a pergunta (ambígua, com opções que se sobrepõem, ou perguntando uma coisa e esperando outra: a documentação de limitações registra justamente que o modelo responde a pergunta escrita, não a pretendida) ou é falta de contexto no state

Antes de mexer no corte, tenta reduzir a incerteza na origem. A documentação mantém cookbooks de padrões avançados que atacam isso, entre eles SDE cascade, self-consistency com nouls (/cookbooks/consistency_noul_cookbook) e perguntas em paralelo (/cookbooks/parallel_questions)

Melhorar a pergunta rende muito mais que caçar a terceira casa decimal do threshold

Vídeo: conteúdo relacionado do canal

Antes de qualquer decisão probabilística, a primeira barreira continua sendo validação determinística no cliente: o que dá pra barrar com regra fixa, barra com regra fixa

Pra começar do zero nesse assunto, este vídeo do canal mostra como impedir o usuário de colar caracteres especiais usando JavaScript

Próximo passo

Threshold bom é o que você mediu no seu domínio, não o que copiou de um post (inclusive deste aqui, que de propósito não te deu número nenhum)

O próximo passo é concreto: separa uns 200 a 300 exemplos rotulados das suas ações mais críticas, roda contra jev-latest, cruza confiança com acerto faixa por faixa e SÓ ENTÃO escreve os dois cortes no código

E antes de automatizar qualquer coisa que dependa de contagem ou precisão numérica, passa na página de limitações conhecidas da jev-1.13, porque ali estão os casos onde o número de confiança mede menos do que você imagina

Depois me conta como ficou a distribuição por faixa no teu caso, bora trocar uma ideia

até o próximo post! 😀