RAG é a técnica que conecta um modelo de linguagem aos documentos da sua empresa antes de ele responder. A sigla vem de retrieval augmented generation, ou geração aumentada por recuperação. Em vez de confiar apenas no que o modelo aprendeu no treino, o sistema busca o trecho certo na sua base e entrega esse texto junto com a pergunta. A resposta então fica ancorada em política interna, contrato e manual, não em memória genérica. É a forma mais barata de tirar a IA do genérico e colocá-la dentro da sua operação.
O que é RAG?
RAG: arquitetura que recupera trechos relevantes de uma base própria e entrega esse contexto ao modelo de linguagem no momento da resposta.
A ideia nasceu num artigo acadêmico. Em 2020, Patrick Lewis e colegas publicaram o trabalho Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, que combinou memória paramétrica, aquilo que está nos pesos do modelo, com memória não paramétrica, aquilo que está num índice externo consultável.
A documentação da AWS descreve o mesmo princípio em linguagem de operação: o RAG amplia o modelo com dados externos, como documentos internos, para produzir saída útil no seu caso específico.
Na prática, isso resolve o problema mais chato de qualquer piloto de IA. O modelo passa a citar a sua tabela de preço, o seu prazo de garantia e a sua política de troca, em vez de inventar um padrão de mercado.
Existe um ganho silencioso nessa arquitetura que costuma decidir a aprovação interna. Como a resposta vem acompanhada do trecho recuperado, qualquer pessoa consegue conferir a origem da informação. Auditoria deixa de ser promessa e passa a ser clique.
Como o RAG funciona na prática?
O fluxo tem quatro etapas e cada uma pode quebrar sozinha. Vale conhecer todas antes de aprovar orçamento.
| Etapa | O que acontece | Risco típico |
|---|---|---|
| Ingestão | Documentos são lidos e quebrados em pedaços | Pedaço grande demais perde precisão |
| Indexação | Cada pedaço vira vetor e entra no índice | Base desatualizada devolve resposta velha |
| Recuperação | A pergunta busca os trechos mais próximos | Busca traz o documento errado |
| Geração | O modelo responde usando os trechos | Resposta ignora o contexto entregue |
A conversão de texto em número acontece por embeddings, e o índice costuma morar num banco de dados vetorial. Nada disso é exótico hoje, porque os provedores entregam esses componentes prontos.
O trabalho difícil está na etapa de recuperação. Se o sistema traz o trecho errado, o modelo responde com confiança sobre a informação errada, e o usuário não tem como perceber.
Um exemplo concreto ajuda a dimensionar. Numa base de atendimento com oito mil documentos, cortar cada arquivo em pedaços de mil caracteres gera cerca de quarenta mil trechos indexados. Cada pergunta recupera de três a cinco desses trechos, então a qualidade do corte define a qualidade da resposta muito antes de o modelo entrar em ação.
Quando usar RAG e quando evitar?
Use RAG quando o conhecimento muda com frequência e precisa de rastreabilidade. Base de atendimento, política interna, catálogo, jurisprudência e documentação técnica se encaixam bem.
Evite quando a tarefa depende de estilo, formato ou comportamento, e não de fato novo. Aí o caminho costuma ser ajuste fino ou um prompt melhor estruturado.
Também evite quando a resposta exige cálculo ou ação em sistema. Nesse caso o certo é chamada de função, com o modelo acionando uma API que devolve o número correto.
Vale lembrar que as abordagens convivem. Boa parte das operações maduras usa RAG para o fato, chamada de função para a ação e engenharia de contexto para organizar o que entra na janela do modelo.
Uma pergunta prática resolve a dúvida na maioria dos casos. A informação que falta está escrita em algum documento seu? Se sim, o caminho é RAG. Se a informação precisa ser calculada ou buscada num sistema vivo, o caminho é integração por API.
Por que o CTO precisa olhar isso agora
O mercado já decidiu que essa é a técnica padrão. O relatório 2025: The State of Generative AI in the Enterprise, da Menlo Ventures, feito com quase 500 tomadores de decisão nos Estados Unidos, aponta o design de prompt como técnica dominante, seguido justamente pelo RAG. Ajuste fino e aprendizado por reforço seguem restritos a times de fronteira.
O mesmo estudo joga água fria no discurso de agentes autônomos. Apenas 16% das implantações corporativas se qualificam como agentes de verdade, porque a maioria é fluxo de sequência fixa em volta de uma chamada de modelo.
O dinheiro acompanha esse movimento. A Menlo registra investimento corporativo em IA saindo de 11,5 bilhões para 37 bilhões de dólares em um ano, com 76% das soluções compradas prontas em vez de construídas internamente.
O ponto que importa para quem responde por resultado veio da McKinsey, em março de 2025. Entre as empresas que usam IA generativa, só 21% redesenharam ao menos parte dos fluxos de trabalho, e o redesenho é o fator com maior correlação com impacto no EBIT. Colocar RAG por cima de um processo torto entrega processo torto com resposta mais bonita.
Onde o RAG falha na vida real
A promessa é boa, contudo o projeto quebra em pontos previsíveis. Cinco deles aparecem em quase toda implantação.
- Base suja. Documento duplicado, versão antiga e PDF escaneado sem texto derrubam a qualidade antes de o modelo entrar em cena.
- Pedaços mal definidos. Corte que separa a pergunta da resposta faz a busca trazer metade da informação.
- Falta de citação. Sem mostrar a fonte de cada trecho, ninguém audita a resposta e a confiança do time desaba.
- Permissão ignorada. Se o índice não respeita quem pode ver o quê, você criou um vazamento com interface amigável.
- Ausência de medição. Sem avaliação de IA, o time não sabe se a mudança de ontem melhorou ou piorou a resposta.
Já vi um projeto de suporte perder credibilidade em duas semanas por causa do quarto item. O agente respondia com dados de contrato de outro cliente, e a demonstração acabou ali.
Existe também um erro de expectativa que custa caro. Time que espera do RAG um salto de inteligência se frustra, porque a técnica melhora a fundamentação da resposta, e não a capacidade de raciocínio do modelo. Pergunta ambígua continua gerando resposta ambígua, ainda que o trecho recuperado esteja perfeito.
Do piloto à produção
Comece por um domínio estreito e chato. Um manual, uma política, uma base de dúvidas frequentes. Escopo pequeno acelera aprendizado e reduz risco de exposição. Assim você aprende com pergunta real e não com hipótese de sala de reunião.
Defina antes o critério de sucesso em número. Percentual de respostas corretas, tempo até a resposta, custo por consulta e taxa de erro grave. Sem isso, a discussão vira opinião sobre qual resposta pareceu melhor.
Trate a LGPD desde o desenho, não no final. Mapeie que dado pessoal entra no índice, quem pode consultar e por quanto tempo o registro fica guardado. Aqui no Brasil, esse ponto costuma travar aprovação jurídica no último minuto.
Cuide também do custo. Cada consulta paga recuperação e geração, então contexto inchado vira conta alta no fim do mês. Limitar o número de trechos recuperados costuma cortar gasto sem perder qualidade.
Planeje a atualização da base desde o início. Documento novo precisa entrar no índice sem intervenção manual, senão a rotina de reindexação vira tarefa esquecida e o sistema envelhece em silêncio. Uma automação simples, disparada quando o arquivo muda na pasta oficial, resolve a maior parte desse risco.
Defina ainda quem responde pelo sistema no dia a dia. Modelo, índice e prompt mudam com frequência, então alguém precisa aprovar cada alteração e acompanhar o efeito nas métricas. Sem dono, o RAG vira projeto de todos e responsabilidade de ninguém.
Minha leitura depois de colocar esse tipo de sistema em operação: o gargalo raramente é o modelo. Ele está na curadoria da base e em quem responde por ela. Empresa que nomeia um dono para o conteúdo, com rotina de revisão mensal, tira mais valor de um RAG simples do que empresa que troca de modelo a cada release sem arrumar a fonte.
Por onde começar esta semana
O RAG deixou de ser novidade técnica e virou infraestrutura de operação. Ele conecta o modelo ao seu conhecimento e devolve respostas auditáveis. Cinco ações colocam o projeto de pé sem aventura.
- Escolha um domínio único, com dono definido e volume alto de perguntas repetidas.
- Limpe a base antes de indexar, removendo versão antiga, duplicata e documento sem texto legível.
- Exija citação de fonte em toda resposta, com link para o trecho recuperado.
- Aplique permissão no índice, respeitando quem pode ver cada documento, e registre consulta para auditoria.
- Monte um conjunto de avaliação com cem perguntas reais e rode a cada mudança relevante.
Meça em sessenta dias e compare com o atendimento atual. Se a taxa de acerto e o custo por consulta fecharem, expanda para o segundo domínio. Vale revisar também a engenharia de prompt do sistema, porque instrução vaga desperdiça um bom mecanismo de recuperação.
Perguntas frequentes
Comentários (0)