Evals dla agentów AI: ocena sumaryzacji

Evals dla agentów AI: systematyczne podejście do oceny jakości podsumowań spotkań

Agenty sztucznej inteligencji do przetwarzania spotkań często generują niestabilne wyniki: halucynacje, pominięte zadania, nadmiarowy tekst. Evals rozwiązują ten problem, dostarczając obiektywne metryki jakości. Są to testy dla niedeterministycznych systemów, analogiczne do testów jednostkowych w tradycyjnym kodzie. Odpowiadają na kluczowe pytania: gdzie agent się psuje, czy ulepszył się po zmianach i czy nie doszło do regresji.

W artykule omówiono typy evals, analizę błędów, code-based assertions i metryki dla podsumowań spotkań. Podejście opiera się na rekomendacjach ekspertów, takich jak Hamel Husain i Eugene Yan.

Typy evals: od prostych testów do LLM-as-Judge

Eval to funkcja f(wyjście) → wynik, oceniająca wyjście agenta. Trzy poziomy złożoności:

• Code-based assertions: Deterministyczne testy formalnych właściwości (długość, struktura, słowa kluczowe). Szybkie, bezpłatne, ale ograniczone.
• Human evaluation: Nuansowa ocena przez człowieka. Dokładna, ale kosztowna i nieskalowalna.
• LLM-as-Judge: LLM ocenia według kryteriów. Skalowalne, tanie, wymaga walidacji.

Złota zasada — łączyć wszystkie typy. Code-based dla każdego zapytania, LLM-as-Judge na próbkach, human do kalibracji.

Dla podsumowania spotkań definiujemy metryki według priorytetu:

• Faithfulness: Każde stwierdzenie potwierdzone transkryptem.
• Action item accuracy: Pełne zadania z właścicielem i terminem.
• Completeness: Pokrycie kluczowych tematów.
• Conciseness: Długość <30% transkryptu, gęstość 0.15 encji/token.
• Coherence: Logiczna struktura.

Error analysis: podstawa efektywnych evals

Ręczna analiza błędów — pierwszy krok, poprzedzający automatyzację. Bez niej evals są bezużyteczne: zespoły budują metryki, ignorując rzeczywiste problemy.

Proces error analysis

Zbierz 20–50 par „transkrypt → podsumowanie” z produkcji lub syntetyki. Czytaj, notuj problemy bez klasyfikacji:

• Halucynacja: „Masia zajmie się refaktoryzacją” zamiast „może przejrzeć”.
• Pominięcie action items na końcu długiego transkryptu.
• Niewystarczająca kompresja: podsumowanie dłuższe niż transkrypt.

Grupuj w taksonomię failure modes:

FAITHFULNESS FAILURES:

• Halucynacja zobowiązań.
• Błędna atrybucja.

COMPLETENESS FAILURES:

• Utrata action items.
• Pominięcie decyzji.

CONCISENESS FAILURES:

• Przerzucanie zamiast podsumowania.

Policz częstotliwość: 2–3 główne błędy określają priorytet evals. Czas: pół dnia–tydzień, ROI maksymalny.

Code-based assertions: szybkie testy pass/fail

Zasada: binary pass/fail, bez gradacji 1–5. Wymusza precyzyjne określenie akceptowalności.

Przykłady dla podsumowania spotkań:

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[] = [];
  
  // Compression ratio: summary < 30% transcript
  const transcriptTokens = transcript.text.split(' ').length;
  const summaryTokens = summary.text.split(' ').length;
  const ratio = summaryTokens / transcriptTokens;
  results.push({
    name: 'Compression ratio',
    pass: ratio < 0.3,
    reason: `Ratio: ${ratio.toFixed(2)}`
  });
  
  // Action items have owner and deadline
  const aiComplete = summary.action_items.every(ai => ai.owner && ai.deadline);
  results.push({
    name: 'Action items completeness',
    pass: aiComplete,
    reason: aiComplete ? 'OK' : 'Missing owner/deadline'
  });
  
  return results;
}

Dodatkowe assertions:

• Obecność sekcji action_items.
• Brak small talk w podsumowaniu.
• Poprawny format JSON structured output.

LLM-as-Judge i zaawansowane scorers

Dla nuansowych metryk użyj LLM-as-Judge z promptami dla faithfulness, completeness. W Mastra 16 scorers: faithfulness, completeness, conciseness.

Przykład prompta dla faithfulness:

Oceń faithfulness podsumowania względem transkryptu. Każde stwierdzenie musi być potwierdzone. Wynik 0–1.
Transkrypt: [text]
Podsumowanie: [text]
Wynik:```

Zintegruj w CI: uruchamiaj na 50 test cases przed wdrożeniem. Metryka ulepszenia: faithfulness z 0.64 do 0.78.

**Co jest ważne:**
- Zacznij od error analysis: 2–3 failure modes pokrywają 60% problemów.
- Łącz code-based (szybko), LLM-as-Judge (skala), human (walidacja).
- Priorytet: faithfulness > action accuracy > completeness.
- Binary pass/fail dla jasnych decyzji.
- Automatyzuj w CI dla systematycznych ulepszeń.

— Editorial Team