Evaluierungen für AI-Agenten: Zusammenfassungs-Bewertung

Bewertung von KI-Agenten: Systematischer Ansatz zur Qualität von Meeting-Zusammenfassungen

KI-Agenten, die Meetings bearbeiten, liefern oft inkonsistente Ergebnisse: Halluzinationen, verpasste Aufgaben und aufgeblähte Texte. Evals beheben das, indem sie objektive Qualitätsmetriken liefern. Das sind Tests für nicht-deterministische Systeme – ähnlich wie Unit-Tests im klassischen Code. Sie beantworten zentrale Fragen: Wo versagt der Agent? Hat er sich nach Änderungen verbessert? Wurde etwas Funktionierendes kaputt gemacht?

Dieser Artikel behandelt Eval-Typen, Fehleranalysen, codebasierte Assertions und Metriken für Meeting-Zusammenfassungen. Der Ansatz basiert auf Experten wie Hamel Husain und Eugene Yan.

Eval-Typen: Von einfachen Checks bis LLM-as-Judge

Ein Eval ist eine Funktion f(output) → score, die die Ausgabe des Agents bewertet. Drei Komplexitätsstufen:

• Codebasierte Assertions: Deterministische Prüfungen auf formale Eigenschaften (Länge, Struktur, Keywords). Schnell, kostenlos, aber begrenzt.
• Manuelle Bewertung: Nuanciertes menschliches Urteil. Genau, aber teuer und nicht skalierbar.
• LLM-as-Judge: LLM-Bewertungen basierend auf Kriterien. Skalierbar, günstig, braucht Validierung.

Goldene Regel: Alle Typen kombinieren. Codebasiert bei jeder Anfrage, LLM-as-Judge auf Stichproben, manuell zur Kalibrierung.

Für Meeting-Zusammenfassungen Metriken nach Priorität definieren:

• Treue (Faithfulness): Jede Aussage durch das Protokoll gedeckt.
• Genauigkeit von Action Items: Vollständige Aufgaben mit Zuständigen und Frist.
• Vollständigkeit: Abdeckung zentraler Themen.
• Kürze: Länge <30 % des Protokolls, Dichte 0,15 Entitäten/Token.
• Kohärenz: Logische Struktur.

Fehleranalyse: Grundlage effektiver Evals

Manuelle Fehleranalyse ist der erste Schritt vor der Automatisierung. Ohne sie sind Evals nutzlos: Teams bauen Metriken, die reale Probleme ignorieren.

Ablauf der Fehleranalyse

20–50 Protokoll → Zusammenfassung-Paare aus Produktion oder Synthetik sammeln. Durchlesen, Probleme protokollieren, ohne zu klassifizieren:

• Halluzination: „Maria übernimmt Refactoring“ statt „könnte sich anschauen“.
• Fehlende Action Items am Ende langer Protokolle.
• Schlechte Kompression: Zusammenfassung länger als Protokoll.

In eine Taxonomie von Fehlermodi gruppieren:

TREUE-FEHLER:

• Erfundene Zusagen.
• Falsche Zuordnung.

VOLLSTÄNDIGKEITS-FEHLER:

• Verlorene Action Items.
• Verpasste Entscheidungen.

KÜRZE-FEHLER:

• Nacherzählen statt Zusammenfassen.

Häufigkeiten zählen: 2–3 Top-Fehler legen Eval-Prioritäten fest. Zeitaufwand: Halber Tag bis eine Woche, maximaler ROI.

Codebasierte Assertions: Schnelle Pass/Fail-Checks

Prinzip: Binär Pass/Fail, keine 1–5-Skalen. Zwingt zu klaren Akzeptanzkriterien.

Beispiele für Meeting-Zusammenfassungen:

interface Transcript {
  text: string;
  duration_minutes: number;
  participants: string[];
}

interface Summary {
  text: string;
  action_items: ActionItem[];
  decisions: string[];
}

interface ActionItem {
  description: string;
  owner?: string;
  deadline?: string;
}

interface AssertionResult {
  name: string;
  pass: boolean;
  reason: string;
}

function runAssertions(transcript: Transcript, summary: Summary): AssertionResult[] {
  const results: AssertionResult[] = [];
  
  // Kompressionsrate: Zusammenfassung < 30% Protokoll
  const transcriptTokens = transcript.text.split(' ').length;
  const summaryTokens = summary.text.split(' ').length;
  const ratio = summaryTokens / transcriptTokens;
  results.push({
    name: 'Kompressionsrate',
    pass: ratio < 0.3,
    reason: `Rate: ${ratio.toFixed(2)}`
  });
  
  // Action Items mit Zuständigem und Frist
  const aiComplete = summary.action_items.every(ai => ai.owner && ai.deadline);
  results.push({
    name: 'Vollständigkeit Action Items',
    pass: aiComplete,
    reason: aiComplete ? 'OK' : 'Fehlender Zuständiger/Frist'
  });
  
  return results;
}

Zusätzliche Assertions:

• Vorhandensein von Action-Items-Abschnitt.
• Kein Smalltalk in der Zusammenfassung.
• Valides JSON für strukturierte Ausgabe.

LLM-as-Judge und fortgeschrittene Scorers

Für nuancierte Metriken LLM-as-Judge mit Prompts für Treue, Vollständigkeit nutzen. Mastra bietet 16 Scorers: Treue, Vollständigkeit, Kürze.

Beispiel-Prompt für Treue:

Bewerten Sie die Treue dieser Zusammenfassung zum Protokoll. Jede Aussage muss gestützt sein. Score 0–1.
Protokoll: [text]
Zusammenfassung: [text]
Score:```

In CI integrieren: Auf 50 Testfällen vor Deployment laufen. Verbesserungsmetrik: Treue von 0,64 auf 0,78.

**Wichtige Erkenntnisse:**
- Mit Fehleranalyse starten: 2–3 Fehlermodi decken 60 % der Probleme ab.
- Kombinieren: Codebasiert (schnell), LLM-as-Judge (skalierbar), manuell (Validierung).
- Prioritäten: Treue > Action-Genauigkeit > Vollständigkeit.
- Binär Pass/Fail für klare Entscheidungen.
- In CI automatisieren für systematische Fortschritte.

— Editorial Team