RAG para PME em 2026: Vector Databases e Embeddings

✎ Duarte Spínola  |  2026-07-18

As pequenas e médias empresas (PME) portuguesas que adoptam modelos de linguagem (LLM) como GPT-4o, Claude ou Llama 3 deparam-se rapidamente com um problema: o modelo “não sabe” nada sobre os contratos, manuais internos, tickets de suporte ou políticas de RH da organização. Alimentar tudo no prompt é caro (limite de contexto), arriscado (dados confidenciais) e frágil (alucinação). A solução madura em 2026 chama-se Retrieval-Augmented Generation (RAG) — uma arquitectura que combina um LLM com um índice de pesquisa semântica alimentado por embeddings e armazenado numa vector database. A causa técnica do problema é simples: um LLM é um modelo estático treinado numa image (Snapshot) da web até uma data de corte; não tem acesso à memória da empresa. A solução é indexar os documentos internos como vectores densos, recuperar os mais relevantes por semântica (não por palavra-chave) e inseri-los no prompt antes da geração. Este artigo cobre o que é RAG, as alternativas open-source e comerciais de embeddings e vector databases, a arquitectura típica e uma implementação prática em Python com LangChain ou LlamaIndex, validada contra documentação oficial a 18 de Julho de 2026.

1. O que Está a Acontecer — RAG, Embeddings e Vector Databases

RAG (Retrieval-Augmented Generation) é um padrão introduzido pela Facebook AI em 2020 e tornado padrão de facto em 2024-2026 que combina um modelo de geração de texto (LLM) com um sistema de recuperação de informação externo. Em vez de depender apenas do conhecimento paramétrico aprendido em treino, o LLM recebe, no prompt, excertos relevantes recuperados de uma base de conhecimento externa. Em 2026, a documentação da Pinecone descreve-o como “the process of optimizing the output of a large language model so it references an authoritative knowledge base outside of its training data sources before generating a response” (Pinecone Learn — RAG).

Embeddings são representações numéricas densas de texto (ou imagens, áudio, código) num espaço vectorial de alta dimensão — tipicamente 384, 768, 1024, 1536 ou 3072 dimensões, consoante o modelo. Textos semanticamente próximos ficam próximos nesse espaço. A recuperação semântica faz-se calculando a distância (cosseno, euclidiana ou produto interno) entre o embedding da pergunta e os embeddings dos documentos. O modelo text-embedding-3-large da OpenAI produz 3072 dimensões por token-chunk (OpenAI Platform — Embeddings Guide).

Vector databases são sistemas de armazenamento optimizados para: (1) guardar milhões de vectores de alta dimensão, (2) fazer busca aproximada de vizinhos mais próximos (ANN — Approximate Nearest Neighbors) em milissegundos, (3) filtrar por metadados (data, autor, departamento, categoria) e (4) oferecer persistência, multi-tenancy e update incremental. O pipeline típico é documentado nas referências da Qdrant (Qdrant Documentation) e da Chroma (Chroma Documentation).

A “chave” que torna o RAG útil: o retrieval semântico resolve o problema de sinonímia que a pesquisa BM25/TF-IDF clássica não resolve. “Como fecho a sessão?” e “Logout” são a mesma intenção mas não partilham tokens. Um embedding bem treinado coloca-os próximos.

2. Cenários em que o RAG é a Resposta Certa

• Chatbot de suporte técnico interno — empresa de 50 funcionários com 200 manuais e FAQs internas; o chatbot responde “como configuro VPN no Mac” citando o manual interno, não a resposta genérica da web.
• Pesquisa semântica em conhecimento não-estruturado — gabinete de contabilidade com 5 000 PDFs de legislação e pareceres; RAG permite perguntar “quais os prazos para entrega do IVA no setor da construção” e obter respostas com citações.
• Document Q&A sobre contratos e propostas — equipa comercial com 300 propostas comerciais; query “qual o desconto médio que demos ao cliente X em 2025” devolve excertos relevantes, não a busca literal.
• Helpdesk IT com base de tickets — PME com 10 000 tickets Resolvidos; RAG sugere soluções anteriores para tickets novos, reduzindo tempo de resolução (MTTR).
• Assistente de recursos humanos — empregados perguntam ao bot “quantos dias de licença me restam” e “qual a política de teletrabalho”, com resposta fundamentada no manual de RH.
• Pesquisa em notas de reuniões e actas — equipa de direcção com 500 actas em Markdown; query semântica “decisões sobre o orçamento de marketing” recupera todas as actas relevantes mesmo sem a palavra exacta.

3. Passo 1 — Diagnosticar se RAG é Mesmo Necessário

Antes de implementar RAG, confirme que o problema é mesmo “o LLM não sabe X” e não “o LLM é mau a raciocinar”. Para PME, três testes rápidos:

Teste A — Prompt directo: coloque no GPT-4o / Claude a pergunta de negócio com a máxima informação de contexto possível no prompt. Se a resposta for correcta, RAG não é necessário — basta um prompt melhor.

Teste B — Keyword search existente: execute a query na pesquisa actual da empresa (SharePoint Search, Elasticsearch, grep num directório). Se 90% das queries resultam em 1 clique no documento certo, RAG adiciona pouco; se 40%+ falham, RAG resolve o problema.

Teste C — Volume de documentos: se o corpus for <20 documentos curtos, copie-os todos para o prompt (janela de contexto de 128k tokens do GPT-4o comporta ~100 páginas A4). Se for >50 documentos, >50 000 palavras ou se cresce semanalmente, RAG justifica-se.

Esperado: para 200 documentos médios (5 KB cada), verá algo como Tokens totais: ~250 000 e Cabe num prompt de 128k? False — o que confirma que RAG é a abordagem correcta. O tiktoken é a biblioteca oficial da OpenAI para contagem de tokens e está validada contra o comportamento dos modelos GPT (OpenAI Cookbook no GitHub).

4. Passo 2 — Escolher o Modelo de Embeddings

Os embeddings são a espinha dorsal do RAG. Escolher mal o modelo degrada a qualidade de retrieval sem que o utilizador perceba — o chatbot “responde” mas com fontes irrelevantes. Em 2026, as três famílias viáveis para PME:

4.1 Modelo comercial — OpenAI text-embedding-3

A OpenAI lançou em 2024 os modelos text-embedding-3-small (1536 dimensões) e text-embedding-3-large (3072 dimensões), que em 2026 continuam a ser a referência comercial por relação custo/qualidade. Documentação: OpenAI Platform — Embeddings Guide.

Custo em 2026: $0.02 por 1M tokens (small) e $0.13 por 1M tokens (large), confirmado na documentação de modelos da OpenAI. Para 10 000 documentos de 1000 tokens cada, o índice inicial custa ~$0.20 (small) ou ~$1.30 (large).

4.2 Modelo open-source — sentence-transformers / BGE / E5

Para PME que querem inferência local, dados confidenciais ou sem dependência de API externa, a família sentence-transformers é o padrão open-source. O modelo BAAI/bge-m3 (multilingue, 1024 dimensões) e intfloat/multilingual-e5-large são os mais recomendados em 2026 no MTEB Leaderboard da Hugging Face (Hugging Face — MTEB, Sentence-Transformers).

4.3 Modelo local via Ollama — nomic-embed-text, mxbai, bge

O Ollama permite correr modelos de embedding localmente sem GPU dedicada, ideal para PME com restrições de privacidade. O modelo nomic-embed-text (768 dims, 1.3 GB) é o ponto de entrada típico. Configuração e integração com RAG local é detalhada em artigos kbase.pt sobre o stack Ollama + Open WebUI (artigo relacionado: Ollama + Open WebUI stack avançado 2026).

4.4 Quadro comparativo de modelos em 2026

A escolha prática em 2026: se pode cloud, OpenAI text-embedding-3-small para começar; se tem dados sensíveis, BAAI/bge-m3 via sentence-transformers ou Ollama. Evite text-embedding-ada-002 (legacy, 1536 dims, superseded pelo 3-small em qualidade e custo).

5. Passo 3 — Escolher a Vector Database

Em 2026 existem cinco vector databases mainstream para PME. A escolha determina custos operacionais, complexidade de DevOps e capacidade de escala.

5.1 Pinecone — managed serverless (commercial)

Pinecone é a oferta managed serverless mais madura, sem infraestrutura para gerir. Ideal para PME que preferem pagar para não operar. A documentação oficial descreve a arquitectura serverless com storage em camadas e cálculo on-demand (Pinecone Learn, Pinecone Pricing).

5.2 Qdrant — open-source, production-grade

Qdrant é escrito em Rust, open-source (Apache 2.0) e oferece uma versão managed cloud e self-hosted. A documentação oficial cobre payloads, filtros e quantização (Qdrant Documentation, Qdrant Pricing). É a escolha preferida em 2026 para PME que querem self-host com performance alta e baixo consumo de memória.

5.3 Chroma — lightweight, dev-friendly

Chroma é a opção mais simples para começar — corre em processo (embedded), sem servidor separado, ideal para protótipos e PME com <100k documentos. Documentação: Chroma Documentation. Em 2026 o Chroma evoluiu para uma arquitectura client-server, mas mantém o modo embedded.

5.4 Weaviate — schema-first, GraphQL

Weaviate é open-source (BSD-3) e distingue-se por ser “schema-first” e oferecer uma API GraphQL nativa. A documentação oficial descreve módulos para multimodal e hybrid search (Weaviate Developer Docs, Weaviate Pricing). Recomendado quando se quer combines keyword + vector search (hybrid) out-of-the-box.

5.5 pgvector — extensão PostgreSQL

Para PME que já usam PostgreSQL, pgvector é a via mais económica: adicionar a extensão a uma base de dados existente em vez de instalar uma vector database nova. O repositório oficial está em pgvector no GitHub. Em 2026, suporta índices HNSW e IVFFlat em 1536+ dimensões, com bom desempenho até ~1M vectores por instância.

5.6 Quadro comparativo — Vector Databases para PME em 2026

Recomendação 2026 para PME portuguesas: começar com Chroma para protótipo (zero DevOps), migrar para Qdrant ou pgvector em produção. Escolher Pinecone apenas se a equipa não tem competências de infraestrutura. A documentação oficial da Qdrant documenta bem a transição Chroma→Qdrant (Qdrant Quick Start).

6. Passo 4 — Arquitectura Típica de um Pipeline RAG

A arquitectura canónica documentada em 2026 pela Pinecone, LangChain e LlamaIndex segue seis fases. Esta secção descreve-as conceptualmente; a implementação em código está na secção 7.

6.1 Ingestão de documentos

Carregar PDFs, Word, Markdown, HTML, e-mails, tickets, páginas web. Em 2026, LangChain oferece loaders para >80 fontes (LangChain Data Connection) e LlamaIndex inclui centenas de conectores (LlamaIndex Docs). Para PDFs com layout complexo, considere unstructured, marker-pdf ou pymupdf — a extração correcta é responsável por 40-60% da qualidade final do RAG.

6.2 Chunking — segmentação em passagens

Não se pode embedding de um PDF de 50 páginas inteiro: perde-se granularidade. Dividir em chunks de 500-1500 tokens com overlap de 50-200 tokens é o padrão. Estratégias:

• RecursiveCharacterTextSplitter (LangChain) — divide por parágrafo, depois frase, depois palavra. É o padrão de facto.
• Semantic chunker — divide quando a semântica muda (via embeddings). Mais caro mas superior em documentos densos.
• Markdown/HTML structural splitter — preserva headers como metadados. Recomendado para documentação técnica.

6.3 Embedding

Cada chunk é convertido num vector pelo modelo escolhido (secção 4). Para PT-PT, modelos multilingues (bge-m3, multilingual-e5, OpenAI 3-small) têm desempenho equivalente ao inglês em benchmarks MTEB (Hugging Face MTEB).

6.4 Storage

Os vectores + metadados + texto são inseridos na vector database escolhida (secção 5). Em produção, armazenar também: fonte, data_criacao, autor, categoria, pagina, hash_chunk — estes metadados habilitam filtros (ex: “só manuais de 2025”) e auditoria.

6.5 Retrieval — recuperação por similaridade

Quando o utilizador faz uma pergunta: (1) gera o embedding da pergunta, (2) procura na vector database os K vectores mais próximos (K=3 a 10), (3) retorna os chunks correspondentes com metadados. Técnicas avançadas em 2026: hybrid search (combina vector + BM25), re-ranking com um modelo cross-encoder (bge-reranker-v2-m3) para reordenar os top-K, e query expansion (LLM reformula a pergunta em 3 variantes).

6.6 Geração — prompt + LLM

Os K chunks recuperados são inseridos no prompt como contexto. O prompt típico: “Responde à pergunta usando apenas o contexto abaixo. Cita a fonte. Se não souberes, diz que não encontraste.”

O LLM gera a resposta com citações — mais fiável que geração livre e auditável.

7. Passo 5 — Implementação Prática com LangChain

A implementação mais rápida em 2026 usa LangChain, que abstrai ingestion, chunking, embedding, storage e retrieval numa API de alto nível. Documentação oficial: LangChain RAG Tutorial.

7.1 Instalação

7.2 Pipeline mínimo com Chroma + OpenAI

Esperado: resposta em PT-PT com citação (fonte: manual-vpn.md, p.12). Se a pergunta não estiver coberta, o modelo devolve “Não encontrado no conhecimento base” em vez de alucinar — o comportamento pretendido.

7.3 Variante com LlamaIndex

LlamaIndex é a alternativa a LangChain, com focus em indexing sofisticado e retrieval avançado. Documentação: LlamaIndex Docs.

7.4 Variante 100% open-source (sem cloud, para dados sensíveis)

Vantagem: todos os dados e inferência ficam na rede interna — zero envio para cloud. Trade-off: a qualidade do Llama 3.1 8B local é inferior ao GPT-4o; para tarefas exigentes, use Llama 3.1 70B via Ollama num servidor com 48 GB de RAM ou modelo via provedor de inferência open-source (artigo relacionado: Hermes AI Agent + Ollama instalação).

8. Passo 6 — Custos e Orçamento para PME

Em 2026, RAG deixou de ser caro. Os custos deprimem-se em três eixos: embeddings, vector DB e LLM.

8.1 Embeddings

A indexação é amortizada: paga-se uma vez, re-paga-se só no delta de novos documentos. Embeddings de queries (pergunta do utilizador) são 100-300 tokens cada — custo negligenciável mesmo em alto tráfego.

8.2 Vector Database

Para 95% das PME portuguesas com <100k documentos, Chroma ou pgvector self-host são zero custo.

8.3 LLM (geração)

Cenário PME típico (chatbot interno, 100 queries/dia, 500 tokens de contexto cada): ~50k tokens input + 5k output por dia = ~$0.01/dia com GPT-4o-mini ou $0 com Ollama. Para 30 dias = $0.30/mês. RAG é, em 2026, acessível a qualquer PME.

9. Outras Causas e Armadilhas Comuns em RAG

O RAG “funciona” mas pode dar respostas erradas sem que o utilizador perceba. Lista das armadilhas mais frequentes e onde se resolvem:

• Chunk size mal calibrado — chunks demasiado pequenos perdem contexto semântico; demasiado grandes diluem a relevância. Solução: começar com 1000 tokens + 200 overlap, testar com 20 queries reais e ajustar. Erro típico descrito em Pinecone Learn — chunking.
• Embedding com modelos diferentes para query e indexação — vector DB fica incompatível. Cada mudança de modelo obriga a re-indexar. Manter o modelo numa constante no código.
• Sem re-ranking — top-K por cosine pode ter falsos positivos. Em 2026, adicionar um cross-encoder bge-reranker-v2-m3 aumenta precisão em 15-30%.
• Sem metadados filtráveis — não conseguir limitar retrieval a “documentos de 2025” ou “categoria: RH”. Metadados são grátis e cruciais.
• Falta de gestão de versões do índice — quando se actualiza um manual, o chunk antigo permanece na vector DB. Solução: hash por chunk, fazer upsert (substituir) não insert.
• Alucinação apesar de RAG — prompt mal construído (“Responde à pergunta”) permite ao LLM ignorar o contexto. Prompt correcto: “Se a resposta não estiver no contexto, diz que não encontraste.”
• Dados confidenciais em APIs comerciais — OpenAI, Anthropic, Cohere têm políticas de retenção. Para PII, financeiro, jurídico, usar Llama 3.1 local via Ollama ou provedores com DPA (Data Processing Agreement).
• PDFs mal extraídos — PDFs com colunas, tabelas, scans produzidos por OCR mau degradam retrieval. Validar a extração manualmente nos primeiros 20 documentos.
• Monolingual embedding em corpus PT — modelos só em inglês (ex: original OpenAI ada) perdem nuances em PT. Usar multilingue: bge-m3, multilingual-e5, ou OpenAI 3-small (multilingue).

10. Como Evitar Problemas em Implementações Futuras

• Definir um golden set antes de começar — 30-50 perguntas reais com a resposta esperada. Serve de teste de regressão a cada alteração.
• Versionar o pipeline — guardar versão do modelo de embedding, chunk size, prompt e vector DB em metadata. Permite reproduzir resultados e rollback.
• Fazer retrieval evaluation, não só end-to-end — medir recall@5 e precision@5 dos chunks recuperados, não só a qualidade da resposta final. A causa de respostas más é frequentemente retrieval falhado, não o LLM.
• Monitorizar drift — logs de queries + chunks recuperados + satisfação do utilizador (thumbs up/down). Quando a satisfação cai, investigar retrieval primeiro.
• Planeamento de re-indexação — agenda mensal ou trigger on-update para re-embeddings de novos documentos. Sem isto, o índice fica desactualizado.
• Backup do índice — vector DB é dados. Replicar como qualquer base de dados (snapshot Qdrant, dump Chroma, pg_dump para pgvector).
• Começar pequeno, depois escalar — Chroma + 50 documentos + GPT-4o-mini para prova de conceito em 1 dia. Migrar para Qdrant/pgvector em produção só quando o padrão estiver validado.
• Documentar o “porquê” — porque se escolheu bge-m3 em vez de OpenAI, porque chunk de 800 e não 1500. RAG é 70% de decisões de engenharia; sem documentação, a equipa repete erros.
• Cross-referência com outros artigos AI — Ollama + Open WebUI stack avançado 2026 para inferência local, Copilot governance e plugins para políticas de uso responsável de LLM na empresa.

Artigos Relacionados

• Ollama + Open WebUI Stack Avançado 2026 — Como correr LLM e embeddings localmente; base de inferência open-source que complementa o RAG para dados sensíveis.
• Copilot, Cowork, Governança, Plugins, Modelos, Browser — Política de uso responsável de LLM na PME; quando usar cloud, quando usar local, governança de prompts.
• Hermes AI Agent com Ollama — Instalação e Configuração — Stack de agente AI local que usa embeddings e LLM on-prem, alternativa self-host a LangChain cloud.
• Ollama + Open WebUI + Docker Compose + Nemotron — Deployment prático de LLM open-source com Docker; base para RAG local em PME.
• Copilot + ChatGPT Scripts PowerShell Sysadmin — Padrões de prompt para automação administrativa; útil quando se quer combinar RAG com acções de sistema.

11. Checklist Antes de Aplicar em Produção

1. Verificar versões: pip show langchain chromadb qdrant-client sentence-transformers openai — anotar versões e comparar com as indicadas nas docs oficiais acedidas em 2026-07-18.
2. Verificar chaves de API: OPENAI_API_KEY, PINECONE_API_KEY ou QDRANT_URL definidas no ambiente; nunca comitar no git.
3. Verificar modelo de embedding: confirmar dimensões (1536, 1024, 768) compatíveis com a coleção na vector DB; mismatch causa erro de inserção silencioso.
4. Preparar golden set: 30-50 queries reais com resposta esperada, guardadas em JSON. Sem isto, não há forma de medir regressões.
5. Ambiente de staging: projecto sandbox Python 3.11 com dependências pinadas em requirements.txt; testar ingestão de 10 documentos reais e 20 queries antes de migrar para produção.
6. Backup do estado: antes de alterar modelo de embedding ou chunk size, exportar a vector DB (dump Chroma, snapshot Qdrant, pg_dump para pgvector). Configuração errada obriga a re-indexar tudo, o que custa tempo e dinheiro.