Praxis: Customer-Service-Bot evaluieren

Szenario

Ihr habt einen LLM-basierten Customer-Service-Bot für einen E-Commerce-Shop. Aufgabe: Quality systematisch messen und verbessern.

Schritt 1 — Goldset bauen

• 50 echte Kundenfragen aus dem letzten Monat sampeln
• Pro Frage: idealen Antwort-Text + Kategorie (Lieferung/Retoure/Produkt/Sonstiges) labeln
• Edge-Cases bewusst rein: Beleidigung, Sprachwechsel, ambivalent, kein Fall im FAQ

Schritt 2 — Metriken definieren

• Korrekt: Antwort enthält die echte Antwort (LLM-Judge)
• Höflich: Tone passt zur Marke (LLM-Judge mit Beispielen)
• Sicher: kein PII-Leak, keine Versprechen außerhalb der Policy (Regex + Judge)
• Latenz P95 < 3s
• Cost < 0.5 ct/Anfrage

Schritt 3 — Baseline-Run

• Aktueller Prompt v1 gegen Goldset → Score-Tabelle
• Beispiel: 76% korrekt, 91% höflich, 94% sicher, P95 = 2.1s, 0.4 ct

Schritt 4 — Hypothesen + Varianten

• v2: Few-Shot mit 5 Bestellungs-Beispielen → erwartet bessere Korrektheit
• v3: Format-Vorgabe (Erstantwort + nächste Schritte) → erwartet höhere CSAT
• v4: Sentiment-Erkennung vorab + adaptive Tone

Schritt 5 — Eval-Run

• v2: 84% korrekt (+8), Latenz +0.3s — ROI gut
• v3: 78% korrekt (+2), aber CSAT in A/B +5% — produktiv ausrollen
• v4: 81% korrekt aber 1.2s mehr Latenz, P95 ist out — verwerfen

Schritt 6 — Production-Monitoring

• Live-Logs in Langfuse
• 1% der Requests durch LLM-as-Judge laufen lassen → Online-Quality-Score
• Wöchentliches Review: was crasht? Goldset erweitern, neuer Iterationszyklus

Faustregeln

• Goldset: 50-200 Samples, alle Edge-Cases drin
• Eval-Lauf vor jedem Prompt-Deploy — automatisch in CI
• Modell-Update? Re-Eval. KEIN blindes Vertrauen, dass "neuer = besser"
• Live-Sampling: 1-5% der Production-Requests durch Judge