Como encadear várias perguntas do Jev (Noul, Choice e Score) em uma sequência de decisões

Fala aí, beleza? Decisão de verdade quase nunca é uma pergunta só

É uma pergunta que puxa outra, que puxa outra, e se a primeira sair torta todo o resto desanda junto 😛

O Jev é o modelo da TypeSafe AI, apresentado em 15 de setembro de 2026 e aberto para todos desde 21 de setembro de 2026

Ele recebe o estado de um programa e devolve uma decisão tipada, com a probabilidade de cada opção

Neste post eu te mostro como compor Noul, Choice e Score em etapas dependentes: qual vem primeiro, quando parar e o que fazer quando uma etapa do meio volta incerta

Se liga num detalhe importante: o encadeamento é desenhado no SEU código, a partir das respostas da API

Pelo que está na documentação, não existe um recurso pra usar a resposta de uma pergunta como entrada de outra dentro da mesma chamada, então quem amarra as etapas é você

O que você precisa antes de montar a sequência

A API tem um endpoint único: POST https://api.typesafe.ai/v1/systemone

Ele recebe três campos:

• state: o estado do programa, em texto ou JSON
• model: um alias de modelo, como jev-latest
• questions: um mapa de perguntas nomeadas

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

Pra chamar, tu tem três caminhos: o SDK Python (pip install typesafe-sdk, com Python 3.10 ou superior), o SDK JavaScript (@typesafe-ai/sdk) ou um HTTP POST puro, sem SDK nenhum

A referência completa está na documentação da TypeSafe

E você precisa conhecer os três tipos de pergunta, porque escolher o tipo certo pra cada etapa é metade do trabalho:

Passo a passo para encadear Noul, Choice e Score

Bora ver na prática? Vou usar o exemplo que a própria documentação dá: triagem de tickets de suporte 🙂

1. Desenhe a árvore de decisão no papel

Por que começar pelo papel? Porque a ordem das perguntas define TUDO o que vem depois: quais etapas dependem de quais e quais só importam em certos ramos

Na triagem de tickets, primeiro vem a categoria (Choice) e a severidade (Score) só faz sentido se a categoria for bug

# Árvore da triagem (estrutura sua, não é sintaxe da API)
arvore = {
    "categoria": {                 # Choice, sempre lida
        "bug": "severidade",       # Score, só no ramo bug
        "duvida_de_uso": None,      # fim do fluxo
        "cobranca": None,           # fim do fluxo
        "outro": None,              # fim do fluxo
    }
}

O erro comum deste passo: abrir o editor e sair escrevendo pergunta sem a ordem definida

Aí você descobre no meio do caminho que uma etapa depende de outra que ainda nem existe…

2. Escreva as perguntas nomeadas no mapa questions

Cada nó da árvore vira uma entrada nomeada no mapa, com o tipo que casa com a pergunta: sim/não é Noul, escolher uma categoria é Choice, medir intensidade é Score

No Choice, a documentação recomenda incluir uma opção tipo "outro" ou "nenhuma das anteriores" quando a lista pode não cobrir todos os casos

questions = {
    # Choice: bug, dúvida de uso, cobrança, outro
    "categoria": ...,   # declaração conforme a documentação
    # Score: níveis de severidade (de 2 a 10 níveis)
    "severidade": ...,  # declaração conforme a documentação
}

payload = {
    "state": texto_do_ticket,
    "model": "jev-latest",
    "questions": questions,
}

O erro comum deste passo: lista de Choice que não cobre todos os casos

Sem a opção "outro", o modelo é empurrado a escolher alguma categoria que não serve, e essa resposta errada contamina todas as etapas seguintes

3. Envie tudo numa chamada só (speculative fan-out)

Aqui mora o pulo do gato 😀

O padrão se chama speculative fan-out: você manda numa única chamada todas as perguntas que PODEM ser necessárias, inclusive as que só importam em alguns ramos, e deixa o código decidir depois quais respostas usar

Por que isso compensa? As perguntas de uma requisição são avaliadas em paralelo, então adicionar pergunta pouco muda o tempo de resposta

Uma pergunta especulativa ignorada custa alguns tokens, e uma segunda ida e volta custa uma requisição inteira

# Uma chamada só, com categoria E severidade juntas
# chamar_jev é a sua função de chamada (SDK ou HTTP POST)
resposta = chamar_jev(payload)

O erro comum deste passo: fazer uma chamada por etapa, esperando a categoria voltar pra só então perguntar a severidade

É o jeito mais intuitivo de pensar (pergunta, espera, pergunta de novo), mas é justamente o que o fan-out evita

4. Percorra as respostas no código, na ordem da árvore

Agora as respostas estão todas na mão, e é o seu código que anda pela árvore: lê a primeira etapa e usa a resposta dela pra decidir qual é a próxima a ler

# Supondo que você já extraiu as respostas num dicionário por nome
# (o formato exato do retorno está na documentação)
cat = respostas["categoria"]
opcao = max(cat["probabilities"], key=cat["probabilities"].get)

proxima = arvore["categoria"].get(opcao)
if proxima == "severidade":
    sev = respostas["severidade"]
    # segue o fluxo de bug
else:
    # ramo sem severidade: a resposta de severidade é ignorada
    pass

O erro comum deste passo: ler respostas de ramos que não se aplicam

A severidade veio na resposta porque foi pedida de forma especulativa, mas se o ticket é dúvida de uso ela não significa nada, e usar esse valor vira bug silencioso

5. Defina as condições de parada de cada etapa

Cada etapa precisa de um critério de "posso seguir ou paro aqui?"

E o sinal de incerteza muda conforme o tipo:

• Noul: não tem campo confidence, a própria probabilidade P(sim), entre 0 e 1, já é o sinal de incerteza
• Choice e Score: usam o campo confidence, um número de 0 a 1 que resume a distribuição em probabilities

# Limites por ação: VOCÊ define, de acordo com o custo de errar
LIMITES = {
    "categoria": ...,
    "severidade": ...,
}

def etapa_confiavel(nome, resp):
    return resp["confidence"] >= LIMITES[nome]

O erro comum deste passo: procurar confidence na resposta do Noul (não existe) ou usar um threshold único pra tudo

A documentação é clara: o threshold é definido por ação, de acordo com o custo de errar

Errar a categoria de um ticket custa uma coisa, disparar uma ação irreversível custa outra bem diferente 🙂

6. Trate a etapa intermediária que volta com probabilidade baixa

Esse é o ponto que mais derruba sequência de decisão

Se uma etapa do meio vem incerta, o encadeamento PARA ali, e o caso vai pra uma pessoa ou pra um LLM mais lento, como sugere a documentação

if not etapa_confiavel("categoria", cat):
    encaminhar_para_revisao(ticket, etapa="categoria", resposta=cat)
    return  # não segue pra severidade

E o que confidence baixa quer dizer? Segundo a documentação:

• No Choice: costuma indicar que nenhuma opção se destaca
• No Score: costuma indicar níveis ambíguos ou multidimensionais, ou falta de informação no estado

Ou seja, confidence baixa recorrente é um recado pra você revisar o desenho: as opções do Choice se sobrepõem? Os níveis do Score misturam duas dimensões? O state que você manda tem informação suficiente?

Vale registrar esses encaminhamentos, e se quiser ir além tem um post aqui sobre como monitorar as decisões em produção

O erro comum deste passo: seguir pra etapa seguinte como se a resposta incerta fosse certa

É o clássico efeito dominó: a severidade de um ticket que talvez nem seja bug não vale nada, por mais confiante que ela pareça

Exemplos de sequências de decisão com o Jev

Os desenhos abaixo são ilustrações de ESTRUTURA, pra tu enxergar o padrão, não resultados testados

Triagem de tickets: Choice e depois Score

É o exemplo base da documentação

• Categoria (Choice, com opção "outro") e severidade (Score) vão juntas na mesma chamada
• O código lê a categoria primeiro e, se a confidence ficar abaixo do limite, para e encaminha
• Se for bug e a categoria estiver confiável, lê a severidade, que tem o próprio limite
• Em qualquer outra categoria, a severidade é descartada

Filtro com Noul e depois Choice

Aqui o fluxo começa com um portão de sim/não, tipo "este ticket é spam?"

• O Noul e o Choice de categoria vão juntos na mesma chamada (fan-out de novo)
• Se P(sim) do Noul está claramente alta ou claramente baixa, o código decide o ramo
• Se P(sim) fica no meio do caminho, a etapa é incerta: para e encaminha
• Só quando o filtro diz "não é spam" com segurança o código passa a ler a categoria

Quando a sequência vira o seu dia a dia

Se a mesma sequência roda o tempo todo e em volume alto, pode surgir a dúvida entre seguir com o Jev ou treinar seu próprio classificador, e aí vale comparar os dois caminhos com calma

Vídeo: tomando decisões como dev

Pra começar do zero no assunto de decisão, este vídeo do canal fala sobre tomar suas próprias decisões como dev

Próximo passo: monte sua primeira sequência

Recapitulando o desenho:

• Ordem definida no papel antes do código
• Todas as perguntas numa chamada só, com speculative fan-out
• Respostas lidas no seu código, seguindo a árvore e ignorando ramos que não se aplicam
• Condição de parada por etapa: P(sim) no Noul, confidence no Choice e no Score
• Threshold por ação, conforme o custo de errar
• Etapa incerta interrompe o fluxo e vai pra uma pessoa ou um LLM mais lento

Do lado do custo, a TypeSafe cobra US$ 0,042 por milhão de tokens de entrada, com saída gratuita, e informa tempo de resposta de ponta a ponta entre 70 ms e 500 ms, dependendo da tarefa

Por isso a pergunta especulativa a mais quase não pesa na conta, e a ida e volta extra é que dói

Agora é contigo: pega um fluxo real do teu projeto, desenha a árvore e transforma ela num mapa questions

Faça o teste! 😀

Até o próximo post!