O que é RAG (Retrieval-Augmented Generation)

O problema que o RAG resolve

Modelos como GPT, Claude ou Gemini aprendem a partir de grandes volumes de dados coletados até uma determinada data. Depois desse ponto, eles não têm acesso a informações novas.

Além disso, esses modelos tendem a "alucinar", ou seja, gerar respostas plausíveis, mas incorretas. Isso acontece principalmente quando alguém pergunta sobre fatos específicos, dados proprietários ou eventos recentes.

Se você quiser entender por que isso acontece, vale ler o artigo sobre como funciona uma LLM. Na prática, o modelo prevê o próximo token mais provável, e não consulta uma fonte de verdade.

O RAG resolve esse problema ao permitir que o modelo consulte uma base de conhecimento externa no momento da inferência, antes de gerar a resposta. Dessa forma, a resposta passa a ter um fundamento verificável.

A documentação da Microsoft chama esse fundamento de grounding data, isto é, o conteúdo recuperado que você entrega ao modelo para reduzir o chute. Com isso, a aplicação também consegue citar a origem de cada informação.

De onde vem a ideia de RAG

O termo ganhou força com o artigo Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, de Patrick Lewis e outros pesquisadores, apresentado na NeurIPS 2020. O trabalho combinava um modelo gerador com um índice denso de documentos da Wikipédia.

Desde então, a técnica deixou o ambiente acadêmico e virou padrão de mercado. Hoje, serviços como Azure AI Search, Microsoft Foundry e diversos bancos de dados oferecem recursos específicos para RAG.

Como o RAG funciona

O pipeline de um sistema RAG tem três etapas principais: indexação, recuperação e geração. A primeira acontece antes de qualquer pergunta, enquanto as outras duas rodam a cada requisição.

A Microsoft descreve o mesmo fluxo como retrieve, augment e generate. Ou seja, a aplicação busca o conteúdo, monta o prompt aumentado e só então pede a resposta ao modelo.

Embeddings e similaridade semântica

Embeddings são representações vetoriais de textos em um espaço multidimensional, no qual textos com significado semelhante ficam próximos entre si. Por exemplo, "cancelar assinatura" e "encerrar meu plano" geram vetores vizinhos.

A busca por similaridade utiliza métricas como cosine similarity ou produto escalar para encontrar os vetores mais próximos ao vetor da pergunta. Quanto maior o score, mais próximo é o significado.

Isso permite que o sistema recupere trechos relevantes mesmo quando as palavras da pergunta são diferentes das palavras do documento. Essa é a grande vantagem do RAG sobre uma busca por palavra-chave tradicional.

Por outro lado, a busca vetorial pode falhar em termos muito exatos, como códigos de produto ou siglas raras. Nesse caso, muitos projetos adotam a busca híbrida, que combina palavra-chave e vetor no mesmo índice.

Chunking no RAG: estratégias e impacto na qualidade

A forma de fragmentar os documentos influencia diretamente a qualidade das respostas do sistema RAG. Por isso, o chunking merece tanta atenção quanto a escolha do modelo.

Chunks muito grandes carregam muito contexto irrelevante e consomem tokens. Por outro lado, chunks muito pequenos podem perder informações importantes de contexto.

As principais estratégias incluem:

• tamanho fixo, medido em caracteres ou tokens;
• divisão por sentença;
• quebra por parágrafo ou por seção;
• recursive character text splitting, que tenta respeitar a estrutura natural do documento;
• agrupamento semântico, que junta sentenças com significado próximo.

Uma prática comum é usar sobreposição entre chunks, chamada de overlap. Assim, uma ideia que começa no fim de um pedaço continua no início do próximo e não se perde.

Quando usar RAG

O RAG brilha quando a resposta depende de informações que o modelo não viu no treinamento. Por exemplo, manuais internos, políticas da empresa, contratos, tickets de suporte e documentação de produto.

Outro cenário clássico envolve conteúdo que muda com frequência, como catálogos, preços ou notícias. Nesse caso, basta atualizar o índice, sem tocar no modelo.

Também faz sentido usar a técnica quando a rastreabilidade importa. Como cada chunk carrega metadados, a aplicação mostra de onde veio cada afirmação, e o usuário confere a fonte.

Por outro lado, o RAG ajuda pouco quando o problema é de raciocínio puro, como resolver uma conta ou refatorar um trecho de código. Nessas situações, o gargalo está na capacidade do modelo, e não na falta de contexto.

RAG vs fine-tuning

Fine-tuning consiste em retreinar o modelo com dados específicos, incorporando o conhecimento diretamente nos pesos da rede neural. O custo e o tempo desse processo, porém, são consideráveis.

O RAG, por outro lado, mantém o modelo base intacto e injeta o conhecimento em tempo de execução. Dessa forma, atualizar a base de conhecimento fica muito mais simples e barato, já que basta reindexar os documentos.

A escolha entre as duas abordagens depende do caso de uso. O fine-tuning é mais adequado quando você deseja alterar o comportamento ou o estilo do modelo.

Já o RAG é mais adequado para acesso a dados atualizados e proprietários. Além disso, ele facilita o controle de acesso, porque a aplicação filtra os documentos antes de enviá-los ao modelo.

Nada impede, contudo, que um projeto combine as duas técnicas. Um modelo ajustado para o tom da empresa pode, ao mesmo tempo, receber contexto recuperado via RAG.

Outra comparação frequente envolve o Model Context Protocol. Se essa dúvida também é sua, o artigo RAG ou MCP: qual escolher aprofunda as diferenças.

Variações e evolução do RAG

O RAG evoluiu além de sua formulação original e deu origem a variações mais sofisticadas. Cada uma ataca uma fraqueza específica do pipeline básico.

O Self-RAG permite que o modelo decida, de forma autônoma, quando realizar uma busca. Além disso, ele avalia a relevância dos resultados recuperados antes de utilizá-los e critica a própria resposta.

O Corrective RAG (CRAG) adiciona uma etapa de validação que verifica a qualidade dos documentos recuperados. Se necessário, ele realiza buscas adicionais ou descarta resultados irrelevantes.

O GraphRAG substitui ou complementa o banco vetorial com um grafo de conhecimento. Com isso, a aplicação recupera informações que dependem de relacionamentos complexos entre entidades, algo que a Microsoft Research explorou em um artigo de 2024.

O Agentic RAG integra o pipeline de recuperação em agentes de IA. Nesse caso, o agente faz múltiplas iterações de busca e raciocínio até construir uma resposta satisfatória.

RAG em aplicações .NET

No ecossistema .NET, você pode implementar RAG com a biblioteca Microsoft.Extensions.AI. Ela fornece abstrações como IChatClient e IEmbeddingGenerator, independentes de um provedor específico de modelo.

O pacote Microsoft.Extensions.VectorData oferece uma interface unificada para bancos de dados vetoriais. Ele suporta pgvector, Qdrant, Azure AI Search, SQL Server, Cosmos DB e outros provedores, cada um em um pacote separado.

Para a ingestão de documentos, o Microsoft.Extensions.DataIngestion abstrai o pipeline de leitura, chunking, embedding e armazenamento. Dessa forma, ele simplifica a construção de sistemas RAG em aplicações ASP.NET Core.

O artigo dados vetoriais no .NET com Microsoft.Extensions.VectorData detalha a camada de armazenamento. Já a etapa de ingestão aparece em ingestão de dados para aplicações .NET.

using Microsoft.Extensions.AI;
using Microsoft.Extensions.VectorData;

public sealed class DocumentChunk
{
    [VectorStoreKey]
    public Guid Id { get; set; }

    [VectorStoreData]
    public string Content { get; set; } = string.Empty;

    [VectorStoreData]
    public string SourceUrl { get; set; } = string.Empty;

    // Recebe o mesmo texto de Content; o vector store gera o embedding
    [VectorStoreVector(1536)]
    public string Embedding { get; set; } = string.Empty;
}

public sealed class AnswerService(
    VectorStoreCollection<Guid, DocumentChunk> collection,
    IChatClient chatClient)
{
    public async Task<string> AskAsync(string question)
    {
        // 1. Recupera os três chunks mais parecidos com a pergunta
        var context = new List<string>();
        await foreach (var result in collection.SearchAsync(question, top: 3))
        {
            context.Add($"[{result.Record.SourceUrl}] {result.Record.Content}");
        }

        // 2. Monta o prompt aumentado com o contexto recuperado
        var messages = new List<ChatMessage>
        {
            new(ChatRole.System,
                "Answer only with the provided context. " +
                "If the answer is not in the context, say you don't know."),
            new(ChatRole.User,
                $"Context:\n{string.Join("\n", context)}\n\nQuestion: {question}")
        };

        // 3. Gera a resposta fundamentada no contexto
        var response = await chatClient.GetResponseAsync(messages);
        return response.Text;
    }
}

Considerações de produção para RAG

Em produção, o desempenho do RAG depende da qualidade dos embeddings, da estratégia de chunking e da relevância dos documentos recuperados. Ou seja, o modelo de linguagem é só uma das peças do sistema.

É fundamental monitorar métricas como faithfulness, que mede a fidelidade da resposta ao contexto recuperado. Também importam a answer relevancy, que mede a relevância da resposta, e a context precision, que mede a precisão dos chunks recuperados.

Ferramentas como o RAGAS avaliam e medem a qualidade de sistemas RAG de forma automatizada. O framework surgiu em um artigo de 2023 justamente para avaliar esses pipelines sem depender de anotação humana em cada resposta.

Além da qualidade, existem custos e latência a considerar. Cada consulta adiciona a geração do embedding, a busca no índice e mais tokens de entrada no prompt.

A segurança também exige cuidado. A Microsoft recomenda aplicar controle de acesso no momento da recuperação e tratar o conteúdo recuperado como entrada não confiável, pois um documento pode conter instruções maliciosas de prompt injection.

Por fim, mantenha a base de conhecimento atualizada. Um RAG com documentos desatualizados apenas troca uma alucinação por uma informação velha.

Conclusão

O RAG representa uma das abordagens mais práticas e eficientes para ampliar as capacidades dos LLMs com conhecimento específico de domínio. Além disso, ele dispensa o retreinamento do modelo.

Ao combinar busca semântica com geração de linguagem natural, o RAG permite construir sistemas de IA confiáveis, atualizáveis e alinhados a dados reais. No .NET, as bibliotecas Microsoft.Extensions.AI, Microsoft.Extensions.VectorData e Microsoft.Extensions.DataIngestion cobrem o fluxo inteiro.

Portanto, comece com um pipeline simples, meça a qualidade com métricas objetivas e evolua para variações como CRAG ou GraphRAG somente quando o caso de uso pedir.

FAQ

O que significa a sigla RAG?

RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação. A técnica busca informações externas e as entrega ao modelo antes da resposta.

O RAG elimina as alucinações do modelo?

Não elimina, mas reduz bastante. O modelo ainda pode interpretar mal o contexto, por isso métricas como faithfulness são importantes.

Preciso de um banco vetorial para usar RAG?

Na maioria dos casos, sim, porque a busca semântica depende de embeddings. Também existem implementações com busca por palavra-chave ou híbrida.

Qual a diferença entre RAG e fine-tuning?

O fine-tuning altera os pesos do modelo com novos dados. O RAG mantém o modelo intacto e injeta o conhecimento em tempo de execução.

Quais bibliotecas usar para RAG no .NET?

As principais são Microsoft.Extensions.AI, Microsoft.Extensions.VectorData e Microsoft.Extensions.DataIngestion. Elas cobrem modelos, armazenamento vetorial e ingestão.