Blog
Ein Entwicklerleitfaden zur Erkundung der Funktionen von Milvus 2.6 auf Zilliz Cloud

Ein Entwicklerleitfaden zur Erkundung der Funktionen von Milvus 2.6 auf Zilliz Cloud

Feb 11, 202610 min read

Milvus begann als hochperformante Open-Source-Vektordatenbank, die für Skalierbarkeit entwickelt wurde und modernste Vektor-ANN-Suchfunktionen bietet. Mit dem Wachstum der Entwickler-Community erweiterten sich die Feature-Anfragen um Volltextsuche, Boosting und Unterstützung für halbstrukturierte Datentypen (JSON, Struct usw.). Diese Anfragen spiegeln einen breiteren Trend zur Konvergenz von Datenbankfähigkeiten wider, angetrieben durch den Bedarf an fortgeschritteneren Funktionen (jenseits der Ähnlichkeitssuche), die die Entwicklung von KI-Anwendungen beschleunigen helfen.

Die Konvergenz zeigt sich nicht nur in Feature-Anfragen — sie zeigt sich nun in der Datenbank selbst. Mit Milvus 2.6 sind viele Fähigkeiten, die Entwickler zuvor außerhalb der Datenbank zusammenfügen mussten, wie decay-basiertes Ranking, Boosting auf Feldebene und hybrides Filtern über strukturierte und unstrukturierte Daten hinweg, nun erstklassige Primitive.

Mit anderen Worten: Milvus 2.6 markiert einen Wandel von "Vektorsuche + Glue Code" hin zu einer fortschrittlicheren Retrieval-Engine, und sie ist jetzt Generally Available (GA) on Zilliz Cloud (ein verwalteter Milvus-Service).

In diesem Artikel führe ich durch einige der coolen Features von Milvus v2.6, wann man sie verwendet und wie man sie verwendet. Los geht's!

Die Embedding Function (auch bekannt als Data In, Data Out)

Hast du dich jemals gefragt, ob die Datenbank die Erzeugung von Embeddings in deinem Namen übernehmen kann? Mit Embedding Functions (auch bekannt als "Data in, data out") kann Milvus Rohtext in Vektoren umwandeln, indem es externe Drittanbieter-Embedding-Services wie OpenAI, VoyageAI und Cohere aufruft.

Embedding Functions wurde erstmals in Milvus v2.6.0 veröffentlicht, und ich habe es in der kafka-milvus-no-code-pipelines-Demo vorgestellt. Jetzt sind Embedding Functions auf Zilliz Cloud verfügbar, dem vollständig verwalteten Service der Milvus-Vektordatenbank.

Wie funktioniert die Embedding Function?

Angenommen, du fügst "The quick brown fox jumps over the lazy dog" in Milvus ein, wobei eine Embedding Function konfiguriert ist. Milvus fängt es auf der Proxy-Schicht ab, leitet es durch eine anbieterspezifische Embedding-Pipeline und speichert den von deinem Modell erzeugten Vektor. Dieselbe Transformation geschieht während der Suche in umgekehrter Richtung. Dein Abfragetext wird in einen Vektor umgewandelt, bevor er den Index erreicht.

Dieses Feature ist besonders nützlich für Teams, die die Verantwortung für die Verwaltung von Embedding-Workflows an die Datenbank auslagern möchten. Indem die Datenbank Embeddings zur Ingestionszeit transparent generiert (über einen Drittanbieter-Modellanbieter), kümmert sich Zilliz Cloud um API-Integration, Batching, Wiederholungsversuche, Rate Limits und Fehlerbehandlung.

Um mit Embedding Functions auf Zilliz Cloud zu starten, brauchst du:

Richte Model Provider Integration für den Embedding-Service-Anbieter deiner Wahl ein
Erstelle eine Collection mit definierter Embedding Function
Füge deine Daten ein.

Du solltest die Embedding Function in der Zilliz Cloud-Konsole auf der Schema-Seite deiner Collection sehen können, wenn du sie korrekt eingerichtet hast.

Jetzt musst du nur noch den Rohtext einfügen, und Embeddings werden automatisch generiert und in deinem angegebenen Dense-Vector-Feld gespeichert. Mit definierten Embedding Functions musst du keine Embeddings mehr erzeugen, nicht einmal für deine Suchabfrage.

Ein mögliches Problem, auf das du stoßen könntest, ist das Batchgrößenlimit, das Milvus bei der Verwendung der Embedding Function auferlegt.

2026-01-21 14:03:12,902 [ERROR][handler]: RPC-Fehler: [insert_rows], <MilvusException: (code=65535, message=numRows [1000] > Funktion [openai]s maximale Batchgröße [640])>, <Time:{'RPC start': '2026-01-21 14:03:12.722589', 'RPC error': '2026-01-21 14:03:12.902013'}>

Best Practices und Tipps

Halten Sie die Batchgrößenbeschränkung ein (in der Fehlermeldung angezeigt). Dies ist ein Sicherheitsmechanismus, um zu vermeiden, dass das Token-Limit des Modellanbieters pro API-Aufruf erreicht wird. OpenAI hat beispielsweise eine Beschränkung von maximal 300.000 Tokens pro API-Aufruf.
Für lange Texte oder Anwendungsfälle mit großen Dokumenten müssen Sie vor dem Einfügen in Chunks aufteilen. Beispielsweise hat OpenAI für alle Einbettungsmodelle ein Limit von 8192 Tokens pro Eingabetext.
Während Anbieter wie VoyageAI und Cohere lange Texte standardmäßig automatisch kürzen, kann ein Verlassen darauf zum stillen Verlust von Inhalten am Ende Ihres Dokuments führen.

Lexikalische Hervorhebung

Lexikalische Hervorhebung ist nützlich, um Nutzern zu zeigen, warum ein Ergebnis zu ihrer Anfrage passte, indem die genauen Begriffe oder Phrasen, die die Übereinstimmung ausgelöst haben, visuell markiert werden. Dies verbessert Transparenz, Interpretierbarkeit und das Vertrauen der Nutzer in Suchergebnisse.

Hier sind einige wichtige Szenarien:

Anzeige von Suchergebnissen in Benutzeroberflächen. Beim Erstellen von Suchoberflächen hilft Hervorhebung den Nutzern, die Relevanz eines Ergebnisses schnell zu verstehen, ohne das vollständige Dokument zu öffnen. Sie reduziert die kognitive Belastung und verbessert die Klickrate, indem sie die Übereinstimmung explizit macht.

Dokumenten- / Inhaltssuche. In großen Dokumenten (z. B. Wissensdatenbanken, PDFs, Richtlinien) ermöglicht lexikalische Hervorhebung den Nutzern, übereinstimmende Schlüsselwörter innerhalb des umgebenden Kontexts sofort zu finden, wodurch die Informationssuche beschleunigt wird.

Log- / Ereignisanalyse. Hervorhebung in Betriebsprotokollen oder Ereignisdaten erleichtert es, übereinstimmende Muster, Fehlercodes oder Schlüsselwörter in dichtem, unstrukturiertem Text zu erkennen, insbesondere bei der Fehlerbehebung oder Incident Response.

RAG-Debugging (Retrieval-Augmented Generation). In RAG-Pipelines hilft lexikalische Hervorhebung Fachleuten dabei zu prüfen, welche Teile der abgerufenen Chunks mit der ursprünglichen Anfrage übereinstimmten. Dies ist nützlich für:

Überprüfung der Korrektheit des Abrufs
Diagnose von False Positives oder schwachen Übereinstimmungen
Verständnis, warum ein bestimmter Kontext für die Generierung ausgewählt wurde

Um serverseitige lexikalische Hervorhebung mit Zilliz Cloud zu implementieren, instanziieren Sie zunächst einen LexicalHighlighter (mit dem Abfragetext, der hervorgehoben werden soll, und umgebenden Tags, die angeben, wie hervorgehobener Text aussieht) und übergeben ihn als Parameter an Ihre Volltextsuchanfrage.

Dann führt Milvus die Suche durch und wendet die lexikalische Logik an, um exakte Übereinstimmungen zu finden und Positionsinformationen dazu zurückzugeben, welche Teilstrings hervorgehoben werden sollen.

Best Practices und Tipps

LexicalHighlighter funktioniert nur mit der BM25-Volltextsuche. Er funktioniert nicht für die Suche mit dichten Vektoren.
Sie können pre_tags und post_tags definieren, um übereinstimmende Begriffe mit HTML-Tags zu umschließen (z. B. benutzerdefinierte CSS-Klasse, fett, kursiv usw.), die direkt auf einer Webseite gerendert werden.

N-gram-Index

N-gram-Indizes sind leistungsstarke Indexierungstechniken für Suchmaschinen, die Zeichenketten in kleinere und überlappende Zeichenfolgen zerlegen (z. B. "coffee" in 3-Gramme -> "cof", "off", "ffe", "fee"), um partielle, flexible und platzhalterartige Übereinstimmungen zu ermöglichen.

Hier sind einige Szenarien, in denen n-gram-Indizes nützlich sind:

Verbesserung der Leistung von Teilstringsuchen (z. B. LIKE %deep%)
Search-as-you-type / Autovervollständigung
Fuzzy-Suche
Suche nach Domainnamen und Kennungen (z. B. example.com, facebook.com)

Wie funktioniert es?

Dokumente, die ein bestimmtes n-Gramm enthalten, können effizient mithilfe eines Index gefunden werden, der oft als invertierter Index bezeichnet wird und jedes n-Gramm einer Liste von Identifikatoren der Dokumente zuordnet, die dieses n-Gramm enthalten. Die Liste wird sortiert gehalten, um sowohl effiziente Komprimierung als auch effiziente Abfrageausführung zu ermöglichen. Im Fall von Milvus wird der ngram index auf Tantivy aufgebaut, das wiederum Komprimierungstechniken wie Delta-Codierung, Bitpacking und Skip-Listen verwendet, um die invertierte Liste zu komprimieren und ihre Größe zu reduzieren, wodurch der Index leichtgewichtig wird.

Anstatt einen vollständigen Scan Ihres Textfelds durchzuführen, extrahiert Milvus zuerst das Prädikat, z. B. deep, zerlegt es basierend auf den konfigurierten Grammgrößen in n-Gramme, führt Lookups im invertierten Index durch und schneidet die Ergebnisse, um Kandidaten zu identifizieren, die alle Grams enthalten, und überprüft anschließend exakte Übereinstimmungen mit dem ursprünglichen LIKE-Muster.

Milvus ermöglicht es Ihnen, min_gram und max_gram anzugeben, die jeweils die minimale und maximale Länge der n-Gramme darstellen, die generiert werden. Weitere Details dazu, wie Sie einen ngram index erstellen und verwenden, finden Sie im NGRAM Index document.

Hier ist eine kurze Demo der Autovervollständigung, die mithilfe der ngram index feature von Milvus implementiert wurde.

Best Practices und Tipps

Benchmark mit repräsentativen Abfragen: Testen Sie mit realistischen Abfragemustern, bevor Sie in die Produktion gehen, um zu validieren, dass die Einstellungen min_gram und max_gram dem tatsächlichen Benutzerverhalten entsprechen.
Strategisch mit Vektorsuche kombinieren: Verwenden Sie NGRAM-beschleunigte Filterung als Vorfilter, um die Kandidatenmenge vor der Berechnung der Vektorähnlichkeit zu reduzieren und so die gesamte Abfragelatenz zu verbessern.
Überindexierung vermeiden: Nicht jedes VARCHAR-Feld profitiert von einem NGRAM-Index. Priorisieren Sie Felder, die häufig in LIKE-Abfragen mit Wildcard-Mustern verwendet werden.
Beachten Sie, dass der n-Gramm-Index case-sensitive ist. Das bedeutet, dass Tokens genau so indexiert werden, wie sie im Originaltext erscheinen, wobei Groß- und Kleinschreibung beibehalten werden. Abfragen müssen der exakten Groß-/Kleinschreibung entsprechen, die in den indexierten Inhalten verwendet wird.

Decay Ranker

Stellen Sie sich vor, Sie bauen eine semantische Suchmaschine für Forschungsarbeiten, bei der Sie Arbeiten bevorzugen, die in den letzten 10 Jahren veröffentlicht wurden, gegenüber solchen, die vor mehr als 10 Jahren veröffentlicht wurden.

Ohne den decay ranker von Milvus müssten Sie die Suchergebnisse wahrscheinlich außerhalb der Vektordatenbank basierend auf dem Feld für das Veröffentlichungsjahr neu ranken. Dies erfordert Verarbeitung auf dem Anwendungsserver / Client, was sowohl Komplexität als auch Latenz erhöht und sich negativ auf die Benutzererfahrung auswirken könnte.

Im Zentrum des decay ranker von Milvus steht die Decay Function. Decay Functions passen Relevanzwerte basierend auf numerischen Feldern (wie Zeitstempeln) an. Der endgültige Score wird wie folgt berechnet:

final_score = normalized_similarity_score x decay_score

Derzeit gibt es drei verschiedene decay functions, nämlich: Linear, Exponential und Gaussian. Jede decay function ist für unterschiedliche Szenarien nützlich. Beispielsweise sollte die Linear Function verwendet werden, wenn Sie Entitäten über einen bestimmten Punkt hinaus ausschließen müssen (z. B. Jahre, Entfernung usw.). Die Exponential Function kann verwendet werden, wenn Sie möchten, dass neuere Elemente die Ergebnisse dominieren, ältere Ergebnisse aber dennoch auffindbar bleiben. Die Gaussian Function ist nützlich für standortbasierte Suchen, d. h. Elemente, die näher am aktuellen Standort liegen, werden höher gerankt.

Decay functions sind hochgradig anpassbar, und Sie können ihre Form mithilfe mehrerer Parameter steuern, wenn Sie sie initialisieren:

origin: Referenzpunkt (z. B. aktueller Zeitstempel)
offset: Erstellt eine „No-Decay-Zone“, in der Elemente ihre vollen Scores beibehalten (decay = 1.0). Nützlich, um sicherzustellen, dass sehr aktuelle oder sehr nahe Elemente überhaupt nicht benachteiligt werden.
scale: Größere Werte führen zu einem allmählichen Rückgang der Relevanz; kleinere Werte führen zu einem steileren Rückgang.
decay: Steuert die Steilheit der Kurve. Niedrigere Werte (z. B. 0.3) erzeugen einen steileren Rückgang; höhere Werte (z. B. 0.7) erzeugen einen allmählicheren Rückgang. Der Standardwert ist 0.5.

Hier ist ein Beispiel dafür, wie man die Parameter der Decay-Funktion festlegt:

Um das aktuelle Jahr als Ursprung zu verwenden: origin=2026
Forschungsarbeiten von 2021 bis 2026 sind gleichermaßen relevant, ohne dass Decay angewendet wird: offset=6
Der Score-Multiplikator bei der Scale-Distanz: decay=0.5
Arbeiten aus dem Jahr 2010 sollten einen Decay-Score (zuvor angegeben) von 0.5 haben: scale=16 (da 2026 - 2010 = 16)

Best Practices und Tipps

Führen Sie A/B-Tests für Decay-Konfigurationen durch. Kleine Änderungen an den Parametern scale und decay können die Benutzererfahrung erheblich beeinflussen.
Stellen Sie sicher, dass alle zeitbasierten Parameter (origin, scale, offset) dieselbe Einheit wie Ihre Collection-Daten verwenden.
FunctionScore akzeptiert nur eine einzelne DecayFunction pro Abfrage. Das Verketten oder Kombinieren mehrerer DecayFunctions wird derzeit nicht unterstützt.
Jeder Decay Ranker unterstützt nur ein numerisches Feld. Sie können nicht mehrere Decay-Faktoren in einem einzelnen Ranker kombinieren.
Vermeiden Sie Decay bei dünn besetzten oder verzerrten Feldern. Wenn Ihr Decay-Feld viele Nullwerte, Ausreißer oder stark verzerrte Verteilungen aufweist, kann Decay-Ranking zu unintuitiven Ergebnissen führen.

Boosting

Boosting ist ein praktischer Mechanismus, um Domänensignale in das Ranking der Vektorsuche einzubeziehen. Während die semantische Suche erfasst, worum es in Ihrer Abfrage geht, ignoriert sie häufig, was in einer bestimmten Domäne wichtiger ist. Boosting ermöglicht es Ihnen, Ergebnisse mithilfe beliebiger Metadatenfelder neu zu ranken und so Geschäfts- oder Domänenintuition effektiv in die Retrieval-Schicht zu kodieren.

Beispielsweise können in einem Such-Workflow für Forschungsarbeiten zwei Arbeiten beide für „deep learning“ relevant sein, aber nicht gleich wichtig. Eine häufig zitierte Arbeit kann es verdienen, über einer weniger zitierten zu erscheinen, selbst wenn ihr Ähnlichkeits-Score etwas niedriger ist. Mit Boosting kann eine Arbeit mit einem Ähnlichkeits-Score von 0.79, aber 1.200 Zitierungen, höher gerankt werden als eine Arbeit mit einem Score von 0.81 und nur 10 Zitierungen.

Das Obige kann implementiert werden, indem Arbeiten basierend auf der Anzahl der Zitierungen geboostet werden. Eine einfache Implementierung sieht wie folgt aus:

Aber was, wenn wir Forschungsarbeiten mit Zitierungszahlen zwischen 100 und 1000 boosten und sogar eine Decay-Funktion einbeziehen möchten, um neuere Arbeiten zu bevorzugen? Es stellt sich heraus, dass wir eine Decay-Funktion mit mehreren Boost Rankers in einer einzigen Suchanfrage verketten können, indem wir die FunctionScore class verwenden.

Best Practices und Tipps

FunctionScore wird derzeit nur für die Suche mit dichten Vektoren unterstützt. Hybride Suche unterstützt FunctionScore nicht; verwenden Sie stattdessen einen einzelnen Ranker.
Für Boosting auf Basis kontinuierlich wertiger Felder sollten Sie in Betracht ziehen, die Werte in diskrete Buckets einzuteilen und jedem Bucket eigene Boost-Gewichte zuzuweisen.

Zusammenfassung

Milvus 2.6 stellt einen bedeutenden Fortschritt darin dar, was eine Vektordatenbank von Haus aus leisten kann. Die oben genannten Features und Fähigkeiten, die ich besprochen habe, sind nicht nur Nice-to-haves; sie eliminieren den Glue Code, den Entwickler zuvor außerhalb der Datenbank erstellen und warten mussten.

Anstatt externe Embedding-Pipelines, benutzerdefinierte Reranking-Logik und Workarounds für Substring-Suche zusammenzufügen, können Sie diese nun direkt in Ihren Milvus-Abfragen ausdrücken. Das Ergebnis ist saubererer Anwendungscode, geringere Latenz und weniger bewegliche Teile, die debuggt werden müssen, wenn etwas schiefgeht.

Wenn Sie Milvus bisher „nur“ als Vektorspeicher betrachtet haben, ist es vielleicht an der Zeit, neu zu betrachten, was möglich ist. All diese Features sind jetzt allgemein verfügbar auf Zilliz Cloud, sodass Sie noch heute mit dem Experimentieren beginnen können.

Ressourcen

Aktualisiert am Jul 28, 2026

Ivan Tang
Solutions Architect

Weiterlesen

Zilliz Cloud Now Available in AWS Europe (Ireland)

Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.

Introducing Zilliz MCP Server: Natural Language Access to Your Vector Database

Developers can easily manage and query vector databases with natural language via Zilliz MCP Server in AI-native environments.

Balancing Precision and Performance: How Zilliz Cloud's New Parameters Help You Optimize Vector Search

Optimize vector search with Zilliz Cloud’s level and recall features to tune accuracy, balance performance, and power AI applications.