Acurácia 0,000 com Confiança 0,952: Tire o Gatilho de Escalonamento do Modelo

Khmer: acurácia de 0,000 com confiança média de 0,952. A linha está na página de avaliação que a ConvAI Innovations publicou para o Laya, um motor de decisão multilíngue, e a página explica o número: nenhuma decisão correta em 100 perguntas, enquanto o modelo relatava cerca de 95% de confiança.

Outras linhas seguem o mesmo padrão. Armênio teve acurácia de 0,050 com confiança de 0,885. Hebraico, 0,060 com 0,964. Bengali, 0,080 com 0,945. Hindi, 0,100 com 0,941. Como referência, a página coloca o acaso na sua varredura MASSIVE de 20 opções em 0,050.

A frase que governa a tabela inteira é esta, em tradução nossa: “Em 51 idiomas, a confiança média do checkpoint em inglês nunca cai abaixo de 0,885, seja a acurácia de 82% ou de 0%.”

Considere uma regra de escalonamento na forma “mande o caso para um humano quando a confiança do modelo ficar abaixo de 0,9”. Aplique a regra às médias acima. Todas as linhas, com exceção do armênio, ficam acima de 0,9 em média, então a regra deixaria a maior parte desses casos com o modelo. O armênio tem média de 0,885, logo abaixo da linha, enquanto a acurácia está em 0,050. A regra foi feita para o momento em que o modelo não sabe. É exatamente nesse momento que ela fica muda.

Uma correção ao que publicamos em maio

Em maio defendemos que confiança calibrada é a primitiva de governança que faltava. Aquele texto recomendava definir limiares de roteamento, regras de escalonamento e filas de revisão em termos de confiança, para que confiar no número virasse uma mudança de configuração quando os modelos estivessem calibrados.

Parte disso precisa de correção, e a correção vem logo aqui. Calibração torna o número de confiança honesto sobre aquilo que o modelo sabe. Sobre aquilo que o modelo nem consegue enxergar, ela é muda.

A página do Laya torna essa distinção mensurável. Ela relata que o erro de calibração esperado cai de 0,466 para 0,081 com o ajuste de uma única temperatura escalar por tipo de pergunta, sobre a distribuição do domínio de destino. É um reparo grande e barato. A falha de confiança sem competência da tabela persiste depois dele. Minha leitura do porquê: um modelo incapaz de ler a escrita khmer segue sem sinal interno que o avise disso. O ajuste de temperatura reescala um sinal existente. Criar um sinal que nunca esteve lá está fora do alcance dele.

A página tira a conclusão em negrito, e eu traduzo: a confiança do próprio modelo “não dá aviso nenhum quando ele não consegue ler a escrita da entrada”, e “portanto, o gate por confiança não protege você. A decisão sobre qual modelo usar precisa ser tomada antes do forward pass.”

A calibração continua necessária. O que muda é o lugar onde o gatilho de escalonamento mora. Qualquer regra que pergunta a um único modelo o quanto ele tem certeza herda a cegueira desse modelo para entradas que ele nunca foi feito para ler.

Primeira metade: decida o roteamento antes da inferência

A primeira metade da correção é a própria conclusão da página do Laya, aplicada ao escalonamento. Se o modelo é incapaz de avisar, a decisão precisa acontecer antes dele. Ela precisa vir de algo que se verifica de forma determinística, antes do forward pass, sobre a própria entrada.

O exemplo a seguir é meu, e a página não o traz. Pegue um classificador de tickets de suporte treinado e avaliado em inglês. Antes que qualquer ticket chegue até ele, uma pré-checagem identifica a escrita em que o ticket foi redigido. Escrita latina vai para o classificador. Qualquer outra vai para um modelo avaliado naquela escrita, ou para uma fila humana, e o classificador nunca a vê. A pré-checagem fica neutra quanto ao conteúdo. Ela responde a uma pergunta que o modelo é incapaz de responder sobre si mesmo: essa entrada pertence à população em que o modelo foi medido?

A pergunta deve soar familiar. Já escrevemos sobre limiares medidos em uma população que não é a sua e sobre quem aprova o limiar de um classificador. A pré-checagem é a forma operacional da mesma preocupação. Ela mantém os números de um modelo presos às entradas em que esses números foram medidos.

O conteúdo da pré-checagem depende do seu sistema. Escrita, idioma, versão de schema e tipo de arquivo são candidatos. A presença de um campo do qual o modelo depende também. O ponto comum é que cada checagem roda fora do modelo e devolve uma resposta binária que independe da opinião dele.

Segunda metade: escale quando juízes independentes divergem

A segunda metade já roda em produção, na Cloudflare.

A Cloudflare publicou neste mês um texto sobre como a sua segurança client-side protege lojas virtuais de scripts maliciosos. A regra de escalonamento cabe em uma frase: humanos revisam apenas o que foi marcado como malicioso ou o que fica sem uma maioria clara de dois terços. O voto vem de um ensemble que usa modelos líderes de cerca de seis famílias diferentes, cada um rodando como agente em uma sessão nova e independente, com votos ponderados pela nota do modelo no Artificial Analysis Intelligence Index.

Vem então a frase que eu colocaria num slide para qualquer time que desenha um caminho de escalonamento, em tradução nossa: “Os modelos de fronteira às vezes divergem, principalmente nos scripts mais intrincados. Tratamos essa divergência como sinal, e não como ruído.”

Leia isso ao lado da tabela do Laya. Um único modelo relatando 0,952 sobre uma entrada ilegível para ele entrega um número e nenhum motivo para duvidar dele. Modelos de cerca de seis famílias, cada um na sua sessão, entregam uma distribuição. Quando eles se dividem, a divisão é o aviso. Nenhum modelo precisa saber que está errado. Basta que erre de um jeito diferente dos outros.

A Cloudflare também mostra o funil que fica na frente da revisão humana. Menos de 0,3% de todo o tráfego analisado é marcado como malicioso pela rede neural de grafos do primeiro estágio, e só esses casos vão para um modelo de segunda opinião antes de um humano entrar. A atenção humana vai para onde existe uma marcação ou um voto dividido.

O argumento da Cloudflare a favor da sua pilha de detecção se apoia em um ponto cego medido nas ferramentas estabelecidas. Em quatro operações, somando oito payloads, a Cloudflare relata que sete dos oito payloads estavam totalmente ausentes do VirusTotal, que o URLScan não deu veredito malicioso para nenhum deles, e que o Page Shield ML pegou os oito em tráfego real. Ausente do VirusTotal quer dizer que o VirusTotal estava sem registro deles. O VirusTotal não os classificou como benignos. A Cloudflare aplica o mesmo rigor a si mesma. Sobre o oitavo payload, diz que o histórico público não revela quando aquele veredito foi atribuído pela primeira vez. E afirma que continua sem observar se alguma requisição resultou em atribuição concluída ou em comissão paga.

Leia as duas fontes como fornecedores

As duas páginas são de fornecedores defendendo os próprios produtos, e cada número deve ficar preso à condição que a página declara.

Todo número do Laya foi medido pelo próprio fornecedor. A página diz isso: os números do Laya são medidos por ela, e os do Jev vêm de estudos independentes de terceiros (AbdelStark, nibzard) e da TypeSafe AI. A página também relata um contraexemplo contra si mesma: no Banking77, com 77 rótulos, o Laya marca 0,425 contra 0,870 do Jev, o sistema com que a página se compara. Não uso nenhuma das alegações de velocidade da página. O único material do Laya de que este argumento precisa é a tabela de confiança sem competência.

Os oito payloads da Cloudflare vêm de quatro operações. É uma amostra pequena, escolhida pela empresa que os pegou. Ela mostra que o Page Shield ML pegou esses casos onde o VirusTotal e o URLScan falharam. Uma taxa de detecção ela não estabelece, e a página não atribui a captura especificamente ao voto do ensemble.

Mais um limite. As duas fontes são independentes, e nenhuma foi escrita em resposta à outra. A convergência é síntese minha. O Laya mostra por que a confiança de um único modelo não pode ser o gatilho. A Cloudflare mostra um gatilho que independe da confiança de qualquer modelo isolado. Nenhuma das páginas faz o argumento da outra.

A regra em duas partes

Juntas, as duas metades formam uma regra curta para qualquer caminho de escalonamento.

Roteie antes da inferência. Decida qual modelo, se algum, vê uma entrada a partir de uma checagem determinística sobre a própria entrada. Os números de um modelo só valem para a população em que ele foi medido, e a checagem garante isso.
Escale pela divergência. Entre as entradas que passam na checagem, mande para um humano aquilo em que juízes independentes se dividem, mais o que eles marcam. A confiança autorrelatada de um modelo pode entrar no voto. Ela não pode ser o gatilho.

A calibração segue com trabalho dentro dessa estrutura. Uma confiança calibrada torna cada voto mais honesto e dá sentido à ponderação dos votos. O texto de maio acertou ao chamá-la de primitiva e errou ao deixá-la sozinha no portão. Para juízes LLM especificamente, nosso texto sobre a metodologia de golden set da Netflix trata de como avaliar cada um antes que ele vote.

Faça isto agora

Levante todas as regras de escalonamento que seus sistemas de IA rodam em produção e separe em duas listas. A primeira reúne regras que disparam pela nota de confiança de um único modelo. A segunda reúne regras que disparam por algo fora do modelo: uma checagem da entrada, um segundo modelo, um voto.

Para cada regra da primeira lista, responda por escrito a uma pergunta: o que acontece quando a entrada é algo que o modelo não consegue ler? Se a resposta honesta for “o modelo relata confiança alta e a regra fica calada”, existe uma linha khmer no seu sistema. Coloque uma pré-checagem na frente do modelo que teste a entrada contra a população em que ele foi avaliado. Depois escolha a decisão de maior risco da lista e dê a ela um segundo juiz independente, de outra família de modelos, com a divergência roteada para um humano.

Comece pelo inventário e por uma pré-checagem. O voto pode vir em seguida.

Fontes

ConvAI Innovations. “Laya: A Multilingual System 1 Decision Engine.” Setembro de 2026.
Cloudflare. “When scanners miss the attack: how Cloudflare client-side security protects storefronts.” Setembro de 2026.

A Victorino ajuda times de engenharia a redesenhar caminhos de escalonamento para que o gatilho não dependa da opinião de um modelo sobre si mesmo: contato@victorino.com.br | www.victorino.com.br