HMDeveloper
Todos os artigos
rag
ragembeddingrerank

O problema do RAG é saber quando não encontrou nada

A busca vetorial sempre retorna um primeiro resultado. Um bom sistema sabe quando ele não ajuda.

O primeiro RAG que parece funcionar quase sempre engana. RAG é um sistema que busca trechos de documentos para ajudar um modelo a responder. Você pergunta sobre algo que está na base, a busca encontra um trecho parecido, o modelo responde, e parece que a memória está resolvida.

O teste de verdade vem quando a resposta não está lá.

A busca vetorial transforma textos em listas de números e procura os mais próximos. A similaridade de cosseno mede quanto esses números apontam na mesma direção. Ela organiza os resultados, mas não verifica se o assunto existe. Se a base não contém a resposta, ainda assim aparece um primeiro resultado. Muitas vezes, a nota é alta o bastante para parecer uma prova.

Depois, o modelo escreve usando o trecho que recebeu. O erro não aparece como erro. Parece uma resposta confiante, apoiada em um trecho que não ajuda.

Ser parecido não é ser relevante

"Mais parecido" compara opções dentro da base. Não diz o que é verdade. Se procuro algo que não existe, o sistema ainda escolhe o resultado mais parecido. O melhor entre opções ruins também é ruim.

Por isso, não basta perguntar qual trecho ficou no topo. É preciso saber se a nota passou de um limite que indica relevância para aquela base. Sem esse limite, o RAG nunca diz "não sei". Só troca um palpite por outro.

Mas o limite não vem da intuição. Cada base tem seu próprio piso de ruído.

O piso de ruído

O piso de ruído é a nota que um trecho aleatório costuma receber na sua base. Não é a nota de um tutorial nem de um teste do fornecedor. É a nota observada na sua base. Documentos longos, termos repetidos, nomes parecidos e linguagem padronizada podem elevar a similaridade, mesmo quando o trecho não responde à pergunta.

Sem medir isso, qualquer corte é um palpite. Um limite baixo aceita contexto ruim. Um limite alto faz o sistema dizer "não sei" mesmo quando havia resposta.

Na prática, teste perguntas cuja resposta você sabe que não existe e veja as notas. Depois, teste perguntas com resposta e veja onde aparecem as boas notas. A faixa entre esses dois grupos ajuda a calibrar o limite.

Reordenar e poder dizer não

Um embedding é uma representação numérica do texto que ajuda a encontrar assuntos próximos. O rerank é uma segunda avaliação: compara a pergunta e o trecho juntos. Os nomes são parecidos, mas as etapas fazem coisas diferentes.

O reordenador pode rebaixar um trecho que usa palavras parecidas, mas não responde à pergunta. Também ajuda a separar um trecho que só menciona o assunto daquele que traz a informação necessária. Em muitos sistemas, esse segundo passo melhora mais a qualidade percebida do que trocar o modelo que escreve a resposta final.

O mais importante é permitir que o sistema diga "nada aqui serve". Sem essa opção, todo RAG tenta justificar o trecho menos errado.

Português e tamanho dos trechos

Conteúdo em português também muda os resultados. Um modelo de embedding treinado só em inglês pode comparar mal termos, variações das palavras e estilos de escrita. Isso não aparece como erro no registro do sistema. Aparece como uma resposta mediana que parece aceitável, até alguém que conhece o assunto ler.

O tamanho do trecho importa tanto quanto o modelo. Um trecho grande dilui a informação: a pergunta combina com uma parte, mas o modelo recebe várias ideias juntas. Um trecho pequeno pode perder o contexto anterior. O pronome, a definição ou a condição pode estar no parágrafo anterior.

Por isso, trato o tamanho dos trechos como parte do produto, não como detalhe de preparação da busca. Se um trecho não tem contexto suficiente para ser citado sozinho, não deveria ser entregue sozinho. Se tem informação demais, vira ruído apresentado como fonte.

Onde isso falha

Um documento antigo ainda presente na busca pode ser pior que um documento ausente. O sistema o encontra, dá uma nota alta, e o modelo o trata como verdade. A ausência pode virar "não sei". Um documento antigo pode gerar uma resposta errada com fonte.

O medo excessivo também atrapalha. Um limite ajustado para nunca errar pode negar uma resposta que estava na base. Calibrar é aceitar uma troca: algum risco de aceitar um trecho ruim ou frustrar alguém com uma resposta que o sistema deixou passar. Fingir que dá para evitar ambos só esconde a decisão.

Ajudo equipes a usar agentes de IA no trabalho de engenharia. Se sua equipe está começando, vamos conversar.

Ver consultoria