RAG sem mistério: escolha o vector DB e avalie a recuperação
RAG não é mágica—é engenharia de produto. Ele traz contexto “vivo” para LLMs via busca semântica antes da geração, reduzindo alucinações e mantendo respostas atualizadas. Mas o ganho só aparece quando você escolhe bem o vector database e mede a recuperação continuamente. Neste guia, explicamos quando RAG faz sentido, comparamos pgvector, FAISS e Chroma em alto nível e propomos um experimento básico para medir recall e consistência, além de dicas práticas para reduzir alucinações. Para um panorama de avaliação em RAG, vale a leitura do RAGAS e de revisões recentes sobre métricas.
Quando RAG faz sentido
- Base de conhecimento dinâmica (políticas, FAQs, catálogos) em que “re-treinar modelo” não é prático.
- Exigência de rastreabilidade (mostrar de onde veio a resposta).
- Domínios extensos em que poucas instruções de prompt não bastam. Se suas perguntas são repetitivas e estáveis, um template + prompts pode ser suficiente; quando há variedade, atualização e necessidade de fontes, RAG tende a ganhar.
Como escolher o vector DB (critérios práticos)
1) Desempenho & escalabilidade. Procure suporte a ANN (índices aproximados), CPU/GPU e recursos de sharding. O FAISS, desenvolvido pela Meta, é referência em busca eficiente e clustering, com implementações C++/Python e suporte a GPU.
2) Custo total e operação. O pgvector roda dentro do PostgreSQL, reduzindo atritos operacionais (um banco, um backup, um monitoramento). A extensão suporta busca exata e aproximada, múltiplas distâncias (L2, cosseno, IP) e vem evoluindo rapidamente.
3) Ecossistema e DX. Se o foco é produtividade e iteração local, Chroma oferece API simples para armazenar embeddings/metadata e busca vetorial + full-text, com docs acessíveis.
4) Integrações. Verifique conectores com suas libs de orquestração. LangChain integra com FAISS e Chroma, acelerando protótipos e POCs. (Útil para provas de conceito, ainda que não substitua critérios de produção.)
Comparação em alto nível
- pgvector (PostgreSQL extension): bom para quem quer simplificar stack e manter vetores + tabelas juntas; ótima integração com ecos Java/.NET/Go/PHP; avança em ANN e performance. Use quando governança Postgres já está madura no time.
- FAISS (library): excelente para alto desempenho e controle fino de índices; ideal para workloads que exigem tuning profundo (quantização, IVF, HNSW, GPU). Exige mais engenharia para servir em produção (camada API/ops).
- Chroma (vector DB): foco em DX, metadata e busca; bom para times que querem protótipos rápidos e uma base aberta com opções de produção escaláveis.
Leitura complementar no site da Tekne: LLMs no dia a dia do analista: 4 automações rápidas e comparativos de stack em Power BI vs Tableau: qual domina em 2025?.
Experimento básico para avaliar a recuperação
Objetivo: verificar se o seu pipeline recupera o que importa (recall) com consistência sob ajustes de chunking, index e embedding.
Amostra representativa. Colete 100–300 perguntas reais (logs anonimizados) e defina, para cada uma, os documentos relevantes (3–5) como ground truth.
Protocolo. Para cada combinação (ex.: pgvector+HNSW, FAISS+IVF, Chroma+HNSW):
- Recall@k: % de perguntas em que pelo menos um doc relevante aparece no top-k.
- Coverage: % de perguntas com todos os docs relevantes no top-k.
- Consistência: repita 3 execuções com seeds iguais e pequenas variações de chunk; acompanhe variação de recall.
Leitura e decisão. Prefira combinações com recall@k alto e baixa variância, compatíveis com seu SLA de latência e custo. Para entender trade-offs e métricas de RAG, consulte RAGAS (recall, faithfulness, answer relevancy) e pesquisas de survey.
Dicas para reduzir alucinações (e aumentar confiança)
- Aprimore o retrieval, não só o prompt. Ajuste embedding model, chunking (tamanho/overlap) e rerank quando possível.
- Maximize “groundedness”. Exija citações (links/IDs) e penalize respostas sem fontes.
- Higiene de base. Remova duplicatas/versões antigas, marque metadados (data, tipo, confiabilidade).
- Avalie continuamente. RAG degrada com o tempo; rode o experimento de recall em janelas (ex.: quinzenal). Frameworks como RAGAS aceleram a avaliação sem rótulos manuais para cada caso.
Conclusão e próximo passo
RAG entrega valor quando recupera bem o que importa e gera a partir de fontes confiáveis. A escolha do vector DB deve refletir seu contexto: pgvector para simplificar operações em Postgres, FAISS para máxima performance/tuning e Chroma para velocidade de desenvolvimento. O essencial é medir recall e consistência desde o dia 1 e acompanhar em produção. Quer implementar esse pipeline com segurança? Conheça o Curso Machine Learning & IA e explore conteúdos práticos da Tekne.
