2026-02-08 · Aktualisiert 2026-07-15

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Such-Ranking-Stack im Jahr 2026: BM25, Embeddings, Cross-Encoder sowie LLM Reranking

Die Suche muss sowohl die exakte als auch die semantische Absicht erfüllen. Eine Abfrage nach „kabellose Kopfhörer“ sollte Produkte enthalten, die diese Begriffe tatsächlich tragen, wobei die endgültige Reihenfolge zudem von der Produktqualität, den Präferenzen der Nutzer sowie der Verfügbarkeit abhängen kann. Keine einzelne Ranking-Methode bewältigt alle diese Faktoren gleichermaßen gut.

Dieser Artikel konstruiert den Technologiestack Schritt für Schritt: BM25 Retrieval, dichte Embeddings Modelle, Reciprocal Rank Fusion, Cross-Encoder Reranking sowie schließlich die listebasierte Rangierung mit LLM. funktionierende Demo Benchmarks in jeder Phase der Produktsuchfunktion von Amazon ESCI Dataset.

TL;DR: Entwickeln Sie die Suchfunktion schrittweise und messbar. Beginnen Sie mit BM25, fügen Sie den dichten Retrieval hinzu, sobald dieser die Recall-Werte bei Ihren Abfragen verbessert, führen Sie eine Fusion nur durch, wenn die beiden Retrieval-Methoden komplementäre Fehler aufweisen, und ordnen Sie erneut nur jene Kandidatenliste, die innerhalb des Latency-Budgets liegt. In dieser auf einem Laptop laufenden ESCI-Demo stieg der vollständige Pipeline-basierte NDCG@10-Wert von 0,585 auf 0,717. Dieses Ergebnis dient lediglich als Beispiel, nicht als Beleg dafür, dass jedes Produktivsystem alle fünf Phasen oder einen Online-LLM benötigt.

Auswahl der Phasen nach Versagensmodus

Der Produktionsstack fungiert als Trichter, wobei der jeweils geeignete Trichtertyp von der Anfrage sowie den betrieblichen Anforderungen abhängt.

Beginnen Sie mit BM25 als Baseline. Fügen Sie einen dichten Retrieval hinzu, wenn eine Unstimmigkeit im Wortschatz die Recall-Rate beeinträchtigt. Setzen Sie einen Cross-Encoder ein, wenn auf der ersten Seite die richtigen Kandidaten in der falschen Reihenfolge vorliegen. Ersetzen Sie den LLM erst dann durch einen solchen, wenn Sie die Ressourcen für den Latency aufbringen können und die Ranking-Entscheidungen bewerten können.

Wie wir hierhergekommen sind

Die Architektur lässt sich leichter als drei Schichten verstehen. Die lexikalische Verarbeitung Retrieval findet exakte Begriffe, die dichte Verarbeitung Retrieval schließt Wortschatzlücken, und die Neubewertungsfunktionen vergleichen die stärksten Kandidaten im Detail.

BM25 und lexikaler Retrieval

Seit Jahrzehnten, BM25 Das war die Standard-Einstellung. Es handelt sich um einen probabilistischen Model, der Dokumente anhand der Häufigkeit von Abfrageschlagwörtern darin bewertet – wobei diese Häufigkeit durch die Länge des Dokuments sowie die umgekehrte Dokumenthäufigkeit (IDF) normalisiert wird.

BM25 zeigt eine hohe Leistungsfähigkeit, wenn die literalen Begriffe die jeweilige Absicht klar transportieren – wie beispielsweise Fehlercodes, Produkt-SKUs, Namen sowie API-Identifikatoren. Seine größte Einschränkung besteht in einem Wortschatzunpass. Eine Anfrage nach „billigem Laptop“ kann dazu führen, dass ein Dokument über einen „Budget-Notebook-Computer“ übergangen wird, falls der indizierte Text keine Verbindung zwischen diesen Ausdrücken herstellt.

Dies gilt zwar, aber BM25 stellt eine solide Grundlage dar. Es erzielt im Durchschnitt einen Wert von 0,429 bei nDCG@10 in allen Testfällen. BEIR Benchmark’s 18 Datasets sowie ist immer noch besser als einige neuronale Models-Modelle. bei argumentativen Retrieval-Aufgaben wie Touche 2020.

Dichte Retrieval und Embeddings

BERT-basierte Encoder machen dichte Retrieval Implementierungen möglich. Sie übertragen Abfragen sowie Dokumente in einen gemeinsamen Vektorraum und ordnen anschließend die Ergebnisse mithilfe einer Ähnlichkeitsfunktion wie der Kosinusähnlichkeit oder dem Skalarprodukt.

Die Bi-Encoder-Architektur (auch „Zweitürmigkeits-Architektur“ genannt) verarbeitet die Abfrage sowie das Dokument unabhängig voneinander mithilfe separater Encoder-Türme und erzeugt dabei Vektoren mit fester Länge Embeddings. Dokumentenvektoren können im Voraus berechnet und offline indiziert werden, um anschließend mithilfe von Algorithmen zur approximativen Nähesten-Nachbarn-Suche (ANN) schnell abgerufen zu werden. Dadurch liegen Begriffe wie „günstiger Laptop“ und „Budget-Notebook“ nun im Vektorraum in der Nähe zueinander.

Einige Bi-Encoder verwenden eine Siamese-Architektur, wie zum Beispiel Sentence-BERT, Dort teilen beide Seiten Weights. Andere Ansätze verwenden getrennte Abfragesysteme und Dokumentdatenbanken. Die Zusammenführung von Ressourcen, die Vektorgröße, die Ähnlichkeitsfunktion sowie das Trainingsziel sind Model‑Optionen und nicht Eigenschaften jedes dichten Retrieval-Systems.

Diese Models werden mithilfe von kontrastivem Lernen trainiert, in der Regel unter Verwendung von InfoNCE Verlustfunktion. Bei einer Batch von (Abfrage, positives_Dokument)-Paaren zielt das Optimierungsziel darauf ab, diesen Verlust zu maximieren. sim(query, positive_doc) während gleichzeitig minimiert wird sim(query, negative_docs). Negative Beispiele stammen von den positiven Beispielen anderer Abfragen im selben Batch (sogenannte In-Batch-Negativen). Der Temperaturparameter $\tau$ bestimmt, wie schmal die Verteilung ist: niedrigere Werte führen dazu, dass der Model Unterschiede zwischen positiven und negativen Beispielen schwieriger erkennen lässt.

Trainingssdaten sind oft wichtiger als die Embedding-Dimension. Retrieval Models lernen anhand von Abfrages-positiven Paaren sowie sorgfältig ausgewählten harten Negativen – plausiblen, aber irrelevanten Dokumenten. Der folgende Abschnitt zur Trainierung zeigt, wie SimANS vermeidet sowohl triviale Negative als auch wahrscheinlich falsche Negative.

Der Kostenfaktor besteht in der Repräsentation Bottleneck. Bi-Encoder komprimieren alle semantischen Nuancen in einen Vektor mit fester Größe, wodurch sie häufig fein abgestimmte Wechselwirkungen zwischen spezifischen Abfrageschlüsseln und konkretem Dokumentinhalt übersehen.

Kreuzkodierer und LLMs

Cross-Encoder (Nogueira & Cho, 2019) Die Abfrage sowie das Dokument werden als zusammengeführte Sequenz gemeinsam in einen Transformer eingegeben.[CLS] Query [SEP] Document), wodurch jede Abfrage Token über vollständige Self-Attention-Verarbeitung auf jedes Dokument Token zugreifen kann. Diese tiefe Interaktion ermöglicht es, Nuancen zu erfassen, die eine einfache Kodierung übersieht.

LLM Reranking nutzt einen angesprochenen Model, um mehrere Kandidaten gleichzeitig miteinander zu vergleichen. RankGPT Es konnten starke Ergebnisse im Zero-Shot-Ansatz unter Verwendung von GPT-4 auf dem getesteten Benchmarks erzielt werden, wobei jedoch die Stabilität der Ausgaben, die damit verbundenen Kosten sowie die Passgenauigkeit zum jeweiligen Anwendungsgebiet weiterhin einer separaten Überprüfung bedürfen.

Da diese Werte für beliebige Abfragen nicht im Voraus berechnet werden können, wird Reranking nach Retrieval eingefügt. Diese Kostenasymmetrie ist der Grund für den mehrstufigen Funnel-Ansatz.

Der mehrstufige Funnel

Der Betrieb eines aufwändigen Cross-Encoders oder von LLM bei Millionen von Dokumenten ist nicht praktikabel; daher nutzen moderne Suchsysteme ein Kanalisierungsverfahren. In jeder Stufe wird die Anzahl der möglichen Ergebnisse reduziert, während die Model Komplexität zunimmt.

Ein komplexer Model ist zu langsam, um das gesamte Korpus bewerten zu können, während ein preisgünstiger Retriever an endgültiger Präzision mangelt. Der Funnel verwendet jeden Model nur dort, wo seine Kosten angemessen sind.

Retrieval legt die Obergrenze fest und Reranking optimiert innerhalb dieser Grenze. Falls ein relevanter Dokument nicht über Retrieval erhalten bleibt, kann kein nachgelagerter Model es wiederherstellen.

Die Demo: ein fünfstufiger Pipeline

Um dies konkret zu machen, habe ich einen solchen Agenten implementiert. Such-Ranking-Stack Demo, die einen fünfstufigen Pipeline ausführt. Amazon ESCI Die Produktsuche Benchmark. Jede Phase wird unabhängig gemessen, sodass Sie genau erkennen können, wo die Verbesserungen tatsächlich entstehen.

Der Pipeline:

1. BM25 sparse Retrieval – lexikalische Grundlagerank_bm25)
2. Dichter Bi-Encoder Retrieval – Erstellung semantischer Kandidatenall-MiniLM-L6-v2)
3. Hybride RRF-Fusion – rankbasierte Fusion von spärlichen und dichten Ergebnissen
4. Kreuzencoder Reranking – paarweise Relevanzbewertungenms-marco-MiniLM-L-12-v2)
5. LLM-Vergleich auf Listeebene Reranking – angeforderte Gegenüberstellung der endgültigen Shortlist (Ollama, API oder lokaler Model)

Schritte 1–3 stellen die Retrieval-Phase des Funnels dar (Maximierung der Recall-Rate); Schritte 4–5 sind die Phase der vollständigen Rangliste (Maximierung der Präzision). In der Demo werden die Vor-Ranking- und Mischungsphase übersprungen. Bei etwa 8.500 Dokumenten ist es möglich, alle hybriden Ergebnisse direkt an Reranking zu übermitteln.

Schnellstart

git clone https://github.com/slavadubrov/search-ranking-stack.git
cd search-ranking-stack
uv sync

# Download and sample ESCI dataset (~2.5GB download, ~5MB sample)
uv run download-data

# Run the full pipeline (without LLM reranking)
uv run run-all

# Run with LLM reranking via Ollama
uv run run-all --llm-mode ollama

Dataset und Sampling: Amazon ESCI

Die Demo verwendet die Amazon Shopping Queries Dataset (ESCI) aus KDD Cup 2022 — eine echte Produktsuchfunktion Benchmark mit vierstufigen Relevanzbewertungen:

Die gestufte Relevanz ist von Bedeutung, da sie es ermöglicht, den NDCG (Normalized Discounted Cumulative Gain) zu verwenden – ein Maß, das eine „perfekte“ Rangliste von einer lediglich „zufriedenstellenden“ unterscheidet. Binäre Metriken betrachten beide Arten von Ranglisten als gleich relevant und können keine Unterschiede zwischen verschiedenen Relevanzstufen an derselben Position erkennen.

I habe die Demo verwendet. small_version Beispiel: Etwa 500 Abfragen, 8.500 Produkte sowie 12.000 Bewertungen. Das System ist klein genug, um auf einem Laptop ausgeführt zu werden, doch zu klein und zu domänenspezifisch, um eine produktive Ranking-Logik einzuführen. Es dient dazu, die jeweiligen Phasen nachzuvollziehen und Fehlermuster zu analysieren; mit aussortierten, repräsentativen Abfragen können anschließend Entscheidungen bezüglich Deployment getroffen werden.

Retrieval: hybride Suche

Die Aufgabe der Schicht Retrieval besteht darin, die Trefferquote zu maximieren – man muss das größtmögliche Netz auswerfen, damit nichts Relevantes durchrutscht.

BM25: die lexikalische Grundlage

BM25 bewertet Dokumente anhand des Term-Überlappungsgrades mit der Abfrage, unter Berücksichtigung der Saturation der Termhäufigkeit sowie der Normalisierung nach Dokumentlänge:

Wo \text{IDF}(t) ist die umgekehrte Dokumenthäufigkeit des Terms $t$; $tf(t,d)$ ist die Termhäufigkeit im Dokument $d$.|d|$ist die Länge eines Dokuments, und$\text{avgdl}$ist die durchschnittliche Dokumentlänge im gesamten Korpus. Zwei Parameter sind von Bedeutung:$k_1$(in der Regel 1,2–2,0) steuert die TF-Sättigung – also wie schnell wiederholte Begriffe keinen weiteren Mehrwert mehr liefern – und$b$ (in der Regel 0,75) regelt die Normalisierung der Dokumentlänge.

Die Implementierung ist kurz. Einfacher Leerzeicheninhalt Tokenization mit rank_bm25:

# src/search_ranking_stack/stages/s01_bm25.py

from rank_bm25 import BM25Okapi

def run_bm25(data: ESCIData, top_k: int = 100):
    doc_ids = list(data.corpus.keys())
    tokenized_corpus = [text.lower().split() for text in data.corpus.values()]

    bm25 = BM25Okapi(tokenized_corpus)

    results = {}
    for query_id, query_text in data.queries.items():
        scores = bm25.get_scores(query_text.lower().split())
        top_indices = np.argsort(scores)[::-1][:top_k]
        results[query_id] = {doc_ids[idx]: float(scores[idx]) for idx in top_indices}

    return results

BM25 erreicht einen Recall@100 von 0,741 – 74 % der relevanten Produkte erscheinen in irgendeiner Position unter den ersten 100 Ergebnissen. Das ist für eine rein lexikalische Methode nicht schlecht, doch 26 % der relevanten Artikel bleiben in allen nachfolgenden Verarbeitungsschritten unsichtbar.

Dichter Bi-Encoder Retrieval

Der Bi-Encoder wandelt Abfragen und Dokumente unabhängig voneinander in einen gemeinsamen Embedding-Raum um:

# src/search_ranking_stack/stages/s02_dense.py

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")

# Encode corpus once, cache to disk
corpus_embeddings = model.encode(
    doc_texts,
    batch_size=128,
    normalize_embeddings=True,  # Cosine sim = dot product
    convert_to_numpy=True,
)

# At query time: encode query, compute dot product
query_embeddings = model.encode(query_texts, normalize_embeddings=True)
similarity_matrix = np.dot(query_embeddings, corpus_embeddings.T)

Durch die Normalisierung von Embeddings reduziert sich die Kosinusähnlichkeit auf ein Skalarprodukt. Die Demonstration berechnet die vollständige Abfragesatz-zu-Korpus-Matrix, da 8.500 Dokumente problemlos im Speicher untergebracht werden können; in einer Produktionsumgebung würde man in der Regel einen Index nach dem Prinzip des nächsten nahen Nachbarn verwenden. In diesem Beispiel all-MiniLM-L6-v2 steigert den Recall@100 von 0,741 auf 0,825.

Wie Bi-Encoder gute Repräsentationen erlernen

Der Training-Prozess eines Bi-Encoders erfolgt in der Regel in zwei Phasen. Zunächst wird der Model auf Aufgaben im Bereich der natürlichen Sprache Inference (NLI) sowie der semantischen Textähnlichkeit (STS) Datasets vorgetrainiert. Dabei wird eine allgemeine semantische Verständnisfähigkeit vermittelt – der Model lernt beispielsweise, dass Aussagen wie „Eine Katze sitzt auf einer Matte“ und „Ein Felid ruht sich auf einem Teppich aus“ ähnliche Embeddings aufweisen sollten. Anschließend wird der Encoder an datenspezifische Informationen zu Retrieval angepasst, etwa an Datensätze wie MS MARCO, wodurch er erkennt, dass eine Suchanfrage zusammen mit den dazu passenden Passagen enger beieinander liegen sollten als die Anfrage mit irrelevanten Passagen.

Der entscheidende Bestandteil der zweiten Phase ist die harte Negative-Mining-Methode. Zufällige Negativbeispiele (z. B. ein Dokument über Kochen in Kombination mit einer Anfrage zu Kopfhörern) lassen sich äußerst leicht voneinander unterscheiden – der Model lernt daraus nichts. Stattdessen wird der aktuelle Model selbst genutzt, um Dokumente zu identifizieren, die er zwar hoch bewertet, die aber tatsächlich nicht relevant sind.

Der SimANS Der Ansatz „Simple Ambiguous Negatives Sampling“ formalisiert dies wie folgt: Zunächst werden alle Dokumente mithilfe des aktuellen Bi-Encoders rangiert. Anschließend werden einfache Negative ausgeschlossen – sie weisen einen zu niedrigen Rang auf und werden bereits vom Model behandelt – sowie potenzielle Falsch-Negative, die einen zu hohen Rang aufweisen; diese könnten tatsächlich relevant sein, aber noch nicht gelabelt sein. Der „harte Mittelweg“ sorgt somit für das maximale Lernsignal.

# What a training triplet looks like after hard negative mining
training_triplet = {
    "query": "wireless noise canceling headphones",
    "positive": "Sony WH-1000XM5 Wireless Noise Cancelling Headphones",
    "negative": "Sony headphone replacement ear pads",  # Hard negative: same brand, related product, but wrong intent
}
# The bi-encoder must learn that "ear pads" is NOT what the user wants,
# even though it shares many tokens with the positive document.

Die kontrastive Verlustfunktion (InfoNCE) verknüpft diese Elemente miteinander. Für jede Abfrage $q$ mit einem positiven Dokument $d^+$ sowie einer Menge an negativen Dokumenten $\{d^-_1, \ldots, d^-_n\}$:

Wo $\text{sim}(q, d)$ die Kosinusähnlichkeit zwischen Abfrage und Dokument Embeddings darstellt, und $\tau$ der Temperaturparameter ist (in der Regel 0,05–0,1), der bestimmt, wie schmal die Verteilung ist – niedrigere Werte machen den Verlust empfindlicher gegenüber stark negativen Beispielen. Im Grunde handelt es sich dabei um Softmax-Kreuzentropie: Man muss die Ähnlichkeit des positiven Paares im Verhältnis zu allen Negativen erhöhen. Wenn $\tau$ klein ist, führen selbst geringe Unterschiede in der Ähnlichkeit zu großen Gradienten, wodurch der Model zu feineren Unterscheidungen gezwungen wird.

Serving Bi-Encoder Embeddings in großem Maßstab

Der architektonische Vorteil eines Bi-Encoders besteht in der Offline/Online-Trennung. Die Dokumente Embeddings werden zum Zeitpunkt der Indexierung berechnet und in einem Vektorindex gespeichert. Zum Zeitpunkt der Abfrage kodiert das System die Abfrage und durchsucht anschließend diese gespeicherten Vektoren. Latency hängt vom Encoder, der Hardware, dem Index, den Filtern sowie dem Ziel hinsichtlich der Rückrufrate ab; daher sollten die beiden Schritte getrennt analysiert werden.

In der Demo sind die Rechenanforderungen gering: 8.500 Dokumente $\times$ 384 Dimensionen $\times$ 4 Bytes pro Float = etwa 13 MB an Embeddings. Im Produktionsumfeld werden diese Werte jedoch erheblich: 1 Milliarde Dokumente mit 768-dimensionalen Embeddings erfordern etwa 3 TiB Speicherplatz. Genau hier kommt Quantization ins Spiel (durch das Komprimieren von 32-Bit-Floats zu 8-Bit-Integern). Produkt Quantization (die Zerlegung von Vektoren in Unterräume) sowie SSD-gestützte Indizes wie DiskANN Kommen Sie herein. Der Abschnitt zur dichten Vektorindizierung behandelt die Indexierungsalgorithmen.

Warum hybride Retrieval testen?

Die beiden Methoden versagen in der Regel auf unterschiedliche Weise. BM25 eignet sich hervorragend für Eigennamen, Produkt-SKUs sowie Fehlercodes. Dichte Retrieval-Strukturen können Wortschatzunterschiede wie „billiger Laptop“ im Vergleich zu „Budget-Notebook“ ausgleichen. Ob eine Kombination dieser Ansätze hilft, hängt davon ab, wie häufig solche ergänzenden Fälle im Zielabfragesatz vorkommen.

Ein gängiges nächstes Experiment ist die hybride Suche: Dabei werden beide Retrieval-Methoden ausgeführt, um anschließend ihre gerankten Ergebnislisten zu fusionieren.

Rückwirkende Rangfusionsmethode (RRF)

BM25 sowie dichte Retrieval-Modelle erzeugen Bewertungswerte, die unterschiedliche Bedeutungen sowie Skalen aufweisen. Daher erfordert eine lineare Kombination sowohl Calibration als auch eine Validierung, sobald sich die Suchalgorithmen oder das Korpus ändern.

Reziproke Rangfusionsmethode (Cormack et al., 2009) verzichtet vollständig auf die Rohwerte und verwendet ausschließlich die Rangposition:

Hierbei ist $k$ eine Glättungskonstante; 60 gilt als üblicher Ausgangswert. RRF belohnt Elemente, die in den Eingabelisten weit oben rangieren, ohne ihre Rohwerte direkt miteinander zu vergleichen. Dadurch wird eine Skalierung der Bewertungen Calibration vermieden, doch die Retrieval-Schwellenwerte, Weights sowie $k$ müssen weiterhin bewertet werden.

Die Implementierung:

# src/search_ranking_stack/stages/s03_hybrid_rrf.py

def reciprocal_rank_fusion(ranked_lists, k=60, top_k=100):
    fused_results = {}

    for query_id in all_query_ids:
        rrf_scores = defaultdict(float)

        for results in ranked_lists:
            sorted_docs = sorted(results[query_id].items(),
                                 key=lambda x: x[1], reverse=True)

            for rank, (doc_id, _score) in enumerate(sorted_docs, start=1):
                rrf_scores[doc_id] += 1.0 / (k + rank)

        sorted_rrf = sorted(rrf_scores.items(),
                            key=lambda x: x[1], reverse=True)[:top_k]
        fused_results[query_id] = dict(sorted_rrf)

    return fused_results

Der hybride RRF erreicht einen Recall@100 von 0,842 sowie einen NDCG@10 von 0,628 – wodurch er sowohl BM25 (0,585) als auch Dense (0,611) allein bereits übertrifft. Um bei der Fusion überhaupt überleben zu können, müssen Dokumente lediglich in einer Methode eine gute Platzierung erzielen.

Kreuzencoder Reranking

Bei 100 hybriden Kandidaten pro Abfrage können Sie sich ein teureres Model leisten. Der Cross-Encoder verarbeitet die Abfrage sowie das Dokument zusammen mithilfe eines einzigen Transformers, wobei eine vollständige Cross-Attention zwischen allen Tokens besteht.

Token-Ebene-Interaktion

Der eigentliche Unterschied liegt in der Attention-Matrix. Bei einem Bi-Encoder ist die Attention-Struktur blockdiagonal: Die Abfragen Tokens beziehen sich ausschließlich auf andere Abfragen Tokens, und die Dokumente Tokens beziehen sich ausschließlich auf andere Dokumente Tokens. Die beiden Repräsentationen treffen auf der Ebene des Token niemals aufeinander – sie kreuzen sich erst am Ende durch einen Skalarprodukt. Ein Cross-Encoder hingegen berechnet die vollständige Attention-Matrix, wodurch jede Abfrage Token mit jedem Dokument Token in Berührung kommt und umgekehrt. Genau dieses Cross-Attention ermöglicht tiefgreifende Interaktionen auf der Ebene des Token.

In einem Bi-Encoder wird die Abfrage „Apfel“ bereits vor dem Betrachten eines Dokuments kodiert. Ein Cross-Encoder hingegen betrachtet die Abfrage zusammen mit dem Kandidaten, wodurch er die Beziehung auf Token-Ebene nutzen kann. Dies kann bei Fällen wie folgenden hilfreich sein:

• Negation: „Kopfhörer, die nicht kabellos sind.“ Eine aggregierte Embedding-Struktur kann die Wirkung der Negation abschwächen, während die gemeinsame Kodierung einer direkten Interaktion zwischen Model und dem Abfragedokument ermöglicht. Es handelt sich dabei um eine Hypothese, die mittels eines gezielten Datensatzabschnitts überprüft werden muss – nicht um eine Garantie.
• Qualification: „Laptop für unter 500 US-Dollar.“ Durch die gemeinsame Kodierung lässt sich die Einschränkung mit einem Preis im Produkttext verknüpfen; strukturierte Preisschranken sind jedoch sicherer, sofern dieses Feld verfügbar ist.

Der Eingang des Cross-Encoders wird in folgender Form formatiert: [CLS] query tokens [SEP] document tokens [SEP]. [CLS] es handelt sich um eine Klassifizierung Token, deren endgültiger versteckter Zustand über einen linearen Head weitergeleitet wird, um einen einzigen Relevanzwert zu erzeugen. Segmente Embeddings unterscheiden die Abfrage Tokens vom Dokument Tokens, und [SEP] markiert die Grenze zwischen den Segmenten.

Wie Cross-Encoder trainiert werden

Cross-Encoder können aus Erfahrungen lernen. (query, document, relevance_label) Beispiele mit punktuellen, paarweisen oder listweisen Zielen. Das untenstehende Beispiel für das punktuelle Ziel verwendet nur eine einzige Relevanzkennzeichnung; es handelt sich dabei jedoch nicht um die einzige mögliche Trainingskonfiguration.

# Cross-encoder training data format
training_example = {
    "query": "wireless headphones",
    "document": "Sony WH-1000XM5 Wireless Headphones",
    "label": 1.0,  # Relevant
}
# Forward pass: [CLS] hidden state → Linear layer → sigmoid → score
# Loss: binary cross-entropy between predicted score and label

Ein herkömmlicher Klassifikator wandelt die finale Ausgabe um. [CLS] Die Umwandlung der Repräsentation in eine Bewertungsscore. Für binäre Labels kann die binäre Kreuzentropie verwendet werden; bei graduierten Relevanzwerten kommen Regressionen, ordinalisierte Verlustfunktionen, paarweise oder listweise Verlustfunktionen in Frage. Entscheiden Sie sich anhand von aufbewahrten Ranking-Metriken – anstatt davon auszugehen, dass ein bestimmtes Ziel allgemein vorzuziehen ist.

Die Gewinnung harter Negative ist umso wichtiger für Cross-Encoder. im Vergleich zu Bi-Encodern. Cross-Encodern sind aufwendig im Training – jedes Trainingsbeispiel erfordert einen vollständigen Vorwärtslauf durch die zusammengefügte Sequenz – weshalb man es sich nicht leisten kann, Rechenressourcen für offensichtlich einfache Negative zu verschwenden. Das praktische Vorgehen besteht darin, einen Bi-Encoder zu verwenden, um für jede Trainingsanfrage die Top-K-Kandidaten zu ermitteln, und anschließend schwierige Negative aus bestimmten Rangbereichen abzurufen (z. B. Ränge 10–100). Dadurch erhält der Cross-Encoder Beispiele, bei denen die Unterscheidung zwischen relevanten und irrelevanten Inhalten tatsächlich eine tiefe Token Interaktion erfordert.

# src/search_ranking_stack/stages/s04_cross_encoder.py

from sentence_transformers import CrossEncoder

model = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-12-v2")

def run_cross_encoder(data, hybrid_results, top_k_rerank=50):
    for query_id, query_text in data.queries.items():
        candidates = list(hybrid_results[query_id].items())[:top_k_rerank]

        # Form (query, document) pairs for joint encoding
        pairs = []
        doc_ids = []
        for doc_id, _ in candidates:
            doc_text = data.corpus.get(doc_id, "")[:2048]
            pairs.append([query_text, doc_text])
            doc_ids.append(doc_id)

        # Score all pairs with full cross-attention
        scores = model.predict(pairs, batch_size=64)

        # Rerank by cross-encoder score
        scored_docs = sorted(zip(doc_ids, scores),
                             key=lambda x: x[1], reverse=True)
        reranked_results[query_id] = {
            doc_id: float(score) for doc_id, score in scored_docs
        }

Im aufgezeichneten Demo-Ausführungsvorgang, ms-marco-MiniLM-L-12-v2 Es sortiert pro Abfrage 50 Kandidaten um und erhöht den NDCG@10-Wert von 0,628 auf 0,645. Der Latency-Wert sollte auf der Deployment-Hardware gemessen werden; dabei haben sowohl die Model-Länge als auch die Batch-Größe sowie der Runtime Einfluss auf das Ergebnis.

Der Kompromiss zwischen Geschwindigkeit und Qualität

Warum werden nicht für alles Cross-Encoder verwendet? Weil eine Vorverarbeitung unmöglich ist. Bi-Encoder-Dokumente Embeddings sind abhängig von der Abfrage nicht, weshalb man sie einmal berechnen und speichern kann. Die Ausgabe eines Cross-Encoders hingegen hängt sowohl von der Abfrage als auch vom Dokument gemeinsam ab. Der Relevanzwert für „kabellose Kopfhörer“ in Kombination mit einem Sony-Produkt ergibt sich aus dem vollständigen Cross-Attention zwischen diesen spezifischen Tokens. Diesen Wert lässt sich weder im Cache speichern noch für eine andere Abfrage wiederverwenden.

Ein Bi-Encoder benötigt eine Abfragekodierung sowie eine Vector Search für die im Voraus berechneten Dokumente Embeddings. Ein Cross-Encoder bewertet jedes Abfrage-Dokument-Paar in der Vorauswahl, wobei die Kosten mit der Anzahl der Kandidaten sowie der Länge der Sequenzen ansteigen. Das Batching kann helfen, doch die Bewertung von 100.000 Kandidaten bleibt weiterhin ein inakzeptabler Betriebspunkt; es sollte zunächst nach den Daten gesucht und anschließend Benchmark die größte Vorauswahl herausgefiltert werden, die die Anforderungen hinsichtlich Qualität und Latency erfüllt.

Die von der Demonstration bestätigte Regel lautet: Der Recall@100 bleibt in beiden Reranking-Phasen konstant bei 0,842. Reranking kann die Reihenfolge der Ergebnisse ändern, fügt jedoch niemals neue Dokumente hinzu. Retrieval legt dabei die Obergrenze fest.

LLM listeweise Reranking

In der abschließenden Demo-Phase wird ein LLM zur Durchführung von listweisen Reranking verwendet. Anstelle einer unabhängigen Bewertung jedes Dokuments betrachtet der Model die zehn besten Ergebnisse und gibt eine sortierte Reihenfolge zurück. Inspiriert von RankGPT, Der Prompt macht den relativen Vergleich explizit, führt jedoch gleichzeitig zu Kontextbeschränkungen, Positionsverzerrungen, Parsing-Fehlern sowie Schwankungen zwischen verschiedenen Ausführungen.

Die listebasierte Prompt

Das Prompt-Template bittet den LLM, die Relevanzhierarchie von ESCI zu berücksichtigen:

# src/search_ranking_stack/stages/s05_llm_rerank.py

def _create_listwise_prompt(query, documents, max_words=200):
    n = len(documents)

    doc_texts = []
    for i, (doc_id, doc_text) in enumerate(documents, start=1):
        words = doc_text.split()[:max_words]
        doc_texts.append(f"[{i}] {' '.join(words)}")

    return (
        f"I will provide you with {n} product listings, each indicated by "
        f"a numerical identifier [1] to [{n}]. Rank the products based on "
        f'their relevance to the search query: "{query}"\n\n'
        "Consider:\n"
        "- Exact matches should rank highest\n"
        "- Substitutes should rank above complements\n"
        "- Irrelevant products should rank lowest\n\n"
        f"{chr(10).join(doc_texts)}\n\n"
        "Output ONLY a comma-separated list of identifiers: [3], [1], [2], ...\n"
        "Do not explain your reasoning."
    )

Drei Ausführungsmodi

Die Demo unterstützt drei Backends für LLM Reranking:

Parsen und Fallback-Mechanismus

Die Ausgaben von LLM erfüllen nicht zwingend das angeforderte Schema, weshalb eine korrekte Parsung sowie ein Fallback-Mechanismus von entscheidender Bedeutung sind:

def _parse_ranking(output: str, n: int) -> list[int] | None:
    """Parse LLM output to extract ranking order."""
    matches = re.findall(r"\[(\d+)\]", output)

    if not matches:
        return None

    positions = [int(m) - 1 for m in matches]

    # Pad with remaining positions if LLM returned partial output
    if len(positions) < n:
        seen = set(positions)
        for i in range(n):
            if i not in seen:
                positions.append(i)

    return positions[:n]

Falls die Parsing-Operation völlig fehlschlägt, wechselt die Demo auf die Anordnungsmethode des Cross-Encoders. Ein Produktions-Parser sollte außerdem Identifikatoren außerhalb des zulässigen Bereichs sowie Duplikate ablehnen, fehlende Kandidaten in ihrer ursprünglichen Reihenfolge hinzufügen, den Fehler protokollieren und die Häufigkeit dieses Fallbacks mit einem definierten Schwellenwert vergleichen.

Ergebnisse aus diesem ESCI-Beispiel

Hier sind die Ergebnisse aus dem Ausführen des vollständigen Pipeline auf etwa 500 ESCI-Anfragen:

Wichtige Beobachtungen

Die hybride Suche übertrifft jede der einzelnen Methoden für sich genommen. Der RRF-NDCG-Wert von 0,628 liegt über den Werten von BM25 (0,585) sowie Dense (0,611). Spärliche und dichte Retrieval-Strukturen weisen komplementäre Fehlermuster auf, wodurch ihre Kombination Dokumente wiederherstellen kann, die bei Verwendung nur einer dieser Strukturen übersehen würden.

Der Recall ist auf Retrieval festgelegt. Der Recall@100 bleibt in beiden Reranking-Phasen konstant bei 0,842. Reranker ordnen die Dokumente neu an, fügen aber keine neuen hinzu. Wenn Sie einen höheren Recall erreichen möchten, müssen Sie die Schicht Retrieval anpassen.

Der mit einem Prompt gesteuerte LLM verursacht den größten gemessenen Sprung in diesem Lauf. Der Wert von NDCG@10 steigt nach der LLM-Phase um 0,072 an. Da der Prompt die ESCI-Relevanzhierarchie berücksichtigt, dient das Ergebnis dazu, diese Kombination aus Model, Prompt und Dataset zu überprüfen. Bevor man den Gewinn auf einen grundsätzlich besseren Neurankierer zurückführt, sind wiederholte Durchläufe, Konfidenzintervalle, Latency, Kosten sowie ein separater Testdatensatz erforderlich.

Der dichte Retrieval übertrifft BM25 in diesem Beispiel. Prüfen Sie die Abfrageschnitte, bevor Sie die Ursache festlegen. Ein Wortschatzunterschied ist ein möglicher Treiber, doch auch die Aufbauweise des Beispiels, der Tokenizer sowie der Model-Trainingsdomäne und die Korpusfelder beeinflussen den Vergleich.

Bewertung: Messung der relevanten Kriterien

Die Demo verwendet drei ergänzende Metriken. Jede von ihnen betrachtet die Rangliste aus einem anderen Blickwinkel:

NDCG@10 (Hauptmetrik)

Normalisierter diskontierter kumulativer Gewinn misst die Qualität der Top-10-Rangliste unter Verwendung einer graduierten Relevanzbewertung. Dabei wird durch einen logarithmischen Diskontfaktor belohnt, dass besonders relevante Dokumente nahe an der Spitze platziert werden:

NDCG ist die einzige Metrik, die das vierstufige Relevanzbewertungssystem von ESCI vollständig nutzt – ein System, bei dem eine exakte Übereinstimmung auf Platz 1 eine höhere Bewertung erhält als eine Ersatzlösung an derselben Stelle. Aus diesem Grund gilt sie als primäre Metrik für die Gesamtqualität der Suche.

MRR@10 (erstes relevantes Ergebnis)

Durchschnittliche umgekehrte Rangfolge berücksichtigt dabei die Position des ersten als relevant erachteten Ergebnisses. Ist dieses an Position 1 zu finden, beträgt die umgekehrte Rangfolge 1,0; befindet es sich hingegen an Position 3, liegt sie bei 0,333. Bei gestuften Bewertungen wie ESCI wird angegeben, welcher Relevanzschwellenwert verwendet wird, um aus diesen Werten die entsprechende binäre Entscheidung abzuleiten.

Recall@100 (Retrieval-Abdeckung)

Der Recall gibt an, welcher Anteil der als relevant eingestuften Dokumente sich in den ersten 100 Plätzen befindet. Es handelt sich dabei um eine Obergrenzmetrik hinsichtlich der bewerteten Urteile: Ein Neurankierer kann kein Dokument hinzufügen, das von Retrieval weggelassen wurde, während unvollständige Bewertungen diese scheinbare Obergrenze unsicher machen können.

Indizierung dichter Vektoren jenseits der Demo

Dichte Embeddings werden erst im großen Maßstab nützlich, sobald man über einen Index für Approximative Näherungs-Nachbarn (ANN) verfügt. Die Demo nutzt die brute-force-Methode zur Berechnung der Kosinusähnlichkeit – was bei etwa 8.500 Dokumenten ausreicht –, doch Produktivsysteme erfordern spezialisierte Indizes.

HNSW (hierarchisch navigierbarer Small-World-Graph)

HNSW Es wird ein mehrschichtiger Graph aufgebaut: Die spärlicher strukturierten oberen Schichten ermöglichen einen weiten Überblick, während die dichter besetzten unteren Schichten das Umfeld genauer präzisieren. M steuert die Verbindbarkeit des Graphen, während efSearch Er setzt die Abfrageleistung zugunsten der Erinnerungsrate ein. Die geeigneten Werte hängen von der Dimension, der Distanzverteilung, den Filtern, der Implementierung sowie vom gewünschten Zielwert der Erinnerungsrate ab.

Updates und Löschvorgänge stellen eine betriebliche Überlegung dar, da Graph-Indizes möglicherweise „Tombstones“ beibehalten oder eine Hintergrundreparatur erfordern. Das Verhalten variiert je nach Datenbank. A Qdrant-Problem, Zum Beispiel weisen Berichte auf eine verschlechterte Qualität nach einer bestimmten Arbeitslast mit umfangreichen Löschvorgängen hin. Es sollte das jeweilige Muster des Datenverlusts nachgeahmt werden, wobei bei der Bewertung auch das Verhalten bezüglich der Komprimierung oder Neuerrichtung berücksichtigt werden muss.

IVF (umgekehrte Datei)

IVF-Indizes teilen den Vektorraum in Cluster auf und scannen anschließend die nprobe die dem Abfragedatum am nächsten liegenden Clustern. Sie ermöglichen einen nützlichen Kompromiss hinsichtlich des Speicherverbrauchs, der Kompilierzeit und der Trefferquote, insbesondere in Kombination mit Komprimierungstechniken. Die Semantik sowie die Leistungsfähigkeit der Aktualisierungen hängen von der konkreten Implementierung ab und nicht ausschließlich von der Art der Indexstruktur.

Bei extremem Skalenniveau. IVF_RaBitQ (Gao & Long, SIGMOD 2024) komprimiert Fließkommenvektoren in einbitige Repräsentationen. Im hochdimensionalen Raum enthält das Vorzeichen einer Koordinate (+/–) bereits ausreichende Winkelinformationen für die Berechnung von Ähnlichkeiten.

In einem Fallstudie zur Lieferortsuche bei Uber, Durch die Reduzierung des Suchparameters auf Shard-Ebene von 1.200 auf 200 sanken die gemeldeten Werte für Latency um 34 % sowie für CPU um 17 %, wobei nur ein geringer Rückrufverlust festgestellt wurde. Die wichtige Lektion hieraus ist, die Rückruf-Kosten-Kurve unter Bedingungen ähnlich denen im Produktivbetrieb zu optimieren, anstatt einfach den Wert 200 zu übernehmen.

Optionaler Erweiterungen nach dem Kern Pipeline

Sobald Retrieval und Reranking eigenständige Messwerte aufweisen, lassen sich mehrere Erweiterungen unkomplizierter bewerten, ohne die Kernfunktionen von Pipeline zu verfälschen.

Abfragedurchdringung

Durch Abfragedehnung und -umformulierung lässt sich ein Wortschatzunpass bei Retrieval bereits im Vorfeld beheben. Query2Doc Es wurden pseudodokumentierte Inhalte erzeugt, und in den MS MARCO-Experimenten wurden Gewinne hinsichtlich des BM25-Algorithms berichtet. Eine Erweiterung kann außerdem zu falschen Intentionen führen; daher sollten Recall-Werte sowie Präzisionswerte für unklare, navigative sowie Anfragen mit exakten Identifikatoren verglichen werden.

Praktische Muster: Erweiterung von Abkürzungen, Bereicherung von Entitäten sowie Aufschlüsselung von Unterabfragen für mehrstufige Reasoning-Verarbeitungsprozesse, und RAG – Fusion — Erstellung mehrerer Abfrages Varianten sowie Kombination der Ergebnisse mithilfe von RRF.

LLM-unterstützte Relevanzkennzeichnung

LLMs kann Relevanzetiketten erstellen, wenn menschliche Beurteilungen knapp sind. TALEC und Pinterests Arbeit zur Erstellung von Relevanzbeschreibungen Stellen Sie zwei bewertete Designs zur Verfügung. Für das mit dem Label LLM gekennzeichnete Ergebnis gilt weiterhin die Vorgabe aus Model: Kalibrieren Sie es anhand von blind bewerteten menschlichen Entscheidungen, prüfen Sie die abweichenden Bereiche und führen Sie eine menschliche Referenzsammlung für Regressionstests auf.

Zu den nützlichen Steuerungselementen gehören:

• eine Rubrik mit konkreten Relevanzgrenzen und Beispielen;
• blinde menschliche Calibration Bewertungen sowie periodische Nachprüfungen;
• Zufallsordnung der Fälle sowie wiederholte Beurteilungen bei instabilen Ergebnissen;
• Model-Panel, deren zusätzlicher Aufwand zu einer besseren Übereinstimmung führt; sowie
• explizite Überprüfungen auf Positionen- und Mittelwertverzerrungen.

Wissensdestillation

Wenn ein LLM-Lehrer einen Mehrwert schafft, aber die Serving-Vorgaben nicht erfüllen kann, stellt die Destillation eine mögliche Lösung dar:

1. Verwenden Sie einen leistungsstarken LLM (den „Lehrer“), um Tausende von Schulungsanfragen neu zu ranken.
2. Trainieren Sie einen kleinen, schnellen Cross-Encoder (den „Schüler“, mit etwa 100 Mio.–200 Mio. Parametern), um die Ranking-Verteilung des LLM nachzuahmen.
3. Vergleichen Sie den „Schüler“ hinsichtlich Qualität, Calibration sowie Kosten von Serving sowohl mit dem „Lehrer“ als auch mit der Baseline-Lösung.

InRanker erhält durch Komprimierung von MonoT5-3B Modelle mit 60 Mio. und 220 Mio. Parametern Models – eine Verkleinerung um das 50-fache bei gleichzeitig konkurrenzfähiger Leistung. Die Rank-Without-GPT Dieser Ansatz erzeugt 7 Milliarden Open-Source-Listenbasierter Reranker, die mithilfe von QLoRA Fine-Tuning eine Effektivität von 97 Prozent gegenüber GPT-4 erreichen.

Die veröffentlichten Kompressionsergebnisse dienen lediglich als Ausgangspunkte und nicht als erwartete Produktionsraten. Durch Destillation können die Voreingenommenheiten des „Lehrers“ übernommen werden, wodurch bei seltenen Abfragen die Qualität leiden kann; daher sollten die ursprünglichen Relevanzbeurteilungen im Bewertungslauf beibehalten werden.

Personalisierung und Positionenbias

Allgemeine Relevanz reicht allein nicht aus. Eine Suche nach „Apfel“ sollte für einen Technikbegeisterten iPhones und für jemanden, der Kochinhalte durchsucht hat, Apfelrezepte liefern.

Eine gängige Retrieval-Architektur für Personalisierung nutzt einen zweistöckigen Embedding Model: Der Abfragespeicher kodiert die Abfrage sowie den Benutzerkontext, während der Item-Speicher die Items und Metadaten speichert. Die Trennung in Offline- und Online-Komponenten ermöglicht das Verfahren des approximierten nächsten Nachbarn Retrieval; dabei hängt die Latency weiterhin vom Encoder, dem Index, den Filtern sowie dem Serving-System ab.

Airbnbs Anzeige Embeddings, Pinterests OmniSearchSage, und Übers’ Zwei-Türme-Systeme Zeigen Sie verschiedene Produktionsdesigns. Ihre Skalierung sowie die gemeldeten Leistungssteigerungen beziehen sich auf diese Systeme; das übertragbare Muster besteht aus einem Offline-Item-Tower sowie einem Online-Query/User-Tower.

Klickdaten weisen einen Positions- und Expositionsbias auf. PAL Eine Methode zur Vermeidung von Voreingenommenheiten besteht darin, während des Trainings die Position zu berücksichtigen und diese anschließend während von Serving konstant zu halten. Dies ist jedoch keine universelle Lösung; randomisierte Eingriffe, inverse-Propensitätsmethoden sowie kontrafaktische Bewertungen könnten für ein anderes Produkt geeigneter sein.

Domänenanpassung mittels synthetischer Abfragen

Ein häufiger Fehler bei der Suchstrategieplanung besteht darin, anzunehmen, dass ein auf allgemeinen Webdaten (wie MS MARCO) trainierter Model auch in einem spezialisierten Bereich gut funktionieren wird. Dies ist das sogenannte Out-of-Domain (OOD)-Problem.

LLMs kann die mit Labels versehenen Bottleneck durch generatives Pseudolabeling verringern, aber nicht vollständig beseitigen.GPL, InPars):

1. Nehmen Sie Ihr domänenspezifisches Dokumentenkorpus.
2. Prompt einen LLM mit dem Auftrag „Erstelle eine Suchanfrage, auf die dieses Dokument antworten würde“.
3. Verwenden Sie die synthetischen (Anfrage, Dokument)-Paare, um Ihren Retriever sowie Reranker feinzujustieren.

Synthetische Paare können hilfreich sein, wenn echte Abfragen knapp sind, spiegeln sie jedoch den Generator sowie Prompt wider. Entfernen Sie Duplikate, filtern Sie unwahrscheinliche Abfragen und überprüfen Sie die Ergebnisse anhand echter, ungenutzter Daten aus dem Produktivbetrieb.

Eine Experimentiersequenz

Erhöhen Sie die Komplexität ausschließlich dann, wenn die vorherige Stufe einen messbaren Fehler aufweist:

Schritt 1 (Baseline): Implementieren Sie BM25 oder das aktuelle lexikalische System und erstellen Sie eine bewertete Abfragesammlung. Erfassen Sie dabei die Recall-Werte, den NDCG-Wert, Latency sowie die Angaben zu fehlschlagenden Abfragen.

Schritt 2 (Kandidaten-Rückruf): Testen Sie dichte Retrieval-Modelle sowie Fusionssysteme ausschließlich dann, wenn die Baseline relevante Dokumente übersieht. Passen Sie die Schwellenwert-Einstellung für die Kandidaten anhand von Rückrufrate und Kosten an.

Schritt 3 (Präzision der Rangliste): Fügen Sie einen Cross-Encoder hinzu, falls die richtigen Kandidaten vorhanden sind, aber in der falschen Reihenfolge auftauchen. Wählen Sie die Größe der Shortlist anhand einer Qualitätskurve für Latency.

Schritt 4 (Domain-Anpassung): Führen Sie Feinabstimmungen oder Destillationen erst dann durch, wenn generische Models stabile, domänenspezifische Fehler aufweisen. Halten Sie die echten, ungenutzten Beurteilungen getrennt von den synthetischen Trainingsdaten.

Schritt 5 (optionale, aufwändige Schicht): Testen Sie die Liste nach Liste oder die auf Reasoning basierenden Reranking-Verfahren nur dann, wenn die durch sie erzielte Qualität bei wiederholten Ausführungen konstant bleibt und somit die Notwendigkeit von Latency sowie die damit verbundenen Kosten, Datenschutzaspekte und Komplexitäten im Fallback-Szenario rechtfertigt.

Forschungsschwerpunkte, die getrennt bewertet werden sollen

Reasoning Reranker und Suchverfahren Agents Sie sind vielversprechend, beantworten jedoch andere Fragen als die fünfstufige Produktsuch-Demo.

Reasoning-basierte Neurangier

Rank1 trainiert Reranker mithilfe von Reasoning Traces und weist starke Ergebnisse bei der BRIGHT Benchmark. Dieser Beleg ist für Reasoning-intensive Retrieval-Anwendungen relevant und stellt keine direkte Vorhersage für die Produktsuchfunktion von ESCI dar.

Zur rechtlichen oder wissenschaftlichen Recherche sollten die Reasoning-Reranker im Vergleich zu Baselines mit starken Cross-Encodern sowie listbasierten Ansätzen hinsichtlich Expertenurteilen, Zitaten, Latency und Konsistenz bei Fehlern bewertet werden.

Agentic Suche

Search-o1 Es wird ein Model untersucht, der bei mehrstufigen Fragebeantwortungsszenarien zusätzliche Suchvorgänge auslöst. Dabei handelt es sich um ein Orchestration-Problem – also um Aspekte wie Abfragenbildung, Abbruchkriterien, Nutzung von Belegen sowie Bewertung der Antworten – und nicht um eine weitere Reranking-Phase. Die Leistungsfähigkeit dieses Ansatzes sollte anhand der Korrektheit bei der Erledigung des Endziels sowie der Verfügbarkeit von Zitaten bewertet werden, und nicht ausschließlich mithilfe von Retrieval-Metriken.

Wichtige Erkenntnisse

1. Betrachten Sie den Stack als eine Abfolge von Experimenten. Legen Sie zunächst eine lexikalische Baseline sowie einen bewerteten Abfragesatz fest, bevor dichte Retrieval-Strukturen, Fusionen oder Reranking hinzugefügt werden.

2. Messen Sie die Recall-Rate der Kandidaten getrennt von der Ranking-Precision. In dieser ESCI-Stichprobe erreicht die Recall@100-Wert nach der Fusion einen Wert von 0,842 und bleibt in beiden Reranking-Phasen konstant.

3. Verwenden Sie einen hybriden Retrieval, wenn die Fehler sich gegenseitig ergänzen. RRF verbesserte in der Demonstration sowohl den Recall@100 als auch den NDCG@10, doch ein anderes Korpus rechtfertigt möglicherweise nicht den Einsatz beider Indizes.

4. Fügen Sie einen Cross-Encoder hinzu, wenn die Auswahl korrekt ist, aber die Reihenfolge falsch. Wählen Sie die Anzahl der Kandidaten anhand einer gemessenen Qualitätskurve für Latency.

5. Betrachten Sie LLM Reranking als ein optionales Abschlussexperiment. Der hier erzielte Gewinn von 0,072 NDCG@10 gehört zu diesem Prompt-, Model-bezogenen Stichproben- und Relevanzbewertungsschema. Wiederholte Ausführungen, strenge Parsing-Verfahren, Fallback-Mechanismen sowie die damit verbundenen Kosten sind Teil der Bewertung.

6. Halten Sie die verschiedenen Arten von Belegen getrennt. Ein Ergebnis aus einer wissenschaftlichen Veröffentlichung, eine Fallstudie eines Anbieters, diese Laptop-Demo sowie ein Produktivumgebungs-A/B-Test beantworten unterschiedliche Fragen.

Der vollständige Code von Pipeline befindet sich hier. github.com/slavadubrov/search-ranking-stack. Klonieren Sie es, führen Sie es aus, ersetzen Sie Models sowie die Parameter durch andere Werte und betrachten Sie anschließend die Ergebniszahlen selbst.

Referenzen

Arbeiten / Publikationen

• Reziproke Rangfusionsmethode — Cormack et al., 2009
• RankGPT: LLMs als Zero-Shot-Listweiser Neurankierer — Sun et al., herausragende Veröffentlichung auf EMNLP 2023
• Rank1: Reasoning-basierte Reranking — Weller et al., COLM 2025
• SCaLR: Selbstkalibrierte listweise Reranking — Selbstkalibrierende listenbasierte Reranking Framework
• GCCP: global konsistenter vergleichender Punktweise-Ansatz — Behandlung von Calibration im punktweisen LLM-Ranking
• Rank-DistiLLM: Wissensdestillation für Reranking — Schlatt et al., ECIR 2025 Query2doc: LLM Abfragedehnung — Wang et al., EMNLP 2023
• GPL: Generatives Pseudo-Labeling — Domänenanpassung für dichte Retrieval-Modelle
• InRanker: Verfeinerter Reranker — 50-fachige Größenreduzierung bei konkurrenzfähiger Leistung Search-o1: Agentic Retrieval — EMNLP 2025
• TALEC: LLM als Judge für die Suche — Bewertung Framework
• BEIR Benchmark — Thakur et al., NeurIPS 2021 Sentence-BERT — Reimers & Gurevych, EMNLP 2019
• InfoNCE / CPC — van den Oord et al., 2018
• SimANS: Hartes negatives Sampling — Zhou et al., EMNLP 2022
• Passage Reranking mithilfe von BERT — Nogueira & Cho, 2019
• HNSW — Malkov & Yashunin, 2016
• DiskANN — Subramanya et al., NeurIPS 2019 RaBitQ — Gao & Long, SIGMOD 2024
• Das Ersetzen von Judges durch Juries — Verga et al., 2024
• RAG – Fusion — Rackauckas, 2024
• InPars — Bonifacio et al., SIGIR 2022
• Heller Benchmark — Su et al., ICLR 2025 Ranking ohne GPT — Zhang et al., ECIR 2025
• Pinterest LLM Suchrelevanz — Wang et al., 2024
• OmniSearchSage — Agarwal et al., WWW 2024 PAL: Lernen unter Berücksichtigung von Positionsverzerrungen — Guo et al., RecSys 2019

Datasets und Benchmarks

• Amazon ESCI: Suchanfragen im E-Commerce Dataset — KDD Cup 2022
• BEIR: IR-Benchmarking — Heterogene Benchmark Strukturen für die Zero-Shot-Bewertung
• MTEB: Massiver Text Embedding Benchmark — Embedding Model Leaderboard ESCI-Paper — Reddy et al., 2022

Models im Demo verwendet

• all-MiniLM-L6-v2 — Bi-Encoder mit 22 Millionen Parametern ms-marco-MiniLM-L-12-v2 — Cross-Encoder mit 33 Millionen Parametern
• Satztransformer — neuronale Retrieval Model Framework

Werkzeuge und Plattformen

• rank_bm25 — Implementierung von BM25 in Python pytrec_eval — TREC-Evaluierungs-Toolkit
• Elasticsearch — Hybrider Suchalgorithmus mit Retrieval-Systemen API
• Vespa — Einheitlicher Such- und Empfehlungsmotor Weaviate — Vector Database mithilfe einer hybriden Suche
• Qdrant — Vector Database bei mehrstufigen Abfragen

Branchenbeispiele

• Airbnb-Angebot Embeddings — Grbovic & Cheng, KDD 2018 Suche nach Lieferdiensten — Uber Engineering, 2025
• Doppel-Turm-Architektur Embeddings — Uber Engineering, 2023
• Elastisches Neuranking — Elastic, 2024

Demo-Projekt

• Such-Ranking-Stack — Funktionsfähige Demo mit dem gesamten Code aus diesem Beitrag