O que é RAG: como pôr a IA a responder com os vossos documentos

O que é RAG? RAG (Retrieval-Augmented Generation, em português "geração aumentada por recuperação") é a técnica que põe um modelo de linguagem a responder com base nos documentos da vossa empresa — manuais, procedimentos, contratos, fichas técnicas — em vez de responder só com o que aprendeu no treino. A pergunta que nos fazem a seguir raramente é técnica: é "consigo pôr um assistente a responder com os nossos documentos sem inventar e sem mostrar a quem não deve aquilo que não deve?" Consegue-se, mas a qualidade depende muito menos do modelo do que se pensa e muito mais da preparação dos documentos, das permissões e de como se mede. Este guia explica o RAG passo a passo, quando usar RAG, fine-tuning ou um prompt longo, onde falha, como se avalia, o que o RGPD exige e o que faz subir o custo.

TL;DR:

• RAG = pesquisa + geração. Antes de responder, o sistema vai buscar os excertos relevantes aos vossos documentos e entrega-os ao modelo junto com a pergunta; a resposta sai com a fonte citada.
• Para conhecimento que muda, o RAG ganha ao fine-tuning. O fine-tuning muda o comportamento do modelo; o RAG muda o que ele sabe no momento da pergunta. Atualizar um preço é re-indexar um documento, não re-treinar um modelo.
• A maioria das falhas é de recuperação, não do modelo: documentos desatualizados, PDF digitalizados, tabelas e permissões mal propagadas. E o RAG reduz as alucinações, não as elimina — ferramentas jurídicas comerciais baseadas em RAG alucinaram entre 17% e 33% das vezes num estudo de Stanford.
• O custo está na engenharia, não nos embeddings: indexar milhares de páginas custa cêntimos em API. O que pesa é ligar as fontes, tratar as permissões e construir o conjunto de teste.

O que é RAG?

RAG é uma arquitetura em que um modelo de linguagem (LLM) recebe, junto com a pergunta, os excertos de documentos mais relevantes para lhe responder — e é instruído a responder apenas com base neles, citando de onde veio cada afirmação. O termo vem de um artigo de investigação de 2020 de Patrick Lewis e colegas, apresentado na conferência NeurIPS, que combinava um modelo gerador com um índice pesquisável de documentos (Lewis et al., 2020).

A analogia mais útil é a de um exame com consulta. Um LLM sozinho responde de memória: sabe muito, mas não sabe nada sobre o vosso procedimento de devoluções, a tabela de preços deste ano ou a ficha técnica do produto lançado em março — e, quando não sabe, tende a produzir uma resposta plausível. Com RAG, antes de responder, o sistema abre o dossier certo na página certa.

Três coisas que o RAG não é:

• Não é treinar um modelo. Os vossos documentos não entram nos pesos do modelo; ficam numa base de dados vossa e são consultados a cada pergunta.
• Não é um produto. É um padrão de arquitetura. Há ferramentas prontas que o implementam de forma genérica e sistemas à medida que o implementam bem para um caso concreto.
• Não é só um chatbot. O mesmo mecanismo serve um assistente interno, um agente que prepara respostas a tickets ou uma pesquisa em linguagem natural sobre o arquivo técnico.

O que é um LLM, em poucas linhas. Um LLM (large language model, modelo de linguagem de grande escala) é um modelo treinado em enormes quantidades de texto para prever a palavra seguinte. É isso que permite ao ChatGPT, ao Claude ou ao Gemini escrever, resumir e responder em linguagem corrente. O conhecimento dele fica congelado na data do treino e não inclui os vossos documentos internos — é exatamente essa lacuna que o RAG preenche. Mais contexto no nosso guia de IA generativa.

Como funciona o RAG, passo a passo?

Um sistema RAG tem duas fases: uma preparação, feita antes de qualquer pergunta (ingestão, chunking, embeddings, indexação), e uma resposta, feita a cada pergunta (recuperação, reranking e geração com citações). A primeira decide se o sistema consegue encontrar a informação; a segunda decide se a usa bem.

1. Ingestão: ler as fontes

O sistema vai buscar os documentos onde eles vivem — SharePoint, Google Drive, pasta de rede, ERP, helpdesk, site — e extrai o texto. É aqui que aparecem os PDF digitalizados (que precisam de OCR), as tabelas que se desfazem na extração e as cinco versões do mesmo procedimento. É também aqui que se guardam os metadados que vão fazer falta mais tarde: data, versão, área e, sobretudo, quem tem permissão para ver cada documento.

2. Chunking: partir em excertos

Um documento de 80 páginas não cabe — nem deve caber — inteiro em cada pergunta. Parte-se em excertos (chunks), normalmente de algumas centenas de tokens cada (Anthropic, 2024). Partir bem é respeitar a estrutura: um artigo de um regulamento, uma secção de um manual, uma linha de uma tabela com o respetivo cabeçalho. Partir mal é cortar a meio da frase que tinha a resposta.

3. Embeddings: transformar texto em vetores

Cada excerto passa por um modelo de embeddings, que o converte num vetor — uma lista de números que representa o significado. Textos com significado próximo ficam com vetores próximos, mesmo que usem palavras diferentes: "prazo de devolução" e "quantos dias tenho para devolver" encontram-se. A pergunta do utilizador passa pelo mesmo modelo, para que pergunta e documentos fiquem no mesmo espaço.

4. Base de dados vetorial: guardar e indexar

Os vetores vão para uma base de dados que sabe encontrar depressa "os mais parecidos com este". Se já têm PostgreSQL, a extensão open-source pgvector acrescenta pesquisa vetorial à base que já operam, com índices HNSW e IVFFlat. Motores de pesquisa vetorial dedicados, como o Qdrant, fazem sentido quando o volume ou os requisitos de filtragem e desempenho passam do que querem pedir ao PostgreSQL. Para a maioria das PME, a escolha da base vetorial é a decisão menos importante do projeto.

5. Recuperação: encontrar os excertos certos

Quando chega uma pergunta, o sistema procura os excertos mais próximos. Em produção, a pesquisa semântica raramente chega sozinha: combina-se com pesquisa por palavras-chave (BM25), que apanha códigos de produto, números de artigo e siglas que os embeddings tratam mal, e com filtros por metadados — versão em vigor, área e as permissões de quem pergunta.

6. Reranking: reordenar antes de responder

Um segundo modelo reavalia os candidatos e fica só com os melhores. Nos testes publicados pela Anthropic, combinar embeddings contextuais com BM25 reduziu em 49% as falhas de recuperação, e acrescentar reranking levou essa redução a 67% (Anthropic, 2024). Os números são do conjunto de teste deles, não do vosso — mas a direção repete-se nos projetos: o reranking é das melhorias mais baratas que existem.

7. Geração com citações

Os excertos escolhidos e a pergunta vão para o LLM com instruções explícitas: responder só com base no contexto, citar a fonte de cada afirmação e dizer "não encontrei isto na documentação" quando for o caso. A citação não é decoração — é o que permite ao utilizador verificar e à equipa auditar.

RAG vs fine-tuning vs prompt longo: quando usar cada um?

Usem RAG quando o problema é o que o modelo sabe; fine-tuning quando o problema é como o modelo se comporta; e um prompt longo quando o conhecimento cabe inteiro na janela de contexto e muda pouco. Fine-tuning é voltar a treinar o modelo com exemplos vossos: ensina formato, tom e classificação, mas é uma má forma de lhe ensinar factos que mudam todos os meses — e não diz de onde veio cada resposta.

O prompt longo é a opção que mais se esquece. A Anthropic indica que, com uma base de conhecimento abaixo de cerca de 200.000 tokens (perto de 500 páginas), pode ser mais simples incluir tudo no prompt do que montar recuperação (Anthropic, 2024). Tem dois limites. O custo e a latência: paga-se o documento inteiro em cada pergunta (o prompt caching atenua). E a qualidade: um estudo publicado na TACL mostrou que os modelos usam pior a informação que está a meio de contextos longos do que a que está no início ou no fim (Liu et al., 2023).

Na prática combinam-se, e a ordem quase sempre é a mesma: primeiro um prompt bem escrito, depois RAG, e fine-tuning só se o comportamento continuar a falhar com os documentos certos à frente do modelo.

Para que serve o RAG numa PME? Quatro exemplos portugueses

Os casos que compensam têm três coisas em comum: muitas perguntas repetidas, respostas que já existem algures num documento, e um custo real quando alguém responde de memória e erra. Estes são os quatro que vemos pedir mais vezes.

Manual interno, qualidade e procedimentos

O que faz: responde a "como se faz X aqui" a partir dos procedimentos, instruções de trabalho, manual de qualidade e regulamento interno, com a secção citada. Dados de que precisa: os documentos em vigor e o controlo de versões. Armadilha n.º 1: versões obsoletas indexadas ao lado das que estão em vigor — e o sistema responde com o procedimento de 2019. Num QMS para fabricantes de dispositivos médicos que construímos, o assistente regulatório responde fundamentado no texto regulatório real e cita a cláusula de onde veio a resposta (caso de estudo): num contexto de auditoria, uma resposta confiante mas errada é pior do que nenhuma.

Apoio a clientes

O que faz: prepara — ou dá, nos casos simples — respostas a pedidos de clientes a partir das FAQ, das condições gerais, dos manuais de produto e de tickets já resolvidos. Dados: base de conhecimento e histórico de tickets, limpo de dados pessoais. Armadilha n.º 1: o assistente comprometer a empresa com uma política, um prazo ou um preço que não existe. A regra que aplicamos: o que envolve dinheiro ou compromissos passa por uma pessoa. Quando o assistente também tem de agir — consultar uma encomenda, abrir um ticket, atualizar o CRM — deixa de ser só RAG e passa a ser um agente: são os agentes de IA ligados aos documentos e sistemas da empresa.

Contabilidade, fiscalidade e legislação

O que faz: em gabinetes de contabilidade e departamentos financeiros, responde a dúvidas com base nos códigos fiscais, nos ofícios-circulados da AT, na legislação publicada no Diário da República e nos memorandos internos, citando o artigo. Dados: corpus legislativo com data de vigência e o trabalho anterior da casa. Armadilha n.º 1: legislação revogada ou alterada — sem metadados de vigência, o sistema cita a versão antiga com toda a confiança. A IA prepara, o profissional decide; isto é informação geral, não aconselhamento fiscal. Mais casos em ideias de projetos de IA para contabilidade.

Catálogo técnico e fichas de produto

O que faz: num distribuidor ou fabricante, a equipa comercial pergunta "que referência aguenta esta pressão e é compatível com aquele equipamento" e recebe a resposta com a ficha técnica. Dados: fichas técnicas em PDF, catálogos, tabelas de compatibilidade e o ERP. Armadilha n.º 1: perguntas sobre números exatos, preços e stock. Essas resolvem-se com uma consulta estruturada ao ERP, não com pesquisa vetorial. O desenho certo é híbrido: RAG para o texto, consulta direta para os dados estruturados — o mesmo princípio da integração de ERP com IA.

Onde é que o RAG falha?

Quando um sistema RAG responde mal, a causa está quase sempre nos documentos ou na recuperação, não no modelo. Antes de trocar de LLM, verifiquem se o excerto certo chegou sequer ao modelo. As falhas que vemos repetir-se:

• Documentos maus. Desatualizados, contraditórios, duplicados. O RAG não arruma a documentação — expõe-na. Se três versões do mesmo procedimento estão na pasta, o sistema vai encontrar as três.
• PDF digitalizados e tabelas. Um PDF que é uma fotografia não tem texto até passar por OCR; uma tabela extraída como texto corrido perde a relação entre linha e coluna. Em catálogos técnicos e documentos financeiros, é aqui que se perde mais qualidade.
• Permissões. Se a indexação junta tudo num só índice, o assistente pode mostrar a um estagiário um excerto de um processo disciplinar ou da tabela salarial. As permissões têm de viajar com os excertos e ser aplicadas na recuperação — não "pedidas" ao modelo no prompt.
• Alucinações que não desaparecem. O RAG reduz o problema, não o elimina. Um estudo de Stanford a ferramentas jurídicas comerciais baseadas em RAG — cujos fornecedores as anunciavam como livres de alucinações — mediu respostas alucinadas entre 17% e 33% das vezes (Magesh et al., 2024).
• Perguntas que não são de pesquisa. "Quantas faturas temos em atraso há mais de 60 dias?" não se responde a encontrar excertos parecidos — é uma consulta à base de dados. Misturar as duas coisas sem desenho dá respostas erradas com ar de certas.
• Instruções escondidas nos documentos. Um documento ou email indexado pode conter texto que tenta dar ordens ao modelo (prompt injection indireta). O relatório sobre riscos de privacidade em LLM publicado no programa de peritos do EDPB inclui-a entre os riscos específicos do RAG, ao lado da recuperação de informação desatualizada (EDPB, 2025).

Uma demonstração de RAG com 20 PDF bem escolhidos funciona sempre. O que separa a demo de um sistema em que a equipa confia é a camada à volta: avaliação, monitorização, filas de exceção e alguém responsável pela qualidade — o mesmo problema que descrevemos em porque é que o vosso agente de IA não é fiável para escalar.

Como se avalia um sistema RAG?

Com um conjunto fixo de perguntas reais, cada uma com a resposta esperada e o documento onde ela está, medido em separado para a recuperação e para a resposta — e corrido de novo sempre que se muda alguma coisa. Sem isso, "parece que está melhor" é a única métrica, e não chega para pôr nada em produção.

Como o montamos:

1. Recolher perguntas reais — dos emails, dos tickets, da pessoa a quem toda a gente pergunta. Na nossa experiência, umas dezenas de perguntas bem escolhidas já mostram os problemas grandes; o importante é incluir as difíceis e as que não têm resposta na documentação.
2. Escrever a resposta certa e a fonte, com quem domina o tema. É trabalho de negócio, não de engenharia — e é a parte que mais se tenta saltar.
3. Medir a recuperação: a fonte certa está entre os excertos recuperados? A métrica context recall, por exemplo, mede quanta da informação relevante foi efetivamente recuperada (Ragas).
4. Medir a resposta: está correta? Cada afirmação está suportada pelo contexto recuperado (faithfulness)? Cita a fonte certa? Diz "não sei" quando devia?
5. Correr o conjunto a cada mudança de chunking, modelo, prompt ou fonte, e comparar com a versão anterior antes de pôr em produção.

Em produção junta-se o que só os utilizadores mostram: feedback positivo/negativo em cada resposta, registo das perguntas sem resposta (são, na prática, a lista da documentação que falta) e revisão humana de uma amostra todas as semanas.

RGPD: onde ficam os dados num sistema RAG?

Num sistema RAG os dados vivem em três sítios — na base de dados vetorial (que guarda vetores e cópias do texto dos excertos), no fornecedor do modelo (que recebe a pergunta e os excertos a cada resposta) e nos registos — e cada um precisa de uma decisão explícita sobre onde fica, quem acede e durante quanto tempo. O relatório sobre riscos de privacidade em LLM publicado em abril de 2025 no programa de peritos do EDPB aponta precisamente estes riscos no RAG: registos e cache inseguros, envio das perguntas a terceiros e exposição de dados pessoais guardados na base de conhecimento (EDPB, 2025).

As decisões a tomar, por ordem:

• Base vetorial. Alojada por vós (pgvector no vosso PostgreSQL, numa região da UE) ou num serviço gerido com região europeia contratada. O índice é uma cópia da vossa documentação: protejam-no com o mesmo nível de acesso dos documentos de origem.
• Modelo. Via API, com acordo de subcontratação (art. 28.º do RGPD) e processamento na UE, ou um modelo open-weight alojado por vós. Um exemplo verificável: no Azure, a Microsoft documenta que prompts, respostas e embeddings não são usados para treinar modelos e que, num deployment "DataZone" criado num recurso localizado num Estado-Membro, o processamento fica dentro da UE (Microsoft Learn). Leiam os termos do fornecedor que escolherem com o mesmo cuidado.
• Registos. As perguntas dos utilizadores trazem dados pessoais com frequência ("o cliente Silva pediu…"). Definam retenção, quem acede e se os registos saem da UE.
• Apagamento. Quando um documento é apagado, ou um titular exerce o direito ao apagamento (art. 17.º), os excertos e vetores correspondentes têm de sair do índice. Isto desenha-se no início — cada excerto sabe de que documento veio —; acrescentar depois é caro.
• Avaliação de impacto. Se o corpus inclui dados de saúde, dados de trabalhadores ou dados pessoais em grande escala, é provável que precisem de uma avaliação de impacto sobre a proteção de dados (art. 35.º). Envolvam o encarregado de proteção de dados desde o início.

Isto é informação geral, não aconselhamento jurídico. A forma como as permissões e as fronteiras de dados se mantêm desde a fonte até à resposta é o centro do nosso trabalho de integração de IA com os vossos sistemas.

Quanto custa um sistema RAG?

O custo de um sistema RAG está quase todo na engenharia e na preparação dos dados; o custo de API para indexar os documentos é residual. Um exemplo com números verificáveis — substituam pelos vossos:

Ou seja: a fatura da API raramente decide o projeto. O que decide é isto:

Um sistema RAG sobre uma fonte limpa para um grupo de utilizadores é um projeto muito diferente de um que liga cinco sistemas com permissões ao nível do registo. Uma ligação só de leitura a um sistema limpo mede-se em semanas; o resto só se estima com honestidade depois de ver os documentos. É este o trabalho dos nossos serviços de desenvolvimento de IA: âmbito e critério de sucesso por escrito antes de qualquer código, e o código fica vosso.

Como começar: do piloto a produção

Comecem por uma pergunta de negócio, uma fonte e um grupo de utilizadores — e escrevam o conjunto de teste antes de escrever código. É o caminho mais curto para saber se o RAG resolve o vosso problema.

1. Uma pergunta de negócio, um grupo de utilizadores. "A equipa de apoio responde a dúvidas de produto com a ficha técnica certa" é um bom âmbito; "um ChatGPT da empresa" não é.
2. Uma fonte, limpa e com dono. Escolham a fonte com mais perguntas e menos lixo, e nomeiem quem a mantém atualizada.
3. O conjunto de teste antes do código. As perguntas reais, com respostas esperadas, definem o que é "funcionar".
4. Piloto com citações e "não sei". Utilizadores reais, respostas sempre com fonte, recolha de feedback. Para testar a ideia num fim de semana, um protótipo chega — o nosso guia de agentes de IA com n8n constrói, passo a passo, um agente RAG sobre uma base de FAQ.
5. Produção. Permissões propagadas, monitorização, re-indexação automática quando os documentos mudam, avaliação a cada alteração e uma pessoa responsável pela qualidade das respostas. Quando o conhecimento vive em vários sistemas, o que se constrói é um assistente de gestão do conhecimento empresarial, não um chatbot.

Se ainda estão a escolher o primeiro projeto, o assistente sobre a base de conhecimento é uma das 40 ideias de projetos de IA para empresas.

Perguntas frequentes

RAG é o mesmo que um chatbot?

Não. O chatbot é a interface; o RAG é a forma de o pôr a responder com os vossos documentos. Um chatbot sem RAG responde com o conhecimento geral do modelo ou com respostas pré-escritas. O mesmo RAG pode servir um chatbot no site, uma pesquisa interna, um assistente no Teams ou um agente que prepara respostas a tickets para uma pessoa aprovar.

O RAG elimina as alucinações?

Não, reduz. Ao dar ao modelo os excertos certos e exigir citações, as respostas inventadas ficam menos frequentes e mais fáceis de detetar — mas um estudo de Stanford encontrou ferramentas jurídicas comerciais baseadas em RAG a alucinar entre 17% e 33% das vezes. Por isso um RAG em produção precisa de citações verificáveis, de um "não sei" explícito e de avaliação contínua.

Preciso de uma base de dados vetorial nova para fazer RAG?

Não necessariamente. Se já usam PostgreSQL, a extensão pgvector acrescenta pesquisa vetorial à base que já têm. Para documentação pequena e estável, pode nem ser preciso recuperação: um prompt longo com o documento inteiro resolve. Uma base vetorial dedicada justifica-se com grandes volumes, muitos filtros ou requisitos de desempenho que o PostgreSQL não cubra.

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

O RAG muda o que o modelo sabe no momento da pergunta, indo buscar excertos aos vossos documentos; o fine-tuning muda como o modelo se comporta, re-treinando-o com exemplos. Para conhecimento que muda — preços, procedimentos, legislação — o RAG é mais barato de manter e cita a fonte. O fine-tuning serve para formato, tom e tarefas de classificação repetitivas.

O que é agentic RAG?

É RAG em que um agente de IA decide quando e onde pesquisar: reformula a pergunta, consulta várias fontes, volta a pesquisar se a primeira tentativa não chegar e pode cruzar documentos com dados de sistemas como o ERP ou o CRM. Responde melhor a perguntas complexas, à custa de mais latência, mais custo por pergunta e mais pontos de falha. Há exemplos concretos nos nossos agentes de IA para empresas.