O Chrome Chama Suas Notas de Decisão de Calibradas. O Código Divide pela Soma

“The interface comments call the output calibrated. The code does no calibration step beyond the division above.” Dan Petrovic escreveu essa frase depois de ler as revisões de código por trás da interface experimental DecisionModel do Chrome. A divisão a que ele se refere pode ser citada inteira. As probabilidades do Chrome são “The engine’s raw scores, with negatives set to 0, divided by their sum”: as notas brutas do motor, com os negativos zerados, divididas pela soma.

Isso é uma normalização. Faz os números somarem um. E nada diz sobre se uma opção com nota de 90% acerta cerca de nove vezes em dez.

A distinção pesa por causa do papel que a Microsoft propõe para os modelos de decisão: ficar no caminho de controle de um agente, onde as aplicações usam a confiança para decidir quando agir, adiar ou pedir revisão. Na prática isso vira limiares: agir acima de um número, adiar entre dois, escalar abaixo. A Microsoft enuncia o requisito no post de lançamento do Decision-1, em uma frase: “Applications use confidence to decide when to act, defer, or ask for review, so a 90% prediction should be right about nine times out of 10 on representative cases.”

Ponha o código do Chrome ao lado dessa definição e a palavra “calibrado” nos comentários da interface vira uma alegação que o código não sustenta.

O que Petrovic encontrou nas revisões

O texto de Petrovic no DEJAN é concreto porque as revisões de código são abertas. Ele cita as revisões diretamente, e dois dos problemas que os revisores acharam são do tipo que um limiar sozinho não revela.

O primeiro foi um bug inicial, pego contra uma referência, em que “later options matched the reference 0/27”. O segundo é viés de posição. No Gemma 4 E2B as revisões relatam um efeito pequeno, de 1,3 ponto ou menos, e no TinyGemma um efeito severo: ele “picked A in 440 of 480 cases”. Em princípio, um modelo que cai na primeira opção quase sempre poderia emitir notas com cara de confiança, e depois da divisão elas continuariam somando um. Nada na aritmética avisa que a confiança está acompanhando a posição da opção, e a correção da resposta fica fora da conta.

Os dois números vêm de revisões de código abertas de um protótipo ainda em revisão. O código do motor do Chrome “is still in review and may change before release”, e os números de viés descrevem um retrato do desenvolvimento, sem relação garantida com o produto final. Eles servem por outro motivo. Mostram o que só apareceu porque os revisores mediram, e um time que constrói sobre uma API de decisão não sabe nada das suas notas até rodar o mesmo tipo de teste.

O problema do 0.85

Petrovic também rodou um teste próprio, reproduzindo o motor EmbeddingGemma do Chrome fora do Chrome. Nenhuma resposta no formato do Chrome chegou a 0.85, o limiar que o explicativo do Google usa antes de aplicar um filtro.

Pense no desenvolvedor que segue o explicativo. Ele coloca o filtro em 0.85 porque a documentação sugere. No teste de dez perguntas de Petrovic, nenhuma resposta no formato do Chrome chegou tão alto, então um filtro posto ali não teria disparado nenhuma vez, e o desenvolvedor veria um sistema quieto que parece estar funcionando. Um limiar copiado da documentação carrega a distribuição de notas de outra pessoa, e quando a distribuição muda, o limiar deixa de significar qualquer coisa sem avisar.

Petrovic deixa claros os limites do teste: “Our test uses 10 questions written and marked by one person, so it shows the direction of the differences between engines, not their size.” Essa ressalva precisa acompanhar o achado. Dez perguntas não dizem quanto as notas do Chrome erram. Dizem que o limiar de 0.85 e as notas do formato do Chrome, reproduzido por ele fora do Chrome, não parecem estar na mesma escala, o que basta para justificar medir antes de confiar em qualquer um dos dois.

A definição da Microsoft, e a tabela da própria Microsoft

O post de lançamento da Microsoft entra aqui como evidência secundária, por um motivo que precisamos declarar. O pipeline editorial da Victorino pontua artigos com o Jev, da TypeSafe, e a Microsoft compara o Decision-1 com o Jev. Leia o que segue com isso em mente. É também por isso que este texto começa por uma revisão independente do código do Chrome e usa a Microsoft sobretudo pela definição.

A definição é a parte útil. “A 90% prediction should be right about nine times out of 10 on representative cases” é testável. Nomeia a propriedade, nomeia uma razão e nomeia onde medir: casos representativos. Essa última expressão carrega quase todo o peso. Calibração medida no benchmark de um fornecedor informa sobre o benchmark.

O próprio post da Microsoft relata a posição do modelo nessa propriedade. O Microsoft-Decision-1 é “Third on calibration”, com 92.2, atrás do Jev 1.13.0 com 93.7 e do Quyet-1.0-Large com 93.1. São benchmarks próprios, publicados pelo fornecedor no lançamento. Citamos esses números para um ponto estreito: um fornecedor que define calibração com cuidado também a reporta como medida separada e ranqueada. Cada modelo conquista essa propriedade ou fica sem ela, e o rótulo de modelo de decisão não a concede a ninguém.

O mesmo post mostra por que tabelas de benchmark pedem leitura linha a linha. A latência do Decision-1 foi “measured through Foundry in the same region”, enquanto as latências dos outros modelos vêm de medianas do JevBench. Duas configurações de medição dividem a mesma comparação. Isso não torna os números de latência errados. Torna-os números de salas diferentes, e quem passa os olhos pela tabela vai compará-los como se viessem da mesma.

Por que a palavra pesa tanto

Uma nota bruta e uma probabilidade calibrada parecem idênticas num painel. As duas ficam entre zero e um. As duas aceitam limiar. A diferença só aparece no agregado, quando você agrupa as previsões pela confiança declarada e conta quantas vezes cada grupo acertou.

Um time pode configurar um limiar confiando no rótulo. Se a API diz “calibrado”, um desenvolvedor razoável lê uma nota de 90% como 90% de chance e põe ali o limiar de ação. Se o número é uma nota bruta normalizada, a taxa de acerto por trás dele nos dados desse time fica desconhecida até alguém contar. Pode ser bem menor ou maior. O limiar passa a codificar uma política que ninguém escolheu.

Já defendemos que um portão deve ser julgado pelo jeito como falha, e que três modelos de decisão deixam a decisão de se abster para quem os chama. O primeiro texto já propunha testar a confiança antes de definir um limiar. Este acrescenta o que o código mostra. A calibração está por baixo dos dois argumentos. Uma faixa de adiamento entre dois limiares só funciona se os números dentro dela significam o que a faixa supõe. Um caminho de abstenção movido por confiança não calibrada pode se abster nos casos errados. E quando uma verificação se comporta mal, o lugar de olhar é a própria verificação, que aqui é o passo que transforma notas em probabilidades.

Teste antes de definir o limiar

Esta recomendação é nossa. Nenhuma das fontes a faz. Ela se apoia na definição da Microsoft, aplicada a qualquer modelo que você esteja prestes a ligar num agente.

Antes que um número de confiança vire limiar de política, rode uma verificação de confiabilidade nos seus próprios casos representativos:

Colete casos rotulados do tráfego real. Amostre as decisões que o agente vai de fato enfrentar, com a resposta correta registrada por alguém que conhece o domínio. A ressalva de Petrovic vale para você também: um conjunto pequeno escrito por uma pessoa mostra direção, sem medir tamanho. Dimensione a amostra pela decisão.
Agrupe as previsões pela confiança declarada. Use faixas estreitas e fixas de confiança e coloque cada previsão na sua faixa.
Conte os acertos por faixa. Se a faixa em torno de 90% acerta bem menos do que cerca de nove vezes em dez, a nota não está calibrada nos seus dados, diga o comentário da interface o que disser.
Compare a distribuição das notas com o limiar que você pretende usar. Se nenhuma saída chega ao limiar, como Petrovic viu com 0.85 na reprodução dele, o portão é decorativo.
Procure viés de posição. Embaralhe a ordem das opções e rode de novo. Um modelo que escolhe a primeira opção na maior parte dos casos, como o TinyGemma nas revisões, pode passar numa checagem ingênua de acurácia em um conjunto de dados e falhar no seguinte.
Leia o passo de normalização, se puder. No caso do Chrome o código e as revisões são abertos, e mostram notas brutas divididas pela soma, sem passo de calibração depois. Onde o código é fechado, pergunte ao fornecedor qual passo produz a probabilidade e em quais dados ele foi ajustado.

Depois, defina os limiares a partir do que as faixas mostram, registre a data e a versão do modelo e repita a verificação quando qualquer uma mudar. Petrovic lembra que o código do motor ainda está em revisão e pode mudar antes do lançamento. Um limiar ajustado à normalização de hoje pode derivar com o próximo motor.

A palavra “calibrado” num comentário de interface declara uma intenção. As contagens por faixa nos seus próprios casos são a evidência. Só a segunda deveria definir política.

Fontes

DEJAN. “Chrome Decisions API: the prompts, limits, engines and code reviews behind DecisionModel.” Outubro de 2026.
Microsoft. “Introducing Microsoft-Decision-1, our model for fast decision-making.” Outubro de 2026.

Declaração: a Victorino pontua artigos do seu pipeline editorial com o Jev, um dos modelos com que a Microsoft compara o Decision-1.

A Victorino ajuda times de engenharia a testar as notas de confiança por trás das decisões de agentes antes que virem política: contato@victorino.com.br | www.victorino.com.br