Eine kontinuierliche Evaluationspipeline erstellen
Integrieren Sie die LLM-as-Judge-Evaluation in Ihre CI/CD-Pipeline, damit jede Änderung an Prompts oder Modellen vor dem Deployment automatisch anhand einer Regressionstestsuite evaluiert wird.
Eine kontinuierliche Evaluationspipeline erstellen ist eine kostenlose AI Engineering Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AI Engineering Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.
Warum Evaluation kontinuierlich erfolgen muss
Eine einmalige Evaluation bei der Bereitstellung reicht nicht aus. Die Qualität von LLMs nimmt unbemerkt ab: Modellanbieter aktualisieren ihre Modelle, Änderungen am System-Prompt gelangen unbemerkt in die Anwendung, die Retrieval-Qualität verändert sich, wenn der Dokumentbestand wächst, und die Verteilung der Benutzeranfragen ändert sich im Laufe der Zeit. Eine kontinuierliche Evaluations-Pipeline führt bei jeder Änderung und nach einem Zeitplan dieselbe Evaluations-Suite aus, sodass Qualitätsregressionen innerhalb von Stunden statt Wochen erkannt werden.
Kernkomponenten der Pipeline
Eine kontinuierliche Evaluations-Pipeline besteht aus fünf Komponenten: einem Testdatensatz (kuratierte Fragen mit erwarteten Ausgaben), einem System-Runner (ruft Ihre LLM-Pipeline für jede Testfrage auf), einem Judge (bewertet jede Antwort), einem Ergebnisspeicher (Datenbank oder Zeitreihenspeicher für historische Metriken) und einer Reporting-Schicht (Dashboards und Alarme). Jede Komponente kann unabhängig aktualisiert werden.
# Pipeline architecture:
#
# test_dataset.json
# |
# v
# system_runner.py --> calls your LLM pipeline
# |
# v
# judge.py --> scores each (question, answer) pair
# |
# v
# results_db --> stores timestamped metric history
# |
# v
# dashboard + alert --> Grafana / Slack notificationStrukturierung des Testdatensatzes
Speichern Sie Ihren Evaluations-Testsatz als versionierte JSON- oder YAML-Datei in Ihrem Repository. Jeder Eintrag enthält eine Frage, die Kategorie (faktisch, prozedural, außerhalb des Geltungsbereichs) und optional eine Referenzantwort. Versionieren Sie den Testsatz unabhängig vom Code – das Hinzufügen neuer Testfälle ist eine abwärtskompatible Änderung, während das Entfernen von Fällen Regressionen verschleiern kann. Streben Sie insgesamt 200–500 Fälle über alle relevanten Kategorien hinweg an.
# eval/test_set_v3.json
# {
# 'version': '3.0',
# 'created': '2026-06-01',
# 'cases': [
# {
# 'id': 'faq_001',
# 'category': 'factual',
# 'question': 'What is the cancellation policy?',
# 'reference': 'Cancellations must be made 24 hours in advance.',
# 'min_correctness': 4
# },
# ...
# ]
# }Ausführen der Evaluations-Suite
Der Evaluations-Runner ruft Ihr Produktivsystem (oder eine Staging-Version) für jeden Testfall auf und zeichnet die Antwort sowie Metadaten auf. Kennzeichnen Sie jeden Evaluationslauf mit einer eindeutigen Run-ID, der Commit-SHA, die ihn ausgelöst hat, dem Zeitstempel und der Version des Testsatzes. Dadurch können Sie Läufe exakt vergleichen und feststellen, welche Codeänderung die Regression verursacht hat.
import asyncio
import uuid
from datetime import datetime
async def run_eval_suite(system, test_set: list, commit_sha: str) -> dict:
run_id = str(uuid.uuid4())
results = []
for case in test_set:
response = await system.answer(case['question'])
score = await judge(case['question'], response, case.get('reference'))
results.append({
'run_id': run_id,
'commit_sha': commit_sha,
'case_id': case['id'],
'category': case['category'],
'response': response,
'score': score.model_dump(),
'evaluated_at': datetime.utcnow().isoformat()
})
return {'run_id': run_id, 'results': results}Speichern und Abfragen historischer Metriken
Speichern Sie das Ergebnis jedes Evaluationslaufs dauerhaft in einer Datenbank. Eine einfache Tabelle eval_results mit den Feldern run_id, commit_sha, case_id und score ist ausreichend. Fragen Sie aggregierte Bewertungen nach run_id ab, um laufbezogene Metriken zu berechnen. Vergleichen Sie den aktuellen Lauf mit dem letzten erfolgreichen Lauf im Haupt-Branch, um Regressionen zu erkennen. Eine Zeitreihendatenbank wie InfluxDB eignet sich gut für die kontinuierliche Überwachung.
-- PostgreSQL schema
CREATE TABLE eval_runs (
run_id UUID PRIMARY KEY,
commit_sha TEXT NOT NULL,
test_set_version TEXT NOT NULL,
triggered_by TEXT, -- 'ci', 'scheduled', 'manual'
started_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE eval_results (
id SERIAL PRIMARY KEY,
run_id UUID REFERENCES eval_runs(run_id),
case_id TEXT NOT NULL,
category TEXT,
correctness INT,
overall INT,
response TEXT
);
CREATE INDEX idx_run_id ON eval_results(run_id);Automatisches Erkennen von Regressionen
Vergleichen Sie nach jedem Evaluationslauf die aggregierten Bewertungen mit der Baseline (dem letzten Lauf aus dem Haupt-Branch, der manuell freigegeben wurde). Eine Regression ist definiert als: Eine Bewertungsdimension fällt um mehr als 5 % unter die Baseline oder der Mittelwert einer Kategorie fällt unter ein festgelegtes Mindestniveau. Regressionen sollten die Bereitstellung blockieren und das Team alarmieren. Verbesserungen können automatisch freigegeben werden.
def detect_regression(current: dict, baseline: dict, threshold_pct: float = 5.0) -> dict:
regressions = []
for metric in ['correctness', 'helpfulness', 'clarity']:
delta_pct = (current[metric] - baseline[metric]) / baseline[metric] * 100
if delta_pct < -threshold_pct:
regressions.append({
'metric': metric,
'baseline': baseline[metric],
'current': current[metric],
'delta_pct': round(delta_pct, 1)
})
return {'has_regression': len(regressions) > 0, 'regressions': regressions}Integration in CI/CD
Fügen Sie die Evaluations-Suite als CI-Schritt hinzu, der bei jedem Pull Request ausgeführt wird. Die CI-Pipeline ruft Ihr Staging-System auf, führt den Judge aus, speichert die Ergebnisse und prüft auf Regressionen. Wird eine Regression erkannt, schlägt der CI-Schritt fehl und blockiert das Mergen des PRs. Fügen Sie dies in GitHub oder GitLab als erforderliche Statusprüfung hinzu, damit niemand sie umgehen kann. Halten Sie die Laufzeit der Evaluation unter 10 Minuten, indem Sie für PR-Prüfungen eine Teilmenge von 50–100 Fällen verwenden.
# .github/workflows/eval.yml
# name: LLM Quality Evaluation
# on: [pull_request]
# jobs:
# eval:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v4
# - name: Run eval suite
# run: python eval/run_suite.py --commit $GITHUB_SHA --mode pr
# env:
# OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
# - name: Check for regressions
# run: python eval/check_regression.py --run-id $EVAL_RUN_IDGeplante vollständige Evaluationsläufe
Führen Sie zusätzlich zu den PR-Prüfungen täglich die vollständige Evaluations-Suite (alle mehr als 300 Fälle) gegen das Produktivsystem aus. So erkennen Sie eine allmähliche Qualitätsverschiebung, die nicht durch eine einzelne Änderung verursacht wird – beispielsweise wenn der Recall der Vektordatenbank durch das Hinzufügen weiterer Dokumente abnimmt oder der LLM-Anbieter sein Modell unbemerkt aktualisiert. Tägliche vollständige Läufe liefern Ihnen eine Qualitätszeitreihe, in der Trends sichtbar werden.
# Separate eval modes:
EVAL_CONFIGS = {
'pr_check': {
'test_cases': 'eval/test_set_core_100.json',
'target': 'staging',
'max_runtime_min': 8
},
'nightly': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'max_runtime_min': 30
},
'weekly_deep': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'include_pairwise': True,
'max_runtime_min': 90
}
}Alarmierung bei Qualitätsverschlechterung
Konfigurieren Sie Alarme, wenn Metriktrends Warn- und kritische Schwellenwerte überschreiten. Ein Rückgang der mittleren Korrektheit um 3 % in den vergangenen 7 Tagen löst eine Warnung aus. Ein Rückgang um 10 % in einem einzelnen Lauf löst sofort einen Alarm aus. Leiten Sie Warnungen an einen Slack-Kanal des Teams und kritische Alarme an PagerDuty weiter. Fügen Sie jeder Alarmnachricht die Regressionsanalyse, einen Link zum Evaluations-Dashboard und die Git-Blame-Informationen für die letzten Änderungen hinzu.
import httpx
def send_regression_alert(regression_report: dict, webhook_url: str):
regressions = regression_report['regressions']
blocks = [{
'type': 'section',
'text': {'type': 'mrkdwn', 'text': '*LLM Quality Regression Detected*'}
}]
for r in regressions:
blocks.append({
'type': 'section',
'text': {'type': 'mrkdwn',
'text': f'*{r["metric"]}*: {r["baseline"]} -> {r["current"]} ({r["delta_pct"]}%)'}
})
httpx.post(webhook_url, json={'blocks': blocks})Erweitern des Testdatensatzes
Erweitern Sie Ihren Testsatz kontinuierlich auf Grundlage echter Fehler im Produktivbetrieb. Wenn ein Benutzer eine fehlerhafte Antwort meldet, fügen Sie diese Frage (bei Bedarf anonymisiert) mit einer von Menschen geprüften erwarteten Antwort zum Testsatz hinzu. So stellt Ihre Evaluations-Suite tatsächliche Benutzeranforderungen statt hypothetischer Fälle dar. Behandeln Sie den Testsatz als lebendes Dokument und überprüfen Sie ihn vierteljährlich, um veraltete Fälle zu entfernen.
def add_to_test_set(question: str, reference_answer: str, category: str,
source: str, test_set_path: str):
import json, uuid
with open(test_set_path, 'r') as f:
test_set = json.load(f)
test_set['cases'].append({
'id': f'user_report_{uuid.uuid4().hex[:8]}',
'category': category,
'question': question,
'reference': reference_answer,
'source': source, # 'user_report', 'regression', 'manual'
'added': '2026-06-21'
})
with open(test_set_path, 'w') as f:
json.dump(test_set, f, indent=2)Visualisieren von Qualitätstrends im Zeitverlauf
Erstellen Sie ein einfaches Qualitäts-Dashboard, das Ihre wichtigsten Metriken im Zeitverlauf darstellt: mittlere Korrektheitsbewertung, Cache-Trefferrate, p95-Latenz und Kosten pro Anfrage. Verwenden Sie einen gleitenden Wochenmittelwert, um das Rauschen kleiner Stichproben zu glätten. Ein Trenddiagramm macht eine Qualitätsverschiebung sofort sichtbar – ein allmählicher Rückgang um 3 % über sechs Wochen ist in einzelnen Laufberichten unsichtbar, in einem Zeitreihendiagramm jedoch offensichtlich. Grafana oder sogar ein einfaches Python-Skript mit matplotlib eignen sich dafür gut.
import matplotlib.pyplot as plt
import pandas as pd
def plot_quality_trend(eval_history: list):
df = pd.DataFrame(eval_history)
df['date'] = pd.to_datetime(df['evaluated_at'])
df = df.sort_values('date')
# 7-day rolling average
df['score_ma7'] = df['mean_correctness'].rolling(window=7).mean()
plt.figure(figsize=(12, 4))
plt.plot(df['date'], df['mean_correctness'], alpha=0.3, label='Daily')
plt.plot(df['date'], df['score_ma7'], label='7-day avg', linewidth=2)
plt.axhline(y=4.0, color='r', linestyle='--', label='Min threshold')
plt.legend()
plt.title('LLM Answer Quality Over Time')
plt.savefig('quality_trend.png')Kurzer Test
Testen Sie Ihr Verständnis kontinuierlicher Evaluations-Pipelines für LLM-Anwendungen.
Zusammenfassung der Lektion
In dieser Lektion haben Sie gelernt: kontinuierliche Evaluations-Pipelines führen bei jedem PR und täglich automatisierte Qualitätsprüfungen aus, um Regressionen frühzeitig zu erkennen; die Regressionserkennung vergleicht aktuelle Bewertungen mit einer Baseline und blockiert die Bereitstellung, wenn die Qualität sinkt; und die Erweiterung des Testsatzes anhand echter Fehler stellt sicher, dass Ihre Evaluations-Suite auf tatsächlichen Benutzeranforderungen beruht. Als Nächstes klassifizieren wir Fehlermuster von Agents und entwickeln Strategien zur Fehlerbehebung.
Lerne Python mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 30
- Lektionen
- 120
Häufig gestellte Fragen
Ist die Lektion „Eine kontinuierliche Evaluationspipeline erstellen“ kostenlos?
Ja — der vollständige Text von „Eine kontinuierliche Evaluationspipeline erstellen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AI Engineering Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Eine kontinuierliche Evaluationspipeline erstellen“?
Integrieren Sie die LLM-as-Judge-Evaluation in Ihre CI/CD-Pipeline, damit jede Änderung an Prompts oder Modellen vor dem Deployment automatisch anhand einer Regressionstestsuite evaluiert wird. Du übst AI Engineering Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um AI Engineering Academy zu starten?
Keine Vorkenntnisse erforderlich. AI Engineering Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Eine kontinuierliche Evaluationspipeline erstellen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser AI Engineering Academy-Lektion Code schreiben und ausführen?
Ja. Jede AI Engineering Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Das LLM-as-Judge-Muster
- Punktuelle und paarweise Evaluierung
- Judge-Modelle mit menschlichen Bewertungen kalibrieren
- Eine kontinuierliche Evaluationspipeline erstellen