10 - Fundamentos de RAG (Retrieval-Augmented Generation)

1. ⚡ Resumo Expandido

A aula abordou o conceito de RAG (Retrieval-Augmented Generation) como a solução arquitetural padrão para contornar as principais limitações dos Large Language Models (LLMs): o congelamento de conhecimento (data cutoff) e a propensão a alucinações. O professor explicou que treinar ou fazer fine-tuning contínuo em modelos de fundação é financeiramente e computacionalmente inviável para atualizar fatos.

Como alternativa, o RAG atua integrando o poder de geração de texto do LLM a um mecanismo de busca externa em tempo real (como a internet, buckets S3, APIs e documentos corporativos). O processo é dividido em cinco etapas: a Query do usuário, a conversão para Embeddings, a busca semântica via Retriever em um banco de dados vetorial, a construção de um Prompt enriquecido com esse contexto, e, finalmente, a Geração da resposta.

Visão de Mercado (Pesquisa Externa): No cenário atual corporativo (Enterprise AI), o RAG é a arquitetura mais adotada por empresas de todos os tamanhos (desde startups até gigantes como Netflix e Uber) para criar assistentes internos e sistemas de Q&A de atendimento ao cliente, pois garante rastreabilidade (citação de fontes) e segurança dos dados, isolando o LLM das bases de dados proprietárias.

---

2. 🔍 Deep Dive: Conceitos & Teoria

• Retrieval-Augmented Generation (RAG):

  • Na Aula: Uma técnica que conecta uma LLM a uma base externa para buscar informações atualizadas antes de responder, evitando que ela invente dados.

  • Deep Dive (Pesquisa): Introduzido inicialmente no paper “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (Lewis et al., 2020 - Meta/Facebook AI). Hoje, o mercado já transicionou do “Naive RAG” (o modelo de 5 passos citado na aula) para o Advanced RAG e Modular RAG, que incorporam técnicas de pré-recuperação (roteamento de query, reescrita de query) e pós-recuperação (como Re-ranking, para ordenar os chunks mais relevantes antes de enviá-los ao LLM).

• Embeddings e Busca Semântica:

  • Na Aula: A transformação de tokens em representações vetoriais numéricas para buscar por similaridade de significado (ex: “acesso remoto seguro” encontrando “VPN corporativa”), em vez de busca exata por palavras-chave.

  • Deep Dive (Pesquisa): Embeddings são matrizes de alta dimensionalidade geradas por modelos específicos (como o text-embedding-3-large da OpenAI ou o text-multilingual do Google). A busca semântica calcula a distância entre os vetores no espaço multidimensional, frequentemente usando a similaridade por cosseno:

    $cosine\_similarity(A,B)=\frac{A\cdot B}{||A||||B||}$

  • ⚠️ Nota do Pesquisador: O professor deu a entender que a busca por embeddings é sempre superior. Na engenharia de software moderna, sabemos que a busca estritamente semântica falha ao procurar códigos de erro específicos, nomes próprios ou SKUs de produtos. A melhor prática de mercado hoje é a Busca Híbrida (Hybrid Search), que une a busca semântica (vetorial) com a busca lexical baseada em palavras-chave (ex: algoritmo BM25), utilizando Reciprocal Rank Fusion (RRF) para combinar os resultados.

• In-Context Learning (Prompt com Contexto):

  • Na Aula: O passo onde os trechos recuperados do banco de dados e a pergunta inicial são injetados no prompt para que a LLM gere a resposta.

  • Deep Dive (Pesquisa): O desempenho desta etapa depende fortemente do tamanho e da eficiência da Context Window do modelo. Embora LLMs modernos como o Gemini 1.5 Pro suportem até 2 milhões de tokens, papers como “Lost in the Middle: How Language Models Use Long Contexts” (Liu et al., 2023) comprovam que LLMs tendem a esquecer ou ignorar informações injetadas no meio de prompts muito grandes. Por isso, extrair apenas os chunks estritamente necessários é essencial para a precisão.

---

3. 🛠️ Engenharia: Arquiteturas e Agentes

• Padrão/Framework: LlamaIndex e LangChain

  • Funcionamento: Para orquestrar os 5 passos descritos pelo professor, a engenharia de software não cria conexões manuais do zero. Utilizamos frameworks de dados como LlamaIndex ou orquestradores como LangChain. O pipeline de ingestão de dados exige: Document Loaders (para ler PDFs, S3, Notion) $\to$ Text Splitters (para quebrar os textos em chunks e manter a sobreposição/overlap) $\to$ Embedding Models $\to$ Vector Stores (bancos de dados vetoriais).

  • Exemplo da Aula: O professor citou o uso de documentos em buckets S3 ou sites delimitados para restringir a alucinação.

  • Referência Externa: Para bancos de dados vetoriais, ferramentas como Pinecone, Milvus, Qdrant ou mesmo o pgvector (extensão do PostgreSQL) são o padrão da indústria. A recomendação da documentação oficial do LlamaIndex para evitar alucinações ao delimitar o escopo é o uso de Agentic RAG, onde um agente roteia a query do usuário apenas para as ferramentas (ou bases) autorizadas.

---

4. 📚 Bibliografia Estendida e Referências (Pesquisa)

• Papers Recomendados:

  • “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (Lewis et al., 2020): Leitura obrigatória por ser a origem arquitetural do RAG.

  • “Seven Failure Points When Engineering a Retrieval Augmented Generation System” (Barnett et al., 2024): Um excelente paper prático que lista onde o RAG costuma quebrar em produção (ex: Missing Context, Format Mismatch).

• Artigos/Blogs de Engenharia:

  • Cohere Rerank Blog: Estudo sobre como adicionar um modelo de Re-ranking (Cross-Encoder) logo após o Retriever melhora a precisão do RAG em mais de 40%.

• Ferramentas Relacionadas:

  • Cohere / BGE (BAAI): SOTA em modelos de Re-rankers.

  • LangGraph / AutoGen: Para evoluir o RAG tradicional para sistemas multi-agentes que podem buscar, criticar o próprio resultado e buscar de novo.

---

5. ⚠️ Pontos de Atenção e Trade-offs

• Estratégia de Chunking (Não abordado a fundo na aula): Como você quebra o documento original antes de gerar o embedding dita o sucesso do seu RAG. Chunks muito pequenos perdem o contexto; chunks muito grandes adicionam ruído e estouram a janela de contexto.

• Custo Oculto: Fazer RAG em larga escala custa dinheiro. Você paga pela API de Embeddings para indexar os dados, paga pela hospedagem do Banco de Dados Vetorial (armazenamento na RAM), e os prompts enviados ao LLM ficam consideravelmente maiores (aumentando o custo de input tokens).

• Latência: A arquitetura síncrona adiciona latência (esperar a vetorização da query $\to$ esperar o DB Vetorial $\to$ esperar a geração do LLM). Em sistemas de alta volumetria, isso deve ser tratado com streaming de respostas e otimização de cache semântico.

---

6. 📝 Quiz Prático

1. (Baseada na Aula) Qual é o principal motivo financeiro e arquitetural para utilizarmos o RAG em vez de simplesmente treinar ou fazer fine-tuning na LLM com os dados mais recentes da empresa?

• Resposta: O principal motivo é a viabilidade técnica e a redução de custos. Treinar ou fazer fine-tuning continuamente em um LLM sempre que uma nova informação surge é extremamente caro e lento, e não resolve o problema do “congelamento de dados” (data cutoff). Arquiteturalmente, o RAG resolve isso separando o motor de raciocínio (LLM) da base de conhecimento (banco de dados). Isso permite que o agente acesse dados privados e atualizados em tempo real, sem precisar alterar os pesos da rede neural, tornando a operação escalável e financeiramente viável.

2. (Baseada na Aula) Qual a diferença fundamental entre uma busca por palavra-chave tradicional e a etapa do “Retriever” utilizando Embeddings no RAG? Dê um exemplo.

• Resposta: A busca tradicional (léxica) procura pela correspondência exata dos caracteres ou palavras digitadas. Já o Retriever com Embeddings realiza uma busca semântica. Ele converte o texto em vetores numéricos no espaço multidimensional e busca pela proximidade de significados, independentemente de as palavras exatas estarem no texto.

• Exemplo da aula: Se o usuário buscar por “acesso remoto seguro”, a busca semântica consegue retornar um documento sobre “VPN corporativa” porque entende que o contexto e a intenção são os mesmos, algo que uma busca tradicional por palavra-chave falharia em fazer.

3. (Baseada na Aula) Quais são as 5 camadas/passos arquiteturais do funcionamento básico do RAG explicados pelo professor?

• Resposta: Os 5 passos sequenciais são:

  1. Query: A entrada textual ou pergunta feita pelo usuário.

  2. Embedding: A transformação dessa pergunta em um vetor numérico para capturar seu significado.

  3. Retriever (Busca Semântica): A busca no banco de dados vetorial pelos trechos de documentos (chunks) que possuem os vetores mais próximos/similares ao vetor da pergunta.

  4. Construção do Prompt: A injeção dos trechos de texto recuperados junto à pergunta original do usuário para formar um contexto rico.

  5. Geração da Resposta: O envio desse prompt enriquecido ao LLM, que gera a resposta final baseada exclusivamente nas evidências que foram fornecidas, reduzindo alucinações.

4. (Desafio de Pesquisa) Sabendo que o modelo “Naive RAG” confia exclusivamente em similaridade de cosseno via Embeddings, explique como a abordagem de Busca Híbrida (Hybrid Search) com algoritmos como BM25 pode resolver a falha de não encontrar termos exatos, como códigos de produtos (SKUs).

• Resposta (Deep Dive): O “Naive RAG” confia apenas em vetores densos (embeddings), o que é excelente para semântica, mas péssimo para buscas de correspondência exata, jargões raros ou siglas. Códigos específicos como um SKU (ex: “TV-XLED-55-2024”) frequentemente não têm um “significado semântico” forte no espaço vetorial e acabam diluídos ou ignorados. A Busca Híbrida resolve isso combinando o melhor dos dois mundos:

  • Busca Vetorial (Embeddings): Entende a intenção, o contexto e os sinônimos.

  • Busca Lexical (BM25): É um algoritmo estatístico avançado de keyword (baseado em frequência do termo e raridade no documento). Se o usuário digitar um SKU exato, o BM25 garantirá que o documento contendo aquele SKU receba um peso altíssimo no ranking.

  • No final, a arquitetura utiliza algoritmos (como o Reciprocal Rank Fusion - RRF) para mesclar as duas listas de resultados, entregando ao LLM os documentos que são ao mesmo tempo semanticamente relevantes e textualmente precisos.