HNSW vs. LSH: Como o Elasticsearch atinge 0.99 recall@10 a 15.000 QPS

O Elasticsearch atinge 0,99 recall@10 a 15.000 QPS graças à sua implementação altamente otimizada do algoritmo Hierarchical Navigable Small World (HNSW) no Apache Lucene — não ao Locality Sensitive Hashing (LSH). Diferentemente do LSH, que depende de hashing probabilístico e sofre queda significativa de recall em vetores densos (ex.: float32 com 768–1536 dimensões), o HNSW constrói um grafo multicamada que permite busca gananciosa eficiente, mantendo alta precisão mesmo sob carga extrema. A versão atual do Elasticsearch (9.3) combina HNSW com quantização binária DiskBBQ, alcançando 0,97 recall@10 a 55.000 QPS — um ganho de 3,7× em throughput com apenas 0,02 de redução no recall. Essa otimização é crítica para aplicações de RAG, recomendação em tempo real e busca semântica em escala industrial.

Enquanto o LSH ainda é usado em cenários específicos como similaridade Jaccard (MinHash LSH) ou texto curto (SimHash), ele falha sistematicamente em tarefas de similaridade cosseno ou euclidiana em embeddings modernos (ex.: BERT, E5, OpenAI text-embedding-3-large). Benchmarks oficiais do Elasticsearch Labs (outubro de 2025) confirmam que o HNSW com quantização int8 reduz consumo de memória em até 75% com impacto desprezível no recall, enquanto o LSH não oferece ajuste fino equivalente: seu recall@10 estagna em ~0,87 mesmo em 15.000 QPS — 12 pontos percentuais abaixo do HNSW.

Esse desempenho não é técnico por acaso: ele define a viabilidade comercial de sistemas baseados em busca vetorial em produção. Um recall@10 de 0,99 significa que, em 99% dos casos, os 10 resultados mais relevantes (segundo o embedding) estão entre os top 10 retornados — essencial para UX em assistentes inteligentes, buscas de produtos e detecção de fraude. Já 15.000 QPS equivale à capacidade de servir consultas simultâneas para centenas de milhares de usuários ativos, como em marketplaces ou plataformas SaaS. A escolha entre HNSW e LSH impacta diretamente custo operacional: HNSW com DiskBBQ reduz memória RAM em 8× versus HNSW puro, enquanto LSH exige reindexação completa para ajustes de sensibilidade — inviável em ambientes com atualizações contínuas de embeddings.

Além disso, o Elasticsearch supera concorrentes como OpenSearch em benchmarks recentes: na versão 8.14, é 2–12× mais rápido que OpenSearch 2.14 em QPS equivalente; na 9.3 com BBQ HNSW, apresenta latência de servidor 5–9× menor que OpenSearch 3.5 com FAISS. Isso posiciona o HNSW do Elasticsearch como referência de fato para ANN em produção no Brasil e globalmente — especialmente para quem busca HNSW Elasticsearch, recall@10 Elasticsearch ou QPS busca vetorial.

Para desenvolvedores, isso significa que a configuração do campo dense_vector passa a exigir decisões estratégicas: usar quantização int8 ou DiskBBQ pode reduzir custos de infraestrutura em até 80% sem comprometer a experiência do usuário, mas requer testes rigorosos com dados reais — pois o ganho de throughput varia conforme a distribuição dos vetores (ex.: embeddings de imagens vs. textos). Parâmetros como num_candidates (default: 50) controlam o trade-off entre recall e latência: aumentar para 100 melhora recall@10 em ~0,005, mas eleva a latência média em 15–20%. Também é crítico dimensionar shards entre 10–50 GB para cargas vetoriais, pois grafos HNSW mal fragmentados causam gargalos de RAM e degradação abrupta do recall.

O suporte nativo a busca híbrida (kNN + BM25 via Reciprocal Rank Fusion) permite integrar busca semântica com filtros textuais sem pipelines externos — reduzindo complexidade de arquitetura e latência final. Isso é fundamental para quem implementa RAG Elasticsearch, busca semântica Elasticsearch ou recomendação com embeddings. Ferramentas como o Elasticsearch Playground e os relatórios de benchmark do Elasticsearch Labs (disponíveis desde outubro de 2025) permitem simular cenários com HNSW vs LSH antes da implantação — prática recomendada para evitar surpresas em produção.