O que são modelos de decisão em IA? Como funcionam e exemplos-chave

Imagine que você senta em um restaurante e o garçom pergunta: “Com ou sem gás?”. Você não responde com um parágrafo sobre suas preferências de hidratação; você escolhe uma das duas opções oferecidas.

Agora pense em como usamos grandes modelos de linguagem (LLMs) na maioria dos apps hoje. Fazemos perguntas como “Este chamado de suporte é sobre cobrança, envio ou devoluções?” e o modelo nos devolve uma frase completa, que a gente ainda precisa interpretar com código. Na prática, só havia três respostas possíveis, mas pagamos por todo um raciocínio mesmo assim.

É essa a lacuna que esse novo tipo de modelo quer preencher. Em setembro de 2026, uma startup chamada TypeSafe AI lançou o Jev, um modelo que não escreve texto.

Em vez disso, ele atribui pontuações a um conjunto fixo de respostas e informa a probabilidade de cada uma. Em poucas semanas, OpenAI, Cloudflare, Perplexity e Microsoft liberaram suas próprias versões, mostrando o ritmo acelerado desse campo.

Neste artigo, quero explorar o que são esses modelos de decisão em IA, como funcionam e de onde veio a ideia (ela é bem mais antiga do que o hype sugere). Também vou comentar o que mostraram benchmarks independentes.

Modelos de decisão em poucas palavras

• Um modelo de decisão em IA recebe um input e uma lista de respostas permitidas e retorna uma probabilidade para cada resposta, em vez de gerar texto.
• Como o modelo pontua as respostas em uma única passada, a TypeSafe relata o Jev respondendo entre 70 e 500 milissegundos, e o resultado já pode ir direto para um if no seu código.
• A ideia não é nova. Zero-shot classifiers, rerankers e verifiers já pontuam candidatos há anos, e os lançamentos de 2026 da TypeSafe, OpenAI, Cloudflare, Perplexity e Microsoft basicamente empacotam isso melhor.
• Nos testes independentes de guardrails da Red Hat, os modelos de decisão não deram respostas mais rápidas, baratas ou melhores do que LLM-as-a-judge, e um classificador pequeno treinado chegou perto no teste de prompt injection.
• Eles funcionam melhor como filtros rápidos e baratos em volta de um LLM. Teste as probabilidades nos seus próprios dados antes de definir limiares.

O que são modelos de decisão em IA?

Um modelo de decisão em IA é um modelo que recebe um input e um conjunto de respostas permitidas e retorna a probabilidade de cada resposta, sem gerar texto livre.

A grande sacada desses modelos é que a saída já vem estruturada.

Você nunca precisa analisar uma frase, porque o modelo só consegue devolver uma das respostas que você forneceu. Isso significa que o resultado pode ir direto para um if no seu código.

Gosto de pensar nessa diferença como dois tipos de prova.

Um grande modelo de linguagem faz uma prova dissertativa, escrevendo a resposta palavra por palavra, enquanto um modelo de decisão faz uma prova de múltipla escolha e ainda te diz o quão seguro está em cada opção (um score de confiança).

Os três tipos de pergunta

O Jev e a maioria das alternativas ao Jev suportam três tipos de perguntas:

• Choice: escolhe uma opção de uma lista (o Jev permite até 255 opções), com probabilidade para cada uma.
• Noul: a probabilidade de uma afirmação ser verdadeira, que é o nome da TypeSafe para uma pergunta de sim/não.
• Score: uma posição em uma escala ordenada, como uma rubrica de 1 a 5.

A TypeSafe também tem um tipo experimental chamado Box para localizar coisas em imagens, que vou deixar de lado aqui.

Deixa eu te dar um exemplo da própria documentação da TypeSafe.

Você pode enviar um state (que é só o texto que quer que o modelo analise) e um mapa de questions. Para uma pergunta de escolha, cada opção vem com uma breve descrição em um campo chamado criteria.

{
  "model": "jev-latest",
  "state": "My running shoes arrived in the wrong size. Can I swap them for a size 10?",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "returns": "Exchanges, wrong or damaged items",
        "shipping": "Delivery status, delays, lost packages",
        "billing": "Charges, invoices, payment problems"
      }
    }
  }
}

E esta foi a resposta respectiva:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": {
        "shipping": 0.0,
        "returns": 1.0,
        "billing": 0.0
      }
    }
  }
}

Não há texto para interpretar.

Você recebe a opção escolhida, a probabilidade de cada opção e um valor de confiança derivado da maior probabilidade — quanto mais “achatada” a distribuição, menor a confiança. Na documentação, um chamado mais confuso que menciona tamanho errado e cobrança em duplicidade divide a probabilidade entre returns (0,61) e billing (0,35), e a confiança cai para 0,42.

Por que a TypeSafe chama de modelo “Sistema 1”

A TypeSafe descreve o Jev como um “System One Model”, pegando emprestado do livro Pensando, rápido e devagar, de Daniel Kahneman. Por quê?

Em linguagem simples, o Sistema 1 é seu julgamento rápido, de intuição, e o Sistema 2 é seu raciocínio lento, passo a passo.

Um modelo de decisão é pensado para ser o rápido.

Um alerta: o Sistema 1 também é a parte do cérebro que comete erros rápidos, e, para crédito da TypeSafe, sua própria documentação lista abertamente onde o Jev erra. Voltaremos a isso já já.

Esclarecendo o nome

Uma coisa que me confundiu quando li sobre isso pela primeira vez é que “modelo de decisão” já significa outras coisas. Pode se referir a:

• Tabelas de decisão em softwares de regras de negócio.
• O Decision Transformer em aprendizado por reforço, que de fato gera ações — quase o oposto do que estamos discutindo.
• Modelos de escolha em economia.

Então, só para ficar claro: neste artigo, “modelo de decisão” significa apenas a nova categoria de modelos lançada no fim de 2026 que pontua respostas tipadas em vez de escrever texto.

Como funciona a geração token a token

Antes de entrar no funcionamento dos modelos de decisão, ajuda ver como um LLM normal produz sua resposta. Acredito que isso facilita enxergar a diferença.

Um grande modelo de linguagem trabalha em loop.

Ele transforma nosso texto em tokens, prevê uma probabilidade para cada token do vocabulário, escolhe um, adiciona ao texto e repete.

Cada token extra na resposta significa mais uma passada forward pelo modelo.

Figura 1: Um LLM precisa de uma passada forward para cada token que escreve. Imagem original do autor.

Esse loop funciona bem para escrever e-mails, código ou explicações, mas, para decisões simples, pode causar alguns problemas:

• Você paga para gerar palavras que vai descartar.
• O modelo pode responder “Sim, porque…” quando você pediu só “sim” ou “não”, quebrando seu parser.
• Erros pequenos podem se acumular em saídas longas.
• Se você perguntar a um LLM quão confiante ele está, o número que ele escreve muitas vezes pouco reflete a realidade, como aponta John Berryman, da Arcturus Labs, em sua análise do Jev.

Modelos de decisão tentam resolver exatamente esses problemas.

Como funcionam os modelos de decisão: pontuando saídas

Agora vamos à mecânica.

Há três ideias importantes aqui:

1. Uma passada, em vez de um loop
2. De onde vêm as probabilidades
3. O que “calibrado” realmente significa

Vamos olhar cada uma delas com mais cuidado.

Uma passada, em vez de um loop

Um modelo de decisão lê seu input e as perguntas e produz um score para cada resposta permitida.

Esses scores normalmente viram probabilidades usando a função softmax. Como dá para notar, não há um loop longo, porque não há nada para escrever.

A documentação da TypeSafe também diz que perguntas no mesmo request são avaliadas em paralelo, então adicionar perguntas quase não muda o tempo de resposta.

É daí que vem a maior parte da velocidade, e a TypeSafe diz que o Jev costuma responder entre 70 e 500 milissegundos.

Figura 2: O mesmo chamado, respondido por um LLM e por um modelo de decisão. Imagem original do autor.

De onde vêm as probabilidades

Não existe uma única “arquitetura de modelo de decisão”.

A TypeSafe não publicou como o Jev funciona, mas há basicamente três jeitos de obter esses scores:

• Lendo as probabilidades de tokens do próprio LLM. Você lista as respostas como A, B e C, roda o modelo e olha só quão provável ele acha que “A”, “B” ou “C” é como próximo token. John Berryman, da Arcturus Labs, primeiro supôs que o Jev fosse um modelo encoder com uma cabeça de saída customizada e depois apontou um post no X de Harsha Gundala replicando algo parecido com probabilidades de tokens. Nada foi confirmado.
• Adicionando uma cabeça de pontuação. Um modelo encoder menor recebe uma camada de saída que pontua cada opção diretamente. O modelo open-source Laya usa ModernBERT assim.
• Usando um avaliador separado. Um segundo modelo, como um reranker ou um reward model, avalia cada candidato.

Não se prenda a qual é usado onde: os três chegam ao mesmo lugar, um número para cada resposta permitida.

O que significa “calibrado”

Para mim, esta é a parte que mais importa, então vou dar um exemplo.

Imagine que um modelo diga “70% de chance” em 100 perguntas diferentes. Se o modelo é bem calibrado, cerca de 70 dessas respostas devem estar certas.

Calibração importa porque probabilidades calibradas permitem definir limiares seguros no código, como “aprovar automaticamente acima de 90%, senão mandar para um humano”.

Se as probabilidades não batem com a realidade, esses limiares não significam nada.

Fornecedores treinam isso usando funções de perda que punem excesso de confiança.

A TypeSafe chama seu método de Reinforcement Learning for Calibrated Decisions (RLCD), enquanto a Cloudflare diz que combina cross-entropy com Brier loss nos modelos Clef.

Modelos de decisão não são uma ideia nova

Pode surpreender, mas a ideia de pontuar candidatos em vez de gerá-los existe há anos.

Na minha visão, modelos de decisão são a versão mais recente e conveniente disso, não uma invenção do zero. Aqui estão as principais famílias de modelos em que eles se apoiam.

Figura 3: Pontuar em vez de gerar remonta a 2019, e os modelos de decisão são a versão de 2026. Imagem original do autor.

Zero-shot classifiers

Lá em 2019, modelos como o BART-large-mnli já conseguiam classificar textos em rótulos para os quais não foram treinados.

Faziam isso pontuando afirmações como “este texto é sobre cobrança” para cada possível rótulo.

O time de segurança de IA da Red Hat sugere que modelos de decisão são, em essência, esses zero-shot classifiers com um novo nome.

Rerankers e cross-encoders

Se você já construiu um sistema de RAG, pode ter usado um deles. Primeiro você recupera rapidamente uma shortlist (por exemplo, 50 documentos), depois um cross-encoder lê sua pergunta e cada documento junto e atribui um score de relevância a cada par.

Nada é gerado; os documentos são apenas reordenados pelo score.

Reward models e verifiers

São avaliadores que pontuam respostas que um LLM já gerou.

Em 2021, pesquisadores da OpenAI mostraram que adicionar um verifier a um modelo trouxe um ganho em matemática de nível fundamental equivalente a tornar o modelo 30 vezes maior, o que é marcante.

Dois anos depois, o paper “Let’s Verify Step by Step” mostrou que pontuar cada passo do raciocínio funciona ainda melhor do que avaliar só a resposta final.

Best-of-N e generate-then-filter

A versão simples é gerar várias respostas, pontuar cada uma e ficar com a melhor. O AlphaCode, do DeepMind (2022), levou isso ao extremo ao gerar até um milhão de programas por problema, descartar cerca de 99% usando testes de exemplo e submeter apenas 10.

Em avaliações simuladas em torneios antigos do Codeforces, ficou, em média, no top 54,3% dos competidores humanos.

Um aviso: se você pressiona demais um avaliador imperfeito, a qualidade cai, porque o gerador passa a explorar as falhas do avaliador.

O termo técnico para isso é reward overoptimization.

LLM-as-a-judge

É quando um LLM grande avalia a saída de outro modelo.

Um estudo de 2023 encontrou mais de 80% de concordância do GPT-4 com julgadores humanos, mas também vieses, como preferir respostas mais longas ou a que aparece primeiro.

Modelos de decisão estão sendo vendidos em parte como substitutos mais baratos e estruturados para esses “juízes”.

Modelos baseados em energia e JEPA

Um modelo baseado em energia dá um score baixo de “energia” para um par input-resposta que combina bem e alto para pares que não combinam.

Escolher uma resposta vira encontrar a menor energia — novamente, pontuar candidatos.

Yann LeCun defende há anos que gerar token a token não é o caminho para inteligência real e que abordagens baseadas em energia e JEPA são uma direção melhor.

Principais modelos de decisão em 2026

Agora, vamos falar dos modelos que de fato foram lançados. As coisas estão mudando muito rápido, então vou ser breve em cada um.

Jev, da TypeSafe

A TypeSafe AI é uma startup de San Francisco fundada por Diogo Almeida, ex-pesquisador da OpenAI, e saiu do modo stealth em 15 de setembro de 2026 com o Jev e uma rodada seed de US$ 40 milhões liderada pela DCVC.

O Jev é uma API hospedada. Em produção, aceita apenas texto; entrada por imagem é experimental e exige um header de opt-in. A precificação cobra pelos tokens de entrada, e as saídas são gratuitas, o que faz sentido quando a saída são só alguns números.

O Jev 1.14 saiu em 14 de outubro, embora o alias jev-latest ainda aponte para a 1.13.0, a versão que a Red Hat testou mais adiante neste artigo.

O lançamento gerou muito burburinho. A Vercel disse que cerca de 13% dos seus times pagos testaram o Jev pelo AI Gateway nas primeiras 24 horas, embora fosse gratuito no gateway naquele momento.

Decisions API da OpenAI

A OpenAI anunciou sua Decisions API no DevDay em 29 de setembro de 2026.

Ela funciona com perguntas definidas pelo usuário que têm um conjunto fixo de respostas e é construída sobre o GPT-6 Luna. Foi para beta público em 6 de outubro e também aceita imagens, algo que o Jev só suporta de forma experimental.

Clef, da Cloudflare

A Cloudflare lançou o Clef e um Clef-flash menor em 1º de outubro de 2026, com pesos abertos e hospedagem no Workers AI. Ambos são baseados em modelos Qwen e aceitam requisições no estilo do Jev, então código escrito para o Jev pode ser apontado para o Clef com pouquíssimas mudanças.

Outros modelos

O que mais me chamou a atenção ao compilar esta seção é que a maioria dos modelos abertos e de big tech aqui são versões ajustadas de LLMs normais. O Laya é a exceção: é um encoder com uma cabeça de decisão. Os detalhes internos do Jev não foram divulgados.

Na minha opinião, isso reforça a ideia de que a verdadeira inovação está no empacotamento (isto é, na interface e no treino para calibração), não apenas em uma arquitetura totalmente nova.

Modelos de decisão vs LLMs vs classificadores

A forma mais clara de decidir quando usar cada um é comparar:

Quando usar qual

Minha regra prática é:

• Respostas limitadas e sem dados de treino: um modelo de decisão é uma ótima escolha.
• Uma tarefa, muitos dados rotulados e limite de latência apertado: um classificador ajustado é difícil de bater.
• Saída aberta: use um LLM.
• Problema difícil com uma forma barata de verificar respostas: use um LLM com um verifier.

Acredito que os melhores sistemas combinam tudo isso.

Vejo modelos de decisão atuando como “portões” rápidos ao redor de um LLM. Um portão decide:

• Qual ferramenta chamar.
• Se um input é seguro.
• Se um resultado precisa de um humano.

Assim, o LLM caro só roda quando realmente é preciso escrever algo.

O que mostram testes independentes

Esta seção é a mais importante, porque muitos números grandes que você vê online vêm dos próprios fornecedores. A própria TypeSafe admite que os ganhos de velocidade e custo de manchete estão no limite superior do que você veria no uso real.

O benchmark de guardrails da Red Hat

Em outubro de 2026, a equipe de segurança de IA da Red Hat comparou nove configurações de guardrail em duas tarefas: detectar prompt injection e conteúdo inseguro.

DiffusionGemma é um modelo Gemma de difusão de texto servido via vLLM.

Aqui estão os resultados mais interessantes:

O Jev ficou em primeiro em content safety, 0,67 ponto percentual à frente do DiffusionGemma (o juiz Qwen ficou em terceiro), e o juiz Qwen ficou em primeiro em prompt injection.

Essa divisão é por que a Red Hat pode dizer que, no geral, modelos de decisão não mostraram ganho de qualidade sobre LLM-as-a-judge.

Mas o que mais me interessa é que um classificador de 200 milhões de parâmetros ficou só 0,3 ponto percentual atrás em prompt injection, com latência mediana abaixo de 100 ms, contra cerca de 348 ms do Jev.

A latência do Jev incluiu uma travessia do Atlântico, já que os testes rodaram do Reino Unido e os servidores da TypeSafe ficam nos EUA.

Esse trajeto só explica a diferença para modelos locais em CPU. Qwen, Nemotron e DiffusionGemma também rodaram em um cluster nos EUA, e o Qwen ainda assim foi mais rápido que o Jev.

Mesmo assim, a Red Hat concluiu que, nos testes deles, modelos de decisão não deram respostas mais rápidas, baratas ou melhores do que LLM-as-a-judge — com exceção do Laya, cujo tamanho pequeno é uma vantagem real se você conseguir contornar suas limitações via prompt.

O paper “Just Ask Jev”

Um artigo de pesquisa de pesquisadores universitários, publicado no arXiv em setembro de 2026, testou o Jev em 44 benchmarks de alignment.

Os resultados foram mistos de um jeito interessante:

• O Jev foi bom em ranquear falhas de alignment acima de não-falhas, com AUROC mediana de 0,886 nos 31 benchmarks que suportam uma pergunta genérica de sim/não. AUROC mede quão bem um score ranqueia exemplos positivos acima dos negativos (0,5 é acaso; 1 é ranking perfeito).
• Custou cerca de US$ 0,30 para um trabalho que custou cerca de US$ 18,96 com juízes LLM, nos 19 benchmarks que usam um juiz via API.
• Foi bem calibrado quando todos os benchmarks foram agrupados, mas não dentro de cada benchmark individual.
• Manter apenas metade das respostas mais distantes de 50% elevou a acurácia mediana de 0,793 para 0,933.
• Os autores citam limites: uma versão do Jev, inglês apenas, modelos-alvo pequenos (2B a 7B) e rótulos gerados em sua maioria por avaliadores existentes.

Acho que o ponto da predição seletiva é muito útil na prática.

Ele mostra que um desenho simples em que o modelo de decisão resolve os casos fáceis e passa os incertos para um LLM ou uma pessoa é uma boa estratégia.

Mão na massa: construa um modelo de decisão a partir de um LLM pequeno

Vamos agora construir nosso próprio modelo de decisão.

Vamos transformar um LLM aberto pequeno em um modelo de decisão usando o truque de probabilidade de token que vimos antes e depois checar se dá para confiar nas probabilidades.

Primeiro, precisamos instalar os pacotes (dá para rodar tudo em um Colab gratuito):

pip install transformers torch datasets sentence-transformers numpy

Passo 1: transformar um LLM em avaliador

Vamos usar o Qwen2.5-0.5B-Instruct, pequeno o suficiente para rodar em CPU.

A ideia é simples: rotulamos as opções com letras, rodamos o modelo uma vez e olhamos apenas as probabilidades dessas letras como próximo token.

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

model_name = "Qwen/Qwen2.5-0.5B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)
model.eval()

def option_logits(state, question, options):
    letters = [chr(ord("A") + i) for i in range(len(options))]
    option_text = "\n".join(f"{l}. {o}" for l, o in zip(letters, options))
    messages = [
        {"role": "system", "content": "Answer with a single letter only."},
        {"role": "user", "content": f"{state}\n\nQuestion: {question}\n{option_text}"},
    ]
    prompt = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True
    )
    inputs = tokenizer(prompt, return_tensors="pt")

    with torch.no_grad():
        next_token_logits = model(**inputs).logits[0, -1].float()

    letter_ids = [tokenizer.encode(l, add_special_tokens=False)[0] for l in letters]
    return next_token_logits[letter_ids]

def decide(state, question, options, temperature=1.0):
    logits = option_logits(state, question, options)
    probs = torch.softmax(logits / temperature, dim=-1)
    return {o: round(p.item(), 3) for o, p in zip(options, probs)}

Note que nunca chamamos generate(). Fazemos uma passada forward, guardamos os scores de “A”, “B”, “C” etc. e descartamos todo o resto.

print(decide(
    state="My running shoes arrived in the wrong size. Can I swap them for a size 10?",
    question="Which team should handle this?",
    options=["returns", "shipping", "billing"],
))

print(decide(
    state="The app crashes every time I open the settings page.",
    question="Does this message describe a software bug?",
    options=["yes", "no"],
))

E é isso mesmo. Acabamos de criar um modelo de decisão funcional em cerca de 30 linhas.

Uma pergunta de sim/não é simplesmente uma pergunta de escolha com duas opções.

Passo 2: identificar as manhas

Agora vamos ver onde essa versão simples começa a patinar.

Tente embaralhar a ordem das opções e rode a mesma pergunta de novo:

options = ["returns", "shipping", "billing"]
state = "My shoes arrived late and in the wrong size, and I was charged twice."
question = "Which team should handle this?"

print(decide(state, question, options))
print(decide(state, question, list(reversed(options))))

Em inputs confusos como este, é comum vermos as probabilidades mudarem só porque as opções mudaram de lugar.

Isso é chamado de viés de ordem, e a TypeSafe lista, inclusive, uma tendência para a primeira opção como uma das fraquezas conhecidas do Jev.

Você também pode ver o modelo dar respostas perto de 100% com certa frequência. Berryman fez um teste legal no próprio Jev: disse que uma moeda cai em cara 60% das vezes, e a pergunta de sim/não retornou 0,58, bem perto.

Mas a pergunta de escolha (“cara ou coroa?”) retornou 0,99 para cara, porque a probabilidade colapsou na opção mais provável.

Passo 3: medir e corrigir a calibração

Este é o passo que acho que todo mundo deveria rodar. Vamos pegar 400 notícias do dataset AG News (cada uma é um título com uma descrição curta), que tem quatro tópicos, e verificar se nossas probabilidades batem com a realidade.

import numpy as np
from datasets import load_dataset

data = load_dataset("fancyzhx/ag_news", split="test").shuffle(seed=42).select(range(400))
labels = ["World", "Sports", "Business", "Science and technology"]
question = "What is the topic of this news headline?"

all_logits, targets = [], []
for row in data:
    all_logits.append(option_logits(row["text"], question, labels))
    targets.append(row["label"])

all_logits = torch.stack(all_logits)
targets = torch.tensor(targets)

Depois, precisamos medir a calibração. O Expected calibration error (ECE) agrupa previsões em faixas de confiança e verifica o quanto a confiança média em cada faixa se afasta da acurácia real.

Para ficar claro: quanto menor, melhor.

def expected_calibration_error(probs, targets, n_bins=10):
    confidences, predictions = probs.max(dim=-1)
    correct = (predictions == targets).float()
    bins = np.linspace(0, 1, n_bins + 1)
    ece = 0.0
    for lo, hi in zip(bins[:-1], bins[1:]):
        mask = (confidences > lo) & (confidences <= hi)
        if mask.any():
            gap = abs(correct[mask].mean() - confidences[mask].mean())
            ece += mask.float().mean() * gap
    return float(ece), float(correct.mean())

Agora vem o truque.

Dividimos os dados em dois, usamos a primeira metade para achar uma temperatura que deixe as probabilidades mais honestas e testamos na segunda metade.

Uma temperatura acima de 1 suaviza previsões autoconfiantes demais, enquanto abaixo de 1 acentua previsões tímidas demais.

calib_logits, test_logits = all_logits[:200], all_logits[200:]
calib_targets, test_targets = targets[:200], targets[200:]

def nll(temperature):
    probs = torch.softmax(calib_logits / temperature, dim=-1)
    picked = probs[torch.arange(len(calib_targets)), calib_targets]
    return -torch.log(picked + 1e-12).mean().item()

temperatures = [float(t) for t in np.linspace(0.5, 5.0, 46)]
best_t = min(temperatures, key=nll)

before = expected_calibration_error(torch.softmax(test_logits, dim=-1), test_targets)
after = expected_calibration_error(torch.softmax(test_logits / best_t, dim=-1), test_targets)

print(f"Best temperature: {best_t:.2f}")
print(f"Before: ECE={before[0]:.3f}, accuracy={before[1]:.3f}")
print(f"After:  ECE={after[0]:.3f}, accuracy={after[1]:.3f}")

A acurácia não muda, porque dividir por uma temperatura não altera qual opção fica em primeiro.

Só a confiança muda.

Seus números exatos vão variar conforme a execução, mas o ECE na metade de teste deve cair na maioria dos casos. Com apenas 200 itens de teste, a estimativa é ruidosa, então não tire conclusões de diferenças pequenas.

A lição é simples: um modelo ser calibrado em dados de outras pessoas não significa que está calibrado nos seus.

Passo 4: pontuar candidatos com um cross-encoder

Para mostrar como essa ideia de “pontuar, não gerar” é comum, aqui vai o mesmo conceito num cenário de RAG.

Um cross-encoder pontua cada passagem contra uma pergunta, e a gente só ordena:

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L6-v2")

query = "How do I get a refund for a double charge?"
passages = [
    "Our app supports dark mode on all devices.",
    "If you were charged twice, contact billing and we will refund the duplicate payment.",
    "Refunds are processed within five business days.",
    "You can change your password from the settings page.",
]

for result in reranker.rank(query, passages):
    print(round(float(result["score"]), 3), passages[result["corpus_id"]])

De novo, nada é gerado: o modelo só dá um número para cada candidato.

Casos de uso de modelos de decisão

Estes são os casos de uso que mais aparecem:

O ponto da robótica é o que eu pessoalmente mais gosto.

Berryman sugere que um modelo como o Jev poderia ficar entre um LLM lento fazendo planos de alto nível e os modelos cinemáticos que movem as juntas de um robô.

Vale notar, porém, que o famoso demo de Doom da TypeSafe alimentou o Jev com telemetria em texto, não imagens brutas.

Limitações de modelos de decisão

Modelos de decisão são úteis, mas não quero supervendê-los.

Aqui estão as principais limitações que encontrei para ter em mente:

• Ele só escolhe da sua lista. Se a resposta certa não está nas opções, o modelo não pode inventá-la; por isso a TypeSafe recomenda incluir “other” ou uma pergunta complementar de sim/não que verifique se algo se encaixa.
• Confiante e errado ainda é errado. Não ter respostas fora do formato não significa não ter erros.
• A calibração não se transfere automaticamente. Teste seus limiares em uma amostra pequena e rotulada dos seus próprios dados.
• Prompts não necessariamente se transferem. A Red Hat achou que um prompt afinado para o Laya aumentou sua acurácia em quase 18 pontos, mas piorou o Jev em cerca de 3,7 pontos.
• Não há explicação. Isso dificulta auditoria, então registre seus inputs e mantenha um LLM para casos que precisem de justificativa.
• Há pontos fracos conhecidos. A própria documentação da TypeSafe lista matemática, datas, contexto longo irrelevante, texto adversarial e viés para a primeira opção.

Considerações finais

Modelos de decisão em IA pegam uma ideia antiga — pontuar candidatos em vez de gerar respostas — e a tornam muito mais fácil de usar.

Você não precisa de dados de treino; recebe respostas tipadas; e pode fazer muitas perguntas de uma vez.

Na minha opinião, esse empacotamento é a verdadeira inovação.

Espero ver modelos de decisão ao redor dos LLMs como portões rápidos e baratos que resolvem as decisões simples, para que o modelo caro só rode quando realmente for preciso escrever algo.