RAG sem mistério: escolha o vector DB e avalie a recuperação
RAG não é mágica; é engenharia de produto.
A sigla vem de Retrieval-Augmented Generation, ou geração aumentada por recuperação. Na prática, ela permite que LLMs consultem uma base externa antes de gerar a resposta, trazendo contexto mais atualizado, rastreável e específico para cada pergunta.
No entanto, o ganho só aparece quando a recuperação funciona bem. Ou seja, não basta conectar um modelo a uma base de documentos. É preciso escolher o vector DB adequado, definir uma estratégia de chunking, selecionar embeddings, medir recall, acompanhar consistência e avaliar continuamente se as respostas estão realmente fundamentadas nas fontes.
Neste guia, você vai entender quando RAG faz sentido, como comparar pgvector, FAISS e Chroma em alto nível, e como montar um experimento básico para medir recuperação, consistência e risco de alucinação.
Quando RAG faz sentido
RAG é uma boa escolha quando o produto precisa responder com base em informações que mudam com frequência ou que não estão no conhecimento geral do modelo.
Isso acontece, por exemplo, em bases de conhecimento dinâmicas, como políticas internas, FAQs, catálogos, documentação técnica, contratos, manuais e conteúdos regulatórios. Nesses casos, retreinar o modelo a cada atualização não costuma ser prático.
Além disso, RAG faz sentido quando há exigência de rastreabilidade. Se o usuário precisa saber de onde veio a resposta, a aplicação deve recuperar fontes, trechos, IDs ou links que sustentem a geração.
Por outro lado, nem todo problema precisa de RAG. Se as perguntas são repetitivas, estáveis e bem delimitadas, um template com prompts bem desenhados pode ser suficiente. Já quando há variedade, atualização frequente e necessidade de fontes confiáveis, RAG tende a ser uma solução mais adequada.
Como escolher o vector DB (critérios práticos)
1. Desempenho e escalabilidade
O primeiro critério é desempenho. Verifique se a solução oferece suporte a ANN — approximate nearest neighbor —, índices aproximados, uso eficiente de CPU ou GPU, além de recursos de particionamento, replicação ou sharding, quando necessário.
Nesse ponto, FAISS é uma referência importante. Desenvolvido pela Meta, ele é uma biblioteca voltada a busca eficiente por similaridade e clustering de vetores densos, com implementações em C++ e Python, além de suporte a algoritmos em GPU.
2. Custo total e operação
Também avalie o custo operacional. Se o time já usa PostgreSQL, o pgvector pode reduzir atritos, porque permite armazenar vetores junto com dados relacionais, aproveitando práticas já existentes de backup, monitoramento, governança e acesso.
O pgvector suporta busca exata e aproximada, múltiplas distâncias e qualquer linguagem com cliente PostgreSQL, o que facilita a integração em stacks já consolidadas.
3. Ecossistema e DX
DX, ou developer experience, também importa. Em fases de protótipo, POC ou iteração local, ferramentas com API simples aceleram muito o aprendizado do time.
Nesse contexto, Chroma é uma opção interessante para armazenar embeddings e metadados, aplicar filtros, fazer busca vetorial, busca full-text e recuperar dados em diferentes formatos.
4. Integrações
Antes de escolher o vector DB, verifique também as integrações com suas bibliotecas de orquestração. LangChain, por exemplo, possui integração com FAISS para uso como vector store e retriever, o que ajuda na montagem de protótipos e fluxos de RAG.
Ainda assim, integração não substitui critério de produção. Em outras palavras, uma ferramenta fácil de prototipar não será necessariamente a melhor opção para escala, governança, latência ou custo.
Comparação em alto nível
pgvector
O pgvector é uma extensão do PostgreSQL para busca vetorial. Ele é uma boa escolha quando o time quer simplificar a stack, manter vetores e tabelas no mesmo banco e aproveitar uma governança PostgreSQL já madura.
Na prática, funciona bem quando a operação valoriza consistência, integração com dados relacionais, simplicidade de backup e menor fragmentação da infraestrutura.
FAISS
O FAISS é uma biblioteca voltada a alto desempenho em busca por similaridade. Ele é forte quando o projeto exige controle fino de índices, tuning, quantização, IVF, HNSW ou uso de GPU.
Por outro lado, como é uma biblioteca, normalmente exige mais engenharia para servir em produção. Você pode precisar criar uma camada de API, observabilidade, persistência, atualização de índices e operação ao redor dela.
Chroma
O Chroma tem foco em produtividade, metadados e recuperação para aplicações de IA. Ele é útil para times que precisam testar rápido, criar protótipos e iterar em aplicações com embeddings, filtros e busca textual.
Ainda assim, antes de levar para produção, avalie requisitos de escala, segurança, custo, governança, persistência, deploy e integração com o restante da arquitetura.
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
O objetivo do experimento é simples: verificar se o pipeline recupera o que importa com consistência.
Para isso, compare combinações de vector DB, embedding model, chunking e índice. Por exemplo: pgvector + HNSW, FAISS + IVF ou Chroma + HNSW.
1. Monte uma amostra representativa
Colete de 100 a 300 perguntas reais, sempre com logs anonimizados. Depois, defina para cada pergunta quais documentos ou trechos são relevantes. Esses documentos funcionam como ground truth, ou seja, a referência usada para medir se a recuperação encontrou o que deveria encontrar.
Sempre que possível, estratifique a amostra por intenção, dificuldade, frequência e impacto para o negócio.
2. Defina o protocolo
Para cada combinação de ferramentas e parâmetros, meça:
- Recall@k: porcentagem de perguntas em que pelo menos um documento relevante aparece no top-k.
- Coverage: porcentagem de perguntas em que todos os documentos relevantes aparecem no top-k.
- Consistência: variação do resultado em execuções repetidas, com seeds controladas e pequenas mudanças de chunking.
- Latência: tempo de busca e rerank, especialmente em p95.
- Custo: custo estimado de embeddings, armazenamento, consulta e reranking.
3. Leia os resultados
Prefira combinações com Recall@k alto, baixa variância, latência compatível com o SLA e custo aceitável para o caso de uso.
Além disso, avalie métricas específicas de RAG com ferramentas como RAGAS, que oferece métricas como Context Precision, Context Recall, Response Relevancy e Faithfulness.
Dicas para reduzir alucinações (e aumentar confiança)
Aprimore o retrieval, não apenas o prompt
Muitos problemas atribuídos ao prompt, na verdade, começam na recuperação. Se o pipeline recupera trechos errados, incompletos ou desatualizados, o modelo terá pouco contexto para gerar uma resposta confiável.
Por isso, ajuste embedding model, tamanho de chunk, overlap, filtros por metadados e rerank antes de tentar resolver tudo com instruções no prompt.
Maximize groundedness
Groundedness indica o quanto a resposta está fundamentada nas fontes recuperadas.
Para melhorar esse ponto, exija citações, links, IDs de documentos ou trechos usados na geração. Além disso, penalize respostas sem fontes quando a tarefa exigir rastreabilidade.
Faça higiene da base
Uma base com duplicatas, documentos antigos e versões conflitantes aumenta o risco de resposta incorreta.
Mantenha metadados como data, tipo de documento, versão, origem, confiabilidade e status de validade. Dessa forma, o retrieval consegue priorizar fontes mais relevantes e atuais.
Avalie continuamente
RAG degrada com o tempo. Documentos mudam, perguntas mudam e prioridades de negócio também mudam.
Por isso, rode o experimento de recuperação em janelas periódicas, como quinzenal ou mensalmente. Quando erros recorrentes aparecerem em produção, transforme esses casos em novas perguntas do conjunto de avaliação.
Conclusão e próximo passo
RAG entrega valor quando recupera bem o que importa e gera respostas a partir de fontes confiáveis.
A escolha do vector DB deve refletir o contexto do produto. pgvector tende a fazer sentido para quem quer simplificar operações em PostgreSQL. FAISS é forte para alta performance e tuning avançado. Chroma favorece velocidade de desenvolvimento e experimentação com boa DX.
No entanto, a escolha da ferramenta é apenas uma parte do trabalho. O essencial é medir Recall@k, consistência, latência, custo e groundedness desde o primeiro dia. Dessa forma, o time reduz alucinações, melhora rastreabilidade e toma decisões com base em evidências, não apenas em percepções.
Quer implementar esse pipeline com segurança? Conheça o Curso Machine Learning & IA e explore conteúdos práticos da Tekne.
