Se você já colocou documentos de uma empresa dentro de uma ferramenta de inteligência artificial e esperou que ela passasse a responder perguntas corretamente sobre aquele conteúdo, provavelmente percebeu uma coisa: colocar os arquivos lá dentro é a parte fácil.
O problema começa quando as respostas precisam ser realmente confiáveis.
É nesse ponto que entra o RAG, sigla para Retrieval-Augmented Generation, ou Geração Aumentada por Recuperação.
A ideia central é relativamente simples. Em vez de depender apenas do conhecimento que um modelo de linguagem aprendeu durante seu treinamento, o sistema pesquisa informações relevantes em uma base externa e fornece esse contexto ao modelo antes que ele produza a resposta.
Na prática, porém, um bom sistema RAG envolve uma cadeia de decisões técnicas. A qualidade dos documentos, a forma como eles são divididos, os embeddings, a estratégia de busca, os filtros, o reranking, o contexto enviado ao modelo e a maneira como o sistema é avaliado podem alterar completamente o resultado.
Por isso, considero mais útil pensar em RAG como uma arquitetura de acesso ao conhecimento do que simplesmente como uma funcionalidade de chatbot.
O que é RAG
RAG combina duas capacidades diferentes.
A primeira é a recuperação de informação. O sistema recebe uma pergunta e procura, em uma base de conhecimento, os trechos mais relevantes para respondê-la.
A segunda é a geração de linguagem. Um modelo de IA recebe a pergunta junto com o contexto recuperado e produz uma resposta utilizando essas informações.
O conceito foi formalizado em um trabalho publicado em 2020 por Patrick Lewis e outros pesquisadores, que propôs combinar conhecimento armazenado nos parâmetros do modelo com conhecimento externo recuperado durante a execução.
Uma forma simples de visualizar o processo é:
Pergunta → busca na base → recuperação dos trechos relevantes → contexto → modelo de linguagem → resposta
Isso muda uma característica importante da aplicação.
O conhecimento específico do negócio pode ser atualizado na base de informações sem que seja necessário treinar novamente o modelo de linguagem para cada alteração documental.
Imagine uma empresa com:
- manuais internos
- políticas comerciais
- documentação técnica
- contratos
- FAQs
- procedimentos operacionais
- informações de produtos
- histórico de atendimento
- documentação de sistemas
Um RAG pode utilizar esse material como fonte de contexto para responder perguntas.
Mas existe uma condição importante: o sistema precisa conseguir encontrar a informação correta.
RAG não corrige uma base de conhecimento ruim
Essa é uma das partes mais importantes de qualquer projeto de RAG.
Se a empresa possui documentos antigos, contraditórios, incompletos ou mal estruturados, simplesmente colocá-los em um banco vetorial não resolve o problema.
Na realidade, pode tornar o problema mais difícil de perceber.
O modelo recebe informações aparentemente plausíveis e pode produzir uma resposta convincente baseada em um documento inadequado.
A qualidade da base de conhecimento, portanto, precisa ser tratada como parte da arquitetura.
Antes de pensar em embeddings ou banco vetorial, vale perguntar:
Quais informações a IA realmente precisa consultar?
E depois:
Essas informações estão corretas, atualizadas e organizadas de uma maneira que permita recuperá-las?
Esse cuidado é especialmente importante em ambientes empresariais.
Uma política comercial modificada ontem não deveria competir em igualdade de condições com uma versão antiga armazenada há dois anos.
Como funciona um pipeline RAG
Um sistema RAG pode ser dividido em algumas etapas principais.
1. Ingestão dos documentos
Primeiro é necessário coletar os dados.
Eles podem estar em PDFs, páginas web, arquivos Word, bases internas, wikis, tickets, e-mails, código ou outros sistemas.
Essa etapa parece simples até aparecer um PDF com tabelas, duas colunas, imagens, cabeçalhos repetidos e páginas digitalizadas.
A extração precisa preservar o máximo possível da estrutura e do significado original.
HTML e Markdown, por exemplo, normalmente oferecem uma estrutura semântica mais amigável para processamento do que documentos cujo conteúdo está preso a um layout visual.
O ponto importante é que extrair texto não significa necessariamente extrair conhecimento corretamente.
2. Limpeza e preparação
Depois da extração vem o tratamento do conteúdo.
Podem existir:
- cabeçalhos repetidos
- rodapés
- números de página
- quebras artificiais
- marcas d’água
- caracteres estranhos
- erros de OCR
- tabelas desorganizadas
- trechos duplicados
Imagine um manual técnico no qual cada página começa com o nome da empresa e termina com um aviso jurídico.
Se esses elementos forem incorporados indiscriminadamente aos chunks, eles passam a fazer parte da informação pesquisável.
Em alguns documentos isso terá pouco impacto. Em outros, poderá prejudicar a recuperação.
3. Chunking
Aqui aparece uma das decisões mais importantes do RAG.
Chunking é o processo de dividir documentos maiores em unidades menores que possam ser indexadas e recuperadas.
Um chunk pequeno demais pode perder contexto.
Um chunk grande demais pode misturar assuntos diferentes e dificultar a recuperação da informação específica.
Não existe um tamanho universalmente correto.
Um contrato, uma documentação de API, um artigo de blog e uma política interna podem exigir estratégias completamente diferentes.
Por isso, uma estratégia baseada apenas em “divida tudo a cada X caracteres” pode funcionar em um teste simples e apresentar problemas quando a aplicação cresce.
4. Embeddings
Depois de dividir o conteúdo, os chunks podem ser transformados em representações vetoriais chamadas embeddings.
A ideia é representar semanticamente o conteúdo para permitir que textos relacionados possam ser encontrados mesmo quando as palavras utilizadas na pergunta não forem exatamente iguais às palavras presentes no documento.
Por exemplo, alguém poderia perguntar:
“Como faço para cancelar meu plano?”
Enquanto a documentação talvez contenha:
“Procedimento para encerramento da assinatura.”
Uma busca puramente baseada em palavras pode ter dificuldades dependendo da implementação. A busca semântica consegue trabalhar melhor com relações de significado.
5. Armazenamento
Os embeddings precisam ser armazenados para que possam ser pesquisados posteriormente.
É aqui que entram os chamados vector databases ou mecanismos de busca vetorial.
Entre as alternativas existentes estão bancos especializados e também plataformas que incorporam recursos de busca semântica.
O armazenamento, porém, não deveria guardar apenas o vetor.
Metadados são extremamente importantes.
Uma informação pode ter atributos como:
- documento de origem
- departamento
- produto
- idioma
- data
- versão
- nível de acesso
- categoria
- autor
Esses dados podem ser utilizados posteriormente para restringir a busca.
A busca é provavelmente a parte mais subestimada
Imagine uma empresa com 100 mil documentos.
O sistema pode possuir embeddings excelentes e ainda assim retornar os documentos errados.
Por isso, o mecanismo de retrieval merece atenção.
Existem diferentes estratégias.
Busca semântica
Procura documentos com significado semelhante à pergunta.
É muito útil quando a pessoa formula a pergunta de maneira diferente daquela utilizada na documentação.
Busca por palavras-chave
Pode ser particularmente importante quando nomes próprios, códigos, números de produtos, identificadores ou termos técnicos precisam ser encontrados com precisão.
Busca híbrida
Combina diferentes mecanismos.
Em muitos cenários empresariais, essa abordagem faz bastante sentido porque permite explorar tanto correspondência textual quanto similaridade semântica.
Reranking
Outra possibilidade é recuperar inicialmente um conjunto maior de candidatos e depois utilizar um mecanismo adicional para reorganizar os resultados de acordo com sua relevância.
Isso cria uma arquitetura em duas etapas:
recuperação inicial → seleção ou ordenação dos melhores resultados
O objetivo é entregar ao modelo um contexto mais relevante, em vez de simplesmente enviar tudo aquilo que apareceu na primeira busca.
RAG não significa jogar documentos inteiros no prompt
Esse erro aparece com frequência em implementações iniciais.
A pessoa possui uma documentação de 500 páginas e tenta colocar o máximo possível dentro do contexto do modelo.
Mesmo que o modelo suporte uma janela de contexto grande, isso não significa que essa seja uma boa arquitetura.
O sistema precisa encontrar o que é relevante para aquela pergunta.
Um bom RAG tenta reduzir o problema de:
“Tenho milhares de documentos.”
para:
“Quais poucos trechos são realmente necessários para responder esta pergunta?”
Essa diferença é fundamental para custo, latência e qualidade.
E onde entra a geração da resposta
Depois que os documentos relevantes são recuperados, eles são enviados ao modelo de linguagem juntamente com a pergunta.
O modelo então utiliza esse contexto para produzir a resposta.
Mas ainda existem decisões importantes.
O sistema pode instruir o modelo, por exemplo, a:
- utilizar prioritariamente o contexto recuperado
- informar quando não encontrou informação suficiente
- não inventar uma resposta
- indicar a fonte utilizada
- diferenciar informação documental de inferência
- respeitar regras de acesso
Isso ajuda, mas não transforma automaticamente o sistema em uma fonte confiável.
Se o retrieval recuperar o documento errado, um prompt perfeito não resolve completamente o problema.
RAG reduz alucinações, mas não elimina o problema
Existe uma promessa comum de que RAG “acaba com as alucinações”.
Eu evitaria essa afirmação.
RAG pode fornecer ao modelo evidências externas e reduzir situações em que ele depende exclusivamente do conhecimento aprendido durante o treinamento.
Mas ainda existe uma cadeia de possíveis falhas.
O documento pode estar errado.
O parser pode ter extraído o conteúdo incorretamente.
O chunk pode ter perdido contexto.
A busca pode recuperar o trecho errado.
O reranking pode priorizar um resultado inadequado.
O contexto pode ser insuficiente.
O modelo pode interpretar incorretamente as evidências.
Por isso, a pergunta correta não deveria ser apenas:
“O RAG funciona?”
A pergunta deveria ser:
“Em quais tipos de perguntas ele funciona, com qual taxa de acerto e em quais condições ele falha?”
Como avaliar um sistema RAG
Essa mudança de mentalidade é fundamental quando o projeto sai do protótipo.
Não basta fazer cinco perguntas e concluir que o chatbot parece inteligente.
É necessário construir um conjunto representativo de perguntas e avaliar o comportamento do sistema.
Por exemplo:
- a informação correta foi recuperada?
- o trecho recuperado realmente responde à pergunta?
- informações irrelevantes foram incluídas?
- a resposta está de acordo com os documentos?
- a resposta inventou alguma informação?
- o sistema reconheceu quando não havia informação suficiente?
- a fonte apresentada corresponde ao conteúdo utilizado?
A avaliação pode ser feita em diferentes camadas.
Uma coisa é medir a qualidade do retrieval.
Outra é medir a qualidade da resposta final.
Misturar as duas pode esconder onde está o problema.
Se a resposta está errada porque o documento correto nunca foi recuperado, melhorar o prompt do modelo provavelmente não resolverá a causa.
RAG ou fine-tuning
Essa é outra decisão que costuma gerar confusão.
RAG e fine-tuning resolvem problemas diferentes.
O RAG é especialmente interessante quando você precisa fornecer ao modelo informações externas que mudam, crescem ou precisam ser consultadas de maneira verificável.
Fine-tuning, por outro lado, pode ser utilizado para adaptar o comportamento de um modelo a determinados padrões, tarefas ou estilos.
Pense em uma empresa que atualiza sua política de preços semanalmente.
Treinar novamente um modelo para incorporar cada alteração seria uma estratégia pouco prática.
Uma base de conhecimento atualizável pode fazer muito mais sentido nesse cenário.
Já se o problema for fazer o modelo seguir consistentemente determinado padrão de saída ou executar uma tarefa específica de uma determinada maneira, a discussão pode ser outra.
Em alguns projetos, inclusive, as duas abordagens podem coexistir.
Quando RAG faz sentido para um negócio
Existem aplicações bastante interessantes.
Atendimento e suporte
Um assistente pode consultar documentação de produtos, políticas, procedimentos e FAQs para ajudar clientes ou equipes internas.
Base de conhecimento interna
Funcionários podem fazer perguntas sobre processos, documentação e políticas sem precisar procurar manualmente em dezenas de sistemas.
Documentação técnica
Equipes de tecnologia podem consultar documentação, decisões arquiteturais, manuais e código.
Análise de documentos
Contratos, relatórios, políticas e outros documentos podem ser utilizados como fontes para consultas específicas.
Assistentes especializados
Uma empresa pode construir uma aplicação orientada a um domínio específico utilizando sua própria base de conhecimento.
É aqui que RAG começa a ficar particularmente interessante para pequenos e médios negócios.
Você não precisa necessariamente construir um grande produto de IA.
Pode existir uma aplicação muito mais simples e útil, como um assistente interno capaz de responder perguntas sobre procedimentos comerciais, documentação ou produtos.
Segurança não pode ser adicionada no final
Existe ainda uma questão que muitas demonstrações deixam de lado.
Quem pode consultar quais informações?
Imagine uma empresa com documentos de diferentes departamentos.
O funcionário do setor comercial não necessariamente deveria conseguir recuperar documentos financeiros confidenciais.
Por isso, controle de acesso precisa fazer parte da arquitetura.
Metadados podem ajudar nessa filtragem.
O sistema pode associar documentos a departamentos, usuários, níveis de acesso ou outros atributos e utilizar essas informações durante a recuperação.
Um RAG que responde muito bem, mas entrega informações para quem não deveria acessá-las, é um sistema tecnicamente perigoso.
O custo real está além do modelo de IA
Quando alguém calcula o custo de um projeto RAG olhando apenas para o preço das chamadas ao modelo de linguagem, está deixando uma parte importante da conta de fora.
Existe custo de:
- armazenamento
- processamento
- embeddings
- infraestrutura
- indexação
- atualização da base
- observabilidade
- avaliação
- manutenção
- integração
- segurança
Existe também o custo operacional de manter a informação confiável.
Uma base de conhecimento desatualizada não deixa de ser um problema porque foi colocada em um vector database.
RAG na prática exige pensar como engenheiro de conhecimento
Esse talvez seja o principal aprendizado que eu tiraria de uma análise mais cuidadosa do tema.
É fácil transformar um conjunto de documentos em uma demonstração de chatbot.
É muito mais difícil construir um sistema que continue entregando respostas confiáveis quando a quantidade de documentos aumenta, os processos mudam, os usuários fazem perguntas inesperadas e os dados possuem diferentes níveis de qualidade.
Por isso, eu começaria um projeto RAG por uma pergunta de negócio:
Qual decisão ou tarefa queremos melhorar utilizando conhecimento empresarial recuperável?
Depois definiria:
- quais informações serão utilizadas
- quem poderá acessá-las
- com que frequência elas mudam
- como os documentos serão atualizados
- como a informação será dividida
- como será feita a recuperação
- como o sistema será avaliado
- quais serão os critérios para considerar uma resposta aceitável
Só então escolheria as ferramentas.
A tecnologia disponível hoje torna relativamente simples criar o primeiro protótipo. Por exemplo, plataformas de IA já oferecem recursos de armazenamento vetorial, busca semântica, filtros por metadados e estratégias de chunking configuráveis.
Isso é ótimo para experimentar.
Mas a facilidade de montar um protótipo também cria uma armadilha: confundir uma demonstração funcional com um sistema pronto para produção.
O futuro do RAG está ficando menos parecido com um simples chatbot
RAG continua evoluindo.
Existem arquiteturas que combinam diferentes estratégias de recuperação, reranking, agentes, grafos de conhecimento, informações multimodais e mecanismos de avaliação.
Isso amplia bastante o que pode ser feito.
Mas existe uma tendência que considero mais importante do que qualquer nova sigla:
a IA está deixando de ser apenas uma interface de geração de texto e passando a funcionar como uma camada de acesso ao conhecimento e aos sistemas de uma organização.
Nesse cenário, RAG é uma das arquiteturas que tornam essa transformação possível.
Para quem trabalha com negócios digitais, isso abre uma oportunidade interessante.
Em vez de pensar apenas em “usar ChatGPT na empresa”, podemos começar a pensar em algo mais estruturado:
Quais conhecimentos da empresa deveriam estar disponíveis para uma IA consultar, em quais situações e sob quais regras?
Essa pergunta leva a projetos muito mais interessantes do que simplesmente colocar um chatbot no site.
E também muda a forma de enxergar a própria informação.
Documentos organizados, atualizados, versionados e bem estruturados deixam de ser apenas arquivos armazenados em algum lugar. Eles passam a fazer parte da infraestrutura de inteligência do negócio.
