Elasticsearch war großartig, aber Vektordatenbanken sind die Zukunft
Dieser Beitrag wurde ursprünglich auf The New Stack veröffentlicht und wird hier mit Genehmigung erneut veröffentlicht.
Seit Jahrzehnten ist Keyword-Matching, auch bekannt als Volltextsuche, veranschaulicht durch Elasticsearch, die Standardwahl für Information-Retrieval-Systeme wie Enterprise Search und Empfehlungsmaschinen.
Mit dem Fortschritt KI-gestützter Suchtechnologien vollzieht sich ein Wandel hin zur semantischen Suche, die es Systemen ermöglicht, sowohl die Bedeutung als auch die Absicht hinter Benutzeranfragen zu verstehen. Embedding-Modelle und Vektordatenbanken sind zu zentralen Bestandteilen dieses Wandels geworden.
Die semantische Suche übertrifft Keyword-Matching, indem sie Daten als Vektor-Embeddings darstellt, ein nuancierteres Verständnis der Suchabsicht bietet und Anwendungen von retrieval-augmented generation (RAG) bis hin zur multimodalen Suche transformiert.
In der Praxis benötigen effektive Information-Retrieval-Systeme sowohl semantisches Verständnis als auch exaktes Keyword-Matching. Benutzer erwarten beispielsweise, dass Suchergebnisse Konzepte anzeigen, die mit ihren Suchanfragen zusammenhängen, während zugleich der wörtliche Text der Anfrage berücksichtigt wird, wie etwa spezielle Begriffe und Namen, und die exakt passenden Ergebnisse zurückgegeben werden.
Eine durch dichte Vektoren gestützte semantische Suche hilft dabei, die Bedeutung zu verstehen (etwa zu wissen, dass „car“ und „automobile“ dasselbe sind), und die traditionelle Volltextsuche liefert die präzisen Ergebnisse, die Benutzer erwarten (etwa exakte Treffer für „Python 3.9“ zu finden). Infolgedessen verfolgen viele Organisationen einen hybriden Suchansatz, der die Stärken beider Methoden kombiniert, um flexible semantische Relevanz mit vorhersehbarem exaktem Keyword-Matching auszubalancieren.
Die Herausforderung der hybriden Suche
Eine gängige Methode zur Implementierung hybrider Suche besteht darin, eine speziell entwickelte Vektordatenbank wie das Open-Source-Milvus für effiziente und skalierbare semantische Suche zusammen mit traditionellen Suchmaschinen wie Elasticsearch oder OpenSearch für die Volltextsuche zu verwenden.
Obwohl dieser Ansatz gute Ergebnisse liefern kann, führt er auch eine neue Komplexitätsebene ein. Zwei unterschiedliche Suchsysteme zu verwalten bedeutet, sich mit separaten Infrastrukturen, Konfigurationen und Wartungsaufgaben auseinanderzusetzen, was den operativen Aufwand erhöht und die Wahrscheinlichkeit potenzieller Integrationsprobleme steigert.
Elasticsearch vs Milvus bei der hybriden Suche
Abbildung: Elasticsearch vs Milvus bei der hybriden Suche
Eine einheitliche Lösung für hybride Suche würde viele Vorteile bieten:
Reduzierter Infrastruktur-Wartungsaufwand: Die Verwaltung eines Systems statt zweier Systeme reduziert die operative Komplexität drastisch und spart sowohl Zeit als auch Ressourcen. Das bedeutet auch weniger Kontextwechsel und weniger mentale Belastung, um zwei verschiedene API-Sätze zu beherrschen.
Konsolidierte Datenverwaltung: Eine einheitliche Tabellenstruktur ermöglicht es Ihnen, sowohl dichte (vektorbasierte) als auch spärliche (keywordbasierte) Daten zusammen mit gemeinsamen Metadaten-Labels zu speichern. Die Verwendung zweier separater Systeme würde erfordern, Metadaten-Labels doppelt zu speichern, damit beide Seiten Metadatenfilterung durchführen können.
Optimierte Abfrage: Eine einzelne Anfrage kann sowohl semantische als auch Volltextsuchaufgaben ausführen, wodurch die Notwendigkeit entfällt, zwei API-Aufrufe an separate Systeme durchzuführen.
Verbesserte Sicherheit und Zugriffskontrolle: Ein einheitlicher Ansatz ermöglicht ein unkomplizierteres und robusteres Sicherheitsmanagement, da alle Zugriffskontrollen zentral innerhalb einer Vektordatenbank administriert werden können, wodurch Sicherheits-Compliance und Konsistenz verbessert werden.
Wie ein einheitlicher Vektoransatz die hybride Suche vereinfacht
Bei der semantischen Suche „betten“ Machine-Learning-Modelle Text als Punkte ein, die als dichte Vektoren bezeichnet werden, in einem hochdimensionalen Raum basierend auf seiner Bedeutung. Texte mit ähnlicher Semantik liegen in diesem Raum näher beieinander. Beispielsweise könnten „Apfel“ und „Obst“ in diesem Raum näher beieinander liegen als „Apfel“ und „Auto“. Dadurch können wir semantisch verwandten Text schnell finden, indem wir einfach die Distanz zwischen den einzelnen Punkten mithilfe von Approximate-Nearest-Neighbor-(ANN)-Algorithmen berechnen.
Diese Methode kann auch auf die Volltextsuche angewendet werden, indem Dokumente und Abfragen als dünn besetzte Vektoren codiert werden. In dünn besetzten Vektoren repräsentiert jede Dimension einen Begriff, und der Wert gibt an, wie wichtig jeder Begriff im Dokument ist.
Begriffe, die im Dokument nicht vorhanden sind, haben einen Wert von null. Da ein bestimmtes Dokument typischerweise nur einen kleinen Teil aller möglichen Begriffe im Vokabular verwendet, erscheinen die meisten Begriffe nicht im Dokument. Das bedeutet, dass die resultierenden Vektoren dünn besetzt sind — die meisten ihrer Werte sind null. Beispielsweise gibt es im MS-MARCO-Datensatz, der häufig zur Bewertung von Aufgaben des Information Retrieval verwendet wird, etwa 9 Millionen Dokumente und eine Million eindeutige Begriffe, doch ein Suchsystem unterteilt diese große Sammlung typischerweise in kleinere Segmente, um die Verwaltung zu erleichtern.
Selbst auf Segmentebene, mit Hunderttausenden von Begriffen im Vokabular, enthält jedes Dokument normalerweise weniger als 100 Begriffe, was bedeutet, dass über 99 % der Werte jedes Vektors null sind. Diese extreme Dünnbesetztheit hat wichtige Auswirkungen darauf, wie wir diese Vektoren effizient speichern und verarbeiten.
Dieses Muster der Dünnbesetztheit kann genutzt werden, um die Suchleistung zu optimieren und gleichzeitig die Genauigkeit aufrechtzuerhalten. Vektordatenbanken, die ursprünglich für dichte Vektoren entwickelt wurden, können angepasst werden, um diese dünn besetzten Vektoren effizient zu verarbeiten. Beispielsweise hat die Open-Source-Vektordatenbank Milvus gerade native Unterstützung für Volltextsuche mit Sparse-BM25 veröffentlicht, einer dünn besetzten Vektorimplementierung des BM25-Algorithmus, der von Elasticsearch und anderen Volltextsuchsystemen verwendet wird. Sparse-BM25 ermöglicht approximationsbasierte Optimierung für die Volltextsuche mit:
Effizienter Abrufalgorithmus mit Datenbereinigung: Durch das Anwenden heuristikbasierter Bereinigung zum Verwerfen von Dokumenten mit den niedrigsten dünn besetzten Vektorwerten im Segmentindex und das Ignorieren niedrigwertiger dünn besetzter Vektoren in der Suchabfrage kann eine Vektordatenbank die Indexgröße deutlich reduzieren und die Leistung mit minimalem Qualitätsverlust optimieren.
Erschließen weiterer Leistungsoptimierungen: Die Darstellung der Termhäufigkeit als dünn besetzter Vektor statt als invertierter Index ermöglicht zusätzliche vektorbasierte Optimierungen. Dazu gehören:
Graphindizierung wird für eine effizientere Suche als Brute-Force-Scans verwendet.
Product Quantization (PQ) / Scalar Quantization (SQ), um den Speicherbedarf weiter zu reduzieren.
Zusätzlich zu diesen Optimierungen übernimmt die Sparse-BM25-Implementierung auch mehrere Vorteile auf Systemebene von der leistungsstarken Vektordatenbank Milvus:
Effiziente Low-Level-Implementierung und Speicherverwaltung: Die zentrale Vektorindizierungs-Engine in Milvus ist in C++ implementiert und bietet eine effizientere Speicherverwaltung als ein Java-basiertes System wie Elasticsearch. Allein dies reduziert den Speicherbedarf, indem im Vergleich zu einem JVM-basierten Ansatz Gigabytes eingespart werden.
Unterstützung für MMap: Ähnlich wie Elasticsearchs Nutzung des Page-Cache für die Indexspeicherung sowohl im Arbeitsspeicher als auch auf der Festplatte unterstützt Milvus Memory Mapping (MMap), um die Speicherkapazität zu erweitern, wenn der Index den verfügbaren Arbeitsspeicher überschreitet.
Warum traditionelle Such-Stacks bei der Vektorsuche an ihre Grenzen stoßen
Elasticsearch wurde für traditionelle invertierte Indizes entwickelt, wodurch die Optimierung der gesamten Architektur für die Suche nach dichten Vektoren grundsätzlich schwierig ist. Die Auswirkungen sind deutlich: Selbst bei nur 1 Million Vektoren benötigt Elasticsearch 200 Millisekunden (getestet auf der vollständig verwalteten Elastic Cloud), um das Suchergebnis zurückzugeben, im Vergleich zu 6 ms bei Milvus (getestet auf der vollständig verwalteten Zilliz Cloud) — das ist ein Leistungsunterschied von mehr als dem 30-Fachen. Auch der Durchsatz, gemessen in Abfragen pro Sekunde (QPS), weist einen Unterschied um den Faktor 3 auf: Die leistungsstärkste Instanz auf Zilliz Cloud läuft mit 6000 QPS, während Elastic Cloud maximal 1900 QPS erreicht. Darüber hinaus ist Zilliz Cloud beim Laden der Vektordaten und beim Erstellen des Index 15-mal schneller als Elastic Cloud. Diese Leistungslücke vergrößert sich bei Skalierung, da Elasticsearchs Java/JVM-Implementierung Schwierigkeiten hat, mit der Skalierbarkeit von C++/Go-basierten Vektordatenbanken mitzuhalten. Zusätzlich fehlen Elasticsearch kritische Funktionen für die Vektorsuche wie festplattenbasierte Indizes (DiskAnn, MMap), optimierte Metadatenfilterung und Bereichssuche.
VectorDBBench Benchmarking Results.jpg
Abbildung: VectorDBBench Benchmarking-Ergebnisse (Quelle)
Fazit
Vektordatenbanken, wie sie Milvus beispielhaft verkörpert, sind auf dem besten Weg, Elasticsearch als einheitliche Lösung für hybride Suche zu übertreffen. Durch die Integration der Suche nach dichten Vektoren mit optimierten Sparse-Vector-Techniken bieten Vektordatenbanken überlegene Leistung, Skalierbarkeit und Effizienz. Dieser einheitliche Ansatz vereinfacht die Infrastruktur, reduziert den Speicherbedarf und erweitert die Suchmöglichkeiten, wodurch er zur Zukunft fortschrittlicher Suchanforderungen wird. Infolgedessen bieten Vektordatenbanken eine umfassende Lösung, die semantische Suche und Volltextsuche nahtlos kombiniert und traditionelle Suchsysteme wie Elasticsearch übertrifft.
Weiterlesen
3 Easiest Ways to Use Claude Code on Your Mobile Phone
Run Claude Code from your phone with Remote Control, Happy Coder, or SSH + Tailscale. Comparison table, setup steps, and tools for typing, memory, and parallel tasks.
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.
Build for the Boom: Why AI Agent Startups Should Build Scalable Infrastructure Early
Explore strategies for developing AI agents that can handle rapid growth. Don't let inadequate systems undermine your success during critical breakthrough moments.