O problema do RAG não é achar, é saber que não achou
Busca vetorial sempre devolve um primeiro resultado. O sistema bom sabe quando esse resultado não serve.
O primeiro RAG que parece funcionar quase sempre engana. Você faz uma pergunta sobre um documento que está na base, a busca traz um trecho parecido, o modelo responde, e pronto: parece que a memória foi resolvida.
O teste de verdade vem quando a resposta não está lá.
Busca vetorial sempre devolve um primeiro resultado. Similaridade de cosseno ordena vetores; ela não julga se o assunto existe. Se a base não tem nada sobre a pergunta, o topo do ranking vem mesmo assim. E muitas vezes vem com um número alto o bastante para parecer evidência.
Depois disso, o modelo faz o que modelo faz: escreve em cima do contexto que recebeu. O erro não aparece como erro. Aparece como resposta confiante, com um trecho irrelevante servindo de alicerce.
Parecido não é relevante
"O mais parecido" é uma relação dentro da base, não uma decisão sobre o mundo. Se eu busco um assunto que não existe, o sistema ainda precisa escolher alguma coisa como mais parecida. O melhor resultado entre opções ruins continua sendo ruim.
Essa diferença muda o desenho do RAG. Não basta perguntar "qual trecho ficou no topo?". A pergunta certa é "o topo passou de um limiar que significa relevância para esta base?". Sem esse limiar, o RAG nunca diz "não sei". Ele apenas troca de chute.
O problema é que limiar não nasce de intuição. Cada base tem um piso de ruído.
O piso de ruído
Piso de ruído é a nota que um trecho aleatório costuma receber na sua própria base. Não na base de exemplo de um tutorial, não no benchmark do fornecedor, na sua. Documentos longos, termos repetidos, nomes parecidos e linguagem padronizada empurram similaridade para cima mesmo quando o trecho não responde nada.
Sem medir isso, qualquer corte é chute. Um limiar baixo demais aceita contexto ruim. Um limiar alto demais transforma o sistema em alguém que responde "não sei" para pergunta que tinha resposta.
O jeito prático é testar perguntas que você sabe que não existem e olhar que notas elas recebem. Depois testar perguntas que existem e ver onde as notas realmente boas aparecem. A zona entre as duas é onde mora a calibragem.
Rerank e o direito de negar
Embedding aproxima por vizinhança de assunto. Rerank lê pergunta e trecho juntos. Essa diferença é pequena no nome e grande no resultado.
O reordenador consegue derrubar um trecho que usa palavras parecidas mas não responde a pergunta. Ele também ajuda a separar o trecho que apenas menciona o tema daquele que contém a informação necessária. Em muitos sistemas, esse segundo passo muda mais a qualidade percebida do que trocar o modelo que escreve a resposta final.
O ponto principal não é só ordenar melhor. É permitir que o sistema diga: nada aqui serve. Sem esse direito de negar, todo RAG vira uma máquina de justificar o trecho menos errado.
Português e tamanho do trecho
Conteúdo em português também cobra sua conta. Um modelo de embedding treinado só para inglês pode aproximar mal termos, flexões e jeito de escrever. O sintoma não é uma exceção no log. É uma resposta medíocre que parece aceitável até alguém que conhece o assunto ler.
O tamanho do trecho decide tanto quanto o modelo. Trecho grande dilui a informação: a pergunta bate em uma parte, mas o gerador recebe várias ideias juntas. Trecho pequeno perde antecedente: o pronome, a definição ou a condição estava no parágrafo anterior.
Por isso eu trato chunking como parte do produto, não como detalhe de indexação. Se o trecho não carrega contexto suficiente para ser citado sozinho, ele não devia ser entregue sozinho. Se carrega coisa demais, ele vira ruído embalado como fonte.
Onde isso quebra
Documento desatualizado indexado é pior que documento ausente. O sistema encontra, dá nota alta, e o modelo lê como verdade. Ausência pelo menos pode virar "não sei"; desatualização vira resposta errada com fonte.
Também existe o excesso de medo. Um limiar ajustado para nunca errar passa a negar resposta quando ela estava na base. Calibragem é uma troca, não um acerto final: aceitar algum risco de falso positivo ou frustrar o usuário com falso negativo. Fingir que dá para eliminar os dois é só empurrar a decisão para um lugar invisível.