Wie MATCH und TO_TEXT die Volltextsuche in beliebigen ES|QL-Ausdrücken ermöglichen

Beginnen wir mit einer Abfrage, die in Elasticsearch 9.4 unmöglich war und den EVAL-Befehl verwendet:

In diesem Beispiel hat Summary keine Mapping- oder Analyzer-Konfiguration. Es ist auch mit keinem invertierten Index verbunden. Es existiert nur für die Dauer dieser Abfrage, kann jetzt aber trotzdem durchsucht werden. Das machen zwei Ergänzungen möglich.

Erstens akzeptiert MATCH nun jeden Ausdruck als erstes Argument, nicht nur ein abgebildetes Feld. Dies umfasst Spalten, die von EVAL erzeugt werden, sowie Funktionsergebnisse, die inline verwendet werden. Es enthält auch nicht zugeordnete Felder, die direkt aus dem Originaldokument geladen wurden. Darüber hinaus werden in diesem neuen Anwendungsfall alle normalerweise von MATCH akzeptierten Datentypen unterstützt.

Der zweite Teil davon ist die neue TO_TEXT-Funktion, die die erste ES|QL-Konvertierungsfunktion ist, die eine Ausgabe vom Typ Text erzeugt. Bisher konnten Textspalten nur aus indizierten zugeordneten Feldern stammen, und alle von ES|QL-Ausdrücken erzeugten Zeichenfolgen waren Schlüsselwortwerte statt Textwerte. Die Unterscheidung ist wichtig, weil MATCH die beiden unterschiedlich behandelt: Textwerte werden analysiert, während Keyword-Werte exakt verglichen werden, was der Umschreibung einer MATCH-Abfrage auf einem indexierten Schlüsselwortfeld in eine Termanfrage ähnelt. TO_TEXT(x) ist die Art, wie Siew ES|QL Folgendes sagen: Behandle diese Zeichenfolge als Volltext.

Dies wird als technische Vorschau in Elasticsearch 9.5 ausgeliefert und hat daher einige Einschränkungen:

• Es wird derzeit nur gefiltert. Ein MATCH-Ergebnis in einem Ausdruck trägt noch nicht zur Relevanzbewertung bei; nur Übereinstimmungen in indizierten Feldern wirken sich auf die Bewertung aus.

• Abfrageoptionen wie Unschärfe und andere werden beim Abgleich eines Ausdrucks noch nicht unterstützt.

• Der Laufzeittext wird mit dem Standard-Analyzer analysiert. Dies ist noch nicht konfigurierbar.

Es wird daran gearbeitet, diese Einschränkungen zu beheben.

Warum sollte man in ES|QL Volltextsuche statt LIKE oder RLIKE verwenden?

ES|QL hatte bereits zwei Möglichkeiten, Zeichenfolgen ohne Index zu suchen: LIKE (Wildcard-Muster) und RLIKE (reguläre Ausdrücke). Beide funktionieren bei jedem Zeichenfolge-Ausdruck, daher ist es fair zu fragen, was MATCH hinzufügt. Die Antwort ist analysis, eine fortgeschrittenere Suchmethode, die Techniken wie Stemming und Synonyme verwendet. Es verwendet auch eine Stoppwortbehandlung.

LIKE ist einfaches Substring-Matching, ohne jegliches Verständnis der Wörter, aus denen eine Zeichenfolge besteht. Nehmen wir beispielsweise an, Sie suchen nach Log-Meldungen über einen Fuchs:

„Fuchs in der Nähe des Hühnerstalls gesichtet“ wird aufgrund der Großschreibung nicht gefunden, während es „Von der Konkurrenz überlistet“ ein Treffer ist, obwohl das überhaupt nichts mit einem Fuchs zu tun hat. Das Verfahren versagt in beiden Richtungen: Es kommt zu falschen Negativbefunden bei der Großschreibung und zu falschen Positivbefunden bei innerhalb anderer Wörter verborgenen Teilzeichenfolgen.

Reguläre Ausdrücke können das Problem der Groß-/Kleinschreibung beheben, aber das Problem der Wortgrenzen wird schnell unübersichtlich. Hier ist ein Beispiel:

Und selbst das stimmt noch nicht. Der Fuchs am Ende eines Satzes, gefolgt von ! oder ?, ist ihm entgangen und es sagt nichts über Tabulatoren, Anführungszeichen oder Klammern aus. Mit jeder Korrektur wird das Muster länger, und die nächste Person, die die Abfrage liest, muss nachvollziehen, was das eigentlich passiert.

MATCH beseitigt das Problem, weil sowohl die Abfrage als auch der Wert durch einen Analyzer laufen, der den Text in Kleinbuchstaben tokenisiert und dann Term für Term abgleicht:

Diese Abfrage passt zu Werten wie „Der schnelle braune Fuchs“ und „FUCHS in der Nähe des Hühnerstalls gesehen“, aber nicht „Von der Konkurrenz überlistet“ oder „FOXTROT-Protokoll aktiviert“, unabhängig von jeglicher Zeichensetzung um die Wörter. Selbstverständlich funktioniert das alles auch für Abfragen mit mehreren Begriffen, wie z. B. MATCH(TO_TEXT(message), „brauner Fuchs“), genau so, wie man es erwarten würde.

Es wird daran gearbeitet, die Nutzung der 36 dedizierten Sprachanalysatoren zu ermöglichen, mit Unterstützung für natürliche Sprachen auf Daten, die nie indexiert oder kartiert wurden.

Anwendungsfälle der Volltextsuche für unindexierte und nicht abgebildete Daten

Die obigen Beispiele suchten Werte, die aus abgebildeten Feldern berechnet wurden. Die interessantesten Anwendungsfälle für ES|QL MATCH bei Ausdrücken betreffen Daten, die zuvor überhaupt nicht durchsuchbar waren. Schauen wir uns einige Beispiele an.

Wie kann man in ES|QL nach nicht zugeordneten Feldern suchen, ohne ein Mapping hinzuzufügen?

Manchmal lässt man absichtlich ein Feld aus den Mappings weg, wie zum Beispiel eine ausführliche Stack-Trace oder eine rohe Anfrage-Nutzlast. Du könntest sogar einen Debug-Blob weglassen. Das Indexieren eines dieser Felder würde Speicherplatz auf der Festplatte und im Heap-Speicher des Dokuments beanspruchen und wäre für ein Feld, das man möglicherweise nur einmal pro Quartal abfragt, nicht lohnenswert.

Diese Entscheidung war immer endgültig, weil nicht zugeordnete Felder für Abfragen völlig unsichtbar waren. In Elasticsearch 9.5 können Sie mit SET unmapped_fields="load" bewirken, dass ES|QL nicht zugeordnete Felder direkt aus dem Quelldokument als Schlüsselwörter lädt. Anschließend wird der Ausdruck in TO_TEXT eingeschlossen, und nun können Sie eine Volltextsuche darauf ausführen:

Hier wurde stack_trace nie zugeordnet. Jeder Wert wird aus den Originaldokumenten abgerufen und direkt analysiert. Sie werden zeilenweise einander zugeordnet. Das ist echte Arbeit und wird niemals so schnell sein wie eine invertierte Index-Suche. Aber jetzt ist das Feld, das Sie nicht indexiert haben, nicht mehr undurchsuchbar. Sie können das Mapping für den Alltag klein halten und trotzdem die einmal im Quartal anstehende Frage beantworten, wenn es darauf ankommt.

Volltextsuche in einem Stichwortfeld ohne Neuindizierung

Keyword-Felder können vieles bewirken. Sie liefern exakte Abgleiche, schnelle Aggregationen und Sortierung, weshalb so viele Felder auf diese Weise zugeordnet werden. Die Mappings der Daten erfolgen jedoch erst, wenn sie eintreffen, und es kann leicht passieren, dass man am Ende etwas anderes mit den Daten machen möchte, als man ursprünglich beabsichtigt hatte. Vielleicht wurde „product_name“ als Keyword zugeordnet, weil die Dashboards darauf aggregieren, und nachdem ein Jahr Produktdaten eingegangen ist, möchte jemand innerhalb der Werte von „product_name“ suchen können.

Die alte Antwort war, das Mapping auf Text zu ändern (oder ein Multi-Feld hinzuzufügen) und alles neu zu indexieren. Das kann sowohl zeitaufwändig als auch kostspielig sein, und in vielen Fällen wollen sich die Nutzer einfach nicht darum kümmern. Die neue Antwort ist ein Funktionsaufruf:

TO_TEXT wandelt die Keyword-Werte spontan in Text um; daher analysiert MATCH sie, anstatt sie exakt zu vergleichen. So können Sie ein Schlüsselwort-Feld abfragen, ohne ein Mapping erstellen oder das Quelldokument neu zu indexieren. Wenn die Suche zu einer alltäglichen Anfrage wird, ist das Indizieren des Feldes als Text zwar immer noch der richtige langfristige Schritt, aber mit TO_TEXT erhalten Sie heute schon eine Antwort, ohne zusätzlichen Aufwand.

Das gleiche Feld in Indizes mit unterschiedlichen Mappings durchsuchen

ES|QL kann viele Indizes umfassen, und dasselbe Feld muss nicht immer in allen gleich aussehen. Wenn dasselbe Feld unterschiedliche Typen in verschiedenen Indizes hat, behandelt ES|QL es als Unionstyp, und eine Konvertierungsfunktion löst den Konflikt. Betrachten wir ein Beispiel, in dem das Message-Feld in der diesjährigen Indexvorlage den Typ „Text“ hat, in der letztjährigen Vorlage aber ein Keyword war:

Jeder Wert wird zur Abfragezeit analysiert, unabhängig davon, ob er aus dem Textindex oder dem Stichwortindex stammt. Die Keywordwerte aus den älteren Indizes werden wie alles andere tokenisiert und kleingeschrieben, sodass „connection reset“ unabhängig davon, in welchem Index es sich befindet, „Connection RESET by peer“ findet.

Ein weiterer interessanter Fall ist, wenn ein Feld nur in einem Index abgebildet wird, aber auch im anderen vorhanden (und nicht abgebildet):

Es gibt eine Nuance, die es wert ist, hier erwähnt zu werden. Wenn error_details in logs-2026, aber nicht in logs-2025 abgebildet ist, kann Elasticsearch diese Abfrage nicht auf Lucene verschieben, da die Indizes, in denen das Feld nicht abgebildet ist, stillschweigend keine Übereinstimmungen liefern würden. Stattdessen stellt der Planer fest, dass das Feld möglicherweise nicht zugeordnet ist und wertet die gesamte MATCH Zeile für Zeile aus, unabhängig davon, woher die Zeilen stammen. Sie müssen nicht wissen, in welchem Ihrer Indizes das Feld zugeordnet ist; die Abfrage beantwortet einfach die Frage.

Wie ES|QL Text zur Abfragezeit ohne invertierten Index analysiert

Wenn ES|QL einen MATCH-Abgleich mit einem Ausdruck plant, analysiert es die Abfragezeichenfolge einmalig, im Voraus, in eine Reihe von Begriffen. Wie jede Zeile anschließend ausgewertet wird, hängt vom Typ des Ausdrucks ab:

Ausdruckstyp

Verarbeitung

Übereinstimmendes Verhalten

Text (über TO_TEXT)

Analyzer tokenisiert Werte in Kleinbuchstaben

Token-gegen-Token-Vergleich; eine Zeile gilt als Treffer, wenn ein Token einem Abfrageterm entspricht (ODER-Semantik)

Schlüsselwort, IP, Datum, numerisch

Keine Analyse; die Abfragekonstante einmal in den nativen Typ konvertiert

Exakter Vergleich pro Zeile

Beide Wege umgehen Lucene vollständig und bewerten Werte Zeile für Zeile. Der Nichttextpfad spiegelt genau das wider, was eine Match-Query tut, wenn sie an Lucene für diese Feldtypen delegiert wird, sodass die Semantik unabhängig davon konsistent bleibt, ob die Abfrage einen Index trifft.

Eine Suche mit invertiertem Index führt ihre Arbeit zur Ingest-Zeit durch und greift bei der Abfrage niemals auf nicht übereinstimmende Dokumente zu. Ein Laufzeit-Match führt diese Analyse zur Abfragezeit für jede Zeile durch, die sie erreicht. Die eine Methode ist schnell, weil die Arbeit bereits erledigt ist; die andere ist flexibel, weil die Daten überhaupt nicht indexiert werden müssen.

Was kommt als Nächstes für die ES|QL-Volltextsuche

Alles in diesem Beitrag ist der erste Teil eines größeren Vorhabens, die Suche in ES|QL auf alles anzuwenden, nicht nur auf das, was man vorher indexiert hat. Die zuvor genannten Einschränkungen werden aktiv bearbeitet und die Roadmap geht weiter:

• Bewertung. Runtime-Matches tragen zu _score bei, sodass Sie nach Relevanz sortieren können, auch wenn die Daten nie indexiert wurden.

• MATCH_PHRASE auf Ausdrücke. Bereits in Elastic Cloud Serverless verfügbar, und kommt im Elastic Stack in Version 9.6.

• Konfigurierbare Analysatoren. Analyzer-Unterstützung für MATCH und MATCH_PHRASE bei Ausdrücken, die Language Analyzer, Stemming und Synonyme zur Abfragezeit ermöglichen.

• Matchoptionen. Optionen wie Unschärfe und Operator für Laufzeitübereinstimmungen.

• Vektorsuche. Generieren von Einbettungen pro Zeile und Ausführen der k-Nearest-Neighbor-Methode (kNN) auf Laufzeit-dense_vector-Ausdrücken, wodurch die semantische Suche auch auf unindizierte Daten ausgeweitet wird.

Probieren Sie noch heute die ES|QL-Volltextsuche für Ausdrücke aus.

Sie können die Laufzeitsuche noch heute ausprobieren. Es ist jetzt in Elastic Cloud Serverless verfügbar, wo neue ES|QL-Fähigkeiten zuerst erscheinen und als technische Vorschau in Elasticsearch 9.5 ausgeliefert werden. Beginnen Sie mit der Suchfunktionsreferenz und prüfen Sie die ES|QL-Einschränkungsseite für die aktuellen Grenzen. Es ist eine technische Vorschau, weil wir Ihr Feedback wollen: Wenn Sie nach etwas suchen, das nie indexiert wurde, und überrascht, sei es positiv oder negativ, würden wir gerne davon hören.

1. Verwendung der _mapping -API zum Abrufen von Feldinformationen

2. Verwendung der _search API zum Anzeigen von Feldwerten

3. Unterfelder anzeigen

4. Synthetisches Feld „_source“

5. Laufzeitfelder

1. Verwendung der _mapping-API zum Abrufen von Feldinformationen

Die _mapping API ermöglicht es Ihnen, die Mapping-Definition für einen oder mehrere Indizes abzurufen. Dies umfasst Informationen über die Felder, ihre Datentypen und weitere Eigenschaften. Um die Zuordnung für einen bestimmten Index abzurufen, verwenden Sie die folgende Anfrage:

Wenn Sie beispielsweise einen Index mit dem Namen my_index haben, können Sie dessen Zuordnung mit der folgenden Anfrage abrufen:

Die Antwort enthält die Mapping-Definition für den Index, die Informationen über die Felder und deren Eigenschaften enthält.

Es ist auch möglich, die Zuordnung eines bestimmten Feldes abzurufen. Dies kann nützlich sein, wenn Ihre Kartierung recht umfangreich ist und Sie sich nur auf ein bestimmtes Feld konzentrieren möchten. Um die Zuordnung eines bestimmten Feldes abzurufen, verwenden Sie die folgende Anfrage:

Sie können die Zuordnungen mehrerer Felder auch abrufen, indem Sie deren Namen durch Kommas trennen, wie in der folgenden Anfrage:

2. Verwenden der _search-API zum Anzeigen von Feldwerten

Um die Werte von Feldern in einem Elasticsearch-Index anzuzeigen, können Sie die _search API verwenden. Die _search API bietet Ihnen mehrere Möglichkeiten, die zurückgegebenen Felder zu steuern; die beiden wichtigsten sind:

1. _sourceDas Feld _source enthält den ursprünglichen JSON-Dokumentkörper genau so, wie er indexiert wurde, einschließlich aller Änderungen, die durch Ingestionspipelines oder Vorverarbeitungsschritte vorgenommen wurden. Um bestimmte Felder aus dem Quelldokument anzuzeigen, implementieren Sie eine Quellfilterung, wie wir im Folgenden sehen werden.

2. fieldsMit dem Parameter fields können Sie beim Durchführen einer Suche bestimmte Felder aus Ihren Dokumenten auf Basis der Indexzuordnung abrufen. Im Gegensatz zu _source kann fields auch Werte aus gespeicherten Feldern, Dokumentwerten oder Laufzeitfeldern zurückgeben, ohne auf _source zu verweisen. Für Standardfelder ohne Dokumentwerte oder gespeicherte Einstellungen wird jedoch auf _source zurückgegriffen. Dies kann viele Vorteile mit sich bringen, wie zum Beispiel eine höhere Leistungsfähigkeit und mehr, wie wir im Folgenden sehen werden.

Verwendung des Feldes _source

Standardmäßig gibt die _search -API das Feld _source zurück, welches das ursprüngliche, indizierte JSON-Dokument enthält. Um bestimmte Felder anzuzeigen, können Sie Filter im Parameter _source der Suchanfrage hinzufügen; dies wird als Quellfilterung bezeichnet.

Hier ist ein Beispiel für eine Suchanfrage, die die Werte der Felder title und author für Dokumente im Index my_index zurückgibt:

In diesem Beispiel gibt der Parameter _source die zurückzugebenden Felder an.

Falls Sie noch mehr Kontrolle benötigen, können Sie die Eigenschaften includes und excludes des Objekts _source verwenden. Beispielsweise gibt die folgende Abfrage das Feld der obersten Ebene title und alle Unterfelder von author außer author.description zurück.

In diesem Beispiel verwenden wir das Muster author.* , um jedes direkte Unterfeld des Objekts author abzurufen. Dann schließen wir author.description explizit aus, sodass nur die übrigen Autorenfelder zurückgegeben werden. Beachten Sie, dass dies keine Leistungsverbesserungen mit sich bringt, da das Quell-JSON weiterhin geladen und analysiert werden muss, aber es kann die Größe der über das Netzwerk gesendeten Antwort verringern.

Verwendung des Parameters „fields“

Mit dem Parameter fields können Sie die in der Suchergebnisseinduktion zurückgegebenen Felder filtern. Die Verwendung fields anstelle von _source bietet mehrere Vorteile, darunter:

• Verbesserte Performance: fields kann Werte direkt aus gespeicherten Feldern oder Dokumentwerten zurückgeben, ohne die vollständige _source laden zu müssen, wodurch die Größe der Antwortnutzlast kleiner wird.

• Formatierte Ausgabe: Bei Standardfeldern kann fields auf _source zurückgreifen, um die Werte zu erfassen. Dabei wird jedoch die Indexzuordnung herangezogen, um die Ausgabe korrekt zu formatieren, z. B. formatierte Datumsangaben, sodass sie mit den für Aggregationen und Sortierungen verwendeten Formaten konsistent sind.

• Zugriff auf Laufzeitfelder: fields kann Laufzeitfelder zurückgeben, die im ursprünglichen _source nicht existieren.

• Weitere Vorteile finden Sie hier.

Um beispielsweise nur die Felder title und author im Index my_index zurückzugeben, können Sie die folgende Suchanfrage verwenden:

In der obigen Abfrage setzen wir das Feld _source auf false, damit wir das Quelldokument nicht zurückgeben. Dadurch kann die Nutzlastgröße der Antwort drastisch reduziert werden. Beachten Sie jedoch, dass dies nur funktioniert, weil die Felder title und author vom Feldtyp keyword sind, bei dem standardmäßig doc_values aktiviert ist. Wenn das Feld doc_values nicht aktiviert hat und _source auf false gesetzt ist, hat Elasticsearch keine Möglichkeit, diese abzurufen, und sie werden in der Antwort übersprungen.

Wichtig zu beachten ist, dass die fields -Antwort immer ein Array von Werten für jedes Feld zurückgibt, selbst wenn es nur einen einzigen Wert gibt. Dies liegt daran, dass Elasticsearch keinen dedizierten Array-Typ besitzt und jedes Feld mehrere Werte haben kann. Für weitere Informationen zu Arrays in Elasticsearch klicken Sie hier.

Weitere Möglichkeiten zum Abrufen von Feldern

Obwohl das Abrufen von Feldern mit _source oder fields die empfohlenen Methoden sind, stehen für bestimmte Anwendungsfälle verschiedene Methoden zur Verfügung, wie zum Beispiel:

Doc-Wertfelder: Wenn Sie _source komplett vermeiden möchten, können Sie mit dem Parameter docvalue_fieldssuchen. Doc-Werte speichern die gleichen Feldwerte wie _source , jedoch in einer auf der Festplatte gespeicherten Datenstruktur, die für Sortierung und Aggregation optimiert ist.

Da es sich um separate Werte handelt, die nicht mit _source gespeichert sind, können Sie bestimmte Felder anfordern, ohne das gesamte _source zu laden. Dies ist nützlich, wenn Sie große Dokumente abfragen, aber nur wenige kleine Felder benötigen, die Dokumentwerte unterstützen. Ein weiterer Anwendungsfall für docvalue_fields besteht darin, dass Sie eine benutzerdefinierte Formatierung für die Felder date und numeric verwenden möchten, wie wir im folgenden Beispiel sehen werden.

Beachten Sie, dass dies nur für Felder funktioniert, für die Sie doc_values aktivieren, oder für Feldtypen, bei denen dies standardmäßig aktiviert ist, wie z. B. keyword, date, numerische Typen und boolean, nicht für text oder annotated_text.

In diesem Beispiel verwenden wir den Parameter docvalue_fields , um die Felder title, author und published abzurufen, ohne das vollständige Dokument _source zu laden:

Wenn diese Abfrage ausgeführt wird, greift Elasticsearch direkt auf die Werte in seinem spaltenorientierten Speicher auf der Festplatte zu, anstatt für jedes Dokument auf _source zu verweisen. Das Feld published wird dank des in der Abfrage angegebenen Parameters format im Format epoch_millis anstatt im Standardformat zurückgegeben.

Gespeicherte Felder: Wenn Sie in der Zuordnung explizit bestimmte Felder als gespeichert markiert haben, können Sie mit dem Parameter stored_fields nach diesen Feldern filtern. Dies ist nützlich, wenn Sie kurze Antworten nur mit diesen spezifischen Feldern wünschen oder Felder, die Sie absichtlich zum späteren Abruf gespeichert haben. Es wird separat von _source gespeichert, daher ist diese Methode auch nützlich, um das Laden von _source zu vermeiden.

Wichtig zu beachten ist, dass diese Option standardmäßig deaktiviert und generell nicht empfehlenswert ist. Verwenden Sie stattdessen Quellfilter, um bestimmte Teilmengen des ursprünglichen Quelldokuments zurückzugeben.

In der folgenden Beispielabfrage verwenden wir den Parameter stored_fields , um das Feld summary abzurufen, das die Indexzuordnungskonfiguration ”store”: true hat.

Wenn diese Abfrage ausgeführt wird, prüft Elasticsearch, ob dieses Feld mit ”store”: true markiert wurde. Falls dies nicht der Fall ist, wird das Feld vollständig übersprungen.

3. Unterfelder anzeigen

Wenn Ihr Index Unterfelder enthält, können Sie die Punktnotation verwenden, um den Feldpfad im Parameter fields anzugeben. Beachten Sie, dass Unterfelder sich vom verschachtelten Feldtyp unterscheiden. Wenn Sie beispielsweise ein Unterfeld mit dem Namen address.city haben, können Sie es wie folgt in die Suchergebnisseinlösung einbinden:

In diesem Beispiel enthält die Suchergebnisseinsendung die Werte der Felder title, author und address.city .

4. Synthetische Quelle

Wenn Sie die Funktionalität der Verwendung von _source beibehalten, aber gleichzeitig Speicherplatz sparen möchten, haben Sie die Möglichkeit, in Ihrer Indexzuordnung synthetisches _source zu verwenden. Die Funktion Synthetic _source ermöglicht es Elasticsearch, die _source aus vorhandenen Daten wie gespeicherten Feldern und Dokumentwerten zu rekonstruieren, selbst wenn _source deaktiviert ist. Dadurch lässt sich viel Speicherplatz sparen, allerdings auf Kosten etwas geringerer Abfragegeschwindigkeiten, da die Rekonstruktion in Echtzeit erfolgt. Aktivieren Sie diese Funktion, indem Sie die folgenden Werte in Ihren Indexeinstellungen verwenden:

Zu den Vorteilen der Verwendung von synthetischem _source gehören: vollständige Dokumentanzeige bei Verwendung der _search API, Quellfilterung und Kompatibilität mit anderen Funktionen und Tools wie Kibana, die die Verfügbarkeit _source voraussetzen, und das alles, ohne dass das vollständige _source Dokument gespeichert werden muss.

5. Laufzeitfelder

Mit Laufzeitfeldern können Sie skriptgesteuerte Felder zur Abfragezeit oder in Ihrer Indexzuordnung unter einem Laufzeitblock definieren. Diese Felder werden nie indiziert, daher erhöht das Hinzufügen eines Laufzeitfelds nicht die Indexgröße, es wird aber niemals in _source angezeigt. Die in der Zuordnung definierten Laufzeitfelder sind persistent und für alle Abfragen verfügbar, während die zur Abfragezeit definierten Laufzeitfelder temporär sind und nur in dieser Suchanfrage verfügbar sind.

Der Hauptvorteil der Verwendung von Laufzeitfeldern besteht darin, dass man Felder zu Dokumenten hinzufügen kann, nachdem man sie bereits importiert hat, was die Zuordnungsentscheidungen vereinfacht. Laufzeitfelder eignen sich auch hervorragend, um Ihre Dokumente mit Werten anzureichern, die im Originaldokument nicht vorhanden sind, sondern mithilfe eines Skripts generiert werden, z. B. durch Formatieren einer Zeichenkette oder Berechnen einer Punktzahl.

Es ist außerdem zu beachten, dass Laufzeitfelder die Leistung beeinträchtigen können, da für jedes Dokument im Ergebnissatz ein Skript ausgeführt werden muss. Um ein Laufzeitfeld abzurufen, können Sie auch den Parameter fields der API _search verwenden.

Fazit

Die Anzeige von Feldern eines Elasticsearch-Index kann von der einfachen Abfrage von Werten mithilfe der Indexzuordnung oder _source bis hin zu fortgeschritteneren Methoden mit fields, docvalue_fields oder Laufzeitfeldern für mehr Kontrolle und Effizienz reichen. Das Verständnis der Vor- und Nachteile verschiedener Methoden ist der Schlüssel zur Optimierung Ihrer Sucherfahrung. Egal ob Sie Nutzdaten optimieren, Dokumente anreichern oder synthetische Daten _source verwenden, um Speicherplatz zu sparen, Elasticsearch bietet Ihnen zahlreiche Tools und Funktionen, um die benötigten Daten so zu finden, wie Sie sie benötigen. Mithilfe dieser Techniken können Sie die Struktur Ihrer Daten verstehen, bestimmte Felder identifizieren und Probleme beheben.

In diesem Artikel werden wir diese Feldtypen, ihre jeweiligen Anwendungsbereiche und ihren Zusammenhang mit Strategien zur Einbettungsgenerierung und -nutzung sowohl bei der Indizierung als auch bei der Abfrage besprechen.

Dichter Vektortyp

Der Feldtyp dense_vector in Elasticsearch dient zur Speicherung dichter Vektoren, die numerische Darstellungen von Daten wie Text, Bildern und Audio darstellen, wobei nahezu alle Dimensionen relevant sind. Diese Vektoren werden mithilfe von Einbettungsmodellen generiert, die von Plattformen wie OpenAI, Cohere oder Hugging Face bereitgestellt werden, und sind so konzipiert, dass sie die Gesamtsemantik der Daten erfassen, auch wenn diese keine exakten Begriffe mit anderen Dokumenten teilen.

In Elasticsearch können dichte Vektoren je nach verwendetem Modell bis zu 4096 Dimensionen haben. Das Modell all-MiniLM-L6-v2 erzeugt beispielsweise Vektoren mit 384 Dimensionen, während das Modell text-embedding-ada-002 von OpenAI Vektoren mit 1536 Dimensionen erzeugt.

Das Feld dense_vector wird üblicherweise als Standardtyp für die Speicherung dieser Art von Einbettungen verwendet, wenn eine größere Kontrolle erforderlich ist, z. B. durch die Verwendung vorab generierter Vektoren, die Anwendung benutzerdefinierter Ähnlichkeitsfunktionen oder die Integration mit externen Modellen.

Wann und warum sollte man dense_vector-Typ verwenden?

Dichte Vektoren eignen sich hervorragend, um semantische Ähnlichkeiten zwischen Sätzen, Absätzen oder ganzen Dokumenten zu erfassen. Sie eignen sich hervorragend, wenn es darum geht, die Gesamtbedeutung von Texten zu vergleichen, selbst wenn diese nicht dieselben Begriffe verwenden.

Das dichte Vektorfeld ist ideal, wenn Sie bereits eine externe Embedding-Generierungspipeline mit Modellen von Plattformen wie OpenAI, Cohere oder Hugging Face verwenden und diese Vektoren nur manuell speichern und abfragen möchten. Dieser Feldtyp bietet eine hohe Kompatibilität mit Einbettungsmodellen und volle Flexibilität bei der Generierung und Abfrage, sodass Sie steuern können, wie die Vektoren erzeugt, indiziert und während der Suche verwendet werden.

Darüber hinaus unterstützt es verschiedene Formen der semantischen Suche, mit Abfragen wie k-NN oder script_score für Fälle, in denen es notwendig ist, die Ranking-Logik anzupassen. Diese Möglichkeiten machen den dichten Vektor ideal für Anwendungen wie RAG (Retrieval-Augmented Generation), Empfehlungssysteme und personalisierte Suchen auf der Grundlage von Ähnlichkeit.

Schließlich ermöglicht Ihnen das Feld, die Relevanzlogik anzupassen, indem Sie Funktionen wie cosineSimilarity, dotProduct oder l2norm verwenden, um das Ranking an die Bedürfnisse Ihres Anwendungsfalls anzupassen.

Dichte Vektoren bleiben die beste Option für diejenigen, die Flexibilität, Anpassungsmöglichkeiten und Kompatibilität mit fortgeschrittenen Anwendungsfällen wie den oben genannten benötigen.

Wie verwendet man die Abfrage für den Datentyp „dichter Vektor“?

Bei Suchen in Feldern, die als dense_vector definiert sind, wird die k-nächste-Nachbarn-Abfrage verwendet. Diese Abfrage dient dazu, Dokumente zu finden, deren Dichtevektor dem Abfragevektor am nächsten kommt. Nachfolgend ein Beispiel für die Anwendung einer k-NN-Abfrage auf ein dichtes Vektorfeld:

Zusätzlich zur k-NN-Abfrage besteht die Möglichkeit, bei Bedarf die Dokumentenbewertung anzupassen, indem man die script_score-Abfrage verwendet und sie mit Vektorvergleichsfunktionen wie cosineSimilarity, dotProduct oder l2norm kombiniert, um die Relevanz kontrollierter zu berechnen. Siehe das Beispiel:

Wer tiefer in die Materie einsteigen möchte, dem empfehle ich den Artikel „Wie man die Vektorsuche in Elasticsearch einrichtet“.

Sparse Vektortyp

Der Feldtyp sparse_vector dient zum Speichern von dünnbesetzten Vektoren. Dabei handelt es sich um numerische Darstellungen, bei denen die meisten Werte null sind und nur wenige Terme ein signifikantes Gewicht haben. Dieser Vektortyp ist in termbasierten Modellen wie SPLADE oder ELSER (Elastic Learned Sparse EncodeR) üblich.

Wann und warum sollte man den Sparse-Vektor-Typ verwenden?

Sparse Vektoren sind ideal, wenn Sie eine präzisere Suche in lexikalischen Begriffen benötigen, ohne dabei semantische Intelligenz einzubüßen. Sie stellen den Text als Token/Wert-Paare dar und heben nur die relevantesten Begriffe mit zugehörigen Gewichtungen hervor, was für Klarheit, Kontrolle und Effizienz sorgt.

Dieser Feldtyp ist besonders nützlich, wenn Sie Vektoren auf der Grundlage von Begriffen generieren, wie beispielsweise in den Modellen ELSER oder SPLADE, die jedem Token unterschiedliche Gewichte zuweisen, basierend auf seiner relativen Bedeutung im Text.

Für den Fall, dass Sie den Einfluss bestimmter Wörter in der Suchanfrage steuern möchten, ermöglichen Ihnen Sparse-Vektor-Typen, die Gewichtung der Begriffe manuell anzupassen, um die Rangfolge der Ergebnisse zu optimieren.

Zu den wichtigsten Vorteilen zählen die Transparenz bei der Suche, da klar ersichtlich ist, warum ein Dokument als relevant eingestuft wurde, und die Speichereffizienz, da nur Token mit einem Wert ungleich Null gespeichert werden, im Gegensatz zu dichten Vektoren, die alle Dimensionen speichern.

Darüber hinaus sind dünnbesetzte Vektoren die ideale Ergänzung in hybriden Suchstrategien und können sogar mit dichtbesetzten Vektoren kombiniert werden, um lexikalische Präzision mit semantischem Verständnis zu verbinden.

Wie verwendet man die Abfrage für den Datentyp „dünnbesetzter Vektor“?

Mit der sparse_vector -Abfrage können Sie nach Dokumenten auf Basis eines Abfragevektors im Token/Wert-Format suchen. Nachfolgend finden Sie ein Beispiel für die Abfrage:

Falls Sie ein trainiertes Modell bevorzugen, können Sie einen Inferenzendpunkt verwenden, der den Abfragetext automatisch in einen Sparse-Vektor umwandelt:

Um dieses Thema weiter zu vertiefen, empfehle ich die Lektüre von „Understanding sparse vector embeddings with trained ML models“.

Semantischer Texttyp

Der Feldtyp semantic_text ist die einfachste und unkomplizierteste Möglichkeit, die semantische Suche in Elasticsearch zu nutzen. Die Generierung von Einbettungen erfolgt automatisch sowohl zur Indexierungs- als auch zur Abfragezeit über einen Inferenz-Endpunkt. Das bedeutet, dass Sie sich keine Gedanken über das manuelle Generieren oder Speichern von Vektoren machen müssen.

Wann und warum sollte man semantischen Text verwenden?

Das Feld semantic_text ist ideal für diejenigen, die mit minimalem technischem Aufwand und ohne manuelle Vektorbearbeitung beginnen möchten. Dieses Feld automatisiert Schritte wie die Generierung von Einbettungen und die Vektorsuche, wodurch die Einrichtung schneller und bequemer wird.

Sie sollten die Verwendung semantic_text in Betracht ziehen, wenn Sie Wert auf Einfachheit und Abstraktion legen, da dadurch die Komplexität der manuellen Konfiguration von Mappings, Embedding-Generierung und Ingestion-Pipelines entfällt. Wählen Sie einfach das Inferenzmodell aus, und Elasticsearch kümmert sich um den Rest.

Zu den wichtigsten Vorteilen gehören die automatische Generierung von Einbettungen, die sowohl während der Indizierung als auch während der Abfrage erfolgt, und das sofort einsatzbereite Mapping, das vorkonfiguriert ist, um das ausgewählte Inferenzmodell zu unterstützen.

Darüber hinaus bietet das Feld native Unterstützung für die automatische Aufteilung langer Texte (Text Chunking), wodurch große Texte in kleinere Abschnitte unterteilt werden können, von denen jeder seine eigene Einbettung hat, was die Suchgenauigkeit verbessert. Dies steigert die Produktivität enorm, insbesondere für Teams, die schnell Mehrwert liefern wollen, ohne sich mit der zugrundeliegenden Technik der semantischen Suche auseinandersetzen zu müssen.

Allerdings bietet semantic_text zwar Geschwindigkeit und Einfachheit, hat aber auch einige Einschränkungen. Es ermöglicht die Verwendung marktüblicher Modelle, sofern diese als Inferenzendpunkte in Elasticsearch verfügbar sind. Es unterstützt jedoch keine extern generierten Einbettungen, wie es mit dem Feld dense_vector möglich ist.

Wenn Sie mehr Kontrolle darüber benötigen, wie Vektoren generiert werden, Ihre eigenen Einbettungen verwenden möchten oder mehrere Felder für fortgeschrittene Strategien kombinieren müssen, bieten die Felder dense_vector und sparse_vector die Flexibilität, die für individuellere oder domänenspezifische Szenarien erforderlich ist.

Wie man die Abfrage für semantischen Texttyp verwendet

Vor semantic_text war es notwendig, je nach Art der Einbettung (dicht oder dünn) eine andere Abfrage zu verwenden. Für dünn besetzte Felder wurde eine sparse_vector -Abfrage verwendet, während für dense_vector -Felder KNN-Abfragen erforderlich waren.

Bei der semantischen Textsuche wird die Suche mithilfe der semantischen Abfrage durchgeführt, die automatisch den Abfragevektor generiert und ihn mit den Einbettungen der indizierten Dokumente vergleicht. Mit dem Typ semantic_text können Sie einen Inferenzendpunkt definieren, um die Abfrage einzubetten. Wenn jedoch kein Endpunkt angegeben wird, wird derselbe Endpunkt, der während der Indizierung verwendet wurde, auf die Abfrage angewendet.

Um mehr zu erfahren, empfehle ich die Lektüre des Artikels Elasticsearch new semantic_text mapping: Simplifying semantic search.

Fazit

Bei der Auswahl der Methode zum Mapping von Embeddings in Elasticsearch ist es wichtig zu verstehen, wie Sie die Vektoren generieren möchten und welchen Grad an Kontrolle Sie darüber benötigen. Wenn Sie Wert auf Einfachheit legen, ermöglicht das semantische Textfeld eine automatische und skalierbare semantische Suche und ist damit ideal für viele erste Anwendungsfälle. Wenn mehr Kontrolle, feinabgestimmte Leistung oder die Integration mit benutzerdefinierten Modellen erforderlich ist, bieten die dichten Vektorfelder und die dünnbesetzten Vektorfelder die notwendige Flexibilität.

Der ideale Feldtyp hängt von Ihrem Anwendungsfall, der verfügbaren Infrastruktur und dem Reifegrad Ihres Machine-Learning-Stacks ab. Am wichtigsten ist jedoch, dass Elastic die Werkzeuge bietet, um moderne und hochgradig anpassungsfähige Suchsysteme zu entwickeln.

Referenzen

• Semantischer Textfeldtyp

• Sparse Vektorfeldtyp

• Dichtes Vektorfeld

• Semantische Anfrage

• Sparse Vektorabfrage

• kNN-Suche

• Elasticsearch: Neues semantisches Textmapping: Vereinfachung der semantischen Suche

• Verständnis von spärlichen Vektoreinbettungen mit trainierten ML-Modellen