O que é RAG (Retrieval-Augmented Generation)?

RAG é uma arquitetura que acopla um LLM (Mistral, GPT-4o, Claude, BERTimbau) a uma base de conhecimento interna. Quando o utilizador faz uma pergunta, o sistema procura na base os documentos pertinentes, fornece-os ao LLM como contexto e gera uma resposta fundamentada nesses documentos com citação das fontes. Benefício: respostas ancoradas na sua documentação interna, não na memória genérica do modelo. É a arquitetura IA mais implantada em empresas portuguesas em 2026 para pesquisa documental, suporte técnico de primeiro nível, onboarding e pesquisa de conformidade.

RAG na empresa: arquitetura e boas práticas 2026

Q: Quando escolher RAG em vez de fine-tuning?

RAG é geralmente preferível ao fine-tuning em 2026 para: conhecimento que evolui regularmente (políticas, procedimentos, catálogo de produtos), múltiplas fontes a citar, necessidade de transparência sobre a origem da informação, equipas sem expertise data science. Fine-tuning preferível para: estilo ou tom específico a aprender de forma duradoura, terminologia ultra-especializada, latência muito crítica. A maioria dos casos de uso empresariais beneficia de começar por RAG; o fine-tuning entra como complemento ou segunda escolha se o RAG sozinho não bastar.

Q: Que vector database escolher para RAG?

Para PME e PoC: Qdrant (open-source, self-hostable, simples — a opção soberana de referência em 2026), Chroma (muito simples, bom para começar), pgvector (extensão PostgreSQL, ideal se já usa Postgres). Para produção em larga escala: Qdrant em cluster, Weaviate, Milvus. Para soberania máxima: self-hosted em Claranet Portugal, NOS Data Center Covilhã, Altice Portugal, Domínios.pt ou OVHcloud Lisboa. A evitar para dados sensíveis: vector databases SaaS norte-americanas (Pinecone, certas ofertas geridas) que reintroduzem o risco de transferência internacional que o RAG deveria contornar.

Q: Quanto custa um RAG em produção?

Para uma PME portuguesa com 1.000 documentos e 100 utilizadores: 50 a 200 € por mês de funcionamento (LLM via API + vector database self-hosted + armazenamento). Investimento inicial de integração: 5 a 25 k€ consoante a complexidade (número de fontes, integrações com SI, qualidade da UI alvo). Para uma grande organização com mais de 100.000 documentos: 500 a 3.000 € por mês de funcionamento. ROI típico em 6 a 12 meses se a adoção se mantiver, principalmente por poupança de tempo de pesquisa documental e redução do volume de tickets de suporte de primeiro nível.

Q: O RAG é conforme com o RGPD?

O RAG é um tratamento automatizado que deve ser inscrito no registo de atividades de tratamento (artigo 30.º do RGPD). Se a base contiver dados pessoais, AIPD recomendada e obrigatória em certos casos (volumes elevados, categorias especiais, vigilância). Escolha de hosting: LLM + vector database em infraestrutura soberana portuguesa ou europeia (ex.: BERTimbau + Qdrant em Claranet Portugal ou OVHcloud Lisboa) para evitar o risco DPF. Controlo de acesso indispensável: um utilizador só deve ver os chunks aos quais tem acesso legítimo na documentação de origem. As orientações da CNPD (Comissão Nacional de Proteção de Dados) sobre IA estabelecem o padrão.

Q: Qual é a diferença entre RAG e um agente IA?

Um RAG responde a uma pergunta apoiando-se em documentos internos — é um componente. Um agente IA decide uma sequência de ações (pesquisa RAG, chamada API, redação, validação humana) para cumprir uma missão de alto nível — é um sistema. RAG é um componente que aparece frequentemente nos agentes. Começar por um RAG é mais simples, previsível e menos arriscado do que um agente autónomo.

Q: O RAG alucina sempre?

Sim, mas muito menos do que um LLM sozinho. RAG obriga o LLM a fundamentar-se em documentos fornecidos, reduzindo drasticamente as alucinações fatuais — tipicamente de 90 % para menos de 5 % em perguntas cuja resposta está no corpus. As alucinações residuais ocorrem quando: os documentos fornecidos não contêm a resposta (o LLM inventa em vez de dizer 'não sei'), o LLM extrapola apesar do contexto, ou os documentos são contraditórios. Um bom RAG inclui sempre a citação das fontes.

Q: Quanto tempo para colocar um RAG em produção?

PoC funcional: 1 a 2 semanas com uma equipa de desenvolvimento à vontade com APIs LLM. Piloto em produção restrita (10-50 utilizadores): 4 a 8 semanas adicionais (integração de fontes, controlo de acesso, monitorização, formação). Industrialização completa: 3 a 6 meses consoante a complexidade. O gargalo raramente é a tecnologia (LangChain, LlamaIndex e Haystack são maduros) — é a ingestão de fontes e a governação de acessos.

Quick Answer: o que é o RAG na empresa?

RAG (Retrieval-Augmented Generation, literalmente «geração aumentada por recuperação») é a arquitetura IA mais implantada em empresas portuguesas em 2026 para fazer um grande modelo linguístico responder a partir da sua própria documentação. O princípio é simples, comparável a um consultor que abre os processos antes de responder:

O utilizador faz uma pergunta em linguagem natural.
O sistema procura os documentos pertinentes numa base de conhecimento preparada (o «vector database»: cada documento é armazenado como uma assinatura numérica para encontrar rapidamente os que se assemelham à pergunta).
Os documentos pertinentes são inseridos no prompt enviado ao LLM.
O LLM gera uma resposta ancorada nesses documentos, com citação de fontes.

Stack de referência 2026 para o mercado português:

LLM: Mistral Large ou Mistral Small 3 (soberano UE), Llama 3.1/3.3 70B self-hosted (em Claranet Portugal ou NOS Data Center na Covilhã), Sabiá-2 e Sabiá-3 (LLMs adaptados ao português pela Maritaca AI — relevantes para conteúdos técnicos em português europeu e brasileiro), GPT-4o ou Claude (se aceitar dependência DPF).
Embeddings: E5-Multilingual (excelente em português europeu), BERTimbau-Sentence (modelo BERT em português desenvolvido na NeuralMind/USP, amplamente adotado), BERTugues (variante focada no português europeu pela Universidade de Aveiro), BGE-M3, Mistral Embed. Para corpus puramente em português europeu: modelos especializados como neuralmind/bert-base-portuguese-cased e variantes Sentence-BERT.
Vector database: Qdrant (self-hostable, referência 2026), Weaviate, Milvus, pgvector se PostgreSQL já está no stack, Chroma para protótipos iniciais.
Orquestração: LangChain, LlamaIndex, Haystack.

Casos de uso prevalecentes em Portugal: serviços e BPO (setor pujante em Lisboa e Porto, com SSCs de grupos internacionais), turismo e hotelaria (Pestana, Vila Galé, Pousadas — bases de conhecimento operacional multipropriedade), banca e seguros sob supervisão Banco de Portugal/ASF (CGD, BCP, Santander Totta, Novo Banco, Fidelidade), administração pública (AMA — Agência para a Modernização Administrativa, Plano de Recuperação e Resiliência), retalho (Sonae, Jerónimo Martins).

Porquê RAG e não fine-tuning: RAG é mais simples, mantível, transparente. Fine-tuning só se justifica em casos muito específicos.

Custo: 50 a 200 € por mês de funcionamento para uma PME, 5 a 25 k€ de investimento inicial.

Por que o RAG se impôs em 2026

Antes de 2024, integrar o conhecimento interno de uma empresa num LLM significava fine-tuning — longo, dispendioso, frágil. O RAG inverteu a equação por três razões.

Mudança 1 — Maturidade dos LLM long-context. Mistral, GPT-4o, Claude, Llama 3.3 e Sabiá-3 gerem em 2026 contextos de 100.000 a 1 milhão de tokens. É possível fornecer dezenas de páginas de documentos como input — exatamente o que o RAG precisa. Antes de 2024, o limite de 8-32k tokens forçava compromissos pesados sobre a quantidade de contexto; essa fricção desapareceu.

Mudança 2 — Maturidade dos vector databases open-source. Qdrant, Weaviate, Milvus, Chroma e pgvector permitem em 2026 implementar um vector database em produção em poucas horas, gratuitamente ou a custo muito baixo. Antes de 2023, era necessário Pinecone (SaaS EUA) ou construir o stack próprio. Hoje: Qdrant self-hosted em Claranet Portugal, NOS Covilhã ou OVHcloud Lisboa, em poucos comandos.

Mudança 3 — Simplicidade de integração. LangChain e LlamaIndex estabilizaram os padrões de integração. Uma PME portuguesa pode prototipar um RAG em 1-2 semanas com uma equipa técnica modesta. Os frameworks gerem ingestão, chunking, embedding, retrieval, geração com citação.

Concretamente: em 2026, qualquer organização portuguesa com uma base documental interna (>500 documentos) ganha em explorar o RAG. Tornou-se acessível, previsível, e o ROI mede-se em meses.

Arquitetura detalhada de um RAG em produção

Uma pipeline RAG madura em 2026 conta com seis componentes. Esquema e depois detalhe.

Esquema da pipeline

[Fontes documentais]
   SharePoint, GED, wiki, Drive, CRM, ERP
            │
            ▼
[1. Ingestão] ─── parsing PDF/DOCX/HTML, OCR se digitalizado
            │
            ▼
[2. Chunking] ─── divisão em passagens de 200-1000 tokens
            │
            ▼
[3. Embeddings] ─── assinatura numérica por chunk
            │
            ▼
[4. Vector DB] ── armazenamento Qdrant / Weaviate / pgvector
            │
            ├──── (em runtime, query do utilizador)
            ▼                              │
[5. Retrieval] ◄─────────────────── embedding query
       │       top-K chunks                │
       ▼                                   │
[6. Geração] ─── LLM com contexto ◄────────┘
       │
       ▼
[Resposta + citação de fontes]

1. Ingestão documental

Fontes: SharePoint, GED (PRIMAVERA é o ERP dominante em Portugal e tem documentação massiva indexável), wikis Confluence, pastas OneDrive, exportações CRM (Salesforce, HubSpot dominantes), exportações SAP, contratos, FAQ, intranet. Parsing: PDF (com OCR se digitalizado — Azure Document Intelligence ou Tesseract), DOCX, HTML, Markdown, transcrições áudio (via Whisper).

Boa prática: preservar metadados (autor, data, fonte, classificação de sensibilidade, período de retenção) ao longo da pipeline para poder filtrar a jusante.

2. Chunking

Os documentos são divididos em passagens de 200-1000 tokens consoante o LLM alvo e a natureza do conteúdo. Estratégias:

Chunking fixo: 500 tokens por chunk, simples
Chunking semântico: por parágrafo ou secção lógica, mais relevante
Chunking hierárquico: chunk grande (vista geral) mais chunks pequenos (detalhe), bom para documentos estruturados (instruções de trabalho, normativos do Banco de Portugal)

Um bom chunking distingue um RAG medíocre de um performante.

3. Embeddings

Cada chunk é convertido num vetor denso (768-3.072 dimensões). Modelos 2026 para conteúdo em português:

Modelo	Origem	Qualidade em português	Soberania
E5-Multilingual	Open Source	Excelente	OK se self-hosted
BERTimbau-Sentence	NeuralMind/USP	Excelente	OK se self-hosted
BERTugues	Universidade de Aveiro	Excelente em PT-PT	OK se self-hosted
BGE-M3	China open-source	Muito boa	OK se self-hosted
Mistral Embed	França	Boa	UE-soberano
OpenAI text-embedding-3	EUA	Muito boa	Dependência DPF

Para contextos sensíveis (banca supervisionada pelo Banco de Portugal, saúde sob CNPD), preferir BERTimbau, BERTugues ou modelos open-source self-hosted.

4. Armazenamento vetorial

Armazenamento de embeddings + metadados + chunk original. Seleção 2026:

Vector DB	Tipo	Caso de uso ideal	Soberania
Qdrant	Open-source self-hostable	Referência 2026, PME a grande grupo	Sim
Chroma	Open-source	PoC, protótipo rápido	Sim
pgvector	Extensão PostgreSQL	Stack Postgres já implementado	Sim
Weaviate	Open-source	Escala maior	Sim se self-hosted
Milvus	Open-source	Escala muito grande	Sim se self-hosted
Pinecone	SaaS EUA	A evitar para dados sensíveis	Não

Para casos regulamentados (banca-Banco de Portugal, saúde-DGS, AT — Autoridade Tributária), Qdrant self-hosted em Claranet Portugal, NOS Data Center Covilhã, Altice/MEO Cloud Portugal, Domínios.pt ou OVHcloud Lisboa é a escolha soberana de referência em 2026. A NOS Covilhã é particularmente apreciada por se localizar em território nacional e cumprir os requisitos do RGPD com hospedagem certificada.

5. Retrieval

Em runtime, a query do utilizador é:

Convertida em embedding (mesmo modelo da ingestão)
Comparada com embeddings armazenados (similaridade cosseno)
Top-K chunks recuperados (tipicamente K=5-10)

Melhorias comuns:

Hybrid search: combina pesquisa vetorial com pesquisa por palavras-chave (BM25). Melhora a precisão em termos técnicos e referências legais (ex.: artigos do Código do Trabalho ou normativas do Banco de Portugal).
Reranking: um modelo dedicado (cross-encoder) reordena os resultados top-K. Cohere Rerank 3 e BGE-Reranker são as escolhas por defeito em 2026.
Filtros metadata: restringir a pesquisa a um subconjunto (por data, fonte, classificação, perfil de utilizador, distrito).

6. Geração com citação

O LLM recebe:

A query do utilizador
Os chunks pertinentes como contexto
Um system prompt que exige citações explícitas

Output típico: «De acordo com o procedimento RH-2024-03 (parágrafo 4.2), são concedidos 5 dias de licença por falecimento de familiar próximo… [Fonte: Procedimento RH-2024-03, atualização 2024-09].»

Sem citação, não tem um RAG: tem um LLM que alucina sobre documentos internos. A citação não é negociável para a confiança do utilizador e a conformidade (artigo 5.º, n.º 1, alínea d) do RGPD — exatidão).

RAG vs fine-tuning — a decisão 2026

Critério	RAG	Fine-tuning
Prazo de implementação	1-4 semanas	4-12 semanas
Custo inicial	5-25 k€	30-100 k€
Manutenção (mudança de conhecimento)	Reindexar (horas)	Re-fine-tuning (dias)
Transparência	Citações possíveis	Caixa preta
Precisão fatual	Alta (ancorada em fontes)	Média (alucinações possíveis)
Estilo/tom específico	Limitado	Excelente
Custo de inferência	Médio (contexto longo = mais tokens)	Baixo
Competências necessárias	Devs com APIs LLM	Data science + GPU

Regra de decisão 2026:

Conhecimento que evolui, fontes múltiplas, citação requerida → RAG
Estilo específico, terminologia ultra-especializada, latência crítica → Fine-tuning
Maioria dos casos de negócio → RAG em primeiro lugar

Começar por RAG; mudar ou complementar com fine-tuning apenas se a avaliação rigorosa o justificar.

6 casos de uso empresariais do RAG no mercado português

1. Serviços partilhados e BPO — knowledge bases multilingue. Portugal é hub europeu de serviços partilhados e BPO (Lisboa e Porto concentram SSCs de grupos como Volkswagen, BNP Paribas, Mercedes-Benz, Natixis, Webhelp). RAG sobre playbooks de processos, documentação de cliente, runbooks operacionais reduz drasticamente o tempo de onboarding e o erro humano.

Volumetria típica: 10.000-200.000 documentos, milhares de queries por dia.

2. Turismo e hotelaria — bases multipropriedade. Pestana, Vila Galé, Tivoli, Pousadas de Portugal, Sana, Vila Vita Parc gerem bases de conhecimento operacional multipropriedade. Um RAG permite a rececionistas e serviços técnicos consultarem manuais, regulamentos locais e procedimentos em linguagem natural.

3. Banca e seguros sob supervisão Banco de Portugal/ASF. Indexação de circulares do Banco de Portugal, normativos da ASF (Autoridade de Supervisão de Seguros e Fundos de Pensões), Solvency II, MiFID II, KYC/AML internos. CGD, Millennium BCP, Santander Totta, Novobanco, Fidelidade lançaram programas RAG.

Volumetria típica: 5.000-100.000 documentos.

4. Suporte técnico de primeiro nível. Indexação da documentação de produto, tickets resolvidos, runbooks. Resultado: respostas coerentes, taxa de resolução self-service em alta, redução de 30-50 % do volume de tickets nível 1 em perímetros bem definidos.

Volumetria típica: 1.000-50.000 documentos, 100-10.000 perguntas por dia.

5. Administração pública — AMA e Plano de Recuperação e Resiliência. A AMA (Agência para a Modernização Administrativa), com o programa SIMPLEX e os investimentos do PRR, experimenta RAG em normativos, procedimentos administrativos e FAQ a cidadãos. Foco em hosting nacional (NOS Covilhã, Claranet, MEO Cloud) e modelos adaptados ao português europeu.

6. Retalho — Sonae, Jerónimo Martins. Os dois grandes grupos retalhistas portugueses gerem catálogos massivos, fichas técnicas de fornecedor e procedimentos operacionais de loja. RAG sobre essa documentação reduz tempo de pesquisa em loja e harmoniza respostas a perguntas frequentes da equipa.

Conformidade RGPD e CNPD do RAG

O RAG é um tratamento automatizado que deve ser enquadrado.

Obrigações chave:

Inscrição no registo (artigo 30.º do RGPD): «assistência IA à pesquisa documental interna». Finalidade, dados tratados, subcontratantes, prazos.
AIPD (Avaliação de Impacto sobre a Proteção de Dados) se a base contiver dados pessoais: a CNPD (Comissão Nacional de Proteção de Dados) publicou orientações sobre IA e proteção de dados (2024). AIPD obrigatória para volumes elevados, categorias especiais, vigilância.
Pseudonimização na ingestão, sempre que possível.
Hosting soberano português ou europeu para dados sensíveis: Claranet Portugal, NOS Covilhã, Altice/MEO Cloud, Domínios.pt, OVHcloud Lisboa. Para AP, preferir prestadores com certificação nacional e ANSC (Centro Nacional de Cibersegurança).
Contrato de subcontratação (artigo 28.º do RGPD): cada componente do stack — fornecedor LLM, vector database gerido se aplicável, fornecedor de embeddings — deve estar sob contrato de subcontratação, com cláusulas adequadas e mecanismos de transferência internacional (cláusulas contratuais-tipo + TIA — Transfer Impact Assessment) quando aplicável.
AI Act: o uso em RH, scoring de crédito ou avaliação educativa pode classificar o RAG como sistema de alto risco. Coordenação CNPD + autoridades setoriais (Banco de Portugal, ASF, ANSC).
Controlo de acesso: um utilizador só deve ver os chunks aos quais tem acesso legítimo na documentação de origem. Filtros metadata por perfil de utilizador alinhados com as permissões dos sistemas fonte.

O que recusamos prometer

Três antipadrões recorrentes que evitamos na DPLIANCE quando concebemos um RAG à medida.

«Indexamos tudo, o acesso resolve-se depois.» Falso. O controlo de acesso deve ser desenhado na ingestão, não a posteriori. Indexar 100.000 documentos com acesso uniforme cria um canal de fuga de permissões monumental — o RAG responderá com base em documentos aos quais o utilizador não tinha acesso na fonte. A aplicação retroativa dos direitos é técnica e juridicamente frágil sob RGPD.

«O RAG vai resolver tudo, já não precisamos de organizar bem as fontes.» Falso. Um RAG sobre fontes mal organizadas, contraditórias responderá com… informação mal organizada, contraditória. O RAG amplifica a qualidade das fontes — não a corrige.

«Começamos diretamente com um agente autónomo que faz RAG e ações.» Habitualmente um erro num primeiro projeto IA. RAG sozinho já tem as suas armadilhas. Adicionar um agente autónomo que executa ações externas multiplica os riscos.

A DPLIANCE é editora de software. Quando concebemos uma solução IA à medida que inclui um RAG, ocupamo-nos do stack completo: escolha do modelo (Mistral, Sabiá, on-premise consoante o nível de sensibilidade), escolha do vector database (Qdrant soberano por defeito), ingestão das fontes, controlo de acesso alinhado com as suas permissões existentes, citações sistemáticas, monitorização de qualidade.

FAQ

O que é o RAG (Retrieval-Augmented Generation)?

RAG é uma arquitetura que acopla um LLM a uma base de conhecimento interna, com citação de fontes. É a arquitetura IA mais implantada em empresas portuguesas em 2026.

Quando escolher RAG em vez de fine-tuning?

RAG para conhecimento que evolui, múltiplas fontes a citar, transparência, equipas sem data science. Fine-tuning para estilo duradouro, terminologia ultra-especializada, latência crítica.

Que vector database escolher para RAG?

PME e PoC: Qdrant, Chroma, pgvector. Produção: Qdrant cluster, Weaviate, Milvus. Soberania máxima: Claranet Portugal, NOS Covilhã, MEO Cloud, OVHcloud Lisboa.

Quanto custa um RAG em produção?

PME com 1.000 documentos e 100 utilizadores: 50-200 € por mês. Investimento inicial: 5-25 k€. Grande organização com 100.000+ documentos: 500-3.000 € por mês.

O RAG é conforme com o RGPD?

Sim, com inscrição no registo art. 30.º, AIPD se dados pessoais, hosting soberano português/europeu, contrato de subcontratação e controlo de acesso por perfil. Orientações da CNPD 2024 de referência.

Qual é a diferença entre RAG e um agente IA?

Um RAG responde apoiando-se em documentos — componente. Um agente decide ações para uma missão — sistema. RAG é frequentemente componente do agente.

O RAG alucina sempre?

Sim, mas muito menos do que um LLM sozinho: tipicamente de 90 % para menos de 5 %. Citação de fontes obrigatória.

Quanto tempo para colocar um RAG em produção?

PoC: 1-2 semanas. Piloto: 4-8 semanas adicionais. Industrialização completa: 3-6 meses.

Fontes: documentação oficial Mistral AI, Qdrant, Weaviate, Milvus, pgvector, Chroma; literatura científica RAG (Lewis et al. 2020 e trabalhos posteriores); documentação LangChain, LlamaIndex e Haystack; Regulamento (UE) 2016/679 (RGPD); Lei n.º 58/2019 (Lei de Execução do RGPD em Portugal); orientações da CNPD sobre IA e proteção de dados; Regulamento (UE) 2024/1689 (AI Act); publicações da AMA e do Centro Nacional de Cibersegurança; NeuralMind/USP — BERTimbau; Maritaca AI — Sabiá-2 e Sabiá-3.

Para enquadrar um projeto RAG na sua organização — escolha de arquitetura, vector database, integração SI, controlo de acesso, conformidade — consulte o nosso guia IA conforme RGPD, o nosso guia carta IA empresa, os nossos casos de uso de IA, ou contacte-nos via as nossas soluções IA à medida.