Choice, Score ou Noul: qual tipo de pergunta do Jev usar em cada decisão?

Fala aí, beleza? Escolher o tipo de pergunta errado no Jev não dá erro de sintaxe, dá coisa pior: uma resposta forçada, que parece certa e não é

O Jev é o modelo System One da TypeSafe AI e ele expõe exatamente três primitivas: Choice, Score e Noul

Três. Nada de prompt criativo pra encaixar o resto

E aqui está o pulo do gato: a decisão de qual dos três usar acontece ANTES de você escrever qualquer linha de código. É modelagem, não implementação

Bora destrinchar os três?

Choice, Score e Noul lado a lado

Se você já usou enum e escala Likert na vida, o mapa mental é esse mesmo: Choice é enum, Score é escala, Noul é booleano com probabilidade em cima

Quando usar Choice: a resposta é uma de um conjunto fixo

A documentação do Choice é direta no critério: use quando a resposta é uma de um conjunto fixo de opções

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

Os exemplos que ela dá:

• qual time atende um ticket
• a qual categoria um produto pertence
• em qual linguagem um trecho de código foi escrito

Sacou o que essas três têm em comum? Nenhuma ordem entre as opções

Python não é "mais" que Go, billing não é "maior" que sales. São categorias soltas, e é exatamente aí que Choice brilha

O campo é o criteria, e ele é um mapa de chave da opção para a descrição da opção. Não é um array chamado options, é mapa mesmo

Quando a opção é auto explicativa, você passa null no valor e segue o baile

O exemplo da referência de API da documentação usa o identificador de modelo jev-latest com uma pergunta do tipo choice e as opções billing, technical e sales:

{
  "model": "jev-latest",
  "state": "Cliente escreveu: fui cobrado duas vezes no cartao esse mes",
  "questions": {
    "fila": {
      "type": "choice",
      "criteria": {
        "billing": null,
        "technical": null,
        "sales": null
      }
    }
  }
}

O fila ali é um ID escolhido por você, e a resposta tipada volta debaixo dele

Na volta você recebe três coisas: a opção selecionada, o probabilities (cada opção mapeada pra sua probabilidade, e elas somam 1) e o confidence

Esse detalhe do "somam 1" é importante e vai voltar a aparecer mais pra frente: Choice distribui 100% da certeza entre as opções que VOCÊ ofereceu

Se a resposta correta não está na lista, ele não vai te avisar com um erro. Ele vai empurrar a probabilidade pra menos errada 😅

Tome cuidado! Conjunto fixo significa fixo de verdade: se aparece caso novo toda semana, você provavelmente precisa de uma opção de escape no criteria

Quando usar Score: a resposta é uma posição num espectro

A documentação do Score dá o critério: use quando a resposta é uma posição num espectro que dá pra descrever em degraus

Os exemplos dela:

• gravidade de um bug
• satisfação de um cliente
• nível de experiência em Python de um candidato

Agora existe ordem real entre as alternativas. "Sistema fora do ar" é pior que "botão torto", e essa relação é informação que o modelo usa

O criteria do Score é um array ordenado de descrições de nível, do menor para o maior. E o número do nível é a posição no array, começando em 0

Ou seja: o primeiro item da lista é o nível 0, não o nível 1. Já vi gente se enrolar com off by one aqui, se liga nisso

{
  "model": "jev-latest",
  "state": "Relato: ao salvar o formulario, os dados do cliente sao apagados do banco",
  "questions": {
    "gravidade": {
      "type": "score",
      "criteria": [
        "cosmetico, nao afeta o uso do produto",
        "incomoda, mas existe contorno simples",
        "funcionalidade principal quebrada",
        "perda de dados ou sistema indisponivel"
      ]
    }
  }
}

Quatro degraus, do menor pro maior. A API aceita de 2 a 10 níveis, então não tente montar aquela escala de 0 a 100 aqui

A resposta traz o score, a probabilidade de cada nível, o confidence e um campo muito massa: o legend, que mapeia cada número de nível de volta pra sua descrição

Isso resolve o problema clássico de log ilegível. Em vez de guardar "score: 3" e ficar adivinhando três meses depois, você guarda o nível com a frase que ele significa

Descreva os degraus como critério, não como adjetivo solto. "Grave" e "muito grave" são a mesma coisa pra qualquer um que leia; "perda de dados" é verificável

Quando usar Noul: a decisão é binária e você quer a probabilidade

Primeiro o nome, porque isso confunde: o tipo binário do Jev se chama Noul na documentação oficial, não "Yes/No"

Ele pergunta um sim ou não e devolve a probabilidade de a resposta ser sim

A resposta é um número único entre 0 e 1, onde 0 significa não e 1 significa sim

E perto de 0,5? Significa que o modelo dá peso parecido pros dois lados. Não é "meio sim", é indecisão mesmo, e o seu código deveria tratar isso de forma diferente de um 0,95

"Mas por que o Noul não tem campo confidence se Choice e Score têm?"

Porque não precisa. A distribuição do Noul tem só dois resultados possíveis, então o próprio valor já a descreve por completo

Um 0,97 é confiante no sim, um 0,03 é confiante no não, um 0,52 é empate. Um segundo número ali seria redundante

É o mesmo tipo de raciocínio de quando você decide entre Claude Code e o autocomplete do editor pra uma edição: o formato da tarefa já entrega qual ferramenta cabe, não é questão de gosto

Como escolher o tipo em 4 perguntas

Roteiro curto, serve pra qualquer caso. Responda na ordem e pare no primeiro que fechar

1. A resposta é sim ou não? Se a pergunta é "isso é spam?", "esse ticket precisa de humano?", "esse texto viola a política?", é Noul. Erro comum deste passo: transformar um sim/não em Choice de duas opções só pra ganhar um campo confidence, quando o valor do Noul já diz tudo que aquele confidence diria

2. Existe ordem real entre as alternativas? Se dá pra dizer "esse é maior/pior/mais avançado que aquele", é Score. Se não dá, é Choice. Erro comum deste passo: inventar ordem onde não tem. billing, technical e sales num array ordenado não faz sentido, e o modelo passa a considerar uma vizinhança entre níveis que não existe no seu domínio

3. O conjunto é fixo e cabe nos limites? Choice aceita até 255 opções, Score aceita de 2 a 10 níveis. Erro comum deste passo: tentar enfiar escala de 1 a 100 num Score, ou usar Choice pra um conjunto que cresce sozinho (produto novo, cliente novo, categoria nova). Conjunto fixo é fixo

4. Você precisa de decisão relativa ou de julgamento absoluto por rótulo? Se a pergunta é "qual desses?", é Choice. Se é "esse aqui se aplica, sim ou não?" e a resposta pode ser não pra todos, é Noul por rótulo. Erro comum deste passo: usar Choice quando nenhuma das opções serve. O Choice é obrigado a distribuir a probabilidade entre o que você deu, então ele vai eleger um vencedor de qualquer jeito

Esse último item merece seção própria, porque é o erro mais caro dos quatro

Choice e Noul na mesma lista: decisão relativa versus absoluta

Um Choice sobre um conjunto de opções e um Noul por opção respondem perguntas diferentes, mesmo rodando sobre a mesma lista

O Choice é relativo: ele olha só as opções que você deu e decide qual delas ganha, distribuindo a probabilidade entre elas até somar 1

Cada Noul é absoluto e independente: ele julga aquele rótulo sozinho, sem comparar com os vizinhos, e pode voltar baixo em todos ao mesmo tempo

Na prática, com aquele ticket das filas: o Choice entre billing, technical e sales sempre aponta uma fila, mesmo pra uma mensagem que é só um "obrigado, valeu"

Já um Noul por fila ("isso é assunto de billing?", "isso é assunto de technical?") pode voltar baixo nas três, e a leitura fica clara: não é pra nenhuma

Ou seja, o Choice sempre te dá um vencedor. O Noul é quem te deixa dizer "nenhuma"

O cookbook de sugestão de skill usa os dois tipos sobre a mesma lista curta, e é um padrão muito massa de copiar:

• Choice pra escolher qual skill
• Nouls pra decidir se vale sugerir alguma

Os Nouls funcionam como porteiro, o Choice como juiz. Se todos os Nouls voltarem baixos, você simplesmente não sugere nada e nem olha o resultado do Choice

Sem isso, você monta um sistema que sugere skill pra tudo, porque ele nunca teve a opção de ficar calado 😛

Combinando vários tipos no mesmo request

A boa notícia: você não precisa escolher UM tipo por requisição

1. Monte as perguntas num mapa. Cada pergunta vai com um ID escolhido por você, e a resposta tipada volta sob aquele mesmo ID. Erro comum deste passo: ID genérico tipo q1, q2. Daqui duas semanas ninguém sabe o que era o q3, e o ID é justamente o que amarra pergunta e resposta no seu código

2. Aponte todas pro mesmo state. As perguntas são avaliadas contra o mesmo state em paralelo, cada uma devolvendo o seu tipo

{
  "model": "jev-latest",
  "state": "Relato: ao salvar o formulario, os dados do cliente sao apagados do banco",
  "questions": {
    "fila": {
      "type": "choice",
      "criteria": { "billing": null, "technical": null, "sales": null }
    },
    "gravidade": {
      "type": "score",
      "criteria": [
        "cosmetico, nao afeta o uso do produto",
        "incomoda, mas existe contorno simples",
        "funcionalidade principal quebrada",
        "perda de dados ou sistema indisponivel"
      ]
    },
    "precisa_humano": { "type": "noul" }
  }
}

3. Prefira muitas perguntas estreitas a uma pergunta larga. O padrão recomendado pela documentação é fazer várias perguntas estreitas e independentes sobre o mesmo state numa requisição só, já que elas rodam em paralelo e o seu código combina os sinais sem round trips extras. Erro comum deste passo: criar um Choice gigante com opções que são combinações de coisas ("technical e urgente", "technical e normal", "billing e urgente"). Isso é duas perguntas fantasiadas de uma, e explode o criteria sem necessidade

4. Leve o custo em conta na hora de dividir. A cobrança do Jev é por token de entrada e os tokens de saída são gratuitos. Como as perguntas compartilham o mesmo state numa requisição só, quebrar em perguntas estreitas não significa pagar o state várias vezes

Essa lógica de separar responsabilidade por pergunta é bem parecida com a de escolher o modelo por tipo de tarefa: cada peça faz uma coisa e faz bem, em vez de uma peça só tentando adivinhar tudo

Sinais de que você escolheu o tipo errado

Agora a parte de debug. Os sintomas são bem característicos, dá pra diagnosticar sem chutar

O confidence vive baixo, com empate entre duas ou três opções

Causa provável: aquelas opções não são categorias, são graus da mesma coisa. O modelo fica dividido entre "médio" e "alto" porque a fronteira entre elas é arbitrária, não categórica

Correção: virou Score. Descreva os degraus em ordem e deixe a vizinhança entre níveis explícita

Pra entender por que o empate derruba o número, a documentação de confiança mostra a fórmula pra três opções: (3 vezes a maior probabilidade, menos 1) dividido por 2

Empate perfeito (cada opção com um terço) dá exatamente 0. Vencedor claro (probabilidade 1) dá exatamente 1

O confidence é um valor de 0 a 1 derivado do formato da distribuição, e existe justamente pro seu código usar como limiar sem refazer essa conta na mão

Seu Choice tem opções que você listou em ordem

Causa: se você escreveu baixo, medio, alto no mapa do criteria, você já sabia que tinha ordem ali. Só não contou pro modelo

Correção: Score, com array do menor pro maior, e usa o legend da resposta pra logar a descrição junto do número

Você dispara um Noul por opção, mas a pergunta era "qual delas?"

Causa: confundir absoluto com relativo. Nouls independentes podem voltar todos altos, e aí você fica sem critério de desempate

Correção: Choice, que é relativo por natureza e já devolve a probabilidade de cada opção somando 1. Se você precisa das duas respostas, use o padrão combinado do cookbook (Choice pra qual, Nouls pra se vale)

Seu Score tem níveis que não têm ordem real

Causa: a escala foi montada por conveniência de código, não por semântica do domínio

Correção: Choice. Se você não consegue completar a frase "o nível 2 é mais ______ que o nível 1", não é espectro

Você bateu nos limites

Causa: mais de 255 opções num Choice ou mais de 10 níveis num Score costuma ser sinal de modelagem larga demais, não de limite apertado

Correção: quebre em várias perguntas estreitas no mesmo request. Duas perguntas de 12 opções resolvem melhor que uma de 144

E a prevenção, que vale pros três tipos: não existe limiar de confiança único

A documentação do roteamento por confiança é clara nisso: ações diferentes no mesmo sistema devem ser barradas em níveis diferentes, conforme a consequência do erro

Os exemplos que ela traz: rotear pra um humano abaixo de 0,5, prosseguir com confirmação acima de 0,9

A recomendação é começar conservador, testar com dados próprios e ajustar. Ou seja: o número certo pro seu caso não está em blog nenhum, ele sai dos seus dados 😀

Vídeo: contexto sobre modelos e ferramentas de IA

Pra quem tá chegando agora nesse mundo de rodar modelo e ferramenta de IA no fluxo de trabalho, este vídeo do canal mostra o passo a passo do GLM-5 no OpenClaw, do zero:

Conclusão

No fim, a escolha entre os tipos de pergunta do Jev cabe em três critérios, e nenhum deles é de implementação:

• é binário? Noul, e o valor entre 0 e 1 já é a sua confiança
• existe ordem real entre as alternativas? Score, array do menor pro maior, índice começando em 0
• é conjunto fixo sem ordem? Choice, mapa opção: descrição, null quando não precisa de detalhe

O próximo passo é prático: monte um request com poucas perguntas estreitas sobre o mesmo state, olhe o confidence que volta nos SEUS dados e calibre os limiares por tipo de ação, não um limiar geral pro sistema todo

Se o confidence vive empatado num Choice, quase sempre a resposta é que aquilo era Score. Faça o teste!

Até o próximo post!