RAG não é produto: é uma camada da solução
Nos últimos dois anos, RAG virou uma das palavras mais usadas em proposta comercial de IA no Brasil. E junto com ela veio uma confusão que está custando caro para empresas que contrataram sistemas que funcionam na demo e não funcionam em produção.
Vou ser direto: a maioria das implementações de RAG que vi no mercado não funciona bem. Não por falta de tecnologia. Por falta de entendimento do que RAG realmente é e do que ele não é.
O que RAG é, de fato
RAG significa Retrieval-Augmented Generation. Em termos práticos: antes de gerar uma resposta, o sistema recupera informação relevante de uma base de dados externa e injeta essa informação no contexto do modelo.
O problema que RAG resolve é real e importante. LLMs são treinados com dados até uma certa data e não têm acesso ao conhecimento específico da sua empresa, dos seus documentos, dos seus processos. Se você quer que o modelo responda com base em informação interna e atualizada, você precisa de algum mecanismo para trazer esse conhecimento para o contexto de cada chamada.
RAG é um desses mecanismos. É o mais comum e o mais estudado. Funciona bem quando implementado corretamente dentro de uma arquitetura bem pensada.
Implementado de qualquer jeito, que é como a maioria está sendo implementado, entrega exatamente o resultado que o mercado está vendo: demo impressionante, produção decepcionante.
Por que "implementamos RAG" não significa que o problema está resolvido
RAG não é uma chamada de API. É um pipeline com pelo menos seis etapas críticas, cada uma com decisões de implementação que afetam diretamente a qualidade do resultado final. Errar em qualquer etapa compromete o sistema inteiro.
Preparação dos documentos. Como você divide os documentos em chunks? Tamanho de chunk afeta precisão da recuperação e custo de processamento. Chunks muito pequenos perdem contexto. Chunks muito grandes recuperam informação irrelevante junto com a relevante. Documentos com formatação complexa, tabelas ou referências cruzadas exigem estratégias de chunking específicas que a maioria das implementações ignora.
Geração de embeddings. Qual modelo de embedding você usa? Embeddings de modelos diferentes capturam semântica de formas diferentes. Um modelo de embedding treinado predominantemente em inglês vai ter performance degradada em português sem ajuste. Essa é uma decisão que afeta tudo que vem depois e que raramente recebe a atenção que merece.
Estratégia de indexação. Busca puramente semântica falha quando a consulta usa terminologia diferente do documento, mesmo que o significado seja idêntico. Busca híbrida, combinando vetorial com lexical, melhora recall em boa parte dos casos mas adiciona complexidade de configuração e tuning.
Recuperação. Quantos chunks você recupera por consulta? Poucos e você perde contexto relevante. Muitos e você polui o contexto com informação que confunde o modelo e aumenta custo por chamada. O número certo depende do caso de uso e precisa ser calibrado com dados reais de uso.
Reranking. Os chunks recuperados por similaridade vetorial não são necessariamente os mais relevantes para a consulta específica. Rerankers aplicam uma segunda camada de avaliação para ordenar os resultados antes de injetar no contexto. É um passo que a maioria das implementações que vi pula e que frequentemente faz diferença mensurável na qualidade da resposta.
Geração. Só aqui o modelo recebe o contexto e gera a resposta. Se qualquer etapa anterior foi mal implementada, a geração será baseada em contexto ruim. O modelo vai fazer o melhor que pode com o que recebe, mas não vai compensar recuperação de má qualidade. Nenhum modelo faz isso.
Implementar RAG sem atenção a cada uma dessas etapas é construir sobre fundação fraca. Funciona na demo porque a demo usa documentos limpos, consultas previsíveis e o happy path. Aparece em produção quando chegam documentos reais, consultas variadas e usuários que não sabem exatamente o que estão procurando.
Quando RAG é a escolha certa e quando não é
RAG resolve bem um problema específico: dar ao modelo acesso a conhecimento externo e atualizado de forma dinâmica, sem retreinar o modelo.
Funciona bem quando: a base de conhecimento muda com frequência e precisa estar disponível para o modelo em tempo real; quando o conhecimento é vasto demais para caber no contexto de uma única chamada; quando você precisa de rastreabilidade clara (saber de onde veio a informação que embasou cada resposta).
Não é a escolha certa quando: o conhecimento que o modelo precisa é estável e pequeno o suficiente para caber num contexto bem estruturado; quando a latência adicional da etapa de recuperação é inaceitável para o caso de uso; quando a base de dados não está organizada e limpa o suficiente para produzir recuperações confiáveis.
Esse último caso é mais comum do que parece. Trabalhei com uma empresa que queria implementar RAG sobre anos de emails e documentos internos sem qualquer organização. O problema não era implementar o pipeline de recuperação. Era que a base era tão inconsistente que qualquer coisa que você recuperasse ia ser ruído tanto quanto sinal. RAG sobre dado ruim produz resposta ruim com muita confiança aparente, que é pior do que admitir que não sabe.
RAG dentro de uma arquitetura real
Em aplicações bem arquitetadas, RAG é um componente dentro da camada de preparação de contexto. Ele coexiste com outras fontes de contexto: dados do usuário autenticado, estado da sessão, resultado de chamadas a sistemas externos, regras de negócio estruturadas.
A orquestração decide, para cada consulta, qual combinação de contextos é relevante. Às vezes RAG é o contexto principal. Às vezes é secundário. Às vezes não é necessário para aquela consulta específica.
Tratar RAG como a arquitetura em vez de como um componente da arquitetura leva a sistemas otimizados para um tipo de consulta e que falham quando o caso de uso evolui.
O que acontece quando você vende RAG como diferencial de produto
Quando uma empresa posiciona "temos RAG" como diferencial, está descrevendo a implementação de um componente técnico como se fosse capacidade de negócio. O usuário não compra RAG. Compra resposta precisa, acesso rápido a informação, processo mais eficiente, decisão mais bem fundamentada.
RAG pode ajudar a entregar isso. O que determina se vai ou não vai é a qualidade do pipeline inteiro, da preparação dos documentos até a validação do output, não a presença da técnica.
O diferencial real está em: quão bem o sistema entende as consultas dos seus usuários no seu domínio específico; quão limpa e organizada está a base de conhecimento que alimenta o sistema; quão precisa é a recuperação para o vocabulário e as intenções típicas do seu caso de uso; e quão bem calibrada está a geração para o nível de detalhe e formato que o usuário precisa.
Tudo isso é trabalho de engenharia de produto. RAG é um dos ingredientes, não a receita.
RAG é uma técnica poderosa. Bem implementada, dentro de uma arquitetura bem pensada, com dados de qualidade e pipeline calibrado, ela melhora significativamente a capacidade de sistemas de IA de trabalhar com conhecimento específico de domínio.
Mas a técnica não substitui a engenharia. E no mercado atual, onde RAG virou palavra em proposta comercial sem que a maioria de quem a usa consiga explicar as seis etapas do pipeline, confundir as duas é o caminho mais rápido para um sistema que impressiona na apresentação e decepciona no uso real.
