Multi-Turn-LLM-Evaluierung: 5 Metriken, 3 Frameworks, 1 Workflow

Multi-Turn-LLM-Evaluierung: 5 Metriken, 3 Frameworks, 1 Workflow

Die Multi-Turn-LLM-Evaluierung ist der einzige Weg, den Amnesie-Bug in Runde 8 zu fangen: Der Nutzer hat seine Bestellnummer in Runde 3 genannt, und der Bot fragt erneut danach. Jede einzelne Runde bestand für sich genommen; das Gespräch ist trotzdem gescheitert. DeepEval 4.0 und RAGAS 0.4 haben genau dafür eigene Conversational-Eval-APIs eingeführt, und nach zwei Eval-Vorfällen in unserer eigenen Pipeline bei Techsy folgen hier die fünf Metriken, drei Frameworks und ein Workflow für den Einstieg.

Die wichtigsten Punkte

• Multi-Turn-Evaluierung bewertet ganze Gespräche, nicht isolierte Eingabe-Ausgabe-Paare.
• Modelle an der Spitze von Single-Turn-Benchmarks verschlechtern sich über die Gesprächsrunden messbar.
• Starten Sie mit vier Metriken: Vollständigkeit, Wissensspeicherung, Rollentreue, Rundenrelevanz.
• DeepEval, RAGAS und Langfuse lösen Multi-Turn-Evals unterschiedlich; die Framework-Tabelle unten vergleicht sie.

Warum Single-Turn-Scores Sie täuschen

Single-Turn-Evals bewerten jeweils ein Eingabe-Ausgabe-Paar und sehen deshalb keine Fehler, die erst über mehrere Runden auftreten: Vergessen, Widersprüche, Themenabweichung. Ein Modell kann einen starken Benchmark-Wert erzielen und trotzdem den Faden eines laufenden Gesprächs verlieren. Laban et al. dokumentieren das in LLMs Get Lost In Multi-Turn Conversation, 353 Zitierungen: Die Leistung sinkt in Multi-Turn-Settings selbst dann, wenn die Single-Turn-Ergebnisse gesund aussehen.

Das Kernproblem ist der Nichtdeterminismus: Die n-te Antwort hängt von allen n-1 vorherigen Runden ab, daher verhalten sich identische Prompts je nach Verlauf unterschiedlich. Ein Datensatz aus isolierten Paaren prüft diese Abhängigkeit nie. Der arXiv-Survey Evaluating LLM-based Agents for Multi-Turn Conversations, ein PRISMA-Review von rund 250 Quellen, teilt das Feld in Was wird evaluiert (Kontextverwaltung, Planung, Kohärenz) und Wie (Metriken, LLM-Judges, menschliche Prüfung). Beide Achsen fehlen in einer Single-Turn-Suite.

Nichts davon macht Ihren Single-Turn-Stack wertlos. Wenn Sie Single-Turn-Metriken wie BLEU, ROUGE und G-Eval einsetzen, behalten Sie sie für das, was sie gut messen: Formatkonformität, Toxizität, Faktenabruf bei einem festen Prompt. Hören Sie nur auf, sie als Gesundheitscheck für die Gespräche zu lesen, die Ihre Nutzer tatsächlich führen.

Unsere Interpretation dieser Studien, in einem Satz:

Single-Turn-Evals messen die Antwort, Multi-Turn-Evaluierung misst das Gespräch, und ein Modell, das Runde eins meistert, kann in Runde fünf bereits verloren sein.

Was ist Multi-Turn-LLM-Evaluierung? Die zwei Evaluierungsmodi

Multi-Turn-LLM-Evaluierung bedeutet, ein ganzes Gespräch oder Fenster daraus zu bewerten statt isolierter Prompt-Antwort-Paare. Sie prüft, ob das Modell den Kontext behalten, die Rolle gehalten und das Problem des Nutzers über die Runden hinweg gelöst hat. Zwei Modi leisten die Arbeit: Scoring auf Gesprächsebene und Gleitfenster-Scoring auf Rundenebene (Sliding Window), und die meisten Teams fahren beide.

Scoring auf Gesprächsebene übergibt dem Judge das vollständige Transkript und stellt eine Frage: War dieses Gespräch erfolgreich? Es erkennt vorzeitige Abschlüsse und ungelöste Schleifen, denn nur der ganze Verlauf zeigt, dass der Nutzer seine Rückerstattung nie bekommen hat. Die Schwäche ist die Granularität: „fehlgeschlagen" bei einem 12-Runden-Verlauf sagt nicht, wo es gebrochen ist.

Gleitfenster-Scoring auf Rundenebene schiebt ein Fenster von N Runden über das Transkript, ein Urteil pro Fenster. Ein Fenster von 3 über einem 10-Runden-Gespräch ergibt 8 Urteile, die an Regionen des Chats gebunden sind; „fehlgeschlagen" kommt also mit Koordinaten: Der Bruch passierte in den Runden 6 bis 8. Das Diagramm oben in diesem Beitrag zeigt beide Modi an einem Verlauf: eine Klammer für das Gesprächsurteil, einen gleitenden Rahmen für die Fensterurteile.

Nutzen Sie das Scoring auf Gesprächsebene als Gate und das Fenster-Scoring, um Fehler zu lokalisieren, wenn es anschlägt. Der Multi-Turn-Evaluierungs-Guide von DeepEval fasst die Arbeitseinheit als Szenario auf, nicht als Eingabe-Ausgabe-Paar (der Typ ConversationalGolden): Sie testen eine Situation, keine Frage.

Beispiel zur Veranschaulichung (synthetisch; zeigt die Mechanik, keinen echten Lauf): ein Gleitfenster von 3 über einem 8-Runden-Chat zu einer Retoure.

Turn 1  user:      I want to return an order that arrived damaged.
Turn 2  assistant: Sorry about that. Can you share the order number?
Turn 3  user:      It's #4471.
Turn 4  assistant: Got it. Damaged on arrival, or after use?
Turn 5  user:      On arrival. The screen was cracked.
Turn 6  assistant: Understood. Replacement or refund?
Turn 7  user:      Refund. How long does that take?
Turn 8  assistant: 3-5 business days. Can you share the order number again?

Urteil auf Gesprächsebene: fehlgeschlagen. Fünf von sechs Fenstern bestanden, und der Verlauf brach trotzdem an der Wissensspeicherung, genau dem Fehler, den eine Single-Turn-Suite nie ans Licht bringt.

Welche Multi-Turn-Metriken zählen? Diese 5

Starten Sie mit vier Metriken: Gesprächsvollständigkeit, Wissensspeicherung, Rollentreue und Rundenrelevanz. Ergänzen Sie eine fünfte, ein eigenes Kriterium (G-Eval in DeepEval, AspectCritic in RAGAS), für alles, was Ihr Produkt nicht falsch machen darf. Die ersten vier sind zwischen Projekten übertragbar; die fünfte ist dort, wo Ihre Fehlermodi leben.

1. Gesprächsvollständigkeit. Wurde das Ziel des Nutzers gelöst, oder hat der Bot zu früh den Sieg erklärt? Ihr Detektor für vorzeitige Abschlüsse.
2. Wissensspeicherung. Merkt sich das Modell Fakten, die früher im Verlauf genannt wurden? Der Amnesie-Bug in Runde 8 ist ein Versagen der Wissensspeicherung.
3. Rollentreue. Bleibt der Assistent in seiner Persona und lehnt Anfragen außerhalb des Geltungsbereichs ab? Kritisch bei einer Compliance-Grenze.
4. Rundenrelevanz. Ist jede Antwort angesichts der vorherigen Runden beim Thema? Erkennt Abweichungen und Schleifen.
5. Ein eigenes Kriterium. Eine Regel in Klartext für Ihre Domäne: „Nenne nie einen Preis, der von der Preisliste abweicht." DeepEval implementiert das als ConversationalGEval; RAGAS als AspectCritic.

Der DeepEval-Metriken-Guide definiert jede mit lauffähigen Klassen, aber die Konzepte sind framework-neutral: Die Tabelle gilt auch, wenn Sie Ihren Judge selbst bauen.

Ein eigenes Kriterium liest sich wie ein Satz:

criterion "price_accuracy":
  question: Does the assistant quote prices matching the official
            list, and self-correct when the user flags a mismatch?
  scale: 0 (wrong, no correction) to 1 (correct throughout)
  verdict: pass if score >= 0.5

Dieselbe Regel als echter DeepEval-Code:

from deepeval.metrics import ConversationalGEval
from deepeval.test_case import LLMTestCaseParams

price_accuracy = ConversationalGEval(
    name="Price Accuracy",
    criteria=(
        "Does the assistant quote prices that match the official "
        "price list, and correct itself immediately when the user "
        "points out a discrepancy?"
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
    ],
    threshold=0.5,
)

DeepEval vs. RAGAS vs. Langfuse: Welches Framework passt?

Alle drei evaluieren Multi-Turn-Gespräche, aber ihre Evaluierungseinheit unterscheidet sich: DeepEval simuliert Szenarien offline, RAGAS scored Aspekte von Gesprächen, die Sie bereits haben, und Langfuse evaluiert echte Produktions-Traces. Wählen Sie nach der Herkunft Ihrer Gespräche, nicht nach der Feature-Anzahl.

Zuerst die framework-neutrale Logik, damit der Vendor-Code darunter portabel ist:

for scenario in scenario_set:
    transcript = run_chatbot(scenario, max_turns=10)
    for window in sliding_windows(transcript, 3):
        scores.append(judge(window, criteria))
    scores.append(judge(transcript, completeness))
fail_if(mean(scores) < baseline - tolerance)

DeepEval: Szenarien und ein voll ausgestatteter Simulator

DeepEval ist das einzige Framework mit einem erstklassigen Gesprächssimulator: Beschreiben Sie ein Szenario und eine Persona, und er spielt den Nutzer gegen Ihren Bot. Der Multi-Turn-Guide ist die Standardreferenz für das Szenario-statt-Paare-Muster. Confident AI verkauft das gehostete Dashboard; unser Confident-AI-Review deckt ab, was die Bezahlschicht ergänzt.

from deepeval.dataset import ConversationalGolden
from deepeval.synthesizer import ConversationSimulator
from deepeval.metrics import (
    ConversationCompletenessMetric,
    KnowledgeRetentionMetric,
)
from deepeval import evaluate

scenario = ConversationalGolden(
    additional_context="Customer wants to return a damaged order",
    user_persona="Impatient customer, second contact this week",
)
simulator = ConversationSimulator(model="gpt-4o-mini", max_turns=10)
test_case = simulator.simulate(scenario, your_chatbot_fn)

evaluate(
    test_cases=[test_case],
    metrics=[
        ConversationCompletenessMetric(threshold=0.7),
        KnowledgeRetentionMetric(threshold=0.7),
    ],
)

RAGAS: Fehleranalyse-getrieben, Aspekt für Aspekt

RAGAS startet bei Gesprächen, die Sie bereits haben, und scored sie Aspekt für Aspekt. Das Multi-Turn-How-to gehört zur manuellen Fehleranalyse: gescheiterte Chats lesen, einen AspectCritic pro Fehlermodus schreiben, scoren.

from ragas.dataset_schema import MultiTurnSample
from ragas.metrics import AspectCritic
from ragas.llms import llm_factory

user_input = [
    {"role": "user", "content": "Can I return a damaged order?"},
    {"role": "assistant", "content": "Yes, within 30 days."},
    {"role": "user", "content": "It arrived broken. Do I pay shipping?"},
    {"role": "assistant", "content": "No, we cover it."},
]
sample = MultiTurnSample(user_input=user_input)

critic = AspectCritic(
    name="policy_consistency",
    definition="Does the assistant stay consistent with the stated return policy across all turns? Answer yes or no.",
    llm=llm_factory("gpt-4o-mini"),
)
score = await critic.multi_turn_ascore(sample)  # binary 0 or 1

Langfuse: N+1-Evaluierung auf echten Traces

Langfuse geht den umgekehrten Weg: Tracer zuerst. Das N+1-Cookbook evaluiert den Trace jeder Runde plus das Gespräch als Ganzes, auf Produktions-Traffic statt auf Simulationen. Wenn Sie die Observability-Schicht noch auswählen, deckt unser Vergleich Langfuse vs. LangSmith diese Entscheidung ab.

Unser Urteil, ohne Zaunpfahl: Für ein neues Chatbot-Projekt starten Sie mit DeepEval. Der Simulator lässt Sie Regressionen gaten, bevor Sie Produktions-Traffic haben, genau dann, wenn Sie Tests am nötigsten brauchen. Ergänzen Sie Langfuse, sobald echte Verläufe existieren; greifen Sie zu RAGAS, wenn Ihr Team lieber gescheiterte Gespräche liest und die Funde in Code gießt.

Wie kommen Sie von der Fehleranalyse zur Automatisierung?

Durch die richtige Reihenfolge. Lesen Sie 20-30 echte Gespräche, labeln Sie Fehlermodi von Hand, schreiben Sie binäre Bestanden/Fehlgeschlagen-Checks für die offensichtlichen, automatisieren Sie diese, und ergänzen Sie erst dann LLM-Judge-Metriken für den subjektiven Rest. Hamel Husain argumentiert für genau diese Reihenfolge: zuerst manuelle Fehleranalyse und binäre Entscheidungen, denn ein Check, den Sie erklären können, schlägt einen Score, den Sie nicht erklären können.

Binär vor Judge: Die Reihenfolge, die uns gerettet hat

Das ist kein Chatbot-Benchmark, den wir gefahren haben; es ist unsere Interpretation desselben Musters in unserer eigenen Content-Pipeline, die bei jeder Prompt- und Tooling-Änderung Eval-gegatete Regressionschecks fährt. Zwei Vorfälle haben die Reihenfolge für uns bewiesen.

Am 2026-06-13 erzeugte ein Republish-Bug neue lokalisierte Slugs und lieferte 54 doppelte Live-Dokumente aus. Wir haben sie am 2026-07-05 gefunden und offline genommen (Backup unter techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Der Fix war kein klügeres Modell; es war ein deterministischer Pre-Publish-Check: das existierende Dokument über den kanonischen Post plus Sprache auflösen, bevor irgendetwas erzeugt wird. Ein binäres Gate.

Zweiter Vorfall: Übersetzer-LLMs geben gelegentlich ASCII statt Unicode aus und machen aus „karşılaştırma" ein „karsilastirma". Kein Judge nötig; ein Grep-Gate fängt es:

grep -cP '[çşğüöıİŞÇĞÜÖ]' file.md   # must be > 0

Beide wurden von Checks gefangen, die Bruchteile eines Cents kosten und exakt ausgeben, warum sie fehlgeschlagen sind. Übertragen auf Multi-Turn-Evals: „Hat der Bot erneut nach einem Feld gefragt, das der Nutzer schon genannt hat?" ist ein String-Match gegen das Transkript, kein Judge-Call. Fahren Sie zuerst günstige deterministische Gates; sie fangen die hässlichen Fehler, bevor Ihr teurer Judge überhaupt läuft.

Wann ein LLM-Judge wirklich das richtige Werkzeug ist

Judges verdienen ihre Token-Kosten bei Kriterien, die sich nicht auf eine Regel reduzieren lassen: „War der Ton angemessen entschuldigend?", „Passte die Lösung zur Situation?" Wenn Sie eine Assertion schreiben können, schreiben Sie eine Assertion. Eine Rubrik voller Ermessensfragen ist Judge-Territorium.

Die Linie, zu der wir immer wieder zurückkehren:

Starten Sie mit binären Bestanden/Fehlgeschlagen-Checks, die Sie einem Teamkollegen erklären können, und ergänzen Sie LLM-Judges nur für das, was sich nicht auf eine Regel reduzieren lässt.

Wie simulieren Sie Gespräche in großem Maßstab, und was kostet Judging?

Simulieren Sie aus Szenarien, nicht aus exportierten Logs. Szenarien testen, was passieren könnte; Logs zeigen nur, was Ihr aktuelles System bereits zugelassen hat. Die Anleitung von DeepEval warnt, dass historische Gespräche vom System geprägt sind, das sie erzeugt hat, und Benchmarks dagegen den Status quo einzementieren.

Szenarien, keine Transkripte

Schreiben Sie jedes Szenario als Ziel plus Persona: „ungeduldiger Kunde, der eine beschädigte Bestellung zurückgibt", „Nutzer, der mitten in der Buchung seine Meinung ändert". Setzen Sie ein Rundenlimit (10 ist vernünftig) und eine Stoppbedingung: Ziel erreicht, Nutzer bricht ab, oder Limit erreicht. DeepEval empfiehlt mindestens 20 vielfältige Szenarien über die primären Use Cases, Edge Cases und fehleranfälligen Situationen; darunter misst Ihre Suite Anekdoten.

Adversariale Personas

Nehmen Sie Personas auf, die den Bot kaputtzumachen versuchen: ein wütender Nutzer, der eskaliert, ein verwirrter Nutzer, der sich selbst widerspricht, ein Injection-Nutzer, der in Runde 4 Anweisungen einschmuggelt. Multi-Turn-Injection ist eine eigene Disziplin; unser Guide zu LLM-Guardrails deckt die Verteidigungsschicht ab, die zu diesen Tests gehört, und das Simulations-Cookbook von Langfuse zeigt die Nutzer-Simulator-Schleife.

Was 100 evaluierte Gespräche kosten

Jede Zahl unten ist eine Schätzung aus genannten Token-Zahlen und öffentlichen Preisen, keine Messung von uns. Die Rechnung ist der Punkt: Setzen Sie Ihre eigenen Zahlen ein.

Unter einem Dollar für 100 vollständig gejudgte Gespräche. Ein teurerer Judge verschiebt das um das 10-50-Fache, und die Taktiken aus unserem Guide LLM-API-Kosten senken greifen: Kriterientext cachen, Fenster batchen, das günstige Modell für binäre Gates nutzen.

Ein 6-Schritte-Workflow für Multi-Turn-Evals

Die Schleife läuft so: Szenarien aus echten Fehlern definieren, vier Kernmetriken plus eine eigene wählen, mindestens 20 Szenarien simulieren, die aktuelle Version baselinen, Regressionen in der CI gaten und Produktionsfehler zurück in den Szenario-Satz speisen.

1. Szenarien aus Fehlern definieren. Lesen Sie 20-30 Transkripte (oder schreiben Sie sie vor dem Launch aus Support-Tickets). Jedes Szenario bekommt ein Ziel, eine Persona und ein Rundenlimit. Verantwortlich: Sie und Hamels Fehleranalyse-zuerst-Methode.
2. Vier Metriken wählen, eine eigene. Vollständigkeit, Wissensspeicherung, Rollentreue, Rundenrelevanz und ein ConversationalGEval oder AspectCritic für den teuren Fehler Ihrer Domäne.
3. Simulieren. Fahren Sie mindestens 20 Szenarien inklusive des adversarialen Sets. Verantwortlich: DeepEvals ConversationSimulator oder das Simulations-Cookbook von Langfuse.
4. Die aktuelle Version baselinen. Protokollieren Sie die Mittelwerte pro Metrik über 3 Läufe, denn Modelle sind nichtdeterministisch und ein einzelner Lauf ist Rauschen. Verantwortlich: Ihr Eval-Skript, Ergebnisse ins Repo committen.
5. Regressionen in der CI gaten. Setzen Sie einen Schwellwert pro Metrik und lassen Sie den Build bei einer Regression jenseits der Toleranz fehlschlagen:

# ci/multi-turn-eval-gate.sh
set -euo pipefail
python eval/run_multi_turn.py --scenarios eval/scenarios.yaml --out results.json
SCORE=$(jq -r '.aggregate.completeness' results.json)
BASELINE=0.82
TOLERANCE=0.03
if (( $(echo "$SCORE < $BASELINE - $TOLERANCE" | bc -l) )); then
  echo "FAIL: completeness $SCORE below baseline $BASELINE"
  exit 1
fi

1. Produktionsverläufe monitoren. Gruppieren Sie Live-Traces nach Verlauf, evaluieren Sie asynchron und machen Sie aus jedem scheiternden Verlauf ein neues Szenario. Verantwortlich: Langfuse oder Ihr Tracer; unsere Guides zu KI-Agenten in Produktion evaluieren und KI-Observability decken die Monitoring-Hälfte ab.

Die Suite ist nie fertig: Schritt 6 speist Schritt 1, und der Szenario-Satz wächst mit jedem Produktionsfehler, den Sie fangen.

Wie evaluieren Sie Ton über Sprachen hinweg?

Eine auf englischen Daten trainierte Rollentreue-Metrik lässt ein türkisches oder japanisches Transkript bestehen, das ein Muttersprachler als unhöflich empfindet, denn das Höflichkeitsregister ist sprachspezifisch. Ihrer englischen Rubrik fehlen dafür die Worte. Der Fix: ein Aspekt-Kriterium pro Register-Erwartung, geschrieben pro Sprache, nicht eine globale Ton-Metrik.

Ein Kriterium pro Register

Unsere Interpretation des AspectCritic-Musters von RAGAS, erweitert aus dem Betrieb einer 23-Sprachen-Pipeline, kein publiziertes Testergebnis:

English:  "Is the assistant's tone friendly but professional?"
Turkish:  "Does the assistant use formal 'siz' address consistently,
           and avoid casual verb forms with an upset customer?"
Japanese: "Does the assistant keep keigo (polite form) throughout,
           including the apology at the resolution turn?"

Jedes Kriterium ist ein eigener binärer Critic auf demselben Transkript. Wir haben keine sprachübergreifenden Ton-Scores veröffentlicht und würden einem Artikel, der sie ohne Rubrik ausgibt, nicht trauen. Aus der Pipeline-Arbeit: Fehler häufen sich bei Entschuldigungs- und Eskalationsrunden, wo das Register zuerst kollabiert.

Häufig gestellte Fragen

Was ist ein Multi-Turn-Conversation-LLM?

Ein Sprachmodell, dessen n-te Antwort von allen vorherigen Runden abhängt, nicht nur vom letzten Prompt. Es konditioniert auf den gesamten Verlauf, daher ändert sich das Verhalten mit der Gesprächshistorie. Genau diese Kontextabhängigkeit können Single-Turn-Tests nicht prüfen, und genau dafür existiert Multi-Turn-Evaluierung.

Was bedeutet LLM-Evaluierung?

Ausgabequalität gegen definierte Kriterien messen, automatisch und wiederholbar, statt nach Gefühl. Single-Turn-Evaluierung scored isolierte Prompt-Antwort-Paare gegen Metriken wie BLEU oder einen LLM-Judge. Multi-Turn-Evaluierung erweitert das auf ganze Gespräche und scored Kontextspeicherung und Zielerreichung über die Runden hinweg statt pro Prompt.

Wie benchmarkt man Multi-Turn-LLM-Leistung?

Bauen Sie mindestens 20 Szenarien mit Zielen und Personas, simulieren Sie sie gegen das Modell und scoren Sie mit Metriken auf Gesprächsebene plus Gleitfenster-Checks. Protokollieren Sie Baselines über mehrere Läufe, um den Nichtdeterminismus aufzufangen, und vergleichen Sie dann jede neue Version in der CI gegen die Baseline. Produktions-Traces erweitern den Benchmark später.

Was sind die besten Wege, ein LLM zu evaluieren?

In der richtigen Reihenfolge: zuerst manuelle Fehleranalyse, dann binäre Bestanden/Fehlgeschlagen-Gates für alles, was sich auf eine Regel reduzieren lässt, dann LLM-as-a-Judge für subjektive Kriterien wie Ton und Lösungsqualität. Binäre Checks sind günstiger, debugbar und driften nicht; Judges gehören auf Kriterien, die wirklich Ermessen erfordern, nachdem die günstigen Gates passiert sind.

Mit welchen Multi-Turn-Metriken sollte ich starten?

Gesprächsvollständigkeit, Rundenrelevanz und Wissensspeicherung; sie fangen die häufigsten Fehler (ungelöste Ziele, Abweichung, Vergessen) in jedem Chat-Produkt. Ergänzen Sie Rollentreue, wenn Ihr Bot eine Compliance-Grenze hat, dann ein eigenes G-Eval- oder AspectCritic-Kriterium für den Fehler, den sich Ihr Geschäft nicht leisten kann.

Was kostet LLM-as-a-Judge pro Gespräch?

Mit einem Gleitfenster von 5 über 10 Runden plus einem Call auf Gesprächsebene machen Sie 7 Judge-Calls pro Gespräch. Bei rund 2.000 Input-Tokens pro Call auf GPT-4o-mini ergibt unsere offengelegte Rechnung etwa 0,29 $ pro 100 Gespräche. Premium-Judge-Modelle erhöhen das um das 10-50-Fache.

DeepEval vs. RAGAS für Multi-Turn-Evaluierung: Was soll ich wählen?

DeepEval, wenn Sie Offline-Regressionstests mit einem eingebauten Gesprächssimulator wollen, besonders bevor Sie Produktions-Traffic haben. RAGAS, wenn Ihr Workflow damit beginnt, echte gescheiterte Gespräche zu lesen und jeden Fehlermodus als AspectCritic zu kodifizieren. Eine übliche Aufteilung: DeepEval in der CI, RAGAS-artige Critics auf Produktions-Logs.

Wie viele Szenarien brauche ich für eine Multi-Turn-Eval-Suite?

Mindestens 20, abdeckend primäre Use Cases, Edge Cases und fehleranfällige Situationen; dieser Schwellwert stammt aus der publizierten Anleitung von DeepEval und deckt sich mit unserer Erfahrung. Unter 20 schwanken die Bestehensquoten je nachdem, welche Szenarien zufällig enthalten sind. Vergrößern Sie den Satz mit jedem Produktionsfehler.

Kann ich Multi-Turn-Evaluierung in CI/CD fahren?

Ja. Halten Sie einen festen Szenario-Satz im Repo, fahren Sie ihn bei jeder Prompt- oder Modelländerung und lassen Sie den Build fehlschlagen, wenn eine Metrik die Baseline jenseits der Toleranz unterschreitet. Weil Modelle nichtdeterministisch sind, vergleichen Sie Mittelwerte über 3 Läufe mit einer Toleranz (wir nutzen 0,03), keine exakten Schwellwerte.

Wie evaluiere ich Multi-Turn-Gespräche in Produktion?

Gruppieren Sie Traces nach Gesprächsverlauf, scoren Sie jeden Verlauf asynchron, damit die Evaluierung nie eine Antwort blockiert, und leiten Sie scheiternde Verläufe in eine Review-Queue. Jeder bestätigte Fehler wird ein neues Szenario in Ihrer Offline-Suite und schließt die Schleife zwischen Monitoring und Regressionstests.

Die Kurzversion

• Single-Turn-Scores sehen Gesprächsfehler nicht; die Forschung zeigt Modelle, die über die Runden hinweg abbauen, trotz gesunder Benchmarks.
• Fahren Sie Scoring auf Gesprächsebene als Gate und Gleitfenster-Scoring, um Brüche zu lokalisieren.
• Vier Kernmetriken plus ein eigenes Kriterium decken die meisten Chat-Produkte ab; binäre Checks immer vor Judges.
• DeepEval für simulierte Regressionstests, RAGAS für Fehleranalyse-getriebene Critics, Langfuse für Produktions-Traces.
• Judge-Kosten sind klein (unter einem Dollar pro 100 Gespräche auf einem Mini-Modell); Kosten sind selten der Blocker.

Für die breitere Tool-Landschaft: Wir haben das gesamte Feld in unserem Roundup der besten LLM-Evaluierungstools gerankt. Und wenn Sie die Eval-Pipeline lieber mit jemandem bauen, holen Sie sich eine kostenlose Beratung beim Techsy-Team.