Comment faire en sorte qu'un chat de personnage se souvienne d'une correction de l'utilisateur d'une session à l'autre
Lorsqu'un utilisateur corrige les détails d'un personnage de fiction, le chat doit enregistrer la version corrigée avec sa portée, remplacer toute version antérieure contradictoire, et rendre la note enregistrée visible et modifiable. Il doit également distinguer les préférences durables de l'utilisateur des faits qui ne s'appliquent qu'à l'intérieur d'une seule scène de l'histoire. Avant d'utiliser ultérieurement un détail mémorisé, le système doit vérifier qu'il est pertinent et d'actualité ; si les éléments ne sont pas clairs, il doit poser une question plutôt que d'inventer un passé commun. Ce guide se concentre sur cette tâche de persistance et de résolution de conflits, et non sur la façon de réagir à un malentendu sur le moment.
De quoi un chat de personnage doit-il se souvenir ?
Prenons un exemple illustratif : un utilisateur dit : « Les yeux de Mira sont verts, pas bleus. » La correction peut faire référence à un détail permanent du personnage, à une version temporaire de Mira dans un jeu de rôle particulier, ou simplement à la préférence de l'utilisateur quant à la façon dont Mira est décrite. Une mémoire qui n'enregistre que « yeux : verts » perd le contexte qui rend ce fait utile.
Un enregistrement mémoriel pratique doit saisir au minimum le sujet, le détail corrigé, la portée, et si l'utilisateur souhaitait qu'il persiste. Par exemple :
Cette structure est une recommandation de conception de produit, et non un format prescrit par les études. Son objectif est d'empêcher qu'un détail spécifique à une scène ne se transforme discrètement en un fait global. Une correction propre à une scène pourrait plutôt être enregistrée sous la forme : « Dans la scène du bal d'hiver, Mira porte une cape verte. » Cette note ne doit pas écraser sa tenue ou son apparence générale.
Comment une correction doit-elle remplacer un souvenir plus ancien ?
Traitez une correction explicite comme une mise à jour du fait concerné, et non comme un fait supplémentaire qui laisserait les deux versions actives. Si le système conserve « Mira a les yeux bleus » et ajoute « Mira a les yeux verts », une récupération ultérieure risque de faire ressortir l'un ou l'autre. L'enregistrement mis à jour doit marquer l'ancienne valeur comme remplacée ou la retirer de l'utilisation active, tout en préservant suffisamment d'historique pour expliquer le changement si le produit propose un journal de mémoire.
Cette distinction est essentielle car les informations peuvent évoluer au fil du temps. Dans *[Keep Me Updated! Memory Management in Long-term Conversations](https://aclanthology.org/2022.findings-emnlp.276/)*, Bae et ses collègues présentent une tâche et un jeu de données pour suivre les informations mises à jour sur les utilisateurs à travers plusieurs sessions de conversation. Ils représentent les souvenirs sous forme de descriptions textuelles et proposent d'éliminer de manière sélective les informations invalidées ou redondantes. Leurs expériences comparent cette approche avec des bases de référence qui laissent les souvenirs stockés inchangés. L'étude porte sur la mémoire conversationnelle à long terme ; elle ne teste pas spécifiquement les chats de personnages de fiction et n'établit pas un modèle de mémoire universel.
Pour un chat de personnage, appliquez prudemment la même logique générale de mise à jour : une correction directe « pas bleus — verts » constitue une preuve solide que l'ancienne valeur est incorrecte dans le cadre de la portée définie. Un nouveau détail de scène ne prouve pas automatiquement qu'un fait durable du personnage a changé. Lorsque la portée est absente et que la différence a de l'importance par la suite, posez une brève question de suivi telle que : « Dois-je me souvenir que Mira a les yeux verts dans chaque histoire, ou seulement dans cette version ? »
Comment le système peut-il séparer les préférences de l'utilisateur des faits de l'histoire ?
Stockez les préférences et les faits du monde fictif dans des catégories distinctes. Une préférence peut être : « L'utilisateur préfère que les répliques de Mira soient concises. » Un fait de l'histoire peut être : « Dans cette scène, Mira vient d'arriver à la gare. » Ils répondent à des questions différentes : la préférence guide la façon dont le chat répond, tandis que le fait de l'histoire aide à maintenir la continuité au sein du récit.
Attribuez une portée aux deux. Une préférence peut s'appliquer à l'ensemble des chats, à un seul personnage ou uniquement au jeu de rôle en cours. Un fait de l'histoire peut s'appliquer à une scène, à un arc narratif ou au profil général du personnage. Ne déduisez pas une préférence générale à partir d'une seule correction. Si un utilisateur dit « Les yeux de Mira sont verts », cela ne signifie pas en soi que l'utilisateur souhaite que tous les personnages aient les yeux verts, ni que ce détail s'applique à chaque version alternative de Mira.
Une séquence de décision simple permet d'y parvenir :
Ces étapes constituent une proposition de flux de travail issue du défi consistant à maintenir les informations conversationnelles à jour. Elles ne prétendent pas qu'un produit de chat en particulier les applique.
Comment gérer les souvenirs contradictoires ?
Résolvez les conflits en comparant le sujet, la portée et la temporalité, et non en favorisant aveuglément la phrase la plus facile à récupérer. Une correction explicite et plus récente de l'utilisateur doit généralement prévaloir sur une version antérieure du même fait au sein de la même portée. Un détail provenant d'un jeu de rôle différent ne doit pas supplanter la scène actuelle. Si le système ne peut pas déterminer si deux enregistrements concernent la même version d'un personnage, il doit les garder séparés ou poser la question.
Par exemple, supposons qu'un souvenir plus ancien indique : « Mira a les yeux bleus », tandis qu'un message ultérieur précise : « Pour cette histoire d'univers alternatif, Mira a les yeux verts. » La seconde affirmation met à jour l'apparence de Mira pour cette histoire, mais ne modifie pas nécessairement le profil par défaut du personnage. Si l'utilisateur dit : « En fait, donne-lui les yeux verts à partir de maintenant », la portée est plus large et la fiche par défaut peut être mise à jour. Ne fusionnez pas silencieusement des versions contradictoires en prétendant que l'utilisateur a toujours décrit Mira de la même façon.
Les systèmes de mémoire doivent également disposer d'un moyen de gérer l'incertitude. Si deux enregistrements ont des dates ou des portées incertaines, marquez le conflit comme non résolu au lieu d'affirmer l'un ou l'autre détail avec aplomb. Une brève question est préférable à un souvenir affirmé avec assurance mais sans fondement.
Comment les utilisateurs peuvent-ils voir et contrôler ce qui a été mémorisé ?
Après avoir enregistré une correction, confirmez la modification précise : « C'est noté, je retiendrai que Mira a les yeux verts dans la description générale de son personnage, en remplacement du détail précédent sur ses yeux bleus. » Si le système enregistre un fait plus restreint, précisez-le : « Je conserverai la cape verte comme détail propre à cette scène. » Cette confirmation donne à l'utilisateur la possibilité de repérer immédiatement une erreur de portée.
Une interface de mémoire doit présenter la formulation enregistrée et sa portée en langage clair, avec une option pour la modifier ou la supprimer. Si le produit permet d'afficher les entrées remplacées, il doit les marquer comme obsolètes plutôt que de les présenter comme étant d'actualité au même titre que les autres. Cela aide les utilisateurs à comprendre pourquoi un chat de personnage évoque un détail et à corriger les données sans avoir à répéter toute l'histoire.
Évitez de sous-entendre qu'un souvenir existe lorsqu'il n'a pas été enregistré, ou de prétendre que le personnage se souvient d'un échange passé que le système ne peut pas vérifier. Un personnage peut s'exprimer de manière naturelle tout en laissant l'interface ou la réponse être transparente sur les informations réellement stockées.
Comment tester le rappel ultérieur ?
Testez la persistance d'une session à l'autre, et pas seulement au sein de la conversation où la correction a été effectuée. L'[étude sur la compréhension situationnelle de Yang et Ettinger](https://aclanthology.org/2023.emnlp-main.394/) évalue ChatGPT à l'aide d'un environnement synthétique conçu pour vérifier s'il suit et rapporte les changements d'état de l'environnement. Les auteurs signalent des erreurs dans la conservation des états au fil du temps et mentionnent la mémoire en contexte non persistante ainsi que la vulnérabilité aux mises à jour hallucinées comme facteurs dans leur cadre d'étude. Il s'agissait d'une étude contrôlée de ChatGPT dans cet environnement, publiée en 2023 ; elle ne constitue pas une preuve valable pour chaque modèle actuel, produit ou système de personnages fictifs.
Un test ciblé pour un chat de personnage peut s'appuyer sur un petit ensemble de conversations scénarisées :
Évaluez chaque test par rapport à la portée voulue : récupération correcte, remplacement approprié des anciennes informations, séparation des faits de scène et des faits généraux, et traitement honnête de l'incertitude. Incluez des cas où la réponse attendue consiste à demander une clarification. Un système qui refuse de manière fiable de deviner lorsque ses notes stockées sont ambiguës gère mieux la situation qu'un système qui invente une continuité.
Un parcours fiable de la correction au rappel
Une correction doit suivre un cheminement clair : identifier son sujet, préserver sa portée, mettre à jour toute mémoire contradictoire, afficher la modification enregistrée et vérifier que les réponses ultérieures la récupèrent sans l'extrapoler en un historique infondé. Cette séquence offre à un chat de personnage une méthode concrète pour rester cohérent au fil des répliques et des sessions, tout en laissant le contrôle de l'univers de fiction à l'utilisateur. La recherche confirme l'importance de traiter avec rigueur les mises à jour mémorielles et le suivi d'état ; le flux de travail présenté ici constitue une recommandation de conception, et son comportement doit être validé au sein du produit dans lequel il sera appliqué.