In diesem Artikel erfahren Sie, wie Sie den Parameter „Mindestscore“ verwenden können, um die Genauigkeit Ihrer semantischen Suchergebnisse zu erhöhen. Wenn Sie die in diesem Blogbeitrag bereitgestellten Beispiele testen möchten, besuchen Sie das zugehörige Jupyter-Notizbuch.

Hintergrund: Präzision und Abruf

In der Suchrelevanz sind Präzision und Recall Schlüsselkonzepte. Lesern, die noch nicht mit diesen Themen vertraut sind, wird dringend empfohlen, sich darüber zu informieren. Nachfolgend eine Zusammenfassung.

• Genauigkeit: Der Anteil der zurückgegebenen Suchergebnisse, die für den Nutzer relevant sind.

• Recall: Der Anteil aller relevanten Dokumente im Korpus, die in den Suchergebnissen enthalten sind.

Oder, mit anderen Worten, Präzision gibt nur relevante Ergebnisse zurück; und Recall gibt alle relevanten Ergebnisse zurück. Wie Sie sich vorstellen können, handelt es sich dabei oft um konkurrierende Anforderungen. Die semantische Suche weist tendenziell eine sehr hohe Trefferquote auf, hat aber mitunter Schwierigkeiten mit der Präzision. Lesen Sie weiter, um zu erfahren, wie Sie diese Eigenschaft umgehen können.

Einführung des Mindestscore-Parameters

Der ‘min_score’-Parameter ermöglicht es uns, die Präzision zu verbessern, indem ein Mindestscore festgelegt wird, der das Ergebnisset durch Entfernen aller Treffer mit einem Score unter dem definierten Schwellenwert kürzt. Nachfolgend ein einfaches Beispiel:

Normalisierung des Scores

Die Festlegung eines Mindestscores ist schön und gut, aber nicht alle semantischen Modelle liefern einen Score, die sich für einen statischen Schwellenwert eignet. ELSER gibt beispielsweise einen unbegrenzten Score zurück. Einige Scores des dichten Modells sind eng gruppiert und nur im Zusammenhang mit der spezifischen Anfrage sinnvoll.

Für die meisten Fälle der semantischen Suche empfehlen wir, vor der Anwendung von „min_score“ einen Normalisierungsansatz zu verwenden. Durch die Normalisierung wird sichergestellt, dass der Dokumentenscore innerhalb eines definierten Intervalls liegt. Elasticsearch-Retriever bieten zwei solcher Normalisierer, ‘l2_norm’ und ‘minmax’. Am häufigsten wird die „minmax“-Methode verwendet, da sie leicht verständlich ist und in vielen Szenarien gut funktioniert. Wichtige Eigenschaften von ‘minmax’ umfassen:

• Die Dokumentenscores liegen im Bereich von 0 bis 1.

• Das Dokument mit der höchsten Punktzahl erhält immer den Score 1.

• Das Dokument mit der niedrigsten Punktzahl erhält immer den Score 0.

  • Dies kann die Eignung für die Stichwortsuche beeinträchtigen. Weitere Informationen finden Sie im Abschnitt „Hybride Suche“.

Im Folgenden ein Beispiel für eine normalisierte semantische Abfrage mit min_score. Die Größe des Ranking-Fensters wurde auf 500 erhöht, damit wir eine längere Liste von Suchergebnissen zurückgeben können, angefangen bei 100.

Die Größe wurde auf einen höheren Wert als in der Produktion üblich eingestellt. So können wir die Qualität der Suchergebnisse inspizieren und die Ergebnisse optimieren.

Hybridsuche mit dem linearen Retriever

Für die Hybridsuche ist der einfachste Ansatz, alle Scores zu normalisieren, Gewichte zuzuweisen und einen Mindestscore anzuwenden. Beachten Sie, dass Sie durch die Wahl von Gewichtungen mit einer Summe von 1 den Gesamtscore innerhalb eines Bereichs von 0 bis 1 halten. Dadurch lassen sich die Endergebnisse leicht nachvollziehen und die Melodie min_score stimmen. Nachfolgend ein Beispiel:

Hybridsuche mit RRF

Mit BM25 steuern wir die Präzision oft durch andere Mittel, wie die Verwendung des AND-Operators oder minimum_should_match. Darüber hinaus werden Abfragen, die aus einzelnen, präzisen und seltenen Begriffen bestehen, natürlicherweise zu Suchergebnissen mit wenigen Suchergebnissen führen, die oft alle hochrelevant sind. Dies kann zu Folgendem führen:

• Ergebnisse, die weiter hinten im Ergebnis stehen, erhalten im BM25-Retriever einen niedrigen normalisierten Score, selbst wenn der absolute BM25-Score nahe an den Treffern mit den höchsten Scores liegt.

• Wenn ein sehr niedriger BM25-Score zum semantischen Score hinzugefügt wird, kann die Summe als semantischer Score approximiert werden.

• Das Fehlen eines BM25-Score-Beitrags kann dazu führen, dass das Dokument von min_score threshold verworfen wird.

Als Lösung können wir stattdessen die reziproke Rangfusion (RRF) verwenden, um BM25- und semantische Ergebnisse zu kombinieren. RRF umgeht die Herausforderung, Scores verschiedener Suchalgorithmen zu vergleichen, indem es sich stattdessen auf die Position in jedem Ergebnis auf konzentriert. In diesem Szenario wird die min_score nur auf den semantischen Retriever angewendet.

Fazit

Mit min_score haben wir gezeigt, wie wir die Anzahl der Fehlalarme in unseren Ergebnissätzen reduzieren können, die durch den hohen Recall semantischer Suchalgorithmen verursacht werden. Um mehr über Retriever zu erfahren, siehe bitte diesen Blogbeitrag und die Elasticsearch-Dokumentation.

Bei der Behebung dieses einen Problems werden jedoch versehentlich andere Abfragen beeinträchtigt, da nicht alle Fälle manuell getestet werden konnten. Aber wie können Sie oder Ihr QA-Team testen, ob eine Änderung in einer Abfrage Auswirkungen auf andere Abfragen hat? Noch wichtiger: Wie können Sie sicher sein, dass Ihre Änderungen eine Abfrage tatsächlich verbessert haben?

In Richtung einer systematischen Bewertung

Hier kommen Bewertungslisten ins Spiel. Anstatt bei jeder Änderung auf manuelle und subjektive Tests angewiesen zu sein, können Sie einen festen Satz von Abfragen festlegen, die für Ihren Anwendungsfall relevant sind, zusammen mit den entsprechenden Ergebnissen.

Dieser Satz wird zu Ihrer Referenzgrundlage. Bei jeder Änderung, die Sie vornehmen, nutzen Sie diese, um zu bewerten, ob sich Ihre Suche tatsächlich verbessert hat oder nicht.

Der Wert dieses Ansatzes liegt in Folgendem:

• Beseitigt Unsicherheit: Sie müssen sich nicht mehr fragen, ob Ihre Änderungen andere Anfragen beeinflussen; die Daten werden es Ihnen mitteilen.

• Stoppt das manuelle Testen: Sobald die Bewertungssätze aufgezeichnet sind, erfolgt der Test automatisch.

• Unterstützt Veränderungen: Sie können klare Metriken zeigen, die die Vorteile einer Veränderung untermauern.

So beginnen Sie mit dem Erstellen Ihrer Bewertungsliste

Eine der einfachsten Möglichkeiten ist die Auswahl einer repräsentativen Abfrage und die manuelle Auswahl der relevanten Dokumente. Zur Erstellung dieser Liste haben Sie zwei Möglichkeiten:

• Binäre Bewertungen: Jedes Dokument, das mit einer Suchanfrage verknüpft ist, erhält ein einfaches Tag: relevant (in der Regel mit einer Punktzahl von „1“) und nicht relevant („0“).

• Abgestufte Bewertungen: Hier erhält jedes Dokument eine Punktzahl mit unterschiedlichen Stufen. Beispiel: Festlegung einer Skala von 0 bis 4, ähnlich einer Likert-Skala, wobei 0 = „überhaupt nicht relevant” und 4 = „vollkommen relevant” bedeutet, mit Varianten wie „relevant”, „eher relevant” usw.

Binäre Urteile funktionieren gut, wenn die Suchintention klare Grenzen hat: Sollte dieses Dokument in den Ergebnissen enthalten sein oder nicht?

Abgestufte Bewertungen sind vor allem bei Grauzonen sinnvoll: Einige Ergebnisse sind besser als andere, sodass Sie „sehr gute“, „gute“ und „nutzlose“ Ergebnisse erhalten und Metriken verwenden können, die die Reihenfolge der Ergebnisse und das Feedback der Benutzer bewerten. Allerdings haben abgestufte Skalen auch Nachteile: Verschiedene Prüfer können die Bewertungsstufen unterschiedlich anwenden, was die Ergebnisse weniger konsistent macht. Und da bei abgestuften Metriken höhere Werte stärker gewichtet werden, kann selbst eine kleine Änderung (z. B. eine Bewertung von 3 statt 4) zu einer viel größeren Verschiebung der Metrik führen, als vom Prüfer beabsichtigt. Diese zusätzliche Subjektivität macht abgestufte Bewertungen im Laufe der Zeit unübersichtlicher und schwieriger zu verwalten.

Muss ich die Dokumente selbst klassifizieren?

Nicht unbedingt, da es verschiedene Möglichkeiten gibt, Ihre Bewertungsliste zu erstellen, jede mit ihren eigenen Vor- und Nachteilen:

• Explizite Bewertungen: Hier gehen SMEs jede Anfrage/jedes Dokument durch und entscheiden manuell, ob (oder inwieweit) sie relevant ist. Obwohl dies Qualität und Kontrolle bietet, ist die Skalierbarkeit geringer.

• Implizite Bewertungen: Mit dieser Methode leiten Sie die relevanten Dokumente auf der Grundlage des tatsächlichen Nutzerverhaltens wie Klicks, Abwanderungsraten und Käufe ab. Mit diesem Ansatz können Sie Daten automatisch erfassen, allerdings könnten die Ergebnisse verzerrt sein. Zum Beispiel klicken Nutzer häufiger auf Top-Ergebnisse, auch wenn sie nicht relevant sind.

• KI-generierte Bewertungen: Diese letzte Option verwendet Modelle (wie LLMs), um Anfragen und Dokumente automatisch zu bewerten, oft als LLM-Jurys bezeichnet. Sie lässt sich schnell und einfach skalieren, doch die Qualität der Daten hängt von der Qualität des verwendeten Modells und davon ab, wie gut die LLM-Trainingsdaten mit Ihren Geschäftsinteressen übereinstimmen. Wie bei menschlichen Bewertungen können auch LLM-Jurys ihre eigenen Vorurteile oder Inkonsistenzen einbringen. Daher ist es wichtig, ihre Ergebnisse anhand einer kleineren Gruppe vertrauenswürdiger Bewertungen zu validieren. LLM-Modelle sind von Natur aus probabilistisch, daher ist es nicht ungewöhnlich, dass ein LLM-Modell dem gleichen Ergebnis unterschiedliche Bewertungen zuweist, unabhängig davon, ob der Temperaturparameter auf 0 gesetzt wird.

Unten finden Sie einige Empfehlungen zur Auswahl der besten Methode für die Erstellung Ihres Bewertungssatzes:

• Entscheiden Sie, wie kritisch einige Features für Sie sind, die nur Nutzer richtig bewerten können (wie Preis, Marke, Sprache, Stil und Produktdetails). Wenn diese kritisch sind, benötigen Sie explizite Bewertungen für mindestens einen Teil Ihrer Bewertungsliste.

• Verwenden Sie implizite Bewertungen, wenn Ihre Suchmaschine bereits genügend Traffic hat, sodass Sie Metriken zu Klicks, Conversions und Verweildauer nutzen können, um Nutzungstrends zu erkennen. Sie sollten diese dennoch sorgfältig interpretieren und sie mit Ihren expliziten Bewertungssätzen vergleichen, um Verzerrungen zu vermeiden (z. B.: Nutzer neigen dazu, häufiger auf die Ergebnisse mit den höchsten Platzierungen zu klicken, auch wenn Ergebnisse mit niedrigeren Platzierungen relevanter sind)

Um dieses Problem zu beheben, werden mithilfe von Techniken zur Positionsentzerrung Klickdaten angepasst oder neu gewichtet, um das tatsächliche Interesse der Nutzer besser widerzuspiegeln. Mögliche Ansätze hierfür sind:

• Ergebnisse neu mischen: Ändern Sie die Reihenfolge der Suchergebnisse für eine Untergruppe von Nutzern, um zu schätzen, wie sich die Position auf die Klicks auswirkt.

• Zu den Click-Modellen gehörenDynamic Bayesian Network DBN, Nutzer Browsing Model UBM. Diese statistischen Modelle schätzen die Wahrscheinlichkeit, dass ein Klick echtes Interesse widerspiegelt und nicht nur die Position, indem sie Muster wie Scrollverhalten, Verweildauer, Klicksequenz und Rückkehr zur Ergebnisseite verwenden.

Beispiel: App zur Filmbewertung

Voraussetzungen

Um dieses Beispiel auszuführen, benötigen Sie einen laufenden Elasticsearch 8.x-Cluster, lokal oder Elastic Cloud Hosted (gehostet oder serverlos), sowie Zugriff auf die REST API oder Kibana.

Stellen Sie sich eine App vor, in der Nutzer ihre Meinungen zu Filmen hochladen und auch nach Filmen suchen können, die sie sich ansehen möchten. Da die Texte von den Nutzern selbst geschrieben werden, können sie Tippfehler und viele Ausdrucksvariationen aufweisen. Daher ist es unerlässlich, dass die Suchmaschine diese Vielfalt interpretieren und den Nutzern hilfreiche Ergebnisse liefern kann.

Um Abfragen wiederholen zu können, ohne das gesamte Suchverhalten zu beeinträchtigen, hat das Business-Team in Ihrem Unternehmen anhand der häufigsten Suchanfragen die folgenden binären Bewertungssätze erstellt:

Abfrage

DocID

Text

Leistung von DiCaprio

doc1

Die Leistung von DiCaprio in The Revenant war atemberaubend.

Leistung von DiCaprio

doc2

Inception zeigt Leonardo DiCaprio in einer seiner ikonischsten Rollen.

Leistung von DiCaprio

doc3

Brad Pitt liefert in diesem Krimi-Thriller eine solide Leistung ab.

Leistung von DiCaprio

doc4

Ein actiongeladenes Abenteuer mit atemberaubenden visuellen Effekten.

Traurige Filme, die einen zum Weinen bringen

doc5

Eine herzzerreißende Geschichte über Liebe und Verlust, bei der ich stundenlang geweint habe.

Traurige Filme, die einen zum Weinen bringen

doc6

Einer der traurigsten Filme, die je gedreht wurden – Taschentücher bereithalten!

Traurige Filme, die einen zum Weinen bringen

doc7

Eine unbeschwerte Komödie, die Sie zum Lachen bringen wird

Traurige Filme, die einen zum Weinen bringen

doc8

Ein Science-Fiction-Epos voller Action und Spannung.

Erstellung des Indexes:

BULK-Anfrage:

Nachfolgend finden Sie die Elasticsearch-Abfrage, die die App verwendet:

Von der Bewertung zu den Metriken

Für sich genommen liefern Bewertungslisten nicht viele Informationen; sie stellen lediglich eine Erwartung der Ergebnisse unserer Abfragen dar. Ihre wahre Stärke zeigen sie, wenn wir sie zur Berechnung objektiver Metriken zur Messung unserer Suchleistung verwenden.

Heutzutage umfassen die meisten gängigen Metriken Folgendes:

• Genauigkeit: Misst den Anteil der Ergebnisse, die innerhalb aller Suchergebnisse tatsächlich relevant sind.

• Recall: Misst den Anteil relevanter Ergebnisse, die die Suchmaschine unter den x Ergebnissen gefunden hat.

• Discounted Cumulative Gain (DCG):Misst die Qualität der Rangfolge der Ergebnisse, wobei die relevantesten Ergebnisse ganz oben stehen sollten.

• Mean Reziprocal Rank (MRR): Misst die Position des ersten relevanten Ergebnisses. Je höher es in der Liste steht, desto höher ist der Score.

Anhand derselben App zur Bewertung von Filmen berechnen wir die Recall-Metrik, um festzustellen, ob Informationen in unseren Abfragen ausgelassen werden.

In Elasticsearch können wir die Bewertungslisten nutzen, um Metriken über die Ranking Evaluation API zu berechnen. Diese API erhält als Eingabe die Bewertungsliste, die Abfrage und die zu bewertende Metrik und gibt einen Wert zurück, der einen Vergleich des Abfrageergebnisses mit der Bewertungsliste darstellt.

Lassen Sie uns die Ergebnisliste für die beiden vorliegenden Anfragen ausführen:

Wir verwenden zwei Anfragen an _rank_eval: eine für die DiCaprio-Abfrage und eine für traurige Filme. Jede Anfrage enthält eine Fragestellung und die dazugehörige Bewertungsliste (Bewertungen). Wir müssen nicht alle Dokumente bewerten, da diejenigen, die nicht in die Bewertung einbezogen werden, als unbewertet gelten. Für die Berechnungen berücksichtigt Recall nur den „relevanten Satz“, also die Dokumente, die für die Bewertung als relevant gelten.

In diesem Fall hat die DiCaprio-Abfrage einen Recall von 1, während die traurigen Filme einen Recall von 0 haben. Das bedeutet, dass wir bei der ersten Abfrage alle relevanten Ergebnisse erhalten haben, während wir bei der zweiten Abfrage keine Ergebnisse erhalten haben. Der durchschnittliche Recall beträgt daher 0,5.

Vielleicht sind wir mit dem Parameter minimum_should_match zu streng, da wir durch die Forderung, dass 100 % der Wörter in der Suchanfrage in den Dokumenten vorkommen müssen, wahrscheinlich relevante Ergebnisse auslassen. Entfernen wir den Parameter minimum_should_match, damit ein Dokument als relevant angesehen wird, wenn nur ein Wort aus der Suchanfrage darin vorkommt.

Wie Sie sehen können, erhalten wir durch Entfernen des Parameters minimum_should_match in einer der beiden Abfragen nun in beiden Fällen einen durchschnittlichen Recall von 1.

Zusammenfassend lässt sich sagen, dass durch das Entfernen der Klausel „minimum_should_match: 100%“ eine perfekte Trefferquote für beide Abfragen erzielt werden kann.

Wir haben es geschafft! Richtig?

Nicht so schnell!

Durch die Verbesserung des Recalls öffnen wir die Tür zu einer größeren Bandbreite an Ergebnissen. Jede Anpassung impliziert jedoch einen Kompromiss. Deshalb ist es wichtig, vollständige Testfälle festzulegen und verschiedene Metriken zur Bewertung von Änderungen zu verwenden.

Die Verwendung von Bewertungslisten und Metriken verhindert, dass Sie Änderungen blind vornehmen, da Sie nun über Daten verfügen, die diese stützen. Die Validierung erfolgt nicht mehr manuell und wiederholt, und Sie können Ihre Änderungen in mehr als nur einem Anwendungsfall testen. Darüber hinaus können Sie mit A/B-Tests live testen, welche Konfiguration für Ihre Nutzer und Ihren Anwendungsfall am besten geeignet ist, wodurch sich der Kreis von technischen Metriken und realen Metriken schließt.

Abschließende Empfehlungen zur Verwendung von Bewertungslisten

Bei der Arbeit mit Bewertungslisten geht es nicht nur um das Messen, sondern auch darum, einen Rahmen zu schaffen, der es Ihnen ermöglicht, mit Zuversicht zu iterieren. Zu diesem Zweck beachten Sie folgende Empfehlungen:

1. Fangen Sie klein an, aber fangen Sie an. Sie benötigen keine 10.000 Anfragen mit jeweils 50 Bewertungslisten. Sie müssen lediglich die 5 bis 10 wichtigsten Suchanfragen für Ihren Anwendungsfall identifizieren und festlegen, welche Dokumente Ihrer Meinung nach ganz oben in den Ergebnissen erscheinen sollten. Damit haben Sie bereits eine Grundlage. Sie möchten in der Regel mit den Top-Suchanfragen sowie den Suchanfragen ohne Ergebnisse beginnen. Sie können auch mit einer einfach zu konfigurierenden Metrik wie Genauigkeit beginnen und sich dann in der Komplexität steigern.

2. Validieren Sie mit Nutzern. Ergänzen Sie die Zahlen durch A/B-Tests in der Produktion. Auf diese Weise können Sie feststellen, ob Änderungen, die in den Metriken gut aussehen, auch tatsächlich Auswirkungen haben.

3. Führen Sie die Liste weiter. Ihr Anwendungsfall wird sich weiterentwickeln. Und damit auch Ihre kritischen Fragen. Aktualisieren Sie Ihre Bewertung regelmäßig, um neue Anforderungen zu berücksichtigen.

4. Integrieren Sie sie in Ihren Workflow. Integrieren Sie Bewertungslisten in Ihre Entwicklungs-Pipelines. Stellen Sie sicher, dass jede Konfigurationsänderung, jedes Synonym und jede Textanalyse automatisch mit Ihrer Basisliste abgeglichen wird.

5. Verbinden Sie technisches Wissen mit Strategie. Beschränken Sie sich nicht auf die Messung technischer Metriken wie Genauigkeit oder Recall. Nutzen Sie Ihre Bewertungsergebnisse, um die Geschäftsergebnisse zu verbessern.

Das Problem der Punktespanne

Um die Ausgangslage zu verdeutlichen, betrachten wir zunächst einen der Hauptgründe, warum die hybride Suche schwierig sein kann: die variierenden Bewertungsbereiche. Unser alter Bekannter BM25 liefert unbegrenzte Ergebnisse. Mit anderen Worten: BM25 kann Werte generieren, die von nahe 0 bis (theoretisch) unendlich reichen. Im Gegensatz dazu liefern Abfragen gegen dense_vector -Felder Ergebnisse im Bereich zwischen 0 und 1. Erschwerend kommt hinzu, dass semantic_text den Feldtyp verschleiert, der zur Indizierung von Einbettungen verwendet wird. Daher ist es ohne detaillierte Kenntnisse über die Konfiguration Ihres Index und Inferenzendpunkts schwierig abzuschätzen, in welchem Bereich die Ergebnisse Ihrer Abfrage liegen werden. Dies stellt ein Problem dar, wenn versucht wird, lexikalische und semantische Suchergebnisse zu verschachteln, da die lexikalischen Ergebnisse Vorrang vor den semantischen haben können, selbst wenn die semantischen Ergebnisse relevanter sind. Die allgemein anerkannte Lösung für dieses Problem besteht darin, die Werte vor der Verschachtelung der Ergebnisse zu normalisieren. Elasticsearch bietet hierfür zwei Tools an: den linearen und den RRF- Retriever.

Der RRF- Retriever wendet den RRF-Algorithmus an, wobei der Dokumentenrang als Relevanzmaß verwendet und der Score verworfen wird. Da die Punktzahl nicht berücksichtigt wird, stellen Abweichungen im Punktzahlbereich kein Problem dar.

Der lineare Retriever verwendet eine lineare Kombination, um die endgültige Punktzahl eines Dokuments zu bestimmen. Dabei wird für jede einzelne Abfrage die Punktzahl der Komponenten des Dokuments ermittelt, normalisiert und anschließend summiert, um die Gesamtpunktzahl zu erhalten. Mathematisch lässt sich die Operation wie folgt ausdrücken:

Dabei ist N die Normalisierungsfunktion und SX die Punktzahl für die Anfrage X. Die Normalisierungsfunktion ist hierbei von zentraler Bedeutung, da sie die Punktzahl jeder Abfrage so transformiert, dass sie denselben Wertebereich verwendet. Hier erfahren Sie mehr über den linearen Retriever.

Aufgeschlüsselt

Mit diesen Tools können Benutzer eine effektive Hybridsuche implementieren, dies erfordert jedoch gewisse Kenntnisse über ihren Index. Betrachten wir ein Beispiel mit dem linearen Retriever, bei dem wir einen Index mit zwei Feldern abfragen:

1. semantic_text_field ist ein semantic_text -Feld, das E5, ein Text-Embedding-Modell, verwendet.

2. text_field ist ein Standard- text -Feld

1. Wir verwenden eine match -Abfrage für unser semantic_text -Feld, dessen Unterstützung wir in Elasticsearch 8.18/9.0 hinzugefügt haben.

Bei der Erstellung der Abfrage müssen wir berücksichtigen, dass semantic_text_field ein Text-Embedding-Modell verwendet, sodass alle Abfragen darauf eine Punktzahl zwischen 0 und 1 generieren. Wir müssen außerdem wissen, dass text_field ein Standardfeld text ist und dass Abfragen darauf eine unbegrenzte Punktzahl erzeugen. Um ein Ergebnis-Set mit der richtigen Relevanz zu erstellen, müssen wir einen Retriever verwenden, der die Abfrage-Scores normalisiert, bevor er sie kombiniert. In diesem Beispiel verwenden wir den linearen Retriever mit minmax -Normalisierung, der den Score jeder Abfrage auf einen Wert zwischen 0 und 1 normalisiert.

Die Abfragekonstruktion in diesem Beispiel ist recht einfach, da nur zwei Felder beteiligt sind. Allerdings kann es sehr schnell kompliziert werden, wenn weitere Felder unterschiedlicher Art hinzugefügt werden. Dies zeigt, dass das Schreiben einer effektiven hybriden Suchanfrage oft ein tieferes Verständnis des abgefragten Index erfordert, damit die Punktzahlen der einzelnen Suchanfragen vor der Kombination richtig normalisiert werden. Dies stellt ein Hindernis für die breitere Akzeptanz der hybriden Suche dar.

Abfragegruppierung

Erweitern wir das Beispiel: Was wäre, wenn wir ein text -Feld und zwei semantic_text -Felder abfragen wollten? Wir könnten eine Abfrage wie diese erstellen:

Das klingt auf den ersten Blick gut, aber es gibt ein potenzielles Problem. Die Treffer im Feld semantic_text machen nun ⅔ der Gesamtpunktzahl aus:

Das ist wahrscheinlich nicht das, was Sie wollen, denn dadurch entsteht ein unausgewogenes Ergebnis. Die Auswirkungen sind in einem Beispiel wie diesem mit nur 3 Feldern möglicherweise nicht so deutlich erkennbar, aber es wird problematisch, wenn mehr Felder abgefragt werden. Beispielsweise enthalten die meisten Indizes weitaus mehr lexikalische als semantische Felder (d. h. dense_vector, sparse_vector, oder semantic_text). Was wäre, wenn wir einen Index mit 9 lexikalischen Feldern und 1 semantischen Feld nach dem oben genannten Muster abfragen würden? Die lexikalischen Übereinstimmungen würden 90 % der Punktzahl ausmachen und somit die Effektivität der semantischen Suche beeinträchtigen.

Eine gängige Methode, um diesem Problem zu begegnen, besteht darin, Anfragen in lexikalische und semantische Kategorien zu gruppieren und beide gleich zu gewichten. Dadurch wird verhindert, dass eine der beiden Kategorien die Gesamtpunktzahl dominiert.

Lasst uns das in die Praxis umsetzen. Wie sähe dieser Ansatz mit gruppierten Abfragen in diesem Beispiel bei Verwendung des linearen Retrievers aus?

Wow, das wird aber ausführlich! Möglicherweise mussten Sie sogar mehrmals auf- und abscrollen, um die gesamte Abfrage zu prüfen! Hier verwenden wir zwei Normalisierungsebenen, um die Abfragegruppen zu erstellen. Mathematisch lässt sich dies wie folgt ausdrücken:

Diese zweite Normalisierungsebene stellt sicher, dass die Anfragen an die Felder semantic_text und text gleich gewichtet werden. Beachten Sie, dass wir in diesem Beispiel die Normalisierung zweiter Ebene für text_field weglassen, da es nur ein lexikalisches Feld gibt, wodurch Sie sich noch mehr Ausführlichkeit ersparen.

Diese Abfragestruktur ist schon jetzt unhandlich, und wir fragen nur drei Felder ab. Je mehr Felder man abfragt, desto unübersichtlicher wird es, selbst für erfahrene Suchmaschinenexperten.

Das Abfrageformat mit mehreren Feldern

Um das Ganze zu vereinfachen, haben wir das Multi-Field-Abfrageformat für die linearen und RRF-Retriever in Elasticsearch 8.19, 9.1 und Serverless hinzugefügt. Sie können die gleiche Abfrage wie oben nun mit folgendem Befehl durchführen:

Dadurch verkürzt sich die Abfrage von 55 Zeilen auf nur noch 9! Elasticsearch verwendet automatisch die Indexzuordnungen für:

• Ermitteln Sie den Typ jedes abgefragten Feldes.

• Ordnen Sie jedes Feld einer lexikalischen oder semantischen Kategorie zu.

• Jede Kategorie sollte im Endergebnis gleich gewichtet werden.

Dies ermöglicht es jedem, eine effektive hybride Suchanfrage auszuführen, ohne Details über den Index oder die verwendeten Inferenzendpunkte kennen zu müssen.

Bei Verwendung von RRF kann das normalizer weggelassen werden, da der Rang als Indikator für die Relevanz dient:

Steigerung pro Spielfeld

Bei Verwendung des linearen Retrievers können Sie eine Gewichtung pro Feld anwenden, um die Wichtigkeit von Übereinstimmungen in bestimmten Feldern anzupassen. Nehmen wir beispielsweise an, Sie fragen vier Felder ab: zwei semantic_text -Felder und zwei text -Felder:

Standardmäßig wird jedes Feld innerhalb seiner Gruppe (lexikalisch oder semantisch) gleich gewichtet. Die Punkteverteilung sieht wie folgt aus:

Mit anderen Worten: Jedes Feld macht 25 % der Gesamtpunktzahl aus.

Mit der Syntax field^boost können wir jedem Feld einen feldbezogenen Boost hinzufügen. Wenden wir einen Boost von 2 auf semantic_text_field_1 und text_field_1 an:

Die Aufschlüsselung der Punkte sieht nun wie folgt aus:

Jede Abfragegruppe ist weiterhin gleich gewichtet, aber die Feldgewichtung innerhalb der Gruppen hat sich geändert:

• semantic_text_field_1 entspricht 66 % der Punktzahl der semantischen Abfragegruppe und 33 % der Gesamtpunktzahl.

• text_field_1 macht 66 % der Punktzahl der lexikalischen Abfragegruppe und 33 % der Gesamtpunktzahl aus.

ℹ️ Beachten Sie, dass sich die Gesamtpunktzahl nicht ändert, wenn ein Bonus pro Feld angewendet wird. Dies ist ein beabsichtigter Nebeneffekt der Score-Normalisierung, der sicherstellt, dass lexikalische und semantische Anfrage-Scores direkt miteinander vergleichbar bleiben.

ℹ️ Die feldbezogene Gewichtung kann auch mit dem RRF-Retriever in Elasticsearch 9.2+ verwendet werden.

Wildcard-Auflösung

Sie können das Platzhalterzeichen * im Parameter fields verwenden, um mehrere Felder abzugleichen. Um das obige Beispiel fortzuführen: Diese Abfrage ist funktional äquivalent zur expliziten Abfrage von semantic_text_field_1, semantic_text_field_2, und text_field_1 :

Interessanterweise passt das Muster *_field_1 sowohl zu text_field_1 als auch semantic_text_field_1. Dies wird automatisch gehandhabt; die Abfrage wird so ausgeführt, als ob jedes der Felder explizit abgefragt würde. Es ist auch in Ordnung, dass semantic_text_field_1 beiden Mustern entspricht; alle Feldnamenübereinstimmungen werden vor der Abfrageausführung dedupliziert.

Sie können das Wildcard-Zeichen auf verschiedene Arten verwenden:

• Präfixübereinstimmung (z. B. *_text_field)

• Inline-Matching (z. B. semantic_*_field)

• Suffix-Matching (z. B. semantic_text_field_*)

Sie können auch mehrere Platzhalter verwenden, um eine Kombination der oben genannten anzuwenden, z. B. *_text_field_*.

Standardabfragefelder

Das Abfrageformat mit mehreren Feldern ermöglicht es Ihnen auch, einen Index abzufragen, über den Sie nichts wissen. Wenn Sie den Parameter fields weglassen, werden alle Felder abgefragt, die durch die Indexeinstellung index.query.default_field angegeben sind:

Standardmäßig ist index.query.default_field auf * gesetzt. Dieser Platzhalter wird auf jeden Feldtyp im Index aufgelöst, der Termabfragen unterstützt, was auf die meisten zutrifft. Die Ausnahmen sind:

• dense_vector Felder

• rank_vector Felder

• Geometrische Felder: geo_point, shape

Diese Funktionalität ist besonders nützlich, wenn Sie eine hybride Suchanfrage auf einem von einem Drittanbieter bereitgestellten Index durchführen möchten. Das Abfrageformat mit mehreren Feldern ermöglicht es Ihnen, auf einfache Weise eine passende Abfrage auszuführen. Lassen Sie einfach den Parameter fields weg, und alle relevanten Felder werden abgefragt.

Fazit

Das Problem der Bewertungsbereiche kann die Implementierung einer effektiven hybriden Suche zu einer echten Herausforderung machen, insbesondere wenn nur begrenzter Einblick in den abgefragten Index oder die verwendeten Inferenzendpunkte besteht. Das Mehrfeld-Abfrageformat für die linearen und RRF-Retriever mindert dieses Problem, indem es einen automatisierten, auf Abfragegruppierung basierenden hybriden Suchansatz in einer einfachen und zugänglichen API bündelt. Zusätzliche Funktionen wie die Gewichtung einzelner Felder, die Auflösung von Platzhaltern und die Verwendung von Standardabfragefeldern erweitern den Funktionsumfang und decken viele Anwendungsfälle ab.

Probieren Sie heute noch das Abfrageformat mit mehreren Feldern aus.

Sie können die linearen und RRF-Retriever mit dem Multi-Field-Query-Format in vollständig verwalteten Elasticsearch Serverless- Projekten mit einer kostenlosen Testversion ausprobieren. Es ist auch in Stack-Versionen ab 8.19 und 9.1 verfügbar.

Legen Sie in wenigen Minuten in Ihrer lokalen Umgebung mit einem einzigen Befehl los:

Wie viele von uns bin auch ich gleichermaßen begeistert und erstaunt über das Tempo, mit dem sich die Fähigkeiten der KI weiterentwickeln. Wir erlebten zum ersten Mal, wie große Sprachmodelle (LLMs) und die Vektorsuche uns in die semantische Revolution katapultierten, bei der wir nicht mehr mühsam mit Schlüsselwörtern herumsuchen mussten, um Dinge zu finden. Dann zeigten uns die LLMs neue Wege der Interaktion mit unseren Daten auf, indem sie Chat-Schnittstellen nutzten, um Anfragen in natürlicher Sprache in Antworten umzuwandeln, die riesige Wissensdatenbanken in leicht verständliche Zusammenfassungen destillierten. Wir jetzt (schon!) haben die Anfänge einer automatisierten LLM-gesteuerten Logik in Form von „agentischen KI“-Workflows, die eine eingehende Anfrage semantisch verstehen, über die zu unternehmenden Schritte nachdenken und dann aus den verfügbaren Werkzeugen auswählen können, um iterativ Aktionen auszuführen, um diese Ziele zu erreichen.

Das Versprechen agentenbasierter KI zwingt uns, uns von der primären Verwendung von „Prompt Engineering“ zur Gestaltung unserer generativen KI-Interaktionen hin zu einem Fokus darauf zu entwickeln, wie wir agentenbasierte Werkzeuge dabei unterstützen können, die relevantesten und effizientesten Zusatzinformationen zu erhalten, die das LLM bei der Generierung seiner Antworten berücksichtigen muss – „Context Engineering“ ist die nächste Herausforderung. Die hybride Suche ist mit Abstand das leistungsstärkste und flexibelste Mittel, um relevante Kontextinformationen zu finden, und die Search AI-Plattform von Elastic eröffnet völlig neue Möglichkeiten, Daten im Dienste des Context Engineering zu nutzen. In diesem Artikel werden wir aus zwei Blickwinkeln erörtern, wie LLMs die Welt der Informationswiedergewinnung verändert haben, und anschließend darauf eingehen, wie sie für bessere Ergebnisse zusammenarbeiten können. Es gibt noch viel zu besprechen…

Teil I: Wie LLMs die Suche verändert haben

Beginnen wir mit der Frage, wie LLMs die Art und Weise verändert haben, wie wir auf Informationen zugreifen und sie abrufen.

Unser lexikalisches Erbe

Wir alle leben schon seit langer Zeit in der etwas eingeschränkten Welt der lexikalischen Suche (ziemlich gut, so gut es eben geht). Die Suche ist das erste Werkzeug, zu dem wir greifen, wenn wir recherchieren oder ein neues Projekt beginnen, und bis vor kurzem lag es an uns, unsere Suchanfragen so zu formulieren, dass eine lexikalische Suchmaschine sie versteht. Die lexikalische Suche basiert auf dem Abgleich von Suchbegriffen mit Schlüsselwörtern in einem Dokumentenkorpus – unabhängig davon, ob der Inhalt unstrukturiert oder strukturiert ist. Damit eine lexikalische Suche ein Dokument als Treffer zurückgibt, muss dieses mit dem entsprechenden Schlüsselwort übereinstimmen (oder über ein kontrolliertes Vokabular wie eine Synonymliste oder ein Wörterbuch verfügen, um die konzeptionelle Verbindung für uns herzustellen).

Beispiel einer lexikalischen Mehrfachabfrage

Suchmaschinen haben zumindest die Möglichkeit, Treffer mit einer Relevanzbewertung zurückzugeben. Suchmaschinen bieten eine Fülle von Abfragesyntaxoptionen, um indizierte Daten effektiv anzusprechen, sowie integrierte Relevanzalgorithmen, die die Ergebnisse im Verhältnis zur Absicht der Abfragesyntax des Benutzers bewerten. Suchmaschinen profitieren von jahrzehntelangen Fortschritten bei Relevanz-Ranking-Algorithmen und sind dadurch eine effiziente Datenabrufplattform, die Ergebnisse liefern kann, die nach ihrer Relevanz für die Suchanfrage bewertet und sortiert sind. Datenbanken und andere Systeme, die SQL als ihre Hauptmethode zum Abrufen von Daten verwenden, sind hier im Nachteil: Es gibt kein Relevanzkonzept in einer Datenbankabfrage; sie können bestenfalls Ergebnisse alphabetisch oder numerisch sortieren. Die gute Nachricht ist, dass Sie mit diesen Schlüsselwörtern alle Treffer (Recall) erhalten, diese aber nicht unbedingt in einer hilfreichen Reihenfolge im Hinblick darauf, warum Sie danach gesucht haben (Präzision). Das ist ein wichtiger Punkt, wie wir gleich sehen werden…

Betreten Sie den (semantischen) Drachen

Das Potenzial von Vektordarstellungen von Informationen als Alternative zur Stichwortsuche wird schon seit geraumer Zeit erforscht. Vektoren bergen großes Potenzial, da sie uns aus dem rein schlüsselwortbasierten Modus des Inhaltsabgleichs herausführen – da Vektoren numerische Darstellungen von Begriffen und Gewichtungen sind, ermöglichen sie es, Konzepte mathematisch nahe beieinander zu bringen, basierend auf dem Verständnis eines Sprachmodells darüber, wie Begriffe im Trainingsbereich miteinander in Beziehung stehen. Die lange Verzögerung bei der allgemeinen Vektorsuche war darauf zurückzuführen, dass die Modelle größtenteils auf spezifische Domänen beschränkt waren; sie waren einfach nicht groß genug, um die vielen verschiedenen Konzepte, die ein Begriff in unterschiedlichen Kontexten repräsentieren könnte, ausreichend zu verstehen.

Erst mit dem Aufkommen der Large Language Models (LLMs) vor einigen Jahren, die in der Lage sind, mit viel größeren Datenmengen zu trainieren (unter Verwendung von Transformatoren und Aufmerksamkeit), wurde die Vektorsuche praktikabel – die Größe und Tiefe der LLMs ermöglichten es Vektoren schließlich, genügend Nuancen zu speichern, um tatsächlich semantische Bedeutung zu erfassen. Dieser plötzliche Anstieg des Verständnisses ermöglichte es LLMs, nun eine große Anzahl von Funktionen der natürlichen Sprachverarbeitung (NLP) zu erfüllen, die zuvor gesperrt waren. Die vielleicht wirkungsvollste Funktion ist die Fähigkeit, aus dem Kontext dessen, was sich bisher in der Sequenz befindet, auf das wahrscheinlichste nächste Glied in einer Sequenz zu schließen. Inferenz ist der Prozess, der generativer KI ihre nahezu menschenähnliche Fähigkeit verleiht, Texte zu erzeugen. Der KI-generierte Text basiert auf dem Verständnis des LLM darüber, wie Begriffe in seinen Trainingsdaten miteinander in Beziehung stehen, und verwendet außerdem die Formulierung der Anfrage, um zwischen verschiedenen Kontexten, in denen die Begriffe vorkommen könnten, zu unterscheiden.

So magisch generative KI auch sein mag, es gibt Einschränkungen bei LLMs, die zu Fehlern in Qualität und Genauigkeit führen, die gemeinhin als Halluzinationen bezeichnet werden. Halluzinationen treten auf, wenn das LLM keinen Zugang zu den Informationen hat (oder nicht in den richtigen Kontext geführt wird), um seine Antwort auf die Wahrheit zu gründen. Stattdessen generiert es, um hilfreich zu sein, eine selbstsicher und plausibel klingende, aber erfundene Antwort. Ein Teil der Ursache liegt darin, dass LLMs zwar den Sprachgebrauch in großen Bereichen mit vielfältigen Informationen erlernen, das Training aber irgendwann beendet werden muss. Daher gibt es einen Zeitfaktor für ihr Verständnis – das heißt, das Modell kann nur das wissen, was bis zum Zeitpunkt des Trainingsstopps korrekt war. Ein weiterer Faktor für Halluzinationen ist, dass das Modell normalerweise keine Kenntnis von privat gespeicherten Daten hat (Daten, die nicht im öffentlichen Internet verfügbar sind), und das ist besonders bedeutsam, wenn diese Daten spezifische Begriffe und Nomenklatur enthalten.

Vektordatenbanken

LLMs vektorisieren Inhalte in ihren Modellraum mithilfe einer Technik namens Text Embedding. Dabei wird die semantische Bedeutung des Inhalts auf der Grundlage des erhaltenen Trainings in die Weltanschauung des Modells eingebettet oder abgebildet. Zur Vorbereitung und Verarbeitung von Inhalten für die Einbettung sind einige Schritte erforderlich, darunter Chunking und Tokenisierung (sowie Subwort-Tokenisierung). Das Ergebnis ist typischerweise eine Menge dichter Vektoren, die das Verständnis des Modells für die Bedeutung dieses Inhaltsabschnitts innerhalb seines Vektorraums darstellen. Chunking ist ein ungenaues Verfahren, das darauf abzielt, Inhalte an die Verarbeitungsbeschränkungen eines Modells zur Generierung von Einbettungen anzupassen und gleichzeitig verwandten Text mithilfe semantischer Konstrukte wie Satz- und Absatzindikatoren zu einem Chunk zusammenzufassen.

Die Notwendigkeit der Segmentierung kann zu einem gewissen semantischen Verlust in einem eingebetteten Dokument führen, da einzelne Segmente nicht vollständig mit anderen Segmenten aus demselben Dokument verknüpft sind. Die inhärente Undurchsichtigkeit neuronaler Netze kann diesen Verlust noch verschlimmern – ein LLM ist in Wahrheit eine „Black Box“, bei der die während des Trainings hergestellten Verbindungen zwischen Begriffen und Konzepten nicht deterministisch und für Menschen nicht interpretierbar sind. Dies führt zu Problemen mit der Erklärbarkeit, der Wiederholbarkeit, unbewussten Voreingenommenheit und möglicherweise zu einem Verlust an Vertrauen und Genauigkeit. Dennoch ist die Möglichkeit, Ideen semantisch zu verknüpfen und bei Suchanfragen nicht an bestimmte Schlüsselwörter gebunden zu sein, extrem wirkungsvoll:

Ein Beispiel für eine semantische Anfrage

Bei Vektordatenbanken gibt es noch einen weiteren Punkt zu beachten: Sie sind keine Suchmaschinen, sondern Datenbanken! Bei einer Vektorähnlichkeitssuche werden die Suchbegriffe kodiert, um einen Satz von (Einbettungs-)Koordinaten innerhalb des Vektorraums des Modells zu finden. Diese Koordinaten dienen dann als Zielscheibe, um die Dokumente zu finden, die die „nächsten Nachbarn“ der Zielscheibe sind – das heißt, der Rang eines Dokuments (oder seine Platzierung in den Ergebnissen) wird durch die berechnete Ähnlichkeitsdistanz der Koordinaten dieses Dokuments zu den Koordinaten der Anfrage bestimmt. In welche Richtung sollte die Rangfolge Vorrang haben, welcher der möglichen Kontexte entspricht am ehesten der Absicht des Nutzers? Das Bild, mit dem ich es vergleiche, ist eine Szene aus dem Film Stargate, in der wir die sechs Koordinatenpunkte haben, die sich schneiden, um uns das Ziel (die Zielscheibe) zu nennen, aber wir können es nicht erreichen, ohne das „7. Symbol“ zu kennen – die Koordinaten des Startpunkts, die die subjektive Absicht des Benutzers repräsentieren. Anstatt also die relative Rangfolge der Vektoren auf einer sich ständig erweiternden und undifferenzierten Sphäre der Ähnlichkeit zu basieren, können wir durch die Berücksichtigung der subjektiven Absicht der Anfrage mittels ausdrucksstarker Syntax und Relevanzbewertung so etwas wie einen Zylinder abgestufter subjektiver Relevanz erhalten.

Die Inferenzfähigkeiten eines LLM können zwar helfen, den wahrscheinlichsten Kontext für die Anfrage zu identifizieren, das Problem besteht jedoch darin, dass ohne diese Unterstützung die Koordinaten der eingehenden Anfrage nur anhand der Art und Weise bestimmt werden können, wie das Modell ursprünglich trainiert wurde.

In gewisser Hinsicht könnte man sagen, dass Vektorähnlichkeit das entgegengesetzte Extrem darstellt als eine strikte Stichwortübereinstimmung – ihre Stärke liegt in ihrer Fähigkeit, die Probleme der Begriffsabweichung zu überwinden, aber fast bis zum Exzess: LLMs neigen dazu, verwandte Konzepte zu vereinheitlichen, anstatt zwischen ihnen zu unterscheiden. Die Vektorähnlichkeit verbessert unsere Fähigkeit, Inhalte semantisch abzugleichen, garantiert aber keine Präzision, da sie exakte Schlüsselwörter und spezifische Details übersehen kann, die vom Modell nicht ausreichend unterschieden werden. Die Vektorähnlichkeitssuche ist an sich schon leistungsstark, aber wir brauchen Möglichkeiten, die Ergebnisse, die wir aus einer Vektordatenbank abrufen, mit Ergebnissen anderer Abrufmethoden zu korrelieren.

Neubewertungstechniken

An dieser Stelle sei eine allgemeine Technik namens Reranking erwähnt, bei der die Ergebnismengen neu bewertet oder normalisiert werden, um eine einheitliche Rangfolge zu erhalten. Die Notwendigkeit einer Neubewertung könnte darauf zurückzuführen sein, dass Ergebnisse aus mehreren Quellen oder Abrufmethoden unterschiedliche Bewertungsmechanismen (oder gar keine, SQL!) haben, oder die Neubewertung könnte dazu dienen, die Ergebnisse aus nicht-semantischen Quellen semantisch an die Anfrage des Benutzers anzupassen. Das Reranking ist ein zweiter Schritt, bei dem es sich um eine Reihe von Ergebnissen handelt, die durch eine erste Abrufmethode (z. B. Anschließend werden SQL-, lexikalische und Vektorsuchen mit einer anderen Bewertungsmethode neu geordnet.

Es stehen verschiedene Ansätze zur Verfügung, darunter Learning-To-Rank (LTR) und Reciprocal Rank Fusion (RRF) – LTR eignet sich, um Suchergebnisse zu erfassen (Likes, Bewertungen, Klicks usw.) und diese zu nutzen, um Ergebnisse zu bewerten und zu verstärken oder zu verzerren. RRF eignet sich perfekt zum Zusammenführen von Ergebnissen, die von verschiedenen Abfragemodalitäten zurückgegeben werden (z. B. lexikalische und Vektordatenbankrecherchen) werden zu einer einzigen Ergebnisliste zusammengeführt. Elastic bietet außerdem die Flexibilität, die Ergebnisse mithilfe linearer Neubewertungsmethoden anzupassen.

Eine der effektivsten Reranking-Techniken ist jedoch das semantische Reranking, bei dem das semantische Verständnis eines LLM genutzt wird, um die Vektoreinbettungen sowohl der Anfrage als auch der Ergebnisse gemeinsam zu analysieren und anschließend eine Relevanzbewertung/Rescoring anzuwenden, um die endgültige Reihenfolge zu bestimmen. Für das semantische Reranking ist natürlich eine Verbindung zu einem Reranking-Modell erforderlich. Elasticsearch bietet eine Inference API , mit der Sie Rerank- Endpunkte erstellen können, die integrierte Modelle (Elastic Rerank), importierte Modelle von Drittanbietern oder extern gehostete Dienste wie Cohere oder Google Vertex AI nutzen. Anschließend können Sie mithilfe der Abstraktionssyntax der Retriever -Abfrage ein Reranking durchführen:

Ein Beispiel für eine mehrstufige Retriever-Neubewertungsoperation

Klingt super, oder? Wir können eine Neubewertung der Ergebnisse aus unterschiedlichen Quellen durchführen und so ein nahezu vollständiges semantisches Verständnis aller Inhaltsarten erreichen… Die semantische Neubewertung kann sowohl rechenintensiv als auch zeitaufwendig sein, weshalb sie nur bei einer begrenzten Anzahl von Ergebnissen praktikabel ist. Daher ist es wichtig, wie die ursprünglichen Ergebnisse abgerufen werden.

Die Methode zur Kontextabfrage ist wichtig.

Die subjektive Intention ist ein wichtiger Faktor bei der Bestimmung der Genauigkeit eines Ergebnisses und bei der Bewertung seiner Relevanz. Ohne die Möglichkeit, die Absicht des Benutzers bei der Durchführung der Abfrage zu berücksichtigen (ausgedrückt durch eine flexible Syntax oder durch eine Neubewertung in einer zweiten Stufe), können wir nur aus den bereits im Modellraum kodierten Kontexten auswählen. Um diesem Mangel an Kontext zu begegnen, setzen wir üblicherweise Techniken wie Retrieval Augment Generation (RAG) ein. Die Funktionsweise von RAG besteht darin, dass die Koordinaten der Abfrage effektiv verschoben werden, indem zusätzliche verwandte Begriffe aus einer Vorabfrage für kontextrelevante Daten einbezogen werden. Dadurch wird die Art und Weise, wie die Engine diesen zusätzlichen Kontext bereitstellt, und ihre anfängliche Methode zur Datenabfrage umso wichtiger für die Genauigkeit des Kontextes!

Lassen Sie uns die verschiedenen Methoden zur Kontextabfrage und deren Einfluss auf eine RAG-Operation betrachten:

• Hybride Suchabrufe ohne Suchmaschine weisen immer noch einen Mangel an subjektiver Relevanz auf. Wenn die Plattform, die RAG bereitstellt, im Wesentlichen auf SQL basiert (was auf die meisten „Data Lake“-Plattformen zutrifft), fehlt ihr die Relevanzbewertung in der ersten Abrufphase. Viele Data-Lake-Plattformen bieten ihre eigene Version des hybriden Retrieval (nicht der Suche) an, wobei in der Regel Reranking-Techniken wie semantisches Reranking und RRF auf ihren SQL-basierten Retrieval- und Vektordatenbankergebnissen kombiniert werden. Eine einfache Sortierung reicht offensichtlich nicht für eine subjektive Rangfolge aus, aber selbst wenn sie als Grundlage für eine semantische Neubewertung in einem zweiten Schritt verwendet wird, wird SQL als erste Stufe der Abfrage problematisch, wenn die semantische Neubewertung nur auf den „Top k“ Treffern durchgeführt wird – ohne eine Möglichkeit, die Ergebnisse bei der Abfrage zu bewerten, welche Garantie haben wir, dass die besten Ergebnisse tatsächlich unter den Top-Ergebnissen enthalten sind?

• Vektorähnlichkeit allein reicht für RAG nicht aus. Das liegt eigentlich an einer Reihe von sich gegenseitig verstärkenden Problemen – es ist der Verlust beim Einbetten, zusammen mit naiven Chunking-Methoden, der Art und Weise, wie Ähnlichkeit berechnet wird, und der entscheidenden fehlenden Komponente der subjektiven Absicht. Eines der Hauptziele von RAG ist es, generative KI-Interaktionen auf objektiver Wahrheit zu gründen, um sowohl Halluzinationen zu verhindern als auch das LLM über private Informationen zu informieren, von denen es während des Trainings keine Kenntnis hatte. Wir können den durch RAG bereitgestellten zusätzlichen Kontext nutzen, um LLMs einzuschränken und anzuleiten, die Verbindungen und Details zu berücksichtigen, von denen wir wissen, dass sie für die Beantwortung der jeweiligen Frage am wichtigsten sind. Dazu müssen wir sowohl semantische als auch lexikalische Ansätze verwenden.

• Dateibasierte grep/regex RAG. Einige Kreise im Universum der agentenbasierten KI plädieren für die Verwendung stark vergrößerter Kontextfenster, die über grep und reguläre Ausdrücke für RAG auf lokale Dateien zugreifen, anstatt externe Abrufplattformen zu nutzen. Die Idee dahinter ist, dass LLMs mit einem wesentlich größeren Kontextfenster in der Lage sein werden, konzeptionelle Verbindungen innerhalb ihres eigenen Denkraums herzustellen, anstatt sich auf fragmentierte Informationen und verschiedene Abrufmethoden/Plattformen zu verlassen, um relevante Informationen zu sammeln. Theoretisch ist es zwar richtig, dass ein ganzes Dokument ein umfassenderes Bild liefert als Dokumentsegmente, dies funktioniert jedoch nur in kleinen Datenbereichen (oder beispielsweise bei der Bereitstellung von Dateien für Vibecoding), und selbst dann besteht die erste Abrufmethode in einem Scan aller Dokumente mit einer reinen Stichwortübereinstimmung.

Suche ist mehr als nur Abruf.

Suchmaschinen sind speziell dafür entwickelt, Suchanfragen so schnell und flexibel wie möglich zu gestalten. Intern nutzen sie spezialisierte Datenstrukturen zum Speichern und Abrufen verschiedener Datentypen, die auf diese Datentypen zugeschnitten sind. Elasticsearch bietet optimiertes Speichern und Abfragen für praktisch alle Datentypen, einschließlich unstrukturierter/Volltext-Lexikalsuche (Match, Phrase, Proximity, Multi-Match), schneller Keyword-Suche (exakte Übereinstimmung) und Filterung, numerischer Bereiche, Datumsangaben, IP-Adressen und ist sehr flexibel in der Speicherung von Dokumentstrukturen (z. B. …). verschachtelte oder flache Dokumente). Elasticsearch ist außerdem eine native Vektordatenbank, die sowohl dünnbesetzte als auch dichte Vektortypen speichern und abfragen kann, und wir erforschen weiterhin innovative Wege (zum Beispiel Better Binary Quantization (BBQ) & DiskBBQ), um die Suchgenauigkeit zu erhalten und gleichzeitig die Geschwindigkeit, Skalierbarkeit und Kosten im Zusammenhang mit vektorisierten Inhalten zu verbessern. Die Elasticsearch-Plattform bietet zudem integrierte Datenstabilität und Hochverfügbarkeit und beinhaltet Funktionen für das Datenlebenszyklusmanagement wie Searchable Snapshots , mit denen Sie selten genutzte oder langfristig aufzubewahrende Daten auf kostengünstigem Objektspeicher speichern können – und diese dennoch vollständig durchsuchbar sind.

Die Hybridsuche vereint das Beste aus allen Welten.

Hybride Suche (nicht nur hybride Abfrage!) kombiniert die Stärken der traditionellen lexikalischen Suche mit dem semantischen Verständnis von LLMs und der Vektorähnlichkeitssuche. Diese Synergie ermöglicht es, bereits in der Abrufphase hochrelevante Ergebnisse durch die flexiblen Abfragesyntaxoptionen einer Suchmaschine zu erzielen: absichtsgesteuerte Syntaxoptionen und Relevanzbewertung, multimodaler Datenabruf, Filterung, Aggregation und Biasing. Mit Suchsyntax wie ES|QL und mehrstufigen Abrufern können wir die traditionelle Suche flexibel mit semantischer Suche, Filtern und mehreren Reranking-Techniken in einer einzigen Anfrage kombinieren.

Einer der größten Vorteile der hybriden Suche ist, dass Ihre Abfragen eine spezialisierte Syntax für mehrere verschiedene Datentypen gleichzeitig verwenden können. Diese unterschiedlichen Abfragesyntaxen können nicht nur zum Auffinden von Ergebnissen verwendet werden, sondern auch als Filter oder Aggregationen der Ergebnisse. Ein Beispiel hierfür ist die Geodatenanalyse, eine der häufigsten Abfragearten, die oft mit anderen Syntaxelementen kombiniert wird. Sie können beispielsweise Abfragen durchführen, um Ergebnisse zu erhalten, deren Geokoordinaten sich innerhalb einer bestimmten Entfernung von einem Punkt befinden, oder um Aggregationen Ihrer Ergebnisse nach Region anzufordern, oder um Aggregationen anzufordern, um Bewegungen in/aus einer Zone zu verfolgen und Warnungen auszugeben. Mit der Hybridsuche haben Sie die Flexibilität, Syntaxen zu kombinieren, um Ergebnisse so präzise wie möglich zu liefern und die Inhalte abzurufen, die Ihrem Kontext am nächsten kommen.

Pause

Dieser erste Teil erzählt die Geschichte, wie die Vektorsuche die Art und Weise verändert hat, wie wir Daten abrufen können, und bereitet den Boden für die Veränderungen, die LLMs an den Abfragemechanismen mit sich gebracht haben, mit denen wir mit Daten interagieren. Wir werden so tun, als hätten wir das in mehrere Teile aufteilen müssen, damit LLMs es verstehen können, ohne den Kontext zu verlieren… ;-) Erfahren wir mehr darüber, warum das wichtig ist, in Teil II: Agentische KI und die Notwendigkeit des Kontext-Engineerings, und in Teil III kehren wir zu unserer Diskussion über die hybride Suche zurück.

Lernen Sie den Linear Retriever kennen!

In diesem Beitrag stellen wir den linear Retriever vor, unsere neueste Ergänzung zur Unterstützung der Hybridsuche! Im Gegensatz zu rrf berechnet der linear -Retriever eine gewichtete Summe aller Abfragen, die mit einem Dokument übereinstimmen. Dieser Ansatz bewahrt die relative Bedeutung jedes Dokuments innerhalb eines Ergebnissatzes und ermöglicht gleichzeitig eine präzise Kontrolle über den Einfluss jeder Abfrage auf das Endergebnis. Dadurch bietet es eine intuitivere und flexiblere Möglichkeit zur Feinabstimmung der Hybridsuche.

Definieren eines linearen Retrievers, bei dem die endgültige Punktzahl wie folgt berechnet wird:

Es ist so einfach wie:

Merken Sie, wie einfach und intuitiv es ist? (und sehr ähnlich zu rrf!) Mit dieser Konfiguration können Sie genau steuern, wie viel jeder Abfragetyp zum endgültigen Ranking beiträgt, im Gegensatz zu rrf, das sich ausschließlich auf relative Ränge stützt.

Ein Vorbehalt bleibt bestehen: knn -Wertungen können je nach verwendeter Ähnlichkeitsmetrik streng begrenzt sein. Beispielsweise liegen die Werte bei der Kosinusähnlichkeit oder dem Skalarprodukt einheitsnormalisierter Vektoren immer im Bereich [0, 1] . Im Gegensatz dazu sind bm25 -Werte weniger vorhersehbar und haben keine klar definierten Grenzen.

Skalierung der Ergebnisse: kNN vs. BM25

Eine Herausforderung bei der Hybridsuche besteht darin, dass verschiedene Retriever Ergebnisse auf unterschiedlichen Skalen liefern. Stellen Sie sich beispielsweise das folgende Szenario vor:

Abfrage A-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

Abfrage B-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

0,63

0,01

0,3

0,4

Sie können die Ungleichheit oben sehen: kNN -Wertungen liegen zwischen 0 und 1, während bm25 -Wertungen stark variieren können. Dieser Unterschied macht es schwierig, statische optimale Gewichte für die Kombination der Ergebnisse festzulegen.

Normalisierung zur Rettung: der MinMax-Normalisierer

Um dieses Problem zu beheben, haben wir einen optionalen minmax -Normalisierer eingeführt, der die Punktzahlen unabhängig für jede Abfrage mithilfe der folgenden Formel auf den [0, 1] -Bereich skaliert:

Dadurch bleibt die relative Wichtigkeit jedes Dokuments innerhalb des Ergebnissatzes einer Abfrage erhalten, was die Kombination von Bewertungen verschiedener Abrufer erleichtert. Durch die Normalisierung ergeben sich folgende Werte:

Abfrage A-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,01

0,005

0,000

Abfrage B-Ergebnisse:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,000

0,465

0,645

Alle Punktzahlen liegen jetzt im Bereich [0, 1] und die Optimierung der gewichteten Summe ist viel einfacher, da wir jetzt die (im Verhältnis zur Abfrage) Wichtigkeit eines Ergebnisses anstelle seiner absoluten Punktzahl erfassen und die Konsistenz über alle Abfragen hinweg aufrechterhalten.

Beispiel für einen linearen Retriever

Sehen wir uns nun ein Beispiel an, um zu zeigen, wie das oben genannte aussieht und wie der linear -Retriever einige der Mängel von rrf behebt. RRF basiert ausschließlich auf relativen Rängen und berücksichtigt keine tatsächlichen Punkteunterschiede. Beispielsweise bei diesen Ergebnissen:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

RRF-Score

0,03226

0,03252

0,03200

0,03125

rrf würde die Dokumente wie folgt einstufen:

Allerdings weist doc1 einen deutlich höheren bm25 -Score als die anderen auf, den rrf nicht erfasst, da nur die relativen Ränge berücksichtigt werden. Der linear -Retriever berücksichtigt in Kombination mit der Normalisierung sowohl die Punktzahlen als auch ihre Unterschiede korrekt und erzeugt so eine aussagekräftigere Rangfolge:

Dokument 1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1

0,01

0,005

0

Wie wir oben sehen können, wird das großartige Ranking von doc1 und score für bm25 richtig berücksichtigt und in den endgültigen Ergebnissen widergespiegelt. Darüber hinaus liegen jetzt alle Ergebnisse im Bereich [0, 1] , sodass wir sie viel intuitiver vergleichen und kombinieren können (und sogar Offline-Optimierungsprozesse erstellen können).

Alles zusammenfügen

Um den linear -Retriever mit Normalisierung optimal zu nutzen, würde die Suchanfrage folgendermaßen aussehen:

Dieser Ansatz kombiniert das Beste aus beiden Welten: Er behält die Flexibilität und intuitive Bewertung des linear -Retrievers bei und gewährleistet gleichzeitig eine konsistente Bewertungsskalierung mit MinMax-Normalisierung.

Wie alle unsere Retriever kann der linear -Retriever in jede Ebene eines hierarchischen Retrieverbaums integriert werden und bietet Unterstützung für Erklärbarkeit, Hervorhebung von Übereinstimmungen, Ausblenden von Feldern und mehr.

Wann Sie sich für den Linear Retriever entscheiden sollten und warum das einen Unterschied macht

Der linear -Retriever:

• Bewahrt die relative Bedeutung durch die Nutzung tatsächlicher Punktzahlen und nicht nur von Rängen.

• Ermöglicht eine Feinabstimmung mit gewichteten Beiträgen aus verschiedenen Abfragen.

• Verbessert die Konsistenz durch Normalisierung und macht die Hybridsuche robuster und vorhersehbarer.

Fazit

Der linear -Retriever ist bereits auf Elasticsearch Serverless und den Versionen 8.18 und 9.0 verfügbar! Weitere Beispiele und Konfigurationsparameter finden Sie auch in unserer Dokumentation. Probieren Sie es aus und sehen Sie, wie es Ihr Hybridsucherlebnis verbessern kann – wir freuen uns auf Ihr Feedback. Viel Spaß beim Suchen!

Quepid unterstützt Suchteams im Prozess der Bewertung der Suchqualität:

• Abfragesätze erstellen

• Erstellen Sie Beurteilungslisten

• Suchqualitätsmetriken berechnen

• Vergleichen Sie verschiedene Suchalgorithmen/Ranking-Systeme anhand berechneter Suchqualitätsmetriken.

Nehmen wir für unseren Blog an, wir betreiben eine Videothek und haben das Ziel, die Qualität unserer Suchergebnisse zu verbessern.

Voraussetzungen

Dieser Blog verwendet die Daten und Zuordnungen aus dem es-tmdb-Repository. Die Daten stammen von The Movie Database. Um dem Beispiel zu folgen, erstellen Sie einen Index namens tmdb mit den entsprechenden Zuordnungen und indizieren Sie die Daten. Ob Sie hierfür eine lokale Instanz einrichten oder eine Elastic Cloud-Bereitstellung verwenden, spielt keine Rolle – beides funktioniert einwandfrei. Für diesen Blog gehen wir von einer Elastic Cloud-Bereitstellung aus. Informationen zur Indizierung der Daten finden Sie in der README-Datei des es-tmdb-Repositorys.

Führen Sie eine einfache Suchabfrage im Titelfeld nach rocky durch, um zu bestätigen, dass Daten zum Durchsuchen vorhanden sind:

Es sollten 8 Ergebnisse angezeigt werden.

Melden Sie sich bei Quepid an.

Quepid ist ein Tool, mit dem Benutzer die Qualität von Suchergebnissen messen und Offline-Experimente durchführen können, um diese zu verbessern.

Sie können Quepid auf zwei Arten nutzen: entweder die kostenlose, öffentlich verfügbare Version unter https://app.quepid.com, oder richten Sie Quepid auf einem Rechner ein, auf den Sie Zugriff haben. Dieser Beitrag geht davon aus, dass Sie die kostenlose gehostete Version verwenden. Wenn Sie eine Quepid-Instanz in Ihrer Umgebung einrichten möchten, folgen Sie der Installationsanleitung.

Egal für welche Variante Sie sich entscheiden, Sie müssen ein Konto erstellen, falls Sie noch keins besitzen.

So richten Sie ein Quepid-Ticket ein

Quepid ist nach dem Prinzip „Fälle“ organisiert. Ein Case speichert Suchanfragen zusammen mit Relevanzeinstellungen und Informationen zur Herstellung einer Verbindung zu Ihrer Suchmaschine.

• Für Erstnutzer: Wählen Sie „Ersten Relevanzfall erstellen“.

• Wiederkehrende Benutzer können im Hauptmenü „Relevanzfälle“ auswählen und auf „+ Fall erstellen“ klicken.

Geben Sie Ihrem Fall einen beschreibenden Namen, z. B. „Filmsuche-Baseline“, da wir mit der Messung und Verbesserung unserer Baseline-Suche beginnen möchten.

Bestätigen Sie den Namen, indem Sie „Weiter“ auswählen.

Als nächstes stellen wir eine Verbindung von Quepid zur Suchmaschine her. Quepid kann Verbindungen zu einer Vielzahl von Suchmaschinen herstellen, darunter Elasticsearch.

Die Konfiguration hängt von Ihrer Elasticsearch- und Quepid-Konfiguration ab. Um Quepid mit einer Elastic Cloud-Bereitstellung zu verbinden, müssen wir CORS für unsere Elastic Cloud-Bereitstellung aktivieren und konfigurieren und einen API-Schlüssel bereithalten. Eine detaillierte Anleitung finden Sie in der entsprechenden Anleitung in der Quepid-Dokumentation.

Geben Sie Ihre Elasticsearch-Endpunktinformationen (https://YOUR_ES_HOST:PORT/tmdb/_search) und alle weiteren Informationen ein, die für die Verbindung erforderlich sind (im Falle einer Elastic Cloud-Bereitstellung den API-Schlüssel in den erweiterten Konfigurationsoptionen), testen Sie die Verbindung, indem Sie auf „pingen“ klicken, und wählen Sie „Weiter“ , um zum nächsten Schritt zu gelangen.

Nun legen wir fest, welche Felder im Fall angezeigt werden sollen. Wählen Sie alle Optionen aus, die unseren menschlichen Gutachtern später helfen, die Relevanz eines Dokuments für eine bestimmte Suchanfrage zu beurteilen.

Setzen Sie title als Titelfeld, lassen Sie _id als ID-Feld und fügen Sie overview, tagline, cast, vote_average, thumb:poster_path als zusätzliches Anzeigefeld hinzu. Im letzten Eintrag werden kleine Vorschaubilder der Filme in unseren Ergebnissen angezeigt, um uns und den menschlichen Gutachtern eine visuelle Orientierung zu geben.

Bestätigen Sie die Anzeigeeinstellungen durch Auswahl der Schaltfläche „Weiter“ .

Der letzte Schritt besteht darin, Suchanfragen zum Fall hinzuzufügen. Fügen Sie die drei Suchbegriffe „Star Wars“, „Harrison Ford“ und „Bester Actionfilm“ nacheinander über das Eingabefeld hinzu und klicken Sie auf „Weiter“.

Idealerweise enthält ein Fallbeispiel Abfragen, die reale Benutzerabfragen repräsentieren und verschiedene Abfragetypen veranschaulichen. Fürs Erste können wir uns vorstellen, dass „Star Wars“ eine Suchanfrage ist, die alle Suchanfragen nach Filmtiteln repräsentiert, „Harrison Ford“ eine Suchanfrage, die alle Suchanfragen nach Darstellern repräsentiert, und „Bester Actionfilm“ eine Suchanfrage, die alle Suchanfragen repräsentiert, die nach Filmen eines bestimmten Genres suchen. Dies wird üblicherweise als Query-Set bezeichnet.

In einem Produktionsszenario würden wir Anfragen aus Ereignisverfolgungsdaten stichprobenartig entnehmen, indem wir statistische Verfahren wie die Wahrscheinlichkeits-proportional-zur-Größe-Stichprobe anwenden, und diese Stichprobenanfragen in Quepid importieren, um Anfragen vom Anfang (häufige Anfragen) und vom Ende (seltene Anfragen) relativ zu ihrer Häufigkeit einzubeziehen, was bedeutet, dass wir häufigere Anfragen bevorzugen, ohne seltene auszuschließen.

Wählen Sie abschließend „Fertigstellen“ aus. Sie werden dann zur Falloberfläche weitergeleitet, wo Sie die drei definierten Abfragen sehen.

Anfragen und Informationsbedarf

Um zu unserem übergeordneten Ziel einer Bewertungsliste zu gelangen, müssen menschliche Gutachter ein Suchergebnis (in der Regel ein Dokument) für eine bestimmte Suchanfrage bewerten. Dies wird als Abfrage-/Dokumentpaar bezeichnet.

Manchmal scheint es einfach zu sein, anhand der Suchanfrage zu erkennen, was ein Benutzer wollte. Die Anfrage harrison ford zielt darauf ab, Filme zu finden, in denen der Schauspieler Harrison Ford die Hauptrolle spielt. Und die Anfrage action? Ich weiß, ich wäre versucht zu sagen, dass der Nutzer Filme aus dem Action-Genre sucht. Aber welche? Die neuesten, die beliebtesten, die laut Nutzerbewertungen besten? Oder möchte der Nutzer vielleicht alle Filme finden, die als „Action“ bezeichnet werden? In der Movie Database gibt es mindestens 12 (!) Filme mit dem Titel „Action“ , die sich hauptsächlich durch die Anzahl der Ausrufezeichen im Titel unterscheiden.

Zwei menschliche Gutachter können bei der Interpretation einer Anfrage, deren Intention unklar ist, zu unterschiedlichen Ergebnissen kommen. Das Informationsbedürfnis: Ein Informationsbedürfnis ist ein bewusstes oder unbewusstes Verlangen nach Informationen. Die Definition eines Informationsbedarfs hilft menschlichen Gutachtern bei der Beurteilung von Dokumenten im Hinblick auf eine Anfrage und spielt daher eine wichtige Rolle beim Aufbau von Beurteilungslisten. Erfahrene Anwender oder Fachexperten eignen sich gut zur Spezifizierung des Informationsbedarfs. Es ist eine gute Praxis, Informationsbedürfnisse aus der Perspektive des Nutzers zu definieren, da die Suchergebnisse dessen Bedürfnisse erfüllen sollten.

Informationsbedarf für die Suchanfragen unseres „Filmsuche-Baseline“-Szenarios:

1. Star Wars: Der Nutzer möchte Filme oder Serien aus dem Star Wars-Franchise finden. Möglicherweise relevant sind Dokumentarfilme über Star Wars.

2. Harrison Ford: Der Nutzer möchte Filme finden, in denen der Schauspieler Harrison Ford mitspielt. Möglicherweise relevant sind Filme, in denen Harrison Ford eine andere Rolle spielt, zum Beispiel die des Erzählers.

3. bester Actionfilm: Der Nutzer möchte Actionfilme finden, vorzugsweise solche mit einer hohen durchschnittlichen Nutzerbewertung.

So legen Sie den Informationsbedarf in Quepid fest

Um einen Informationsbedarf in Quepid zu definieren, greifen Sie auf die Fallschnittstelle zu:

1. Öffnen Sie eine Abfrage (z. B. Star Wars) und wählen Sie „Notizen umschalten“.

2. Tragen Sie im ersten Feld den Informationsbedarf und im zweiten Feld etwaige zusätzliche Anmerkungen ein:

3. Klicken Sie auf Speichern.

Für eine Handvoll Anfragen ist dieses Vorgehen in Ordnung. Wenn Sie Ihren Fall jedoch von drei auf 100 Anfragen erweitern (Quepid-Fälle liegen oft im Bereich von 50 bis 100 Anfragen), sollten Sie die Informationsbedürfnisse außerhalb von Quepid definieren (z. B. in einer Tabellenkalkulation) und diese dann über Import hochladen und Informationsbedürfnisse auswählen.

Erstellen Sie ein Team in Quepid und teilen Sie Ihr Ticket mit anderen

Gemeinsame Beurteilungen verbessern die Qualität von Relevanzbewertungen. So stellen Sie ein Team zusammen:

1. Navigieren Sie im Hauptmenü zu Teams .

2. Klicken Sie auf + Neu hinzufügen, geben Sie einen Teamnamen ein (z. B. "Suchrelevanzbewerter") und klicken Sie auf Erstellen.

3. Fügen Sie Mitglieder hinzu, indem Sie deren E-Mail-Adressen eingeben und auf Benutzer hinzufügen klicken.

4. Wählen Sie in der Falloberfläche die Option „Fall teilen“.

5. Wählen Sie das passende Team aus und bestätigen Sie die Auswahl.

Erstellen Sie ein Bewertungsbuch in Quepid

Ein Buch in Quepid ermöglicht es mehreren Bewertern, Anfrage-/Dokumentpaare systematisch zu bewerten. Um einen zu erstellen:

1. Gehen Sie in der Falloberfläche zu „Urteile“ und klicken Sie auf „+ Buch erstellen“.

2. Konfigurieren Sie das Buch mit einem aussagekräftigen Namen, weisen Sie es Ihrem Team zu, wählen Sie eine Bewertungsmethode (z. B. DCG@10) und legen Sie die Auswahlstrategie fest (einzelner oder mehrere Bewerter). Verwenden Sie für das Buch die folgenden Einstellungen:

• Name: „Filmsuche Skala 0-3“

• Teams, mit denen Sie dieses Buch teilen möchten: Markieren Sie das Kästchen neben dem Team, das Sie erstellt haben.

• Torschütze: DCG@10

3. Klicken Sie auf „Buch erstellen“.

Der Name ist beschreibend und enthält Informationen darüber, wonach gesucht wird („Filme“) sowie über die Skala der Bewertungen („0-3“). Der ausgewählte Scorer DCG@10 definiert die Berechnungsmethode der Suchmetrik. „DCG“ ist die Abkürzung für Discounted Cumulative Gain (diskontierter kumulativer Gewinn) und „@10“ ist die Anzahl der Ergebnisse von oben, die bei der Berechnung der Kennzahl berücksichtigt werden.

In diesem Fall verwenden wir eine Metrik, die den Informationsgewinn misst und ihn mit der Positionsgewichtung kombiniert. Möglicherweise gibt es andere Suchmetriken, die für Ihren Anwendungsfall besser geeignet sind, und die Auswahl der richtigen Metrik ist schon eine Herausforderung für sich.

Füllen Sie das Buch mit Abfrage-/Dokumentpaaren.

Um Abfrage-/Dokumentpaare für die Relevanzbewertung hinzuzufügen, befolgen Sie diese Schritte:

1. Navigieren Sie in der Fallübersicht zu „Urteile“.

2. Wählen Sie Ihr erstelltes Buch aus.

3. Klicken Sie auf „Buch füllen“ und bestätigen Sie mit der Auswahl von „Abfrage-/Dokumentpaare für Buch aktualisieren“.

Diese Aktion generiert Paare basierend auf den Top-Suchergebnissen für jede Suchanfrage, die dann von Ihrem Team ausgewertet werden können.

Lassen Sie Ihr Team aus menschlichen Bewertern urteilen

Die bisher abgeschlossenen Schritte waren überwiegend technischer und administrativer Natur. Nachdem diese notwendigen Vorbereitungen nun abgeschlossen sind, können wir unser Richterteam seine Arbeit machen lassen. Im Wesentlichen besteht die Aufgabe des Richters darin, die Relevanz eines bestimmten Dokuments für eine gegebene Anfrage zu bewerten. Das Ergebnis dieses Prozesses ist die Bewertungsliste, die alle Relevanzbezeichnungen für die bewerteten Abfragedokumentpaare enthält. Im Folgenden werden dieser Prozess und die zugehörige Benutzeroberfläche genauer erläutert.

Übersicht über die Schnittstelle von Human Rating

Die Human Rating-Schnittstelle von Quepid ist für effiziente Bewertungen konzipiert:

• Suchanfrage: Zeigt den Suchbegriff an.

• Informationsbedarf: Zeigt die Absicht des Nutzers.

• Bewertungsrichtlinien: Enthält Anweisungen für eine einheitliche Bewertung.

• Dokumentmetadaten: Enthält relevante Details zum Dokument.

• Bewertungsbuttons: Ermöglicht es den Bewertenden, Beurteilungen mithilfe entsprechender Tastenkombinationen zuzuweisen.

Verwendung der Human Rating-Schnittstelle

Als menschlicher Bewerter greife ich über die Buchübersicht auf die Benutzeroberfläche zu:

1. Navigieren Sie zur Falloberfläche und klicken Sie auf Urteile.

2. Klicken Sie auf „Weitere Urteile sind erforderlich!“.

Das System präsentiert ein Anfrage-/Dokumentpaar, das noch nicht bewertet wurde und weitere Beurteilungen erfordert. Dies wird durch die Auswahlstrategie des Buches bestimmt:

• Einzelbewerter: Eine einzige Bewertung pro Anfrage/Dokumentenpaar.

• Mehrere Gutachter: Bis zu drei Beurteilungen pro Anfrage/Dokumentenpaar.

Bewertungsanfrage/Dokumentpaare

Schauen wir uns ein paar Beispiele an. Wenn Sie dieser Anleitung folgen, werden Ihnen höchstwahrscheinlich verschiedene Filme angezeigt. Die Bewertungsgrundsätze bleiben jedoch unverändert.

Unser erstes Beispiel ist der Film „Heroes“ für die Suchanfrage Harrison Ford:

Wir betrachten zunächst die Suchanfrage, dann den Informationsbedarf und beurteilen anschließend den Film anhand der angegebenen Metadaten.

Dieser Film ist ein relevantes Ergebnis für unsere Suchanfrage, da Harrison Ford zur Besetzung gehört. Wir mögen neuere Filme subjektiv als relevanter einstufen, aber dies entspricht nicht unserem Informationsbedürfnis. Daher bewerten wir dieses Dokument mit „Perfekt“, was einer 3 auf unserer Bewertungsskala entspricht.

Unser nächstes Beispiel ist der Film „Ford v Ferrari“ für die Suchanfrage Harrison Ford:

In Anlehnung an diese Vorgehensweise beurteilen wir diese Anfrage/dieses Dokument, indem wir die Anfrage, den Informationsbedarf und anschließend prüfen, wie gut die Metadaten des Dokuments dem Informationsbedarf entsprechen.

Das ist ein schlechtes Ergebnis. Dieses Ergebnis sehen wir wahrscheinlich deshalb, weil einer unserer Suchbegriffe, „ford“, im Titel vorkommt. Harrison Ford spielt jedoch weder in diesem Film noch in irgendeiner anderen Rolle eine Rolle. Daher bewerten wir dieses Dokument mit „Mangelhaft“, was einer 0 auf unserer Bewertungsskala entspricht.

Unser drittes Beispiel ist der Film „Action Jackson“ für die Suchanfrage „bester Actionfilm“:

Das sieht nach einem Actionfilm aus, das Informationsbedürfnis ist also zumindest teilweise befriedigt. Der durchschnittliche Stimmenanteil liegt jedoch bei 5,4 von 10 Punkten. Und das macht diesen Film wahrscheinlich nicht zum besten Actionfilm unserer Sammlung. Dies würde mich als Richter dazu veranlassen, dieses Dokument mit „Mittelmäßig“ zu bewerten, was einer 1 auf unserer Bewertungsskala entspricht.

Diese Beispiele veranschaulichen den Prozess der Bewertung von Anfrage-/Dokumentpaaren mit Quepid im Besonderen, auf einer hohen Ebene und auch im Allgemeinen.

Best Practices für menschliche Bewerter

Die gezeigten Beispiele könnten den Eindruck erwecken, es sei unkompliziert, zu eindeutigen Urteilen zu gelangen. Doch die Einrichtung eines zuverlässigen menschlichen Bewertungsprogramms ist keine leichte Aufgabe. Es handelt sich um einen Prozess voller Herausforderungen, die die Qualität Ihrer Daten leicht beeinträchtigen können:

• Menschliche Bewerter können durch sich wiederholende Aufgaben ermüden.

• Persönliche Vorlieben können Urteile verzerren.

• Der Grad an Fachwissen variiert von Richter zu Richter.

• Bewerter jonglieren oft mit mehreren Aufgaben gleichzeitig.

• Die wahrgenommene Relevanz eines Dokuments entspricht möglicherweise nicht seiner tatsächlichen Relevanz für eine Suchanfrage.

Diese Faktoren können zu uneinheitlichen und qualitativ minderwertigen Beurteilungen führen. Aber keine Sorge – es gibt bewährte Best Practices, die Ihnen helfen können, diese Probleme zu minimieren und einen robusteren und zuverlässigeren Evaluierungsprozess aufzubauen:

• Konsequente Bewertung: Überprüfen Sie die Anfrage, den Informationsbedarf und die Dokumentenmetadaten der Reihe nach.

• Beachten Sie die Richtlinien: Verwenden Sie die Bewertungsrichtlinien, um eine einheitliche Bewertung zu gewährleisten. Die Bewertungsrichtlinien können Beispiele enthalten, wann welche Note zu vergeben ist, wodurch der Beurteilungsprozess veranschaulicht wird. Die Rücksprache mit menschlichen Gutachtern nach der ersten Bewertungsrunde erwies sich als gute Vorgehensweise, um schwierige Grenzfälle zu erkennen und herauszufinden, wo zusätzliche Unterstützung benötigt wird.

• Nutzen Sie die Antwortmöglichkeiten: Wenn Sie unsicher sind, verwenden Sie „Ich werde später urteilen“ oder „Ich kann es nicht sagen“ und geben Sie gegebenenfalls Erklärungen an.

• Machen Sie Pausen: Regelmäßige Pausen tragen dazu bei, die Urteilsfähigkeit aufrechtzuerhalten. Quepid sorgt für regelmäßige Pausen, indem es Konfetti knallen lässt, sobald ein menschlicher Bewerter eine Reihe von Beurteilungen abgeschlossen hat.

Durch Befolgen dieser Schritte etablieren Sie einen strukturierten und kollaborativen Ansatz zur Erstellung von Beurteilungslisten in Quepid und steigern so die Effektivität Ihrer Bemühungen zur Optimierung der Suchrelevanz.

Wie geht es weiter?

Wie geht es nun weiter? Bewertungslisten sind nur ein grundlegender Schritt zur Verbesserung der Qualität der Suchergebnisse. Hier die nächsten Schritte:

Berechnen Sie Metriken und beginnen Sie mit dem Experimentieren

Sobald die Bewertungslisten verfügbar sind, ist die Nutzung der Bewertungen und die Berechnung von Kennzahlen zur Suchqualität ein logischer nächster Schritt. Quepid berechnet die konfigurierte Metrik für den aktuellen Fall automatisch, sobald Urteile vorliegen. Metriken werden als „Scorer“ implementiert, und Sie können Ihre eigenen angeben, wenn die unterstützten Metriken Ihre bevorzugten nicht enthalten!

Gehen Sie zur Falloberfläche, navigieren Sie zu „Scorer auswählen“, wählen Sie DCG@10 und bestätigen Sie mit einem Klick auf „Scorer auswählen“. Quepid berechnet nun DCG@10 pro Abfrage und mittelt außerdem die Gesamtzahl der Abfragen, um die Qualität der Suchergebnisse für Ihren Fall zu quantifizieren.

Nachdem die Qualität Ihrer Suchergebnisse nun quantifiziert wurde, können Sie erste Experimente durchführen. Experimente beginnen mit der Aufstellung von Hypothesen. Ein Blick auf die drei Suchanfragen im Screenshot nach der Bewertung macht deutlich, dass die drei Suchanfragen hinsichtlich ihrer Suchqualitätsmetrik sehr unterschiedlich abschneiden: Star Wars schneidet ziemlich gut ab, Harrison Ford sieht in Ordnung aus, aber das größte Potenzial liegt bei Best Action Movie.

Durch die Erweiterung dieser Abfrage sehen wir ihre Ergebnisse und können in die Details eintauchen und untersuchen, warum Dokumente übereinstimmten und was ihre Punktzahl beeinflusst:

Durch Klicken auf „Abfrage erläutern“ und Aufrufen der Registerkarte „Parsing“ sehen wir, dass es sich bei der Abfrage um eine DisjunctionMaxxQuery handelt, die drei Felder durchsucht: cast, overview und title:

Als Suchmaschinenentwickler kennen wir in der Regel einige domänenspezifische Details unserer Suchplattform. In diesem Fall wissen wir möglicherweise, dass wir ein Genre- Feld haben. Fügen wir das der Suchanfrage hinzu und schauen wir, ob sich die Suchqualität verbessert.

Wir verwenden die Abfrage-Sandbox , die sich öffnet, wenn man in der Fallschnittstelle „Relevanz optimieren“ auswählt. Probieren Sie es aus, indem Sie das Suchfeld „Genres“ hinzufügen:

Klicken Sie auf „Meine Suchanfragen erneut ausführen“! Und sehen Sie sich die Ergebnisse an. Haben sie sich verändert? Leider nein. Wir haben nun viele Möglichkeiten zur Erkundung, im Grunde alle Abfrageoptionen, die Elasticsearch bietet:

• Wir könnten die Gewichtung des Feldes „Genres“ erhöhen.

• Wir könnten eine Funktion hinzufügen, die Dokumente anhand ihres durchschnittlichen Abstimmungsergebnisses höher priorisiert.

• Wir könnten eine komplexere Abfrage erstellen, die Dokumente nur dann nach ihrem Stimmendurchschnitt priorisiert, wenn eine starke Übereinstimmung der Genres vorliegt.

• …

Das Beste daran, all diese Optionen zu haben und sie in Quepid zu erkunden, ist, dass wir die Möglichkeit haben, die Auswirkungen nicht nur auf die eine Abfrage zu quantifizieren, die wir verbessern wollen, sondern auf alle Abfragen in unserem Fall. Das hindert uns daran, eine leistungsschwache Suchanfrage zu verbessern, indem wir die Qualität der Suchergebnisse für andere opfern. Wir können schnell und kostengünstig iterieren und den Wert unserer Hypothese ohne Risiko validieren, wodurch Offline-Experimente zu einer grundlegenden Fähigkeit aller Suchteams werden.

Messung der Interrater-Zuverlässigkeit

Selbst bei Aufgabenbeschreibungen, Informationsbedarfsdefinitionen und einer Benutzeroberfläche für menschliche Bewerter, wie sie Quepid bietet, können menschliche Bewerter unterschiedlicher Meinung sein.

Meinungsverschiedenheiten an sich sind nichts Schlechtes, ganz im Gegenteil: Die Messung von Meinungsverschiedenheiten kann Probleme aufdecken, die man angehen möchte. Relevanz kann subjektiv sein, Anfragen können mehrdeutig sein und Daten können unvollständig oder fehlerhaft sein. Fleiss' Kappa ist ein statistisches Maß für die Übereinstimmung zwischen Beurteilern. In Quepid gibt es ein Beispiel-Notebook, das Sie verwenden können. Um es zu finden, wählen Sie in der Hauptnavigation „Notebooks“ aus und wählen Sie das Notebook Fleiss Kappa.ipynb im Ordner „examples“ aus.

Fazit

Mit Quepid können Sie selbst die komplexesten Herausforderungen im Bereich der Suchrelevanz bewältigen und es wird ständig weiterentwickelt: Ab Version 8 unterstützt Quepid KI-generierte Beurteilungen, was besonders für Teams nützlich ist, die ihren Beurteilungsgenerierungsprozess skalieren möchten.

Mit Quepid-Workflows können Sie effizient skalierbare Beurteilungslisten erstellen – was letztendlich zu Suchergebnissen führt, die den Bedürfnissen der Nutzer wirklich gerecht werden. Mit den erstellten Bewertungslisten verfügen Sie über eine solide Grundlage, um die Relevanz der Suchergebnisse zu messen, Verbesserungen iterativ umzusetzen und ein besseres Nutzererlebnis zu schaffen.

Denken Sie bei Ihrem weiteren Vorgehen daran, dass die Relevanzoptimierung ein fortlaufender Prozess ist. Beurteilungslisten ermöglichen es Ihnen, Ihren Fortschritt systematisch zu bewerten, ihre größte Wirkung entfalten sie jedoch in Kombination mit Experimenten, Metrikanalysen und iterativen Verbesserungen.

Weitere Lektüre

• Quepid-Dokumentation:

  • Relevanz ist ein Teamsport

  • Quepid für menschliche Bewerter

  • Wie man Quepid mit Elastic Cloud verbindet

• Quepid GitHub-Repository

• Lernen Sie Pete kennen, eine Blogserie zur Verbesserung der E-Commerce-Suche

• Relevanz Slack: Treten Sie dem Kanal #quepid bei

Arbeiten Sie mit Open Source Connections zusammen, um Ihre Such- und KI-Fähigkeiten zu transformieren und Ihr Team zu befähigen, diese kontinuierlich weiterzuentwickeln. Unsere Erfolgsbilanz erstreckt sich über den gesamten Globus, wobei unsere Kunden durchweg dramatische Verbesserungen in der Suchqualität, der Teamleistung und der Geschäftsperformance erzielen. Kontaktieren Sie uns noch heute, um mehr zu erfahren.

Filter und Facetten im Vergleich

Bevor wir beginnen, definieren wir zunächst, was Filter und Facetten sind. Filter sind vordefinierte Attribute, die verwendet werden, um eine Reihe von Ergebnissen einzuschränken. Auf einem Marktplatz stehen beispielsweise Filter schon vor der eigentlichen Suche zur Verfügung. Der Benutzer kann vor der Suche nach „PS5“ eine Kategorie auswählen, zum Beispiel „Videospiele“, und so die Suche auf eine spezifischere Teilmenge anstatt der gesamten Datenbank eingrenzen. Dadurch erhöhen sich die Chancen auf relevantere Ergebnisse erheblich.

Facetten funktionieren ähnlich wie Filter, sind aber erst nach der Durchführung der Suche verfügbar. Mit anderen Worten: Die Suche liefert Ergebnisse, und auf deren Grundlage wird eine neue Liste von Verfeinerungsoptionen generiert. Bei der Suche nach einer PS5-Konsole werden beispielsweise Aspekte wie Speicherkapazität, Versandkosten und Farbe angezeigt, um den Nutzern bei der Auswahl des idealen Produkts zu helfen.

Nachdem wir nun Filter und Facetten definiert haben, wollen wir die Auswirkungen der klassischen und der auf maschinellem Lernen (ML) basierenden Ansätze auf ihre Implementierung und Verwendung erörtern. Jede Methode hat Vor- und Nachteile, die die Effizienz der Suche beeinflussen.

Klassischer Ansatz für Filter und Facetten

Bei diesem Ansatz werden Filter und Facetten manuell anhand vordefinierter Regeln definiert. Dies bedeutet, dass die zur Verfeinerung der Suche verfügbaren Attribute festgelegt und im Voraus geplant sind, wobei die Katalogstruktur und die Bedürfnisse der Nutzer berücksichtigt werden.

Auf einem Marktplatz können beispielsweise Kategorien wie „Elektronik“ oder „Mode“ über spezifische Filter wie Marke, Format und Preisspanne verfügen. Diese Regeln werden statisch erstellt, um eine einheitliche Sucherfahrung zu gewährleisten, erfordern jedoch manuelle Anpassungen, sobald neue Produkte oder Kategorien auftauchen.

Obwohl dieser Ansatz Vorhersagbarkeit und Kontrolle über die angezeigten Filter und Facetten bietet, kann er an seine Grenzen stoßen, wenn neue Trends entstehen, die eine dynamische Anpassung erfordern.

Vorteile:

• Vorhersagbarkeit und Kontrolle: Da Filter und Facetten manuell definiert werden, wird die Verwaltung einfacher.

• Geringe Komplexität: Es müssen keine Modelle trainiert werden.

• Wartungsfreundlichkeit: Da die Regeln vordefiniert sind, können Anpassungen und Korrekturen schnell vorgenommen werden.

Nachteile:

• Neuindizierung für neue Filter erforderlich: Wenn ein neues Attribut als Filter verwendet werden soll, muss der gesamte Datensatz neu indiziert werden, um sicherzustellen, dass die Dokumente diese Information enthalten.

• Fehlende dynamische Anpassung: Filter sind statisch und passen sich nicht automatisch an Änderungen im Nutzerverhalten an.

Implementierung von Filtern/Facetten – Klassischer Ansatz

In Dev Tools, Kibana, werden wir eine Demonstration von Filtern/Facetten mit dem klassischen Ansatz erstellen.

Zuerst definieren wir die Zuordnung zur Strukturierung des Index:

Die Felder „Marke“ und „Speicherort “ sind als Schlüsselwort festgelegt, sodass sie direkt in Aggregationen (Facetten) verwendet werden können. Das Preisfeld ist vom Typ Float, wodurch die Erstellung von Preisspannen ermöglicht wird.

Im nächsten Schritt werden die Produktdaten indexiert:

Nun wollen wir klassische Aspekte herausfiltern, indem wir die Ergebnisse nach Marke, Speicherort und Preisspanne gruppieren. In der Abfrage wurde Größe:0 definiert. In diesem Szenario besteht das Ziel darin, nur die Aggregationsergebnisse abzurufen, ohne die Dokumente einzubeziehen, die der Abfrage entsprechen.

Die Antwort wird Zählungen für Marke, Lager und Preis enthalten und so zur Erstellung von Filtern und Facetten beitragen.

Ansatz, der auf Machine Learning/KI basiert, für Filter und Facetten

Bei diesem Ansatz analysieren Modelle des maschinellen Lernens (ML), einschließlich Techniken der künstlichen Intelligenz (KI), Datenattribute, um relevante Filter und Facetten zu generieren. Anstatt sich auf vordefinierte Regeln zu stützen, nutzt ML/KI die Merkmale indexierter Daten. Dies ermöglicht die dynamische Entdeckung neuer Facetten und Filter.

Vorteile:

• Automatische Aktualisierungen: Neue Filter und Facetten werden automatisch generiert, ohne dass manuelle Anpassungen erforderlich sind.

• Entdeckung neuer Attribute: Es kann bisher unberücksichtigte Datenmerkmale als Filter identifizieren und so das Sucherlebnis bereichern.

• Reduzierter manueller Aufwand: Das Team muss keine Filterregeln mehr ständig definieren und aktualisieren, da die KI aus den verfügbaren Daten lernt.

Nachteile:

• Wartungsaufwand: Die Verwendung von Modellen kann eine Vorvalidierung erfordern, um die Konsistenz der generierten Filter sicherzustellen.

• Erfordert Expertise in den Bereichen Maschinelles Lernen und Künstliche Intelligenz: Die Lösung erfordert qualifizierte Fachkräfte, die die Modellleistung feinabstimmen und überwachen.

• Risiko irrelevanter Filter: Wenn das Modell nicht gut kalibriert ist, kann es Facetten generieren, die für die Benutzer nicht nützlich sind.

• Kosten: Der Einsatz von ML und KI kann die Inanspruchnahme von Dienstleistungen Dritter erfordern, was die Betriebskosten erhöht.

Es ist wichtig zu beachten, dass selbst bei einem gut kalibrierten Modell und einer gut formulierten Eingabeaufforderung die generierten Facetten noch einen Überprüfungsschritt durchlaufen sollten. Diese Validierung kann manuell oder auf der Grundlage von Moderationsregeln erfolgen, um sicherzustellen, dass die Inhalte angemessen und sicher sind. Dies ist zwar nicht unbedingt ein Nachteil, aber dennoch ein wichtiger Aspekt, um die Qualität und Eignung der Facetten sicherzustellen, bevor sie den Nutzern zur Verfügung gestellt werden.

Implementierung von Filtern/Facetten – KI-Ansatz

In dieser Demonstration verwenden wir ein KI-Modell, um Produkteigenschaften automatisch zu analysieren und relevante Attribute vorzuschlagen. Mithilfe einer gut strukturierten Eingabeaufforderung extrahieren wir Informationen aus dem Katalog und wandeln diese in Filter und Facetten um. Im Folgenden stellen wir jeden einzelnen Schritt des Prozesses vor.

Zunächst werden wir die Inference API verwenden, um einen Endpunkt für die Integration mit einem ML-Dienst zu registrieren. Nachfolgend ein Beispiel für die Integration mit dem Dienst von OpenAI.

Nun definieren wir die Pipeline, um die Eingabeaufforderung auszuführen und die vom Modell generierten neuen Filter zu erhalten.

Eine Simulation dieser Pipeline für das Produkt „PlayStation 5“ wird mit folgender Beschreibung durchgeführt:

Atemberaubendes Spielerlebnis: Bestaunen Sie die beeindruckende Grafik und erleben Sie die Funktionen der neuen PS5.

Atemberaubendes Eintauchen: Entdecken Sie ein intensiveres Spielerlebnis mit Unterstützung für haptisches Feedback, adaptive Trigger und 3D-Audiotechnologie.

Schlankes Design: Mit der PS5 Digital Edition erhalten Gamer leistungsstarke Gaming-Technologie in einem schlanken, kompakten Design.

1 TB Speicherplatz: Dank 1 TB integriertem SSD-Speicher sind Ihre Lieblingsspiele immer griffbereit und warten nur darauf, von Ihnen gespielt zu werden.

Abwärtskompatibilität und Game Boost: Die PS5-Konsole kann über 4.000 PS4-Spiele abspielen. Mit Game Boost können Sie sogar in einigen der besten PS4-Konsolenspiele schnellere und flüssigere Bildwiederholraten genießen.

Betrachten wir nun die von dieser Simulation generierte Prompt-Ausgabe.

Nun wird dem neuen Index ein neues Feld, dynamic_facets, hinzugefügt, um die von der KI generierten Facetten zu speichern.

Mithilfe der Reindex API werden wir den Videospiele- Index auf videogames_1 neu indizieren und dabei die generate_filter_ai- Pipeline anwenden. Diese Pipeline generiert während der Indizierung automatisch dynamische Facetten.

Nun führen wir eine Suche durch und rufen die neuen Filter ab:

Ergebnisse:

Zur Veranschaulichung der Umsetzung der einzelnen Aspekte folgt unten ein einfaches Frontend:

Der hier dargestellte UI-Code befindet sich hier.

Fazit

Beide Ansätze zur Erstellung von Filtern und Facetten haben ihre Vor- und Nachteile. Der klassische Ansatz, der auf manuellen Regeln basiert, bietet Kontrolle und niedrigere Kosten, erfordert jedoch ständige Aktualisierungen und passt sich nicht dynamisch an neue Produkte oder Funktionen an.

Andererseits automatisiert der auf KI und maschinellem Lernen basierende Ansatz die Facettenextraktion, wodurch die Suche flexibler wird und die Entdeckung neuer Attribute ohne manuelles Eingreifen ermöglicht wird. Allerdings kann dieser Ansatz in der Umsetzung und Aufrechterhaltung komplexer sein und erfordert eine Kalibrierung, um konsistente Ergebnisse zu gewährleisten.

Die Wahl zwischen klassischen und KI-basierten Ansätzen hängt von den Bedürfnissen und der Komplexität des Unternehmens ab. Bei einfacheren Szenarien, in denen die Datenattribute stabil und vorhersehbar sind, kann der klassische Ansatz effizienter und einfacher zu warten sein, wodurch unnötige Kosten für Infrastruktur und KI-Modelle vermieden werden. Andererseits kann der Einsatz von ML/KI zur Extraktion von Facetten einen erheblichen Mehrwert bieten, das Sucherlebnis verbessern und die Filterung intelligenter gestalten.

Wichtig ist es zu beurteilen, ob die Automatisierung die Investition rechtfertigt oder ob eine traditionellere Lösung die Geschäftsanforderungen bereits effektiv erfüllt.

Dieser Blogbeitrag untersucht, wie große Sprachmodelle (LLMs) verwendet werden können, um Synonyme automatisch zu identifizieren und zu generieren, sodass diese Begriffe programmatisch in die Synonym-API von Elasticsearch geladen werden können.

Wann verwendet man Synonyme?

Die Verwendung von Synonymen kann im Vergleich zur Vektorsuche eine schnellere und kostengünstigere Lösung sein. Die Implementierung ist einfacher, da sie keine tiefgreifenden Kenntnisse über Einbettungen oder einen komplexen Vektor-Ingestionsprozess erfordert.

Darüber hinaus ist der Ressourcenverbrauch geringer, da die Vektorsuche für die Einbettungsindizierung und den Abruf eine größere Speicherkapazität und einen größeren Arbeitsspeicher benötigt.

Ein weiterer wichtiger Aspekt ist die Regionalisierung der Suche. Mithilfe von Synonymen ist es möglich, Begriffe an die jeweilige Sprache und die lokalen Gepflogenheiten anzupassen. Dies ist in Situationen nützlich, in denen Einbettungen möglicherweise nicht mit regionalen Ausdrücken oder länderspezifischen Begriffen übereinstimmen. Beispielsweise können manche Wörter oder Akronyme je nach Region unterschiedliche Bedeutungen haben, werden aber von den lokalen Nutzern selbstverständlich als Synonyme behandelt. In Brasilien ist das recht üblich. „Abacaxi“ und „ananás“ bezeichnen die gleiche Frucht (Ananas), wobei der zweite Begriff in einigen Regionen des Nordostens gebräuchlicher ist. Ähnlich verhält es sich mit dem im Südosten bekannten „pão francês“, das im Nordosten als „pão careca“ bekannt ist.

Wie kann man LLMs verwenden, um Synonyme zu generieren?

Um Synonyme automatisch zu erhalten, können wir LLMs verwenden, die den Kontext eines Begriffs analysieren und passende Variationen vorschlagen. Dieser Ansatz ermöglicht die dynamische Erweiterung von Synonymen und gewährleistet so eine umfassendere und genauere Suche, ohne auf ein festes Wörterbuch angewiesen zu sein.

In dieser Demonstration verwenden wir ein LLM, um Synonyme für E-Commerce-Produkte zu generieren. Viele Suchanfragen liefern aufgrund von Variationen in den Suchbegriffen nur wenige oder gar keine Ergebnisse. Mit Synonymen können wir dieses Problem lösen. Eine Suche nach „Smartphone“ kann beispielsweise verschiedene Modelle von Mobiltelefonen umfassen, um sicherzustellen, dass die Nutzer die Produkte finden, die sie suchen.

Voraussetzungen

Bevor wir beginnen, müssen wir die Umgebung einrichten und die erforderlichen Abhängigkeiten definieren. Wir werden die von Elastic bereitgestellte Lösung nutzen, um Elasticsearch und Kibana lokal in Docker auszuführen. Der Code wird in Python, Version 3.9.6, mit folgenden Abhängigkeiten geschrieben:

Erstellung des Produktindex

Zunächst erstellen wir einen Index der Produkte ohne Synonymunterstützung. Dies ermöglicht es uns, Abfragen zu validieren und sie dann mit einem Index zu vergleichen, der Synonyme enthält.

Um den Index zu erstellen, laden wir einen Produktdatensatz per Massenimport mit folgendem Befehl in den Kibana DevTools:

Synonyme mit LLM generieren

In diesem Schritt verwenden wir ein LLM, um dynamisch Synonyme zu generieren. Um dies zu erreichen, werden wir die OpenAI-API integrieren und ein geeignetes Modell sowie eine entsprechende Eingabeaufforderung definieren. Der LLM erhält die Produktkategorie und den Produktnamen, wobei darauf geachtet wird, dass die Synonyme kontextuell relevant sind.

Aus dem erstellten Produktindex rufen wir alle Artikel der Kategorie „Elektronik“ ab und senden deren Namen an das LLM. Die erwartete Ausgabe sieht in etwa so aus:

Mit den generierten Synonymen können wir diese mithilfe der Synonyms API in Elasticsearch registrieren.

Synonyme mit der Synonyms-API verwalten

Die Synonyms-API bietet eine effiziente Möglichkeit, Synonymgruppen direkt im System zu verwalten. Jedes Synonymset besteht aus Synonymregeln, nach denen eine Gruppe von Wörtern bei Suchanfragen als gleichwertig behandelt wird.

Beispiel für die Erstellung eines Synonymsets

Dadurch entsteht eine Menge namens „meine-Synonyme-Menge“, in der „hello“ und „hi“ sowie „bye“ und „goodbye“ als gleichwertig behandelt werden.

Implementierung der Synonymerstellung für den Produktkatalog

Nachfolgend ist die Methode aufgeführt, die für den Aufbau eines Synonymsets und dessen Einfügen in Elasticsearch zuständig ist. Die Synonymregeln werden auf der Grundlage der vom LLM vorgeschlagenen Synonymzuordnung generiert. Jede Regel hat eine ID, die dem Produktnamen im Slug-Format entspricht, und die vom LLM berechnete Liste der Synonyme.

Nachfolgend die Anfragenutzlast zum Erstellen des Synonymsets:

Nachdem im Cluster ein Synonymset erstellt wurde, können wir zum nächsten Schritt übergehen, nämlich der Erstellung eines neuen Index mit Synonymunterstützung unter Verwendung des definierten Sets.

Der vollständige Python-Code mit den von LLM generierten Synonymen und der durch die Synonyms-API definierten Erstellung von Synonymsätzen ist unten aufgeführt:

Erstellen eines Index mit Synonymunterstützung

Es wird ein neuer Index erstellt, in dem alle Daten aus dem Index products neu indiziert werden. Dieser Index verwendet synonyms_filter, der den zuvor erstellten products-synonyms-set anwendet.

Nachfolgend die Indexzuordnung, die für die Verwendung von Synonymen konfiguriert ist:

Neuindizierung des Index products

Nun werden wir die Reindex-API verwenden, um die Daten vom Index products in den neuen Index products_02 zu migrieren, der auch Synonymunterstützung beinhaltet. Der folgende Code wurde in den Kibana DevTools ausgeführt:

Nach der Migration wird der Index products_02 gefüllt sein und kann Suchanfragen mithilfe des konfigurierten Synonymsets validieren.

Suche mit Synonymen validieren

Lassen Sie uns die Suchergebnisse der beiden Indizes vergleichen. Wir werden die gleiche Abfrage auf beiden Indizes ausführen und überprüfen, ob die Synonyme verwendet werden, um Ergebnisse abzurufen.

Suche im Index products (ohne Synonyme)

Wir werden Kibana verwenden, um Suchvorgänge durchzuführen und die Ergebnisse zu analysieren. Im Menü „Analytics > Discovery“ erstellen wir eine Datenansicht, um die Daten aus den von uns erstellten Indizes zu visualisieren.

Klicken Sie innerhalb von Discovery auf Datenansicht und definieren Sie einen Namen und ein Indexmuster. Für den Index "Produkte" verwenden wir das Muster "Produkte ". Anschließend wiederholen wir den Vorgang, um eine neue Datenansicht für den Index "products_02" zu erstellen, wobei wir das Muster "products_02 " verwenden.

Nachdem die Datenansichten konfiguriert sind, können wir zu Analytics > Discovery zurückkehren und die Validierungen starten.

Hier erhalten wir nach Auswahl der DataView-Produkte und einer Suche nach dem Begriff „Tablet“ keine Ergebnisse, obwohl wir wissen, dass es Produkte wie „Kindle Paperwhite“ und „Apple iPad Air“ gibt.

Suche im Index products_02 (unterstützt Synonyme)

Bei der Durchführung derselben Abfrage in der Datenansicht "products_synonyms", die Synonyme unterstützt, wurden die Produkte erfolgreich abgerufen. Dies beweist, dass die konfigurierte Synonymgruppe korrekt funktioniert und sicherstellt, dass verschiedene Variationen der Suchbegriffe die erwarteten Ergebnisse liefern.

Das gleiche Ergebnis lässt sich erzielen, indem man dieselbe Abfrage direkt in den Kibana DevTools ausführt. Suchen Sie einfach im Index products_02 mithilfe der Elasticsearch Search API:

Fazit

Die Implementierung von Synonymen in Elasticsearch verbesserte die Genauigkeit und Abdeckung der Produktkatalogsuche. Der entscheidende Unterschied bestand in der Verwendung eines LLM, das Synonyme automatisch und kontextbezogen generierte, wodurch die Notwendigkeit vordefinierter Listen entfiel. Das Modell analysierte Produktnamen und Kategorien und stellte dabei relevante Synonyme für den E-Commerce sicher.

Darüber hinaus vereinfachte die Synonyms-API die Wörterbuchverwaltung, sodass Synonymsätze dynamisch geändert werden können. Mit diesem Ansatz wurde die Suche flexibler und besser an unterschiedliche Suchanfragen der Nutzer anpassbar.

Dieser Prozess kann durch neue Daten und Modellanpassungen kontinuierlich verbessert werden, wodurch ein immer effizienteres Forschungserlebnis gewährleistet wird.

Referenzen

Elasticsearch lokal ausführen

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

Synonyms API

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

Aufbauend auf den Beispielen aus Teil 1 befasst sich dieser Blog damit, wie verschiedene Techniken und das leistungsstarke Toolkit zur Vektorsuche von Elasticsearch zur Bereitstellung später Interaktionsvektoren für umfassende Produktions-Workloads genutzt werden können.

Die vollständigen Code-Beispiele finden Sie auf GitHub.

Herausforderungen bei späten Interaktionsmodellen

ColPali erstellt über 1000 Vektoren pro Seite für die Dokumente in unserem Index.

Dies führt zu zwei Herausforderungen bei der Arbeit mit späten Interaktionsvektoren:

1. Speicherplatz: Das Speichern all dieser Vektoren auf Festplatten wird einen erheblichen Speicherplatzbedarf verursachen, was in großem Maßstab teuer wird.

2. Berechnung: Wenn wir unsere Dokumente mit dem maxSimDotProduct()-Vergleich bewerten, müssen wir alle diese Vektoren für jedes unserer Dokumente mit den N-Vektoren unserer Abfrage vergleichen.

Sehen wir uns einige Techniken zur Bewältigung dieser Probleme an.

Techniken zur Optimierung von späten Interaktionsmodellen

Bit-Vektoren

Um den Festplattenspeicher zu reduzieren, können wir die Bilder in Bitvektoren komprimieren. Wir können eine einfache Python-Funktion verwenden, um unsere Multivektoren in Bitvektoren umzuwandeln.

Das Kernkonzept der Funktion ist einfach: Werte über 0 werden zu 1 und Werte unter 0 werden zu 0. Daraus ergibt sich ein Array aus Nullen und Einsen, das wir dann in eine Hexadezimalzeichenfolge umwandeln, die unseren Bitvektor darstellt.

Für unser Index-Mapping setzen wir den Parameter element_type auf bit:

Nachdem wir alle unsere neuen Bitvektoren in unseren Index geschrieben haben, können wir unsere Bitvektoren mit folgendem Code bewerten:

Durch einen geringen Verlust an Genauigkeit können wir den Hamming-Abstand (maxSimInvHamming(...)) verwenden, wodurch Optimierungen wie Bitmasken oder SIMD genutzt werden können. Mehr über Bitvektoren und den Hamming-Abstand erfahren Sie in unserem Blog.

Alternativ können wir unseren Abfragevektor nicht in Bitvektoren umwandeln und mit dem vollwertigen späten Interaktionsvektor suchen:

Hierbei werden unsere Vektoren mithilfe einer asymmetrischen Ähnlichkeitsfunktion verglichen.

Betrachten wir den regulären Hamming-Abstand zwischen zwei Bitvektoren. Angenommen, wir haben einen Dokumentenvektor D:

Und ein Abfragevektor Q:

Eine einfache binäre Quantisierung transformiert Vektoren D in 10101101 und Q in 11111011. Um den Hamming-Abstand zu ermitteln, benötigen wir direkte Bit-Mathematik – die extrem schnell ist. In diesem Fall ist der Hamming-Abstand 01010110, was einer Bitanzahl von 4 entspricht. Das Scoring wird also zum Kehrwert dieses Hamming-Abstands. Denken Sie daran, dass ähnlichere Vektoren einen KLEINEREN Hamming-Abstand aufweisen, sodass durch die Umkehrung ähnlichere Vektoren eine höhere Bewertung erhalten können. Konkret wäre hier der Wert 1/4 = 0.25.

Beachten Sie jedoch, wie wir die Größenordnung jeder Dimension verlieren. Ein 1 ist ein 1. Für Q verschwindet also der Unterschied zwischen 0.01 und 0.79. Da wir lediglich gemäß >0 quantisieren, können wir einen kleinen Trick anwenden, bei dem der Q-Vektor nicht quantisiert wird. Dies ermöglicht zwar keine extrem schnellen Bitoperationen, hält aber die Speicherkosten niedrig, da D weiterhin quantisiert wird.

Das bedeutet, dass die in Q enthaltenen Informationen erhalten bleiben, wodurch die Qualität der Entfernungsschätzung verbessert und der Speicherbedarf gering gehalten wird.

Durch die Verwendung von Bitvektoren können wir bei der Abfragezeit deutlich an Festplattenspeicher und Rechenaufwand sparen. Aber wir können noch mehr tun.

Mittlere Vektoren

Um unsere Suche auf Hunderttausende von Dokumenten auszuweiten, reichen selbst die Leistungsvorteile, die Bitvektoren bieten, nicht aus. Für die Skalierung dieser Art von Workloads werden wir die HNSW-Indexstruktur von Elasticsearch für die Vektorsuche nutzen wollen.

ColPali generiert etwa tausend Vektoren pro Dokument. Das sind zu viele, um sie zu unserem HNSW-Graph hinzuzufügen. Daher müssen wir die Anzahl der Vektoren reduzieren. Dazu können wir eine einzige Repräsentation der Bedeutung des Dokuments erstellen, indem wir den Durchschnitt aller Dokumentvektoren bilden, die von ColPali beim Einbetten unseres Bildes erzeugt werden.

Aktuell ist das innerhalb von Elastic selbst nicht möglich, daher müssen wir die Vektoren vorverarbeiten, bevor wir sie in Elasticsearch ingestieren können.

Das ist mit Logstash- oder Ingest-Pipelines möglich, jedoch verwenden wir hier eine einfache Python-Funktion:

Außerdem normalisieren wir den Vektor, damit wir die Ähnlichkeit des Skalarprodukts verwenden können.

Nachdem wir alle unsere ColPali-Vektoren in mittlere Vektoren umgewandelt haben, können wir sie in unser dense_vector-Feld indexieren:

Wir müssen berücksichtigen, dass dadurch die gesamte Festplattennutzung erhöht wird, da wir neben unseren späten Interaktionsvektoren mehr Informationen speichern. Zusätzlich werden wir zusätzlichen RAM für den HNSW-Graphen verwenden, wodurch wir die Suche auf Milliarden von Vektoren skalieren können. Um den RAM-Verbrauch zu reduzieren, können wir unser beliebtes BBQ-Feature nutzen. Dadurch erhalten wir schnelle Suchergebnisse über enorme Datensätze, die sonst nicht möglich wären.

Jetzt suchen wir einfach mit der kNN-Abfrage, um unsere relevantesten Dokumente zu finden.

Das bisher beste Ergebnis ist leider auf Platz 3 abgerutscht.

Um dieses Problem zu beheben, können wir ein mehrstufiges Abrufen durchführen. Im ersten Schritt verwenden wir die kNN-Abfrage, um unter Millionen von Dokumenten die besten Kandidaten für unsere Abfrage zu suchen. Im zweiten Schritt ordnen wir nur die besten k (hier: 10) mit der höheren Genauigkeit der späten ColPali-Interaktionsmodelle neu. 

Hier verwenden wir den in 8.18 vorgestellten Rescore-Retriever zum Reranking unserer Ergebnisse. Nach dem Rescoring sehen wir, dass unser bester Treffer wieder an erster Stelle steht.

Hinweis: In einer Produktionsanwendung können wir einen viel höheren Wert für k als 10 verwenden, da die Max-Sim-Funktion immer noch vergleichsweise leistungsfähig ist.

Token-Pooling

Token-Pooling reduziert die Sequenzlänge von Multi-Vektor-Einbettungen, indem redundante Informationen wie weiße Hintergrund-Patches gepoolt werden. Diese Technik verringert die Anzahl der Einbettungen, während der Großteil des Seitensignals erhalten bleibt.

Token-Pooling funktioniert, indem ähnliche Token-Einbettungen innerhalb eines Dokuments mithilfe eines Clustering-Algorithmus in Cluster gruppiert werden. Anschließend wird der Mittelwert der Vektoren in jedem Cluster berechnet, um eine einzige, aggregierte Darstellung zu erzeugen. Dieser aggregierte Vektor ersetzt die ursprünglichen Token in der Gruppe und reduziert die Gesamtzahl der Vektoren ohne nennenswerten Verlust des Dokumentsignals.

Im ColPali-Paper wird für die meisten Datensätze ein anfänglicher Pooling-Faktor von 3 vorgeschlagen, der 97,8 % der ursprünglichen Leistung beibehält und gleichzeitig die Gesamtzahl der Vektoren um 66,7 % reduziert. 

Aber Vorsicht ist geboten: Der Datensatz „Shift“, der sehr dichte, textlastige Dokumente mit wenig Leerzeichen enthält, zeigt eine rapide Leistungsverschlechterung bei steigenden Poolfaktoren.

Um die gepoolten Vektoren zu erstellen, können wir die Bibliothek colpali_engine verwenden:

Wir haben nun einen Vektor, der in seinen Dimensionen um etwa 66,7 % reduziert wurde. Wir indexieren ihn wie üblich und können mit unserer maxSimDotProduct()-Funktion danach suchen.

Wir erzielen gute Suchergebnisse, auch wenn die Genauigkeit der Ergebnisse dadurch etwas beeinträchtigt wird.

Tipp: Mit einem höheren pool_factor (100–200) kann man auch einen Mittelweg zwischen der mittleren Vektorlösung und der hier besprochenen Lösung finden. Bei etwa 5–10 Vektoren pro Dokument ist es sinnvoll, diese in einem verschachtelten Feld zu indizieren, um den HNSW-Index optimal zu nutzen.

Cross-Encoder vs. späte Interaktion vs. Bi-Encoder

Auf Grundlage unserer bisherigen Erkenntnisse stellt sich die Frage: Wo ordnen sich späte Interaktionsmodelle wie ColPali oder ColBERT im Vergleich zu anderen KI-gestützten Retrieval-Techniken ein?

Obwohl die Max-Sim-Funktion im Vergleich zu Cross-Encodern günstiger ist, erfordert sie dennoch deutlich mehr Vergleiche und Berechnungen als die Vektorsuche mit Bi-Encodern, bei denen wir einfach zwei Vektoren für jedes Abfrage-Dokumentpaar vergleichen.

Aus diesem Grund empfehlen wir, späte Interaktionsmodelle generell nur für das Reranking der besten k-Suchergebnisse zu verwenden. Wir halten das auch im Namen des Feldtyps fest: rank_vectors.

Aber was ist mit dem Cross-Encoder? Sind späte Interaktionsmodelle besser, weil sie zum Zeitpunkt der Abfrage günstiger auszuführen sind? Wie so oft lautet die Antwort: Es kommt darauf an. Cross-Encoder liefern in der Regel qualitativ hochwertigere Ergebnisse, sind aber sehr rechenintensiv, da die abgefragten Dokumentenpaare das Transformatormodell vollständig durchlaufen müssen. Sie profitieren außerdem davon, dass sie keine Indizierung von Vektoren erfordern und zustandslos arbeiten können. Dies führt zu Folgendem:

• Weniger verwendeter Festplattenspeicher

• Ein einfacheres System

• Höhere Qualität der Suchergebnisse

• Höhere Latenz und daher keine Möglichkeit, ein umfassendes Reranking vorzunehmen

Andererseits können späte Interaktionsmodelle einen Teil dieser Berechnungen beim Indizieren auslagern, wodurch die Abfrage kostengünstiger wird. Der Preis, den wir dafür zahlen, ist, dass wir die Vektoren indizieren müssen, was unsere Indizierungspipelines komplexer macht und auch mehr Festplattenspeicher zum Speichern dieser Vektoren erfordert.

Insbesondere im Fall von ColPali ist die Analyse von Informationen aus Bildern sehr teuer, da sie viele Daten enthalten. In diesem Fall verschiebt sich der Kompromiss zugunsten eines späten Interaktionsmodells wie ColPali, da die Bewertung dieser Informationen zur Abfragezeit zu ressourcenintensiv bzw. zu langsam wäre.

Bei einem späten Interaktionsmodell wie ColBERT, das wie die meisten Cross-Encoder (z. B. elastic-rerank-v1) mit Textdaten arbeitet, könnte die Entscheidung eher zugunsten des Cross-Encoders ausfallen, um von den Festplattenspeicherersparnissen und der Einfachheit zu profitieren.

Wir empfehlen Ihnen, die Vor- und Nachteile für Ihren Anwendungsfall abzuwägen und mit den verschiedenen Tools von Elasticsearch zu experimentieren, um die besten Suchanwendungen zu entwickeln.

Fazit

In diesem Blog befassen wir uns mit verschiedenen Techniken zur Optimierung von späten Interaktionsmodellen wie ColPali für umfassende Vektorsuche in Elasticsearch. Während späte Interaktionsmodelle ein gutes Gleichgewicht zwischen Retrieval-Effizienz und Ranking-Qualität bieten, bringen sie auch Herausforderungen in Bezug auf Speicher und Berechnung mit sich.

Für die Bewältigung dieser Herausforderungen haben wir Folgendes untersucht:

• Bitvektoren zur deutlichen Reduzierung des Festplattenspeichers bei gleichzeitiger Nutzung effizienter Ähnlichkeitsberechnungen wie dem Hamming-Abstand oder der asymmetrischen maximalen Ähnlichkeit.

• Mittlere Vektoren zur Komprimierung mehrerer Einbettungen in eine einzige dichte Darstellung, wodurch ein effizientes Abrufen mit HNSW-Indizierung ermöglicht wird.

• Token-Pooling zur intelligenten Zusammenführung redundanter Einbettungen unter Beibehaltung der semantischen Integrität, wodurch der Rechenaufwand zum Zeitpunkt der Abfrage reduziert wird.

Elasticsearch bietet ein leistungsstarkes Toolkit zur Anpassung und Optimierung von Suchanwendungen gemäß Ihren Anforderungen. Unabhängig davon, ob Sie Retrieval-Geschwindigkeit, Ranking-Qualität oder Speichereffizienz priorisieren – mit diesen Tools und Techniken können Sie die Leistung und Qualität entsprechend den Anforderungen Ihrer Anwendungen in der Praxis aufeinander abstimmen.