Évaluation LLM multi-tours : 5 métriques, 3 frameworks, 1 workflow

Évaluation LLM multi-tours : 5 métriques, 3 frameworks, 1 workflow

L'évaluation LLM multi-tours est le seul moyen de détecter le bug d'amnésie du 8e tour : l'utilisateur a donné son numéro de commande au 3e tour, et le bot le redemande. Chaque tour, pris isolément, passait ; la conversation, elle, a échoué. DeepEval 4.0 et RAGAS 0.4 ont livré des API d'évaluation conversationnelle dédiées précisément pour cela, et après deux incidents d'évaluation dans notre propre pipeline chez Techsy, voici les cinq métriques, trois frameworks et un workflow par lesquels commencer.

Points clés à retenir

• L'évaluation multi-tours note des conversations entières, pas des paires entrée-sortie isolées.
• Les modèles en tête des benchmarks single-turn se dégradent de façon mesurable au fil des tours.
• Commencez avec quatre métriques : complétude, rétention des connaissances, respect du rôle, pertinence des tours.
• DeepEval, RAGAS et Langfuse abordent l'évaluation multi-tours différemment ; le tableau ci-dessous les compare.

Pourquoi les scores single-turn vous mentent-ils ?

Les évaluations single-turn notent une paire entrée-sortie à la fois, si bien qu'elles ne peuvent pas voir les échecs qui n'apparaissent qu'au fil des tours : oublis, contradictions, dérive. Un modèle peut afficher un excellent score de benchmark et perdre le fil d'une conversation réelle. Laban et al. le documentent dans LLMs Get Lost In Multi-Turn Conversation, 353 citations : les performances se dégradent en contexte multi-tours même quand les résultats single-turn semblent sains.

Le problème de fond est le non-déterminisme : la nième réponse dépend des n-1 tours précédents, donc des prompts identiques se comportent différemment selon l'historique. Un jeu de données de paires isolées n'exerce jamais cette dépendance. L'état de l'art arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, une revue PRISMA d'environ 250 sources, découpe le domaine entre ce qu'on évalue (gestion du contexte, planification, cohérence) et comment (métriques, juges LLM, revue humaine). Ces deux axes sont absents d'une suite single-turn.

Rien de tout cela ne rend votre pile single-turn inutile. Si vous utilisez des métriques single-turn comme BLEU, ROUGE et G-Eval, gardez-les pour ce qu'elles mesurent bien : conformité au format, toxicité, rappel factuel sur un prompt figé. Cessez simplement de les lire comme un bilan de santé de la conversation que vos utilisateurs touchent.

Notre interprétation de ces études, en une ligne :

Les évaluations single-turn mesurent la réponse, l'évaluation multi-tours mesure la conversation, et un modèle qui excelle au tour un peut être perdu au tour cinq.

Qu'est-ce que l'évaluation LLM multi-tours ? Les deux modes d'évaluation

L'évaluation LLM multi-tours consiste à noter une conversation entière, ou des fenêtres à l'intérieur de celle-ci, plutôt que des paires prompt-réponse isolées. Elle demande si le modèle a conservé le contexte, gardé son rôle et résolu le problème de l'utilisateur au fil des tours. Deux modes font le travail : le scoring au niveau conversation et le scoring par fenêtre glissante au niveau tour, et la plupart des équipes utilisent les deux.

Le scoring au niveau conversation transmet au juge la transcription complète et pose une question : cette conversation a-t-elle réussi ? Il détecte les clôtures prématurées et les boucles non résolues, car seul le fil complet révèle que l'utilisateur n'a jamais obtenu son remboursement. Sa faiblesse est la granularité : « échec » sur un fil de 12 tours ne dit pas où les choses ont cassé.

Le scoring par fenêtre glissante déplace une fenêtre de N tours le long de la transcription, un verdict par fenêtre. Une fenêtre de 3 sur une conversation de 10 tours donne 8 verdicts attachés à des régions du chat, donc « échec » vient avec des coordonnées : la rupture a eu lieu aux tours 6 à 8. Le schéma en haut de cet article montre les deux modes sur un même fil : une accolade pour le verdict de conversation, un cadre glissant pour les verdicts par fenêtre.

Utilisez le scoring au niveau conversation comme barrière, et le scoring par fenêtre pour localiser les échecs quand elle tombe. Le guide d'évaluation multi-tours de DeepEval présente l'unité de travail comme un scénario plutôt qu'une paire entrée-sortie (son type ConversationalGolden) : vous testez une situation, pas une question.

Exemple illustratif (synthétique ; montre la mécanique, pas une exécution réelle) : une fenêtre glissante de 3 sur un chat de demande de retour en 8 tours.

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?

Verdict au niveau conversation : échec. Cinq fenêtres sur six passaient, et le fil a quand même cassé sur la rétention des connaissances, exactement l'échec qu'une suite single-turn ne fait jamais remonter.

Quelles métriques multi-tours comptent vraiment ? Les 5 essentielles

Commencez par quatre métriques : complétude de la conversation, rétention des connaissances, respect du rôle et pertinence des tours. Ajoutez une cinquième, un critère personnalisé (G-Eval dans DeepEval, AspectCritic dans RAGAS), pour ce que votre produit ne peut pas rater. Les quatre premières se transfèrent d'un projet à l'autre ; la cinquième, c'est là que vivent vos modes d'échec.

1. Complétude de la conversation. L'objectif de l'utilisateur a-t-il été résolu, ou le bot a-t-il crié victoire trop tôt ? Votre détecteur de clôture prématurée.
2. Rétention des connaissances. Le modèle se souvient-il des faits énoncés plus tôt dans le fil ? Le bug d'amnésie du 8e tour est un échec de rétention des connaissances.
3. Respect du rôle. L'assistant reste-t-il dans son personnage et refuse-t-il les demandes hors périmètre ? Critique avec une frontière de conformité.
4. Pertinence des tours. Chaque réponse est-elle dans le sujet compte tenu des tours précédents ? Détecte la dérive et les boucles.
5. Un critère personnalisé. Une règle en langage naturel pour votre domaine : « ne jamais citer un prix différent de la grille tarifaire ». DeepEval l'implémente via ConversationalGEval ; RAGAS via AspectCritic.

Le guide des métriques DeepEval définit chacune avec des classes exécutables, mais les concepts sont indépendants du framework : le tableau reste valable même si vous construisez votre juge à la main.

Un critère personnalisé se lit comme une phrase :

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

La même règle en vrai code DeepEval :

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 : quel framework choisir ?

Tous les trois évaluent des conversations multi-tours, mais leur unité d'évaluation diffère : DeepEval simule des scénarios hors ligne, RAGAS note les aspects de conversations que vous avez déjà, et Langfuse évalue de vraies traces de production. Choisissez selon la provenance de vos conversations, pas selon le nombre de fonctionnalités.

D'abord la logique indépendante du framework, pour que le code vendeur ci-dessous soit portable :

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 : scénarios et simulateur clé en main

DeepEval est le seul à proposer un simulateur de conversation de première classe : décrivez un scénario et un persona, et il joue l'utilisateur face à votre bot. Son guide multi-tours est la référence canonique du motif scénario-plutôt-que-paires. Confident AI vend le tableau de bord hébergé ; notre avis sur Confident AI couvre ce que la couche payante ajoute.

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 : piloté par l'analyse d'erreurs, aspect par aspect

RAGAS part de conversations que vous avez déjà et les note aspect par aspect. Son guide pratique multi-tours se combine avec une analyse d'erreurs manuelle : lisez les chats en échec, écrivez un AspectCritic par mode d'échec, notez.

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 : évaluation N+1 sur de vraies traces

Langfuse prend le chemin opposé : le tracer d'abord. Son cookbook N+1 évalue la trace de chaque tour plus la conversation dans son ensemble, sur du trafic de production plutôt que des simulations. Si vous choisissez encore votre couche d'observabilité, notre comparatif Langfuse vs LangSmith couvre cette décision.

Notre verdict, sans langue de bois : pour un nouveau projet de chatbot, commencez avec DeepEval. Le simulateur vous permet de barrer la route aux régressions avant d'avoir du trafic de production, au moment où vous avez le plus besoin de tests. Ajoutez Langfuse une fois que de vrais fils existent ; tournez-vous vers RAGAS quand votre équipe préfère lire les conversations en échec et codifier ce qu'elle y trouve.

Comment passer de l'analyse d'erreurs à l'automatisation ?

En séquencant. Lisez 20 à 30 conversations réelles, étiquetez les modes d'échec à la main, écrivez des vérifications binaires réussi/échec pour les cas évidents, automatisez-les, et seulement ensuite ajoutez des métriques jugées par LLM pour le résidu subjectif. Hamel Husain défend exactement cet ordre : d'abord l'analyse d'erreurs manuelle et les décisions binaires, parce qu'une vérification que vous pouvez expliquer bat un score que vous ne pouvez pas.

Le binaire avant le juge : le séquençage qui nous a sauvés

Ce n'est pas un benchmark de chatbot que nous avons mené ; c'est notre interprétation du même motif à l'intérieur de notre propre pipeline de contenu, qui exécute des vérifications de régression barrées par l'évaluation à chaque changement de prompt ou d'outillage. Deux incidents nous ont prouvé le séquençage.

Le 13 juin 2026, un bug de republication a généré de nouveaux slugs localisés et expédié 54 documents en double en ligne. Nous les avons trouvés et dépubliés le 5 juillet 2026 (sauvegarde dans techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). La correction n'était pas un modèle plus intelligent ; c'était une vérification déterministe avant publication : résoudre le document existant par article canonique et langue avant toute création. Une barrière binaire.

Deuxième incident : les LLM de traduction émettent parfois de l'ASCII au lieu d'Unicode, transformant « karşılaştırma » en « karsilastirma ». Pas besoin de juge ; une barrière grep le détecte :

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

Les deux ont été attrapés par des vérifications qui coûtent des fractions de centime et affichent exactement pourquoi elles ont échoué. Transposez à l'évaluation multi-tours : « le bot a-t-il redemandé un champ que l'utilisateur a déjà donné ? » est une correspondance de chaînes sur la transcription, pas un appel au juge. Exécutez d'abord les barrières déterministes bon marché ; elles attrapent les échecs les plus grossiers avant que votre juge coûteux ne tourne.

Quand un juge LLM est vraiment le bon outil

Les juges gagnent leur coût en tokens sur les critères que vous ne pouvez pas réduire à une règle : « le ton était-il convenablement contrit ? », « la résolution était-elle adaptée à la situation ? ». Si vous pouvez écrire une assertion, écrivez une assertion. Une grille pleine d'appréciations, c'est le territoire du juge.

La ligne à laquelle nous revenons toujours :

Commencez par des vérifications binaires réussi/échec que vous pouvez expliquer à un coéquipier, puis n'ajoutez des juges LLM que pour ce que vous ne pouvez pas réduire à une règle.

Comment simuler des conversations à grande échelle, et combien coûte le jugement ?

Simulez à partir de scénarios, pas de journaux exportés. Les scénarios testent ce qui pourrait arriver ; les journaux montrent seulement ce que votre système actuel a déjà laissé passer. Les conseils de DeepEval avertissent que les conversations historiques ont été façonnées par le système qui les a produites, donc benchmarker contre elles fige le statu quo.

Des scénarios, pas des transcriptions

Écrivez chaque scénario comme un objectif plus un persona : « client impatient retournant une commande endommagée », « utilisateur qui change d'avis en pleine réservation ». Fixez une limite de tours (10 est raisonnable) et une condition d'arrêt : objectif atteint, l'utilisateur abandonne, ou plafond. DeepEval recommande au moins 20 scénarios variés couvrant les cas d'usage principaux, les cas limites et les situations à risque d'échec ; en dessous, votre suite mesure des anecdotes.

Personas adverses

Incluez des personas qui tentent de casser le bot : un utilisateur en colère qui monte en escalade, un utilisateur confus qui se contredit, un utilisateur d'injection qui glisse des instructions au tour 4. L'injection multi-tours est une discipline à part ; notre guide des garde-fous LLM couvre la couche défensive qui accompagne ces tests, et le cookbook de simulation de Langfuse montre la boucle de simulation d'utilisateur.

Ce que coûtent 100 conversations évaluées

Chaque chiffre ci-dessous est une estimation à partir des volumes de tokens annoncés et des tarifs publics, pas une mesure que nous avons menée. Le calcul est le sujet : remplacez par vos propres chiffres.

Moins d'un dollar pour 100 conversations entièrement jugées. Un juge plus cher multiplie cela par 10 à 50, et les tactiques de notre guide réduire les coûts d'API LLM s'appliquent : mettez en cache le texte des critères, traitez les fenêtres par lots, utilisez le modèle bon marché pour les barrières binaires.

Un workflow d'évaluation multi-tours en 6 étapes

La boucle tourne ainsi : définissez des scénarios à partir d'échecs réels, choisissez quatre métriques de base plus une personnalisée, simulez au moins 20 scénarios, établissez une ligne de base de la version actuelle, barrez la route aux régressions dans le CI, et réinjectez les échecs de production dans le jeu de scénarios.

1. Définissez des scénarios à partir des échecs. Lisez 20 à 30 transcriptions (ou, avant lancement, écrivez-les à partir des tickets support). Chaque scénario reçoit un objectif, un persona et un plafond de tours. Responsable : vous et la méthode d'analyse d'erreurs d'abord de Hamel.
2. Choisissez quatre métriques, une personnalisée. Complétude, rétention des connaissances, respect du rôle, pertinence des tours, et un ConversationalGEval ou AspectCritic pour l'erreur coûteuse de votre domaine.
3. Simulez. Exécutez au moins 20 scénarios incluant le jeu adverse. Responsable : le ConversationSimulator de DeepEval, ou le cookbook de simulation de Langfuse.
4. Établissez la ligne de base de la version actuelle. Enregistrez les moyennes par métrique sur 3 exécutions, car les modèles sont non déterministes et une exécution seule est du bruit. Responsable : votre script d'évaluation, résultats commités dans le dépôt.
5. Barrez la route aux régressions dans le CI. Fixez un seuil par métrique et faites échouer le build en cas de régression au-delà d'une tolérance :

# 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. Surveillez les fils de production. Groupez les traces en direct par fil, évaluez de façon asynchrone, et transformez chaque fil en échec en nouveau scénario. Responsable : Langfuse ou votre tracer ; nos guides sur l'évaluation des agents IA en production et l'observabilité IA couvrent la moitié surveillance.

La suite n'est jamais finie : l'étape 6 nourrit l'étape 1, et le jeu de scénarios grandit à chaque échec de production que vous attrapez.

Comment évaluer le ton à travers les langues ?

Une métrique de respect du rôle réglée sur des données anglaises fera passer une transcription turque ou japonaise qu'un locuteur natif trouve grossière, parce que le registre de politesse est propre à chaque langue. Votre grille anglaise n'a pas de mots pour cela. La correction : un critère d'aspect par attente de registre, écrit par langue, pas une métrique de ton globale.

Un critère par registre

Notre interprétation du motif AspectCritic de RAGAS, étendue à partir de l'exploitation d'un pipeline de 23 langues, pas un résultat de test publié :

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?"

Chaque critère est un critiqueur binaire distinct sur la même transcription. Nous n'avons pas publié de scores de ton inter-langues, et nous ne ferions pas confiance à un article qui les affiche sans la grille. D'après le travail sur le pipeline : les échecs se concentrent sur les tours d'excuse et d'escalade, là où le registre s'effondre en premier.

Questions fréquemment posées

Qu'est-ce qu'un LLM de conversation multi-tours ?

Un modèle de langage dont la nième réponse dépend de tous les tours précédents, pas seulement du dernier prompt. Il se conditionne sur le fil complet, donc son comportement change avec l'historique de conversation. Cette dépendance au contexte est ce que les tests single-turn ne peuvent pas exercer et que l'évaluation multi-tours existe pour noter.

Que signifie l'évaluation de LLM ?

Mesurer la qualité des sorties contre des critères définis, automatiquement et de façon répétable, plutôt qu'au feeling. L'évaluation single-turn note des paires prompt-réponse isolées contre des métriques comme BLEU ou un juge LLM. L'évaluation multi-tours étend cela aux conversations entières, notant la rétention du contexte et l'atteinte de l'objectif au fil des tours plutôt que par prompt.

Comment benchmarker la performance LLM multi-tours ?

Construisez au moins 20 scénarios avec objectifs et personas, simulez-les contre le modèle, et notez avec des métriques au niveau conversation plus des vérifications par fenêtre glissante. Enregistrez des lignes de base sur plusieurs exécutions pour absorber le non-déterminisme, puis comparez chaque nouvelle version à la ligne de base dans le CI. Les traces de production étendent le benchmark ensuite.

Quelles sont les meilleures façons d'évaluer un LLM ?

Séquencez : d'abord l'analyse d'erreurs manuelle, puis des barrières binaires réussi/échec pour tout ce qui se réduit à une règle, puis LLM-as-a-judge pour les critères subjectifs comme le ton et la qualité de la résolution. Les vérifications binaires sont moins chères, déboguables et ne dérivent pas ; les juges appartiennent aux critères qui exigent vraiment du jugement, après que les barrières bon marché passent.

Par quelles métriques d'évaluation multi-tours commencer ?

Complétude de la conversation, pertinence des tours et rétention des connaissances ; elles détectent les échecs les plus courants (objectifs non résolus, dérive, oubli) dans n'importe quel produit de chat. Ajoutez le respect du rôle si votre bot a une frontière de conformité, puis un critère personnalisé G-Eval ou AspectCritic pour l'erreur que votre entreprise ne peut pas se permettre.

Combien coûte LLM-as-a-judge par conversation ?

Avec une fenêtre glissante de 5 sur 10 tours plus un appel au niveau conversation, vous faites 7 appels au juge par conversation. À environ 2 000 tokens d'entrée par appel sur GPT-4o-mini, notre estimation calculée revient à environ 0,29 $ pour 100 conversations. Les modèles juges haut de gamme multiplient cela par 10 à 50.

DeepEval vs RAGAS pour l'évaluation multi-tours : lequel choisir ?

DeepEval si vous voulez des tests de régression hors ligne avec un simulateur de conversation intégré, surtout avant d'avoir du trafic de production. RAGAS si votre workflow commence par lire de vraies conversations en échec et codifier chaque mode d'échec en AspectCritic. Une répartition courante : DeepEval dans le CI, des critiques à la RAGAS sur les journaux de production.

Combien de scénarios pour une suite d'évaluation multi-tours ?

Au moins 20, couvrant les cas d'usage principaux, les cas limites et les situations à risque d'échec ; ce seuil vient des conseils publiés de DeepEval et correspond à notre expérience. En dessous de 20, les taux de réussite oscillent selon les scénarios qui se trouvent être inclus. Faites grandir le jeu à chaque échec de production.

Peut-on exécuter l'évaluation multi-tours dans le CI/CD ?

Oui. Gardez un jeu de scénarios figé dans le dépôt, exécutez-le à chaque changement de prompt ou de modèle, et faites échouer le build quand une métrique régresse au-delà de la tolérance face à la ligne de base. Comme les modèles sont non déterministes, comparez des moyennes sur 3 exécutions avec une tolérance (nous utilisons 0,03), pas des seuils exacts.

Comment évaluer les conversations multi-tours en production ?

Groupez les traces par fil de conversation, notez chaque fil de façon asynchrone pour que l'évaluation ne bloque jamais une réponse, et dirigez les fils en échec vers une file de revue. Chaque échec confirmé devient un nouveau scénario dans votre suite hors ligne, bouclant la boucle entre surveillance et tests de régression.

La version courte

• Les scores single-turn ne voient pas les échecs conversationnels ; la recherche montre des modèles qui se dégradent au fil des tours malgré des benchmarks sains.
• Exécutez le scoring au niveau conversation comme barrière et le scoring par fenêtre glissante pour localiser les ruptures.
• Quatre métriques de base plus un critère personnalisé couvrent la plupart des produits de chat ; les vérifications binaires avant les juges, toujours.
• DeepEval pour les tests de régression simulés, RAGAS pour les critiques pilotées par l'analyse d'erreurs, Langfuse pour les traces de production.
• Les coûts de juge sont faibles (moins d'un dollar pour 100 conversations sur un modèle mini) ; le coût est rarement le blocage.

Pour le paysage plus large de l'outillage, nous avons classé tout le champ dans notre dossier sur les meilleurs outils d'évaluation LLM. Et si vous préférez construire le pipeline d'évaluation avec quelqu'un, obtenez une consultation gratuite avec l'équipe Techsy.