2026-05-10 · Aktualisiert 2026-07-22

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

Bewertung von RAG: Metriken für jede Phase eines produktiven RAG-Systems

Teil 1 der Produktionsreihe RAG

Ein RAG-System mit fehlerhaften Filtern kann monatelang ohne Auslösung eines Betriebsalarms weiterlaufen. Es liefert weiterhin Antworten und erfüllt sein Latency-Ziel, doch diese Antworten stützen sich auf unvollständige Belege. Ein Recall@k gegen den ursprünglichen Gold-Set macht diesen Verlust sichtbar; Latency- sowie Verfügbarkeits-Dashboards hingegen nicht.

Die Bewertung kann einen Fehler nur dann erkennen, wenn jede Pipeline-Phase über eigene Metriken verfügt. In diesem Artikel werden gängige Fehlermuster diesen Metriken zugeordnet – von der Dokumentanalyse bis hin zur Überwachung im Produktivbetrieb.

!!! Tipp „Möchten Sie direkt zum Code springen und ihn ausführen?“

Der ausführbare Code [`slavadubrov/rag-evals-demo`](https://github.com/slavadubrov/rag-evals-demo) Der Repository wendet die Metriken auf SciFact an. `make eval` führt das Suite aus und `make benchmark` Es werden die Konfigurationen von Chunking, Embedding und LLM verglichen. Die Notebooks 00–09 isolieren jeweils eine Metrik. Da die Demo ein eingebettetes Qdrant verwendet, ist kein Docker erforderlich.

Zusammenfassung

• Die Bewertung definiert das System. Eine Phase ohne Metrik ist eine Phase, die stillschweigend versagt.
• Ein nützlicher Bewertungsstack umfasst die Eingabe, Retrieval, die Generierung Grounding, die Konformität zur Ontologie sowie die Systemsignale. RAGAS, TruLens, DeepEval, Arize Phoenix, und der TREC 2024 RAG Spur Wir stellen Ihnen die entsprechenden Werkzeuge zur Verfügung. Sie wählen jedoch selbst die Metriken aus. – Bei auf Metadaten sowie Ontologien basierenden RAG kann ein falscher Tag oder ein instabiler, starre Prädikat den Recall auf Null reduzieren. Der Standard-Recall@k erkennt diesen Verlust, da er die ursprüngliche Referenzmenge beibehält. Eine Metrik zur Erkennung falscher Ausschlüsse identifiziert die Ursache, während die Zuverlässigkeit weiterhin gut erscheinen kann – schließlich hat der Model zuverlässig mitgeteilt: „Ich weiß es nicht.“

Die Abschnitte folgen der Reihenfolge von Pipeline. Beginnen Sie mit der Entscheidungstabelle und nutzen Sie die nachfolgenden Abschnitte anschließend als Referenz für jede Phase.

RAG-Bewertungsbeschluss-Tabelle

Verwenden Sie diese Tabelle als Ausgangspunkt, bevor Sie einen Framework auswählen. Die geeignete Metrik hängt vom zu erfassenden Fehlermodus ab und nicht vom Namen des Tools.

Für einen kürzeren Vergleich der Tools siehe Die besten Bewertungstools und Metriken für RAG im Jahr 2026.

Teil 1: Erfolg definieren, bevor die Architektur entworfen wird

Entwerfen Sie den Eval-Set vor dem Architekturdiagramm. Dadurch erhält jede spätere Komponentenauswahl ein messbares Ziel.

Man kann nicht einfach zwischen BM25 und dichten Retrieval-Modellen, rekursiven und semantischen Chunking-Ansätzen oder Cohere Rerank sowie BGE wählen, solange man nicht genau weiß, was optimiert werden soll. „Bessere Antworten“ ist keine messbare Kennzahl. Ein geeignetes Leistungsprofil sieht beispielsweise so aus: „Treuegrad ≥ 0,85 auf einer Testmengen von 200 Abfragen, die unsere drei wichtigsten Intentionen abdecken, wobei die p95 Latency-Wert unter 1,5 Sekunden liegt und die Rate falscher Ausklusionen unter 2 % beträgt.“ Die genannten Zahlen dienen lediglich als Platzhalter; entscheidend sind vielmehr klare Kriterien für Qualität, Abdeckung, Latency-Funktionen sowie das Filtern von Ergebnissen.

Definieren Sie den Harness vor dem Schreiben des Retrieval-Codes. Der erste Harness wird fehlerhaft sein, und Sie müssen ihn korrigieren. Die Anpassung einer Metrik ist weitaus kostengünstiger als die Überarbeitung eines bereits veröffentlichten Systems.

Drei Pipeline Schichten und zwei Betriebsmodi

Moderne RAG sind Pipeline, weshalb die Bewertung als Pipeline erfolgen muss. Keine einzige Zahl kann alle möglichen Fehlerfälle abdecken.

Die Produktivitätsbewertung umfasst drei Pipeline-Ebenen. Bei der Evaluierung der Dateneingabe wird geprüft, ob das Korpus sowie der Index die ursprünglichen Inhalte erhalten haben. Bei der Evaluierung zum Zeitpunkt der Abfrage wird überprüft, ob durch Umformulieren, Filtern, Retrieval, Reranking sowie Zusammenführung des Kontexts die richtigen Belege gefunden wurden. Schließlich prüft die Evaluierung der Antwort und der Produktivität, ob die Antwort tatsächlich auf diesen Belegen beruht und ob die Qualität unter echtem Nutzerverkehr gewährleistet bleibt. Wenn diese Ebenen zu einem einzigen Score zusammengefasst werden, kann ein Fehler bei der Normalisierung innerhalb eines akzeptablen Antwortwerts verborgen bleiben.

Diese Schichten beschreiben, an welcher Stelle ein Fehler auftritt. Offline und online geben an, zu welchem Zeitpunkt und mit welchen Daten die Überprüfung durchgeführt wird. Bei der Offline-Bewertung wird eine feste Dataset unter Verwendung bekannter Referenzwerte verwendet; sie ist reproduzierbar und eignet sich für die Auswahl von Komponenten, A/B-Vergleiche sowie CI-Gates. Die Online-Bewertung bewertet Samples aus dem Live-Traffic und erfasst Aspekte wie Regeneration, Verweildauer, explizite Rückmeldungen sowie tatsächliche Abweichungen der Anfragen. Sie weist mehr Rauschen auf und ist schwieriger zu instrumentieren.

Jede Pipeline Schicht kann sowohl Offline- als auch Online-Prüfungen durchführen. Ein fest definiertes Eingabekorpus erkennt Regressionen des Parsers bereits vor der Veröffentlichung, während Monitore für Aktualität und Parse-Fehler die Live-Updates überwachen. Eine feste Abfragesammlung dient dazu, Retrieval vor der Veröffentlichung zu messen, wohingegen stichprobenartige Live-Traces-Abfragen Abweichungen im Produktivumfeld aufdecken. Prüfungen ausschließlich im Offline-Modus übersehen Änderungen in Echtzeit; Prüfungen ausschließlich im Online-Modus erschweren es zudem, Regressionen nachzuvollziehen.

Komponentenebene versus End-zu-Ende

Es gibt zwei häufige Fehlerquellen. Eine Bewertung ausschließlich im End-to-End-Modus zeigt zwar an, dass das System fehlerhaft ist, nicht jedoch wo genau. Eine Bewertung nur der einzelnen Komponenten kann hingegen darauf hinweisen, dass alle Teile erfolgreich sind, obwohl das Gesamtsystem weiterhin versagt. Die Lösung besteht darin, einige zentrale End-to-End-Metriken zur Entscheidungsfindung über Erfolg oder Misserfolg zu verwenden und zusätzlich Komponentenmetriken für die Diagnose. Retrieval-Metriken erkennen Regressionen beim Retrieval-Modul, Generierungsmetriken erkennen Regressionen beim Generierungsmodul und die End-to-End-Korrektheit der Antworten zeigt Integrationsfehler auf.

Der Referenzweg Frameworks (vorgefertigter Tourplan)

Mein Standard-Stack umfasst RAGAS für das Metrik-Wortschatz, DeepEval für CI-Gates, Phoenix für die Produktion Tracing sowie eigene Codebausteine für metrikenspezifische Anforderungen innerhalb der Ontologie. Jede Lösung, mit der man beginnt, wird irgendwann zu eng für die wachsenden Anforderungen. Wählen Sie daher den Framework, der die Erstellung von benutzerdefinierten Metriken erleichtert.

Für Benchmarks sollte man verwenden BEIR (Laut Thakur et al., NeurIPS 2021) für die zero-shot Retrieval-Generalisierung. MTEB für eine allgemeine Embedding-Qualität. MIRACL für mehrsprachige Retrieval-Systeme sowie die TREC 2024 RAG Spur zur end-to-end RAG-Bewertung.

Teil 2: Bewertungspunkte auf den Pipeline abbilden

Ein Produktivsystem RAG umfasst weitaus mehr als nur das Einbetten von Dokumenten, das Abrufen von Teilstücken sowie den Aufruf eines LLM. Jede Stufe zwischen der Dokumentenerfassung und der Bereitstellung der Antwort kann fehlschlagen.

Jede Stufe im Diagramm verfügt über mindestens eine Metrik. Eine Stufe ohne Metrik kann fehlschlagen, ohne dass es jemand bemerkt.

Die drei Kanäle entsprechen den Bereichen, in denen Beweismittel verloren gehen können. Der Eingabekanal umfasst die Parsing-, Reinigungs-, Chunking-, Embedding- sowie Indexierungsprozesse. Der Kanal zur Abfragenzeit beinhaltet das Umformulieren, Filtern, Retrieval-, Reranking- sowie die Zusammenstellung des Kontexts. Der Kanal für Antworten und die Produktion kümmert sich um die Genauigkeit der Ergebnisse, die Überprüfung von Quellenangaben, Benutzersignale, Drift-Effekte, Latency sowie die Kosten.

Fehler kumulieren sich entlang der Verarbeitungskette. Eine fehlerhafte Parsing-Logik beschränkt Chunking. Fehlende Chunking begrenzen wiederum Retrieval. Mangelhafte Retrieval beeinträchtigen schließlich Reranking. Fehlerhafte Reranking hemmen zudem die Generierung von Ergebnissen. Die Treueprüfung misst lediglich das endgültige Ergebnis und nicht die ursprünglichen Auslöser.

Teil 3: Bewertung der Dateneingangsprozesse

Viele Fehlfälle bei RAG in der Produktion beginnen bereits in der Eingabephase. Das System funktioniert mit sauberen Testdokumenten einwandfrei, scheitert jedoch bei echten PDF-Dateien, Scans, Tabellen sowie unstrukturierten Seiten aus großen Datensätzen.

Dokumentbeschaffung und Parsing

Was gemessen werden sollte:

• Vollständigkeit der Textextraktion: extracted_chars / expected_chars auf einem gelabelten Beispiel, berechnet pro Dokumentklasse. Es gibt kein standardisiertes Paket – schreiben Sie einen kleinen Harness, der die Ausgabe des Parsers mit einer manuell bearbeiteten Referenz vergleicht. Achten Sie auf fehlende Fußnoten, Überschriften und Bildunterschriften.

• OCR-Genauigkeit: CER (Character Error Rate) und WER (Word Error Rate), die gängigen Metriken für Sprach-/OCR-Systeme:

  $$\text{CER} = \frac{S + D + I}{N}, \qquad \text{WER} = \frac{S_w + D_w + I_w}{N_w}$$

  wobei $S$, $D$, $I$ charakterweite Substitutionen, Deletionen und Insertionen sind und $N$ die Referenz-Zeichenzahl darstellt (Unterschrift $w$ für die Wortversion). Es soll nicht für jedes Korpus eine einzige CER-Grenze angewendet werden. Diese sollte stattdessen anhand der Dokumentklasse sowie des Verlusts bei den anschließenden Antworten kalibriert werden; gedruckter Text, Handschrift und mehrsprachiges Material weisen unterschiedliche Fehlerprofile auf. Berechnen Sie damit jiwer (jiwer.cer(refs, hyps), jiwer.wer(refs, hyps)) oder HuggingFace evaluate. Für Evaluationskorpora, FUNSD und SROIE sind öffentlich Benchmarks.

  from jiwer import cer, wer
  
  refs = ["Mars has two moons, Phobos and Deimos."]
  hyps = ["Mars has two m00ns, Phobos and Deirnos."]
  
  print(f"CER = {cer(refs, hyps):.3f}")  # CER = 0.105
  print(f"WER = {wer(refs, hyps):.3f}")  # WER = 0.286

• Genauigkeit der Tabellenextraktion: TEDS (Tree-Edit-Distance-based Similarity) misst, wie nah ein vorhergesagter HTML-Tabellenbaum dem Referenzbaum ist, wobei die Messung durch die Größe des größeren Baums normalisiert wird. Aus Zhong et al., 2020 (PubTabNet):

  $$\text{TEDS}(T_a, T_b) = 1 - \frac{\text{EditDist}(T_a, T_b)}{\max(|T_a|, |T_b|)}$$

  TEDS nutzt sowohl die Struktur (Zeilen, Spalten, Spans) als auch den Zellinhalt; TEDS-S entfernt den Inhalt und bewertet ausschließlich die Struktur. Referenzimplementierung: PubTabNet’s teds.py ( verwendet apted im Hintergrund. Zu den Bewertungskorpora siehe PubTabNet. FinTabNet, sowie SciTSR. Naive Parser versagen häufig bei Tabellen; Benchmark sollte daher vor dem Vertrauen darauf verwendet werden.

• Erhaltung der Layout-/Strukturlogik: Reihenfolge der Überschriften, Integrität der Listen sowie Lesereihenfolge in mehrspaltigen PDF-Dokumenten. Verwenden Sie DocLayNet für ein gelabeltes Benchmark. Ein fertig verfügbarer Vergleich kann Span einen Elementparser wie unstructured, eine PDF-Bibliothek wie pymupdf, sowie ein VLM-Parser wie docling.

Vergleichen Sie verschiedene Parser-Familien – beispielsweise eine Tesseract-Baseline, einen auf VLM basierenden OCR Model sowie Ihren eigenen Kandidaten von einem Drittanbieter. Verwenden Sie dazu eine stratifizierte Stichprobe aus echten Dokumentenklassen bei einer festen DPI, wobei saubere Scans, Fotos, Tabellen, mehrsprachiger Text, Mathematikformeln und Handschrift berücksichtigt werden sollen. Berichten Sie den CER bzw. WER für jede Klasse sowie den TEDS für Seiten mit Tabellen.

Reinigung und Normalisierung

• Genauigkeit bei der Entfernung von Boilerplate: Präzision/Auflösung im Vergleich zu von Menschen gelabeltem Boilerplate Spans. Eine zu aggressive Entfernung führt zum Verlust relevanter Inhalte; eine zu nachsichtige Entfernung verschmutzt Embeddings. Zum Vergleich verfügbare Tools: trafilatura, jusText, Resiliparse. Barbaresi (2021) Benchmarks diese direkten Vergleiche.

• Unicode-Normalisierung: Prozentsatz der Dokumente, die identische NFC- und NFKC-Ergebnisse liefern (berechnet mit der stdlib) unicodedata.normalize) Es handelt sich dabei um ein nützliches Signal für Drift. Genau solche Unstimmigkeiten führen dazu, dass Zero-Width-Joiner sowie ähnliche Zeichen die Recall-Werte von Retrieval zerstören.

• Genauigkeit der Spracherkennung: F1-Wert auf einem gelabelten mehrsprachigen Datensatz. Von entscheidender Bedeutung für mehrsprachige Indizes. Verwenden Sie fasttext-langdetect (Facebooks lid.176), lingua-py, oder cld3. FLORES-200 Es stehen Bewertungstexte in 200 Sprachen zur Verfügung, wobei die zu testende Sprachkombination von Ihrer Produktionsumgebung abhängen sollte.

• Effektivität der Doppelungserkennung (MinHash / LSH): Genauigkeit/Auflösung Ihres Detektors für nahezu identische Datensätze anhand einer manuell beschrifteten Testmengen. Die zugrundeliegende Idee: Schätzung der Jaccard-Ähnlichkeit J(A, B) = \frac|$A \cap B$|}{|A ∪ B|$-$ zwischen den Dokument-Set-Blöcken mittels $k$ zufälliger Permutationshashes.Broder, 1997) und nahezu identische Elemente mithilfe von LSH-Banding zusammenfassen.Indyk und Motwani, 1998). Überprüfen Sie die Hash-Zählung sowie den Jaccard-Threshold für Ihr Korpus. Erfassen Sie den Anteil an falschen Fusionen – die zu fehlerhaften Antworten führen – getrennt vom Anteil an fehlgeschlagenen Fusionen, die Ressourcen im Index verschwenden. datasketch es liefert die unten verwendete Implementierung; ihre Parameter dienen lediglich zur Veranschaulichung:

  from datasketch import MinHash, MinHashLSH
  
  def shingles(text: str, k: int = 5) -> set[str]:
      text = text.lower()
      return {text[i:i + k] for i in range(len(text) - k + 1)}
  
  def to_minhash(text: str, num_perm: int = 128) -> MinHash:
      m = MinHash(num_perm=num_perm)
      for s in shingles(text):
          m.update(s.encode("utf-8"))
      return m
  
  docs = {
      "d1": "Mars has two moons, Phobos and Deimos.",
      "d2": "Mars has two moons, Phobos and Deimos!",   # near-dup
      "d3": "Curiosity rover landed on Mars in 2012.",
  }
  
  lsh = MinHashLSH(threshold=0.8, num_perm=128)
  for did, text in docs.items():
      lsh.insert(did, to_minhash(text))
  
  print(sorted(lsh.query(to_minhash(docs["d1"]))))  # ['d1', 'd2']

• PII-Ausfilterung: Genauigkeit und Trefferquote, die jeweils für jeden Entitätstyp (E-Mails, Sozialversicherungsnummern, Namen, Adressen) separat berechnet werden. Fehler bei der Trefferquote führen zu Compliance-Risiken, während Fehler bei der Genauigkeit die Qualität der Antworten beeinträchtigen. Der optimale Betriebspunkt sollte in Absprache mit dem Rechtsteam festgelegt werden. Zu den möglichen Werkzeugen gehören Microsoft Presidio, scrubadub, oder ein feinabgestimmter NER Model auf einem gelabelten Datensatz.

Chunking steuert die Qualität von Retrieval

Chunking kann selbst dann eine Mehrpunkte-Rückruflücke verursachen, wenn der Embedding Model konstant bleibt. In NVIDIAs Anbieter für das Jahr 2024 Benchmark, Die auf Seiteebene erfolgende Chunking-Verarbeitung erzielte bei paginierten Dokumenten die höchste Genauigkeit sowie die geringste Varianz. Dieses Ergebnis sollte als Beleg für den getesteten Datensatz betrachtet werden und nicht als allgemeingültiger Sieger angesehen werden.

Semantische Chunking-Gruppen ordnen benachbarte Sätze aufgrund von Embedding-Ähnlichkeit zusammen und trennen sie an unähnlichen Grenzen. LangChain’s SemanticChunker und der von LlamaIndex SemanticSplitterNodeParser Implementieren Sie diese Strategie. Sie kann die Recall-Rate bei festen Zeitfenstern verbessern, insbesondere dann, wenn thematische Grenzen eine entscheidende Rolle spielen.

Die rekursive Zeichensegmentierung versucht zunächst Absatztrennungen, anschließend Satzzeichen und danach Worttrennungen, bis jedes Segment die gewünschte Größe erreicht. LangChain’s RecursiveCharacterTextSplitter führt die Sequenz aus. Wählen Sie geeignete Fenster- und Überlappungswerte, die zur Struktur Ihres Dokuments passen, und überlassen Sie anschließend der „goldenen Menge“, die endgültigen Werte zu bestimmen.

Zu überwachende Metriken:

• Blöck-Kohärenz: $\text{Kohärenz} = \overline{\cos(s_i, s_j)}_{\text{innerhalb}} - \overline{\cos(s_i, s_j)}_{\text{über Grenze}}$, wobei $s_i$ Sätze Embeddings sind. Gesunde Blöcke weisen eine hohe Ähnlichkeit untereinander auf und eine geringe Ähnlichkeit an den Grenzen. Die Berechnung erfolgt mit sentence-transformers plus scikit-learn’s cosine_similarity.
• Grenzkvalität: menschlich annotierte Bewertungen zur Frage „Ist dies ein sinnvoller Schnitt?“, sowie eine strukturelle Überprüfung, um sicherzustellen, dass die Blöcke Tabellen, Listen oder nummerierte Abschnitte nicht teilen.
• Optimale Blockgröße: Testen Sie Token verschiedene Größenwerte (128, 256, 512, 1024) und erstellen Sie einen Plot von Recall@k gegenüber der Größe anhand Ihres Referenzdatensatzes. Wählen Sie den Punkt, an dem die Kurve eine Wendung zeigt – nicht einfach das, was im Tutorial empfohlen wird.
• Effektivität der Überlappung: Variieren Sie mehrere Überlappungsgrade und messen Sie dabei den Recall@k-Wert. Beenden Sie die Erhöhung der Überlappung, sobald die lokale Recall-Kurve flacher wird oder die Kosten durch Duplikate die Vorteile übersteigen.
• Treue der Blockzuordnung: Prozentsatz der Blöcke, die einen nachvollziehbaren Quellenverweis beibehalten (Seitennummer, Abschnittsanker, Dokument-ID). Für Auditableit ist dies unerlässlich.
• Späte vs. frühe Chunking: spät Chunking (Günther et al., 2024) fügt den gesamten Dokumenttext ein und segmentiert ihn anschließend, wodurch der globale Kontext erhalten bleibt (Referenzimplementierung in) jina-embeddings-v3). kontextbezogener Retrieval (Anthropic, 2024) fügt zu jedem Chunk den von LLM erzeugten Kontext voran. Beides verursacht zusätzliche Kosten. Prüfen Sie daher zunächst den Benchmark Ihres Korpus, bevor Sie eines dieser Verfahren einsetzen.

Meine Meinung: strukturelle Chunking Gliederung (Aufteilung nach Überschriften, Tabellen und Abschnitten – umgesetzt durch Parser wie unstructured.io oder durch das Durchlaufen des bereits von Ihrem Parser erzeugten ASTs) wird zu wenig genutzt. Wenn Ihre Dokumente eine Struktur aufweisen, sollten Sie diese zunächst nutzen, bevor Sie Ähnlichkeitsheuristiken anwenden. Die rekursive Zeichensegmentierung stellt die Grundlage dar; semantische Chunking-Verarbeitung lohnt sich hauptsächlich bei unstrukturiertem Prosa-Text.

Extraktion und Erweiterung von Metadaten

• NER Präzision/Auflösung/F1-Score: pro Entitätsart, auf einem gelabelten Teilmenge. Im üblichen CoNLL/MUC-Stil. Berechnung erfolgt mit seqeval (from seqeval.metrics import f1_score) für die auf BIO/IOB-Tagungen ausgerichtete Version oder scikit-learn zur Durchführung von Span-Mengenvergleichen. CoNLL-2003 und OntoNotes 5.0 gelten als die kanonischen Referenzkorpora.
• Relation Extraction F1: Dieser Wert ist insbesondere für auf Ontologien basierende Systeme von großer Bedeutung. Beschriften Sie manuell eine Menge, die nach Relationstyp und Dokumentklasse strukturiert ist. TACRED und DocRED sind öffentlich verfügbar Benchmarks; zu den möglichen Implementierungen zählen opennre und spaCy Beziehung Pipelines.
• Genauigkeit der Titel-/Überschriftenextraktion: exakte Übereinstimmung in Kombination mit normalisierter Levenshtein-Ähnlichkeit ($1 - \frac{\text{edit\_dist}(a, b)}{\max(|a|, |b|)}$) im Vergleich zur Ground Truth — python-Levenshtein oder rapidfuzz beide in einem einzigen Aufruf bereitstellen.
• Hierarchische Metadatenpräservierung: Prozentsatz der Blöcke, die ihre übergeordnete Sektion, das übergeordnete Dokument sowie den Abstammungspfad korrekt beibehalten. Dieser Wert ist maßgeblich dafür, ob Ihr RAG Fragen vom Typ „Was besagt das Kind der Richtlinie X?“ beantworten kann.

Embedding-Generierung

• Model Auswahl Benchmarks: MTEB zur Bewertung der allgemeinen Leistungsfähigkeit (nDCG@10 dient als Hauptindikator; die MTEB-Python-Paket (lässt es zu, die Leaderboard-Daten lokal nachzubilden), BEIR für die Zero-Shot-Generalisierung. MIRACL für mehrsprachige Anwendungen: Der beste Retrieval Models-Cluster liegt innerhalb eines engen nDCG@10-Bereichs, doch die englischen MTEB-Werte liefern nur ungenaue Vorhersagen bezüglich der Leistung bei Sprachen mit begrenzten Ressourcen.
• Domänenbezogene Bewertung: Ein allgemeiner Rang von Benchmark darf nicht als Ergebnis für eine spezifische Domäne angesehen werden. Erstellen Sie eine „Golden-Set“-Sammlung für die Domäne anhand ihrer Abdeckungsmatrix sowie der Unsicherheit, die Ihre Entscheidungsfindung zulässt. Ordnen Sie die Kandidaten von Models anschließend erneut auf dieser Grundlage. ranx oder pytrec_eval. Ein Domänenmenge kann die Reihenfolge der Leaderboard-Listen umkehren; daher sollten die Dataset-Schnittstelle, das Retrieval-Protokoll sowie der Konfidenzintervall zusammen mit dem Ergebnis veröffentlicht werden.
• Embedding-Detektion von Abweichungen: Überwachung der durch die KL-Divergenz beschriebenen Verteilungsänderungen oder abweichungen auf Basis von Model zwischen einem festen Referenzfenster und dem sich dynamisch erweiternden Produktionsumfeld Embeddings; zudem wird die Stabilität bezüglich des nächsten Nachbarn für eine feste Probemenge gemessen. evidently und alibi-detect Implementieren Sie detektierende Mechanismen, die auf Model-Basis sowie statistischen Verfahren beruhen. Evidently’s vergleichende Studie Es handelt sich dabei um eine Bewertung einzelner Anbieter; vergleichen Sie die Methoden anhand bekannter Schwankungen in Ihren eigenen Embeddings.
• Mehrvektor- versus Einfachvektorverfahren: Durch späte Interaktion werden die Repräsentationen auf Token-Ebene beibehalten, anstatt jedes Dokument in einen einzigen Vektor zusammenzufassen; ColBERT es handelt sich um das kanonische Design, wobei Referenzimplementierungen vorhanden sind RAG-Atouille und PyLate. Diese aufwendigere Repräsentation erhöht die Kosten für das Indexieren sowie den Retrieval-Prozess. Vergleichen Sie vor der Einführung die Qualität, den Speicherbedarf und den Latency-Wert im Vergleich zu einer Baseline mit einem einzigen Vektor für denselben Datensatz.

Indexerstellung

• Recall@k unter Annäherung: Vergleichen Sie den Index des approximativen nächsten Nachbarn (ANN) mit einer exakten Brute-Force-Baseline bei derselben k – in FAISS, das ist IndexHNSWFlat (oder) IndexIVFFlat) gegenüber IndexFlatIP/IndexFlatL2. Legen Sie den zulässigen Recall-Verlust gemäß Ihrem nachgelagerten Qualitätsbudget fest. Der ann-benchmarks Das Projekt verfolgt die Recall- sowie QPS-Pareto-Kurven der verschiedenen Bibliotheken.
• HNSW-Anpassung: HNSW (Hierarchisch navigierbare Kleine Welt – ein schichtweises Nähegraph; siehe Malkov & Yashunin, 2018, in Implementierung hnswlib, FAISSs IndexHNSWFlat, und die meisten Vektor-Datenbanken) bieten drei Einstellmöglichkeiten an: M (Graphen-Ausstrahlung) efConstruction (Breite des Kandidaten zur Zeit der Kompilierung) efSearch (Breite des Kandidaten zur Abfristzeit). Beginnen Sie mit den in der Bibliothek dokumentierten Standardwerten und variieren Sie anschließend die Parameter, bis die Recall–Latency-Kurve den Anforderungen Ihres Evaluationssets entspricht.
• IVF-Tuning: IVF (umgekehrter Dateindex – Vektoren werden mithilfe von k-means aufgeteilt) nlist Zellen, und anschließend zur Abfragezeit scannen nprobe nächste Zellen; siehe FAISSs IndexIVFFlat und IndexIVFPQ). Durchsuchen nlist und nprobe im Gegensatz zur Recall-Rate bei der exakten Suche und Latency. Benchmark werden gefilterte Abfragen getrennt betrachtet, da Indexfamilien sowie Vector Databases die Filterabfrage unterschiedlich umsetzen.
• Aktualisierungsverzögerung: Zeit vom Commit des Dokuments bis zur Verfügbarkeit desselben. Es sollten Werte für p50 und p99 erfasst werden. Bei Systemen mit regulatorischen Anforderungen ist zudem der Prozentsatz der Abfragen zu erfassen, die mit veralteten Indizes abgewickelt werden.

Teil 4: Bewertung zur Abfrageszeit

Der Abfragedauer-Bereich enthält die Metriken, mit denen ein Pfad von Retrieval diagnostiziert werden kann. Allein der Recall@k liefert keine Informationen darüber, ob das Versagen durch Umformulierung, Filtern, Reranking oder Kontextzusammenstellung verursacht wurde.

Abfragedurchsicht und -umformulierung

• Qualität der Abfragedehnung: Recall@k-Verbesserung auf Ihrem Gold-Set, verglichen mit der ursprünglichen Abfrage nach der Dehnung. Definieren Sie vor dem Testen einen minimalen nützlichen Gewinn sowie dessen Unsicherheit im Voraus. Wenn die Dehnung diese lokale Schwellenbedingung nicht erfüllt, rechtfertigt sie weder ihren Latency noch die damit verbundenen Kosten. Klassische PRF-(Pseudo-Relevanz-Feedback)-Baseline-Methoden wie RM3 und Bo1 sie bleiben weiterhin nützliche Validierungsprüfungen; die auf LLM basierende Erweiterung muss diese übertreffen.
• HyDE-Bewertung: HyDE (Gao et al., 2022) erzeugt eine hypothetische Antwort mithilfe von LLM, fügt diese ein und führt anschließend eine Abfrage darauf durch. Dadurch entsteht zusätzlich eine Generierung Latency sowie eine neue Fehlerquelle. Es wird die Recall@10-Wertung getrennt für Domänenbezogene, außerdomänische sowie niedrigvertrauenswürdige Datensätze ermittelt, um anschließend zu entscheiden, ob der Fall dem Standardweg zugeordnet werden soll, als Fallback verwendet werden kann oder weder das eine noch das andere gilt.
• Erstellung mehrerer Abfragen: Union von Recall@k aus N Überarbeitungen im Vergleich zu einer einzigen Abfrage. Variiert man N, so kann man einen Punkt auf der Recall–Latency-Grenze auswählen. Implementierungen: LangChain’s MultiQueryRetriever, LlamaIndex’s QueryFusionRetriever.
• Genauigkeit der Intent-Klassifizierung: Standardwerte für Präzision/Wiedererkennung/F1 pro Intent (berechnen mit sklearn.metrics.classification_report), doch die entscheidende Metrik ist die Routenkorrektheit – wird das richtige nachgelagerte Pipeline aufgerufen?
• Anpassungsfähiges Routing: adaptives RAG (Jeong et al., NAACL 2024) argumentieren, dass nicht jede Abfrage einer identischen Retrieval-Strategie bedarf. Erfassen Sie die Router-Genauigkeit als Klassifizierungsproblem anhand eines gelabelten Satzes mit den Kategorien „kein Retrieval erforderlich“ / „einschrittig“ / „iterativ“.

Retrieval-Metriken

Dies sind die Basismetriken. Wenn Sie diese nicht überwachen, können Sie nicht feststellen, ob sich Retrieval verbessert.

Die Formeln zur Referenz (binäre Relevanz mit dem relevanten Mengensatz $R_q$ für die Abfrage $q$, wobei $\text{rel}_i = 1$ gilt, wenn das $i$-te abgerufene Dokument zu $R_q$ gehört):

Für die graduierte Relevanz gilt $\text{rel}_i \in \{0, 1, 2, \dots\}$; der binäre nDCG ist der spezielle Fall, der im untenstehenden Code verwendet wird. MAP ist der Mittelwert über alle Abfragen von $\text{AP}_q = \frac{1}{|R_q|}\sum_{i: \text{rel}_i = 1} \text{Precision@}i$. Siehe Manning, Raghavan, Schütze, Einführung in die Informationsbeschaffung, Kapitel 8: Herleitungen.

Für Produktionscode sollte man … verwenden. ranx, pytrec_eval, oder ir_measures — Sie implementieren die gesamte TREC-Metrikfamilie und bewältigen die Berechnung der graduierten Relevanz korrekt. Legen Sie die Freigabeziele anhand eines realistischen Referenzdatensatzes, der Qualität der Ergebnisse im Nachgang sowie des Kostenfaktors bei Fehlern fest. Übernehmen Sie keine Schwellenwerte aus Schulungsmaterialien.

Der Test für Harness ist in diesem Fall kurz. Er kann bereits aus einer Notebook-Umgebung ausgeführt werden, noch bevor ein Vector Database ausgewählt wurde.

from math import log2
from statistics import mean

# synthetic gold set: query_id -> set of relevant doc ids
gold = {
    "q1": {"d3"},
    "q2": {"d7", "d2"},
    "q3": {"d11"},
    "q4": {"d5"},
}

# ranked retrieval results: query_id -> ranked list of doc ids (top-10)
runs = {
    "q1": ["d8", "d3", "d1", "d4", "d2", "d9", "d6", "d10", "d12", "d13"],
    "q2": ["d2", "d6", "d4", "d7", "d1", "d3", "d8", "d11", "d5", "d9"],
    "q3": ["d11", "d2", "d3", "d4", "d1", "d6", "d7", "d8", "d10", "d12"],
    "q4": ["d1", "d2", "d3", "d6", "d8", "d9", "d10", "d12", "d13", "d14"],
}

def recall_at_k(ranked, gold_set, k):
    if not gold_set:
        return 0.0
    hit = sum(1 for d in ranked[:k] if d in gold_set)
    return hit / len(gold_set)

def reciprocal_rank(ranked, gold_set):
    # MRR contribution per query: 1/rank of the first relevant doc.
    for rank, d in enumerate(ranked, start=1):
        if d in gold_set:
            return 1.0 / rank
    return 0.0

def ndcg_at_k(ranked, gold_set, k):
    # binary relevance: rel ∈ {0, 1}
    gains = [1.0 if d in gold_set else 0.0 for d in ranked[:k]]
    dcg = sum(g / log2(i + 2) for i, g in enumerate(gains))
    # ideal DCG: all gold docs ranked first, capped by k
    n_gold_in_topk = min(k, len(gold_set))
    idcg = sum(1.0 / log2(i + 2) for i in range(n_gold_in_topk))
    return dcg / idcg if idcg else 0.0

K = 5
print(f"Recall@{K}: {mean(recall_at_k(runs[q], gold[q], K) for q in gold):.3f}")
print(f"MRR:       {mean(reciprocal_rank(runs[q], gold[q]) for q in gold):.3f}")
print(f"nDCG@{K}:  {mean(ndcg_at_k(runs[q], gold[q], K) for q in gold):.3f}")
# Recall@5: 0.750
# MRR:       0.625
# nDCG@5:    0.627

Das ist Ihre Retrieval CI-Gate. Verbinden Sie es mit einem auf Code-Coverage basierenden, schnellen Testumfang bei jedem Pull Request und führen Sie den vollständigen Testumfang auf der langsameren Release-Gate-Ausführung durch. Verhindern Sie eine Fusion, wenn eine im Voraus definierte Metrik ihren Regressionsbudget überschreitet.

Der begleitende Repository fixiert die genannten Werte exakt.Recall@5 = 0.750, MRR = 0.625, nDCG@5 = 0.627) als Unit-Test in tests/test_retrieval_metrics.py; Notizbuch 01 führt Recall@k / MRR / nDCG-Berechnungen anhand eines echten SciFact-Index durch, und die für die Produktion optimierte Harness-Implementierung befindet sich in evaluation/retrieval.py.

Hybride Fusion von Retrieval-Ranking und gegenseitigem Ranking

BM25 ist ein spärlicher lexikalischer Scorer, der die exakte Termeinstimmung, die Termwichtung sowie die Längennormalisierung kombiniert. Er ist verfügbar in rank_bm25Elasticsearch, OpenSearch sowie die meisten Suchmaschinen.

Reciproke Rangfusionsmethode (Cormack, Clarke und Buettcher, SIGIR 2009) kombiniert BM25 mit dichten Ranglisten nach Position. Die ursprüngliche k=60 Die Einstellung stellt eine nützliche Grundlage dar. RRF ist skorunabhängig, wodurch die für die lineare Interpolation erforderliche Normalisierung über verschiedene Kategorien vermieden wird. Bei einem ausreichend großen, gelabelten Datensatz, der es ermöglicht, einen stabilen Delta-Wert zu schätzen, sollte zudem eine konvexe Kombination getestet sowie der Parameter α abgestimmt werden.

Ein Hybrid aus Retrieval und einem Cross-Encoder-Reranker verbessert in der Regel technische, protokollbasierte sowie Code-Korpora. Bei stark semantisch strukturierten Korpora kann der Nutzen jedoch gering ausfallen. Es sollte mit den Ansätzen verglichen werden, die ausschließlich dichte oder ausschließlich spärliche Daten verwenden, da eine ungeeignete Fusionskonfiguration die Leistung beider Eingangsformate verschlechtern kann.

Die Implementierung passt in wenige Zeilen.

from collections import defaultdict

# two retrieval lanes: dense embeddings and BM25.
dense  = ["d3", "d7", "d1", "d4", "d2", "d9", "d10"]
sparse = ["d2", "d3", "d8", "d1", "d11", "d4", "d6"]

def rrf(rankings: list[list[str]], k: int = 60) -> list[tuple[str, float]]:
    """Reciprocal Rank Fusion (Cormack et al., SIGIR 2009).

    score(d) = sum over rankings of 1 / (k + rank(d))
    Score-agnostic: only rank position matters. k=60 is the canonical default.
    """
    scores: dict[str, float] = defaultdict(float)
    for ranking in rankings:
        for rank, doc in enumerate(ranking, start=1):
            scores[doc] += 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda kv: kv[1], reverse=True)

fused = rrf([dense, sparse], k=60)
for doc, score in fused[:5]:
    print(f"{doc}  score={score:.5f}")
# d3  score=0.03252   <- rank 1 dense, rank 2 sparse
# d2  score=0.03178   <- rank 5 dense, rank 1 sparse
# d1  score=0.03150

Beachten Sie, was RRF nicht tut: Es betrachtet niemals die rohen Similaritätswerte. Ein dichter Retriever, der einen Kosinuswert von 0,98 liefert, und ein BM25-Algorithmus mit einem Score von 17,4 sind nicht direkt vergleichbar. Wenn man diese Werte mit Z-Scores oder Min-Max-Skalierung normalisiert, kann es dazu kommen, dass der Algorithmus den Datensatz bevorzugt, bei dem die Varianz am höchsten ist.

RRF verwendet ausschließlich die Rangfolge. Wenn ein Retriever ein Dokument auf Position 2 platziert, ist dieser Wert gleichbedeutend mit einem Stimmenwert von 1 / (60 + 2)unabhängig von der Rohwertzahl, die ihn erzeugt hat.

Hybrid-Modell mit RRF in SciFact: Notizbuch 02 vergleicht Dense, BM25 und RRF anhand von pro Abfrage ermittelten Deltas. Der für die Produktion optimierte Fuser befindet sich in retrieval/hybrid_rrf.py; tests/test_rrf.py fixiert den kanonischen Zustand d3 / d2 / d1 Bestellung aufgeben bei k=60.

Reranking

• ΔnDCG / ΔMRR: die einzige zuverlässige Metrik für Reranking – der Nutzen im Vergleich zum Zustand ohne Reranking, basierend auf Ihrem Gold-Set und in der tatsächlichen Tiefe, die Ihre Anwendung verwendet. Berechnen Sie diese Werte, indem Sie Ihre Retrieval-Metriken mit und ohne den Reranker auf identischen Kandidatensätzen auswerten.
• Cross-Encoder gegen Bi-Encoder: Ein Bi-Encoder embeddet Abfragen und Dokumente unabhängig voneinander (einen Vektor pro Seite) und bewertet sie mithilfe des Skalarprodukts; ein Cross-Encoder concateniert Abfrage und Dokument und führt einen einzigen Vorwärtslauf durch, bei dem gemeinsam auf beide Inhalte reagiert wird. Cross-Encoders tauschen einen Vorwärtslauf pro Kandidat gegen eine umfassendere Interaktion zwischen Abfrage und Dokument ein. Referenzimplementierung: sentence-transformers CrossEncoder. Benchmark-Relevanz sowie Latency hinsichtlich des genannten Hardwares, der Batch-Größe und der Tiefe der Kandidaten; es darf kein Ergebnis eines Model oder einer verwalteten Dienstleistung in ein anderes Umfeld übertragen werden.
• Listweise versus punktweise: Bei der punktweisen Methode werden jede (Abfrage, Dokument)-Kombination unabhängig bewertet; bei der listweisen Methode wird die gesamte Liste der Kandidaten gemeinsam bewertet, damit der Model die Kandidaten miteinander vergleichen kann. Beide Ansätze sollten an denselben Kandidatensätzen getestet werden. Kalibrieren Sie alle Schwellenwerte entsprechend Model und dem Korpus, anstatt veröffentlichte Beispiele als universell anwendbar zu betrachten.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

query = "How do I rotate database credentials in production?"
candidates = [
    "Production database credentials are rotated via Vault every 30 days.",
    "The new logo was unveiled at the all-hands meeting.",
    "To rotate prod DB creds, run the `rotate-secrets` GitHub Action.",
]

scores = reranker.predict([(query, c) for c in candidates])
ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])
for doc, score in ranked:
    print(f"{score:+.3f}  {doc}")

Ein Reranker stellt ein hochpotentes Kandidat für eine grundlegende RAG Pipeline dar, ist jedoch keine garantierte Lösung. Messen Sie dessen ΔPrecision@1 sowie ΔnDCG an Ihrem Gold-Set und behalten Sie ihn nur dann bei, wenn der erzielte Gewinn sowohl die festgelegten Latency als auch den Kostenrahmen übertreffen. Vergleichen Sie diesen gemessenen Gewinn anschließend mit geringeren Änderungen durch Retrieval, bevor Sie zur nächsten Optimierung übergehen.

ΔnDCG und ΔPrecision@1 eines Cross-Encoders auf SciFact: Notizbuch 03; Modul: retrieval/reranker.py.

Kontextkonstruktion und Verlust im Mittelteil

Genau hier entstehen viele Fehler, bei denen es sich um „gute Retrieval, schlechte Antworten“ handelt.

• Kontextrelevanz: Relevanzwert pro Chunk RAGAs ContextRelevancy oder ein Cross-Encoder, der als Mittelwert sowie als Prozentsatz der unter einem Schwellenwert liegenden Blöcke aggregiert wird.
• Kontextnutzung: Von den im Kontext bereitgestellten Chunks – wie viele davon wurden tatsächlich zitiert oder im Antworttext verwendet? Berechnen als \frac|\text{zitierte Fragmente}|}{|\text{herausgeholte Blöcke}|$-$Wert für ein beschriftetes Beispiel. Legen Sie den Betriebsschwellenwert anhand der Antwortqualität sowie des Token-Kostens fest, anstatt von einem universellen Prozentsatz auszugehen.
• Erkennung von „Lost-in-the-Middle“-Fällen: synthetische Eval-Beispiele, bei denen der „Gold-Chunk“ an den Positionen {erst, mittel, letzt} eines langen Kontexts platziert wird, um die Richtigkeit der Antwort zu messen. Die U-förmige Verschlechterung tritt tatsächlich auf und ist in der Literatur dokumentiert. Liu et al. (TACL 2023). Moderne Models-Systeme leisten bessere Arbeit als die Modelle aus dem Jahr 2023 von Models, doch das Verzerrungseffekt bleibt bestehen. Gegenmaßnahmen: Zuerst die Rangfolge neu bestimmen und anschließend die Top-k-Einträge so anordnen, dass der am höchsten bewertete Teil zuerst oder zuletzt erscheint (wie bei LangChain). LongContextReorder führt genau dies aus) oder komprimiert die mittleren Abschnitte aggressiv. Messen Sie mit einer nach Position stratifizierten Eval, und nicht nur mit einem aggregierten Score. Ein funktionsfähiger, ausführbarer, nach Position stratifizierter Eval befindet sich in Notizbuch 06 (Modul: evaluation/lost_in_middle.py).
• Context Compression: geben Sie den Kompressionsgrad (Eingang Tokens / Ausgang Tokens) zusammen mit der Richtigkeit der Antwort an. Zu den verfügbaren Werkzeugen gehört LangChain. ContextualCompressionRetriever und LongLLMLingua. Definieren Sie zunächst den maximal zulässigen Verlust an Korrektheit auf der Grundlage des Risikos der Anwendung sowie des Budgets von Token, und lehnen Sie anschließend solche Konfigurationen ab, die diesen Wert überschreiten.

Teil 5: Die Fehl-Ausschlussrate des Filters

Dieser Metrikwert erhält eigene Abschnitt, da aggregierte Retrieval-Werte keinen Fehlversuch dem Filter zuordnen können.

Ein strenger Metadatenfilter wie tenant_id = X AND product = Y AND locale = en-US Er kann die effektive Recall-Wertung auf Null senken. Eine korrekt implementierte Recall@k-Methode erfasst diesen Verlust, da ihr Nenner weiterhin aus der ursprünglichen Menge der relevanten Dokumente besteht. Sie gibt jedoch nicht an, ob der Filter, der Retriever oder der Ranker für das Ausbleiben einer Treffermeldung verantwortlich ist. Die Treuebewertung kann dennoch gut aussehen, da sie die Antwort anhand des unvollständigen, zurückgeholten Kontextes bewertet; der Model hat dabei zuverlässig „Ich weiß es nicht“ gesagt.

Der rote Zweig im Diagramm stellt den häufigsten Fehler dar: Das richtige Dokument existiert tatsächlich, wird jedoch vom Filter bereits vor Retrieval entfernt.

Die Metrik

filter_false_exclusion_rate =
    (# queries where all gold docs were excluded by metadata filter) /
    (# queries with at least one gold doc)

Diese Definition auf Abfrageebene berücksichtigt katastrophale Ausschlüsse, bei denen kein relevanter Dokument übrig bleibt. Bei mehrfach-goldenen Abfragen führt Recall@k weiterhin zu einem teilweisen Verlust an Informationen; fügen Sie daher eine pro-Dokument-Ausschlussrate hinzu, falls dieser Wert von Bedeutung ist. Um eine dieser Raten zu berechnen, benötigen Sie (a) die echten Dokument-ID‑Werte für jede Eval-Abfrage sowie (b) eine Instrumentierung, die die angewandten Filterprädikate protokolliert – und nicht nur die endgültigen Ergebnisse. Legen Sie das Zielwert fest, indem Sie den Kosten eines Ausschlusses einer gültigen Antwort gegen den Konfidenzintervall Ihrer Produktionsstichprobe abwägen.

Hier ist eine funktionierende Implementierung. Sie vergleicht den korrekten Standard-Recall mit einem ungültigen Evaluator, der die Relevanz nach dem Filtern neu definiert.

# A small worked example where hard filters remove relevant documents.
docs = [
    {"id": "d1", "tenant": "acme",   "locale": "en-US"},
    {"id": "d2", "tenant": "acme",   "locale": "en-GB"},
    {"id": "d3", "tenant": "globex", "locale": "en-US"},
    {"id": "d4", "tenant": "acme",   "locale": "en-US"},
    {"id": "d5", "tenant": "acme",   "locale": "de-DE"},
]

queries = [
    # the gold doc lives in en-GB but the dynamic filter forced en-US
    {"qid": "q1", "gold": {"d2"}, "filter": lambda d: d["locale"] == "en-US"},
    # the gold doc is correctly within the tenant filter
    {"qid": "q2", "gold": {"d4"}, "filter": lambda d: d["tenant"] == "acme"},
    # the gold doc is in a different tenant and gets dropped
    {"qid": "q3", "gold": {"d3"}, "filter": lambda d: d["tenant"] == "acme"},
    # the gold doc passes the filter (de-DE locale match)
    {"qid": "q4", "gold": {"d5"}, "filter": lambda d: d["locale"] == "de-DE"},
]

def filter_false_exclusion_rate(queries, docs):
    n_with_gold, n_excluded = 0, 0
    for q in queries:
        if not q["gold"]:
            continue
        n_with_gold += 1
        survivors = {d["id"] for d in docs if q["filter"](d)}
        if not (q["gold"] & survivors):
            n_excluded += 1
    return n_excluded / n_with_gold if n_with_gold else 0.0

rate = filter_false_exclusion_rate(queries, docs)
print(f"filter_false_exclusion_rate = {rate:.2%}")
# filter_false_exclusion_rate = 50.00%

# Correct Recall@k keeps the original gold set as its denominator.
def standard_recall_at_k(queries, docs, k=10):
    recalls = []
    for q in queries:
        survivors = [d for d in docs if q["filter"](d)][:k]
        survivor_ids = {d["id"] for d in survivors}
        recalls.append(len(q["gold"] & survivor_ids) / len(q["gold"]))
    return sum(recalls) / len(recalls) if recalls else 0.0

print(f"standard recall@10 = {standard_recall_at_k(queries, docs):.2%}")
# standard recall@10 = 50.00%

# INVALID: rebuilding the gold set after filtering changes the question.
# It drops queries whose relevant documents did not survive, then scores 100%.
def invalid_recall_over_filtered_gold(queries, docs, k=10):
    recalls = []
    all_doc_ids = {d["id"] for d in docs}
    for q in queries:
        all_survivors = {d["id"] for d in docs if q["filter"](d)}
        filtered_gold = q["gold"] & all_doc_ids & all_survivors
        if not filtered_gold:
            continue
        top_k_ids = set(list(all_survivors)[:k])
        recalls.append(len(filtered_gold & top_k_ids) / len(filtered_gold))
    return sum(recalls) / len(recalls) if recalls else 0.0

invalid = invalid_recall_over_filtered_gold(queries, docs)
print(f"INVALID recall (filtered gold) = {invalid:.2%}")
# INVALID recall (filtered gold) = 100.00%

assert rate == 0.5
assert standard_recall_at_k(queries, docs) == 0.5
assert invalid == 1.0

Die Hälfte der Abfragen verliert aufgrund des Filters ihr Gold-Dokument, wodurch die korrekte Recall@10-Wertung auf 50 % sinkt. Dieser Wert zeigt zwar das Symptom auf, kann es jedoch nicht zuordnen. Der Fehlerausschlussgrad verdeutlicht, dass der Prädikat vor dem Ausführen des Retrievers bereits zwei Antworten entfernt hat. Die absichtlich ungültigen Evaluator-Einträge weisen lediglich 100 % aus, weil sie diese Fehlschläge aus ihrem Gold-Set ausschließen. Kein Model kann ein Dokument wiederherstellen, das bereits gefiltert wurde.

Der oben genannte Wert von 50 % wird als Unit‑Test im begleitenden Repository wiedergegeben: tests/test_filter_exclusion.py::test_50_percent_exclusion_rate. Notizbuch 04 erstellt damit eine Auswertung in SciFact unter Verwendung synthetischer Metadaten, sodass man beobachten kann, wie ein echter Filter die Recall-Werte auf Null reduziert; der Runtime-Metriker (zusammen mit den Begleitmetriken Präzision/Precision und Recall) wird dabei verwendet evaluation/filter_exclusion.py.

Begleitmetrik: Präzision und Recall des Prädikats

Wenn das Filtern dynamisch ist (zum Beispiel extrahiert ein LLM die Filterprädikate aus der Abfrage), sollte der Prädikatsextraktor als eine KlassifizierungsModel behandelt und entsprechend bewertet werden. Die Präzision sowie der Recall des Prädikats werden anschließend anhand einer gelabelten Datensammlung gemessen. (query, correct predicate) Paare. Ein Fehlerquotient für Prädikate entspricht nicht direkt dem gleichen Punktverlust bei der Retrieval-Rückrufrate; es muss ermittelt werden, wie oft solche Fehler ein Golddokument ausschließen. Sobald ein harter Filter das Golddokument bereits entfernt hat, hilft keine Menge an Reranking mehr.

Weicher Boost im Vergleich zum harten Filter

Dieser Metrikwert erzwingt eine Designentscheidung. Wenden Sie harte Filter an, wenn die Korrektheit binär ist – beispielsweise bei rechtlichen Zuständigkeitsbereichen, Grenzen von ACLs oder zwischen veröffentlichten und Entwurfsversionen. Verwenden Sie hingegen sanfte Aufwertungen, wenn die Relevanz in einem Gradmaß bewertet wird – wie bei Lokalvorlieben, Aktualität oder Versionen. Ohne Messung der Ausschlussrate fällt es schwer, die falsche Wahl zu erkennen.

Die Entscheidungsregel ist messbar:

For each filter predicate F:
  hard_recall_F  = retrieval_recall@k with F as a hard filter
  soft_recall_F  = retrieval_recall@k with F as a +0.X rerank boost
  hard_precision = relevant_in_top_k / k under hard filter
  soft_precision = relevant_in_top_k / k under soft boost
  exclusion_rate = % of queries where the gold doc was filtered out (hard)

Use hard filter only if exclusion_rate < ε AND hard_precision >> soft_precision.
Otherwise prefer soft boost.

Wählen Sie ε anhand des Schadens durch eine falsche Ausschlussentscheidung, des Nutzens einer erhöhten Präzision sowie der Größe der Bewertungsstichprobe aus. Ein spezieller Artikel in dieser Reihe geht dieser Abwägung genauer nach.

Teil 6: Bewertung der Generierung

Retrieval Metriken geben an, ob das System in der Lage wäre, korrekt zu antworten. Sie liefern jedoch keine Information darüber, ob es tatsächlich das auch getan hat. Generationsmetriken schließen diese Lücke.

Treue und Groundedness

RAGAS Treue er zerlegt die Antwort in atomare Aussagen (kurze, selbstständige faktische Erklärungen) und überprüft anschließend jede davon im Bezug auf den abgerufenen Kontext mithilfe von LLM Judge:

Der Prozentsatz der unterstützten Ansprüche stellt den Score dar. Diese Struktur ist nützlicher als eine einzelne Zahl, da sie angeben kann, welche Ansprüche nicht unterstützt werden. Der Produktionscode befindet sich in ragas package – die Verwendung sieht wie folgt aus:

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

samples = Dataset.from_dict({
    "question": ["How many moons does Mars have?"],
    "answer":   ["Mars has two moons, Phobos and Deimos."],
    "contexts": [["Mars has two moons named Phobos and Deimos."]],
    "ground_truth": ["Mars has two moons."],
})

result = evaluate(samples, metrics=[faithfulness, answer_relevancy, context_precision])
print(result)

Unten ist derselbe Loop in seiner vollständigen Ausprägung dargestellt, wobei ein deterministischer Ersatzwert Judge verwendet wird, damit Sie die Struktur von Anfang bis Ende erkennen können.

def extract_claims(answer: str) -> list[str]:
    # Production: an LLM call that decomposes the answer.
    # Demo: split on sentence-final punctuation.
    return [c.strip() for c in answer.replace("?", ".").replace("!", ".").split(".") if c.strip()]

def verify_claim(claim: str, context: str) -> bool:
    # Production: an NLI (natural-language inference) model or LLM judge.
    # Demo: a deterministic stand-in so the example runs offline.
    entailed_pairs = {
        "Mars has two moons": True,
        "Phobos and Deimos orbit Mars": True,
        "Mars has a thick atmosphere": False,  # unsupported by context
        "Curiosity landed in 2012": True,
    }
    for k, v in entailed_pairs.items():
        if k.lower() in claim.lower() or claim.lower() in k.lower():
            return v
    words = [w.lower() for w in claim.split() if len(w) > 3]
    return all(w in context.lower() for w in words) if words else False

context = (
    "Mars has two moons, Phobos and Deimos. NASA's Curiosity rover "
    "landed on Mars in 2012."
)
answer = (
    "Mars has two moons. Phobos and Deimos orbit Mars. "
    "Mars has a thick atmosphere. Curiosity landed in 2012."
)

claims = extract_claims(answer)
verdicts = [(c, verify_claim(c, context)) for c in claims]
faithfulness = sum(1 for _, ok in verdicts if ok) / len(verdicts)
for c, ok in verdicts:
    print(f"  [{'✓' if ok else '✗'}] {c}")
print(f"faithfulness = {faithfulness:.2f}")
# faithfulness = 0.75   (one unsupported claim about the atmosphere)

Die Struktur ist von entscheidender Bedeutung. In der Produktion, verify_claim es wird entweder zu einem NLI Model oder zu einem LLM Aufruf. Der Rest des Harness bleibt unverändert: Extrahieren, Überprüfen, Aggregieren.

End-to-End-Extraktion und -Verifizierung von Anfragen an generierten SciFact-Antworten: Notizbuch 05; Modul: evaluation/faithfulness.py. Der Repository-Code führt außerdem im selben Zyklus einen auf dem Prinzip von HHEM basierenden Verifier für verschiedene Familien aus, sodass man erkennen kann, welche Judge-Familie mit welcher übereinstimmt.

Eine speziell entwickelte Alternative zu LLM als Judge HHEM-2.1-Offen (Hughes Hallucination Evaluation Model, Vectara) – ein für die Hallucination-Erkennung feinabgestimmter Klassifikator. Seine Model-Karte dokumentiert die Checkpoint, also die Standardentscheidungsgrenze, sowie die Ergebnisse bei AggreFact und RAGTruth. Diese sollten als Beweismittel im Rahmen von Model-Karten betrachtet werden und nicht als Garantie für die Qualität Ihres Korpus angesehen werden: Kalibrieren Sie den Schwellenwert anhand lokaler Etiketten und vergleichen Sie ihn mit dem von Ihnen gewählten Judge vor dem Einsatz in Deployment.

Bewertung atomarer Fakten

Faktorwert (Min et al., EMNLP 2023) zerlegt langformatige Generierungen in atomare Fakten, holt für jeden Fakt Beweise ab und kennzeichnet jeden davon supported / not-supportedund gibt den unterstützten Bruch an:

Referenzimplementierung: shmsw25/FActScore. Es eignet sich hervorragend für Biografien, Zusammenfassungen sowie andere langformatige Ausgaben. Achten Sie jedoch darauf: wiederholte, triviale Fakten können die Bewertung erhöhen, und „MontageLie“-Angriffe (wahre Fakten in irreführender Reihenfolge) können das System überlisten. VeriScore bearbeitet Anfragen unter Verwendung der erforderlichen Modifikatoren; der Kern Filter helfen dabei, das Hinzufügen unnötiger Fakten zu verhindern.

Genauigkeit der Zitationen

Überwachen Sie die Präzision der Zitationen (die tatsächlich zitierten Spans stützen die jeweilige Behauptung) sowie die Rekallrate der Zitationen (die behauptet werden sollten und tatsächlich zitiert werden):

Die TREC 2024 RAG-Sparte definiert ein reproduzierbares Protokoll für die Unterstützungsbeurteilung. Upadhyay et al. (SIGIR 2025) Es wird berichtet, dass GPT-4o bei manueller, von Grund auf durchgeführter Bewertung zu 56 % mit dem menschlichen Judges übereinstimmt, dieser Wert steigt auf 72 %, wenn die Vorhersagen von LLM nachträglich bearbeitet werden. Unter den jeweiligen Bedingungen kann dies als Verstärkungsmittel nützlich sein, ersetzt jedoch nicht die menschliche Beurteilung in hochriskanten Situationen. Es handelt sich dabei um eine automatisierte Annäherungslösung. ALCE (Gao et al., EMNLP 2023) wenden Zitatenpräzision/Zitatenauflösung unter Verwendung einer auf NLI basierenden Überprüfung an.

Richtigkeit, Vollständigkeit und Ablehnung der Antwort

• Richtigkeit der Antwort gegenüber Ground Truth: Wenn dieser verfügbar ist, gilt eine exakte Übereinstimmung oder Token-F1 bei Aufgaben mit kurzen Antworten.evaluate.load("squad")), semantische Ähnlichkeit für offene Aufgabenstellungenbert-score, Embedding mittels Kosinus sentence-transformers, oder RAGAS AnswerCorrectness).
• Vollständigkeit durch Informationskörner: Ein „Informationskorn“ ist ein einzelner, atomarer Informationsgegenstand, der in jeder korrekten Antwort enthalten sein muss (z. B. bei der Frage „Wann wurde das Unternehmen gegründet?“ könnten die Informationskörner sein) {year: 1994, founder: Jane Doe}). TRECs AutoNuggetizer Es werden die wertvollsten Elemente einer korrekten Antwort aus einer Referenzquelle extrahiert, anschließend wird ermittelt, welcher Anteil des Inhalts vom System abgedeckt wird – dabei zeigte sich eine starke Korrelation zur manuellen Bewertung in 21 verschiedenen Themenbereichen bei insgesamt 45 Durchläufen im Rahmen von TREC 2024.
• Verweigerungsverhalten: Abfragen, für die es im Korpus keine Antwort gibt, sollten zu einer Verweigerung führen und nicht zu Hallucination. Es ist erforderlich, die Präzision der Verweigerungen (also die Fälle, in denen tatsächlich keine Antwort vorhanden war) sowie den Recall der Verweigerungen (d.h. die außerhalb des Aufgabengebiets liegenden Abfragen, die eine Verweigerung auslösten) zu tracken. NoMIRACL Ist der öffentliche Benchmark in Ihrem eigenen Domänenumfeld vorhanden? Markieren Sie dabei einen Teil der außerhalb des Anwendungsbereichs fallenden Abfragen und überwachen Sie die Genauigkeit der Auslassentscheidungen.

Nachgenerierungsverifizierung

Die günstigsten Verbesserungen der Zuverlässigkeit ergeben sich in der Regel aus deterministischen Nachprüfungen und nicht aus größeren Models.

• Überprüfung der Entität Grounding: Jede benannte Entität in der Antwort muss im abgerufenen Kontext vorkommen (oder daraus abgeleitet werden können). Eine einfache Regex-Prüfung in Kombination mit einer Prüfung auf exakte Übereinstimmung (oder spaCy’s ents gegenüber einem normalisierten Kontextstring werden überraschend viele Fälle von Hallucinations erfasst.
• Prüfung der Behauptungen: Die Behauptungen werden extrahiert, anschließend eine NLI-Prüfung gegen den Kontext durchgeführt; Fälle unter dem Schwellenwert scheitern oder werden markiert. NLI als Treueprüfung Models: cross-encoder/nli-deberta-v3-large, MoritzLaurer/DeBERTa-v3-large-mnli-fever-anli-ling-wanli. Fügt Latency hinzu. In hochkritischen Anwendungsbereichen lohnt sich das.
• Selbstkonsistenz (Wang et al., ICLR 2023): Erstellen Sie mehrere Generationen bei einer Temperatur von über 0 und berichten Sie den Übereinstimmungsgrad – beispielsweise als Anteil der Generationen, die die modale Antwort entsprechen, oder als Paarweiser BERTScore. Wählen Sie die Anzahl der zu prüfenden Beispiele anhand der Stabilitäts-Kosten-Kurve aus und kennzeichnen Sie Antworten mit geringer Übereinstimmung zur manuellen Überprüfung.
• Vertrauensgrad Calibration: Erfassen Sie den ausgesprochenen Vertrauensgrad („Wie zuversichtlich sind Sie, 0–1?“) und vergleichen Sie ihn mit der tatsächlichen Korrektheit auf dem Eval-Set. Zeichnen Sie eine Calibration-Kurve und geben Sie den erwarteten Calibration-Fehler an: \text{ECE} = \sum_{m=1}^{M} \frac{|B_m|{n} |\text{acc}(B_m) – \text{conf}(B_m)|, wobei $B_m$ die Konfidenzintervalle darstellen. Implementierungen: netcal, torchmetrics.CalibrationError. Ein Model, der eine Zuverlässigkeit von 0,9 angibt, sollte in etwa 90 % der vergleichbaren Fälle korrekt sein; messen Sie daher den Unterschied, anstatt von Calibration auszugehen.

Teil 7: Bewertung auf Basis von Ontologien für RAG

Die oben genannten Standardmetriken decken das offene Korpus RAG ab. Ontologiebasierte Systeme benötigen hingegen weitere Kennzahlen. Wenn Ihr RAG auf einer strukturierten Ontologie, Taxonomie oder Wissensgraphik abruft – beispielsweise Produkte in einem Katalog, Bedingungen in SNOMED, Komponenten in einer BOM oder Sicherheitstechniken in MITRE ATT&CK – sind Standard-Metriken wie RAG zwar notwendig, reichen jedoch nicht aus. Zudem muss auch die Ebene der Ontologie selbst gemessen werden.

Genauigkeit der Entitätsverknüpfung

Die erste Aufgabe besteht darin, eine in einer Abfrage erwähnte Entität auf eine Ontologie-Entität abzubilden („Aspirin“ → wikidata:Q18216”der 737” aircraft:Boeing_737).

• Präzision/Wiedererkennung-Rate/F1 auf Ebene der Mentions: Standard, gegenüber den Referenzmentionsdaten Spans (berechnen mit seqeval oder ein Span-Set-Vergleicher).
• Präzision der Enteindung: Von den korrekt erkannten Erwähnungen – welcher Anteil entspricht der richtigen Entity-ID? Zu den öffentlichen Referenzen gehören ReFinED, REL, und Genre; Benchmarks ähnlich wie AIDA-CoNLL und BELB Zeigen Sie, dass sich die Ergebnisse je nach System und Anwendungsbereich unterscheiden.
• NIL-Behandlung: Genauigkeit/Auflösung bei „Entität befindet sich nicht in der Ontologie“. Messen Sie das Überverknüpfen mit nahe liegenden, aber falschen Entitäten getrennt von einer korrekten Abstinenz.

Hierarchiebewusste Bewertung

Die einfache Genauigkeit behandelt den Fall „vorausgesagter Sedan, wenn die Wahrheit Hatchback ist“ genauso wie den Fall „vorausgesagter Sedan, wenn die Wahrheit Submarine ist“. Solche Fehler sind jedoch nicht gleichwertig.

• Hierarchische Präzision/Wiedererkennung/F1-Score (Kosmopoulos et al., 2015): Weisen Sie den Vorfahren und Nachkommen im Ontologie-DAG einen Kredit zu. Dabei steht $\hat{P}_q$ für den vorhergesagten Knoten zusammen mit allen seinen Vorfahren und $T_q$ für den tatsächlichen Knoten zusammen mit allen seinen Vorfahren:

  $$hP = \frac{\sum_q |\hat{P}_q \cap T_q|{\sum_q} |\hat{P}_q|}, \quad hR = \frac{\sum_q |\hat{P}_q \cap T_q|{\sum_q} |T_q|}, \quad hF1 = \frac{2 \cdot hP \cdot hR}{hP + hR}$$

  Implementieren mit networkx im Ontologie-Graphen; siehe hierarchical-classifier-metrics zur Referenz.

• Die Wu-Palmer-Similarity zwischen der vorhergesagten und der Referenzentität in der TaxonomieWu und Palmer, 1994):

  $$\text{WuP}(c_1, c_2) = \frac{2 \cdot \text{Tiefe}(\text{LCA}(c_1, c_2))}{\text{Tiefe}(c_1) + \text{Tiefe}(c_2)}$$

  dabei ist LCA der niedrigste gemeinsame Vorfahre in der Taxonomie. Er ist in NLTK für WordNet bereits aus der Box verfügbar.from nltk.corpus import wordnet as wn; wn.synset("car.n.01").wup_similarity(wn.synset("truck.n.01"))); für benutzerdefinierte Taxonomien wird das kürzeste gemeinsame Vorfahren mithilfe von networkx.

• Rate der Verwechslung zwischen Geschwistern und Eltern: Erfassen Sie getrennt die Fälle von Verwechslungen mit Geschwistern, Eltern sowie Kindern — count_sibling / total_errors, count_parent / total_errors, count_descendant / total_errors. Verwenden Sie die überprüften Beispiele, um zu prüfen, ob Geschwisterfehler auf mehrdeutige Erwähnungen zurückzuführen sind oder Elternteilfehler auf Übergeneralisierung.

Rate der Falsch-Ausschluss-Filterung (Wiederholung – nun kritisch)

In ontologiebasierten Systemen stammen harte Filter häufig direkt aus der Ontologie selbst („Rufen Sie nur Dokumente ab, die mit der Kategorie X markiert sind“). Die Ausschlussrate-Metrik (definiert in Teil 5) Es wird zu einem primären Signal für die Korrektheit. Eine falsche Kategorievervollständigung kann die Trefferquote auf Null reduzieren; der Ausschlussgrad ordnet diesen Verlust dem Filter zu.

Konformität bei restriktiver Generierung

Wenn die Ausgabe einer Ontologie entsprechen muss (jeder Entitätsname in der Antwort muss ein gültiges Mitglied der Ontologie sein; jedes Prädikat muss aus einem geschlossenen Wortschatz stammen), messen Sie:

• Schema-Gültigkeitsrate: Prozentsatz der Ausgaben, die gegen das Ontologie-Schema analysiert und validiert werden. Validieren mit jsonschema oder pydantic. JSONSchemaBench Ist die öffentliche Benchmark eine allgemeine Structured Output-Lösung? Für ontologiespezifische Schemata muss man einen eigenen Validierer entwickeln.
• Wortschatzkonformität: Prozentsatz der im Ausgabeinhalt enthaltenen benannten Entitäten, die gültige Ontologie-IDs sind – eine einzeilige Prüfung auf Zugehörigkeit zum geschlossenen Wortschatz.
• Semantische Konformität: Gültigkeit ist zwar erforderlich, reicht jedoch nicht aus. Ein syntaktisch korrekter Ausgabeinhalt kann trotzdem auf eine falsche, aber dennoch gültige Entität verweisen. Man muss die Konformität daher mit der Richtigkeit der anschließenden Antworten verknüpfen.

Constrained Decoding Frameworks (Übersichten, XGrammar, Leitfaden, OpenAI Structured Outputs) sind dafür konzipiert, die Gültigkeit des Schemas zu überwachen. JSONSchemaBench Es vergleicht Effizienz, Abdeckung und Qualität verschiedener Implementierungen. Führen Sie die entsprechenden Testfälle erneut aus, die mit Ihren Schemata sowie Serving Backend übereinstimmen, da sowohl die Abdeckung als auch Latency von diesen Faktoren abhängen.

Überprüfbarkeit

Für ontologiebasierte Systeme, bei denen die Antworten einer Überprüfung unterzogen werden:

• Zitierkomplettheit: Prozentsatz der faktischen Aussagen, die über mindestens eine nachprüfbare Quelle verfügen.
• Herkunftsgründlichkeit: Prozentsatz der Zitate, die bis zu einem Quelldokument mit einer stabilen Identifikationsnummer zurückverfolgt werden können – und nicht nur bis zu einem Hash-Wert eines Teilstücks.
• Wiederholbarkeitsrate: Beim erneuten Ausführen derselben Abfrage unter Verwendung von Snapshot erhält man stets dasselbe Ergebnis. Es müssen Model, Runtime, die Dekodierkonfiguration sowie der Seed festgelegt werden, wobei anschließend die erforderliche Wiederholungsrate aufgrund der Anforderungen an die Nachvollziehbarkeit gemäß Workflow bestimmt wird. Allein eine Temperatur von null garantiert keine Determiniertheit. Fehler können bei der Generierung, durch Serving Runtime oder in einem früheren Schritt entstehen.

Teil 8: Bewertung auf Systemebene

Gesamte Qualität der Antwort

• LLM-als-Judge (Zheng et al., NeurIPS 2023): eine skalierbare Bewertungsmethode, die auf Model beruht. G-Eval (ein LLM-Judge-Protokoll, das es Model ermöglicht, vor der Bewertung eigene Chain-of-Thought-Kriterien zu erzeugen) leitet Kriterien aus natursprachlichen Anforderungen ab und führt anschließend die Bewertung mit schwellenwertgewichteten Ausgaben durch. Die Übereinstimmung hängt von den Judge, der Aufgabe, dem Prompt sowie dem Calibration-Set ab.
• Paarweise Präferenz: Zeigen Sie Judge Antwort A im Vergleich zu Antwort B an und dokumentieren Sie die gewählte Präferenz. Dadurch werden Probleme mit absoluten Bewertungswerten bei Calibration vermieden. MT-Bench Es wurden Werte für GPT-4 Judge von über 80 % gemeldet, sowohl hinsichtlich menschlicher Präferenzen als auch bezüglich der Übereinstimmung zwischen Menschen, und zwar unter den Benchmark definierten Bedingungen; diese Rate darf ohne vorherige Calibration Genehmigung nicht auf einen anderen Anwendungsgebiet übertragen werden.

LLM als Judge weist tatsächliche Voreingenommenheiten auf:

• Position Bias: Judges führt dazu, dass unabhängig von der Qualität bevorzugt die erste oder zweite Antwort ausgewählt wird. Gegenmaßnahme: Die Reihenfolge zufällisieren oder beide Reihenfolgen ausführen und die Ergebnisse durchschnittlich bilden.
• Verbosity Bias: Judges kann zu einer Verwechslung zwischen Länge und Qualität führen. Ein 2026 kontrollierte Studie Es wurde ein heterogenes Verhalten der Erweiterungspaarungen festgestellt: Drei Judges wählten tendenziell längere Antworten, Claude bevorzugte kurze Antworten, während GPT-4o eine mehr oder weniger neutrale Haltung zeigte. Alle fünf Modelle erzielten gute Ergebnisse bei den Trunkierungsprüfungen. Das Ergebnis ist durch Benchmark begrenzt; teilen Sie daher Ihrem Judge mit, wie Vollständigkeit und Fülltexte zu bewerten sind, und dokumentieren Sie anschließend die leistungsbezogenen Werte unter Anwendung Ihrer eigenen Bewertungskriterien.
• Selbstpräferenzbias: GPT-4 bevorzugt eigene Ausgaben; dieser Bias steht in Zusammenhang mit der Ausgabe-Perplexität (Judges neigen dazu, Texte zu wählen, die ihnen vertraut sind). Gegenmaßnahme: Verwenden Sie eine andere Judge-Familie als das getestete System. Vermeiden Sie es außerdem, einen Model direkt auf Judge anzuwenden.

Praktischer Leitfaden: Wählen Sie einen Judge aus den von Menschen annotierten Calibration Data-Beispielen aus, randomisieren Sie die Reihenfolge der Antworten, maskieren Sie die Identitäten der Model-Instanzen und geben Sie in der Bewertungskriterienliste die Längenrichtlinie an. Wiederholen Sie Testfälle nur dann, wenn die hinzugefügten Beispiele die Unsicherheit erheblich verringern. Bei kritischen Evaluierungen sollten Judges-Werte aus verschiedenen Model-Familien miteinander verglichen werden, wobei Abweichungen im Vergleich zu den menschlichen Labels analysiert werden müssen.

Schema-gestütztes Reasoning für Judges

Freiform-Ausgaben stellen eine Quelle für Variationen bei den Ausführungen von Judge dar. Zwei Ausführungen gegenüber derselben Aufgabe können die Bewertungskriterien unterschiedlich anwenden und somit unterschiedliche Ergebniswerte erzeugen. Schema-gestütztes Reasoning (SGR) Stellen Sie diese Bewertungskriterien klar: Definieren Sie die Evaluierungsphasen als Pydantic-Schema und nutzen Sie anschließend eingeschränkte Ausgaben mithilfe von Outlines, XGrammar, vLLM Structured Outputs oder OpenAI. response_format Daher liefert jeder Ausführung die gleichen Felder in derselben Reihenfolge.

Für RAG Eval zerlegt das Schema das Urteil in explizite, überprüfbare Felder, anstatt es dem Model zu ermöglichen, direkt auf eine Zahl zuzugreifen:

from pydantic import BaseModel, Field
from typing import Literal

class FaithfulnessJudgment(BaseModel):
    extracted_claims: list[str] = Field(
        description="Atomic factual claims in the answer, one per item."
    )
    supported_claims: list[str] = Field(
        description="Subset of extracted_claims that are entailed by the context."
    )
    unsupported_claims: list[str] = Field(
        description="Subset that is NOT entailed by the context."
    )
    failure_mode: Literal[
        "none", "fabrication", "overgeneralization", "wrong_entity", "stale_fact"
    ]
    score: float = Field(ge=0.0, le=1.0)
    rationale: str

Durch die strukturierten Felder ist der Score wiederherstellbar. len(supported) / len(extracted) und zeigen genau an, über welche Behauptungen sich die beiden Judges nicht einig waren. Der Pydantic Model macht außerdem eine Änderung im Bewertungsschema als Code-Diff sichtbar. Durch die eingeschränkte Ausgabeform wird zwar die Struktur gewährleistet, doch kein unvoreingenommenes Urteil abgegeben; daher gelten weiterhin Positionsrandomisierung, cross-family Judges sowie menschliche Calibration Einflüsse.

Dies funktioniert für jedes auf Kriterien basierende Judge-System, nicht nur für solche, die auf Treueprinzipien beruhen. Sowohl die paarebene Präferenzbewertung, die Unterstützung bei Zitaten als auch die Richtigkeit von Ablehnungen profitieren alle vom gleichen Ansatz.

Ein G-Eval / paarweise / position-biases / cross-familienweiter Judge Harness existiert in Notizbuch 07; Modul: evaluation/llm_judge.py. Der Benchmark-Scanmake benchmark im Repository werden drei Agenten der Spitzenklasse Models vernetzt — gpt-5-mini, claude-haiku-4-5, gemini-2.5-flash — in einen rotierenden‑Judge paarweise A/B-Testung, sodass jeder Model Judges Die beiden anderen zeigen die numerischen Werte der Selbstpräferenz an.

Latency und Kosten

• p50, p95, p99 in jeder Pipeline-Phase. Die gewählten Prozentswerte für die SLO sowie die Alarmgrenzen hängen von der Nutzerinteraktion, dem Traffic-Volumen und dem Fehlerbudget ab.
• Zeit bis zum ersten Token im Vergleich zur Gesamtgenerierungszeit. Für eine reibungslose Streaming-UX sind die Werte bezüglich der TTFT für die Nutzer entscheidend.
• Aufschlüsselung nach Phasen: Retrieval, Reranking, Generierung, Nachverarbeitung. Verwenden Sie dazu den Trace, um die Ursache im „Tail“-Bereich zu ermitteln, anstatt einfach davon auszugehen, welche Phase dafür verantwortlich ist; notieren Sie außerdem das Gerät des Rerankers sowie die Batch-Größe bei der Vergleich von Ausführungen.
• Gesamtkosten pro Abfrage = Embedding + Retrieval + Kosten für Reranking + Generierung + amortisierte Speicherkosten. Überwachen Sie dabei die Werte p50 und p99 – schließlich fließen die meisten Ressourcen in den langen Schwanzbereich.
• Cache-Hit-Raten auf den Ebenen des Embedding-Caches, des Retrieval-Caches sowie des KV-Caches. Legen Sie hierfür getrennte Ziele fest, die sich von der beobachteten Wiederholungsrate, der Validierungsstrategie sowie den eingesparten Kosten pro Ebene unterscheiden.

Die pro Phase angegebenen Werte für P50/P95/P99 zusammen mit einer detaillierten Aufschlüsselung nach Phasen sind bereits integriert. Notizbuch 08 und der Runner bei evaluation/latency.py; Der Bericht Benchmark vereint Latency mit hoher Genauigkeit in einer einzigen Matrix, die Sie erneut ausführen können. make benchmark.

A/B-Testing

• Einheit der Randomisierung: Wählen Sie die geeignete Einheit aus den Optionen „Estimand“, „Carryover“ und „Interference“. Verwenden Sie eine Zuweisung pro Benutzer oder pro Session, wenn wiederholte Expositionen das Verhalten verändern oder zu einer inkonsistenten Benutzeroberfläche führen können. Eine Zuweisung pro Abfrage ist nur dann vertretbar, wenn solche Effekte vernachlässigbar sind und die Analyse Models auf wiederholten Beobachtungen beruht.
• Haupt-, Guardrails-, sowie explorative Metriken: Registrieren Sie diese im Voraus. Wählen Sie die primäre Messgröße aus dem Produktergebnis aus; zu den Indikatoren für Zufriedenheit gehören Daumenbewertungen, Wiederholungsrate sowie Dauer der Interaktion. Behandeln Sie Latency sowie Kosten als Guardrails, sofern sie die Nutzererfahrung einschränken.
• Stichprobengröße: Führen Sie vor dem Start eine Power-Analyse durch, wobei als Grundlagen die minimale nachweisbare Wirkung, die Basisspannung, die Zuweisungseinheit sowie die Stoppregel herangezogen werden.

Teil 9: Erstellung des Testsets

Eine Metrik ist nur so gut wie der Testdatensatz, auf dem sie ausgeführt wird. Wenn Ihr „Golden Set“ drei Intenten und der Produktivverkehr Spans zwölf umfasst, misst Recall@10 lediglich diese drei Intenten. Noch schlimmer ist es, wenn ein Testdatensatz zu leichten Fragen überanpasst wird („Wie lautet die Rückerstattungspolitik des Unternehmens?“), wodurch ein System genehmigt werden kann, das bei schwierigen Fällen versagt („Rückerstattungsfähigkeit bei teilweiser Stornierung gemäß dem EU-Digitaldienstegesetz von 2023, in EUR abgerechnet, aus Irland stammend?“). Der Gesamtwert steigt, obwohl das System weiterhin einen wichtigen Teil des Produktivverkehrs nicht bewältigen kann.

Dasselbe Problem tritt auch bei den Ground-Truth-Daten auf. Wenn KMU die offensichtlichen Dokumente annotieren, aber die weniger bekannten, relevanten Dokumente übersehen, führt dies dazu, dass Recall@k einen Suchalgorithmus, der diese tatsächlich gefunden hat, zu schlecht bewertet. Man optimiert somit in Richtung der Annotierungen und nicht in Richtung der wahren Realität.

Erstellen Sie zunächst den Testdatensatz unter Berücksichtigung der tatsächlichen Abfrageverteilung und Schwierigkeitsgrade. Wählen Sie anschließend Metriken aus, die auf die gewünschten Fehlermuster reagieren, und passen Sie das System entsprechend an.

Erzeugung synthetischer Abfragen

Verwenden Sie einen LLM, um aus Ihrem Korpus Fragen zu erzeugen:

• Pro-Chunk: „Erstellen Sie 3 Fragen, die ein Benutzer stellen könnte und die von diesem Chunk beantwortet werden.“
• Multi-Hop: Wählen Sie zwei Chunks aus und erstellen Sie eine Frage, für die beide benötigt werden.
• Adversarial: Erstellen Sie Fragen mit irreführenden Elementen, nahezu identischen Formulierungen sowie mehrdeutigen Verweisen.

RAGAS verfügt über eine integrierte Verteilung der Fragearten (Reasoning, bedingte, mehrkontextuelle). DataMorgana Es erzeugt konfigurierbare synthetische Benchmarks-Beispiele für verschiedene Kategorien von Benutzern und Fragen. Synthetische Daten sind nützlich bei der Initialisierung neuer Systeme sowie bei Tests zur Abdeckung aller möglichen Szenarien. Sie können jedoch keine echten Anfragen von Nutzern ersetzen.

Konstruktion nach dem Goldenen Dataset-Prinzip

Durch von Menschen überwachte Daten wird die Referenzmenge gesichert.

1. Beispiele für tatsächliche Benutzeranfragen (oder simulierte, falls vor dem Launch), stratifiziert nach Absicht.
2. Lassen Sie Fachexperten jede Frage beantworten und bestimmen, in welchem Dokument(en) sich die Antwort befindet.
3. Legen Sie die Größe des Datensatzes anhand der Abdeckungsmatrix sowie des für Entscheidungen zum Release erforderlichen Konfidenzintervalls fest; die Abdeckungsrate ist wichtiger als die Anzahl der eingesammelten Anfragen.
4. Führen Sie eine erneute Auswahl durch, wenn das Release-Rhythmus, Anzeichen für Abweichungen, Domänenrisiken oder die Annotationskapazitäten dies rechtfertigen.

Adversarische Testmengen

• Kontrafaktische Fälle: Austausch der Schlüsselentitäten in der Anfrage. Liefert das System die richtigen Fragmente für die umgewandelte Anfrage?
• Ablenkungselemente: Anfragen, bei denen das Korpus eine plausibel klingende, aber falsche Antwort enthält, die nicht abgerufen werden sollte. Genau das ist … RGB (Chen et al., AAAI 2024) führen Stresstests durch hinsichtlich der Rauschfestigkeit, der negativen Ablehnung, der Informationsintegration sowie der Kontrafaktischen Robustheit.
• Negation und Quantoren: Abfragen mit „not“, „except“ und „only“. Dichte Retrieval-Systeme haben oft Schwierigkeiten mit solchen Formulierungen.
• Außerhalb des Aufgabengebiets: Abfragen, für die es im Korpus keine Antwort gibt. Das System sollte in diesem Fall „Ich weiß es nicht“ angeben und keine Halluzinationen erzeugen. NoMIRACL lebt hier. Bewerten Sie das Verhalten bei Auslassungen ausdrücklich für Ihre Produktionsabfragen.

Abdeckung und kontinuierliche Bewertung

• Erstellen Sie eine Abdeckungsmatrix: Abfragedezidert × Dokumenttyp × Ontologiezweig. Streben Sie mindestens eine Abfrage pro Zelle an. Leere Zellen stellen unüberwachte Bereiche dar, in denen Regressionen verborgen bleiben können.
• Führen Sie für jeden Pull Request einen begrenzten, schnellen Regressionstest durch und das vollständige Testset zu einem langsameren Zeitpunkt.
• Planen Sie die Ausführung des vollständigen Golden-Set Eval entsprechend dem Release-Rhythmus sowie den damit verbundenen Evaluierungskosten ein; Release-Kandidaten bilden dabei eine natürliche Kontrollstufe.
• Legen Sie die Bewertung von Abweichungen basierend auf Traffic-Mengen, erwarteten Änderungen und Risiken fest. Verwenden Sie dabei eine dynamisch gewählte Produktionsstichprobe und strukturieren Sie diese nach Feedback, anstatt heimlich die Zielverteilung zu ändern.

Teil 10: Produktionsüberwachung

Das von Ihnen bereitgestellte Eval-Paket beschreibt das System zum Zeitpunkt des Releases. Der Produktivverkehr ändert sich danach.

Implizite und explizite Rückmeldung

• Klick-/Öffnungsrate der zitierten Quellen (sofern die Benutzeroberfläche diese anzeigen lässt).
• Verweildauer beim Antwortinhalt.
• Erneuerungsrate: Prozentsatz der Antworten, bei denen der Nutzer erneut nachfragt oder das System bittet, die Antwort neu zu erstellen. Diese Rate sollte als Indikator für Unzufriedenheit betrachtet und anhand von überprüften Gesprächen kalibriert werden.
• Kopieren/Teilen/Exportieren-Raten – ein sehr starkes positives Signal.
• Nachfragemuster: Phrasen wie „Sind Sie sicher?“ oder „Aber was ist mit X?“ deuten auf Misstrauen hin.
• Daumen hoch/runter mit optionalen Begründungskategorien (falsch, unvollständig, außerhalb des Themas, schädlich, langsam). Inlineschnitte, sofern die Benutzeroberfläche dies ermöglicht, stellen das informativste Feedback dar.

Abweichungserkennung

• Abweichung der Abfragen: Überwachen Sie die Verteilung der Abfragen Embedding im Vergleich zu einem Referenzzeitraum mithilfe von KL-Divergenz, MMD oder einem auf Model basierenden Detektor. Triggeren Sie bei einer Veränderung einen Alarm, um anschließend gezielt zu diagnostizieren.
• Abweichung der Embedding: Legen Sie eine feste Probeauswahl an Dokumenten fest und embedden Sie diese regelmäßig erneut, um den Kosinuswert zum ursprünglichen Embeddings zu messen. Selbst geringe Abweichungen zwischen verschiedenen Versionen der Model-Komponenten können unbemerkt zu Störungen bei Retrieval führen. Eine versionierte Embedding-Speicherlösung (mit unveränderlichen Inhalten pro Version nach dem Prinzip von Snapshots) stellt die kostengünstigste Gegenmaßnahme dar.
• Leistungsabweichung: Verfolgen Sie im Laufe der Zeit metrikenbasierte Kennzahlen, die dem Betriebsbetrieb entsprechen (z. B. Regenerationsrate nach Intention). Plötzliche Sprünge deuten auf einen Fehler hin, während langsame Abweichungen darauf hindeuten, dass sich die Umgebung verändert hat.

Schattenbewertung und Human-in-the-Loop

Führen Sie das Kandidatssystem parallel zur Produktivumgebung aus, vergleichen Sie die Ergebnisse offline miteinander und stellen Sie diese nicht den Nutzern zur Verfügung. Auf diese Weise werden Regressionen bereits vor dem Release erkannt. Dies verursacht zusätzliche Kosten für Inference, hat aber keinen Einfluss auf die Kunden.

Zur Überprüfung von Human-in-the-Loop (HITL):

• Führen von Ausgaben mit geringer Zuverlässigkeit in eine Überprüfungs-Warteschlange ein.
• Einbeziehen eines zufälligen Samples aus dem Produktivverkehr für eine blinde Überprüfung; die Häufigkeit hierfür wird anhand des Verkehrsvolumens, des Risikos sowie der Kapazität der Prüfer festgelegt.
• Weight Ausgaben mit negativer Bewertung in großem Umfang berücksichtigen.
• Nutzen die überprüften Ausgaben, um den „goldenen Satz“ zu erweitern.

Die minimale Guardrail-Menge

Warnung bei diesen Elementen, in Prioritätsreihenfolge:

1. Der Faithfulness/HHEM-Score liegt bei einer rollierenden Produktionsstichprobe unter dem definierten Schwellenwert.
2. Der p95 Latency überschreitet den festgelegten SLO-Wert.
3. Die Rate falscher Ausschlüsse durch Filter liegt über dem definierten Schwellenwert (basierend auf Stichproben).
4. Die Regenerationsrate befindet sich außerhalb eines lokal kalibrierten Kontrollbereichs, der Größen des Zeitfensters, Verkehrsmengen, saisonalen Schwankungen sowie dem Budget für falsche Alarme berücksichtigt.
5. Die Kosten pro Abfrage liegen über dem zugewiesenen Budget.

Falls ein Alarm ausgelöst wird, ohne dass es einen entsprechenden Code oder eine Änderung von Model gibt, liegt vermutlich ein Drift vor. Tritt der Alarm hingegen nach einer Änderung auf, deutet dies wahrscheinlich auf eine Regression hin. In jedem Fall erhalten Sie frühzeitig ein Signal, noch bevor Support-Anfragen eintreffen.

Einschränkungen

• Die Zielwerte sind lokal begrenzt und nicht universell gültig. Jede Zahl, die in diesem Leitfaden als Beispieldatum angegeben ist, stellt eine Beispielkonfiguration oder ein erzieltes Ergebnis dar – keinesfalls einen festgelegten Freigabenschwellenwert. Passen Sie die Schwellenwerte an Ihr spezifisches Anwendungsfeld, die damit verbundenen Risiken, die Unsicherheit des Bewertungssatzes sowie die Erwartungen der Nutzer an.
• Der Framework-Bereich entwickelt sich rasant weiter. Versionen von HHEM, Namen von Metriken wie RAGAS, Model-Karten sowie die Reihenfolge in den Leaderboards können nach der Veröffentlichung ändern. Überprüfen Sie daher stets die verlinkten Quellen und führen Sie vor dem Veröffentlichen erneut eine Benchmark-Prüfung durch.
• Zahlen zu der LLM-als-Judge-Übereinstimmung sind meist mit Sternchen versehen. Der Wert von 80 % für GPT-4 gegenüber Menschen bezieht sich auf die Bedingungen von MT-Bench / Chatbot Arena. In Nischenbereichen oder bei adversativen Szenarien sinkt diese Übereinstimmung deutlich. Nutzen Sie Judges eher als Verstärkungsmittel und nicht als Ersatz für eigene Stichprobenprüfungen.
• Die von Anbietern angegebenen Benchmark-Verbesserungen lassen sich oft nicht unabhängig nachvollziehen. Führen Sie die Tests zunächst mit Ihren eigenen Daten durch, bevor Sie einem angegebenen Wert Glauben schenken – insbesondere bei neueren Reranker-Systemen und OCR-Lösungen.
• Keine Metrik kann die direkte Prüfung der Ausgaben ersetzen. Planen Sie regelmäßige, blinde Überprüfungen zufälliger Produktionsbeispiele unter Berücksichtigung von Traffic, Risiko und Kapazitäten der Prüfer. Die Metriken unterstützen zwar dieses Vorgehen, ersetzen es jedoch nicht.

Was in dieser Serie folgt

Dies war der Index. Die weiteren Dokumente sind Planning:

• Soft Boosts gegenüber Hard Filters: Ein detaillierter Vergleich der Fehl ausschluss rate von Filtern, inklusive Codebeispiele, echter Produktionsbeispiele sowie einer Entscheidungsgrundlage Framework.
• Ist Chunking die versteckte Variable?: Ein kontrolliertes Experiment mit rekursiven, semantischen, späten und strukturellen Chunking-Methoden an drei Korpora.
• Auswahl von Reranker-Modellen im Jahr 2026: BGE gegenüber Cohere, ZeRank sowie den aktuellen cross-encoder-Modellen Models – direkte Vergleiche hinsichtlich Kosten, Latency und Verbesserungseffekten.
• Ontologie-basierte RAG-Methoden: Eine Schritt-für-Schritt-Anleitung: Aufbau der vollständigen Bewertungsmethode Harness für ein auf Entitäten basierendes Retrieval-System.
• LLM als Judge ohne die Falle der Selbstpräferenz: Praktische Ansätze für eine unvoreingenommene automatisierte Bewertung.
• Online-Bewertung in der Produktion: Instrumentierungsmuster, Alarmrichtlinien sowie Dashboards, die tatsächliche Regressionen frühzeitig erkennen.

Referenzen

Frameworks und Benchmarks

• Es et al., Ragas: Automatisierte Bewertung von Retrieval-gestützter Generierung, 2023.
• Dokumentation zu RAGAS und GitHub.
• Saad-Falcon et al., ARES: Eine automatisierte Bewertung Framework für Retrieval-ergänzte Generierungssysteme, NAACL 2024.
• TruLens, DeepEval, Arize Phoenix.
• Thakur et al., BEIR: Ein heterogener Benchmark zur Null-Shot-Bewertung von Informationen Retrieval Models, NeurIPS 2021.
• MTEB-Rangliste.
• TREC 2024 RAG Spur.
• Pradeep et al., Erste Bewertungsergebnisse der Nugget-Erkennung für den TREC 2024 RAG-Track mithilfe des AutoNuggetizers Framework, 2024.

Retrieval und Ranking

• Cormack, Clarke, Buettcher, Die rekursive Rangfusionsmethode übertrifft die Condorcet-Methode sowie Ansätze zum individuellen Ranglernen., SIGIR 2009.
• Gao et al., Präziser Zero-Shot-Dichte-Algorithmus Retrieval ohne Relevanzetiketten (HyDE), 2022.
• Jeong et al., Adaptive-RAG: Lernen, sich an die Komplexität von Fragen anzupassen – bei Retrieval-erweiterten großen Sprachmodellen Models, NAACL 2024.
• Anthropic, Einführung in kontextsensitive Retrieval-Systeme, September 2024.
• Günther et al., Späte Chunking: Kontextuelles Chunk Embeddings unter Verwendung von Langkontext-Embedding Models-Technologien, 2024.
• Sarthi et al., RAPTOR: Rekursives abstraktionsbasiertes Verarbeitungsverfahren für tree-basierte Retrieval, 2024.

Generierung, Treue, Judges

• Min et al., FActScore: Feinabgestimmte atomare Bewertung der Faktengenauigkeit bei der Erstellung langformatiger Texte, EMNLP 2023.
• Liu et al., Verloren in der Mitte: Wie Sprache Models lange Kontexte nutzt, TACL 2023. – Chen et al., Benchmarking großer Sprachmodelle Models in Retrieval-ergänzter Generierung (RGB), AAAI 2024.
• Vectara, HHEM-2.1-Offene Hallucination-Bewertung Model.
• Zheng et al., Die Bewertung von LLM als Judge mithilfe von MT-Bench und Chatbot Arena, NeurIPS 2023.
• Upadhyay et al., Bewertung der Unterstützung für den TREC 2024 RAG-Track: Vergleich zwischen menschlichem Verhalten und LLM Judges, SIGIR 2025.
• Thakur et al., NoMIRACL: Wie man erkennt, wann man etwas nicht weiß – für zuverlässige mehrsprachige Retrieval-ergänzte Generierung, 2023.
• Geng et al., JSONSchemaBench: Eine präzise Benchmark für Structured Outputs im Bereich Sprach Models, 2025.
• Kosmopoulos et al., Bewertungskriterien für hierarchische Klassifizierung: Ein integrierter Überblick und innovative Ansätze, 2015.

Drift und Produktionseinsatz

• Offensichtlich, Embedding Methoden zur Erkennung von Drift im Vergleich.

Begleitcode

• slavadubrov/rag-evals-demo — ein ausführbarer Harness für jede Metrik in diesem Artikel zum SciFact-Korpus, sowie eine Chunking × Embedding × LLM Benchmark-Sweep-Methode. Dazu gehören die Notebooks 00–09, Unit-Tests, die die oben dargestellten Beispiele verifizieren, sowie ein eingebetteter Qdrant-Index, sodass die Anwendung ohne Docker ausgeführt werden kann.