RAG é um pipeline de dados com um modelo de linguagem no final

Quando um time me diz que a feature de RAG responde mal, peço para ver o job de ingestão antes de pedir para ver o prompt. Nove em cada dez vezes o problema está ali. O parser de PDF descartou todas as tabelas. O chunker separou a oração da frase que a negava. O índice tem três cópias da política do ano passado e nenhuma deste ano. O modelo no final fez exatamente o que mandaram com exatamente o que recebeu. Recebeu lixo.

Onde as features de RAG falham de verdade

Retrieval-augmented generation é um pipeline: adquirir documentos, fazer o parsing, dividir, gerar embeddings, armazenar, consultar, ranquear, montar o contexto, gerar. Só a última etapa envolve algo que dá para chamar de IA, e é a etapa com menos bugs, porque o modelo é um componente bem testado que você não escreveu. Todas as outras etapas são código seu, escrito com pressa, sobre dados que você não olhou de perto. É ali que olho primeiro, e é ali que as falhas que ninguém achou costumam estar escondidas.

Ingestão é o produto

Um pipeline de documentos que auditei tinha um prompt lindo, um re-ranker e uma camada de busca híbrida, e não conseguia responder perguntas sobre preço, porque preço morava em tabelas e o parser achatava tabelas numa sopa de palavras. Nenhum prompt conserta isso. Os times com as melhores features de RAG são chatos com ingestão: guardam a fonte, versionam o parser, armazenam metadados como seção, data e responsável junto de cada chunk, detectam duplicatas e reindexam quando a fonte muda. Tratam como um job de ETL, com os mesmos testes e os mesmos alertas, porque é isso que é.

Retrieval é um problema de busca, e busca é coisa antiga

Similaridade vetorial é um sinal. Bom para significado, ruim para identificadores exatos, datas, negações e termos raros. Um retrieval bom combina isso com o que engenheiros de busca sabem há décadas: matching lexical, filtros de metadados, recência, autoridade da fonte e uma etapa de ranking avaliada contra consultas reais. A pergunta não é se o modelo de embeddings é bom. É se, para as cinquenta perguntas que seus usuários realmente fazem, o trecho certo aparece entre os primeiros resultados. Meça isso diretamente, com um conjunto rotulado, antes de mexer em qualquer coisa depois.

O modelo é a última milha

Quando os trechos certos chegam, a etapa de geração tem um trabalho estreito: responder a partir do contexto, citar o que usou e avisar quando o contexto não contém a resposta. Esse último comportamento é onde o system prompt importa, e é testável: mande uma pergunta que o corpus não responde e verifique se ele recusa. O modelo deveria ser pequeno no seu modelo mental da feature. É um formatador com discernimento, sentado em cima de um sistema de busca que carrega o peso de verdade.

O que verifico primeiro numa auditoria de RAG

Sorteio vinte chunks do índice e leio. Não o prompt, não os dashboards, os chunks. Se são coerentes, autocontidos e rastreáveis até a fonte, o pipeline provavelmente está saudável e sigo para a qualidade do retrieval. Se são fragmentos sem contexto, cortados no meio da frase, sem o título que dá sentido a eles, paro a auditoria ali mesmo, porque nada depois pode ser confiável enquanto os dados não forem. Isso é uma constatação de engenharia de dados, e a correção é engenharia de dados. O modelo de linguagem nunca foi o problema.