A maioria das falhas de RAG nas empresas começa na busca. Meça a busca como um sistema próprio

Quando um assistente corporativo dá uma resposta ruim, o primeiro suspeito costuma ser o modelo. Muitas vezes, o modelo fez exatamente o que foi pedido: resumiu os documentos que recebeu. O problema estava nos documentos. A etapa de busca trouxe uma política desatualizada, a versão errada do contrato ou nada relevante.

A maioria dos times ainda avalia só a resposta final. Isso faz falhas de busca parecerem falhas do modelo, e leva à correção errada. O novo método da Cohere para avaliar busca é uma boa ocasião para separar as duas coisas.

O que a Cohere publicou

Em 30 de setembro, a Cohere apresentou o RCP-nDCG@10 (Rubric-Calibrated Preferences nDCG@10), uma forma de medir quão relevantes são os dez primeiros resultados de um sistema de busca.

O problema que ele ataca é real. As métricas tradicionais de busca dependem de julgamentos de relevância rotulados previamente para cada consulta. Quando um sistema mais novo encontra documentos relevantes que nunca foram rotulados, a métrica conta como erro. A Cohere relata que, entre os documentos que os seus benchmarks marcavam como irrelevantes, 28% foram considerados úteis por pessoas.

O RCP-nDCG troca os rótulos fixos por um juiz de IA calibrado, que avalia cada documento recuperado com dois sinais:

• uma rubrica de relevância com cinco perguntas de sim ou não, aplicada do mesmo jeito a todas as consultas;
• comparações em pares entre documentos, para estimar a ordem relativa.

Uma etapa de calibração, baseada na teoria de resposta ao item, combina os dois. Nas palavras da Cohere, as comparações definem a ordem e a rubrica coloca essa ordem em uma escala comum a todas as consultas.

Segundo a Cohere, o RCP-nDCG escolheu o sistema preferido pelos revisores humanos em 77% das vezes, contra 52% do nDCG tradicional, e nas maiores margens os revisores concordaram com ele em 97% dos casos. São resultados da própria Cohere. O artigo, o código e os dados foram publicados, o que permite a verificação independente.

1. Pergunta
2. Busca: os 10 primeiros documentos
3. Geração: resposta a partir desses documentos
4. Resposta ao usuário

Medir a relevância do que foi encontradoMedir fidelidade e correção da resposta

Por que isso importa para os times

A busca merece um placar próprio. Um sistema de RAG (busca em documentos da empresa antes de responder) são dois sistemas: um que encontra e outro que escreve. Eles falham de jeitos diferentes e se corrigem de jeitos diferentes. Chunking melhor, filtros de metadados, busca híbrida ou um reranker corrigem a busca. Um prompt ou um modelo melhor corrigem a geração. Sem métricas separadas, o time mexe na coisa errada.

Conjuntos de teste rotulados envelhecem. O conteúdo das empresas muda toda semana: novas políticas, novos produtos, novos contratos. Um conjunto rotulado há seis meses penaliza o sistema por encontrar documentos que nem existiam. Juízes guiados por rubrica são uma forma de manter a avaliação atual sem rotular tudo de novo à mão.

A rubrica é um artefato de negócio. “Relevante” significa uma coisa para um analista de sinistros e outra para um advogado. Escrever as cinco perguntas que definem relevância em um caso de uso é trabalho de quem é dono do caso de uso, e não só da engenharia.

Juízes de IA também precisam de calibração. O método da Cohere é explícito sobre calibração porque um juiz sem calibração só muda o problema de lugar. Qualquer juiz LLM deve ser conferido contra uma amostra de julgamentos humanos, e conferido de novo quando o modelo do juiz mudar. Fizemos o mesmo alerta na nossa análise sobre observabilidade de agentes.

O que isso significa no Brasil

Quase todos os benchmarks públicos de busca são em inglês. Um sistema que vai bem neles pode ir mal com documentos em português, com o vocabulário próprio de cada setor (sinistro, cláusula, nota fiscal, glosa) e com siglas internas. Para empresas brasileiras, isso significa três coisas:

• montar o conjunto de avaliação em português, com perguntas reais dos usuários e documentos reais da empresa;
• escrever a rubrica em português, com os termos que o negócio usa;
• verificar se o juiz de IA se sai bem em português, comparando as notas dele com as de revisores humanos daqui antes de confiar nelas.

O que fazer agora

1. Registre os resultados da busca separados das respostas, em todos os testes e em uma amostra da produção.
2. Escreva uma rubrica de relevância com o dono do caso de uso: o que torna um documento útil para aquela pergunta.
3. Monte um pequeno conjunto rotulado por pessoas e use-o para calibrar qualquer juiz de IA antes de confiar nas notas.
4. Acompanhe uma métrica de ranking ao longo do tempo, como o nDCG@10 ou uma variante calibrada, e repita quando conteúdo, embeddings ou chunking mudarem.
5. Corrija a busca antes de trocar o modelo. Quando as respostas pioram, olhe primeiro o que foi recuperado.

Em resumo

O RCP-nDCG@10 é uma contribuição de pesquisa, não um produto para comprar. O valor dele para as empresas está na disciplina que propõe: tratar a busca como um sistema em produção, com definição própria de qualidade, testes próprios e um dono. Como defendemos na nossa análise do AIP Evolve, da Palantir, a avaliação está virando a superfície de controle dos sistemas de IA. A busca é onde muitos desses controles deveriam começar.