Model Evaluation Metrics (z.B. Accuracy, F1, Faithfulness)
Model Evaluation Metrics sind Kennzahlen, mit denen die Qualität von KI-Modellen und insbesondere von RAG (Retrieval-Augmented Generation)-Systemen messbar gemacht wird – z. B. wie oft ein Modell korrekt liegt (Accuracy), wie gut es seltene Klassen erkennt (F1) oder wie gut Antworten durch Quellen gestützt sind (Faithfulness). Sie helfen, Modelle objektiv zu vergleichen, Regressionen zu erkennen und Verbesserungen gezielt umzusetzen.
Wie funktioniert die Bewertung mit Model Evaluation Metrics?
In der Praxis definierst du zuerst eine Aufgabe (z. B. Klassifikation, Extraktion, Q&A, RAG-Chat), erstellst ein Testset (idealerweise ein Golden Dataset (Goldstandard-Datensatz)) und misst dann die Leistung anhand passender Metriken. Wichtig: Eine einzelne Metrik reicht selten aus. Für produktive Systeme kombiniert man meist Qualitäts-, Sicherheits- und Betriebsmetriken (Kosten/Latenz).
- Schritt 1: Ziel definieren (z. B. „korrekte Antworten mit Quellen“).
- Schritt 2: Testdaten & Ground Truth festlegen (siehe Ground Truth (Referenzwahrheit)).
- Schritt 3: Metriken auswählen (Task- und Risikoprofil).
- Schritt 4: Messen, vergleichen, Schwellenwerte (SLOs) ableiten.
- Schritt 5: Monitoring/Regressionstests etablieren (z. B. Model Monitoring & Observability (LLMOps), Regression Testing für Prompts/Agents).
Typische Metriken (mit Beispielen)
Accuracy misst den Anteil korrekter Vorhersagen. Beispiel: Ein Intent-Klassifikator liegt in 92 von 100 Fällen richtig → 92% Accuracy. Achtung: Bei unausgewogenen Klassen (z. B. 95% „kein Problem“) kann Accuracy täuschen.
Precision, Recall und F1 sind wichtig bei seltenen Ereignissen (z. B. „kritische Supportfälle“). Precision sagt, wie „sauber“ positive Treffer sind; Recall, wie viele echte Positive gefunden werden. F1 ist der harmonische Mittelwert und balanciert beide. Beispiel: Ein PII-Detektor (siehe PII Detection (PII-Erkennung)) soll lieber hohe Recall haben, damit möglichst wenig Sensibles durchrutscht.
Faithfulness (Treue zur Quelle) ist zentral für RAG (Retrieval-Augmented Generation). Sie bewertet, ob eine Antwort aus den bereitgestellten Kontextdokumenten ableitbar ist – und nicht frei „halluziniert“ (siehe Halluzinationen (Hallucinations)). Beispiel: Das Modell nennt eine Vertragsklausel, die im Kontext nicht vorkommt → geringe Faithfulness.
Answer Correctness / Groundedness geht einen Schritt weiter: Ist die Antwort nicht nur „belegt“, sondern auch faktisch korrekt und passend zur Frage? In RAG unterscheidet man oft: Retrieval-Qualität (wurden die richtigen Chunks gefunden?) vs. Generation-Qualität (wurde richtig zusammengefasst?).
Retrieval-Metriken wie Recall@k oder MRR bewerten die Suche in Vektordatenbank (Vector Database)/Vector Search (Vektorsuche) / Semantic Search. Beispiel: Bei k=5 ist in 80% der Fälle mindestens ein relevanter Chunk unter den Top-5 → Recall@5 = 0,8. Re-Ranking (siehe Re-Ranking (Neu-Rangordnung)) kann diese Werte verbessern.
LLM-as-a-Judge ist eine moderne Methode, bei der ein Large Language Model (LLM) Antworten nach Rubriken bewertet (Korrektheit, Vollständigkeit, Stil). Das ist schnell skalierbar, muss aber mit Stichproben durch Menschen kalibriert werden (siehe Human-in-the-Loop (HITL)).
Warum sind Model Evaluation Metrics wichtig?
- Vergleichbarkeit: Modelle, Prompts oder RAG-Pipelines lassen sich objektiv gegeneinander testen.
- Qualitätssicherung: Du erkennst Regressionen nach Änderungen an Prompt, Chunking oder Embeddings (siehe Embeddings und Chunking (Text-Chunking)).
- Risikomanagement: Sicherheits- und Compliance-Ziele können messbar gemacht werden (z. B. PII-Leakage, Policy-Verstöße).
- Business-Optimierung: Du balancierst Qualität gegen Latenz/Kosten (siehe Latency (Latenz) & Throughput und Cost Optimization (Token-Kostenoptimierung)).
Was kostet Model Evaluation?
Die Kosten hängen von Datenaufbereitung, Tooling und Umfang ab. Ein kleines Eval-Setup (manuelles Testset, einfache Metriken) ist oft mit wenigen Personentagen möglich. Umfangreiche RAG-Evals mit großen Testsets, automatisierten Runs, LLM-Judge und Monitoring verursachen zusätzliche API- und Engineering-Kosten – lohnen sich aber, sobald das System produktiv genutzt wird oder Fehler teuer werden (z. B. im Support oder in regulierten Bereichen).