Como medimos se a IA responde só com base no que foi aprovado

O problema

Um assistente que responde com base em documentos da empresa erra de dois jeitos, e eles puxam em sentidos opostos.

O primeiro é não achar o documento certo. A busca devolve trechos parecidos com a pergunta, mas não o que a responde, e o modelo escreve uma resposta plausível em cima do material errado.

O segundo é responder quando não deveria. A pergunta não tem resposta na base, a busca devolve alguma coisa mesmo assim, e o modelo preenche o vazio.

Melhorar o primeiro costuma piorar o segundo. Uma busca mais generosa encontra mais documentos certos, mas também traz mais trechos que só compartilham palavras com a pergunta e convencem o filtro de que existe resposta.

A régua

Antes de mudar qualquer coisa, montamos uma régua: 45 perguntas sobre 5 bases de teste, cada uma com o documento que deveria sustentar a resposta, marcado à mão.

• 31 perguntas legítimas: a resposta está na base.
• 14 perguntas sem resposta: parecem legítimas, mas a base não cobre. O comportamento certo é dizer que não encontrou.

Medimos quatro coisas:

Medida	O que diz
hit@1 e hit@5	Em quantas perguntas legítimas o documento certo veio em primeiro lugar, ou entre os cinco primeiros
MRR	Uma nota única para a posição do documento certo (1,0 é sempre em primeiro)
Sem resposta recusadas	Das 14 sem resposta, quantas o sistema recusou em vez de inventar
Legítimas barradas	Das 31 legítimas, quantas o sistema recusou por engano

A régua roda o mesmo código que roda em produção, não uma cópia. Se o código muda, a régua mede a mudança.

O que tínhamos

Na configuração anterior, o documento certo ficava entre os cinco primeiros em 48% das perguntas legítimas. O filtro de relevância contava quantos termos da pergunta apareciam nos trechos, e recusava só 4 das 14 perguntas sem resposta.

Uma busca melhor (fusão de busca lexical e semântica) subia o hit@5 para 74%, mas derrubava as recusas corretas para 1 de 14: os trechos lexicais continham as palavras da pergunta, e contar termos não separava mais nada. Ela ficou desligada por isso.

Faltava um sinal de relevância de verdade.

O juiz

Entre a busca e a resposta, colocamos um segundo modelo com uma tarefa só: dar nota de 0 a 3 a cada trecho encontrado, numa chamada única.

• 3: o trecho responde à pergunta.
• 2: contém parte importante da resposta.
• 1: mesmo assunto, mas não responde.
• 0: sem relação.

A memória só sustenta uma resposta se algum trecho chegar a nota 2. Abaixo disso, o assistente diz que não encontrou. Testamos o juiz com e sem raciocínio estendido: com raciocínio, ele ficou cinco vezes mais lento e recusou menos perguntas sem resposta. Ficou sem.

O juiz lê trechos de documento, e documento pode carregar instrução escondida. Por isso os trechos chegam a ele depois da triagem de prompt injection, como dado, e a única saída aceita é uma lista de números. Um trecho malicioso consegue, no máximo, inflar a própria nota, o que devolve o sistema ao comportamento de antes do juiz, não a um pior.

Os resultados

Medido com o código do motor, busca com fusão e juiz ligados:

Medida	Antes	Depois
hit@1	32%	71%
hit@5	48%	84%
MRR	0,402	0,759
Sem resposta recusadas	4 de 14	12 de 14
Legítimas barradas por engano	3	6

A última linha é o custo, e ele é real. Olhando caso a caso no experimento, a maior parte das legítimas barradas não tinha o documento certo entre os trechos encontrados, e ali recusar é o comportamento correto. As demais tinham o documento, mas o juiz deu nota 1 aos trechos. Esse é o erro que pagamos para parar de inventar.

Para reduzir esse custo, o juiz ganhou um modo parcial: quando a melhor nota fica em 1, em vez de recusar, o assistente recebe a instrução de pedir a leitura do documento inteiro ou declarar que a evidência é insuficiente. Ele não responde apoiado só nos trechos.

Quanto custa

Cada chamada do juiz usou cerca de 1.800 tokens de entrada e 24 de saída, com latência média de 0,87 segundo e custo próximo de US$ 0,0004. O registro de custo grava cada chamada, ligada ao turno que a originou, então o custo do juiz aparece separado do custo da resposta.

Se o juiz falha, estoura o tempo ou o teto de gasto, o turno não trava: cai no filtro anterior e segue.

O que esta medição não prova

• A régua é pequena. São 45 perguntas. Ela mostra direção e tamanho do efeito, não uma taxa que se transporta para qualquer base.
• O juiz é um modelo e oscila. Num experimento recusou 14 de 14; na medição com o código final, 12 de 14.
• Base de teste não é a sua base. Documentos curtos e específicos concorrendo com políticas longas que os citam foram o caso mais difícil. Cada operação tem o seu.

Por que isso importa fora da engenharia

Para quem decide, a pergunta não é “qual modelo vocês usam”. É “como vocês sabem que a resposta veio do documento certo, e o que acontece quando não vem”. Uma resposta honesta a essa pergunta tem método, número, custo e limite declarados. É o que tentamos fazer aqui, e é o que fazemos com a régua de cada cliente antes do piloto.