Falso positivo ou falso negativo: como escolher o corte de uma pergunta Noul ou Score no Jev

Usar 0,5 ou 0,8 como corte só porque é um número redondo é decidir sem olhar o custo do erro

Fala aí, beleza? Se tu já começou a brincar com o Jev, provavelmente bateu nessa dúvida: a partir de qual probabilidade eu confio na resposta? 🙂

O Jev é da TypeSafe AI e é o primeiro modelo da classe que a empresa chama de System One Models

Ele foi lançado em acesso antecipado em 15 de setembro de 2026 e tem uma proposta bem diferente de um LLM comum: não gera texto, devolve decisões tipadas, cada uma com probabilidade

E aí vem o ponto que muita gente pula: quem escolhe o corte é a SUA aplicação, não o modelo

Neste post te mostro o critério pra escolher o threshold no Jev olhando pra quanto custa cada tipo de erro, ou seja, pra qual lado vale mais a pena errar

O que o Jev devolve: probabilidade no Noul, score e confiança no Score

Antes de falar de corte, precisa entender ONDE o corte age

E isso muda conforme o tipo de pergunta

Noul: a pergunta de sim ou não

Uma pergunta Noul é do tipo sim/não

A resposta é um único número entre 0 e 1 com a probabilidade de a resposta ser sim: perto de 0 é não, perto de 1 é sim

O Noul não tem campo de confiança separado, porque a própria probabilidade já descreve a incerteza do sim/não

E aqui o primeiro aviso: o Noul não é booleano

Ele não te devolve true ou false, devolve uma probabilidade de sim, e o corte que transforma isso em ação é decisão tua

Score: a escala de níveis

O Score posiciona algo numa escala ordenada de níveis descritivos, e hoje aceita de 2 a 10 níveis

A resposta traz o score, a probabilidade de cada nível, a legenda dos níveis e a confiança

E o score pode cair entre dois níveis, porque é a posição ponderada pelas probabilidades

Que confiança é essa?

É um número de 0 a 1 calculado pelo espalhamento das probabilidades: um pico único num nível dá confiança alta, probabilidade espalhada por vários níveis dá confiança baixa

Onde o corte age em cada um

No Noul tu corta direto na probabilidade

No Score tu olha duas coisas: em qual nível a resposta caiu e se a confiança está alta o bastante pra agir em cima dela

Falso positivo e falso negativo: o que cada erro significa numa pergunta Noul

Bora pegar um exemplo que a própria documentação usa: o comentário contém dado pessoal?

Aqui o sim é contém dado pessoal

• Falso positivo: o sistema diz sim quando era não, ou seja, marca como tendo dado pessoal um comentário que é inofensivo
• Falso negativo: o sistema diz não quando era sim, ou seja, deixa passar um comentário que tinha dado pessoal

Se liga no efeito do corte:

• Subiu o corte (precisa de mais certeza pra dizer sim): menos falsos positivos, mais falsos negativos
• Desceu o corte (aceita sim com menos certeza): menos falsos negativos, mais falsos positivos

Não tem mágica, é uma gangorra haha

Você não elimina erro mexendo no corte, você ESCOLHE qual erro prefere ter mais

Por que dá pra ler a probabilidade como risco?

Por causa da calibração

A documentação explica que calibração vale para grupos de previsões: entre todas as respostas com probabilidade 0,8, cerca de 80% devem estar corretas

Isso é o que permite tratar a probabilidade como uma medida de risco e não como um enfeite

Tome cuidado só com um detalhe: calibração fala de grupo, não de uma resposta isolada, então ela te ajuda a prever quantos erros vão aparecer numa faixa, não qual resposta específica está errada

O que você precisa antes de escolher o corte

Antes de cravar qualquer número, separa isso aqui:

• A pergunta já escrita: a pergunta Noul, ou no caso do Score, os níveis escritos como situações concretas (a TypeSafe recomenda algo como Sem impacto operacional, Serviço degradado, mas com contorno, Serviço indisponível e sem contorno, em vez de baixo/médio/alto)
• Um conjunto de exemplos rotulados: com casos comuns, limítrofes, raros, com redação adversarial e casos que deveriam ir para revisão (é o mesmo tipo de base que você usaria pra comparar o Jev com treinar seu próprio classificador)
• Uma estimativa de custo: quanto custa uma ação errada e quanto custa uma revisão humana
• As ações do produto listadas separadamente: cada coisa que o sistema faz depois da decisão, uma por linha

Esse último item parece bobo, mas é o que mais faz diferença lá na frente 😀

Como escolher o corte passo a passo

A documentação de roteamento por confiança é bem direta: o threshold não é um número único, ações diferentes no mesmo sistema devem ter cortes diferentes, conforme o custo de errar

Bora transformar isso em processo

1. Liste cada ação e o pior caso de cada erro

Pra cada ação, escreve o que acontece num falso positivo e num falso negativo

Nada de pensar no sistema como um bloco só

Erro comum: usar um corte único pro sistema inteiro, como se bloquear um comentário e aprovar uma operação sensível tivessem o mesmo peso

2. Decida qual erro é mais caro em cada ação

Agora compara as duas colunas e marca qual dói mais

É isso que define pra que lado tu vai errar: se o falso negativo é o caro, o corte pra agir sozinho fica mais exigente do lado que deixa passar; se o falso positivo é o caro, o contrário

Erro comum: tratar os dois erros como iguais, que é exatamente o que um 0,5 por hábito faz

3. Rode o conjunto rotulado e veja a distribuição

Passa os exemplos rotulados pelo Jev e olha onde acertos e erros caem ao longo da probabilidade

A doc é clara: os thresholds de produção saem dos exemplos rotulados e do custo de uma ação errada e da revisão humana

Erro comum: testar só casos fáceis, que deixam tudo lindo no teste e quebram no primeiro texto escrito de um jeito estranho

4. Defina as três faixas

O padrão da documentação é este:

• Alta: age automaticamente
• Média: pede confirmação ou marca para revisão
• Baixa: não age e manda para um humano

A faixa do meio é onde mora a revisão barata, e é ela que te deixa ser exigente na faixa automática sem travar tudo

Erro comum: ler o Noul como booleano e jogar fora a faixa do meio, aí todo caso duvidoso vira sim ou não na marra

5. Mantenha as regras rígidas por cima do modelo

O corte é da aplicação, e a aplicação continua aplicando as regras rígidas que já tinha

Se uma regra de negócio diz que algo nunca pode acontecer, não é uma probabilidade alta que vai liberar

A lógica de roteamento fica mais ou menos assim (é pseudocódigo da SUA aplicação, não é API do Jev, e os nomes das variáveis são inventados por mim):

# Pseudocódigo da lógica da aplicação (não é API do Jev)
# Cortes por ação: saldo e transferência vêm do exemplo oficial da TypeSafe
# Os demais são placeholders a calibrar no seu conjunto rotulado

CORTES = {
  consultar_saldo:   { agir: 0.6 },
  transferir:        { agir: 0.85, minimo: 0.6 },
  marcar_comentario: { agir: CORTE_AGIR_CALIBRADO, revisar: CORTE_REVISAR_CALIBRADO }
}

funcao rotear(acao, confianca):
  se viola_regra_rigida(acao):
    retorna BLOQUEAR            # regra rígida vem antes do modelo

  corte = CORTES.get(acao)

  se confianca >= corte.agir:
    retorna AGIR_SOZINHO
  senao se confianca >= corte.revisar (ou corte.minimo):
    retorna PEDIR_CONFIRMACAO   # faixa do meio
  senao:
    retorna MANDAR_PARA_HUMANO

Repara que cada ação tem o próprio corte, e que os valores sem fonte oficial ficam como placeholder até o teu conjunto rotulado dizer o número

6. Registre tudo em produção e revise

Em produção, a recomendação da doc é registrar a versão dos critérios, as distribuições de probabilidade, a rota escolhida e o desfecho humano

E acompanhar também a taxa de revisão e o custo dos erros, que é o que te diz se o corte continua fazendo sentido (tem um passo a passo de como monitorar as decisões em produção aqui no blog)

Erro comum: escolher o corte uma vez e nunca mais olhar, como se o tráfego real fosse igualzinho ao conjunto de teste

Exemplos opostos: checagem de segurança versus triagem de conteúdo

Agora o critério aplicado nos dois sentidos, pra ficar claro

Um aviso honesto: a TypeSafe não publica um exemplo específico de checagem de segurança contra triagem de conteúdo, então o raciocínio abaixo é sobre custo de erro, sem números atribuídos a ela (fora o exemplo do banco, que é oficial)

Checagem de segurança e ações sensíveis

Aqui deixar passar é o erro caro

Então o corte pra agir sozinho fica alto e a faixa de revisão fica larga, porque mandar pra um humano custa muiiito menos que errar

O exemplo oficial da documentação é uma interface bancária por voz:

• Consultar saldo com 0,6 de confiança está ok, porque o pior caso é o usuário ouvir o saldo
• Pra transferências, o corte citado pra agir sozinho é acima de 0,85
• Abaixo de 0,6, qualquer ação vai para um humano

Mesmo sistema, mesma pessoa falando, cortes diferentes

É a prova de que o corte acompanha a consequência, não o modelo

Triagem de conteúdo

Pega os exemplos oficiais de Noul: o comentário contém dado pessoal? a mensagem pede reembolso?

Aqui a pergunta muda: qual erro dói mais NO SEU produto?

• Dado pessoal: um falso negativo expõe dado de alguém, um falso positivo segura um comentário inofensivo por um tempo; na maioria dos produtos, o primeiro pesa mais, então tu aceita mais falsos positivos indo pra revisão
• Pedido de reembolso: um falso negativo pode deixar um cliente sem resposta, um falso positivo manda pra fila de reembolso uma mensagem que não era pedido; aí a conta depende de quanto custa um atendente olhar a mensagem contra quanto custa o cliente irritado

A regra prática: a faixa de revisão vale a pena enquanto a revisão humana custar menos que o erro que ela evita

Quando a revisão fica mais cara que o erro, tu estreita a faixa e deixa o automático trabalhar

Um caso com Score: impacto operacional

Imagina um Score com os níveis do exemplo da TypeSafe: Sem impacto operacional, Serviço degradado, mas com contorno, Serviço indisponível e sem contorno

O corte aqui tem duas camadas:

• Por nível: caiu perto de Sem impacto operacional, pode seguir o fluxo automático; caiu perto de Serviço indisponível e sem contorno, aciona o caminho mais rápido de escalonamento
• Por confiança: se a probabilidade ficou espalhada entre níveis (confiança baixa), não importa onde o score caiu, vai pra um humano

E lembra que o score pode cair entre dois níveis, então decide antes o que fazer quando ele cair no meio do caminho entre degradado e indisponível (geralmente, tratar pelo lado mais caro de errar)

Vídeo: tome suas próprias decisões como dev

Pra começar do zero com essa ideia de decidir com critério em vez de seguir o padrão por hábito, este vídeo do canal fala sobre tomar as próprias decisões como dev 😀

Próximo passo: monte seu conjunto rotulado antes de escolher qualquer número

Recapitulando o que importa:

• O threshold no Jev é por ação, não um número só pro sistema todo
• Erre pro lado mais barato, e quem define o que é barato é o custo real no seu produto
• Guarde uma faixa do meio pra confirmação ou revisão, porque o Noul é probabilidade e não booleano
• Mantenha as regras rígidas por cima do modelo

O próximo passo concreto é separar teus exemplos rotulados, incluindo os limítrofes e os de redação adversarial, e estimar o custo de cada erro e da revisão humana

Só depois disso tu fixa o primeiro threshold

E aí acompanha os logs em produção pra ver se a escolha se sustenta com tráfego de verdade

Até o próximo post! 🙂