O que é RAG (Retrieval Augmented Generation)

RAG é a arquitetura padrão pra fazer IA usar conhecimento da empresa sem fine-tuning. Ela resolve um problema concreto: o modelo de linguagem não sabe o que está nos seus documentos internos, mas você precisa que ele responda com base neles. Em vez de retreinar o modelo (caro), o sistema busca os documentos relevantes e entrega como contexto pra geração. Quando bem feito, RAG reduz alucinação e dá rastreabilidade da fonte. Quando mal feito, fica pior que IA sem RAG, porque entrega lixo plausível baseado em parser ruim.

Como funciona o pipeline

RAG tem oito etapas, agrupadas em duas fases. A fase de ingestão acontece uma vez (ou a cada atualização do conteúdo). A fase de query acontece a cada pergunta do usuário.

Na ingestão, quatro etapas. A primeira é o parser, que lê o documento original (PDF, HTML, Word, planilha, transcrição) e extrai o texto preservando estrutura. A segunda é o chunker, que divide o texto em pedaços de tamanho gerenciável, idealmente respeitando fronteira semântica (parágrafo, seção). A terceira é o embedder, que transforma cada pedaço em embedding, um vetor de N dimensões. A quarta é o storage no vector database, que indexa os embeddings pra busca rápida por similaridade.

Na query, quatro etapas. A primeira é a interpretação da pergunta do usuário, que vira embedding via mesmo modelo usado na ingestão. A segunda é a busca, que retorna os K pedaços mais similares à pergunta. A terceira é o reranking opcional, que reordena os resultados usando modelo mais preciso (cross-encoder) pra reduzir falsos positivos. A quarta é a geração, em que o LLM recebe a pergunta original e os pedaços recuperados, com instrução de responder com base no contexto fornecido.

A arquitetura ganhou tração depois do paper original Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al, 2020), e virou default corporativo em 2023 conforme as APIs ficaram acessíveis e os vector databases maduros.

Os componentes que decidem qualidade

Parser é o ponto mais subestimado. Documento corporativo real é cheio de tabela, lista, hierarquia de seção, footnote, gráfico com legenda, sumário. Parser ingênuo achata tudo em texto corrido e perde estrutura. Quando o usuário pergunta "qual o desconto pra cliente premium na faixa de 50k a 100k", e o desconto está numa tabela, parser que não tratou tabela entrega lixo. O modelo recebe lixo e gera resposta plausível, baseada em lixo.

Chunker decide o que vai junto. Chunk grande demais dilui sinal e excede janela de contexto. Chunk pequeno demais perde contexto necessário pra responder. Estratégias modernas: chunker semântico (respeita fronteira de parágrafo), chunker estrutural (respeita seção e subsecão), chunker hierárquico (mantém múltiplos níveis de granularidade). Não há um chunker certo; há o chunker certo pro tipo de documento.

Embedder define a qualidade da busca semântica. Modelo geral (text-embedding-3, voyage, e5) cobre maior parte dos casos. Domínio com vocabulário específico (medicina, jurídico, química) pode precisar de modelo especializado ou fine-tune do embedder. A escolha tem efeito direto em recall: se o embedder não captura a similaridade entre "cancelar" e "rescisão", o documento certo nunca volta na busca.

Retriever combina dense (embedding) com sparse (BM25) na maioria das implementações modernas. Hybrid search tipicamente performa melhor que dense puro, especialmente em queries com termo técnico raro ou nome próprio. Frameworks como Pinecone, Weaviate, Qdrant e pgvector suportam hybrid nativamente.

Reranker reordena o top-K usando cross-encoder, que avalia query e documento juntos, em vez de usar embeddings independentes. Adiciona latência e custo, e em geral melhora precision em 15 a 30% pra mesmo recall, segundo benchmarks da Cohere e da Anthropic.

Onde RAG quebra na prática

Documento desatualizado é o primeiro modo de falha. Sistema responde com base em política antiga porque a versão nova não foi reindexada. Solução: pipeline de ingestão automatizado conectado à fonte da verdade, com versionamento explícito.

Recuperação de documento errado é o segundo. Pergunta sobre tópico A traz documento sobre tópico B porque os dois compartilham vocabulário. Solução: metadata filtering (limita busca por departamento, data, categoria), reranking, e em casos extremos query rewriting (modelo reformula a pergunta antes da busca).

Conflito entre documentos é o terceiro. Política de RH 2023 diz uma coisa, política 2024 diz outra, ambas estão indexadas. Modelo recebe ambos e gera resposta combinando os dois, ou escolhe um sem critério. Solução: governança de fonte com data de validade, depreciação explícita, ou priorização por metadata.

Parser que perde estrutura é o quarto, e o mais comum. Tabela vira parágrafo confuso, lista vira texto corrido, hierarquia some. Modelo recebe contexto degradado e responde com confiança proporcional ao texto, não à qualidade da informação. Como argumento na sinopse do artigo Seu RAG não funciona porque seu parser é lixo, esse é o gargalo real de RAG corporativo, e não a escolha de modelo ou de vector database.

As variantes que importam

Naive RAG é o pipeline básico descrito acima: parse, chunk, embed, store, query, retrieve, generate. Cabe em prova de conceito, e em muitos casos de uso simples basta.

Advanced RAG adiciona query rewriting (reformula a pergunta), hybrid search (dense + sparse), reranking (cross-encoder), e self-correction (modelo avalia se a resposta está bem ancorada). Default pra produção corporativa.

Graph RAG indexa relação entre entidades (pessoas, empresas, conceitos) em grafo, em vez de só embeddings. Útil quando a query exige raciocínio sobre relação ("quem trabalhou com X em Y entre 2020 e 2023?"). Pesquisa da Microsoft sobre GraphRAG mostra ganho significativo em queries de síntese cross-document.

Agentic RAG move a estratégia de retrieval pra dentro de um agente, que decide quando buscar, o que buscar e como combinar os resultados. Útil quando a query exige múltiplos passos de busca. Adiciona custo e latência; ganha em casos complexos.

Quando RAG não basta

Conhecimento que muda em tempo real (preço de mercado, status de incidente, dado operacional) não cabe em RAG estático. Solução: tool use com chamada direta à API ou banco operacional, em vez de indexar.

Cálculo determinístico não cabe em RAG. Modelo não calcula; ele prevê próxima palavra. Pra cálculo, ferramenta determinística (calculadora, query SQL, função). RAG entrega o contexto; tool use entrega a operação.

Domínio com vocabulário muito específico, em que o embedder geral não captura similaridade, pode exigir fine-tune do embedder ou abordagem híbrida com ontologia explícita.

A pergunta que define a decisão

Antes de aprovar projeto de RAG, três perguntas:

1. O parser está tratando a estrutura real dos documentos (tabela, lista, hierarquia)?
2. A fonte da verdade está versionada, com pipeline de atualização e governança de acesso?
3. A eval inclui casos representativos com resposta esperada conhecida, e mede taxa de alucinação?

Se a resposta a qualquer das três é "vamos resolver depois", o projeto vai rebobinar em três meses. Aprofundamento conceitual no glossário de IA pro Translator e crítica do parser é tema da série A3 sobre RAG no Medium.

Referências

• Lewis, P. et al (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
• Microsoft Research (2024). GraphRAG: Unlocking LLM discovery on narrative private data.
• Cohere (2023). Introducing Rerank 3: A new foundation model for efficient enterprise search and retrieval.