2026: filtragem e hybrid search nas bases vetoriais

TL;DR

Em 2026, a conversa sobre bases vetoriais saiu do “armazenar embeddings” e foi para o desenho fino do pipeline de consulta. O ponto principal é que hybrid search e filtering agora entram na API de primeira classe, com impacto direto em recall, latência e na forma de combinar sinais densos e lexicais.

O que mudou no desenho das consultas

O recorte do briefing mostra três linhas muito claras: Weaviate expõe hybrid search com controle de peso entre vetor e keyword, Qdrant organiza consultas multi-sinal com filtros e prefetch, e Azure AI Search torna explícito quando o filtro acontece antes ou depois da busca vetorial. Em vez de uma consulta única “mágica”, o que aparece é uma composição de etapas, cada uma com efeito real sobre os candidatos retornados. Veja as docs oficiais de Weaviate hybrid search, Qdrant hybrid queries e Azure AI Search vector query filters.

Na prática, isso muda a forma como a equipe pensa o problema. Para um mecanismo de recomendação, por exemplo, não basta achar itens semanticamente próximos; também é preciso respeitar filtros de negócio, como país, categoria, estoque ou perfil do usuário. Quando esses sinais entram em fases diferentes do pipeline, o resultado final pode mudar bastante mesmo com o mesmo embedding de origem.

Weaviate: híbrido com controle explícito de fusão

A documentação do Weaviate descreve a busca híbrida como a combinação de BM25 e vetores, com peso ajustável via alpha. Isso permite favorecer o lado semântico ou o lado lexical sem tirar nenhum dos dois do caminho. O mesmo conjunto de docs também apresenta estratégias de fusão como relativeScoreFusion e rankedFusion, o que dá ao engenheiro mais controle sobre como os resultados são consolidados.

Esse detalhe é importante porque a combinação de sinais não é neutra. Uma busca por termo raro, em português, pode depender muito de keyword; já uma consulta mais descritiva pode ganhar mais com o componente vetorial. Em uma aplicação brasileira de atendimento ou catálogo, isso ajuda quando o nome do produto aparece em uma variação local, mas a intenção do usuário foi escrita de outro jeito.

Quando o threshold entra na conversa

O briefing também destaca o uso de threshold no componente vetorial, como maxVectorDistance. O efeito é direto: mesmo que o componente lexical traga candidatos, o recorte vetorial ainda pode excluir itens que estejam longe demais semanticamente. Na prática, isso ajuda a reduzir ruído em cenários onde o texto bate, mas a intenção não bate.

Quando a consulta mistura linguagem natural e termos de domínio, o ponto de falha costuma ser a fusão. Por isso, vale testar o peso do vetor, o peso do lexical e o threshold separadamente, em vez de ajustar tudo de uma vez.

Qdrant: filtros de payload e consultas multiestágio

No Qdrant, o componente central não é só o vetor; é também o payload filtering. A documentação oficial descreve filtros aplicados por condições estruturadas sobre campos do payload, incluindo combinações com must e estruturas aninhadas. Isso é útil quando a base guarda metadados ricos, como região, idioma, segmento ou janela temporal.

A parte mais interessante para hybrid search é a API universal com prefetch. A consulta pode pré-carregar candidatos por mais de um sinal e depois consolidar a resposta final. O material do Universal Query API ainda menciona filtros aplicados globalmente no nível da query ou específicos por prefetch, o que deixa a composição bem explícita para o desenvolvedor.

Esse desenho favorece arquiteturas multiestágio. Primeiro, você amplia a base de candidatos com mais de um caminho de busca. Depois, aplica filtro de negócio e uma regra de ranking final. Isso costuma ser mais fácil de depurar do que esconder tudo dentro de uma única chamada opaca.

Por que multiestágio importa

Em sistemas com consulta seletiva, o risco clássico é reduzir demais a busca cedo demais. Se o filtro entra cedo e a base é pequena, você pode perder itens corretos; se entra tarde demais, você paga custo desnecessário. O valor do modelo do Qdrant é tornar essa decisão visível no acesso à API, em vez de tratá-la como vida interna do índice.

Azure AI Search: o tempo do filtro altera o resultado

O Azure AI Search formaliza algo que muitos times tratavam como detalhe interno: o modo de aplicação do filtro. A doc de vector query filters mostra preFilter, postFilter e strictPostFilter, cada um com efeitos diferentes em recall e desempenho. Já a doc de hybrid search ranking explica o uso de RRF para unificar rankings em cenários híbridos.

O ponto prático é simples: filtrar antes da travessia tende a preservar melhor o recall em filtros seletivos, mas pode custar mais CPU. Filtrar depois tende a ser mais barato em alguns casos, mas pode eliminar bons candidatos antes da fusão final. Em indexação distribuída, isso deixa de ser um detalhe acadêmico e vira decisão de arquitetura.

Para quem opera sistemas de busca em produção, essa distinção ajuda a entender bug reports do tipo “a busca funciona sem filtro, mas some resultado quando incluo país ou categoria”. Muitas vezes o problema não é o embedding, e sim o lugar onde o filtro entrou no pipeline.

Uma leitura prática para times no Brasil

O ângulo brasileiro aqui não é retórico: ele passa por custo e operação. Muitos times no Brasil ainda trabalham com orçamento em BRL e infraestrutura com latência sensível para regiões como us-east-1, enquanto também precisam acomodar requisitos de LGPD quando o payload carrega dados pessoais ou identificadores de perfil. Em cenários assim, poder escolher entre prefilter, postfilter, hybrid com alpha ou fusão por ranking não é luxo; é forma de evitar gasto desnecessário e reduzir risco regulatório. As regras de tratamento de dados da LGPD também tornam importante limitar o que entra no payload e como ele é usado em busca.

Outro ponto bem brasileiro é a composição de times. É comum ter squads com formação mista, parte vinda de bootcamp e parte vindo de banco de dados tradicional. Para esse contexto, uma API que separa índice vetorial, filtro de metadados e fusão ajuda a alinhar o raciocínio entre quem pensa em SQL e quem pensa em embeddings. A documentação deixa de ser só referência técnica e vira ferramenta de alinhamento entre áreas.

O que testar antes de colocar em produção

Se você está avaliando essas features, vale montar um conjunto pequeno de consultas reais e medir três coisas: qualidade dos resultados, custo por consulta e sensibilidade dos filtros. Teste uma query sem filtro, uma com filtro seletivo e uma com mistura de termos curtos e longos. A diferença entre elas normalmente revela mais sobre a arquitetura do que um benchmark genérico.

Também vale separar o experimento em duas camadas: primeiro a recuperação, depois a fusão. Se o sistema estiver trazendo candidatos bons, mas a ordenação final estiver ruim, o problema pode estar no método de fusão. Se os candidatos já vierem pobres, o problema provavelmente está na etapa de filtro ou no equilíbrio entre sinais dense e lexical.

Conclusão

O recorte de 2026 deixa uma mensagem clara: em bases vetoriais, buscar bem passou a significar combinar sinais com intenção. Hybrid search, filtering e fusão não são acessórios; são parte do contrato de consulta e influenciam diretamente o comportamento do sistema. Para quem opera no Brasil, isso conversa com custo, latência, LGPD e com a realidade de times que precisam unir SQL, busca textual e embeddings no mesmo produto.

Se você quer transformar isso em prática ainda hoje, abra as docs oficiais de Weaviate hybrid search, Qdrant hybrid queries e Azure AI Search vector query filters, escolha uma consulta real do seu projeto e compare preFilter, postFilter e um híbrido com vetor+keyword em menos de 1 hora.

Conteúdos da DIO para quem quer aprofundar

• Database Experience — trilha para fortalecer fundamentos de bancos de dados e entender melhor modelagem, consultas e operações que ajudam a pensar filtros e recuperação em sistemas de busca.
• Formação SQL Database Specialist — formação voltada a SQL, modelagem e boas práticas, útil para quem quer conectar raciocínio relacional com consultas em dados vetoriais e metadados.
• Aceleração Internacional DIO - Integrating SQL Databases with Python and MongoDB — aceleração que conecta SQL, Python e MongoDB, boa para quem quer transitar entre dados relacionais e bancos NoSQL em arquiteturas de busca.

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