Couche 4 : Analysez les schémas et améliorez continuellement votre assistant

Après avoir trié les échecs des cas de test individuels, vous pouvez appliquer des correctifs et constater peu ou pas d’amélioration des performances globales de l’assistant. Ce résultat indique souvent un problème systémique, et non un ensemble de défaillances sans rapport.

L’analyse des schémas vous aide à examiner plusieurs cas de test défaillants afin d’identifier des signaux récurrents et des causes racines partagées. Utilisez l’analyse des schémas pour cibler les changements qui traitent des groupes de défaillances simultanément, au lieu de corriger chaque défaillance isolément.

Important

Utilisez ces recommandations après avoir terminé le triage des défaillances et appliqué les changements de remédiation. L’analyse des schémas est particulièrement utile après avoir trié au moins cinq défaillances.

Quand utiliser l’analyse de schémas

L’analyse des schémas est particulièrement utile lorsque vous observez une ou plusieurs des conditions suivantes :

  • De nombreux échecs dans le même ensemble d’évaluation.
  • Échecs répétés avec des symptômes similaires.
  • Des améliorations dans des cas de test individuels qui n’affectent pas les scores globaux.
  • Des améliorations dans un domaine qui provoquent des régressions dans un autre.

Corriger les défaillances une par une est inefficace dans ces situations. L’analyse des schémas vous aide à identifier ce que les échecs ont en commun afin de pouvoir en traiter la cause sous-jacente.

Analyse de la concentration

Après avoir classé les défaillances individuelles, cherchez des motifs sur l’ensemble.

Modèle Ce que cela indique Action recommandée
80 % ou plus des défaillances sont des problèmes d’installation d’évaluation La suite d’évaluation a besoin d’un étalonnage, pas de modifications de l’assistant Mettez en pause l’itération de l’assistant. Auditez et corrigez d’abord la qualité de l’évaluation, puis relancez pour obtenir un signal clair.
80 % ou plus des échecs sont des problèmes de configuration de l’assistant dans un domaine (par exemple, tous liés à la connaissance) Écart systémique de configuration des assistants Ciblez la remédiation sur ce domaine. Ce problème relève souvent de l’architecture (par exemple, la structure de la source de connaissances), plutôt que de corrections individuelles de cas de test.
80 % ou plus des défaillances sont des limitations de la plateforme L’assistant atteint les limites de la plateforme Réévaluez la portée de l’assistant. Faites remonter à l’équipe en charge de la plateforme. Ajustez les seuils ou traitez les éléments impactés comme des limitations connues, le cas échéant.
Les défaillances se répartissent uniformément selon les causes profondes Aucun problème systémique unique Continuez la remédiation au cas par cas en utilisant mappage de remédiation.

Comment réaliser une analyse de concentration

  1. Décomptez vos échecs classés par type de cause principale :

    • Problèmes liés à la configuration de l’évaluation
    • Problèmes de configuration de l’assistant
    • Limitations de la plateforme
    • Non classifié

  2. Calculez le pourcentage pour chaque type.

  3. Si un type unique est à 80 % ou plus — indiquant un problème systémique — corrigez la catégorie, pas les cas individuels.

  4. Si les problèmes de configuration de l’assistant se concentrent sur un seul signal de qualité (par exemple, cinq sur six concernent l’ancrage des connaissances), ce schéma indique une cause racine liée à l’architecture.

Schémas inter-signaux

Lorsque les échecs couvrent plusieurs ensembles d’évaluation, ils pointent souvent vers une cause racine commune. Recherchez les schémas suivants :

Modèle Ce que cela indique probablement Ce qu’il faut examiner
Défaillance simultanée de l’exactitude factuelle et de l’ancrage des connaissances Problème de source de connaissances (erroné, manquant, inaccessible ou obsolète) Configuration des connaissances, statut d’indexation et fraîcheur du contenu
Invocation de l’outil et routage des déclencheurs échouant tous deux Problème de configuration d’orchestration : les rubriques et les outils ne sont pas correctement connectés Vérifiez comment les rubriques sont routées vers les outils. Vérifiez s’il y a des flux déconnectés ou mal configurés.
Ton non conforme mais précision validée L’assistant obtient la bonne réponse mais la présente mal Se concentrer sur les instructions de style de requête ; l’infrastructure de précision est solide.
Sécurité validée mais précision non conforme L’assistant peut être trop contraint : trop prudent, il refuse de répondre lorsqu’il devrait le faire Vérifiez les consignes de sécurité pour repérer des restrictions trop larges qui bloquent les réponses légitimes.
Tout est conforme, sauf les cas limites Le comportement fondamental est solide Concentrez-vous sur le renforcement de la robustesse dans les cas limites ; cette tendance est bon signe.
La précision s’améliore mais la tonalité se dégrade Conflit d’instructions — de nouvelles instructions de précision pourraient remplacer la guidance par tonalité Passez en revue les changements de requête récents et gardez à l’esprit le « budget d’instructions ».
Plusieurs ensembles d’évaluation se dégradent simultanément Probablement une cause racine unique avec un impact étendu Vérifiez les récentes modifications des invites système, les mises à jour des sources de connaissances ou les mises à jour du modèle de la plateforme.

Que faire avec des schémas de signaux croisés

  1. Identifier la cause racine commune : si deux signaux échouent ensemble, ils partagent probablement une dépendance, comme une source de connaissances, une section de requête ou une configuration d’outil.
  2. Corrigez la dépendance partagée : ne corrigez pas chaque signal indépendamment.
  3. Relancez les deux ensembles d’évaluation : après la correction, confirmez que les deux ensembles montrent une amélioration.
  4. Si un seul s’améliore, les signaux ne partagent pas réellement une cause racine. Trier les échecs restants de façon indépendante.

Analyse des tendances au fil des itérations

Suivez l’évolution des scores au fil des cycles d’itération afin de vérifier que votre stratégie de remédiation fonctionne.

Tendance Interprétation Action
Les scores s’améliorent au fil des itérations La remédiation fonctionne Continuez jusqu’à ce que les seuils soient atteints.
Les scores restent stables malgré les changements La remédiation ne cible pas la véritable cause racine Nouveau triage ; la classification de la cause profonde pourrait être erronée.
Scores en baisse après un changement Régression – le changement a provoqué une défaillance Annuler les modifications. Analysez ce qui a régressé et pourquoi.
Un ensemble d’évaluation s’améliore, un autre se dégrade Échange — la correction d’une dimension a affecté une autre Étudier le couplage, souvent causé par un conflit d’instructions (voir Journey 3).
Scores variables d’une exécution à l’autre (plus de +/-10 % de variance) Instabilité de l’évaluateur ou non-déterminisme de l’assistant Validez d’abord la fiabilité de l’évaluateur (voir Validation de l’évaluateur). Exécutez au moins trois fois par itération.

Créer une vue des tendances

Après chaque itération, notez :

  • Date
  • Modification apportée
  • Ensemble d’évaluation
  • Score avant
  • Score après
  • Delta

Cette information vous permet d’effectuer les opérations suivantes :

  • Confirmer que vous convergez vers des seuils
  • Identifier rapidement les régressions
  • Détecter les plateaux tôt (Journey 2)

Documenter les défaillances

Les enregistrements structurés des défaillances constituent une base de connaissance institutionnelle à travers les cycles d’itération. Sans documentation, les équipes répètent souvent le même travail d’enquête.

Pourquoi documenter les défaillances

  • Accélérer le triage futur : vous reconnaissez immédiatement les schémas de défaillance connus.
  • Générer des preuves d’escalade : accumulez des enregistrements des limitations de la plateforme afin de constituer des dossiers plus solides auprès de l’équipe plateforme.
  • Favorisez l’apprentissage en équipe : le journal aide à prévenir les enquêtes en double lorsque plusieurs personnes travaillent sur le même assistant.
  • Suivre les écarts connus : n’oubliez pas de suivre les défaillances classées comme « non corrigée » ou « limitation connue ».

Utiliser le modèle du journal de défaillance

Utilisez le modèle du journal de défaillance pour enregistrer les défaillances dans un format léger ou détaillé, selon la taille de l’équipe et la maturité du processus.

Quoi enregistrer

Au minimum, capturez les informations suivantes pour chaque défaillance triée :

  1. Quel cas de test a échoué.
  2. Dans quel type de cause profonde vous l’avez classé
  3. Ce qui n’a pas fonctionné précisément.
  4. Ce que vous avez changé pour y remédier.
  5. Si la correction a fonctionné

Pour les échecs non résolus, notez également :

  • Ce que vous avez essayé jusqu’à présent.
  • Pourquoi cela reste non résolu.
  • Quand réévaluer (par exemple, « après la mise à jour X de la plateforme »).

Flux de travail d’amélioration continue

Utilisez cette liste de vérification après chaque cycle de triage et de remédiation pour confirmer que vous avez documenté les résultats et les prochaines étapes.

Liste de contrôle après l’itération

Vous avez terminé ? Tâche
✓ Enregistrez toutes les défaillances triées dans le journal des échecs.
✓ Identifiez et notez les concentrations de causes profondes.
✓ Vérifiez les schémas de signaux croisés.
✓ Enregistrez les scores pour le suivi des tendances.
✓ Documentez les limitations connues avec des solutions de contournement.
✓ Identifiez les priorités des prochaines itérations en fonction des échecs restants.
✓ Définir le calendrier de réexécution (quels ensembles d’évaluation, quand).

Quand arrêter les itérations

Arrêter d’itérer lorsque :

  • Tous les ensembles d’évaluation sont supérieurs aux seuils.
  • Vous avez documenté les lacunes connues.
  • Les scores sont cohérents (variance < 5 %).
  • Aucun problème de configuration d’assistant ouvert concernant des signaux bloquants.

Ne cessez pas d’itérer lorsque :

  • Vous n’avez pas analysé les échecs persistants.
  • Vous avez supprimé des cas de test difficiles pour atteindre des seuils.
  • Vous n’avez pas documenté les limites de la plateforme.

Pour en savoir plus, consultez Savoir quand l’itération est terminée.

Étapes suivantes

  • Last updated on