RAG com vector databases: o que mudou no retrieval

TL;DR

Vector databases para RAG deixaram de ser só uma camada de busca por similaridade. Hoje, o ponto central está em combinar vetores, texto esparso e filtros por metadados para recuperar menos ruído e mais contexto útil.

Na prática, isso muda a arquitetura: em alguns cenários vale usar um motor dedicado com hybrid search e filtragem index-aware; em outros, o Postgres com pgvector já resolve bem sem adicionar outro serviço ao stack.

Do top-K por similaridade para retrieval de verdade

O primeiro desenho de RAG usava embedding + busca top-K e parava aí. Isso funciona, mas costuma trazer documentos semanticamente parecidos que não são os mais úteis para a pergunta real. O que o briefing mostra é uma evolução clara: hoje as engines relevantes tratam filtros, fusão de sinais e ranking híbrido como parte do mecanismo central de recuperação.

Esse avanço importa porque RAG não é só “achar algo parecido”. Em muitos fluxos, o sistema precisa respeitar idioma, tenant, tipo de documento, recorte temporal e até seção do conteúdo. Sem isso, o contexto recuperado cresce em volume e piora em precisão.

Busca híbrida: sparse e dense no mesmo fluxo

O sinal mais forte dessa evolução é a busca híbrida. Em vez de depender apenas de embeddings, a consulta mistura recuperação esparsa, como BM25, e recuperação densa por vetores, e depois funde os resultados. A explicação prática aparece em Getting Started with Hybrid Search e em Hybrid Search Explained.

Na documentação do Weaviate, a busca híbrida combina matching textual e vetorial, enquanto o modo de uso em Hybrid search descreve os parâmetros de execução. Já o Pinecone apresenta o caminho de índice esparso+denso com controle de peso via alpha. Em termos de produto, isso reduz a dependência de um único tipo de sinal: o texto literal ajuda quando a entidade importa, e o embedding ajuda quando a intenção está mais implícita.

Para RAG em português, isso é particularmente útil. Um usuário pode perguntar com termos muito específicos que o embedding não captou bem, ou usar abreviações e nomes internos da empresa. A parte esparsa preserva esses termos, enquanto a parte densa cobre variações semânticas.

Filtros por metadados não são detalhe de apoio

Outro ponto importante do briefing é que filtros deixaram de ser um pós-processamento simples. Em Qdrant, o Filterable HNSW mostra que o índice pode ser construído para respeitar filtros durante a travessia, em vez de só cortar resultados depois.

Isso faz diferença quando o sistema RAG atende múltiplos clientes, múltiplos domínios ou conteúdo com regras de visibilidade. Em vez de buscar em todo o universo e filtrar depois, o motor já reduz o espaço de busca com base em payload indexado. No material de Payload - Qdrant, o payload é descrito como JSON usado em condições de filtro com tipos estruturados.

Na prática, isso viabiliza padrões comuns de RAG:

• tenant_id para isolamento multicliente;
• doc_type para separar contrato, manual e FAQ;
• language para atender português e inglês no mesmo índice;
• timestamp para limitar contexto a dados recentes;
• section_title para recuperar trechos mais bem recortados.

Quanto mais cedo o filtro entra na recuperação, menor a chance de gastar contexto do LLM com ruído que o usuário nunca queria ver.

Fusão de consultas e reranking: quando um só score não basta

O briefing também aponta que algumas engines aceitam fusão de múltiplas consultas. Em Hybrid Queries - Qdrant, aparecem estratégias como rrf e dbsf para combinar rankings vindos de representações diferentes.

Esse ponto é relevante porque buscas híbridas não terminam no “somar score e pronto”. Em retrieval real, listas diferentes podem vir com escalas incompatíveis, e a fusão precisa preservar itens relevantes mesmo quando um dos sinais não ranqueia bem sozinho. Em muitos sistemas, esse estágio ainda conversa com reranking posterior, principalmente quando a consulta é curta e ambígua.

O ganho prático é fácil de visualizar: uma pergunta pode recuperar um documento por similaridade semântica, outro porque contém o termo exato, e um terceiro por proximidade de contexto. A fusão ajuda a formar um conjunto inicial melhor para o LLM resumir ou responder.

pgvector: quando o Postgres já resolve a camada vetorial

Nem todo time precisa adotar um banco vetorial dedicado. O repositório pgvector mostra uma alternativa bem pragmática: busca vetorial diretamente no Postgres, com opções de índice aproximado, half-precision e binary quantization. Em várias arquiteturas, isso reduz um componente do sistema e simplifica operação.

A vantagem do pgvector é especialmente clara quando o produto já usa Postgres como fonte principal de verdade. Em vez de sincronizar outro banco, guardar metadados em um sistema separado e cuidar de mais uma rotina operacional, o time pode manter documentos, filtros e vetores próximos do dado transacional. O trade-off aparece quando o volume, a latência ou a concorrência exigem tuning mais agressivo do que um banco relacional costuma oferecer.

Para times brasileiros com orçamento enxuto, isso pesa. Em vez de abrir uma nova frente de infraestrutura em dólar, muita equipe consegue começar com Postgres, validar o caso de uso e só depois migrar para uma engine dedicada se o perfil de consulta exigir.

Como pensar a escolha de arquitetura

O briefing sugere uma diferença importante entre “armazenar vetores” e “operar retrieval”. A primeira ideia resolve protótipo. A segunda resolve produto. Se a aplicação precisa de filtros fortes, consultas híbridas e fusão de resultados, um banco vetorial com esses recursos nativos tende a encaixar melhor.

Se a aplicação é menor, ou se o dado já vive no Postgres, pgvector costuma ser uma rota mais simples. Em contrapartida, se há necessidade de payload rico, múltiplas estratégias de fusão e otimização do índice para filtros, o conjunto de capacidades descrito em Qdrant Hybrid Queries e em Filterable HNSW vira diferencial arquitetural.

Uma forma prática de decidir é perguntar:

• preciso de busca textual e vetorial ao mesmo tempo?
• meu caso exige filtros obrigatórios antes da resposta?
• o time já opera Postgres com folga?
• o custo operacional de mais um serviço faz sentido agora?

As respostas costumam apontar mais para simplicidade operacional ou para especialização de busca.

Por que isso importa pro dev brasileiro

No Brasil, a escolha entre Postgres e uma vector database dedicada não é só técnica. Ela também cruza custo em BRL, câmbio e maturidade do time. Em muitas empresas, a meta é colocar RAG em produção sem inflar a conta de infraestrutura em dólar; por isso, começar com pgvector no Postgres pode ser uma decisão mais realista do que adotar uma stack nova desde o primeiro dia.

Há também o fator operacional. Muitos times brasileiros já têm Postgres como sistema central, inclusive em produtos com dados sensíveis sujeitos à LGPD. Manter documentos, metadados e vetores próximos facilita controle de acesso, trilha de auditoria e governança do dado, sem multiplicar integrações desnecessárias.

Ao mesmo tempo, quando o projeto cresce, o contexto BR costuma trazer latência para regiões fora do país, integração com times pequenos e janela de orçamento curta. Nessa situação, motores com filtros index-aware e hybrid search ajudam a recuperar menos lixo, consumir menos tokens e entregar resposta com mais previsibilidade.

Conclusão

O retrato atual de RAG com vector databases é menos sobre “qual banco guarda embeddings?” e mais sobre “qual engine recupera o contexto certo com o menor ruído possível?”. Hybrid search, filtros por metadados e fusão de consultas viraram peças centrais desse desenho.

Se você já usa Postgres, vale testar pgvector antes de introduzir outro serviço. Se o caso pede recuperação mais sofisticada, compare as capacidades de Qdrant Hybrid Queries, Weaviate Hybrid e a abordagem de Pinecone para entender qual encaixa melhor no seu fluxo.

CTA prático: em até 1 hora, pegue uma base pequena do seu domínio, adicione 3 metadados reais no índice ou tabela, rode duas consultas — uma só vetorial e outra híbrida — e compare manualmente quais trechos realmente ajudariam o LLM a responder melhor.

Conteúdos da DIO para quem quer aprofundar

• Database Experience — Bootcamp de banco de dados com conceitos de SQL e NoSQL, modelagem, SGBD, EER, arquitetura e queries para aprofundar a base necessária antes de operar retrieval em produção.
• Formação SQL Database Specialist — Formação focada em modelagem, DML, DDL, controle de concorrência e boas práticas para quem quer dominar a camada relacional que часто convive com RAG.
• Aceleração Internacional DIO - Integrating SQL Databases with Python and MongoDB — Trilha voltada à integração entre bancos SQL, Python e MongoDB, útil para entender convivência entre diferentes modelos de persistência em aplicações de dados.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.