Eval & Tuning: Test-Cases, Rubriken, Regression

Ein Assistent ist erst dann wirklich brauchbar, wenn du weißt, wie gut er unter realen Bedingungen funktioniert – und ob er nach Änderungen stabil bleibt. Eval & Tuning heißt: mit Testfällen prüfen, nach klaren Kriterien bewerten, Versionen sichern und bei Updates Regressionen vermeiden.

1. Test-Cases: gezielt statt zufällig

Statt „einfach mal ausprobieren“ definierst du ein kleines, fixes Set an Testfällen pro Assistent.

Empfehlung: 5–10 Testfälle pro Assistent

Typen von Testfällen:

• Standardfall: typischer, sauber formulierter Use Case.

• Grenzfall/Lücke: Information fehlt → „Nicht in den Quellen“.

• Formatstress: komplizierter Input, Output muss dennoch korrekt formatiert sein (z. B. Tabelle oder JSON).

• Mehrdeutig: Frage mit Interpretationsspielraum – prüft Rückfragen-Verhalten.

• Versionskonflikt: zwei Quellen mit unterschiedlichen Datumsständen – prüft, ob der Assistent die neueste nutzt.

Beispiel (Q&A mit Zitierpflicht):

• TF1: „Welche radiale Toleranz hat Lager X?“ (Kerninfo vorhanden)

• TF2: „Wie oft sollte Lager X gewartet werden?“ (nicht in den Dokumenten → „Nicht in den Quellen“)

• TF3: Lange Freitext-Spezifikation, aus der eine Tabelle extrahiert werden soll.

2. Bewertungsrubrik (1–5) – kurz, aber klar

Für jeden Testfall vergibst du Bewertungen nach einer kleinen Rubrik. 1 = schlecht, 5 = sehr gut.

Rubrik-Vorschlag:

• Faithfulness (Quellentreue):
  1 = erfindet Fakten; Quellen fehlen/falsch
  3 = größtenteils korrekt, einzelne unsaubere Stellen
  5 = alle Aussagen durch Quellen gedeckt oder klar als „Nicht in den Quellen“ markiert

• Format-Treue:
  1 = Formatvorgaben ignoriert (kein JSON/Tabelle/Struktur)
  3 = kleinere Abweichungen (z. B. zusätzliche Sätze)
  5 = exakt im gewünschten Format; direkt weiterverarbeitbar

• Klarheit & Kürze:
  1 = geschwätzig, unklar, doppelt
  3 = verständlich, aber zu lang oder etwas diffus
  5 = prägnant, eindeutig, ohne Ballast

• Vollständigkeit:
  1 = wichtige Punkte fehlen
  3 = meiste Punkte abgedeckt, kleine Lücken
  5 = alle gefragten Punkte abgedeckt oder explizit als „Nicht in den Quellen“ markiert

Copy & Paste – Eval-Template je Testfall:

Testfall-ID: {TF1}
Beschreibung: {z. B. "Standard Q&A zu Toleranz Lager X"}
Erwartung (High-Level): {z. B. "Konkreter Wert + Quellenblock"}
 
Bewertung (1–5):
- Faithfulness: {…}
- Format-Treue: {…}
- Klarheit & Kürze: {…}
- Vollständigkeit: {…}
 
Kommentar:
- {1–3 Sätze, was gut ist / was verbessert werden muss}

3. Tuning: zielgerichtete Anpassung statt „Herumspielen“

Wenn ein Assistent in einem Kriterium schwach ist, passt du gezielt den System-Prompt oder ein Pattern an – nicht alles auf einmal.

Typische Probleme und Tuning-Hebel:

• Halluzinationen / unbelegte Aussagen:
  Hebel: Zitierpflicht im System-Prompt verschärfen; „Keine Spekulation; Lücken = ‚Nicht in den Quellen‘“ explizit; Beispiel hinzufügen.

• Format bricht (JSON/Tabelle):
  Hebel: Output-Format-Hinweis verstärken („Nur JSON…“, Beispielobjekt im Prompt); Zusatztext verbieten.

• Zu lang/zu vage:
  Hebel: Wortlimit setzen („max. 150–200 Wörter“), kurze Sätze verlangen, Ziel enger definieren.

• Unvollständige Antworten:
  Hebel: im Prompt klar auflisten, was beantwortet werden muss; „Falls etwas fehlt → ‚Nicht in den Quellen‘“ ergänzen.

Vorgehen:
1) Schwachpunkt identifizieren (Rubrik-Wert < 4).
2) 1–2 Zeilen im System-Prompt/Pattern anpassen.
3) Nur die relevanten Testfälle erneut laufen lassen.
4) Eval-Werte vergleichen.

4. System-Prompt sichern, bevor du etwas Größeres änderst

Bevor du größere Änderungen am System-Prompt machst, solltest du immer den bisherigen Zustand extern sichern. So kannst du jederzeit zurückspringen, wenn ein Tuning-Versuch nach hinten losgeht.

Empfehlung:

• Vor jeder größeren Anpassung:

• System-Prompt komplett per Copy & Paste in ein externes Dokument einfügen (z. B. Google Doc, Word, Notion).

• Kurz datieren und beschriften: „Version vom 2025-11-18 – vor Änderung X“.

Mini-Template für deine Sicherung:

Assistent: {Name}
Version: {Datum, z. B. 2025-11-18}
Änderungsgrund: {z. B. "Zitierpflicht verschärfen", "Format strikt auf JSON"}
 
Gesicherter System-Prompt:
{kompletter Text}

Vorteil:

• Du kannst schnell auf die letzte funktionierende Version zurückrollen, wenn Eval/Regression zeigt, dass die Änderung die Qualität verschlechtert.

5. Regression: nach Änderungen nichts kaputt machen

Jede Änderung am System-Prompt kann Nebenwirkungen haben. Regression bedeutet: alte Testfälle bleiben auch nach Updates stabil.

Mini-Regression-Set:

• 3–5 repräsentative Testfälle (Standard, Lücke, Formatstress).

• Nach jeder größeren Änderung kurz durchlaufen lassen.

• Ergebnisse mit vorherigen Bewertungen vergleichen.

Copy & Paste – Regression-Notiz:

Assistent: {Name}
Änderung am: {Datum}
Was wurde geändert?
- {z. B. "Zitierpflicht verschärft; Wortlimit reduziert"}
 
Regression-Tests:
- TF1: {Score alt} → {Score neu} (Kommentar)
- TF2: {Score alt} → {Score neu}
- TF3: {Score alt} → {Score neu}
 
Ergebnis:
- {ok / weitere Anpassungen nötig}

6. Wie viel Eval ist „genug“?

Für einen GHH-Assistenten reicht in der Praxis:

• 5–10 definierte Testfälle

• 1–2 Tuning-Runden, bis die wichtigsten Kriterien stabil bei 4–5 liegen

• Regressionstest bei jeder größeren System-Prompt-Änderung (und vorherige Prompt-Version extern gesichert)

Kurz-Check: Eval & Tuning für deinen Assistenten

• Gibt es klar definierte Testfälle (inkl. Lücke/Formatstress)?

• Nutzt du eine einfache 1–5-Rubrik (Faithfulness, Format, Klarheit, Vollständigkeit)?

• Sicherst du den aktuellen System-Prompt vor größeren Änderungen extern (Copy & Paste, Datum)?

• Prüfst du nach Änderungen ein kleines Regression-Set?