Débogueur de conversations

Débogueur de conversations Le débogueur utilise l’IA pour examiner des messages conservés, des extraits de contexte d’outils, des incidents liés et une reconstruction de la configuration actuelle de l’agent. Il propose une cause possible, une séquence de message, des éléments de preuve et des recommandations. Ce diagnostic doit être vérifié ; il ne constitue pas une reproduction exhaustive du traitement d’origine.

Ce que fait le débogueur

Relire une longue conversation demande du temps. Le débogueur aide à repérer un échange problématique et à formuler des pistes liées au contenu ou à la configuration. Il travaille sur les données chargées et abrégées pour l’analyse, pas sur une garantie de tous les détails de chaque exécution.

L’analyse est assistée par l’IA. Depuis une conversation, saisissez une question précise, par exemple « Pourquoi l’agent n’a-t-il pas envoyé l’e-mail ? ». Dans le parcours fourni, cette question est obligatoire : le bouton s’active à partir de cinq caractères après retrait des espaces de début et de fin, et la saisie est limitée à 1 000 caractères. Le résultat est renvoyé sous forme structurée lorsque la réponse peut être interprétée.

Structure du résultat

Champ	Signification
`rootCause`	Cause proposée par le modèle. Elle doit être rapprochée du contenu et des résultats réels avant d’être considérée comme confirmée.
`problemAtSequence`	Numéro de séquence du message où le modèle situe le problème. Repérez ce message dans la transcription ; l’indication affichée n’est pas une garantie de lien de navigation automatique.
`evidence`	Extrait ou observation présenté à l’appui du diagnostic : texte, outil, manque de contexte ou information de configuration disponible.
`recommendations`	Liste de corrections proposées, par exemple ajouter un outil nécessaire, modifier un prompt ou ajuster des champs de contexte.
`severity`	`low`, `medium` ou `high` : gravité estimée du problème, pas degré de certitude. Aucun score de confiance distinct n’est fourni.
`stopReason`	Motif d’arrêt de la réponse produite par le modèle pour ce diagnostic, par exemple `end_turn`, `max_tokens` ou `stop_sequence`. Il ne s’agit pas du motif d’arrêt historique de l’agent analysé. Une limite de sortie atteinte signale que les conclusions du débogueur peuvent être incomplètes.
`creditsUsed`	Crédits enregistrés pour l’appel d’analyse.
`rawAnalysis`	Texte brut de la réponse du modèle, conservé notamment comme solution de repli si les champs JSON attendus ne peuvent pas être interprétés.
`error`	Message renvoyé pour certains blocages sans exception, notamment l’absence de période ou de solde disponible. D’autres échecs sont remontés comme erreurs du parcours.

Données examinées

Le débogueur rassemble les données accessibles prévues par son parcours. Les informations de configuration sont reconstruites à partir de leur état actuel et peuvent différer de celles de l’exécution d’origine :

Informations actuelles de l’agent, dont le personnage abrégé à 1 500 caractères, et prompts sélectionnés avec des extraits de contenu limités à 300 caractères ; ce n’est pas le prompt système historique intégral.
Définitions d’outils actives sélectionnées pour l’agent, limitées dans cette requête à 15 avec descriptions abrégées à 200 caractères ; cela ne prouve pas la liste exacte des outils chargés lors de chaque échange passé.
Objet et identifiant de contexte de la conversation, objets de contexte par défaut et éléments éventuels de détection de conflits. Le parcours ne recharge pas un instantané exhaustif des valeurs métier vues par l’agent à l’époque.
Jusqu’aux 200 premiers messages, dans l’ordre de leur séquence, avec un contenu limité à 500 caractères par message avant envoi à l’IA.
Noms d’outils enregistrés et extraits du contexte des outils des messages assistant, limités à 2 000 caractères par message ; des entrées, résultats ou erreurs peuvent donc être absents ou abrégés.
Crédits enregistrés et jusqu’aux 10 incidents liés les plus récents. Les mesures de jetons et motifs d’arrêt historiques de chaque échange ne sont pas tous fournis dans cette collecte.
Votre question précise, par exemple « Pourquoi la réponse est-elle vide ? ».

Des mécanismes de masquage sont appliqués à certains textes avant transmission. Ils ne doivent pas être considérés comme une garantie absolue d’anonymisation. Vérifiez le périmètre de données autorisé et gardez à l’esprit les limites de cette reconstruction lors de l’interprétation.

Aperçu de l’exécution de l’agent présente une simulation de ce que la configuration actuelle prévoit de charger. La consultation de l’aperçu est en lecture seule et sans analyse IA facturée ; ses résultats ne prouvent pas le contenu exact d’une exécution historique.
Transcription de conversation présente les messages et informations conservés, selon les accès et limites de chargement, sans analyse IA ni coût d’analyse.
Débogueur de conversations soumet les éléments préparés à l’IA et propose un diagnostic. Il consomme des crédits ; ses conclusions et recommandations nécessitent une validation.

Consultez directement une conversation courte lorsque cela suffit. Utilisez le débogueur pour une analyse plus complexe ou un second avis, en vérifiant les extraits qu’il a effectivement pu examiner.

Déroulement d’une analyse

Ouvrir la conversation
Ouvrez l’enregistrement de conversation depuis Conversations sur l'IA, une liste liée ou un lien Salesforce autorisé. Ne cherchez pas une liste de conversations universellement fournie dans l’onglet d’administration.
Repérer le panneau de diagnostic
Repérez le composant Analyse des causes profondes de l'IA sur la page. L’analyse ne se lance pas automatiquement ; la collecte destinée au modèle commence après votre demande.
Saisir une question
Saisissez une question dans Votre question, par exemple « Pourquoi l’agent n’a-t-il pas appelé send_email ? » ou « Pourquoi la réponse était-elle dans la mauvaise langue ? ». La question doit contenir au moins cinq caractères utiles dans l’interface et ne pas dépasser 1 000 caractères.
Lancer le diagnostic
Cliquez sur Déboguer. La plateforme prépare les données et extraits, les transmet au modèle puis attend sa réponse. Des nouvelles tentatives techniques peuvent être effectuées pour certaines réponses de service occupé.
Examiner le résultat
Examinez la cause proposée, la séquence, les preuves, recommandations et gravité, puis comparez-les à la transcription et aux résultats Salesforce. Le diagnostic n’applique aucune modification.
Valider et appliquer les recommandations
Les corrections peuvent concerner la définition d’agent, un prompt, des champs de contexte ou un outil. Après validation de la correction, exécutez une demande semblable et contrôlez le résultat.

Gravité et motif d’arrêt

La gravité, high, medium ou low, décrit l’importance estimée du problème. Elle n’indique pas la certitude du modèle et aucun score de confiance séparé n’existe. Une valeur high suggère de traiter le problème en priorité, medium invite à l’examiner et low indique une gravité estimée moindre. Aucune de ces valeurs ne prouve ou n’exclut un défaut de configuration.

L’indication Problème identifié au message n° situe l’échange proposé, tandis que Preuves tirées de la conversation présente l’élément invoqué. Relisez le message et vérifiez le contexte avant d’accepter une recommandation : le modèle peut mal interpréter un extrait ou ne pas avoir reçu une partie importante de l’historique.

Examinez séparément stopReason, qui décrit l’arrêt de la réponse de diagnostic :

end_turn — Le modèle a terminé ce diagnostic normalement. Cela ne certifie ni l’exactitude de ses conclusions ni l’absence d’un problème technique dans la conversation d’origine.
max_tokens — La réponse de diagnostic a atteint son budget de sortie. Les conclusions peuvent être incomplètes. Précisez la question ou faites vérifier le budget du débogueur ; ne modifiez pas automatiquement le budget de l’agent d’origine sur cette seule base.
stop_sequence — La réponse de diagnostic s’est arrêtée sur une séquence configurée. Vérifiez si le résultat est complet et cohérent avec ce paramétrage.

Le résultat contient stopReason, et l’interface affiche un avertissement lorsqu’il indique une limite de jetons atteinte. Ce signal concerne le diagnostic en cours.

Distinguez les limites d’entrée du débogueur de celles de sa réponse. Les limites de 500 caractères de contenu et de 2 000 caractères de contexte d’outils sont appliquées avant l’envoi à l’IA ; elles peuvent donc retirer des éléments utiles au diagnostic. Elles ne concernent pas seulement l’affichage. À l’inverse, stopReason égal à max_tokens indique que la sortie du modèle de diagnostic a été interrompue par son budget.

Coût et durée

Une analyse est une opération d’IA, avec d’éventuelles nouvelles tentatives techniques selon les réponses du service. Le coût dépend des jetons réellement traités et des règles applicables ; le résultat indique les crédits enregistrés. Certains échecs d’appel peuvent entraîner une pénalité : consultez le message et les transactions au lieu de supposer qu’un échec est gratuit.

Un historique et une configuration plus volumineux peuvent augmenter le coût et le délai dans les limites de collecte et d’abréviation décrites. Réduire la question à un problème précis facilite souvent l’interprétation sans garantir un coût ou un délai fixe.

Ce que le débogueur ne fait pas

Il ne corrige rien automatiquement. Il propose un diagnostic et des recommandations. Vous décidez des modifications autorisées sur les agents, prompts, outils ou champs de contexte.
Il ne rejoue pas la conversation. Il analyse les éléments conservés et la configuration actuelle reconstruite. Pour valider un changement, lancez une nouvelle conversation comparable.
Il ne garantit pas une cause unique. Plusieurs problèmes peuvent se combiner, et les données fournies peuvent être incomplètes. Utilisez le résultat comme une hypothèse étayée à vérifier.
Il ne remplace pas le journal d’incidents. Les exceptions et erreurs d’appel peuvent être consignées dans le journal d’incidents. Le débogueur de conversations peut intégrer certains incidents liés, mais l’outil de diagnostic d’un incident reste utile pour approfondir une défaillance technique.

Bonnes pratiques

Formulez une question précise. La saisie est obligatoire dans ce parcours. Indiquez le résultat attendu, l’écart observé et, si possible, le numéro de message, sans ajouter de données sensibles inutiles.

Vérifiez d’abord stopReason. Si le diagnostic lui-même est tronqué, affinez la question ou faites examiner son budget avant d’interpréter un résultat incomplet. Ce signal ne justifie pas à lui seul de changer l’agent analysé.

Contrôlez les preuves citées. Retrouvez la séquence dans la transcription et examinez les messages voisins. Les limites d’entrée et les erreurs d’interprétation peuvent expliquer une conclusion incorrecte.

Appliquez une modification à la fois. Choisissez une correction vérifiée, testez une conversation comparable puis réévaluez. Des changements simultanés compliquent l’identification de leur effet.

Consultez l’aperçu après correction. Ouvrez l’aperçu de l’exécution de l’agent pour vérifier la configuration prévue, puis confirmez le comportement par un test réel représentatif.

Questions fréquentes

Non. Il propose une cause et des recommandations. Vous vérifiez les preuves et appliquez les modifications autorisées, généralement dans un prompt, un outil ou des champs de contexte.

Oui, le débogueur peut lire les conversations et messages conservés par un parcours asynchrone. Attendez ou examinez l’état de traitement : une réponse en attente, absente ou en échec ne donne pas les mêmes éléments qu’un échange terminé. Consultez Traitement asynchrone des agents.

Le modèle peut renvoyer un texte qui ne correspond pas à la structure JSON attendue. Le contenu reste disponible dans rawAnalysis et peut être affiché comme solution de repli. L’interface peut aussi montrer ce texte lorsqu’aucune recommandation structurée n’est présente. Vérifiez d’abord un éventuel avertissement de troncature ; relancer consomme des crédits et ne garantit pas un résultat mieux structuré.

Oui, ces canaux peuvent produire les objets de conversation et de message examinés par le débogueur. L’accès, la disponibilité des données, l’agent lié et les limites de collecte restent déterminants ; le canal ne dispense pas de ces vérifications.

Décrivez plus précisément l’erreur, le résultat attendu et la séquence concernée, puis examinez les preuves disponibles. Une gravité low n’est pas un score de confiance et ne nie pas votre constat. Une question plus précise peut améliorer le diagnostic, sans garantir une augmentation de la gravité ni une conclusion particulière.

Consultez les incidents liés et l’outil de diagnostic des incidents pour les défaillances techniques. Le débogueur de conversations peut fournir un contexte complémentaire, notamment à partir des incidents récents chargés, mais ne remplace pas l’examen de l’exception.

Vérifiez les données réellement disponibles, la configuration au moment de l’exécution, les outils et un test reproductible. Les recommandations indiquent des pistes modifiables, mais une affirmation du débogueur selon laquelle le modèle a suivi sa configuration reste une hypothèse. Ne concluez pas à la cause sur cette seule appréciation.

Pour continuer

Consultez Transcriptions des conversations pour la structure des enregistrements, ou Diagnostiquer un incident avec l’IA pour le parcours centré sur une défaillance technique.

← Précédent : actions planifiées

Suivant : journaux d’incidents IA →