Elasticsearch ist tot, es lebe die lexikalische Suche

Inzwischen weiß jeder, dass die hybride Suche die RAG-Suchqualität (Retrieval-Augmented Generation) verbessert hat. Während die Suche mit dichter Einbettung beeindruckende Fähigkeiten bei der Erfassung tiefer semantischer Beziehungen zwischen Abfragen und Dokumenten gezeigt hat, weist sie immer noch bemerkenswerte Einschränkungen auf. Dazu gehören mangelnde Erklärbarkeit und suboptimale Leistung bei Long-Tail-Anfragen und seltenen Begriffen.

Viele RAG-Anwendungen haben damit zu kämpfen, dass den vortrainierten Modellen oft domänenspezifisches Wissen fehlt. In einigen Szenarien übertrifft das einfache BM25-Schlüsselwortmatching diese hochentwickelten Modelle. Hier schließt die hybride Suche die Lücke, indem sie das semantische Verständnis des Dense Vector Retrieval mit der Präzision des Keyword Matching kombiniert.

Warum die hybride Suche in der Produktion komplex ist

Während Frameworks wie LangChain oder LlamaIndex den Aufbau eines Proof-of-Concept-Hybrid-Retrievers erleichtern, ist die Skalierung auf die Produktion mit massiven Datensätzen eine Herausforderung. Herkömmliche Architekturen erfordern separate Vektordatenbanken und Suchmaschinen, was zu mehreren zentralen Herausforderungen führt:

• Hohe Wartungskosten für die Infrastruktur und betriebliche Komplexität

• Datenredundanz über mehrere Systeme hinweg

• Schwierige Verwaltung der Datenkonsistenz

• Komplexe Sicherheit und systemübergreifende Zugriffskontrolle

Der Markt benötigt eine einheitliche Lösung, die lexikalische und semantische Suche unterstützt und gleichzeitig die Systemkomplexität und -kosten reduziert.

Die Schmerzpunkte von Elasticsearch

Elasticsearch ist eines der einflussreichsten Open-Source-Suchprojekte des letzten Jahrzehnts. Es basiert auf Apache Lucene und wurde durch seine hohe Leistung, Skalierbarkeit und verteilte Architektur populär. Obwohl in Version 8.0 die Vector ANN-Suche hinzugefügt wurde, stehen Produktionsimplementierungen vor mehreren kritischen Herausforderungen:

Hohe Aktualisierungs- und Indizierungskosten: Die Architektur von Elasticsearch entkoppelt Schreibvorgänge, Indexaufbau und Abfragen nicht vollständig. Dies führt zu erheblichem CPU- und I/O-Overhead bei Schreiboperationen, insbesondere bei Massenaktualisierungen. Die Ressourcenkonkurrenz zwischen Indizierung und Abfrage wirkt sich auf die Leistung aus und stellt einen erheblichen Engpass für hochfrequente Aktualisierungsszenarien dar.

Schlechte Leistung in Echtzeit: Als "echtzeitnahe" Suchmaschine führt Elasticsearch zu einer spürbaren Latenz bei der Datensichtbarkeit. Diese Latenz wird besonders problematisch für KI-Anwendungen, wie z. B. Agentensysteme, bei denen hochfrequente Interaktionen und dynamische Entscheidungsfindung einen sofortigen Datenzugriff erfordern.

Schwierige Shard-Verwaltung: Obwohl Elasticsearch Sharding für eine verteilte Architektur verwendet, stellt das Shard-Management eine große Herausforderung dar. Das Fehlen einer dynamischen Sharding-Unterstützung führt zu einem Dilemma: Zu viele Shards in kleinen Datensätzen führen zu schlechter Leistung, während zu wenige Shards in großen Datensätzen die Skalierbarkeit einschränken und eine ungleichmäßige Datenverteilung verursachen.

Nicht-Cloud-native Architektur: Elasticsearch wurde entwickelt, bevor sich Cloud-native Architekturen durchsetzten. Das Design von Elasticsearch koppelt Storage und Compute eng aneinander, was die Integration mit modernen Infrastrukturen wie Public Clouds und Kubernetes einschränkt. Die Skalierung der Ressourcen erfordert eine gleichzeitige Erhöhung von Speicher und Rechenleistung, was die Flexibilität einschränkt. In Szenarien mit mehreren Replikaten muss jeder Shard seinen Index unabhängig aufbauen, was die Rechenkosten erhöht und die Ressourceneffizienz verringert.

Schlechte Vektorsuchleistung: Obwohl Elasticsearch 8.0 die ANN-Vektorsuche eingeführt hat, bleibt seine Leistung deutlich hinter der von dedizierten Vektormaschinen wie Milvus zurück. Die auf dem Lucene-Kernel basierende Indexstruktur erweist sich als ineffizient für hochdimensionale Daten und hat mit den Anforderungen einer groß angelegten Vektorsuche zu kämpfen. Besonders instabil wird die Leistung in komplexen Szenarien mit skalarer Filterung und Mandantenfähigkeit, was es schwierig macht, eine hohe Last oder unterschiedliche Geschäftsanforderungen zu unterstützen.

Übermäßiger Ressourcenverbrauch: Elasticsearch stellt extreme Anforderungen an Speicher und CPU, insbesondere bei der Verarbeitung großer Datenmengen. Seine JVM-Abhängigkeit erfordert häufige Anpassungen der Heap-Größe und eine Optimierung der Garbage Collection, was die Speichereffizienz stark beeinträchtigt. Vektorsuchoperationen erfordern intensive SIMD-optimierte Berechnungen, für die die JVM-Umgebung alles andere als ideal ist.

Diese grundlegenden Beschränkungen werden zunehmend problematisch, wenn Unternehmen ihre KI-Infrastruktur skalieren, was Elasticsearch zu einer besonderen Herausforderung für moderne KI-Anwendungen macht, die hohe Leistung und Zuverlässigkeit erfordern.

Einführung von Sparse-BM25: Lexikalische Suche neu gedacht

Milvus 2.5 führt native lexikalische Suchunterstützung durch Sparse-BM25 ein, die auf den in Version 2.4 eingeführten hybriden Suchfunktionen aufbaut. Dieser innovative Ansatz umfasst die folgenden Schlüsselkomponenten:

• Erweiterte Tokenisierung und Vorverarbeitung durch Tantivy

• Verteiltes Vokabular und Termfrequenzmanagement

• Sparse-Vektor-Generierung mit Korpus-TF und Abfrage-TF-IDF

• Unterstützung von invertierten Indizes mit dem WAND-Algorithmus (Block-Max WAND und Graph-Index-Unterstützung in Entwicklung)

Im Vergleich zu Elasticsearch bietet Milvus erhebliche Vorteile bei der Flexibilität des Algorithmus. Seine auf Vektor-Distanz basierende Ähnlichkeitsberechnung ermöglicht ein ausgefeilteres Matching, einschließlich der Implementierung von TW-BERT (Term Weighting BERT) auf der Grundlage der "End-to-End Query Term Weighting"-Forschung. Dieser Ansatz hat sowohl bei In-Domain- als auch bei Out-Domain-Tests eine hervorragende Leistung gezeigt.

Ein weiterer entscheidender Vorteil ist die Kosteneffizienz. Durch die Nutzung des invertierten Index und der Dense Embedding-Komprimierung erreicht Milvus eine fünffache Leistungsverbesserung bei einer Verschlechterung des Recalls um weniger als 1 %. Durch Tail-Term Pruning und Vektorquantisierung wurde die Speichernutzung um über 50 % reduziert.

Die Optimierung langer Abfragen ist eine besondere Stärke. Wo herkömmliche WAND-Algorithmen mit längeren Abfragen zu kämpfen haben, zeichnet sich Milvus durch die Kombination von Sparse Embeddings mit Graph-Indizes aus, was zu einer zehnfachen Leistungsverbesserung in hochdimensionalen Sparse-Vector-Such-Szenarien führt.

Milvus: Die ultimative Vektordatenbank für RAG

Milvus ist durch seinen umfassenden Funktionsumfang die erste Wahl für RAG-Anwendungen. Zu den wichtigsten Vorteilen gehören:

• Umfangreiche Metadatenunterstützung mit dynamischen Schemafunktionen und leistungsstarken Filteroptionen

• Mehrmandantenfähigkeit auf Unternehmensebene mit flexibler Isolierung durch Sammlungen, Partitionen und Partitionsschlüssel

• Branchenweit erste Unterstützung für Festplattenvektorindizes mit mehrstufiger Speicherung vom Speicher bis zu S3

• Cloud-native Skalierbarkeit mit nahtloser Skalierung von 10 Mio. bis 1 Mrd. Vektoren

• Umfassende Suchfunktionen, einschließlich Gruppierung, Bereich und hybride Suche

• Tiefgreifende Ökosystemintegration mit LangChain, LlamaIndex, Dify und anderen KI-Tools

Die vielfältigen Suchfunktionen des Systems umfassen Gruppierungs-, Bereichs- und hybride Suchmethoden. Die tiefe Integration mit Tools wie LangChain, LlamaIndex und Dify sowie die Unterstützung zahlreicher KI-Produkte machen Milvus zum Zentrum des modernen KI-Infrastruktur-Ökosystems.

Blick in die Zukunft

Mit dem Übergang von KI von POC zur Produktion entwickelt sich Milvus weiter. Wir konzentrieren uns darauf, die Vektorsuche zugänglicher und kostengünstiger zu machen und gleichzeitig die Suchqualität zu verbessern. Ob Sie ein Startup oder ein Unternehmen sind, Milvus reduziert die technischen Barrieren für die Entwicklung von KI-Anwendungen.

Dieses Engagement für Zugänglichkeit und Innovation hat uns zu einem weiteren großen Schritt nach vorn geführt. Während unsere Open-Source-Lösung weiterhin als Grundlage für Tausende von Anwendungen weltweit dient, haben wir erkannt, dass viele Unternehmen eine vollständig verwaltete Lösung benötigen, die den operativen Overhead eliminiert.

Zilliz Cloud: Die verwaltete Lösung

In den letzten drei Jahren haben wir Zilliz Cloud, einen vollständig verwalteten Vektordatenbankdienst auf der Grundlage von Milvus, entwickelt. Durch eine Cloud-native Neuimplementierung des Milvus-Protokolls bietet er verbesserte Benutzerfreundlichkeit, Kosteneffizienz und Sicherheit.

Mit unserer Erfahrung in der Wartung der weltweit größten Vektorsuchcluster und der Unterstützung von Tausenden von KI-Anwendungsentwicklern reduziert Zilliz Cloud den betrieblichen Aufwand und die Kosten im Vergleich zu selbst gehosteten Lösungen erheblich.

Sind Sie bereit, die Zukunft der Vektorsuche zu erleben? Starten Sie noch heute Ihre kostenlose Testversion mit einem Guthaben von bis zu 200 $, keine Kreditkarte erforderlich.