Étape 2 : Défaillances des assistants de triage

Après avoir interprété les scores d’évaluation et identifié les axes d’intervention, déterminez pourquoi chaque cas de test a échoué et qui doit agir.

Cet article fournit un guide structuré pour diagnostiquer les échecs au niveau des cas de test. Il vous aide à identifier la cause racine, à distinguer entre les problèmes d’assistant, d’évaluation et d’infrastructure, et à déterminer la prochaine étape appropriée.

Avant de commencer

Avant de commencer le triage des défaillances :

1. Complétez l’interprétation du score et l’évaluation de la préparation, et identifiez quels ensembles d’évaluation nécessitent une attention particulière.
2. Concentrez-vous sur les défaillances prioritaires en fonction de la préparation et du risque.

Vérification pré-triage : Vérifier la santé de l’infrastructure

Avant d’analyser des défaillances individuelles, assurez-vous que les dépendances fonctionnaient correctement pendant l’évaluation. Les problèmes d’infrastructure peuvent entraîner des défaillances similaires à celles des assistants ou des évaluations, mais qui en sont indépendantes.

Vérifiez les conditions suivantes :

• Les sources de connaissances sont accessibles et entièrement indexées.
• Les back-ends ou connecteurs API ne génèrent ni erreurs, ni expirations, ni réponses de limitation de débit.
• Les jetons d’authentification sont valides tout au long de l’exécution.
• L’environnement d’évaluation correspond à la configuration prévue de l’assistant.

Si une dépendance est défectueuse, corrigez le problème et relancez l’évaluation avant de continuer. L’analyse des résultats d’une exécution dégradée peut conduire à des conclusions erronées.

Étape 0 : Prioriser les échecs

Avant de traiter des cas de test individuels, décidez d’abord où vous concentrer.

Priorisez les échecs dans cet ordre :

Si vous avez beaucoup de défaillances (par exemple, plus de 15), ne triez pas chacune individuellement. Commencez par l’ensemble d’évaluation ayant obtenu les scores les plus faibles et passez en revue manuellement quelques échecs. Si elles partagent une cause racine, la corriger peut résoudre de nombreuses défaillances simultanément.

Identifiez le signal de qualité d’un cas de test échoué

Si un résultat d’évaluation présente un cas de test échoué sans identifier clairement le signal de qualité, utilisez l’ensemble d’évaluation et la méthode de notation pour en déduire le signal de qualité.

Par exemple :

• L’ensemble d’évaluation indique le domaine de compétence, tel que la sécurité, l’ancrage ou l’utilisation des outils.
• La méthode de notation, p. ex. la correspondance par mots-clés ou la notation basée sur une grille d’évaluation, fournit plus de contexte.

Identifier le signal de qualité visé vous aide à choisir les questions de diagnostic les plus pertinentes.

Étape 1 : Vérifier la configuration de l’évaluation

Pour chaque défaillance, examinez manuellement la réponse réelle de l’assistant ainsi que la valeur attendue et la méthode de notation.

Passez en revue les questions suivantes dans l’ordre. Arrêtez-vous quand vous atteignez un objectif.

1. La réponse de l’assistant est-elle acceptable ? Un vrai utilisateur serait-il satisfait de cette réponse, même si elle a échoué à l’évaluation ?

   • Si Oui, la configuration d’évaluation pose un problème : le correcteur ou la valeur attendue est erroné.
   • Si Non, passez à la question suivante.

2. La réponse attendue est-elle à jour et exacte par rapport à la source ?

   • Si Oui, passez à la question suivante.
   • Si Non, la configuration d’évaluation pose un problème : la réponse attendue est périmée ou erronée.

3. Le cas de test reflète-t-il une entrée utilisateur réaliste ?

   • Si Oui, passez à la question suivante.
   • Si Non, la configuration d’évaluation pose un problème : le cas de test est irréaliste.

4. Une autre réponse raisonnable pourrait-elle aussi être correcte, mais le correcteur ne l’autorise pas ?

   • Si Oui, la configuration d’évaluation pose un problème : le correcteur est trop rigide et ne prend pas en compte les variations valides.
   • Si Non, passez à la question suivante.

5. La méthode d’évaluation est-elle appropriée pour ce que vous testez ?

   • Si Oui, l’évaluation est valide. Passez à l’Étape 2 : Diagnostiquer l’assistant.
   • Si Non, la configuration d’évaluation pose un problème : la méthode d’évaluation n’est pas adaptée à ce signal de qualité.

Déterminer l’acceptabilité de la réponse

Utilisez les signaux suivants pour déterminer si la réponse de l’assistant est acceptable :

• Même faits clés, formulation différente → Souvent acceptable (l’évaluateur peut être trop rigide).
• Informations cruciales manquantes trouvées dans la source → souvent inacceptables.
• Un seuil ambigu de « suffisamment bon » → Les critères d’acceptation peuvent être flous (signalement pour l’étape 4).

Si vous n’êtes pas sûr, comparez le contenu à la source originale, pas seulement à la réponse attendue.

Ces signaux éclairent votre jugement, mais ne le remplacent pas.

Types courants de défaillance des configurations d’évaluation

Validation de l’évaluateur

La fiabilité de l’évaluateur est un prérequis pour un triage digne de confiance. Si l’évaluateur lui-même n’est pas fiable, vous diagnostiquez mal chaque échec qu’il traite.

Pour valider la fiabilité de l’évaluateur :

1. Sélectionnez 5 à 10 cas de test où vous connaissez le bon résultat réussi/échec grâce à une vérification manuelle.
2. Effectuez l’évaluation et comparez le résultat de l’évaluateur avec le verdict manuel.
3. Si l’évaluateur est en désaccord dans plus de 20 % des cas, recalibrez-le avant de déboguer l’assistant.

Signes qu’un évaluateur a besoin d’attention :

• Le même cas de test produit des verdicts différents d’une exécution à l’autre.
• Les défaillances se regroupent dans des ensembles d’évaluation utilisant une évaluation basée sur des modèles tandis que les méthodes déterministes réussissent.
• L’évaluateur signale des problèmes que vous ne pouvez pas reproduire en examinant la réponse de l’assistant.

Options de recalibrage de l’évaluateur :

• Utilisez des méthodes déterministes si possible.
• Ajoutez des exemples explicites « acceptables » et « non acceptables » à la rubrique.
• Élargissez les ensembles de mots-clés pour inclure des synonymes et des reformulations valides.
• Utilisez Comparer le sens au lieu de Correspondance par mot-clé (Tous) pour les vérifications d’équivalence sémantique.

Étape 2 : Diagnostiquer l’assistant

À ce stade, l’évaluation est valide et l’assistant a donné une mauvaise réponse. Diagnostiquez ce qui a mal fonctionné dans la configuration de l’assistant.

Vérifiez l’exactitude des faits et les défaillances d’ancrage des connaissances

Vérifier les défaillances d’appel d’outil

Vérifiez les défaillances de routage des déclencheurs

Vérifiez les problèmes de tonalité et de qualité de réponse

Vérifier la présence de défaillances de sécurité et de limites

Vérifiez les mécanismes d’escalade et d’échec contrôlé

Après le diagnostic, associez les schémas de défaillance aux stratégies de remédiation selon la cause racine.

Étape 3 : Identifier les limites de la plateforme

Si l’évaluation est correcte et que des modifications raisonnables de configuration n’améliorent pas les résultats, le problème pourrait être une limitation de la plateforme.

Indicateurs de limitation de la plateforme

Chemin d’action pour les limitations de plateforme

1. Documentez clairement la limitation (ce qui ne fonctionne pas, ce que vous avez essayé, et les preuves qui montrent que ce n’est pas lié à la configuration).
2. Appliquez une solution de contournement si possible (p. ex., restructurez le document source pour améliorer la récupération).
3. Marquez le cas de test comme une limitation connue ou ajustez les seuils pour éviter qu’il ne bloque la progression indépendante.
4. Escalader avec des éléments probants à l’équipe de la plateforme.
5. Suivez l’élément dans le journal des défaillances pour une réévaluation lorsque les capacités de la plateforme évoluent.

Après avoir classifié, consultez les solutions de contournement et les instructions d’escalade pour répondre aux limitations de la plateforme.

Quand une défaillance ne correspond pas au cadre

Certaines défaillances ne correspondent pas clairement à un seul type de cause profonde. Voici quelques exemples courants :

• Problèmes de qualité des données back-end : le contenu de la source de connaissances est techniquement correct mais ambigu, donc ni l’assistant, ni l’évaluation ne sont en cause.
• Problèmes d’infrastructure intermittents : délais d’expiration réseau, limitation du taux de l’API et problèmes de connecteurs qui ne se reproduisent pas de manière constante.
• Changements de version du modèle : le comportement de l’assistant a changé après une mise à jour du modèle de plateforme que vous n’avez pas initiée.
• Cas de test ambigus : le scénario est ambigu, et des personnes raisonnables ne sont pas d’accord sur la bonne réponse.

Approche suggérée : documentez ce que vous avez observé (la défaillance, la réponse de l’assistant, ce que vous avez vérifié). Enregistrez l’élément comme « non classifié » dans le journal des défaillances. Si la défaillance réapparaît, elle peut alors souvent être classée grâce à des preuves supplémentaires.

Gestion des causes composées

Une même défaillance peut avoir plusieurs causes profondes contributives. Par exemple :

• Une défaillance de précision factuelle où la réponse attendue est légèrement périmée (paramétrage d’évaluation) et la source de connaissances est également incomplète (configuration de l’assistant).
• Une défaillance d’invocation d’outil où la description de l’outil est ambiguë (configuration de l’assistant) et dont l’orchestration ne prend pas en charge les appels conditionnels d’outil (limitation de plateforme).

Approche suggérée : effectuer le triage complet pour chaque défaillance. Si plusieurs types de causes profondes s’appliquent, traitez-les par ordre de priorité :

1. Corrigez d’abord l’évaluation pour obtenir un signal clair sur l’efficacité réelle du changement d’assistant.
2. Corrigez la configuration de l’assistant pour déterminer si la défaillance restante est vraiment un problème de plateforme.
3. Documentez la limitation de la plateforme uniquement après avoir résolu les points 1 et 2.

Relancez les cas de test concernés après chaque changement avant de continuer.

Gestion des échecs d’invite multitour

Pour les scénarios à plusieurs tours, les défaillances ne surviennent que sur plusieurs tours.

Quand suspecter un problème sur plusieurs tours

• L’assistant répond correctement aux premiers tours, mais se contredit plus tard.
• L’assistant perd le contexte d’un appel d’outil précédent ou d’une récupération de connaissances lors d’un tour ultérieur.
• Le moment de l’escalade n’a de sens que si l’on prend en compte l’ensemble de l’historique de la conversation.
• Le ton de l’assistant se dégrade progressivement à mesure que la conversation s’allonge.
• L’assistant demande les informations que l’utilisateur a déjà fournies.

Questions de diagnostic supplémentaires

Instructions de remédiation pour les problèmes multitours

• Perte de contexte : vérifiez la configuration de l’état de la conversation. Assurez-vous que les résultats des outils et les faits clés persistent au fil des tours.
• Contradictions : ajoutez une consigne de cohérence, par exemple : « Conserve la cohérence avec tes réponses précédentes dans cette conversation. »
• Re-demande : vérifiez la configuration de la mémoire conversationnelle de la plateforme.
• Dégradation des longues conversations : envisagez des stratégies de résumé des conversations ou d’élagage contextuel.

Validation des cas de test réussis (vérification des faux positifs)

Ce cadre se concentre sur les cas de test en échec. Cependant, un cas de test qui réussit à tort peut créer des lacunes de qualité invisibles.

Pratique recommandée : vérifier manuellement 5 à 10 % des cas de test réussis lors de chaque cycle d’évaluation, en particulier pour :

• Évaluation basée sur un modèle (risque accru de faux positifs)
• Signaux subjectifs (ton, utilité)
• Échecs précédents à des tests qui sont maintenant réussis après un changement

Si vous trouvez des faux positifs, recalibrez l’évaluateur.

Étapes suivantes

Après avoir terminé le triage des défaillances :

• Utiliser la Couche 3 : Mapper les modèles de défaillances aux stratégies de remédiation.
• Utilisez la Couche 4 : Analyser les motifs pour identifier les problèmes systémiques.
• Passez en revue des exemples pratiques qui démontrent comment les couches du cadre fonctionnent ensemble dans des scénarios réels.