Seis meses depois do projeto, a equipe ainda não consegue explicar por que o modelo cita com confiança uma política que foi atualizada há dois anos. O sistema de recuperação está retornando documentos. O modelo está gerando respostas. As alucinações persistem. O diagnóstico usual: “precisamos de um modelo melhor.” O diagnóstico real: a camada de recuperação foi construída como um motor de busca, e motores de busca não são sistemas de coleta de evidências.
Essa distinção não é semântica. Ela muda o que você constrói.
O Equívoco do RAG que Custa Seis Meses
Retrieval-Augmented Generation, RAG, significa Recuperar, Augmentar, Gerar. A maioria das implementações corporativas foca pesadamente na etapa Gerar (qual modelo, qual prompt) e trata Recuperar como um problema resolvido porque bibliotecas de busca semântica existem e tutoriais fazem chunking parecer trivial.
A falha arquitetural está na etapa Augmentar. Augmentação não é concatenação. É o processo de montar uma janela de contexto que dá ao modelo a evidência específica que precisa para responder à pergunta sem lacunas. Quando a augmentação falha, o modelo preenche lacunas com conhecimento de treinamento. Esse é o mecanismo de alucinação.
O modelo mental que prevê falha: se você pensa em RAG como “busca semântica com uma camada de sumarização em cima,” você construirá exatamente isso e se perguntará por que o modelo ainda inventa coisas.
O modelo mental que prevê sucesso: RAG é um sistema de coleta de evidências. A camada de recuperação é um investigador que precisa retornar os documentos certos, as seções certas, com os metadados certos. O modelo é uma camada de raciocínio aplicada a essas evidências. O modelo não consegue raciocinar bem sobre evidências ruins.
Os Modos de Falha do RAG Ingênuo
Quatro modos de falha respondem pela maioria dos problemas de alucinação em implantações corporativas de RAG:
Chunking de tamanho fixo. O padrão na maioria dos tutoriais: dividir texto a cada 512 tokens, sobrepor por 50 tokens, armazenar. Um procedimento descrito ao longo de duas páginas é dividido na fronteira de um chunk. O modelo recebe metade de um procedimento e preenche o resto com treinamento. Correção: chunking semântico ou hierárquico que preserva a estrutura do documento.
Sem reranking. Top-K por similaridade de cosseno não é Top-K por relevância para a pergunta real. Um documento com alta similaridade de embedding para os termos da consulta pode ser menos relevante para a intenção do usuário do que um documento com menor similaridade mas cobertura procedural direta. Correção: reranking por cross-encoder como segundo passo após a recuperação inicial.
Filtragem de metadados ausente. A camada de recuperação retorna documentos do departamento errado, idioma errado ou versões obsoletas. O modelo não consegue distinguir uma política atual de uma depreciada sem metadados explícitos de tempo e classificação. Correção: cada chunk carrega fonte, data, proprietário, jurisdição e classificação; a filtragem acontece antes da busca vetorial, não depois.
Sem verificação de fidelidade. A resposta do modelo não é verificada em relação ao contexto que lhe foi dado. Uma resposta pode ser fluente, confiante e factualmente inconsistente com os documentos recuperados. Correção: pontuação de fidelidade como gate, não como log post-hoc.
Cada modo de falha é independente. Corrigir o chunking sem corrigir o reranking produz uma classe diferente de alucinação, não zero alucinação.
O Stack Avançado de Recuperação que Realmente Funciona
As técnicas de recuperação abaixo não são uma lista de verificação para aplicar universalmente. Cada uma endereça um modo de falha específico. Implantar todas sem um modo de falha alvo desperdiça tempo de engenharia.
Hybrid search com fusão RRF. BM25 (correspondência de palavras-chave) combinado com busca vetorial densa, resultados fundidos usando Reciprocal Rank Fusion. O BM25 captura termos de correspondência exata, códigos de equipamento, nomes, números de referência que vetores densos tratam mal. A busca densa captura intenção semântica que o BM25 não captura. A combinação supera qualquer um isolado em corpora de documentos corporativos. Este é agora o baseline, não uma opção avançada.
HyDE (Hypothetical Document Embedding). Em vez de embutir a pergunta do usuário e buscar documentos similares, o modelo gera uma resposta hipotética ideal para a pergunta, e essa resposta é embutida e usada para recuperação. Documentos recuperados dessa forma correspondem à estrutura e especificidade de uma resposta correta, em vez da estrutura de uma pergunta. Particularmente eficaz para recuperação de documentos técnicos onde a formulação da pergunta diverge acentuadamente da formulação da resposta.
RAG-Fusion. Gera múltiplas reformulações da consulta original, executa recuperações paralelas contra cada uma, funde resultados. Melhora o recall para consultas onde a formulação do usuário não é o caminho mais direto para o documento relevante.
Reranking por cross-encoder. Após a recuperação inicial, um modelo cross-encoder pontua cada par (consulta, documento) conjuntamente, em vez de comparar embeddings independentes. Mais lento que a busca vetorial, roda em um conjunto pequeno de candidatos (top-20 a top-50), melhora substancialmente a precisão. Bibliotecas como FlashRank fornecem reranking por cross-encoder auto-hospedável.
Chunking hierárquico. Chunks pai armazenam resumos de documentos; chunks filho armazenam conteúdo granular. A recuperação opera no nível do pai para identificar seções relevantes, depois busca os chunks filho para contexto. Preserva a estrutura do documento enquanto habilita recuperação granular. Apropriado para documentos regulatórios longos, manuais técnicos e repositórios de contratos.
A camada de recuperação não é um detalhe. É a restrição que determina quanto da capacidade do modelo você consegue realmente usar.
O Framework de Avaliação que Previne Arrependimento Pós-Implantação
Equipes corporativas que implantam RAG sem um harness de avaliação operam com base em opiniões. As opiniões frequentemente estão erradas, e a descoberta é cara.
O framework RAGAS fornece quatro métricas que juntas medem a qualidade do RAG sem exigir anotação humana para cada resposta:
- Fidelidade: a resposta está fundamentada no contexto recuperado, ou introduz afirmações não suportadas pelos documentos?
- Relevância da Resposta: a resposta endereça a pergunta do usuário?
- Precisão do Contexto: os chunks recuperados são relevantes para a pergunta?
- Recall do Contexto: todos os chunks relevantes foram recuperados, ou material está faltando?
Baixa fidelidade com alta precisão de contexto significa que o modelo está ignorando as evidências. Baixo recall de contexto significa que a camada de recuperação está perdendo documentos relevantes. Cada métrica identifica uma camada diferente do sistema para corrigir.
Construa o dataset de avaliação antes da implantação, não depois: 50 a 100 perguntas representativas com respostas esperadas e citações de fonte, extraídas da população real de usuários. Toda mudança de prompt, atualização de modelo, modificação de chunking e mudança de parâmetro de reranking é testada contra esse baseline. Isso é teste de regressão aplicado a um sistema probabilístico.
O loop de feedback de produção estende o conjunto de avaliação continuamente: correções de usuários, respostas rejeitadas e consultas escaladas se tornam novos casos de teste. O harness de avaliação não é um gate único, é o mecanismo para manter qualidade conforme o sistema evolui.
Segurança e Permissões no RAG Corporativo
A camada de recuperação herda permissões de dados. Um usuário consultando um sistema RAG não deve recuperar documentos que não pode acessar no sistema de origem. A maioria das implantações corporativas de RAG pula isso até a revisão de segurança.
Segurança a nível de linha em bancos de dados vetoriais exige que todo chunk carregue grupo de usuário, nível de classificação e metadados de jurisdição, e que esses metadados sejam aplicados no momento da recuperação, não filtrados depois. Filtrar após a recuperação significa que o documento foi recuperado e tratado pelo sistema, mesmo que não mostrado ao usuário. Dependendo da jurisdição, isso importa.
RAG com perímetro privado mantém dados dentro da infraestrutura da organização. A inferência do modelo roda on-premise ou em ambiente de nuvem privada. Nenhum conteúdo de documento, nenhum chunk e nenhum embedding sai do perímetro. Para indústrias reguladas e dados com escopo GDPR, isso é arquitetura, não preferência.
O requisito de trilha de auditoria merece tratamento explícito: para conformidade com o EU AI Act e alinhamento com ISO 42001, o sistema precisa ser capaz de responder “quais documentos fundamentaram esta resposta, para qual usuário, em qual momento?” Um sistema RAG sem trilha de auditoria não está em conformidade independentemente de quão precisas são suas respostas.
Quando RAG Não É a Resposta
RAG é a arquitetura certa para uma classe específica de problema de conhecimento corporativo: resposta a perguntas sobre um corpus de documentos heterogêneos onde a resposta pode ser fundamentada em passagens específicas.
Não é a arquitetura certa para todo problema de recuperação de conhecimento.
Se a pergunta exige síntese de centenas de documentos simultaneamente, rastreamento de relações entre entidades em um corpus, ou conexão de requisitos regulatórios entre múltiplas jurisdições, GraphRAG é mais apropriado. Recuperação baseada em grafo percorre relações de entidades; recuperação vetorial encontra passagens similares. São operações diferentes.
Se o domínio de conhecimento é altamente estruturado, tabular ou transacional, uma camada de consulta determinística é mais confiável que recuperação vetorial. O modelo gerando SQL e executando contra um banco de dados estruturado superará a busca vetorial aplicada a documentos que descrevem dados estruturados.
Se o conhecimento é estático, bem delimitado e estável, uma camada de contexto compilada ou um modelo fine-tuned pode superar a recuperação. RAG adiciona latência e complexidade por um benefício que só se materializa quando o domínio de conhecimento é grande, dinâmico ou heterogêneo.
O enquadramento correto: RAG é uma arquitetura de recuperação de evidências. Combine a arquitetura com a estrutura epistêmica do problema. Comece com essa questão, não com o framework mais fácil de implantar.
O pipeline de ingestão é onde a maioria dos problemas de qualidade do RAG é criada antes que o modelo veja qualquer consulta. Essa arquitetura está coberta aqui.
Se sua equipe está avaliando qual arquitetura de recuperação se encaixa em seu caso de uso específico, o AI Opportunity Sprint é como começamos.