Neubewertung in RAG: Cross-Encoder gegen LLM-Bewerter und ihre Latenzzeit

Der richtige Abschnitt war in den Ergebnissen, nur zu weit unten

Stellen Sie sich ein RAG-System vor, dessen hybrider Suchmechanismus endlich richtig funktioniert. Der Vektor-Speicher ist online, der Schlüsselwort-Index arbeitet, die Fusion-Logik ist implementiert, und der Abschnitt, der die Antwort enthält, taucht nun irgendwo in der Liste der Kandidaten auf. Dennoch liefert das Modell weiterhin eine mittelmäßige Antwort.

Die Protokolle erklären, warum das so ist. Ein Entwickler fragte, wie man einen PAYMENTS_API_TIMEOUT-Fehler in der Staging-Umgebung debuggt. Der hybride Suchmechanismus lieferte zwanzig Kandidaten: einen allgemeinen Überblick zur Authentifizierung, eine veraltete Incidentsnotiz vom Vorjahr, eine allgemeine Seite zur Wiederholungslogik und auf Platz acht den Runbook-Abschnitt zur Staging-Umgebung mit der genauen Lösung. Für die Anfrage gab es jedoch nur Platz für drei Abschnitte. Der richtige befand sich zu weit unten, weshalb das Modell seine Antwort aus den falschen Informationen erstellte, da der richtige Abschnitt nicht passte.

Die Ergebnissuche fand die Beweise, stellte sie aber nicht an erster Stelle. Die Ergebnissuche dreht sich um das Abrufen von Informationen, während das Neuranking auf Präzision unter einer begrenzten Ressourcenbilanz abzielt.

Ein guter Kandidatenpool allein reicht nicht aus. Was das Modell tatsächlich liest, hängt von der Reihenfolge dieses Pools ab, und genau diese Reihenfolge ist das Engpassproblem.

Was die Neuranking-Phase leistet

Der erste Durchlauf ist darauf ausgelegt, schnell und umfassend zu arbeiten. Eine Abfrage in einer Vektordatenbank oder einem Schlüsselwortindex muss Millionen von Datensätzen in Millisekunden abdecken, weshalb diese Systeme auf Approximationen und vorberechneten Indizes angewiesen sind und absichtlich mehr als nötig abrufen.

Das Reranking fügt eine zweite Phase hinzu, die eine kleine Untergruppe der Ergebnisse auswählt und jedes davon genauer untersucht. Es ist langsamer, aber präziser, und berührt die Datenbank nie. Was auch immer die erste Durchlaufphase liefert – in der Regel die zwanzig oder fünfzig besten Ergebnisse – wird von einem leistungsstärkeren, genaueren Modell erneut bewertet.

Die erste Durchlaufphase erzeugt Kandidaten, und das Reranking entscheidet, welche von ihnen einen Platz im begrenzten Kontextfenster erhalten.

Warum die erste Durchlaufphase die Aufgabe nicht erledigen kann

Falls das Embedding-Modell gut ist, sollte der beste Teiltext doch einfach an die Spitze kommen, oder? Das ist jedoch nicht zuverlässig, denn die Auswertung in der ersten Durchlaufphase ist von Natur aus störanfällig.

Die Bewertung nach Schlüsselwörtern wie BM25 hängt von einer exakten Überschneidung der Begriffe ab. Eine umfangreiche Referenzseite, die einen Fehlercode fünfzig Mal erwähnt, schneidet oft besser ab als ein kurzes Schritt-für-Schritt-Anleitungsdokument, das ihn nur zweimal erwähnt, da der Algorithmus Häufigkeit als Relevanz interpretiert.

Die Vektorabrufung weist auf eine andere Weise Störungen auf. Embeddings messen die semantische Nähe, indem sie Konzepte in einem hochdimensionalen Raum platzieren. Bei einer Störungsbehebung werden dabei Abschnitte angezeigt, die mit den genannten Systemen zusammenhängen. Umfassende Übersichten liegen in diesem Raum in der Regel sehr nahe bei spezifischen Verfahren. Ein Abschnitt, der die Abrechnungsarchitektur beschreibt, kann eine höhere Bewertung erhalten als der genaue Befehl, mit dem der Abrechnungsdienst neu gestartet wird. Das Modell erkennt zwar, dass beides mit der Abrechnung zu tun hat, kann aber zwischen einer operativen Anweisung und einer theoretischen Beschreibung nicht unterscheiden.

Die hybride Abrufmethode fügt die lexikalischen und semantischen Listen zu einem umfassenden Kandidatenpool zusammen, der die benötigten Belege enthält. Dabei sind auch Duplikate, veraltete Dokumente, allgemeine Zusammenfassungen sowie nur teilweise relevante Abschnitte enthalten.

Die Erstabrufliste sollte niemals als letzte Sortierstufe angesehen werden. Sie funktioniert wie ein Trichter, wobei die erneute Sortierung der Filter am Ende darstellt.

Zwei Möglichkeiten zur Neubewertung

Sobald Kandidaten vorhanden sind, muss etwas sie ordnen. Zwei Ansätze haben sich als Standard etabliert. Der eine verwendet Cross-Encoder, spezialisierte Modelle, die darauf trainiert sind, zu bewerten, wie relevant ein Dokument für eine Anfrage ist. Der andere nutzt große Sprachmodelle, bei denen ein Modell wie Claude oder GPT die Anfrage sowie das Dokument erhält und gefragt wird, wie nützlich das Dokument ist.

Sowohl Ansätze verbessern die Qualität der Rangliste erheblich im Vergleich zur ersten Durchführung. Sie unterscheiden sich in Latenz, Kosten, Determinismus sowie den Anforderungen an die Technik.

Cross-Encoder

Ein Cross-Encoder ist ein Transformer, arbeitet jedoch anders als die Embedding-Modelle in einer Vektordatenbank.

Ein Standard-Embedding-Modell leitet die Abfrage durch das Netzwerk, um einen Vektor zu erhalten, leitet den Dokumenttext durch das Netzwerk, um einen weiteren Vektor zu erhalten, und vergleicht die beiden mit der Kosinusähnlichkeit. Dies ist das Design des Bi-Encoders, und es ist schnell, weil jeder Dokumentvektor im Voraus berechnet werden kann.

Ein Cross-Encoder erzeugt keine separaten Vektoren. Er verbindet die Abfrage und den Dokumenttext zu einem einzigen String und lässt alles gleichzeitig durch das Netzwerk laufen. Selbst-Attention kann daher in jeder Schicht sowohl die Wörter der Abfrage als auch die Wörter des Dokuments betrachten und so erkennen, wie sich die Begriffe im Kontext zueinander verhalten. Die Ausgabe ist eine einzige Relevanzbewertung.

Dieses Design eignet sich hervorragend für präzise Relevanzentscheidungen. Die Ergebnisse sind vorhersehbar und stabil, weisen eine viel geringere Streuung auf als bei der Anwendung auf ein Sprachmodell, und es bevorzugt zuverlässig einen spezifischen Auszug vor einer umfassenden Zusammenfassung.

Hier ist eine Neurangierungsfunktion, die auf einer gehosteten Cross-Encoder-API basiert.

import cohere
import time

def rerank_cross_encoder(
    query: str,
    candidates: list[dict],
    top_n: int = 5,
    model: str = "rerank-v4.0-pro",
) -> list[dict]:
    """
    The practical default for second-stage ranking.
    Passes the query and candidate texts to a dedicated cross-encoder model.
    """
    co = cohere.ClientV2()

    # Extract just the text content for the API call
    documents = [c["content"] for c in candidates]

    resp = co.rerank(
        model=model,
        query=query,
        documents=documents,
        top_n=top_n,
    )

    # Reattach the original metadata and the new score
    reranked = []
    for r in resp.results:
        original_chunk = candidates[r.index]
        reranked.append({
            **original_chunk,
            "rerank_score": r.relevance_score
        })

    return reranked

In der Produktion eignet sich ein Cross-Encoder für zehn bis fünfzig Kandidaten. Teams greifen ihn standardmäßig bei der Suche in Dokumentationen für Ingenieure, in Support-Wissensdatenbanken sowie in internen Copiloten auf.

Der Hauptkostenfaktor ist die Geschwindigkeit. Ein Cross-Encoder kann keine gesamte Datenbank durchscannen. Er wartet auf den ersten Durchlauf, erhält die Kandidaten über eine API oder ein lokales Modell und wartet anschließend auf die Bewertungen, wodurch ein Netzwerktransfer sowie ein Rechenschritt hinzukommen.

LLM-Reranker

Die Alternative ist ein allgemein einsetzbares Sprachmodell, das als Bewertungsinstanz fungiert. Ein präziser Prompt enthält die Anfrage des Benutzers sowie einen Kandidaten-Auszug, und das Modell gibt eine Bewertung zurück.

LLM-Reranker kommen gut mit Nuancen zurecht. Ein Cross-Encoder sucht nach tiefer semantischer Relevanz, während ein LLM außerdem prüfen kann, ob ein Verfahren abgeschlossen ist, durch widersprüchliche Beweise schlussfolgern kann und Abschnitte mit konkreten Schritten von solchen mit nur Hintergrundinformationen unterscheiden kann. Der Prompt kann anweisen, Vagheit zu bestrafen oder Abschnitte mit Codebeispielen zu bevorzugen.

Dieser Judge-Prompt verwendet Anthropics Client.

import anthropic

JUDGE_PROMPT = """\
You are a strict relevance judge. Given a user query and a candidate document chunk,
rate how well the chunk answers the query on a scale of 0 to 10.

Respond with ONLY a JSON object in this exact format:
{"score": <int>, "reason": "<one short sentence>"}

Query: {query}
Chunk: {chunk}"""

async def rerank_llm(
    query: str,
    candidates: list[dict],
    top_n: int = 5,
) -> list[dict]:
    """
    Expensive special forces. Uses an LLM to reason about nuance and completeness.
    """
    client = anthropic.AsyncAnthropic()
    scored = []

    for c in candidates:
        resp = await client.messages.create(
            model="claude-opus-4-6",
            max_tokens=128,
            messages=[{
                "role": "user",
                "content": JUDGE_PROMPT.format(query=query, chunk=c["content"]),
            }],
        )

        import json
        try:
            result = json.loads(resp.content[0].text)
            scored.append({
                **c,
                "rerank_score": result["score"],
                "reason": result.get("reason", "")
            })
        except (json.JSONDecodeError, KeyError):
            # Fallback if the model fails to follow JSON instructions
            scored.append({**c, "rerank_score": 0, "reason": "parse_error"})

    # Sort by the LLM-assigned score descending
    scored.sort(key=lambda x: x["rerank_score"], reverse=True)
    return scored[:top_n]

Das Modell wird aufgefordert, zusammen mit der Bewertung auch einen Grund anzugeben. Zunächst eine Begründung zu schreiben funktioniert wie ein Chain-of-Thought-Verfahren und stabilisiert die endgültige Zahl.

Sie verdienen ihr Geld mit hochwertigen Abfragen, in Systemen mit geringer Durchsatzrate, bei denen die Genauigkeit der Antwort eine Wartezeit rechtfertigt, sowie in komplexen Korpora, in denen die Relevanz von politischen Nuancen abhängt und nicht nur von einer reinen Themenübereinstimmung.

Die Kosten sind hoch. Für jeden potenziellen Teiltext wird ein vollständiger LLM-Aufruf durchgeführt, und selbst wenn die Aufrufe gleichzeitig laufen, bestimmt die langsamste Antwort das Ergebnis. Die Kosten liegen deutlich über denen eines Cross-Encoders, und die Ausgabe ist weniger deterministisch.

Welchen Einfluss hat das Neuranking auf die Latenz

Eine zusätzliche Stufe verändert die Leistung des Systems. Dadurch entstehen weitere Modellaufrufe, zusätzliche Serialisierung von Textdaten sowie mehr Netzwerkzeit.

Die Nutzer kümmern sich nicht darum, wie die Abfrage abgewickelt wird, und nehmen keine Informationen zu den Wiedererkennungsmetriken wahr. Sie achten auf die Qualität der Antworten sowie die Reaktionszeit. Ein theoretisch hervorragender Neurankierer ist nutzlos, wenn er den Assistenten zu langsam macht, sodass man ihm nicht vertrauen kann.

Dieser Hilfsprogramm misst die Laufzeit einer Neurankierungsfunktion.

def rerank_with_timing(
    rerank_fn: callable,
    query: str,
    candidates: list[dict],
    top_n: int = 5,
) -> tuple[list[dict], float]:
    """
    Measure the exact cost of the reranking stage.
    """
    t0 = time.perf_counter()

    results = rerank_fn(query, candidates, top_n)

    latency_ms = (time.perf_counter() - t0) * 1000
    return results, latency_ms

Das Übergeben von zwanzig Kandidaten an eine schnelle Cross-Encoder-API kann 150 bis 300 Millisekunden hinzufügen, was in der Regel ein angemessener Preis für besseren Kontext ist. Das Übergeben von fünfzig Kandidaten an einen LLM-Entscheider kann zwei bis vier Sekunden hinzufügen. Zusammen mit weiteren drei Sekunden für die Generierung wartet der Benutzer insgesamt sieben Sekunden – was über das Akzeptable in einer Chat-Schnittstelle hinausgeht.

Die Anzahl der neu rangierten Kandidaten muss angepasst werden. Die zehn besten Kandidaten liefern schnelle Ergebnisse, können aber bei Schwierigkeiten in der ersten Durchlaufphase den richtigen Inhalt übersehen. Die fünfzig besten Kandidaten erfassen fast alles, verbrauchen jedoch das gesamte Latenzbudget. Für einen Cross-Encoder in der Produktion ist in der Regel die Auswahl der zwanzig besten Kandidaten der optimale Kompromiss.

Wann sich das Neu-Rangieren lohnt

Fügen Sie einen Neu-Rangierer hinzu, wenn die erste Suchrunde unzuverlässig ist, aber in der Regel die relevanten Informationen findet.

Falls die Spuren zeigen, dass der genaue Beweisausschnitt häufig bei den Kandidaten vorkommt, aber nur auf Rang zehn oder fünfzehn liegt, wird eine Neubewertung das System umgehend reparieren. Dies ist gerechtfertigt, wenn umfassende Dokumente regelmäßig präzisere Verfahren übertreffen und die Antwortqualität stark davon abhängt, die drei besten Ausschnitte im Prompt zu haben – wodurch Präzision wichtiger ist als reine Erinnerungskraft.

Runbooks, interne Richtlinienassistenten und Fehlerbehebungstools benötigen fast immer einen Neubewertungsmechanismus. Die Wahl des richtigen Befehls anstelle eines nahe liegenden Fehlers kann darüber entscheiden, ob ein Incident gelöst wird oder zu einem Ausfall führt.

Wann ist Neubewertung übertrieben

Bei einem sehr kleinen Korpus sollte man darauf verzichten. Eine Wissensdatenbank mit fünfzig Seiten kann vollständig eingebettet und über Vektorabfragen bereitgestellt werden.

Es ist auch sinnlos, wenn die erste Verarbeitungsrunde bereits nahezu perfekt ist. In einem system, das stark auf Abfragen angewiesen ist und bei dem BM25 zuverlässig die richtige API-Referenz auf Platz eins bringt, verlangsamt ein Cross-Encoder die Prozesse nur, ohne das Ergebnis zu ändern.

Ein sehr enges Latenzbudget, wie es bei Sprachassistenten oder Inline-Code-Vervollständigungen der Fall ist, lässt keinen Raum für eine weitere Verarbeitungsstufe. Justieren Sie die erste Verarbeitungsrunde und akzeptieren Sie etwas „Rauschen“. Wenn der richtige Teil des Textes in der Regel bereits auf Platz eins oder zwei landet, ist die Rangliste nicht das, was Sie zurückhält.

Aufzupassende Fehlermuster

Reranker korrigieren die Reihenfolge, bringen aber ihre eigenen Probleme mit sich. Achten Sie nach der Implementierung auf diese.

Bias zugunsten umfassender Zusammenfassungen. Einige Cross-Encoders werden mit Daten trainiert, die umfassende Antworten belohnen. Eine allgemeine Übersicht kann einen kleinen, präzisen Codeausschnitt übertreffen, weil die Übersicht mehr Wörter mit der Abfrage gemeinsam hat.

Doppelte Überlastung. Wenn das Korpus drei Versionen eines Einrichtungshandbuchs enthält, wird die erste Durchlaufphase vermutlich alle drei herunterladen. Der Neubewertungsmechanismus betrachtet jede Version als gute Antwort auf die Anfrage und bewertet sie alle hoch. Die drei besten Ergebnisse im Kontextfenster enthalten dann dieselben Informationen, wodurch weitere eindeutige Belege verdrängt werden. Ein solcher Hilfsmechanismus beseitigt nahezu identische Inhalte.

def dedupe_candidates(
    candidates: list[dict],
    similarity_threshold: float = 0.85,
) -> list[dict]:

    seen_tokens: list[set[str]] = []
    deduped = []

    for c in candidates:
        tokens = set(c["content"].lower().split())
        is_dup = False

        for s in seen_tokens:
            # Calculate simple Jaccard similarity
            overlap = len(tokens & s) / max(len(tokens | s), 1)
            if overlap >= similarity_threshold:
                is_dup = True
                break

        if not is_dup:
            deduped.append(c)
            seen_tokens.append(tokens)

    return deduped

Voreingenommenheit gegenüber veralteten Dokumenten. Ein Cross-Encoder liest nur den Text und hat keine Ahnung, in welchem Jahr wir uns befinden. Ein sorgfältig erstelltes Handbuch aus dem Jahr 2022 kann bessere Ergebnisse liefern als eines aus dem hastig erstellten Jahr 2026, obwohl das ältere Dokument völlig veraltet ist. Nach der Neubewertung angewendete Metadatenanpassungen korrigieren die Bewertungen hinsichtlich Aktualität und Dokumentstatus.

from datetime import datetime, timezone

def apply_metadata_boost(
    candidates: list[dict],
    freshness_halflife_days: int = 90,
) -> list[dict]:

    now = datetime.now(timezone.utc)
    boosted = []

    for c in candidates:
        score = c.get("rerank_score", 0.0)

        # Hard penalty for superseded documentation
        if c.get("status") == "superseded":
            score *= 0.4

        # Gradual decay for older documents
        updated = c.get("updated_at")
        if updated:
            age_days = (now - updated).days
            decay_factor = max(0.5, 1 - age_days / (freshness_halflife_days * 2))
            score *= decay_factor

        boosted.append({**c, "rerank_score": score})

    # Sort again based on the adjusted scores
    boosted.sort(key=lambda x: x["rerank_score"], reverse=True)
    return boosted

Explosion der Latenzzeit. Die Qualität verbessert sich nach dem Einsatz, doch gelegentlich stürzt das System für fünf Sekunden ab. Dies tritt in der Regel auf, wenn die Anzahl der Kandidaten stark ansteigt oder die externe Neubewertungs-API versagt. Es sollte stets ein Timeout-Backup vorhanden sein, das bei langen Laufzeiten der zweiten Phase auf die Ergebnisse der ersten Phase ausweicht.

Angemessene Bewertung eines Neubewerters

Teams messen oft das Falsche, indem sie prüfen, ob der richtige Teiltext irgendwo in den ersten zwanzig Ergebnissen erscheint. Die erste Suchphase deckt dies bereits ab.

Die wichtigere Frage ist, ob der Neubewerter den richtigen Teiltext ausreichend nach oben gebracht hat, um von Bedeutung zu sein. Dazu gehören die Messung der Relevanz der ersten und dritten Ergebnisse, die Vollständigkeit der Antworten sowie die Beseitigung von Duplikaten, zusätzlich zur Überwachung der Latenzzeit und der Kosten pro Abfrage.

Entwickeln Sie ein Bewertungstool, das den einfachen Baseline-Ansatz in einer ersten Durchlauf mit dem Cross-Encoder sowie dem LLM-Reranker vergleicht, wobei identische Kandidatensätze verwendet werden.

from dataclasses import dataclass

@dataclass
class RerankEvalCase:
    query: str
    expected_substring: str
    category: str  # e.g., "identifier", "procedure", "troubleshooting"

def eval_reranking(
    cases: list[RerankEvalCase],
    retrieve_fn: callable,
    rerank_fns: dict[str, callable | None],
    top_n: int = 3,
) -> dict:
    """
    Compare multiple reranking strategies against a baseline.
    Measures hit rate at top-N and tracks latency overhead.
    """
    results = {}

    for name, rerank_fn in rerank_fns.items():
        hits = 0
        total_latency = 0.0
        by_type: dict[str, dict] = {}

        for case in cases:
            # Get the exact same starting candidates for every strategy
            candidates = retrieve_fn(case.query)

            if rerank_fn is not None:
                reranked, lat = rerank_with_timing(
                    rerank_fn, case.query, candidates, top_n
                )
                total_latency += lat
            else:
                # Baseline: just take the top-N from first-pass retrieval
                reranked = candidates[:top_n]

            # Check if the expected evidence made it into the final prompt window
            top_contents = [r["content"] for r in reranked]
            found = any(case.expected_substring in c for c in top_contents)
            hits += int(found)

            # Track metrics by query category
            by_type.setdefault(case.category, {"hit": 0, "total": 0})
            by_type[case.category]["total"] += 1
            by_type[case.category]["hit"] += int(found)

        total = len(cases)
        results[name] = {
            "hit_rate": hits / total if total else 0,
            "avg_latency_ms": total_latency / total if total else 0,
            "by_type": {
                t: {**v, "rate": v["hit"] / v["total"]}
                for t, v in by_type.items()
            },
        }

    return results

Der Testdatensatz sollte verschiedene Abfruchtypen umfassen: solche mit vielen Identifikatoren, bei denen die genaue Zeichenfolge entscheidend ist, solche, bei denen die Einhaltung von Schrittfolgen wichtig ist, sowie solche zur Fehlerbehebung, bei denen Symptome auf die Ursachen hinweisen.

Die Zahlen zeigen anschließend genau, was der Neurangier gewinnt. Wenn ein Cross-Encoder die Trefferquote der Top-3 von 60 % auf 85 % innerhalb von 200 Millisekunden erhöht, sollte er verwendet werden. Wenn der LLM-Neurangier eine Trefferquote von 88 % über drei Sekunden erreicht, bleibt der Cross-Encoder wahrscheinlich. Die Neurangierung muss durch bessere Endantworten innerhalb eines realistischen Latenzbudgets gerechtfertigt werden.

Eine sinnvolle Standardkonfiguration

Eine zuverlässige Grundlage für ein Produktionsystem folgt einer bestimmten Abfolge. Teilen Sie Dokumente mithilfe von strukturbewusstem Chunking auf. Verwenden Sie eine hybride Suchmethode, um zwanzig bis dreißig Kandidaten zu sammeln. Entfernen Sie Duplikate, um nahezu identischen Text zu beseitigen. Bewerten Sie den Rest mit einem Cross-Encoder hinsichtlich semantischer Relevanz. Wenden Sie einen Metadaten-Boost an, der veraltete Dokumente bestraft. Nehmen Sie anschließend die drei bis fünf besten Blöcke aus der endgültig sortierten Liste und erstellen Sie daraus den Prompt.

def two_stage_retrieve(
    query: str,
    retrieve_fn: callable,
    top_k: int = 20,
    top_n: int = 5,
) -> tuple[list[dict], dict]:
    """
    The complete production pipeline for second-stage ranking.
    """
    t0 = time.perf_counter()

    # Stage 1: Fast hybrid retrieval
    candidates = retrieve_fn(query)[:top_k]

    # Clean up the candidate pool
    candidates = dedupe_candidates(candidates)

    # Stage 2: Cross-encoder rerank
    # We score slightly more than top_n to allow metadata boosts to reorder the edges
    score_limit = min(top_n * 2, len(candidates))
    reranked = rerank_cross_encoder(query, candidates, top_n=score_limit)

    # Apply business logic for freshness and status
    final = apply_metadata_boost(reranked)[:top_n]

    latency = (time.perf_counter() - t0) * 1000

    trace = {
        "query": query,
        "first_pass_count": len(candidates),
        "post_rerank_count": len(reranked),
        "final_count": len(final),
        "latency_ms": latency,
    }

    return final, trace

Die Standardlösung funktioniert, weil jedes Werkzeug die Aufgabe erledigt, für die es geeignet ist. Die Abruflogik kümmert sich um die Wiederherstellung der Kandidaten, die Neubewertungslogik um die Reihenfolge der Kandidaten, und die Kreuzkodierer liefern für diese zweite Phase das beste Verhältnis von Qualität zu Latenz.

Eine Einschränkung: Eine Neubewertungslösung sollte nicht einfach hinzugefügt werden, um fehlerhafte Daten zu beheben. Bei schlechtem Aufteilen der Daten wird sie lediglich die fehlerhaften Teile korrekt sortieren. Bei fehlenden Metadaten kann sie nicht erraten, welches Dokument veraltet ist. Beheben Sie zunächst die Probleme bei der Eingabe und Extraktion der Daten.

Was die Neubewertung noch ungelöst lässt

Eine Neubewertungslösung sorgt dafür, dass die stärksten Belege aus der abgerufenen Menge zum Modell gelangen. Was sie jedoch nicht verraten kann, ist, ob eine Vektorsuche überhaupt die richtige Entscheidung war. Nehmen wir die Frage, wie viele Nutzer in einer bestimmten Region aktiv sind: Es ist falsch, diese Frage an einen Dokumentationsindex zu richten, denn diese Zahl befindet sich in einer SQL-Datenbank.

Die Qualität der Informationsabrufung hat verschiedene Ebenen. In der ersten Phase wird der Text gefunden und in der zweiten geordnet, doch bereits zuvor wird entschieden, wo gesucht werden soll. Die Zuweisung einer Anfrage an die Vektorabfrage, SQL-Abfragen oder die Live-Websuche, basierend auf der Absicht des Benutzers, ist die Ebene, die allen anderen Schritten vorausgeht.