Pourquoi un chatbot de fiction oublie-t-il sa configuration après une longue conversation ? Un guide en cinq vérifications
Si un chatbot incarnant un personnage de fiction cesse de respecter sa configuration après de nombreux échanges, ce changement à lui seul n'en révèle pas la cause. Un détail oublié peut être sorti du contexte de conversation exploitable, ne pas avoir été renvoyé par un système de récupération, avoir été perdu ou modifié dans un résumé, être entré en conflit avec une autre instruction, ou n'avoir jamais été enregistré dans la mémoire persistante. Utilisez les cinq vérifications ci-dessous avec des détails fictifs anodins pour réduire le champ des hypothèses. Elles permettent d'identifier des tendances, mais sans accès aux journaux d'événements ou à la conception du chatbot, elles ne peuvent prouver le fonctionnement d'une application spécifique.
D'abord, séparer le symptôme de sa cause possible
Choisissez un détail qui doit rester stable et qui est facile à vérifier. Par exemple : « Mira, une gardienne de phare fictive, garde une boussole en laiton dans le tiroir vert du bureau. » Utilisez ce même fait tout au long des vérifications et posez une question précise telle que « De quelle couleur est le tiroir ? » Évitez les informations personnelles ou les détails ayant une importance en dehors du test.
Consignez l'invite exacte, la réponse, la longueur approximative de la conversation et indiquez si vous avez démarré une nouvelle discussion. Si vous testez le chatbot de quelqu'un d'autre, utilisez uniquement une configuration et une conversation de test auxquelles vous êtes autorisé à accéder. Ne tirez pas de conclusion à partir d'une seule réponse : la génération peut varier, et un oubli ponctuel ne permet pas de savoir si le fait était présent mais ignoré, ou absent des informations fournies au modèle.
La recherche invite à la prudence quant à l'interprétation des défaillances lors de longues discussions. Liu et ses collègues ont constaté que les performances sur des tâches de recherche d'information pouvaient varier selon la position du détail pertinent dans une longue entrée, faiblissant souvent lorsqu'il apparaissait au milieu. Leurs expériences portent sur des questions-réponses et la récupération de paires clé-valeur, et non sur le jeu de rôle fictif ou une application précise. Une étude de 2026 menée par Luz de Araujo et ses collègues a directement examiné la fidélité du persona dans des dialogues prolongés et a mis en évidence une dégradation au fil de la discussion sur l'ensemble des modèles évalués. Aucun de ces articles n'identifie la cause de la défaillance d'un chatbot particulier. ([Liu et al., « Lost in the Middle », 2024](https://aclanthology.org/2024.tacl-1.9/) ; [De Araujo et al., « Persistent Personas? », 2026](https://aclanthology.org/2026.eacl-long.246/))
1. Vérifier la présence d'une limite de fenêtre de contexte
Dans la discussion en cours, posez une question sur la boussole et le tiroir. Ouvrez ensuite une nouvelle conversation, fournissez à nouveau la configuration du personnage au début, puis posez la même question. Si la réponse fonctionne dans la nouvelle discussion mais échoue tardivement dans l'ancienne, l'hypothèse d'une limite de contexte étendu devient plausible. Le détail fourni n'est peut-être plus disponible sous la même forme, ou le modèle est peut-être moins apte à l'exploiter à mesure que la conversation s'allonge.
Cette tendance n'établit pas une limite précise de la fenêtre de contexte. La nouvelle discussion modifie également d'autres conditions : elle place le fait près du début et supprime les instructions ultérieures susceptibles d'entrer en concurrence avec lui. Une fenêtre de contexte correspond au volume de conversation et d'autres entrées qu'un système peut traiter en même temps ; ce n'est pas nécessairement la même chose que la mémoire enregistrée d'une discussion à l'autre. À moins que le service ne documente ses limites, n'en déduisez pas un nombre de tokens à partir d'un seul échec.
2. Vérifier un défaut de récupération
Si le service propose une fonctionnalité documentée de recherche, de rappel ou d'historique de conversation, testez s'il peut retrouver le texte exact de la configuration. Vous pouvez également demander au chatbot de récupérer le fait à partir de l'échange précédent pertinent, s'il s'agit d'une fonctionnalité prise en charge. Comparez le résultat avec la référence de la nouvelle discussion.
Si la configuration figure toujours dans un historique ou un registre de mémoire accessible mais que le chatbot ne l'utilise pas, un échec de récupération ou de sélection est une possibilité. Il peut aussi s'agir d'un effet lié à la position dans le contexte, d'une réponse de faible qualité ou d'une fonctionnalité fonctionnant différemment de ce qui était prévu. Sans voir quelles informations ont été fournies au modèle pour cette réponse, vous ne pouvez pas faire la distinction avec certitude. Ne supposez pas qu'un chatbot recherche dans chaque message passé simplement parce que l'interface affiche l'intégralité de la transcription.
3. Vérifier la présence d'un résumé obsolète ou avec perte d'informations
Certains systèmes peuvent condenser les répliques précédentes en un résumé plus court. Si l'application donne accès à ce résumé, vérifiez s'il mentionne toujours que le tiroir est vert et que la boussole est en laiton. S'il indique seulement que Mira « garde une boussole à proximité », posez une question précise sur la couleur omise et comparez la réponse avec la version dont vous avez explicitement fourni la configuration.
Un résumé erroné ou incomplet renforce l'hypothèse selon laquelle la compression a modifié ce qui a été conservé. Cependant, un résumé qui vous est visible n'est pas forcément celui utilisé par le système, et l'existence d'un résumé invisible ne peut être présumée. Ne considérez cette vérification comme une preuve que lorsque le produit donne réellement accès à l'enregistrement pertinent ou à sa documentation.
4. Vérifier un conflit d'instructions lié au persona
Gardez le fait inchangé, puis observez les instructions ultérieures qui pourraient influencer la manière dont la réponse est apportée. Une scène fictive pourrait préciser : « Mira est incertaine aujourd'hui et devine que le tiroir est bleu. » Cette instruction entre en conflit avec une configuration affirmant que le tiroir est vert. Posez une question factuelle neutre, puis une question formulée dans le cadre de la scène. Si le chatbot répond différemment, la formulation ou la priorité des instructions peut être en train d'influer sur la réponse.
Pour un test plus net, supprimez ou modifiez une instruction conflictuelle tout en conservant le reste de la configuration fictive à l'identique. Si le respect de la consigne réapparaît, le conflit constitue une explication plus solide qu'un simple oubli. Un chatbot peut également mal interpréter une instruction ou improviser ; un changement après modification ne révèle pas les règles de priorité internes du système. Les recherches sur le dialogue prolongé de persona démontrent que la fidélité au persona et le respect des instructions peuvent tous deux être évalués sur de longues interactions, mais elles ne permettent pas d'indiquer quelle règle prévaut pour un service particulier. ([« Persistent Personas? »](https://aclanthology.org/2026.eacl-long.246/))
5. Vérifier si la mémoire persistante est réellement conçue pour l'enregistrer
Un détail dans la discussion en cours, un profil de personnage enregistré et une mémoire transversale d'une discussion à l'autre sont des choses différentes. Consultez les paramètres ou la documentation propres au produit pour vérifier s'il propose des informations de personnage persistantes, si l'enregistrement doit être activé ou confirmé, et si l'élément sélectionné est censé être conservé d'une conversation à l'autre. N'utilisez une nouvelle discussion pour tester que si le service indique que la fonctionnalité doit s'y appliquer.
Si le produit ne dispose d'aucun moyen documenté d'enregistrer ce type de détail de personnage, l'incapacité à le rappeler dans une autre discussion ne prouve pas qu'une mémoire enregistrée a été effacée. S'il dispose d'une telle fonctionnalité, vérifiez l'entrée enregistrée visible et sa portée avant de tirer des conclusions. Une note enregistrée peut préserver le fait que le « tiroir est vert » sans exiger que chaque message précédent reste dans la conversation active, mais n'affirmez pas qu'une application fonctionne ainsi sans preuve spécifique au produit.
Analyser la tendance, pas seulement la dernière réponse
Utilisez les observations comme des indices, tout en veillant à ce que chaque interprétation reste plus nuancée que la tendance elle-même :
Observation : La nouvelle discussion avec la configuration fournie fonctionne ; la discussion ancienne et avancée échoue Interprétation possible : Sensibilité au contexte long ou à la position Ce que cela ne prouve pas : Une coupure nette de la fenêtre de contexte
Observation : Un historique ou une mémoire documentée contient le fait, mais la réponse l'omet Interprétation possible : Échec de récupération ou d'utilisation Ce que cela ne prouve pas : Que la récupération seule a causé l'oubli
Observation : Un résumé affiché omet ou modifie le détail Interprétation possible : Perte ou altération due au résumé Ce que cela ne prouve pas : Que l'entrée réelle du modèle a utilisé ce résumé
Observation : La suppression d'une instruction de scène conflictuelle rétablit la cohérence Interprétation possible : Conflit ou interprétation d'instructions Ce que cela ne prouve pas : La hiérarchie interne des instructions de l'application
Observation : Un détail est absent dans une nouvelle discussion et aucun enregistrement entre discussions n'est documenté Interprétation possible : Aucune voie démontrée de mémoire persistante Ce que cela ne prouve pas : Qu'une mémoire existante a été supprimée
Comment interpréter les tendances qui se recoupent
Si plusieurs tendances apparaissent, les causes peuvent se cumuler. Par exemple, un résumé pourrait omettre la couleur du tiroir tandis qu'une instruction ultérieure introduit également un tiroir bleu. Gardez chaque test de portée réduite, ne modifiez qu'une seule condition à la fois et conservez la formulation exacte afin que la comparaison demeure pertinente.
Distinguer cette vérification du ton et des comportements de correction
Un personnage qui sonne différemment constitue un symptôme distinct de l'oubli d'un fait précis de sa configuration. La cohérence du ton concerne le style, l'élocution ou les manières ; les vérifications ci-dessus portent sur la disponibilité et le respect d'un fait fictif concret. Une mise à jour du modèle ou du service pourrait modifier le style, mais à moins que le service ne documente un changement ou ne fournisse des informations comparables sur le modèle, une variation de voix ne prouve pas qu'une mise à jour a eu lieu.
De même, une correction acceptée dans une réponse n'est pas automatiquement une correction persistante. Testez-la d'abord dans la même discussion, puis dans une nouvelle discussion uniquement si le produit affirme que les corrections doivent être reportées. Si le personnage prend en compte une fois le fait que « le tiroir est vert » mais fait machine arrière par la suite, cela décrit la persistance de la correction ; cela n'identifie pas en soi si la cause relève du contexte, de la récupération, du résumé, d'un conflit d'instructions ou de la conception de la mémoire.
Pour un concepteur, ces cinq mêmes cas suggèrent une méthode d'évaluation pratique : garder constant un fait fictif anodin, faire varier la longueur de la conversation ainsi que la position du fait, afficher ou consigner les notes et résumés récupérés lorsque cela est approprié, introduire une instruction conflictuelle contrôlée, et préciser si le fait est censé persister d'une session à l'autre. Notez sur quelle source de vérité repose chaque test. Cela facilite la reproduction d'une défaillance et aide à distinguer un problème de contenu d'une attente que le produit n'a jamais promise.
Une conclusion rigoureuse doit nommer la preuve et sa limite : « La comparaison avec la nouvelle discussion suggère un effet lié à la longueur de la conversation, mais je ne peux affirmer si le détail a été tronqué, non récupéré ou supplanté. » Cela s'avère plus utile que de qualifier chaque oubli de défaillance de mémoire — et plus précis lorsque l'implémentation de l'application reste inconnue.