Analyse forensique des conversations

Détecter les incidents dans les conversations humain↔agent

Un incident est un moment du fil où quelque chose s'est mesurablement mal passé : l'utilisateur a reformulé la même question trois fois, le sentiment a viré négatif et y est resté, l'utilisateur a explicitement demandé un humain, la confiance de l'agent est descendue sous un seuil, un appel d'outil a échoué et la reprise n'a pas abouti, ou l'utilisateur a abandonné en cours. La détection s'exécute sur le signal en direct — trajectoire de sentiment, patrons de répétition, demandes d'escalade, événements d'erreur d'outil, temps de présence — et sur les métadonnées de trace que le runtime émet déjà. La détection est par fil, pas par message, parce que l'incident n'a généralement de sens que dans l'arc.

• Trajectoire de sentiment et détection de négatif persistant
• Patrons de questions répétées et reformulées
• Signaux d'escalade explicites (« je veux parler à un humain »)
• Échecs d'outils et erreurs non récupérées
• Abandon en cours de conversation

Rejouer le fil autour du moment

Une fois un incident signalé, la vue forensique reconstruit la fenêtre autour : les messages avant et après, le raisonnement intermédiaire de l'agent, ce qui a été récupéré et d'où, quels outils ont été appelés avec quelles entrées et sorties, les paramètres et la route du modèle à chaque étape. Le réviseur (ou le pipeline d'analyse) voit non seulement ce que l'agent a dit mais ce que l'agent a vu — la différence compte pour diagnostiquer une hallucination versus un mauvais retrieval versus une source de connaissance périmée.

Extraction du résultat : l'utilisateur a-t-il vraiment résolu ?

Un incident qui se termine par un remerciement est un artefact très différent de celui qui se termine par la fermeture de l'onglet. Nous extrayons la résolution par fil : résolu avec l'agent seul, résolu après escalade humaine, résolu sur un fil de suivi, abandonné sans résolution, ou indéterminé. Le résultat est apparié au signal d'incident et à ce que l'agent (ou l'humain) a effectivement fait — pour que la prochaine fois qu'un incident similaire est détecté, il existe une preuve réelle de ce qui a marché.

• Résolu avec l'agent seul — quelle action ou réponse a clos
• Résolu après escalade — ce que l'humain a fait différemment
• Résolu sur un fil de suivi — comment l'utilisateur est revenu
• Abandonné — et l'utilisateur est-il revenu par un autre canal

L'artefact d'apprentissage produit

Chaque incident analysé devient un enregistrement structuré : le signal d'échec, l'extrait de trace, la cause hypothétique (retrieval, raisonnement, outil, connaissance, politique), le résultat de résolution et — quand il existe — la recette de résolution. Agrégés, ces enregistrements forment un regroupement nommé d'échecs reliés avec compte, tendance, propriétaire recommandé et remède candidat. Les mêmes enregistrements alimentent le jeu d'évaluations (en cas de régression), la base de connaissance (quand la résolution était un contexte manquant) et le workflow lui-même (quand une recette à haute confiance peut être branchée comme chemin de récupération automatique).

• Enregistrement d'incident structuré par fil
• Regroupement avec compte, tendance, propriétaire et remède
• Cas de régression pour le jeu d'évaluations
• Mises à jour de connaissance quand la résolution était un contexte manquant
• Recettes de récupération branchées au workflow sous approbation

Comment nous regroupons

La similarité d'embedding sur le signal d'échec (la question, l'échange non résolu, le résumé de trace, les caractéristiques d'incident extraites) amorce les regroupements ; un étiquetage assisté par modèle les raffine ; les humains révisent et fusionnent. L'identité du regroupement est assez stable pour que les nouveaux mauvais fils correspondent aux existants ou émergent comme candidats à de nouveaux — et le résultat de résolution voyage avec le regroupement, pour qu'un patron puisse être marqué « récurrent et non résolu », « récurrent mais le chemin humain marche », ou « on a une recette, automatisons-la ».

Où la boucle se ferme

Les échecs de retrieval deviennent du travail de graphe source ou de découpage. Les échecs de raisonnement deviennent des changements de prompt ou de modèle qui passent la porte d'évaluation. Les échecs d'outil deviennent du travail de fiabilité dans le runtime. Les échecs de connaissance deviennent des mises à jour de la source sous-jacente. Les échecs de politique deviennent des changements de gouvernance. Et quand le résultat de résolution est bien caractérisé, la recette elle-même devient un changement de workflow candidat — proposé, évalué contre le jeu de régression et promu sous approbation. Chaque fermeture décrémente le compte du regroupement ; les nouveaux échecs le font croître ; le taux est l'état visible de la discipline en boucle fermée.