Home
Blog
Einführung in den Milvus Ngram Index: Schnelleres Keyword Matching und LIKE-Abfragen für Agent Workloads

Einführung in den Milvus Ngram Index: Schnelleres Keyword Matching und LIKE-Abfragen für Agent Workloads

Engineering

December 16, 2025

Chenjie Tang

In Agentensystemen ist die Kontextsuche ein grundlegender Baustein in der gesamten Pipeline, der die Grundlage für nachgelagerte Überlegungen, Planungen und Aktionen bildet. Die Vektorsuche hilft den Agenten, semantisch relevanten Kontext abzurufen, der die Absicht und Bedeutung großer und unstrukturierter Datensätze erfasst. Die semantische Relevanz allein reicht jedoch oft nicht aus. Agenten-Pipelines stützen sich auch auf die Volltextsuche, um exakte Schlüsselwortbeschränkungen durchzusetzen, z. B. Produktnamen, Funktionsaufrufe, Fehlercodes oder rechtlich relevante Begriffe. Diese unterstützende Schicht stellt sicher, dass der abgerufenen Kontext nicht nur relevant ist, sondern auch explizit harte textliche Anforderungen erfüllt.

Reale Arbeitslasten spiegeln diesen Bedarf durchweg wider:

Kundendienstmitarbeiter müssen Gespräche finden, in denen ein bestimmtes Produkt oder eine bestimmte Zutat erwähnt wird.
Coding Copilots suchen nach Snippets, die einen exakten Funktionsnamen, API-Aufruf oder eine Fehlerzeichenfolge enthalten.
Juristische, medizinische und akademische Mitarbeiter filtern Dokumente nach Klauseln oder Zitaten, die wortwörtlich erscheinen müssen.

Traditionell haben die Systeme dies mit dem SQL-Operator LIKE gehandhabt. Eine Abfrage wie name LIKE '%rod%' ist einfach und wird weitgehend unterstützt, aber bei hoher Gleichzeitigkeit und großen Datenmengen geht diese Einfachheit mit erheblichen Leistungseinbußen einher.

Ohne einen Index durchsucht eine LIKE -Abfrage den gesamten Kontextspeicher und wendet den Musterabgleich Zeile für Zeile an. Bei Millionen von Datensätzen kann selbst eine einzige Abfrage Sekunden dauern - viel zu langsam für Agenteninteraktionen in Echtzeit.
Selbst mit einem herkömmlichen invertierten Index lassen sich Platzhaltermuster wie %rod% nur schwer optimieren, da die Engine immer noch das gesamte Wörterbuch durchsuchen und den Musterabgleich auf jeden Eintrag anwenden muss. Der Vorgang vermeidet Zeilenscans, bleibt aber grundsätzlich linear, was nur zu marginalen Verbesserungen führt.

Dies führt zu einer deutlichen Lücke in hybriden Retrievalsystemen: Die Vektorsuche bewältigt die semantische Relevanz effizient, aber die exakte Filterung von Schlüsselwörtern ist oft der langsamste Schritt in der Pipeline.

Milvus unterstützt von Haus aus eine hybride Vektor- und Volltextsuche mit Metadatenfilterung. Um die Grenzen des Keyword-Matching zu überwinden, führt Milvus den Ngram Index ein, der die Leistung von LIKE verbessert, indem er den Text in kleine Teilstrings aufteilt und diese für eine effiziente Suche indiziert. Dadurch wird die Datenmenge, die während der Ausführung der Abfrage untersucht wird, drastisch reduziert, was zu zehn- bis hundertmal schnelleren LIKE Abfragen in echten agentenbasierten Workloads führt.

Im weiteren Verlauf dieses Beitrags wird die Funktionsweise des Ngram-Index in Milvus erläutert und seine Leistung in realen Szenarien evaluiert.

Was ist der Ngram-Index?

In Datenbanken wird die Textfilterung üblicherweise mit SQL ausgedrückt, der Standardabfragesprache, die zum Abrufen und Verwalten von Daten verwendet wird. Einer der am häufigsten verwendeten Textoperatoren ist LIKE, der den musterbasierten String-Matching unterstützt.

LIKE-Ausdrücke lassen sich grob in vier gängige Mustertypen einteilen, je nachdem, wie Platzhalter verwendet werden:

Infix-Abgleich (name LIKE '%rod%'): Passt auf Datensätze, in denen die Teilzeichenkette an beliebiger Stelle im Text vorkommt.
Präfix-Übereinstimmung (name LIKE 'rod%'): Passt auf Datensätze, deren Text mit "rod" beginnt.
Suffix-Abgleich (name LIKE '%rod'): Passt auf Datensätze, deren Text mit "rod" endet.
Platzhalterübereinstimmung (name LIKE '%rod%aab%bc_de'): Kombiniert mehrere Teilstring-Bedingungen (%) mit Ein-Zeichen-Platzhaltern (_) in einem einzigen Muster.

Diese Muster unterscheiden sich zwar in Aussehen und Ausdruckskraft, aber der Ngram-Index in Milvus beschleunigt sie alle mit demselben Ansatz.

Bevor der Index erstellt wird, zerlegt Milvus jeden Textwert in kurze, sich überschneidende Teilstrings fester Länge, die als n-Gramme bezeichnet werden. Wenn zum Beispiel n = 3 ist, wird das Wort "Milvus" in die folgenden 3-Gramme zerlegt: "Mil", "ilv", "lvu", und "vus". Jedes n-Gramm wird dann in einem invertierten Index gespeichert, der die Teilzeichenkette auf die Menge der Dokument-IDs abbildet, in denen sie vorkommt. Bei der Abfrage werden die Bedingungen von LIKE in Kombinationen von N-Gramm-Suchanfragen übersetzt, so dass Milvus die meisten nicht übereinstimmenden Datensätze schnell herausfiltern und das Muster anhand einer viel kleineren Kandidatengruppe bewerten kann. Auf diese Weise werden teure String-Scans in effiziente indexbasierte Abfragen umgewandelt.

Zwei Parameter steuern, wie der Ngram-Index aufgebaut wird: min_gram und max_gram. Zusammen definieren sie den Bereich der Teilstringlängen, die Milvus generiert und indiziert.

min_gram: Die kürzeste Teilstringlänge, die indiziert werden soll. In der Praxis wird damit auch die minimale Abfrage-Teilstringlänge festgelegt, die vom Ngram-Index profitieren kann
max_gram: Die längste zu indizierende Teilstringlänge. Zur Abfragezeit wird zusätzlich die maximale Fenstergröße festgelegt, die bei der Aufteilung längerer Abfragezeichenfolgen in n-Gramme verwendet wird.

Durch die Indizierung aller zusammenhängenden Teilstrings, deren Länge zwischen min_gram und max_gram liegt, schafft Milvus eine konsistente und effiziente Grundlage für die Beschleunigung aller unterstützten LIKE Mustertypen.

Wie funktioniert der Ngram-Index?

Milvus implementiert den Ngram-Index in einem Zwei-Phasen-Prozess:

Bauen Sie den Index auf: Generierung von N-Grammen für jedes Dokument und Aufbau eines invertierten Index während der Datenaufnahme.
Abfragen beschleunigen: Verwenden Sie den Index, um die Suche auf eine kleine Gruppe von Kandidaten einzugrenzen, und überprüfen Sie dann die exakten LIKE Übereinstimmungen mit diesen Kandidaten.

Ein konkretes Beispiel macht diesen Prozess leichter verständlich.

Phase 1: Aufbau des Index

Zerlegen Sie den Text in n-Gramme:

Nehmen wir an, wir indizieren den Text "Apple" mit den folgenden Einstellungen:

min_gram = 2
max_gram = 3

Bei dieser Einstellung generiert Milvus alle zusammenhängenden Teilstrings der Länge 2 und 3:

2-Gramme: Ap, pp, pl, le
3-Gramme: App, ppl, ple

Erstellen Sie einen invertierten Index:

Betrachten wir nun einen kleinen Datensatz von fünf Datensätzen:

Dokument 0: Apple
Dokument 1: Pineapple
Dokument 2: Maple
Dokument 3: Apply
Dokument 4: Snapple

Während der Aufnahme erzeugt Milvus n-Gramme für jeden Datensatz und fügt sie in einen invertierten Index ein. In diesem Index:

Schlüssel sind n-Gramme (Teilstrings)
Werte sind Listen von Dokument-IDs, in denen das n-Gramm vorkommt

"Ap"  -> [0, 3]
"App" -> [0, 3]
"Ma"  -> [2]
"Map" -> [2]
"Pi"  -> [1]
"Pin" -> [1]
"Sn"  -> [4]
"Sna" -> [4]
"ap"  -> [1, 2, 4]
"apl" -> [2]
"app" -> [1, 4]
"ea"  -> [1]
"eap" -> [1]
"in"  -> [1]
"ine" -> [1]
"le"  -> [0, 1, 2, 4]
"ly"  -> [3]
"na"  -> [4]
"nap" -> [4]
"ne"  -> [1]
"nea" -> [1]
"pl"  -> [0, 1, 2, 3, 4]
"ple" -> [0, 1, 2, 4]
"ply" -> [3]
"pp"  -> [0, 1, 3, 4]
"ppl" -> [0, 1, 3, 4]

Jetzt ist der Index vollständig aufgebaut.

Phase 2: Beschleunigung von Abfragen

Wenn ein LIKE Filter ausgeführt wird, verwendet Milvus den Ngram Index, um die Abfrageauswertung durch die folgenden Schritte zu beschleunigen:

1. Extrahieren des Abfragebegriffs: Zusammenhängende Teilstrings ohne Platzhalter werden aus dem Ausdruck LIKE extrahiert (z. B. wird '%apple%' zu apple).

2. Zerlegen des Abfragebegriffs: Der Abfrageterm wird in n-Gramme zerlegt, basierend auf seiner Länge (L) und den konfigurierten min_gram und max_gram.

3. Suche nach jedem Gramm und Überschneidung: Milvus sucht nach n-Grammen im invertierten Index und überschneidet deren Dokument-ID-Listen, um eine kleine Kandidatenmenge zu erzeugen.

4. Überprüfen und Ergebnisse zurückgeben: Die ursprüngliche Bedingung LIKE wird nur auf diese Kandidatenmenge angewendet, um das endgültige Ergebnis zu ermitteln.

In der Praxis hängt die Art und Weise, wie eine Abfrage in n-Gramme aufgeteilt wird, von der Form des Musters selbst ab. Um zu sehen, wie das funktioniert, konzentrieren wir uns auf zwei häufige Fälle: Infix-Treffer und Wildcard-Treffer. Präfix- und Suffixübereinstimmungen verhalten sich genauso wie Infixübereinstimmungen, daher werden wir sie nicht gesondert behandeln.

Infix-Übereinstimmung

Bei einer Infix-Übereinstimmung hängt die Ausführung von der Länge der literalen Teilzeichenkette (L) relativ zu min_gram und max_gram ab.

1. min_gram ≤ L ≤ max_gram (z. B. strField LIKE '%ppl%')

Der literale Teilstring ppl liegt vollständig innerhalb des konfigurierten n-gram-Bereichs. Milvus sucht direkt nach dem n-gram "ppl" im invertierten Index und erzeugt die Kandidaten-Dokument-IDs [0, 1, 3, 4].

Da das Literal selbst ein indiziertes n-Gramm ist, erfüllen alle Kandidaten bereits die Infix-Bedingung. Der letzte Überprüfungsschritt eliminiert keine Datensätze, und das Ergebnis bleibt [0, 1, 3, 4].

2. L > max_gram (z. B. strField LIKE '%pple%')

Die wörtliche Teilzeichenkette pple ist länger als max_gram und wird daher mit einer Fenstergröße von max_gram in überlappende n-Gramme zerlegt. Mit max_gram = 3 ergeben sich die n-Gramme "ppl" und "ple".

Milvus sucht jedes n-gram im invertierten Index:

"ppl" → [0, 1, 3, 4]
"ple" → [0, 1, 2, 4]

Wenn man diese Listen schneidet, erhält man die Kandidatenmenge [0, 1, 4]. Der ursprüngliche Filter LIKE '%pple%' wird dann auf diese Kandidaten angewendet. Alle drei erfüllen die Bedingung, so dass das Endergebnis [0, 1, 4] bleibt.

3. L < min_gram (z. B. strField LIKE '%pp%')

Der literale Teilstring ist kürzer als min_gram und kann daher nicht in indizierte n-Gramme zerlegt werden. In diesem Fall kann der Ngram-Index nicht verwendet werden, und Milvus fällt auf den Standardausführungspfad zurück und wertet die Bedingung LIKE durch einen vollständigen Scan mit Mustervergleich aus.

Platzhalterübereinstimmung (z. B. strField LIKE '%Ap%pple%')

Dieses Muster enthält mehrere Wildcards, so dass Milvus es zunächst in zusammenhängende Literale aufteilt: "Ap" und "pple".

Milvus verarbeitet dann jedes Literal unabhängig:

"Ap" hat die Länge 2 und fällt in den n-gram Bereich.
"pple" ist länger als max_gram und wird in "ppl" und "ple" zerlegt.

Dadurch wird die Abfrage auf die folgenden n-Gramme reduziert:

"Ap" → [0, 3]
"ppl" → [0, 1, 3, 4]
"ple" → [0, 1, 2, 4]

Die Überschneidung dieser Listen ergibt einen einzigen Kandidaten: [0].

Schließlich wird der ursprüngliche Filter LIKE '%Ap%pple%' auf das Dokument 0 ("Apple") angewendet. Da es das vollständige Muster nicht erfüllt, ist die endgültige Ergebnismenge leer.

Beschränkungen und Kompromisse des Ngram-Index

Während der Ngram Index die Leistung von LIKE Abfragen erheblich verbessern kann, bringt er Kompromisse mit sich, die in der Praxis berücksichtigt werden sollten.

Erhöhte Indexgröße

Die primären Kosten des Ngram-Index sind ein höherer Speicher-Overhead. Da der Index alle zusammenhängenden Teilzeichenketten speichert, deren Länge zwischen min_gram und max_gram liegt, wächst die Anzahl der generierten n-Gramme schnell, wenn dieser Bereich erweitert wird. Jede zusätzliche n-Gramm-Länge fügt effektiv einen weiteren vollständigen Satz von überlappenden Teilzeichenketten für jeden Textwert hinzu, wodurch sowohl die Anzahl der Indexschlüssel als auch deren Buchungslisten steigen. In der Praxis kann die Erweiterung des Bereichs um nur ein Zeichen die Indexgröße im Vergleich zu einem standardmäßigen invertierten Index ungefähr verdoppeln.

Nicht für alle Workloads effektiv

Der Ngram Index beschleunigt nicht jede Arbeitslast. Wenn die Abfragemuster sehr unregelmäßig sind, sehr kurze Literale enthalten oder der Datensatz in der Filterphase nicht auf eine kleine Kandidatenmenge reduziert werden kann, ist der Leistungsvorteil möglicherweise begrenzt. In solchen Fällen kann sich die Ausführung der Abfrage immer noch den Kosten eines vollständigen Scans nähern, auch wenn der Index vorhanden ist.

Bewertung der Leistung von Ngram-Indizes bei LIKE-Abfragen

Das Ziel dieses Benchmarks ist es, zu bewerten, wie effektiv der Ngram Index LIKE Abfragen in der Praxis beschleunigt.

Test-Methodik

Um die Leistung im Kontext zu sehen, vergleichen wir ihn mit zwei grundlegenden Ausführungsmodi:

Master: Brute-Force-Ausführung ohne jeglichen Index.
Master-invertiert: Ausführung mit einem herkömmlichen invertierten Index.

Wir haben zwei Testszenarien entwickelt, um unterschiedliche Datenmerkmale abzudecken:

Wiki-Text-Datensatz: 100.000 Zeilen, wobei jedes Textfeld auf 1 KB abgeschnitten wurde.
Ein-Wort-Datensatz: 1.000.000 Zeilen, wobei jede Zeile ein einzelnes Wort enthält.

In beiden Szenarien werden die folgenden Einstellungen einheitlich angewendet:

Die Abfragen verwenden das Infix-Match-Muster (%xxx%)
Der Ngram Index ist mit min_gram = 2 konfiguriert und max_gram = 4
Um die Kosten für die Abfrageausführung zu isolieren und den Overhead bei der Ergebnismaterialisierung zu vermeiden, geben alle Abfragen count(*) anstelle von vollständigen Ergebnismengen zurück.

Ergebnisse

Test für Wiki, jede Zeile ist ein Wiki-Text mit einer um 1000 gekürzten Inhaltslänge, 100K Zeilen

	Wörtlich	Zeit(ms)	Beschleunigung	Anzahl
Master	Stadion	207.8		335
Master-umgekehrt		2095		335
Ngramm		1.09	190 / 1922	335

Meister	Sekundarschule	204.8		340
Meister-umgekehrt		2000		340
Ngramm		1.26	162.5 / 1587	340

Meister	ist eine koedukative Sekundarschule, die gefördert wird	223.9		1
Master-umgekehrt		2100		1
Ngramm		1.69	132.5 / 1242.6	1

Test für einzelne Wörter, 1M Zeilen

	Wörtlich	Zeit(ms)	Beschleunigung	Anzahl
Master	na	128.6		40430
Master-umgekehrt		66.5		40430
Ngramm		1.38	93.2 / 48.2	40430

Master	nat	122		5200
Master-umgekehrt		65.1		5200
Ngramm		1.27	96 / 51.3	5200

Meister	nati	118.8		1630
Master-invertiert		66.9		1630
Ngramm		1.21	98.2 / 55.3	1630

Master	natio	118.4		1100
Master-umgekehrt		65.1		1100
Ngramm		1.33	89 / 48.9	1100

Meister	Nation	118		1100
Meister-umgekehrt		63.3		1100
Ngramm		1.4	84.3 / 45.2	1100

Hinweis: Diese Ergebnisse beruhen auf Benchmarks, die im Mai durchgeführt wurden. Seitdem hat der Master-Zweig zusätzliche Leistungsoptimierungen erfahren, so dass der hier beobachtete Leistungsunterschied in aktuellen Versionen voraussichtlich geringer ausfallen wird.

Die Benchmark-Ergebnisse zeigen ein klares Muster: Der Ngram-Index beschleunigt LIKE-Abfragen in allen Fällen erheblich, und wie viel schneller die Abfragen laufen, hängt stark von der Struktur und Länge der zugrunde liegenden Textdaten ab.

Bei langen Textfeldern, wie z.B. bei Wiki-Dokumenten, die auf 1.000 Bytes gekürzt wurden, sind die Leistungsgewinne besonders ausgeprägt. Im Vergleich zur Brute-Force-Ausführung ohne Index erreicht der Ngram-Index Geschwindigkeitssteigerungen von etwa 100-200×. Im Vergleich zu einem herkömmlichen invertierten Index ist die Verbesserung sogar noch dramatischer und erreicht das 1.200-1.900-fache. Dies liegt daran, dass LIKE-Abfragen auf langem Text für herkömmliche Indexierungsansätze besonders teuer sind, während N-Gramm-Lookups den Suchraum schnell auf eine sehr kleine Menge von Kandidaten eingrenzen können.
Bei Datensätzen, die aus Ein-Wort-Einträgen bestehen, sind die Gewinne zwar geringer, aber immer noch beträchtlich. In diesem Szenario läuft der Ngram-Index etwa 80 bis 100 Mal schneller als die Brute-Force-Ausführung und 45 bis 55 Mal schneller als ein herkömmlicher invertierter Index. Obwohl kürzerer Text von Natur aus billiger zu scannen ist, vermeidet der N-Gramm-basierte Ansatz dennoch unnötige Vergleiche und reduziert konsequent die Abfragekosten.

Schlussfolgerung

Der Ngram Index beschleunigt LIKE Abfragen, indem er den Text in n-Gramme fester Länge aufteilt und sie mit einer invertierten Struktur indiziert. Dieses Design verwandelt teure Teilstring-Abgleiche in effiziente n-Gramm-Suchvorgänge, gefolgt von einer minimalen Überprüfung. Dadurch werden Volltextscans vermieden, während die genaue Semantik von LIKE erhalten bleibt.

In der Praxis erweist sich dieser Ansatz in einem breiten Spektrum von Arbeitslasten als effektiv, mit besonders guten Ergebnissen beim Fuzzy-Matching in langen Textfeldern. Der Ngram-Index eignet sich daher gut für Echtzeitszenarien wie die Suche nach Codes, Kundendienstmitarbeiter, juristische und medizinische Dokumente, Wissensdatenbanken in Unternehmen und die akademische Suche, bei denen ein präziser Abgleich von Schlüsselwörtern unerlässlich ist.

Zugleich profitiert der Ngram Index von einer sorgfältigen Konfiguration. Die Auswahl geeigneter Werte für min_gram und max_gram ist entscheidend für das Gleichgewicht zwischen Indexgröße und Abfrageleistung. Wenn der Ngram Index so eingestellt wird, dass er reale Abfragemuster widerspiegelt, bietet er eine praktische, skalierbare Lösung für leistungsstarke LIKE Abfragen in Produktionssystemen.

Weitere Informationen über den Ngram-Index finden Sie in der folgenden Dokumentation:

Ngram Index | Milvus Dokumentation

Haben Sie Fragen oder möchten Sie einen tieferen Einblick in eine Funktion des neuesten Milvus? Treten Sie unserem Discord-Kanal bei oder melden Sie Probleme auf GitHub. Sie können auch eine 20-minütige Einzelsitzung buchen, um Einblicke, Anleitung und Antworten auf Ihre Fragen in den Milvus Office Hours zu erhalten.

Erfahren Sie mehr über die Funktionen von Milvus 2.6

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started

Like the article? Spread the word