Sie fragen sich vielleicht, warum Sie überhaupt mehrere Diagramme verwenden? Dies ist ein Nebeneffekt einer Architekturentscheidung in Lucene: unveränderliche Segmente. Wie bei den meisten architektonischen Entscheidungen gibt es Vor- und Nachteile. Beispielsweise haben wir vor Kurzem Serverless Elasticsearch allgemein zugänglich gemacht. In diesem Zusammenhang haben wir durch unveränderliche Segmente erhebliche Vorteile erzielt, darunter eine effiziente Indexreplikation und die Möglichkeit, die Index- und Abfrageberechnung zu entkoppeln und unabhängig voneinander automatisch zu skalieren. Bei der Vektorquantisierung bieten uns Segmentzusammenführungen die Möglichkeit, Parameter zu aktualisieren, um sie an die Dateneigenschaften anzupassen. In diesem Sinne sind wir der Meinung, dass die Möglichkeit, Datenmerkmale zu messen und Indexierungsentscheidungen zu überprüfen, noch weitere Vorteile mit sich bringt.

In diesem Beitrag besprechen wir die Arbeit, die wir geleistet haben, um den Aufwand für die Erstellung mehrerer HNSW-Diagramme deutlich zu reduzieren und insbesondere die Kosten für das Zusammenführen von Diagrammen zu senken.

Hintergrund

Um eine überschaubare Anzahl von Segmenten beizubehalten, prüft Lucene regelmäßig, ob Segmente zusammengeführt werden sollen. Dies läuft darauf hinaus, zu prüfen, ob die aktuelle Segmentanzahl eine Zielsegmentanzahl überschreitet, die durch die Basissegmentgröße und die Zusammenführungsrichtlinie bestimmt wird. Wenn die Anzahl überschritten wird, führt Lucene Segmentgruppen zusammen, während die Einschränkung verletzt wird. Dieser Vorgang wurde an anderer Stelle ausführlich beschrieben.

Lucene entscheidet sich für die Zusammenführung ähnlich großer Segmente, da dadurch ein logarithmisches Wachstum der Schreibverstärkung erreicht wird. Im Fall eines Vektorindex ist die Schreibverstärkung die Anzahl der Male, die ein Vektor in ein Diagramm eingefügt wird. Lucene versucht, Segmente in Gruppen von etwa 10 zusammenzuführen. Folglich werden Vektoren in einen Graphen eingefügt, der ungefähr beträgt.mal, wobei die Anzahl der Indexvektoren und die erwartete Anzahl der Basissegmentvektoren ist. Aufgrund des logarithmischen Wachstums liegt die Schreibverstärkung selbst bei großen Indizes im einstelligen Bereich. Die Gesamtzeit, die zum Zusammenführen von Graphen benötigt wird, ist jedoch linear proportional zur Schreibverstärkung.

Beim Zusammenführen von HNSW-Graphen nehmen wir bereits eine kleine Optimierung vor: Wir behalten den Graphen für das größte Segment bei und fügen Vektoren aus den anderen Segmenten darin ein. Dies ist der Grund für den oben genannten 9/10-Faktor. Im Folgenden zeigen wir, wie wir durch die Verwendung von Informationen aus allen Diagrammen, die wir zusammenführen, deutlich bessere Ergebnisse erzielen können.

HNSW-Graphzusammenführung

Bisher haben wir den größten Graphen beibehalten und Vektoren aus den anderen eingefügt, wobei wir die Graphen, die sie enthalten, ignoriert haben. Die zentrale Erkenntnis, die wir im Folgenden nutzen, ist, dass jeder HNSW-Graph, den wir verwerfen, wichtige Näheinformationen über die darin enthaltenen Vektoren enthält. Wir möchten diese Informationen nutzen, um das Einfügen zumindest einiger Vektoren zu beschleunigen.

Wir konzentrieren uns auf das Problem des Einfügens eines kleineren Graphen in einen größeren Graphen , da dies eine atomare Operation ist, die wir zum Erstellen beliebiger Zusammenführungsrichtlinien verwenden können.

Die Strategie besteht darin, eine Teilmenge von Eckpunkten von zu finden, die in den großen Graphen eingefügt werden soll. Wir verwenden dann die Konnektivität dieser Knoten im kleinen Graphen, um das Einfügen der verbleibenden Knoten zu beschleunigen. Im Folgenden verwenden wir und um die Nachbarn eines Knotens im kleinen bzw. großen Graphen zu bezeichnen. Schematisch ist der Ablauf wie folgt.

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

Wir berechnen die Menge mithilfe eines Verfahrens, das wir unten besprechen (Zeile 1). Dann fügen wir jeden Knoten in mithilfe des Standard-HNSW-Einfügeverfahrens in den großen Graphen ein (Zeile 2). Für jeden Knoten, den wir nicht eingefügt haben, finden wir seine Nachbarn, die wir eingefügt haben, und deren Nachbarn im großen Graphen (Zeilen 4 und 5). Wir verwenden ein mit diesem Set (Zeile 6) gesätes FAST-SEARCH-LAYER -Verfahren, um die Kandidaten für SELECT-NEIGHBORS-HEURISTIC aus dem HNSW- Papier (Zeile 7) zu finden. Tatsächlich ersetzen wir SEARCH-LAYER , um den Kandidatensatz in der Methode INSERT (Algorithmus 1 aus dem Dokument) zu finden, die ansonsten unverändert bleibt. Schließlich fügen wir den Scheitelpunkt hinzu, den wir gerade in eingefügt haben (Zeile 8).

Damit dies funktioniert, ist klar, dass jeder Scheitelpunkt in mindestens einen Nachbarn in haben muss. Tatsächlich verlangen wir, dass für jeden Scheitelpunkt in für ein gewisses , die maximale Schichtkonnektivität, gilt. Wir beobachten, dass in realen HNSW-Diagrammen eine ziemliche Streuung der Scheitelpunktgrade zu sehen ist. Die folgende Abbildung zeigt eine typische kumulative Dichtefunktion des Scheitelpunktgrads für die unterste Ebene eines Lucene HNSW-Diagramms.

Wir haben die Verwendung eines festen Werts für sowie die Möglichkeit untersucht, ihn zu einer Funktion des Scheitelpunktgrads zu machen. Diese zweite Wahl führt zu größeren Beschleunigungen bei minimalen Auswirkungen auf die Grafikqualität, daher habe ich mich für Folgendes entschieden

Beachten Sie, dass | per Definition gleich dem Grad des Scheitelpunkts im kleinen Graphen ist. Eine Untergrenze von zwei bedeutet, dass wir jeden Scheitelpunkt einfügen, dessen Grad kleiner als zwei ist.

Ein einfaches Zählargument legt nahe, dass wir bei sorgfältiger Wahl von nur etwa direkt in einfügen müssen. Konkret färben wir eine Kante des Graphen, wenn wir genau einen ihrer Endknoten in einfügen. Dann wissen wir, dass wir für jeden Knoten in mindestens Kanten einfärben müssen, um mindestens Nachbarn in Darüber hinaus erwarten wir, dass

Dabei ist der durchschnittliche Knotengrad im kleinen Graphen. Für jeden Knoten färben wir höchstens Kanten. Daher beträgt die Gesamtzahl der Kanten, die wir voraussichtlich einfärben werden, höchstens . Wir hoffen, dass wir durch sorgfältige Wahl von annähernd diese Anzahl von Kanten einfärben können. Um alle Eckpunkte abzudecken, muss folgende Bedingung erfüllen:

Dies impliziert, dass .

Vorausgesetzt, SEARCH-LAYER dominiert die Laufzeit, lässt dies darauf schließen, dass wir eine bis zu Beschleunigung der Zusammenführungszeit erreichen könnten. Angesichts des logarithmischen Wachstums der Schreibverstärkung bedeutet dies, dass wir selbst bei sehr großen Indizes die Erstellungszeit im Vergleich zum Erstellen eines Diagramms normalerweise nur verdoppeln würden.

Das Risiko bei dieser Strategie besteht darin, dass wir die Grafikqualität beeinträchtigen. Wir haben es zunächst mit einem No-Op FAST-SEARCH-LAYER versucht. Wir haben festgestellt, dass dies die Qualität des Diagramms in dem Maße verschlechtert, dass die Rückrufrate als Funktion der Latenz beeinträchtigt wird, insbesondere beim Zusammenführen auf ein einzelnes Segment. Anschließend haben wir mithilfe einer eingeschränkten Suche im Diagramm verschiedene Alternativen untersucht. Am Ende war die effektivste Wahl die einfachste. Verwenden Sie SEARCH-LAYER , aber mit einem niedrigen ef_construction. Mit dieser Parametrisierung konnten wir Grafiken von hervorragender Qualität erzielen und die Zusammenführungszeit dennoch durchschnittlich um etwas mehr als 30 % verkürzen.

Berechnung der Join-Menge

Die Suche nach einer guten Join-Menge kann als HNSW-Graphüberdeckungsproblem formuliert werden. Eine Greedy-Heuristik ist eine einfache und effektive Heuristik zur Annäherung an optimale Graphüberdeckungen. Bei unserem Ansatz werden die Knotenpunkte nacheinander in absteigender Reihenfolge der Verstärkung zu hinzugefügt. Der Gewinn ist wie folgt definiert:

Dabei bezeichnet die Anzahl der Nachbarn eines Vektors in und ist die Indikatorfunktion. Der Gewinn beinhaltet die Änderung der Anzahl der Scheitelpunkte, die wir zu hinzugefügt haben, also , da wir unserem Ziel durch das Hinzufügen eines weniger abgedeckten Scheitelpunkts näher kommen. Die Gewinnberechnung wird in der folgenden Abbildung für den zentralen orangefarbenen Scheitelpunkt veranschaulicht.

Wir behalten für jeden Knoten den folgenden Zustand bei:

1. Ob es abgestanden ist,

2. Sein Gewinn ,

3. Die Anzahl der benachbarten Eckpunkte in wird bezeichnet,

4. Eine Zufallszahl im Bereich [0,1], die zum Auflösen eines Gleichstands verwendet wird.

Der Pseudocode zum Berechnen des Join-Sets lautet wie folgt.

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

Wir initialisieren zunächst den Status in den Zeilen 1-5.

In jeder Iteration der Hauptschleife extrahieren wir zunächst den Scheitelpunkt mit der maximalen Verstärkung (Zeile 8) und lösen Gleichstände nach dem Zufallsprinzip auf. Bevor wir Änderungen vornehmen, müssen wir prüfen, ob die Verstärkung des Scheitelpunkts veraltet ist. Insbesondere beeinflussen wir jedes Mal, wenn wir einen Scheitelpunkt zu hinzufügen, den Gewinn anderer Scheitelpunkte:

1. Da alle seine Nachbarn einen zusätzlichen Nachbarn in haben, können sich ihre Gewinne ändern (Zeile 14).

2. Wenn einer seiner Nachbarn jetzt vollständig gedeckt ist, können sich die Gewinne aller seiner Nachbarn ändern (Zeilen 14-16).

Wir berechnen die Gewinne auf verzögerte Weise neu, d. h. wir berechnen den Gewinn eines Scheitelpunkts nur dann neu, wenn wir ihn in einfügen möchten (Zeilen 18–20). Da die Gewinne immer nur abnehmen, können wir nie einen Scheitelpunkt verpassen, den wir einfügen sollten.

Beachten Sie, dass wir lediglich den Gesamtgewinn der zu hinzugefügten Scheitelpunkte im Auge behalten müssen, um zu bestimmen, wann wir aussteigen müssen. Darüber hinaus wird, obwohl mindestens ein Scheitelpunkt einen von Null verschiedenen Gewinn aufweisen, sodass wir immer Fortschritte machen.

Ergebnisse

Wir haben Experimente mit vier Datensätzen durchgeführt, die zusammen unsere drei unterstützten Distanzmetriken (euklidisch, Kosinus und inneres Produkt) abdecken:

1. quora-E5-small: 522931 Dokumente, 384 Dimensionen und verwendet Kosinusähnlichkeit,

2. cohere-wikipedia-v2: 1 Million Dokumente, 768 Dimensionen und verwendet Kosinusähnlichkeit,

3. Kern: 1 Million Dokumente, 960 Dimensionen und verwendet euklidische Distanz und

4. cohere-wikipedia-v3: 1 Mio. Dokumente, 1024 Dimensionen und verwendet das maximale innere Produkt.

Für jeden Datensatz bewerten wir zwei Quantisierungsstufen:

1. int8 – verwendet eine 1-Byte-Ganzzahl pro Dimension und

2. BBQ – das ein einzelnes Bit pro Dimension verwendet.

Schließlich haben wir für jedes Experiment die Suchqualität bei zwei Abruftiefen bewertet und nach dem Erstellen des Index und anschließend nach der erzwungenen Zusammenführung zu einem einzelnen Segment untersucht.

Zusammenfassend lässt sich sagen, dass wir durchgängig erhebliche Beschleunigungen bei der Indizierung und Zusammenführung erzielen und dabei in allen Fällen die Grafikqualität und damit die Suchleistung beibehalten.

Experiment 1: int8-Quantisierung

Die durchschnittlichen Beschleunigungen von der Basislinie bis zum Kandidaten, die vorgeschlagenen Änderungen, sind:

Beschleunigung der Indexzeit: 1,28

Beschleunigung der Force Merge: 1,72

Dies entspricht folgender Laufzeitaufteilung

Der Vollständigkeit halber sind die genauen Zeiten

Index

Verschmelzen

Datensatz

Basislinie

Kandidat

Entwickeln

Kandidat

Quora-E5-klein

112,41 s

81,55 s

113,81 s

70,87 s

wiki-cohere-v2

158,1 s

122,95 s

425,20 s

239,28 s

Kern

141,82 s

119,26 s

536,07 s

279,05 s

wiki-cohere-v3

211,86 s

168,22 s

654,97 s

414,12 s

Unten zeigen wir die Diagramme „Rückruf vs. Latenz“, die den Kandidaten (gestrichelte Linien) mit der Basislinie bei zwei Abruftiefen vergleichen: Rückruf@10 und Rückruf@100 für Indizes mit mehreren Segmenten (das Endergebnis unserer Standard-Zusammenführungsstrategie nach der Indizierung aller Vektoren) und nach der erzwungenen Zusammenführung zu einem einzelnen Segment. Eine Kurve, die höher und weiter links liegt, ist besser, da sie eine höhere Rückrufrate bei geringerer Latenz bedeutet.

Wie Sie sehen, ist der Kandidat für mehrere Segmentindizes für den Cohere v3-Datensatz besser und für alle anderen Datensätze etwas schlechter, aber fast vergleichbar. Nach der Zusammenführung zu einem einzigen Segment sind die Erinnerungskurven in allen Fällen nahezu identisch.

Experiment 2: BBQ-Quantisierung

Die durchschnittlichen Beschleunigungen von der Basislinie zum Kandidaten sind:

Beschleunigung der Indexzeit: 1,33

Beschleunigung der Force Merge: 1,34

Dies entspricht folgender Laufzeitaufteilung

Der Vollständigkeit halber sind die genauen Zeiten

Index

Verschmelzen

Datensatz

Basislinie

Kandidat

Entwickeln

Kandidat

Quora-E5-klein

70,71 s

58,25 s

59,38 s

40,15 s

wiki-cohere-v2

203,08 s

142,27 s

107,27 s

85,68 s

Kern

110,35 s

105,52 s

323,66 s

202,2 s

wiki-cohere-v3

313,43 s

190,63 s

165,98 s

159,95 s

Bei Indizes mit mehreren Segmenten ist der Kandidat für fast alle Datensätze besser, mit Ausnahme von Cohere v2, wo die Basislinie etwas besser ist. Für die einzelnen Segmentindizes sind die Recall-Kurven in allen Fällen nahezu identisch.

Fazit

Der in diesem Blog besprochene Algorithmus wird im kommenden Lucene 10.2 und in der darauf basierenden Elasticsearch-Version verfügbar sein. Benutzer können in diesen neuen Versionen von der verbesserten Zusammenführungsleistung und der verkürzten Indexerstellungszeit profitieren. Diese Änderung ist Teil unserer kontinuierlichen Bemühungen, Lucene und Elasticsearch für die Vektor- und Hybridsuche schnell und effizient zu machen.

Den BEIR-Benchmark bei der Bewertung der Suchrelevanz verstehen

Für die Verbesserung eines Systems müssen Sie messen können, wie gut es funktioniert. Im Zusammenhang mit der Suche BEIR (oder gleichwertig der Abschnitt „Retrieval” der Bestenliste MTEB) gilt als der „heilige Gral” für die Informationsabruf-Community, was nicht weiter verwunderlich ist. Es handelt sich um einen sehr gut strukturierten Benchmark mit vielfältigen Datensätzen für unterschiedliche Aufgaben. Genauer gesagt werden folgende Bereiche abgedeckt:

• Abrufen von Argumenten (ArguAna, Touche2020)

• Open-Domain-QA (HotpotQA, Natural Questions, FiQA)

• Passagenabruf (MSMARCO)

• Abrufen doppelter Fragen (Quora, CQADupstack)

• Faktenprüfung (FEVER, Climate-FEVER, Scifact)

• Biomedizinische Informationsabfrage (TREC-COVID, NFCorpus, BioASQ)

• Abrufen von Entitäten (DBPedia)

• Zitationsvorhersage (SCIDOCS)

Es liefert eine einzige Statistik, nDCG@10, die angibt, wie gut ein System die relevantesten Dokumente für jedes Aufgabenbeispiel in den von ihm zurückgegebenen besten Ergebnissen abgleicht. Für ein Suchsystem, mit dem ein Mensch interagiert, ist die Relevanz der betsen Ergebnisse entscheidend. Allerdings gibt es bei der Bewertung von Suchvorgängen viele Nuancen, die durch eine einzelne zusammenfassende Statistik nicht erfasst werden.

Struktur eines BEIR-Datensatzes

Jeder Benchmark hat drei Artefakte:

• der Korpus oder die Dokumente, die abgerufen werden sollen

• Die Abfragen

• die Relevanzbewertungen für die Abfragen (auch bekannt als qrels).

Relevanzbewertungen werden als Wert zwischen null und größer angegeben. Werte ungleich Null zeigen an, dass das Dokument in gewisser Weise mit der Abfrage in Zusammenhang steht.

Datensatz

Korpusgröße

#Abfragen im Testset

#qrels positiv gekennzeichnet

#qrels gleich Null

#duplicates im Korpus

Arguana

8.674

1.406

1.406

0

96

Climate-FEVER

5.416.593

1.535

4.681

0

0

DBPedia

4.635.922

400

15.286

28.229

0

FEVER

5.416.568

6.666

7.937

0

0

FiQA-2018

57.638

648

1.706

0

0

HotpotQA

5.233.329

7.405

14.810

0

0

Natürliche Fragen

2.681.468

3.452

4.021

0

16.781

NFCorpus

3.633

323

12.334

0

80

Quora

522.931

10.000

15.675

0

1.092

SCIDOCS

25.657

1.000

4.928

25.000

2

Scifact

5.183

300

339

0

0

Touche2020

382.545

49

932

1.982

5.357

TREC-COVID

171.332

50

24.763

41.663

0

MSMARCO

8.841.823

6.980

7.437

0

324

CQADupstack (Summe)

457.199

13.145

23.703

0

0

Tabelle 1: Datensatzstatistiken. Die Zahlen wurden auf dem Testabschnitt der Datensätze berechnet (dev für MSMARCO).

Tabelle 1 enthält einige Statistiken zu den Datensätzen, aus denen der BEIR-Benchmark besteht, wie zum Beispiel die Anzahl der Dokumente im Korpus, die Anzahl der Abfragen im Testdatensatz und die Anzahl der positiven/negativen Paare (Abfrage, Dokument) in der qrels-Datei. Ein kurzer Blick auf die Daten lässt uns sofort Folgendes ableiten:

• Die meisten Datensätze enthalten keine negativen Beziehungen in der qrels-Datei, d. h. null Werte, was Dokumente ausdrücklich als irrelevant für die jeweilige Abfrage kennzeichnen würde.

• Die durchschnittliche Anzahl von Dokumentbeziehungen pro Abfrage (#qrels / #queries) variiert von 1,0 im Ticket von ArguAna bis 493,5 (TREC-COVID), jedoch mit einem Wert von <5 für die Mehrheit der Tickets.

• Bei einigen Datensätzen gibt es doppelte Dokumente im Korpus, was in einigen Fällen zu einer falschen Auswertung führen kann, z. B. wenn ein Dokument als relevant für eine Abfrage angesehen wird, sein Duplikat jedoch nicht. Zum Beispiel haben wir in ArguAna 96 Tickets von doppelten Dokumentpaaren identifiziert, wobei pro Paar nur ein Dokument als relevant für eine Abfrage markiert wurde. Durch die „Erweiterung“ der ursprünglichen Qrels-Liste um die Duplikate haben wir einen relativen Anstieg des nDCG@10-Wertes um durchschnittlich ~1 % festgestellt.

Beispiel für duplizierte Paare in ArguAna. In der qrels-Datei scheint nur der erste Eintrag (als Gegenargument) für die Abfrage („test-economy-epiasghbf-pro02a“) relevant zu sein.

Beim Vergleich von Modellen in der MTEB-Rangliste ist es naheliegend, sich auf die durchschnittliche Retrieval-Qualität zu konzentrieren. Dies ist ein guter Indikator für die Gesamtqualität des Modells, sagt jedoch nicht unbedingt etwas darüber aus, wie es für Sie funktionieren wird. Da die Ergebnisse pro Datensatz gemeldet werden, ist es sinnvoll zu verstehen, wie eng die verschiedenen Datensätze mit Ihrer Suchaufgabe zusammenhängen, und die Modelle nur anhand der relevantesten Datensätze neu zu bewerten. Wenn Sie noch tiefer eintauchen möchten, können Sie zusätzlich überprüfen, ob es Überschneidungen zwischen den Themen der verschiedenen Datensätze gibt. Die Stratifizierung von Qualitätsmaßen nach Themen ermöglicht eine viel differenziertere Bewertung ihrer spezifischen Stärken und Schwächen.

Wichtig ist hierbei, dass ein Dokument, das nicht in der qrels-Datei markiert ist, standardmäßig als für die Abfrage irrelevant angesehen wird. Wir befassen uns etwas eingehender mit diesem Bereich und sammeln einige Nachweise, um mehr Licht in die folgende Frage zu bringen: „Wie oft werden einem Evaluator Paare (Abfrage, Dokument) vorgelegt, für die es keine Ground-Truth-Informationen gibt?“. Der Grund dafür ist, dass bei nur verfügbaren oberflächlichen Markups (sodass nicht jedes relevante Dokument als solches gekennzeichnet ist) ein Informationsabrufsystem schlechter bewertet werden kann als ein anderes, nur weil es sich dafür „entscheidet“, andere relevante (aber nicht markierte) Dokumente anzuzeigen. Das ist ein häufiger Fehler bei der Erstellung qualitativ hochwertiger Evaluierungsdatensätze, insbesondere bei großen Datensätzen. Aus praktischen Gründen konzentriert sich die manuelle Kennzeichnung in der Regel auf die besten Ergebnisse, die vom aktuellen System zurückgegeben werden, sodass relevante Dokumente in den blinden Flecken möglicherweise übersehen werden. Daher ist es in der Regel vorzuziehen, mehr Ressourcen auf ein umfassenderes Markup weniger Abfragen als auf ein breites, oberflächliches Markup zu konzentrieren.

Nutzung des BEIR-Benchmarks zur Bewertung der Suchrelevanz

Um unsere Analyse zu beginnen, implementieren wir das folgende Szenario (siehe Notizbuch):

1. Zuerst laden wir den Korpus jedes Datensatzes in einen Elasticsearch-Index.

2. Für jede Abfrage im Testsatz rufen wir die 100 besten Dokumente mit BM25 ab.

3. Wir ordnen die abgerufenen Dokumente mithilfe verschiedener SOTA-Reranking-Modelle neu an.

4. Abschließend geben wir die „Bewertungsrate“ für die 10 besten Dokumente aus Schritt 2 (nach dem Abrufen) und Schritt 3 (nach dem Reranking) an. Mit anderen Worten: Wir berechnen den durchschnittlichen Prozentsatz der 10 besten Dokumente mit einer Bewertung in der qrels-Datei.

Die Liste der von uns verwendeten Reranking-Modelle lautet wie folgt:

• Coheres rerank-english-v2.0 und rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

Abruf

Reranking

Datensatz

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7,54

4,87

7,87

4,52

4,53

6,84

Climate-FEVER

5,75

6,24

8,15

9,36

7,79

7,58

DBPedia

61,18

60,78

64,15

63,9

63,5

67,62

FEVER

8,89

9,97

10,08

10,19

9,88

9,88

FiQa-2018

7,02

11,02

10,77

8,43

9,1

9,44

HotpotQA

12,59

14,5

14,76

15,1

14,02

14,42

Natürliche Fragen

5,94

8.84

8,71

8,37

8,14

8,34

NFCorpus

31,67

32,9

33,91

30,63

32,77

32,45

Quora

12,2

10,46

13,04

11,26

12,58

12,78

SCIDOCS

8,62

9,41

9,71

8,04

8,79

8,52

Scifact

9,07

9,57

9,77

9,3

9,1

9,17

Touche2020

38,78

30,41

32,24

33,06

37,96

33,67

TREC-COVID

92,4

98,4

98,2

93,8

99,6

97,4

MSMARCO

3,97

6,00

6,03

6,07

5,47

6,11

CQADupstack (Durchschnitt)

5,47

6,32

6,87

5.89

6,22

6,16

Tabelle 2: Bewertungsrate pro Paare (Datensatz, Reranker), berechnet anhand der 10 am häufigsten abgerufenen/neu geordneten Dokumente

Aus Tabelle 2 sehen wir, mit Ausnahme von TREC-COVID (>90 % Abdeckung), DBPedia (~65 %), Touche2020 und nfcorpus (~35 %), dass die Mehrheit der Datensätze eine Labeling-Rate zwischen 5 % und etwas mehr als 10 % nach dem Abrufen oder Reranking aufweist. Das heißt nicht, dass alle diese unmarkierten Dokumente relevant sind, aber es könnte ein Teilbereich davon geben, insbesondere diejenigen, die an oberster Stelle stehen, die positiv sein könnten.

Mit dem Aufkommen von auf allgemeine Anweisungen abgestimmten Sprachmodellen haben wir ein neues leistungsfähiges Tool, das die Beurteilung der Relevanz potenziell automatisieren kann. Diese Methoden sind in der Regel viel zu rechenaufwändig, um online für die Suche verwendet zu werden, aber hier geht es uns um die Offline-Auswertung. Im Folgenden verwenden wir sie, um die Hinweise darauf zu untersuchen, dass einige der BEIR-Datensätze unter oberflächlichen Markups leiden.

Zur weiteren Untersuchung dieser Hypothese haben wir uns entschlossen, uns auf MSMARCO zu konzentrieren und einen Teilbereich von 100 Abfragen zusammen mit den fünf (mit Cohere v2) höchsten Reranking-Dokumenten auszuwählen, die derzeit nicht als relevant markiert sind. Wir haben zwei verschiedene Bewertungsansätze verfolgt: Zunächst haben wir einen sorgfältig abgestimmten Prompt (mehr dazu in einem späteren Beitrag) verwendet, um das kürzlich veröffentlichte Phi-3-mini-4k-Modell darauf vorzubereiten, die Relevanz (oder Nicht-Relevanz) eines Dokuments für die Abfrage vorherzusagen. Parallel dazu wurden diese Tickets auch manuell gekennzeichnet, um auch die Übereinstimmungsrate zwischen dem LLM-Ausgang und der menschlichen Bewertung zu ermitteln. Insgesamt können wir die folgenden beiden Schlüsse ziehen:

• Die Übereinstimmungsrate zwischen den LLM-Reaktionen und den menschlichen Beurteilungen lag bei knapp 80 %, was als Ausgangspunkt in diese Richtung durchaus gut erscheint.

• In 57,6 % der Fälle (nach menschlicher Beurteilung) erwiesen sich die zurückgegebenen Dokumente tatsächlich als relevant für die Abfrage. Anders ausgedrückt: Bei 100 Abfragen werden 107 Dokumente als relevant eingestuft, aber es gibt mindestens 0,576 x 5 x 100 = 288 zusätzliche Dokumente, die tatsächlich relevant sind!

Hier einige Beispiele aus dem Datensatz MSMARCO/dev, die die Abfrage, das annotierte positive Dokument (aus qrels) und ein falsch negatives Dokument aufgrund unvollständiger Auszeichnung enthalten:

Beispiel 1:

Beispiel 2:

Die manuelle Auswertung solcher spezifischer Abfragen ist eine allgemein nützliche Methode, um die Suchqualität zu verstehen und quantitative Messgrößen wie nDCG@10 zu ergänzen. Bei einem repräsentativen Abfrageset, das Sie immer ausführen, wenn Sie Änderungen an der Suche vornehmen, erhalten Sie wichtige qualitative Informationen darüber, wie sich die Leistung verändert, die in den Statistiken nicht sichtbar sind. Beispielsweise erhalten Sie viel mehr Einblick in die falschen Ergebnisse Ihrer Suche: Sie erkennen offensichtliche Fehler in den Suchergebnissen, Kategorien verwandter Fehler, wie z. B. die Fehlinterpretation fachspezifischer Terminologie und so weiter.

Unser Ergebnis stimmt mit einschlägigen Studien zur MSMARCO Bewertung der Suchrelevanz überein. Zum Beispiel folgen Arabzadeh et al. einem ähnlichen Verfahren, bei dem sie Crowdsourcing-Mitarbeiter für Präferenzurteile einsetzen: Sie zeigen unter anderem, dass in vielen Fällen die von den Reranking-Modulen zurückgegebenen Dokumente im Vergleich zu den Dokumenten in der MSMARCO- qrels-Datei bevorzugt werden. Ein weiterer Nachweis stammt von den Autoren des RocketQA-Rerankers, die berichten, dass mehr als 70 % der Reranking-Dokumente nach einer manuellen Überprüfung als relevant eingestuft wurden.

Aktualisierung – 9. September: Nach einer genauen Neubewertung des Datensatzes haben wir 15 weitere Fälle relevanter Dokumente identifiziert, wodurch sich die Gesamtzahl von 273 auf 288 erhöht hat

Wichtigste Erkenntnisse und nächste Schritte

• Das Streben nach besseren Referenzwerten ist ein nie endender Prozess, da diese für Benchmarking und Modellvergleiche von entscheidender Bedeutung sind. LLMs können in einigen Bewertungsbereichen helfen, wenn sie mit Vorsicht angewendet und mit den richtigen Anweisungen abgestimmt werden.

• Allgemeiner gesagt: Da Benchmarks niemals perfekt sein werden, könnte es vorteilhaft sein, von einem reinen Wertevergleich zu robusteren Methoden überzugehen, die statistisch signifikante Unterschiede erfassen. Die Arbeit von Arabzadeh et al. liefert hierfür ein gutes Beispiel, da auf Grundlage der Ergebnisse 95-prozentige Konfidenzintervalle erstellt wurden, die signifikante (oder nicht signifikante) Unterschiede zwischen den verschiedenen Durchläufen aufzeigen Im beigefügten Notizbuch stellen wir eine Implementierung von Konfidenzintervallen unter Verwendung von Bootstrapping zur Verfügung.

• Aus der Perspektive des Endnutzers ist es sinnvoll, bei der Betrachtung von Benchmark-Ergebnissen über die Aufgabenausrichtung nachzudenken. Für einen KI-Ingenieur, der beispielsweise eine RAG-Pipeline entwickelt und weiß, dass der typische Anwendungsfall das Zusammenführen mehrerer Informationen aus verschiedenen Quellen beinhaltet, wäre es sinnvoller, die Leistung seines Retrieval-Modells anhand von Multi-Hop-QA-Datensätzen wie HotpotQA zu bewerten, anstatt den globalen Durchschnitt des gesamten BEIR-Benchmarks zu verwenden.

Im nächsten Blogbeitrag werden wir uns eingehender mit der Verwendung von Phi-3 als LLM-as-a-Judge und der Optimierung zur Vorhersage der Relevanz befassen.