LLM-Evaluierung: Metriken, Frameworks und was 2026 wirklich funktioniert

LLM-Evaluierung ist der Unterschied zwischen „scheint in Ordnung zu sein" und „ich kann beweisen, dass es funktioniert." Wenn du LLM-gestützte Features für Nutzer auslieferst, ohne systematische Evaluierung, deployest du im Wesentlichen ungetesteten Code – nur dass die Fehlermuster Halluzinationen, Toxizität und stillschweigend falsche Antworten sind, statt Stack Traces.

Dieser Leitfaden deckt alles ab: Metriken, Methoden, Frameworks, Pipeline-Design und EU-KI-Gesetz-Compliance. Kein Vendor-Bias, kein Füllmaterial.

Auf einen Blick

Bevor wir ins Detail gehen, hier das Gesamtbild in einer Tabelle.

Jetzt schlüsseln wir jeden Punkt auf.

Was ist LLM-Evaluierung (und warum ist sie 2026 wichtig)?

LLM-Evaluierung ist der systematische Prozess der Messung und Bewertung der Qualität von Ausgaben großer Sprachmodelle anhand definierter Kriterien – Genauigkeit, Relevanz, Sicherheit und Treue zu den Quelldaten. Sie umfasst automatisierte Metriken, LLM-as-a-Judge-Bewertung und menschliche Überprüfung, um sicherzustellen, dass LLM-gestützte Anwendungen zuverlässige Ergebnisse in der Produktion liefern.

Warum ist das gerade jetzt wichtig? Zwei Gründe. Erstens haben sich LLMs von Prototypen zu Produktions-Features entwickelt, auf die echte Nutzer angewiesen sind. Ein Chatbot, der eine Unternehmensrichtlinie halluziniert, oder ein RAG-System, das nicht existierende Dokumente zitiert, ist kein lustiger Demo-Bug mehr – es ist ein Support-Ticket, ein rechtliches Risiko oder ein verlorener Kunde.

Zweitens beginnt die Durchsetzung des EU-KI-Gesetzes im August 2026. Wenn dein KI-System EU-Nutzer bedient, brauchst du dokumentierte Evaluierungspraktiken – nicht nur eine Slack-Nachricht, die sagt „Ich habe ein paar Prompts getestet und es sah gut aus."

Die meisten Teams machen noch das, was man als „Bauchgefühl-Evaluierung" bezeichnen könnte – ein paar Ausgaben in einem Playground stichprobenartig prüfen und entscheiden, dass es gut genug aussieht. Das hat funktioniert, als LLMs Experimente waren. Es funktioniert nicht, wenn sie Features sind.

Evaluierung beantwortet drei Fragen: Ist die Ausgabe korrekt? Ist sie sicher? Ist sie nützlich? Der Rest dieses Leitfadens zeigt dir, wie du alle drei systematisch beantwortest.

Ein wichtiger Unterschied: Dieser Leitfaden behandelt Anwendungsevaluierung – das Testen, wie dein LLM-gestütztes Produkt bei echten Aufgaben abschneidet. Das unterscheidet sich von der Modellevaluierung (Pre-Training-Benchmarks wie MMLU), die dir sagt, wie ein Basismodell allgemein abschneidet, aber fast nichts darüber, wie es sich in deiner spezifischen Anwendung verhält.

Fazit: Wenn du LLM-Features ohne systematische Evaluierung auslieferst, fliegst du blind. Die Frage ist nicht, ob man evaluieren soll – sondern wie.

LLM-Evaluierungsmetriken – Was man wann misst

Die Metriken, die du verfolgst, hängen vollständig davon ab, was du baust. Ein Chatbot braucht eine andere Evaluierung als ein Code-Generator. Hier ist eine praktische Taxonomie, die nach Anwendungsfall organisiert ist, nicht alphabetisch.

Textsimilaritätsmetriken (wenn du Referenzantworten hast)

Diese klassischen Metriken vergleichen generierten Text mit einer bekannten korrekten Referenz:

• BLEU misst N-Gramm-Präzision – wie viele Wortsequenzen in der Ausgabe mit der Referenz übereinstimmen. Ursprünglich für maschinelle Übersetzung entwickelt.
• ROUGE misst den Recall – wie viel des Referenzinhalts in der Ausgabe erscheint. Häufig für Zusammenfassungsaufgaben verwendet.
• BERTScore verwendet kontextuelle Embeddings, um semantische Ähnlichkeit zu messen, und erfasst Paraphrasen, die BLEU und ROUGE übersehen.

Der Haken? Diese funktionieren nur, wenn du Ground-Truth-Antworten zum Vergleichen hast. Überspringe BLEU für offene Generierung – es bestraft kreative Umformulierungen, was genau das ist, was du von einem guten Chatbot willst.

Semantische Evaluierungsmetriken (wenn du Bedeutung statt exakter Übereinstimmung brauchst)

Für offene Generierung brauchst du Metriken, die Bedeutung bewerten:

• Answer Relevancy bewertet, ob die Antwort tatsächlich auf die Frage des Nutzers eingeht.
• Kohärenz misst, wie logisch die Ausgabe fließt.
• Prägnanz kennzeichnet unnötig ausschweifende Antworten.
• G-Eval ist die flexible Option: Du definierst benutzerdefinierte Evaluierungskriterien in natürlicher Sprache, und ein LLM-Richter bewertet Ausgaben mithilfe von Chain-of-Thought-Reasoning. Hier verbringen die meisten Teams 2026 ihre Zeit.

RAG-spezifische Metriken

Wenn du Retrieval-Augmented Generation aufbaust, evaluierst du zwei Komponenten – den Retriever und den Generator. Das Ragas-Framework definiert vier Kernmetriken:

• Faithfulness – Ist die Antwort im abgerufenen Kontext verankert? Dies erkennt Halluzinationen.
• Context Relevancy – Hat der Retriever die richtigen Dokumente abgerufen?
• Context Recall – Hat der Retriever ALLE relevanten Dokumente gefunden?
• Answer Relevancy – Geht die Antwort tatsächlich auf die Anfrage ein?

Sicherheits- und Compliance-Metriken

Diese Metriken schützen deine Nutzer und dein Unternehmen:

• Halluzinationsrate – sachliche Korrektheit anhand bekannter Quellen
• Toxizitätserkennung – schädliche, anstößige oder unangemessene Inhalte
• Bias-Messung – ungleiche Behandlung verschiedener demografischer Gruppen
• PII-Leckage-Erkennung – personenbezogene Daten, die in Ausgaben erscheinen

Welche Metriken für welche Anwendung?

Das ist die Tabelle, die kein Vendor-Leitfaden dir gibt. Statt alle Metriken alphabetisch aufzulisten, ordne deinen Anwendungstyp den Metriken zu, die wirklich wichtig sind:

Fazit: Messe nicht alles. Wähle 3-5 Metriken, die zu DEINEM Anwendungstyp passen, und konzentriere dich darauf.

Wie führt man Evals tatsächlich durch? (Die drei Methoden)

Es gibt drei Möglichkeiten, LLM-Ausgaben zu evaluieren. Die meisten Produktionsteams verwenden alle drei, aber in sehr unterschiedlichen Anteilen.

Automatisierte Metriken (schnell, günstig, begrenzt)

Skriptbasiertes Scoring mit Metriken wie BLEU, ROUGE, exakter Übereinstimmung oder Regex-Mustern. Du schreibst einen Test, er läuft in Millisekunden, und du bekommst ein Bestanden/Nicht-bestanden.

Der Vorteil: Es ist schnell, reproduzierbar und im Wesentlichen kostenlos. Der Nachteil: Diese Metriken können Nuancen, Kreativität oder reale Nützlichkeit nicht beurteilen. Eine Antwort kann bei ROUGE perfekt abschneiden und für den Nutzer trotzdem nutzlos sein.

Verwende automatisierte Metriken für Regressionstests, CI/CD-Gates und hochvolumiges Screening, wo du Geschwindigkeit über Tiefe brauchst.

LLM-as-a-Judge (der Standard von 2026)

Hier hat die Branche gelandet. Du verwendest ein separates LLM – typischerweise GPT-4o oder Claude – um Ausgaben gegen deine Kriterien zu bewerten. Das G-Eval-Muster funktioniert so: Definiere deine Evaluierungskriterien in natürlicher Sprache, gib dem Richter-LLM die Kriterien plus den Testfall, und es produziert Chain-of-Thought-Reasoning plus eine Bewertung.

Forschungen von Zheng et al. zeigen ungefähr 81% Korrelation mit menschlichen Bewertungen, was gut genug für die tägliche Evaluierung ist, wenn du die Fehlermuster verstehst (mehr dazu im nächsten Abschnitt).

Verwende LLM-as-a-Judge für offene Generierung, subjektive Qualitätsbewertung und benutzerdefinierte Kriterien, die nicht durch einfache Metriken erfasst werden können.

Menschliche Evaluierung (Goldstandard, skaliert nicht)

Experten-Reviewer bewerten Ausgaben mithilfe von Rubriken, Likert-Skalen oder blinden A/B-Tests. Nichts schlägt einen Menschen, der eine Antwort liest und sagt „das ist tatsächlich hilfreich" oder „das würde den Nutzer verwirren."

Das Problem: Es kostet 5–50 € pro Evaluierung, dauert Minuten statt Millisekunden, und du kannst es nicht bei jeder Anfrage ausführen. Verwende menschliche Evaluierung für die Kalibrierung deines LLM-as-Judge, Compliance-Audits und die Validierung von Edge Cases.

Deine Methode wählen

Fazit: Verwende LLM-as-a-Judge für 80% deiner Evals, automatisierte Metriken für CI/CD-Gates und menschliche Überprüfung für Kalibrierung und Compliance. Das ist das Playbook von 2026.

LLM-as-a-Judge: Wie es funktioniert, wann es versagt

LLM-as-a-Judge ist aus gutem Grund zur Standard-Evaluierungsmethode geworden – es ist flexibel, relativ günstig und korreliert gut mit menschlichem Urteil. Aber es hat echte blinde Flecken, die Vendor-Leitfäden bequem überspringen.

Wie G-Eval funktioniert

Das Muster ist unkompliziert. Du definierst, wie „gut" in natürlicher Sprache aussieht, das Richter-LLM liest deine Kriterien zusammen mit der zu evaluierenden Ausgabe, denkt es Schritt für Schritt durch und produziert eine Bewertung.

Hier ist ein praktisches Beispiel mit DeepEvals G-Eval-Implementierung:

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

correctness_metric = GEval(
    name="Correctness",
    criteria="Determine if the output is factually correct based on the expected output.",
    evaluation_params=[
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
    ],
    threshold=0.7,
)

test_case = LLMTestCase(
    input="What is the capital of France?",
    actual_output="Paris is the capital of France.",
    expected_output="The capital of France is Paris.",
)

correctness_metric.measure(test_case)
print(f"Score: {correctness_metric.score}")  # 0.0 bis 1.0
print(f"Reason: {correctness_metric.reason}")

Du kannst beliebige Kriterien definieren – Korrektheit, Hilfsbereitschaft, Professionalität, Markenstimme-Compliance – und das Richter-LLM wird entsprechend bewerten.

Bekannte Biases (was Vendor-Leitfäden dir nicht sagen)

Hier hören die meisten Evaluierungsleitfäden auf. Sie zeigen dir die Einrichtung und gehen weiter. Aber LLM-Richter haben systematische Biases, die deine Evaluierungsergebnisse still korrumpieren können:

• Positionsbias: Beim Vergleich zweier Ausgaben (A/B-Tests) bevorzugen LLM-Richter konsequent die Option, die zuerst präsentiert wird. Tausche die Reihenfolge aus, und der „Gewinner" ändert sich.
• Selbstpräferenz-Bias: GPT-4 bewertet GPT-4-Ausgaben höher als Claude dieselben Ausgaben bewertet, und umgekehrt. Der Richter bevorzugt seine eigene Modellfamilie.
• Ausführlichkeits-Bias: Längere Antworten erhalten unabhängig von der tatsächlichen Qualität höhere Bewertungen. Eine 500-Wort-Antwort schneidet besser ab als eine 100-Wort-Antwort, die dasselbe klarer sagt.
• Ankerungs-Bias: Wenn du dem Richter vorherige Bewertungen oder Beispiele zeigst, werden nachfolgende Bewertungen zu diesen Ankern hingezogen.

Richter-Bias mindern

Diese Biases sind beherrschbar, sobald du sie kennst:

1. Reihenfolge zufällig anordnen in A/B-Vergleichen (behebt Positionsbias)
2. Eine andere Modellfamilie als Richter verwenden als deinen Generator (behebt Selbstpräferenz)
3. Längennormalisierungsanweisungen in deine Bewertungskriterien einbeziehen (behebt Ausführlichkeits-Bias)
4. Multi-Richter-Panels ausführen – 2-3 verschiedene LLMs verwenden und die Bewertungen für wichtige Evaluierungen mitteln

Fazit: LLM-as-a-Judge funktioniert überraschend gut – aber nur, wenn du seine blinden Flecken kennst. Validiere immer gegen menschliche Bewertungen auf deinem spezifischen Anwendungsfall, bevor du ihm voll vertraust.

RAG-Systeme evaluieren: Faithfulness, Relevancy und Recall

RAG-Evaluierung ist 2026 der mit Abstand häufigste Evaluierungs-Use-Case, und sie unterscheidet sich grundlegend von der Evaluierung eines eigenständigen LLMs. Du testest zwei Komponenten – den Retriever und den Generator – und ein Fehler bei einer von beiden produziert schlechte Ausgaben.

Die vier Kernmetriken

• Faithfulness – Ist die generierte Antwort tatsächlich im abgerufenen Kontext verankert? Eine Antwort, die korrekt klingt, aber Informationen enthält, die nicht in den abgerufenen Dokumenten vorhanden sind, ist eine Halluzination. Das ist deine wichtigste Metrik.
• Context Relevancy – Hat der Retriever Dokumente abgerufen, die tatsächlich relevant für die Anfrage sind? Garbage in, Garbage out.
• Context Recall – Hat der Retriever ALLE relevanten Dokumente gefunden, oder hat er kritischen Kontext verpasst?
• Answer Relevancy – Geht die endgültige Antwort, selbst bei perfekter Retrieval, tatsächlich auf das ein, was der Nutzer gefragt hat?

RAG-Evals mit Ragas durchführen

Ragas ist das zweckgebundene Framework für RAG-Evaluierung. Hier ist das Kernmuster:

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

# Dein Evaluierungsdatensatz
eval_data = {
    "question": ["Was ist unsere Rückgaberichtlinie?"],
    "answer": ["Sie können innerhalb von 30 Tagen nach dem Kauf eine Rückerstattung beantragen."],
    "contexts": [["Rückgaberichtlinie: Kunden können innerhalb von 30 Tagen eine vollständige Rückerstattung beantragen."]],
    "ground_truth": ["Kunden können innerhalb von 30 Tagen eine Rückerstattung erhalten."],
}

eval_dataset = Dataset.from_dict(eval_data)

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, context_relevancy, answer_relevancy],
)
print(result)
# {'faithfulness': 0.95, 'context_relevancy': 0.88, 'answer_relevancy': 0.91}

Häufige RAG-Evaluierungsfehler

Drei Muster, über die Teams wiederholt stolpern:

1. Nur den Generator evaluieren und die Retriever-Qualität ignorieren. Deine Antwort könnte perfekt aus den falschen Dokumenten generiert werden.
2. BLEU oder ROUGE für RAG verwenden – diese Metriken können Halluzinationen überhaupt nicht erkennen. Eine Antwort kann bei ROUGE hoch abschneiden und dabei fabrizierte Informationen enthalten.
3. Nicht mit adversariellen Anfragen testen – Edge Cases, die das Retrieval brechen (mehrdeutige Anfragen, Out-of-Scope-Fragen, Anfragen ohne relevante Dokumente), sind, wo RAG-Systeme am härtesten scheitern.

Wenn du den richtigen Stack für deine KI-Anwendung auswählst, stelle sicher, dass deine Infrastruktur von Anfang an Evaluierung unterstützt – sie später hinzuzufügen ist immer schwieriger.

Fazit: RAG-Evaluierung ist nicht verhandelbar. faithfulness und context_relevancy sind deine zwei Pflicht-Metriken. Alles andere ist sekundär.

KI-Agenten evaluieren: Jenseits von Single-Call-Metriken

Agenten-Evaluierung ist der Bereich, wo es wirklich schwierig wird. Anders als ein Chatbot oder RAG-System führt ein Agent mehrere Schritte durch, nutzt Tools, trifft Entscheidungen und kann in unerwartete Richtungen gehen. Traditionelle Single-Call-Metriken erfassen das nicht.

Agenten-spezifische Metriken

• Task Completion Rate – Hat der Agent das Gesamtziel erreicht? Das ist deine Nordstern-Metrik.
• Tool Use Correctness – Hat er die richtigen Tools mit den richtigen Parametern aufgerufen? Ein Agent, der eine Datenbankabfrage mit falschen Filtern aufruft, könnte die Aufgabe mit falschen Daten „abschließen".
• Context Retention – Behält der Agent über einen mehrstufigen Workflow kohärenten Kontext bei, oder verliert er den Überblick?
• Cost per Successful Task – Agenten können API-Aufrufe verbrennen. Ein Agent, der 47 LLM-Aufrufe benötigt, um eine Aufgabe zu erledigen, die 5 erfordern sollte, ist ein Produktionskostenproblem.
• Error Recovery – Wenn ein Tool-Aufruf fehlschlägt oder unerwartete Ergebnisse liefert, passt sich der Agent an oder steckt er in einer Endlosschleife fest?

Die statistische Testherausforderung

Hier ist, was die Agenten-Evaluierung grundlegend anders macht: Das Verhalten von Agenten ist nicht-deterministisch. Führe dieselbe Aufgabe zehnmal aus und du bekommst vielleicht sieben Erfolge, zwei Teilvollendungen und eine Endlosschleife. Du brauchst statistische Evaluierung – führe jeden Testfall N-mal aus und berichte über Abschlussraten, nicht Bestanden/Nicht-bestanden.

Frameworks holen auf. DeepEval enthält jetzt agenten-spezifische Metriken, und AWS hat Agenten-Evaluierungsmuster veröffentlicht. Aber ehrlich gesagt ist das Tooling noch früh. Wenn du KI-Agenten in der Produktion deployest, erwarte, etwas benutzerdefinierte Evaluierungslogik zu bauen.

Fazit: Agenten-Evaluierung ist noch früh, aber Task Completion Rate und Kosten pro Aufgabe sind die zwei Metriken, die du von Tag eins an verfolgen solltest.

LLM-Evaluierungs-Frameworks im Vergleich

Jeder bestehende Framework-Vergleich wird von einem Vendor geschrieben, der sich selbst an erste Stelle stellt. Hier ist die neutrale Version.

Wähle dies, wenn...

• Du gerade anfängst: DeepEval oder Ragas – beide kostenlos, gut dokumentiert, schnell einzurichten
• Du LangChain verwendest: LangSmith – tiefe Integration macht es zum Weg des geringsten Widerstands
• Du CI/CD-Blocking brauchst: Braintrust – das einzige Tool, das nativ Deployments bei Eval-Fehler blockiert
• Du selbst-gehostete Observability willst: Langfuse – die beste Open-Source-Tracing + Evaluierungs-Kombination
• Du Produktionsüberwachung brauchst: Arize Phoenix – stärkste Embedding-Analyse und Drift-Erkennung
• Du nur RAG evaluierst: Ragas – zweckgebaut, leichtgewichtig, beste RAG-Metriken

Für einen tieferen Blick auf jedes Tool mit Preisaufschlüsselungen und Einrichtungsanleitungen, siehe unsere Best LLM Evaluation Tools [demnächst].

Fazit: Es gibt kein einzelnes „bestes" Framework. DeepEval für benutzerdefinierte Metriken, Ragas für RAG, Braintrust für CI/CD, Langfuse für selbst-gehostete Observability. Wähle das, das zu deinem Workflow passt.

Deine Evaluierungs-Pipeline aufbauen: Von Ad-hoc zu automatisiert

Die meisten Teams, die LLM-Features bauen, stecken bei dem fest, was wir Level 1 nennen – ein paar Ausgaben manuell prüfen und das Beste hoffen. So geht es weiter.

Das Evaluierungs-Reifegradmodell

Einen goldenen Datensatz aufbauen

Deine Evaluierung ist nur so gut wie deine Testdaten. Beginne mit 50-100 handkuratierten Beispielen, die echte Nutzeranfragen repräsentieren, Edge Cases und adversarielle Eingaben einschließen und die gesamte Bandbreite des erwarteten Verhaltens abdecken.

Versioniere deine Datensätze. Sie sollten sich entwickeln, wenn dein Produkt sich entwickelt – neue Features bedeuten neue Testfälle. Ein goldener Datensatz von vor sechs Monaten spiegelt wahrscheinlich nicht wider, was deine Nutzer heute tun.

Qualität deiner Evaluierungsergebnisse gleich Qualität deiner Ground Truth. Investiere die Zeit.

CI/CD-Integration

Sobald du einen goldenen Datensatz hast, verbinde ihn mit deiner Deployment-Pipeline. Führe Evals bei jedem PR aus, der Prompts, Retrieval-Logik oder Modellkonfiguration berührt. Jede Änderung am Prompt Engineering sollte durch einen messbaren Score abgesichert sein, nicht auf gut Glück ausgeliefert werden. Lege Score-Schwellenwerte fest – beispielsweise faithfulness >= 0.8 und hallucination_rate < 0.05 – und blockiere das Deployment, wenn sie scheitern.

Hier ist ein minimales GitHub Actions-Setup als Ausgangspunkt:

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
  pull_request:
    paths: ['prompts/**', 'src/llm/**']
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install deepeval
      - run: deepeval test run tests/eval_suite.py
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

Dies löst eine Evaluierung aus, wenn jemand eine Prompt-Datei oder LLM-bezogenen Code ändert. Wenn eine Metrik unter den Schwellenwert fällt, kann der PR nicht gemergt werden. Das ist Regressionstesting für LLM-Apps.

Produktionsüberwachung

Sobald du in der Produktion bist, sample und evaluiere Live-Traffic – 1-5% ist typisch. Verfolge Metric-Drift über die Zeit, denn Modell-Updates, Datenänderungen und sich veränderndes Nutzerverhalten können alle die Qualität verschlechtern, ohne dass jemand es bemerkt.

Richte Alerting ein, wenn Metriken unter Schwellenwerte fallen. Protokolliere alle Evaluierungen für Compliance-Audits (du wirst dich bedanken, wenn das EU-KI-Gesetz-Audit kommt). Wie Gergely Orosz anmerkt, muss Evaluierung ein kontinuierlicher Prozess sein, kein Launch-Checkbox.

Fazit: Die meisten Teams stecken bei Level 1 (Bauchgefühl) fest. Der Übergang zu Level 2 (goldene Datensätze) dauert einen Tag und verändert dein Vertrauen beim Ausliefern von LLM-Features dramatisch.

EU-KI-Gesetz und LLM-Evaluierung: Was du für Compliance brauchst

Das ist der Abschnitt, den kein anderer Evaluierungsleitfaden abdeckt – und mit der August-2026-Durchsetzung, die näher rückt, ist es der Abschnitt, der für Engineering-Leads und CTOs am wichtigsten ist.

Was das EU-KI-Gesetz erfordert

Das EU-KI-Gesetz (Verordnung 2024/1689) klassifiziert KI-Systeme nach Risikograd und stellt entsprechende Anforderungen. Hochrisiko-Systeme benötigen systematische Evaluierung, Dokumentation und laufende Überwachung. Selbst Systeme mit „begrenztem Risiko" (wo die meisten LLM-Anwendungen fallen) haben Transparenz- und Dokumentationspflichten.

Der Kernpunkt: Selbst wenn du nicht in der EU ansässig bist, gelten diese Regeln für dich, wenn dein KI-System EU-Nutzer bedient. Das Risikoklassifizierungs-Framework der Europäischen Kommission hilft dir, zu bestimmen, wo dein System fällt.

Evaluierungspraktiken auf Compliance-Anforderungen mappen

Hier ist, wie deine Evaluierungsmetriken direkt mit EU-KI-Gesetz-Artikeln verbunden sind:

Red Teaming für Compliance

Das EU-KI-Gesetz verlangt adversarielle Tests für Hochrisiko-Systeme. Red Teaming bedeutet systematisches Versuchen, dein System zu brechen:

• Prompt Injection – Können Nutzer System-Prompts manipulieren?
• Jailbreak-Versuche – Können Nutzer Sicherheitsrichtlinien umgehen?
• Bias-Sondierung – Behandelt das System demographische Gruppen unterschiedlich?
• Datenextraktion – Können Nutzer Trainingsdaten oder PII extrahieren?

Dokumentiere alles: Methodik, Erkenntnisse, Milderungsmaßnahmen. Plane vierteljährliche Red-Team-Übungen mindestens.

Praktische Schritte für die August-2026-Bereitschaft

1. Klassifiziere das Risikoniveau deines KI-Systems (die meisten LLM-Apps sind „begrenztes Risiko")
2. Etabliere Evaluierungsmetriken und Schwellenwerte jetzt
3. Implementiere automatisierte Evaluierung in CI/CD
4. Richte Produktionsüberwachung mit Audit-Logging ein
5. Dokumentiere deine Evaluierungsmethodik formell
6. Plane regelmäßige Red-Teaming-Übungen
7. Bereite Vorfallreaktionsverfahren vor

Fazit: Selbst wenn du nicht in der EU bist, setzt das KI-Gesetz den globalen Standard. Jetzt Evaluierungs- und Dokumentationspraktiken aufzubauen, spart dir später einen Kraftakt.

Häufige Evaluierungsfehler (und wie man sie vermeidet)

Nach der Unterstützung von Teams beim Aufbau von LLM-Evaluierungs-Pipelines sind das die Fehler, die wir immer wieder sehen:

1. Mit Trainingsdaten evaluieren – Wenn deine Testfälle mit dem überlappen, was das Modell während des Fine-Tunings gesehen hat, sind deine Scores bedeutungslos. Verwende immer zurückgehaltene Evaluierungssets.
2. BLEU/ROUGE für offene Aufgaben verwenden – Diese Metriken messen oberflächliche Textüberlappung. Sie können keine Halluzinationen erkennen, Hilfsbereitschaft bewerten oder kreative Qualität beurteilen.
3. Benchmarks blind vertrauen – Benchmark-Kontamination ist real. Modelle, die auf MMLU-Fragen trainiert wurden, schneiden gut bei MMLU ab, aber das bedeutet nicht, dass sie gut bei deiner spezifischen Aufgabe abschneiden werden. Verwende immer anwendungsspezifische Evals.
4. Menschliche Kalibrierung überspringen – LLM-as-Judge braucht Validierung gegen menschliche Bewertungen auf DEINEN Daten, bevor du ihm vertraust. Führe mindestens 50 Beispiele durch sowohl menschliche Reviewer als auch den LLM-Richter, dann prüfe die Korrelation.
5. Einmalige Evaluierung – Evaluierung ist kein Launch-Checkbox. Modelle ändern sich, Nutzerverhalten verschiebt sich und Retrieval-Qualität degradiert. Mach es kontinuierlich.
6. Dasselbe Modell als Richter und Generator – Selbstpräferenz-Bias bläht Scores auf. Verwende eine andere Modellfamilie zum Urteilen.
7. Evaluierungsdatensätze nicht versionieren – Deine Evals sollten sich mit deinem Produkt weiterentwickeln. Verfolge Änderungen, füge neue Edge Cases hinzu, ziehe veraltete Testfälle zurück.
8. Kosten ignorieren – LLM-as-Judge bei jeder Produktionsanfrage auszuführen wird schnell teuer. Sample intelligent – 1-5% des Traffics reicht für die Überwachung.

Wie Techsy die LLM-Evaluierung angeht

Wir haben Evaluierungs-Pipelines für Startup-Teams aufgebaut, die LLM-Features über Chatbots, RAG-Systeme und KI-Agenten ausliefern. Unsere typische Zusammenarbeit folgt einem Muster:

1. Audit – Wir überprüfen deine aktuellen LLM-Ausgaben, identifizieren Fehlermuster und kartieren deine Position auf dem Reifegradmodell
2. Metrikauswahl – Basierend auf deinem Anwendungstyp definieren wir die 3-5 Metriken, die wirklich wichtig sind (mithilfe des Frameworks aus diesem Leitfaden)
3. Goldener Datensatz-Erstellung – Wir bauen deinen initialen Evaluierungsdatensatz, einschließlich der adversariellen Edge Cases, die die meisten Teams übersehen
4. Pipeline-Setup – CI/CD-Integration mit automatisiertem Scoring und Deployment-Gates
5. Übergabe – Dein Team besitzt es danach, mit Dokumentation und Runbooks

Die meisten Teams brauchen für das keinen externen Partner – wenn du einen ML-Ingenieur und eine Woche dedizierter Zeit hast, gibt dir dieser Leitfaden alles, was du brauchst. Aber wenn du wenig Zeit hast, einer Compliance-Frist gegenübersiehst oder eine erfahrene zweite Meinung zu deiner Evaluierungsstrategie willst, helfen wir gerne.

Brauchst du Hilfe beim Aufbau einer Evaluierungs-Pipeline für deine LLM-Anwendung? Kostenlose Beratung anfragen

FAQ

Wie evaluiert man die Leistung von LLMs?

Beginne damit, deine Erfolgskriterien zu definieren – Genauigkeit, Sicherheit, Relevanz oder was auch immer für deinen Anwendungsfall wichtig ist. Wähle 3-5 Metriken, die zu deinem Anwendungstyp passen (siehe die Metrik-zu-Anwendungs-Tabelle oben), baue einen goldenen Datensatz mit mindestens 50 Testfällen und führe automatisierte Evals mit Frameworks wie DeepEval oder Ragas aus. Validiere deine automatisierten Scores gegen menschliches Urteil an einer Stichprobe, bevor du ihnen vertraust.

Welche Metriken werden zur Evaluierung von LLMs verwendet?

Kernmetriken umfassen Faithfulness, Answer Relevancy und Halluzinationsrate für RAG-Systeme; BLEU und ROUGE für Übersetzung und Zusammenfassung; Toxizität und Bias für Sicherheit; und Task Completion Rate für Agenten. Die richtigen Metriken hängen von deinem Anwendungstyp ab – ein Chatbot braucht eine andere Evaluierung als ein Code-Generator.

Was ist LLM-as-a-Judge?

Eine Methode, bei der ein separates LLM (typischerweise GPT-4o oder Claude) die Ausgabe eines anderen LLMs gegen von dir definierte Kriterien bewertet. G-Eval ist die beliebteste Implementierung, die Chain-of-Thought-Scoring verwendet. Forschungen zeigen ungefähr 81% Korrelation mit menschlichen Bewertungen, was es zum praktischen Standard für die tägliche Evaluierung 2026 macht.

Wie erkennt man Halluzinationen in LLMs?

Verwende Faithfulness-Metriken, die generierten Text mit Quelldokumenten vergleichen. Sowohl DeepEval als auch Ragas bieten eingebaute Halluzinationserkennung, die prüft, ob jede Behauptung in der Ausgabe im bereitgestellten Kontext verankert ist. Für Produktionssysteme kombiniere automatisierte Erkennung mit menschlichen Stichproben auf gekennzeichneten Ausgaben.

Was ist das beste LLM-Evaluierungs-Framework?

Es gibt kein einzelnes bestes. DeepEval für benutzerdefinierte Metriken und umfassende Evaluierung, Ragas für RAG-spezifische Evaluierung, Braintrust für CI/CD-Integration und Deployment-Blocking, LangSmith für Teams, die bereits LangChain verwenden, und Langfuse für selbst-gehostete Observability. Wähle das, das zu deinem Workflow passt.

Wie evaluiert man ein RAG-System?

Miss vier Metriken: Faithfulness (ist die Antwort im Kontext verankert?), Context Relevancy (richtige Dokumente abgerufen?), Context Recall (alle relevanten Dokumente gefunden?), und Answer Relevancy (geht auf die Anfrage ein?). Ragas und DeepEval sind die Standardtools. Entscheidend: Evaluiere sowohl den Retriever als auch den Generator – die meisten Teams testen nur den Generator und übersehen Retrieval-Fehler.

Was ist G-Eval?

G-Eval ist ein LLM-as-Judge-Framework, das Chain-of-Thought-Prompting verwendet, um Ausgaben gegen benutzerdefinierte Kriterien zu evaluieren. Du beschreibst, wie „gut" auf Deutsch aussieht, und das Richter-LLM denkt jeden Ausgabe durch und vergibt eine Bewertung. Das Originalpaper von Liu et al. zeigte starke Übereinstimmung mit menschlicher Evaluierung über mehrere NLG-Aufgaben.

Wie beeinflusst das EU-KI-Gesetz die LLM-Evaluierung?

Das EU-KI-Gesetz erfordert systematische Evaluierung, Dokumentation und Überwachung für KI-Systeme, die EU-Nutzer bedienen. Hochrisiko-Systeme müssen Genauigkeit, Robustheit, Transparenz und Nicht-Diskriminierung durch formale Evaluierungspraktiken nachweisen. Selbst Systeme mit begrenztem Risiko haben Transparenzpflichten. Die Durchsetzung beginnt August 2026, und die Anforderungen gelten für jedes Unternehmen, das EU-Nutzer bedient, unabhängig vom Standort.

Wie evaluiert man KI-Agenten?

Verfolge Task Completion Rate, Tool Use Correctness, Context Retention über Schritte hinweg und Kosten pro erfolgreicher Aufgabe. Agenten-Evaluierung erfordert statistische Ansätze – führe dieselbe Aufgabe mehrmals aus und berichte über Abschlussraten, nicht einzelne Bestanden/Nicht-bestanden-Ergebnisse. Das Tooling ist noch früh, aber DeepEval und AWS bieten beide aufkommende Agenten-Evaluierungs-Frameworks.

Was ist Benchmark-Kontamination?

Wenn LLM-Trainingsdaten Benchmark-Testfragen enthalten, werden Scores künstlich aufgebläht, ohne echte Fähigkeit widerzuspiegeln. Deshalb sollten öffentliche Benchmarks wie MMLU nicht deine einzige Evaluierungsmethode sein. Modelle können bei kontaminierten Benchmarks beeindruckend abschneiden, während sie bei realen Aufgaben schlecht performen. Ergänze immer Benchmarks mit anwendungsspezifischer Evaluierung auf deinen eigenen Daten.

Wie viel kostet LLM-Evaluierung?

Open-Source-Tools wie DeepEval und Ragas sind kostenlos. LLM-as-a-Judge kostet ungefähr 0,01–0,05 € pro Evaluierung, abhängig vom Richter-Modell. Kommerzielle Plattformen wie Braintrust und LangSmith haben kostenlose Tiers für kleine Teams und kostenpflichtige Pläne für Produktionsnutzung. Menschliche Evaluierung kostet 5–50 € pro Evaluierung. Die meisten Teams können eine solide Evaluierungs-Pipeline für unter 100 €/Monat einrichten.

Quellen

• DeepEval Dokumentation – Metriken
• Ragas Dokumentation – Metriken
• Braintrust Dokumentation – Evals
• LangSmith Dokumentation – Evaluierung
• Langfuse Dokumentation – Scores und Evaluierung
• Arize Phoenix Dokumentation
• EU-KI-Gesetz – Volltext (Verordnung 2024/1689)
• EU-KI-Gesetz – Risikoklassifizierung (Europäische Kommission)
• Judging LLM-as-a-Judge – Zheng et al., 2023
• G-Eval: NLG Evaluation using GPT-4 – Liu et al., 2023
• How to Build an LLM Evaluation Framework – The Pragmatic Engineer