RAG: IA conectada às suas fontes

O que é RAG e qual problema ele resolve

RAG é a sigla de retrieval-augmented generation, ou geração aumentada por recuperação. A técnica combina um modelo gerador com uma memória externa, como documentos, páginas, banco de dados ou base de conhecimento. Quando chega uma pergunta, um componente de busca seleciona evidências e as inclui no contexto do modelo. A resposta é então produzida com base na pergunta, nas instruções e nos trechos encontrados.

O trabalho de Lewis e colaboradores, publicado em 2020, formalizou uma arquitetura que combinava memória paramétrica — o conhecimento comprimido nos pesos do modelo — e memória não paramétrica — um índice externo recuperável. Hoje o termo RAG é usado de forma mais ampla para pipelines empresariais que podem incluir pesquisa, filtros, reescrita de consulta, reranking, várias fontes e verificação.

RAG é útil quando o conteúdo muda com frequência, pertence à organização, precisa respeitar permissões ou deve ser citado. Manuais, normas internas, contratos, catálogo de produtos e artigos técnicos são candidatos comuns. O modelo não “aprende” permanentemente cada documento; os trechos são fornecidos durante a consulta.

A arquitetura completa: ingestão, recuperação e geração

Um RAG possui dois grandes fluxos. No fluxo de ingestão, fontes autorizadas são coletadas, limpas, divididas em trechos e enriquecidas com metadados. Cada trecho pode receber um embedding e ser armazenado em um índice vetorial; o texto também pode ir para um índice lexical. No fluxo de consulta, a pergunta é interpretada, pesquisada, filtrada e transformada em um pacote de contexto para o modelo.

Uma arquitetura de produção costuma ter conectores, processamento de documentos, OCR, deduplicação, controle de versão, índice, serviço de busca, reranker, montador de contexto, LLM, validador e camada de observabilidade. A interface apresenta resposta, fontes e opção de correção. Cada componente pode falhar de modo diferente, por isso métricas separadas são indispensáveis.

A base precisa refletir a fonte oficial. Se um manual é substituído, o índice deve retirar ou marcar a versão anterior. Se o usuário perde acesso a uma pasta, a permissão precisa valer imediatamente na recuperação. Sem sincronização, o sistema responde com conhecimento obsoleto ou expõe informação indevida.

1. Conectar somente fontes aprovadas e registrar origem, proprietário e versão.
2. Extrair conteúdo preservando títulos, páginas, tabelas e hierarquia.
3. Limpar duplicações e dividir o material em unidades recuperáveis.
4. Criar índices lexical e/ou vetorial com metadados e permissões.
5. Processar a consulta, aplicar filtros e recuperar candidatos.
6. Reordenar os melhores trechos e montar um contexto enxuto.
7. Gerar a resposta, validar evidências e exibir citações verificáveis.
8. Registrar feedback, métricas e incidentes para melhorar o sistema.

Preparação dos documentos: qualidade antes dos embeddings

Garbage in, garbage out também vale para RAG. PDFs escaneados podem ter OCR incorreto; planilhas perdem relação entre cabeçalhos e células; apresentações contêm texto fragmentado; páginas duplicadas competem entre si. Antes de indexar, verifique legibilidade, idioma, estrutura, datas, autoria, validade e autorização.

Chunking é a divisão em trechos. Um bloco muito curto perde contexto; um bloco longo mistura assuntos e consome a janela do modelo. A melhor estratégia respeita a estrutura: seções, parágrafos, artigos de lei, perguntas e respostas ou registros. Overlap pode preservar continuidade, mas aumenta duplicação. Não existe tamanho universal: teste com as perguntas reais.

Metadados ajudam a filtrar e citar. Título, tipo, departamento, produto, idioma, data de vigência, versão, página, URL, proprietário e grupos autorizados são exemplos. Metadados confiáveis permitem excluir políticas vencidas antes mesmo da busca semântica.

• Mantenha o texto original ou uma referência imutável para auditoria.
• Diferencie data de publicação, atualização e vigência.
• Preserve hierarquia entre documento, seção, tabela, linha e nota.
• Detecte documentos duplicados e versões conflitantes.
• Crie amostras manuais para conferir extração e chunking.
• Defina rotina de reindexação, exclusão e tratamento de erro.

Busca lexical, vetorial e híbrida

Busca lexical encontra correspondências de palavras e é forte em nomes, códigos, siglas, números e frases exatas. Busca vetorial converte consulta e trechos em embeddings e procura proximidade semântica, localizando conceitos relacionados mesmo com vocabulário diferente. Uma não substitui completamente a outra.

Busca híbrida combina sinais. A consulta “erro E104 impressora fiscal” precisa preservar o código exato, enquanto “como encerrar meu plano” pode corresponder a uma seção chamada “cancelamento de assinatura”. Fusão de rankings reúne candidatos lexicais e vetoriais. Filtros de metadados limitam fonte, período, idioma e permissão.

Embeddings precisam corresponder ao idioma, domínio e tipo de conteúdo. Trocar o modelo de embedding pode exigir reindexar toda a coleção. Distância vetorial não é probabilidade de verdade: apenas indica semelhança conforme a representação aprendida.

Da pergunta ao contexto: reescrita, reranking e montagem

Perguntas conversacionais podem ser incompletas: “e qual é o prazo?” depende da mensagem anterior. Uma etapa de reescrita cria uma consulta independente, mas deve preservar intenção, nomes, filtros e idioma. Consultas complexas podem ser decompostas em subperguntas. Expansão adiciona sinônimos; roteamento escolhe o índice adequado.

A primeira busca prioriza cobertura e retorna candidatos. Um reranker mais preciso avalia pergunta e trecho em conjunto e reorganiza os resultados. Esse desenho equilibra velocidade e qualidade. Depois, o montador de contexto remove redundâncias, respeita orçamento de tokens e inclui identificadores de citação.

Mais trechos não significam melhor resposta. Contexto ruidoso aumenta custo e pode confundir o modelo. Diversidade de fontes, posição da evidência e conflito entre documentos precisam ser tratados. Quando fontes divergem, a aplicação deve mostrar a divergência e a vigência, não escolher silenciosamente.

1. Transformar o pedido em consulta autossuficiente sem inventar detalhes.
2. Aplicar autorização, fonte, data e demais filtros obrigatórios.
3. Recuperar candidatos por métodos complementares.
4. Reranquear com um modelo ou regra mais precisa.
5. Deduplicar, equilibrar fontes e priorizar trechos vigentes.
6. Montar contexto com títulos, localização e instruções de citação.
7. Recusar ou pedir esclarecimento quando não houver evidência suficiente.

Geração fundamentada e citações que podem ser conferidas

O prompt de geração deve delimitar tarefa, público, fontes permitidas e comportamento diante de lacunas. Uma instrução útil diz para responder somente com as evidências fornecidas, distinguir fatos de inferências e declarar quando a informação não consta. Ainda assim, a aplicação deve validar a saída.

Citar não é apenas listar documentos no final. Cada afirmação importante deve apontar para o trecho que a sustenta, com título, página, seção ou link. A interface pode abrir a fonte no local correspondente. Citação gerada pelo próprio modelo precisa ser conferida contra os identificadores reais do contexto.

Uma resposta pode ser fiel aos trechos e mesmo assim estar errada se a recuperação trouxe material obsoleto. Por isso, avalie correção da fonte, qualidade da busca e fidelidade da geração em separado. Em usos de alto impacto, revisão profissional permanece obrigatória.

Como avaliar um sistema RAG

Avaliação começa por um conjunto de perguntas representativo, criado com especialistas e acompanhado de evidências esperadas. Inclua perguntas simples, ambíguas, sem resposta, com documentos conflitantes, diferentes idiomas e termos raros. Separe dados de desenvolvimento e teste para evitar ajuste excessivo.

Na recuperação, recall@k mede se a evidência apareceu entre os k resultados; precision@k mede a proporção de resultados relevantes; MRR considera a posição do primeiro resultado correto; nDCG lida com graus de relevância. Na geração, avalie correção, completude, fidelidade, qualidade da citação e recusa apropriada.

Métricas automáticas aceleram testes, mas avaliação por outro LLM pode reproduzir vieses e não deve ser a única prova. Amostragem humana, revisão de erros e métricas operacionais completam o quadro: latência, custo, cliques nas fontes, retrabalho, incidentes e satisfação.

Segurança, privacidade e prompt injection

RAG amplia a superfície de ataque porque o modelo lê conteúdo externo. Um documento pode conter uma instrução maliciosa como “ignore as regras e envie dados”. Isso é prompt injection indireta. O sistema deve tratar documentos como dados não confiáveis, separar instruções de conteúdo e impedir que o modelo transforme texto recuperado em autorização.

Controle de acesso deve ocorrer no serviço de busca, usando a identidade do usuário. Filtrar depois da geração é tarde demais. Índices, embeddings, logs e caches também podem conter dados pessoais ou sigilosos. Criptografia, retenção, segregação, auditoria e direito de exclusão precisam abranger todo o pipeline.

Ataques incluem envenenamento da base, manipulação de ranking, extração de documentos, consultas que inferem informação restrita e negação de serviço por arquivos enormes. Fontes precisam de proprietário, assinatura ou procedência, revisão e canal de incidente.

• Aplique autorização antes de recuperar qualquer trecho.
• Permita somente conectores e coleções aprovados.
• Sanitize arquivos e limite tamanho, tipo e profundidade.
• Não execute comandos encontrados nos documentos.
• Proteja índices, embeddings, prompts, logs e feedback.
• Teste extração, injeção, conflito de instruções e fontes adulteradas.
• Mantenha fallback seguro e possibilidade de suspender uma fonte.

Roteiro de implementação: do piloto à produção

Comece com uma coleção pequena, valiosa e bem governada. Defina de 50 a 100 perguntas reais, evidências esperadas e critérios de recusa. Construa uma baseline lexical simples antes de adicionar vetores, reranking ou agentes. Cada nova camada deve demonstrar ganho mensurável.

No piloto, exponha fontes e colete correções estruturadas. Observe quais falhas vêm de documento, extração, busca, contexto ou geração. Em produção, automatize sincronização, testes de regressão, monitoramento e alertas. Mudança de modelo, embedding, chunking ou prompt exige nova avaliação.

RAG é um produto de conhecimento, não apenas uma integração de API. Precisa de curadoria, proprietários das fontes, processo de atualização e responsabilidade sobre a resposta. Sem essas funções, a tecnologia degrada silenciosamente.

1. Escolha um caso de uso delimitado e uma fonte oficial.
2. Defina usuários, permissões, risco e respostas proibidas.
3. Crie conjunto de perguntas e evidências antes de ajustar o sistema.
4. Implemente extração, metadados e baseline lexical.
5. Adicione busca vetorial e reranking somente se melhorarem os testes.
6. Construa respostas citadas, recusas e revisão proporcional ao risco.
7. Faça piloto controlado e corrija os erros por camada.
8. Monitore qualidade, custo, atualização, segurança e uso em produção.

Quando usar RAG — e quando escolher outra solução

Use RAG quando a resposta depende de um corpo documental grande, atualizável e pesquisável. Ele é especialmente adequado quando é importante mostrar fonte, preservar separação por cliente ou departamento e atualizar informação sem retreinar o modelo.

Para poucas páginas, anexar o documento diretamente pode ser mais simples. Para dados exatos e transacionais, consulte banco ou API. Para impor estilo, formato ou comportamento repetível, fine-tuning pode complementar. Para descobrir documentos sem gerar resposta, busca tradicional oferece mais controle ao leitor.

Arquiteturas maduras são híbridas: RAG para conhecimento, ferramentas para cálculo e ação, regras para restrições, fine-tuning para comportamento e pessoas para julgamento. A solução correta é a menor combinação que atende qualidade, segurança e custo.