Como modelar a opção “nenhuma das anteriores” numa decisão do Jev

Fala aí, beleza? Um Choice do Jev sempre nomeia um vencedor, e isso é por design: as probabilities somam 1, então a massa de probabilidade é distribuída entre as opções que VOCÊ mandou, nem que a entrada não tenha nada a ver com nenhuma delas

Ou seja: se a sua lista tem três departamentos e chega um ticket que não é de nenhum dos três, alguém vai ganhar a disputa de qualquer forma

O Jev é o primeiro modelo da classe System One da TypeSafe AI, apresentado em 15 de setembro de 2026, e a proposta dele é justamente devolver resposta tipada com probabilidade calibrada em vez de texto livre

E é aí que mora o detalhe chato: tipagem sem saída de escape não te protege do encaixe forçado, ela só deixa o encaixe forçado bonitinho e válido no schema…

Bora ver como modelar isso direito?

O que você precisa entender antes

O Choice é a primitiva do Jev pra escolher uma opção dentro de um conjunto definido por você

A resposta vem com três coisas:

• a opção escolhida
• as probabilities, uma por opção, somando 1
• um confidence, número de 0 a 1 derivado da concentração dessa distribuição

Concentrou numa opção? confiança alta

Espalhou entre várias? confiança baixa

Dois limites práticos pra ter na cabeça antes de sair montando a lista

Pré-inscrição Curso Jev

Domine o Jev e coloque decisões de IA dentro do seu sistema

Você vai aprender a usar o Jev, o System One Model da TypeSafe AI, pra automatizar decisões com resposta tipada e confiança medida, sem depender de chat nem de alguém revisando cada passo. Entre na lista de espera para garantir a condição de lançamento!

Quero minha vaga

Primeiro: um Choice aceita no máximo 255 opções. Se a sua taxonomia estoura isso, o jogo muda e vale ver como modelar decisão com lista grande antes de continuar

Segundo: o nome da opção E a descrição dela são enviados ao modelo. Não é enfeite de documentação interna, é prompt de verdade

E o custo? O Jev é cobrado por tokens de entrada, US$ 0,042 por 1M de tokens, com saída em US$ 0,00

Cada opção adicionada custa poucos tokens, e é exatamente por isso que a doc recomenda passar a lista COMPLETA de categorias em vez de uma listinha curta pra economizar

Economizar opção aqui é economia errada, beleza?

Como adicionar a saída de escape no seu Choice

Não existe flag mágica pra isso: a orientação documentada é criar a opção na mão, dentro da sua lista. Cinco passos

1. Pergunte se a sua lista cobre todo input possível. Não "na média", não "nos casos que eu lembrei": todo input que pode chegar naquele ponto do fluxo. Se a resposta for "acho que sim", trate como não.

Erro comum deste passo: validar a lista só com os exemplos felizes que você já tem rotulados, que por definição são os que se encaixam.

2. Adicione a opção catch-all com nome claro. A documentação do Jev recomenda incluir um other ou none of the above quando a lista pode não cobrir todo tipo de entrada, justamente pro modelo poder dizer que nenhuma das outras serve.

Erro comum deste passo: nome ambíguo tipo misc, que o modelo pode ler como uma categoria de conteúdo miscelâneo e não como saída de escape.

3. Escreva a descrição que DIFERENCIA o escape das demais. Como nome e descrição vão pro modelo, a doc orienta escrever descrições que separem as opções umas das outras. A descrição do escape precisa dizer que ele é pra quando nenhuma das outras se aplica.

Erro comum deste passo: descrição genérica e acolhedora ("outros assuntos, dúvidas gerais") que canibaliza as opções legítimas e vira o ralo do classificador.

4. Escolha entre other e not stated. A página de boas práticas da TypeSafe separa os dois casos: other em todo Choice que possa não cobrir toda entrada, e not stated quando você extrai um dado que simplesmente pode estar ausente no texto.

Erro comum deste passo: usar other numa extração, misturando "o texto não fala isso" com "isso é de um tipo que eu não previ", que são problemas diferentes.

5. Trate o escape no código a jusante como um caminho próprio. Ele não é erro, não é exceção, não é null: é uma resposta legítima que significa "sua taxonomia não cobre isso".

Erro comum deste passo: cair no else genérico e virar falha silenciosa, o que é o pior dos mundos porque você perdeu a informação mais valiosa que o modelo te deu.

O conjunto de opções, na prática, fica com essa cara (nome + descrição, porque os dois são enviados):

Choice: departamento_do_ticket

- vendas
  "Pedido de orçamento, dúvida de preço, negociação de contrato, upgrade de plano"

- suporte_tecnico
  "Erro, bug, indisponibilidade, dúvida de uso do produto já contratado"

- financeiro
  "Nota fiscal, cobrança, reembolso, dados de pagamento, inadimplência"

- other
  "Use esta opção quando NENHUMA das anteriores se aplica ao ticket.
   Ex: candidatura de vaga, parceria de marketing, imprensa, spam."

Se liga na descrição do other: ela é restritiva e dá exemplos de coisas que ficam FORA das outras três

É o oposto de "outros assuntos diversos", que puxaria ticket de suporte mal escrito pra dentro dela

E no seu lado, o escape é um if explícito, no mesmo nível dos outros (pseudocódigo do seu código, não da API):

resposta = classificar_ticket(texto)

if resposta.opcao == "other":
    # não é erro: é "minha taxonomia não cobre isso"
    fila_triagem_humana.append(texto)
    registrar_gap_de_taxonomia(texto)

elif resposta.confidence < LIMIAR[resposta.opcao]:
    fila_revisao.append((texto, resposta.opcao, resposta.probabilities))

else:
    rotear(resposta.opcao)

Repare que registrar_gap_de_taxonomia é onde tá o ouro: a pilha de other ao longo de um mês é o que te diz qual categoria nova você precisa criar

Por que forçar uma escolha errada polui o dado a jusante

Pensa no que acontece com a entrada que não pertence a nenhuma categoria

Ela não desaparece

Ela vira ruído DENTRO de uma categoria legítima, indistinguível de uma classificação correta

Aí o time de vendas abre a fila e encontra candidatura de emprego no meio dos leads, o dashboard mostra crescimento de um departamento que não cresceu, e a regra de negócio que dispara em cima daquela categoria dispara em cima de lixo

E o pior: quem consome esse dado depois não tem como saber. O campo é tipado, o valor é válido, o schema passou. Nada grita

Tem um teste publicado no DEV Community por Alistair Brown que mostra o efeito de forma bem limpa: com a opção "other" disponível, o Jev escolheu "other"; tirando a saída de escape e deixando só três departamentos, a mesma pergunta virou sales, com confiança de 0.31

Olha o que rolou aí

O modelo não mentiu e não bugou: ele fez exatamente o que um Choice faz, distribuiu a massa entre o que existia e nomeou um vencedor

A confiança de 0.31 é o modelo avisando que aquilo tá esticado

Mas o campo que vai pro seu banco é sales, não é 0.31, e é o campo que o resto da empresa vai ler…

Opção de escape ou score de confiança: qual usar

Os dois parecem resolver a mesma coisa ("o modelo tá inseguro"), só que detectam problemas diferentes

E tem um ponto sobre o confidence que vale repetir porque quase todo mundo lê errado

A documentação é explícita: a confiança mede a FORMA da distribuição, não a correção

Confiança baixa quer dizer "várias respostas estão próximas"

Não quer dizer "eu estou errado"

Dá pra ter confiança alta numa resposta errada, quando a lista de opções é ruim, e é aí que o escape faz um trabalho que nenhum limiar de confiança faz pra você

Quando cada um resolve (e por que usar os dois juntos)

Resumo brutal:

• nada se encaixa = opção de escape
• várias se encaixam = score de confiança

Pra confiança, a TypeSafe sugere trabalhar em três faixas: alta, você age automaticamente; média, você segue com cautela (confirmar, sinalizar pra revisão, buscar mais informação); baixa, você não age e escala pra um humano, pra uma clarificação ou pra outro sistema

E o limiar não é um número único pro sistema todo. A doc orienta limiar POR AÇÃO: ações diferentes dentro do mesmo fluxo são liberadas em níveis diferentes, conforme a consequência do erro, testando confiança contra acurácia nos seus próprios dados rotulados

Faz sentido, né? Mover um ticket de fila e emitir um reembolso não podem passar pelo mesmo corte

Esse desenho tem nome na documentação da TypeSafe: confidence-gated routing, onde o código toma ações diferentes pra respostas confiantes e não confiantes, escalando os casos incertos pra uma pessoa ou pra um modelo de raciocínio mais caro

E tem um cookbook de classificação por confiança que mostra o tamanho do efeito: em 60 documentos, sob duas políticas, um corte em 0.9 divide o conjunto na metade. A metade confiante acerta 90% das vezes e a outra metade 40%

O detalhe massa: ao reportar um nível acima na hierarquia, aqueles 40% viram 70%

Tradução: a resposta granular estava errada, mas a região da resposta estava certa. Perder granularidade de propósito é uma jogada válida quando a confiança tá baixa

E pra fechar o raciocínio de "onde a certeza mora", olha o caso do Noul: ele responde sim ou não devolvendo a probabilidade de ser verdadeiro, e NÃO tem campo confidence separado, porque o próprio valor já é a certeza

0.5 no Noul significa indeciso

Ou seja, a ideia é a mesma em toda a família: o modelo te entrega o material pra você decidir o que fazer, não uma sentença

Vídeo: contexto de ferramentas de IA no fluxo de código

Pra quem tá chegando agora no assunto de agentes e ferramentas de IA dentro do fluxo de desenvolvimento, esse vídeo do canal mostra o plugin Superpowers rodando no Claude Code:

Conclusão

A regra prática cabe em duas linhas

Escape por padrão em todo Choice de cobertura incerta, com descrição restritiva e caminho próprio no código

Confiança pra modular a ação depois que a categoria já é confiável

O próximo passo é chato e é o que separa fluxo de brinquedo de fluxo de produção: rotule um conjunto pequeno de dados SEUS, meça a confiança contra a acurácia real e defina limiar por ação em cima disso. É também assim que você consegue medir acerto e custo por decisão sem ficar no achismo

E se a sua taxonomia é grande, a documentação mostra um caminho bonito: encadear perguntas Choice nível a nível e aplicar beam search sobre as probabilities, mantendo os K melhores caminhos em vez de escolher guloso no primeiro nível

Aí você tem escape em cada nível e confiança em cada nível… o que é bem mais robusto que uma lista gigante achatada

Até o próximo post! 😀