LLM-Evaluations-Pipelines aufbauen: KI vor der Produktion testen [2026]

Sie haben eine LLM-Anwendung gebaut, die in Ihren Demos brillant funktioniert. Das Produktteam ist begeistert. Die Führung will sie nächstes Quartal in Produktion. Aber dann kommt die Frage, die jedes KI-Projekt stoppt: Woher wissen Sie, dass sie tatsächlich funktioniert?

Traditionelles Software-Testing gibt Ihnen binäre Antworten — die Funktion liefert den erwarteten Output oder nicht. LLM-Evaluation ist fundamental anders. Ihr Modell könnte fünf verschiedene gültige Antworten auf dieselbe Frage geben. Es könnte faktisch korrekt sein, aber die Intention des Nutzers verfehlen. Es könnte perfekt auf Ihren Testfällen funktionieren und auf echten Nutzeranfragen spektakulär versagen.

Warum LLM-Evaluation anders ist

Software-Ingenieure erwarten, dass LLM-Evaluation wie Unit-Testing funktioniert. Tut sie nicht. Das Verständnis warum hilft beim Aufbau besserer Evaluationssysteme.

Nicht-deterministische Outputs

Selbst mit Temperature auf Null können LLM-Outputs zwischen API-Aufrufen variieren wegen Infrastrukturänderungen, Model-Updates oder Gleitkomma-Präzisionsunterschieden. Derselbe Prompt könnte heute «Die Hauptstadt von Frankreich ist Paris» generieren und morgen «Paris ist die Hauptstadt von Frankreich». Beide sind korrekt, aber ein naiver String-Vergleich schlägt fehl.

Mehrere gültige Antworten

Bitten Sie ein LLM, ein Dokument zusammenzufassen, und Sie erhalten Dutzende gültiger Zusammenfassungen. Bitten Sie es, Code für eine Funktion zu schreiben, und es gibt unendlich viele korrekte Implementierungen. Ihr Evaluationssystem muss erkennen, dass anders nicht falsch bedeutet.

Evaluation erfordert Urteilsvermögen

Zu bestimmen, ob eine LLM-Antwort «gut» ist, erfordert oft menschliches Verständnis. Ist die Antwort faktisch korrekt? Adressiert sie die tatsächliche Intention des Nutzers? Ist der Ton angemessen? Diese Urteile lassen sich nicht auf einfache Assertions reduzieren.

Fehler sind subtil

LLMs crashen selten — sie versagen elegant, indem sie plausibel klingenden Unsinn generieren. Ein halluzinierter Fakt sieht identisch zu einem korrekten aus. Ein subtil falscher Code-Vorschlag kompiliert und läuft, produziert aber inkorrekte Ergebnisse. Ihre Evaluation muss diese stillen Fehler fangen.

Evaluationsdimensionen

Produktions-LLM-Systeme brauchen Evaluation über mehrere Dimensionen. Eine Antwort kann bei Faktizität gut abschneiden, aber bei Relevanz versagen, oder hochrelevant aber schlecht strukturiert sein.

Nicht jede Dimension ist für jede Anwendung gleich wichtig. Ein Kundensupport-Bot priorisiert Faktizität und Sicherheit. Ein kreatives Schreibassistenten-Tool gewichtet Kohärenz und Relevanz höher. Definieren Sie, welche Dimensionen für Ihren Anwendungsfall am wichtigsten sind, bevor Sie Evaluationsinfrastruktur aufbauen.

Evaluationsdatensätze aufbauen

Ihre Evaluation ist nur so gut wie Ihre Testfälle. Die meisten Teams investieren zu wenig in die Datensatzerstellung und zahlen dafür mit unzuverlässigen Qualitätssignalen.

Echte Anfragen sammeln

Beginnen Sie mit tatsächlichen Nutzeranfragen, nicht mit synthetischen Beispielen, die Sie erfunden haben. Produktionsanfragen enthüllen Edge Cases, Formulierungsvarianten und Nutzungsmuster, die Sie nie antizipieren würden. Quellen umfassen:

• Produktionslogs — Sample von tatsächlichen Anfragen (anonymisiert wenn nötig)
• Support-Tickets — Fragen, die Kunden tatsächlich stellen
• Suchlogs — Was Nutzer in Ihrem Produkt suchen
• Fehlerfälle — Anfragen, die Beschwerden oder Eskalationen auslösten

Golden Answers erstellen

Jede Testanfrage braucht eine Referenzantwort — die «Golden» Response, gegen die Sie Model-Outputs vergleichen. Golden Answers sollten sein:

• Expertengeprüft — Von Domänenexperten geschrieben oder validiert
• Umfassend — Alle Kernpunkte abdecken, die die Antwort enthalten sollte
• Annotiert — Metadaten über erforderliche Fakten, Formaterwartungen, benötigte Zitationen einschliessen

Evaluationsdatensatz-Format

Strukturieren Sie Ihren Evaluationsdatensatz für automatisiertes Testing:

{
  "test_cases": [
    {
      "id": "tc-001",
      "query": "Was sind die Rückerstattungsrichtlinien für Jahresabonnements?",
      "context": "Abgerufene Dokumente würden hier für RAG-Evaluation stehen",
      "golden_answer": "Jahresabonnements können innerhalb von 30 Tagen nach Kauf erstattet werden...",
      "required_facts": [
        "30-Tage-Rückerstattungsfenster",
        "Anteilige Erstattungen nach 30 Tagen",
        "Keine Erstattung für verbrauchte Credits"
      ],
      "evaluation_criteria": {
        "must_mention": ["30 Tage", "Erstattung"],
        "must_not_mention": ["garantiert", "unbegrenzt"],
        "expected_format": "paragraph",
        "max_length": 200
      },
      "metadata": {
        "category": "billing",
        "difficulty": "easy",
        "source": "production_logs"
      }
    }
  ]
}

Datensatz-Pflege

Evaluationsdatensätze sind nicht statisch. Planen Sie für laufende Pflege:

• Regelmässige Updates — Neue Testfälle aus Produktionsfehlern hinzufügen
• Golden-Answer-Aktualisierung — Aktualisieren, wenn zugrundeliegende Informationen sich ändern
• Balance-Monitoring — Abdeckung über Kategorien und Schwierigkeitsgrade sicherstellen
• Versionierung — Datensatzänderungen neben Modelländerungen verfolgen

Ein gesunder Evaluationsdatensatz wächst kontinuierlich. Beginnen Sie mit 50-100 hochwertigen Testfällen, dann erweitern Sie basierend auf Produktionserkenntnissen.

Automatisierte Evaluationstechniken

Manuelle Überprüfung skaliert nicht. Sie brauchen automatisierte Evaluation, die bei jeder Änderung läuft.

LLM-as-Judge

Verwenden Sie ein leistungsfähiges LLM, um Outputs Ihres Produktionsmodells zu evaluieren. Dieser Ansatz erfasst nuancierte Qualitätsurteile, die Regeln nicht ausdrücken können.

from openai import OpenAI

client = OpenAI()

def evaluate_response(query: str, response: str, golden_answer: str) -> dict:
    """GPT-4 zur Bewertung der Antwortqualität verwenden."""

    evaluation_prompt = f"""Sie evaluieren die Antwort eines KI-Assistenten.

Anfrage: {query}

KI-Antwort: {response}

Referenzantwort: {golden_answer}

Bewerten Sie die Antwort nach diesen Kriterien (Score 1-5):
1. Faktizität: Sind alle Behauptungen akkurat?
2. Relevanz: Adressiert sie die Anfrage?
3. Vollständigkeit: Deckt sie Kernpunkte der Referenz ab?
4. Klarheit: Ist sie gut geschrieben und leicht verständlich?

Antworten Sie im JSON-Format:
,
    "relevance": ,
    "completeness": ,
    "clarity": ,
    "overall_pass": true/false,
    "issues": ["Liste spezifischer Probleme falls vorhanden"]
}}"""

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": evaluation_prompt}],
        response_format={"type": "json_object"}
    )

    return json.loads(response.choices[0].message.content)


# Evaluation ausführen
result = evaluate_response(
    query="Was ist Ihre Rückgabepolitik?",
    response=model_output,
    golden_answer=test_case["golden_answer"]
)

assert result["overall_pass"], f"Evaluation fehlgeschlagen: {result['issues']}"

Embedding-basierte Metriken

Messen Sie semantische Ähnlichkeit zwischen Model-Output und Referenzantworten mittels Embeddings. Dies fängt Antworten ab, die dasselbe unterschiedlich sagen.

• Kosinus-Ähnlichkeit — Embedding-Vektoren von Antwort und Golden Answer vergleichen
• BERTScore — Token-Level-Ähnlichkeit mit kontextuellen Embeddings
• Semantische Textähnlichkeit — Zweckgebundene Modelle zum Vergleich von Textbedeutung

Embedding-Metriken funktionieren gut für faktisches Q&A, wo die «richtige Antwort» existiert. Sie kämpfen mit kreativen oder offenen Aufgaben.

Traditionelle NLP-Metriken

Klassische Metriken haben nach wie vor ihren Platz:

• BLEU/ROUGE — N-Gramm-Überlappung, nützlich für Zusammenfassung und Übersetzung
• Exakte Übereinstimmung — Für strukturierte Outputs wie Entity-Extraktion
• Regex-Validierung — Formatkonformität prüfen (JSON, E-Mail, Datum)
• Keyword-Präsenz — Verifizieren, dass erforderliche Begriffe in der Antwort erscheinen

Spezialisierte Evaluatoren

Manche Evaluationsaufgaben brauchen zweckgebaute Tools:

• Code-Ausführung — Generierten Code ausführen und Outputs prüfen
• SQL-Validierung — Queries ausführen und Ergebnisse vergleichen
• Mathe-Verifikation — Erwartete Antworten berechnen und vergleichen
• Zitations-Checking — Verifizieren, dass Behauptungen auf Quellen zurückführbar sind (kritisch für RAG-Systeme)

Evaluations-Frameworks im Vergleich

Mehrere Open-Source-Frameworks helfen bei der Strukturierung von LLM-Evaluation. Jedes hat unterschiedliche Stärken.

deepeval-Beispiel

deepeval integriert sich mit pytest für vertraute Testing-Muster:

from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import (
    AnswerRelevancyMetric,
    FaithfulnessMetric,
    ContextualRelevancyMetric
)

def test_rag_response():
    """Test, dass RAG-Antworten relevant und fundiert sind."""

    test_case = LLMTestCase(
        input="Was ist die Rückerstattungsrichtlinie für Jahrespläne?",
        actual_output=rag_pipeline.query("Was ist die Rückerstattungsrichtlinie für Jahrespläne?"),
        expected_output="Jahrespläne können innerhalb von 30 Tagen erstattet werden...",
        retrieval_context=[
            "Rückerstattungsrichtlinie: Jahresabonnements sind innerhalb von 30 Tagen nach Kauf voll erstattbar.",
            "Nach 30 Tagen werden Erstattungen anteilig basierend auf der verbleibenden Abonnementperiode berechnet."
        ]
    )

    # Evaluationsmetriken definieren
    relevancy_metric = AnswerRelevancyMetric(threshold=0.7)
    faithfulness_metric = FaithfulnessMetric(threshold=0.8)
    context_metric = ContextualRelevancyMetric(threshold=0.7)

    # Assertions ausführen
    assert_test(test_case, [relevancy_metric, faithfulness_metric, context_metric])


def test_no_hallucination():
    """Verifizieren, dass Antwort keine vom Kontext nicht gestützten Behauptungen enthält."""

    test_case = LLMTestCase(
        input="Welche Premium-Features sind enthalten?",
        actual_output=model_response,
        retrieval_context=retrieved_docs
    )

    # Faithfulness prüft, dass Behauptungen im Kontext fundiert sind
    faithfulness = FaithfulnessMetric(threshold=0.9)
    assert_test(test_case, [faithfulness])

CI/CD-Integration

Evaluation sollte automatisch bei jeder Änderung laufen. Regressionen vor dem Deployment zu fangen ist weit günstiger als sie in Produktion zu fixen.

GitHub Actions Workflow

name: LLM Evaluation Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  OPENAI_API_KEY: $

jobs:
  evaluate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install deepeval pytest

      - name: Run evaluation suite
        run: |
          deepeval test run tests/evaluation/

      - name: Run regression tests
        run: |
          pytest tests/evaluation/ -v --tb=short

      - name: Upload evaluation results
        uses: actions/upload-artifact@v4
        with:
          name: evaluation-results
          path: evaluation_results/

      - name: Check quality gates
        run: |
          python scripts/check_quality_gates.py \
            --min-relevancy 0.8 \
            --min-faithfulness 0.85 \
            --max-hallucination-rate 0.05

      - name: Comment PR with results
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const results = JSON.parse(fs.readFileSync('evaluation_results/summary.json'));

            const body = `## LLM Evaluation Results

            | Metrik | Score | Schwellenwert | Status |
            |--------|-------|---------------|--------|
            | Relevanz | ${results.relevancy.toFixed(2)} | 0.80 | ${results.relevancy >= 0.8 ? 'Pass' : 'Fail'} |
            | Faithfulness | ${results.faithfulness.toFixed(2)} | 0.85 | ${results.faithfulness >= 0.85 ? 'Pass' : 'Fail'} |
            | Halluzinationsrate | ${results.hallucination_rate.toFixed(2)} | 0.05 | ${results.hallucination_rate <= 0.05 ? 'Pass' : 'Fail'} |

            **Testfälle:** ${results.total_tests} | **Bestanden:** ${results.passed} | **Fehlgeschlagen:** ${results.failed}
            `;

            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: body
            });

Quality Gates

Definieren Sie klare Schwellenwerte, die vor dem Deployment bestanden werden müssen:

• Mindestgenauigkeitswerte — Relevanz, Faithfulness, Faktizität über Schwellenwerten
• Maximale Regression — Nicht mehr als X% Degradation von der Baseline
• Null kritische Fehler — Sicherheitsverletzungen, Formatfehler oder komplette Fehler blockieren Deployment
• Abdeckungsanforderungen — Evaluation muss alle wichtigen Anfragekategorien abdecken

Produktions-Monitoring

Evaluation endet nicht beim Deployment. Produktionstraffic enthüllt Fehlermodi, die Testing verpasst.

Online-Evaluation

Führen Sie Evaluation kontinuierlich auf Produktionstraffic aus:

• Sample-basierte Evaluation — Zufällige Stichprobe von Anfragen automatisch evaluieren
• Shadow-Evaluation — Kandidatenmodelle parallel zur Produktion laufen lassen und vergleichen
• A/B-Testing — Modellversionen mit echten Nutzern vergleichen

Nutzerfeedback-Integration

Explizite und implizite Nutzersignale sind unschätzbar:

• Daumen hoch/runter — Direktes Qualitätssignal von Nutzern
• Regenerationsanfragen — Nutzer, die neue Antwort verlangen, zeigen Fehler an
• Folgefragen — Können auf unvollständige oder verwirrende Antworten hinweisen
• Aufgabenerfüllung — Hat der Nutzer sein Ziel erreicht?

Alerting bei Qualitätsdegradation

Richten Sie Alerts für Qualitätsabfälle ein:

• Rollierende Genauigkeitsmetriken — 24h-Durchschnitt verfolgen, bei signifikanten Drops alerten
• Fehlerraten-Spikes — Plötzlicher Anstieg von Formatfehlern oder fehlgeschlagenen Generierungen
• Latenzdegradation — P95-Latenz überschreitet Schwellenwerte
• Nutzerzufriedenheits-Drops — Sinkende Daumen-hoch-Quote oder steigende Beschwerden

Häufige Evaluationsfehler

Teams, die neu in LLM-Evaluation sind, fallen oft in diese Fallen.

Auf Trainingsdaten testen

Wenn Ihre Testfälle sich mit Daten überschneiden, die für Fine-Tuning oder Prompt-Engineering des Modells verwendet wurden, messen Sie Memorisierung, nicht Generalisierung. Halten Sie strikte Trennung zwischen Training- und Evaluationsdaten.

Overfitting auf Benchmarks

Optimierung auf Evaluationsmetriken kann von tatsächlicher Nutzerzufriedenheit divergieren. Ein Modell, das perfekt auf Ihrer Test-Suite scored, aber echte Nutzer frustriert, ist ein Fehler. Fügen Sie Nutzerfeedback in Ihre Evaluationsschleife ein.

Edge Cases ignorieren

Die meisten Evaluationsdatensätze tendieren zu gängigen, einfachen Fällen. Echter Produktionstraffic enthält adversariale Inputs, ungewöhnliche Formulierungen, Out-of-Scope-Anfragen und kombinierte Intentionen. Fügen Sie bewusst schwierige Fälle in Ihre Test-Suite ein.

Statische Evaluationssets

Ein fixer Evaluationsdatensatz wird veraltet, wenn sich Ihr Produkt entwickelt und Nutzerverhalten sich ändert. Aktualisieren Sie Testfälle kontinuierlich aus Produktionsdaten.

Fokus auf einzelne Metrik

Optimierung auf eine Metrik degradiert oft andere. Ein Modell, das Faktizität durch extreme Zurückhaltung maximiert, wird bei Vollständigkeit versagen. Verfolgen Sie mehrere Dimensionen und verstehen Sie ihre Trade-offs.

Unzureichendes Testvolumen

Mit 20 Testfällen verschiebt ein einzelner Evaluationsfehler Ihre Genauigkeit um 5%. Sie brauchen genug Testfälle für statistisch aussagekräftige Ergebnisse — typischerweise 100+ für Kernfunktionalität, 500+ für Produktionsreife.

Fazit

LLM-Evaluation ist die unspektakuläre Arbeit, die Demos von Produktionssystemen trennt. Ohne rigorose Evaluation deployen Sie KI auf Vertrauensbasis — in der Hoffnung, dass sie funktioniert, unfähig zu erkennen, wann sie degradiert, und überrascht, wenn Nutzer sich beschweren. Der Aufbau ordentlicher Evaluationsinfrastruktur erfordert Vorabinvestition, zahlt sich aber aus in Deployment-Vertrauen, schnellerer Iteration und früher Problemerkennung.

Die zentrale Erkenntnis ist, dass LLM-Evaluation ein anderes Mindset erfordert als traditionelles Software-Testing. Sie prüfen nicht auf exakte Korrektheit — Sie messen Qualität über mehrere Dimensionen und akzeptieren, dass «korrekt» oft «gut genug für den Anwendungsfall» bedeutet. Dies erfordert menschliches Urteilsvermögen, das in automatisierte Systeme kodiert wird, kontinuierliches Monitoring des Produktionsverhaltens und ehrliche Anerkennung dessen, was Ihre Tests erfassen können und was nicht.

Beginnen Sie einfach: Bauen Sie einen kleinen Evaluationsdatensatz aus echten Anfragen, implementieren Sie LLM-as-Judge für Kernqualitätsdimensionen, integrieren Sie Testing in Ihre CI/CD-Pipeline und monitoren Sie Produktionsfeedback. Erweitern Sie die Abdeckung, wenn Sie lernen, wo Ihr System versagt. Das Ziel ist nicht perfekte Evaluation — es ist ausreichendes Vertrauen, dass Ihr System gut genug funktioniert, um echte Nutzer zu bedienen, und schnelles Feedback, wenn es aufhört zu funktionieren.