O Elasticsearch Foi Ótimo, Mas os Bancos de Dados Vetoriais São o Futuro
Este post foi originalmente publicado em The New Stack e é republicado aqui com permissão.
Por décadas, a correspondência de palavras-chave, também conhecida como busca de texto completo, exemplificada pelo Elasticsearch, tem sido a escolha padrão para sistemas de recuperação de informações, como busca empresarial e mecanismos de recomendação.
À medida que as tecnologias de busca impulsionadas por IA avançam, há uma mudança em direção à busca semântica, permitindo que os sistemas entendam tanto o significado quanto a intenção por trás das consultas dos usuários. Modelos de embedding e bancos de dados vetoriais tornaram-se centrais para essa mudança.
A busca semântica supera a correspondência de palavras-chave ao representar dados como embeddings vetoriais, proporcionando uma compreensão mais sutil da intenção de busca e transformando aplicações que vão desde geração aumentada por recuperação (RAG) até busca multimodal.
Na prática, sistemas eficazes de recuperação de informações precisam tanto de compreensão semântica quanto de correspondência exata de palavras-chave. Por exemplo, os usuários esperam que os resultados de busca mostrem conceitos relacionados às suas consultas de busca, ao mesmo tempo em que respeitam o texto literal usado na consulta, como termos e nomes especiais, e retornem os resultados de correspondência exata.
Uma busca semântica impulsionada por vetores densos ajuda a entender o significado (como saber que ‘car’ e “automobile” são a mesma coisa) e a busca tradicional de texto completo fornece os resultados precisos que os usuários esperam (como encontrar correspondências exatas para “Python 3.9”). Como resultado, muitas organizações estão adotando uma abordagem de busca híbrida, combinando os pontos fortes de ambos os métodos para equilibrar relevância semântica flexível com correspondência exata e previsível de palavras-chave.
O Desafio da Busca Híbrida
Uma forma comum de implementar busca híbrida é usar um banco de dados vetorial criado para esse fim, como o Milvus de código aberto, para busca semântica eficiente e escalável, juntamente com mecanismos de busca tradicionais como Elasticsearch ou OpenSearch para busca de texto completo.
Embora essa abordagem possa gerar bons resultados, ela também introduz uma nova camada de complexidade. Gerenciar dois sistemas de busca distintos significa lidar com infraestruturas, configurações e tarefas de manutenção separadas, criando uma carga operacional mais pesada e aumentando a chance de possíveis problemas de integração.
Elasticsearch vs Milvus na busca híbrida
Figura: Elasticsearch vs Milvus na busca híbrida
Uma solução unificada para busca híbrida traria muitos benefícios:
Manutenção reduzida da infraestrutura: Gerenciar um sistema em vez de dois reduz drasticamente a complexidade operacional, economizando tempo e recursos. Isso também significa menos troca de contexto e sobrecarga mental para dominar dois conjuntos diferentes de APIs.
Gerenciamento de dados consolidado: Uma estrutura de tabela unificada permite armazenar dados densos (baseados em vetores) e esparsos (baseados em palavras-chave) juntamente com rótulos de metadados compartilhados. Usar dois sistemas separados exigiria armazenar rótulos de metadados duas vezes para que ambos os lados pudessem realizar filtragem por metadados.
Consulta simplificada: Uma única solicitação pode executar tanto tarefas de busca semântica quanto de texto completo, eliminando a necessidade de realizar duas chamadas de API para sistemas separados.
Segurança e controle de acesso aprimorados: Uma abordagem unificada permite uma gestão de segurança mais direta e robusta, já que todos os controles de acesso podem ser administrados centralmente em um banco de dados vetorial, melhorando a conformidade e a consistência da segurança.
Como uma Abordagem Vetorial Unificada Simplifica a Busca Híbrida
Na busca semântica, modelos de machine learning “incorporam” texto como pontos, conhecidos como vetores densos, em um espaço de alta dimensionalidade com base em seu significado. Textos com semântica semelhante ficam mais próximos uns dos outros nesse espaço. Por exemplo, “maçã” e “fruta” podem estar mais próximos nesse espaço do que “maçã” e “carro.” Isso nos permite encontrar rapidamente textos semanticamente relacionados apenas calculando a distância entre cada ponto usando algoritmos de vizinho mais próximo aproximado (ANN).
Esse método também pode ser aplicado à busca de texto completo codificando documentos e consultas como vetores esparsos. Em vetores esparsos, cada dimensão representa um termo e o valor indica a importância de cada termo no documento.
Termos que não estão presentes no documento têm valor zero. Como qualquer documento geralmente usa apenas uma pequena parte de todos os termos possíveis no vocabulário, a maioria dos termos não aparecerá no documento. Isso significa que os vetores resultantes são esparsos — a maioria de seus valores é zero. Por exemplo, no conjunto de dados MS-MARCO comumente usado para avaliar tarefas de recuperação de informações, embora existam cerca de 9 milhões de documentos e um milhão de termos únicos, um sistema de busca normalmente divide essa grande coleção em segmentos menores para facilitar o gerenciamento.
Mesmo no nível do segmento, com centenas de milhares de termos em seu vocabulário, cada documento geralmente contém menos de 100 termos, o que significa que mais de 99% dos valores de cada vetor são zero. Essa extrema esparsidade tem implicações importantes para a forma como armazenamos e processamos esses vetores de maneira eficiente.
Esse padrão de esparsidade pode ser explorado para otimizar o desempenho da busca mantendo a precisão. Bancos de dados vetoriais originalmente projetados para vetores densos podem ser adaptados para lidar com esses vetores esparsos de forma eficiente. Por exemplo, o banco de dados vetorial open source Milvus acaba de lançar suporte nativo à busca de texto completo usando Sparse-BM25, uma implementação de vetor esparso do algoritmo BM25 usado pelo Elasticsearch e outros sistemas de busca de texto completo. O Sparse-BM25 desbloqueia a otimização baseada em aproximação para busca de texto completo com:
Algoritmo de recuperação eficiente com poda de dados: Ao aplicar poda baseada em heurísticas para descartar documentos com os menores valores de vetor esparso no índice do segmento e ignorar vetores esparsos de baixo valor na consulta de busca, um banco de dados vetorial pode reduzir significativamente o tamanho do índice e otimizar o desempenho com perda mínima de qualidade.
Desbloqueio de otimizações adicionais de desempenho: Representar a frequência de termos como um vetor esparso em vez de um índice invertido permite otimizações adicionais baseadas em vetores. Elas incluem:
Indexação em grafos é usada para uma busca mais eficiente do que varreduras de força bruta.
Quantização de produto (PQ) / quantização escalar (SQ) para reduzir ainda mais a pegada de memória.
Além dessas otimizações, a implementação Sparse-BM25 também herda várias vantagens em nível de sistema do banco de dados vetorial de alto desempenho Milvus:
Implementação de baixo nível e gerenciamento de memória eficientes: O mecanismo central de indexação vetorial no Milvus é implementado em C++, oferecendo gerenciamento de memória mais eficiente do que um sistema baseado em Java como o Elasticsearch. Só isso reduz a pegada de memória ao economizar gigabytes em comparação com uma abordagem baseada em JVM.
Suporte a MMap: Semelhante ao uso que o Elasticsearch faz do page-cache para armazenamento de índices tanto na memória quanto em disco, o Milvus oferece suporte a mapeamento de memória (MMap) para ampliar a capacidade de memória quando o índice excede a memória disponível.
Por que as pilhas de busca tradicionais ficam aquém na busca vetorial
O Elasticsearch foi criado para índices invertidos tradicionais, tornando fundamentalmente difícil otimizar toda a arquitetura para busca vetorial densa. O impacto é claro: mesmo com apenas 1 milhão de vetores, o Elasticsearch leva 200 milissegundos (conforme testado no Elastic Cloud totalmente gerenciado) para retornar o resultado da busca, em comparação com 6 ms no Milvus (conforme testado no Zilliz Cloud totalmente gerenciado) — isso representa uma diferença de desempenho de mais de 30x. A taxa de transferência medida por consultas por segundo (QPS) também apresenta uma diferença de 3x, em que a instância de melhor desempenho no Zilliz Cloud opera a 6000 QPS, enquanto o Elastic Cloud chega no máximo a 1900 QPS. Além disso, o Zilliz Cloud é 15x mais rápido no carregamento dos dados vetoriais e na construção do índice do que o Elastic Cloud. Essa lacuna de desempenho aumenta em escala, quando a implementação Java/JVM do Elasticsearch tem dificuldade para igualar a escalabilidade de bancos de dados vetoriais baseados em C++/Go. Além disso, o Elasticsearch carece de recursos críticos de busca vetorial, como índices baseados em disco (DiskAnn, MMap), filtragem de metadados otimizada e busca por intervalo.
VectorDBBench Benchmarking Results.jpg
Figura: Resultados de benchmarking do VectorDBBench (fonte)
Conclusão
Bancos de dados vetoriais, exemplificados pelo Milvus, estão preparados para superar o Elasticsearch como a solução unificada para busca híbrida. Ao integrar busca vetorial densa com técnicas otimizadas de vetores esparsos, bancos de dados vetoriais oferecem desempenho, escalabilidade e eficiência superiores. Essa abordagem unificada simplifica a infraestrutura, reduz o consumo de memória e aprimora os recursos de busca, tornando-se o futuro das necessidades avançadas de busca. Como resultado, bancos de dados vetoriais fornecem uma solução abrangente que combina perfeitamente busca semântica e busca de texto completo, superando sistemas de busca tradicionais como o Elasticsearch.
Continue lendo
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
Zilliz Named "Highest Performer" and "Easiest to Use" in G2's Summer 2025 Grid® Report for Vector Databases
Zilliz shines in G2's Summer 2025 Grid® Report as both "Highest Performer" and "Easiest to Use," solving the performance-usability dilemma.
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.