Pourquoi votre roleplay IA NSFW oublie l’histoire, et comment réparer sa mémoire

Votre personnage se rappelle la couleur de ses yeux, mais oublie sa promesse d’hier. Une relation construite toute une soirée revient au stade d’inconnus. Un secret est mentionné par quelqu’un qui n’était pas dans la pièce. Dans un long roleplay NSFW avec IA, ces erreurs peuvent ruiner une scène plus vite qu’une prose maladroite.

La correction pratique consiste à donner des emplacements distincts aux différents types de mémoire. Gardez identité et limites permanentes dans la définition du personnage. Placez lieu, relation et situation immédiate dans une courte note d’état actuel. Transformez les scènes terminées en résumés factuels d’événements. Faites revenir les anciens faits lorsqu’ils comptent, par lorebook ou système de recherche. Gardez les dialogues récents intacts pour préserver la voix du personnage.

Une fenêtre de contexte plus grande ajoute de l’espace, mais ne répare ni résumé faux ni relation périmée. Avant de payer un autre modèle, examinez ce que l’interface a réellement envoyé. Le fait manquant peut être sorti du prompt ; le fait faux peut encore s’y trouver.

Ce guide utilise SillyTavern car ses sources de mémoire sont visibles et modifiables. Les exemples suivent une romance fictive entre Mara, 32 ans, et Julian, 35 ans. Ce sont des exemples d’écriture, pas des transcriptions de tests. La même organisation convient à une autre interface permettant de modifier faits, résumés et notes persistantes.

Identifiez d’abord le type d’oubli

Toute réponse incorrecte n’est pas un problème de mémoire. Le personnage peut savoir qu’un événement a eu lieu et réagir d’une manière qui vous déplaît, garder les faits mais perdre sa voix, ou refuser une scène selon les règles du modèle ou du service. Ces problèmes demandent des changements distincts.

Pour la mémoire, choisissez une erreur concrète. Notez le fait attendu et trouvez le moment où il est devenu vrai. Comparez-le à l’information de la requête suivante. La documentation des prompts SillyTavern explique l’inspection du prompt assemblé, dont Prompt Itemization sur une réponse et l’extension facultative Prompt Inspector.

Vous cherchez l’une de ces situations :

• Le fait est absent. Il doit être reporté ou récupéré. Un rappel jamais envoyé ne peut pas aider.
• Le fait est présent avec une version ancienne. Retirez ou datez clairement l’ancienne. Un autre rappel peut aggraver la contradiction.
• Le bon fait est présent sans contradiction. Le modèle peut le lire de travers, deviner au-delà ou privilégier d’autres instructions. Clarifiez, retirez les distractions et essayez une courte suite avant de refaire toute la configuration.

Supposons que Mara invite Julian chez elle après leur deuxième rendez-vous. Dans la scène suivante, il demande si elle accepterait un premier rendez-vous. Si les rendez-vous manquent de la requête, l’historique s’est perdu. Si la fiche dit encore « ils ne se sont jamais rencontrés », la préparation est périmée. Si la requête décrit clairement les deux sorties et la relation actuelle, la génération n’a pas utilisé l’information fournie.

La distinction indique la suite. Un historique perdu demande une entrée mémoire. Une préparation périmée demande une modification. Une erreur de génération demande une suite corrigée ou un prompt plus ciblé. Installer une deuxième extension avant cette distinction ajoute des pièces sans corriger la cause.

Le tableau est un diagnostic initial, pas une promesse de cause unique. Chaque correction vise un texte précis au lieu de demander de « mieux se souvenir ».

Donnez cinq rôles à cinq types d’information

Une bonne mémoire d’histoire ne conserve pas chaque phrase. Elle garde ce dont la prochaine scène a besoin sans la noyer dans la prose d’hier. Pensez à ce que vous rappelleriez à un partenaire humain : qui sont ces personnes, ce qui a changé, ce qu’elles font maintenant et quels anciens moments les affectent encore.

Faits permanents : qui est cette personne

Utilisez la définition pour ce qui reste vrai pendant l’histoire : âge, identité, personnalité centrale, préférences établies, relations durables hors romance principale et limites du rôle de l’IA.

Pour Mara :

Mara est une photographe de restauration de 32 ans. Elle est observatrice, pratique un humour sec et parle lentement de ses sentiments privés. Sa sœur Leena vit dans une autre ville. Mara montre son affection par l’aide pratique avant de savoir l’exprimer directement. L’utilisateur contrôle les répliques, décisions et sentiments de Julian.

Cela donne une personne à écrire, sans exiger sœur, métier et explication de personnalité dans chaque scène. Cela ne signifie pas qu’elle reste distante pour toujours. Une tendance centrale doit permettre l’évolution.

La documentation de conception des personnages identifie les champs présents à chaque génération et explique que les longues définitions permanentes laissent moins de place à l’historique. Mettez-y l’identité essentielle ; déplacez ailleurs les longs décors et anecdotes.

Ne transformez pas la fiche en transcription croissante. Ajouter chaque rendez-vous, dispute et tenue brouille qui est Mara et ce qui lui est arrivé, tout en attachant une définition réutilisable à une seule intrigue. Gardez la fiche initiale propre et la relation évolutive dans la mémoire du chat.

État actuel : ce qui est vrai maintenant

Cet état change. Les personnages changent de pièce, règlent une dispute, voient partir un visiteur, se rapprochent ou demandent une pause. Ce ne sont pas des traits permanents.

Pour la scène actuelle :

Scène présente : vendredi soir, appartement de Mara, après leur deuxième rendez-vous. Mara et Julian sont à l’aise ensemble, mais n’ont pas discuté d’exclusivité. Mara vient de proposer un café. Julian n’a pas répondu. Leena est absente. Continue depuis cette offre en attente ; ne recommence pas leur présentation.

La note se lit vite et empêche un retour au départ. L’offre non répondue indique où l’histoire s’arrête. Sans elle, le résumé peut encourager le modèle à sauter le prochain choix utilisateur.

Dans SillyTavern, une Author’s Note propre au chat peut l’accueillir. Le guide Author’s Note décrit placement et fréquence. Pour un rappel de scène actif, zéro signifie aucune insertion ; un l’insère à chaque entrée utilisateur. Ce sont de vrais réglages ; le meilleur emplacement dépend du modèle et doit être inspecté.

Ne gardez pas une grande note inchangée toute la soirée. Une parfaite description d’appartement devient fausse dès leur départ. Remplacez-la au changement de scène plutôt que d’ajouter la nouvelle pièce sous l’ancienne.

Résumés d’événements : ce qui a réellement eu lieu

Une scène terminée va dans un résumé qui précise qui a fait quoi, ce qui a changé, les accords et les points ouverts. C’est un registre, pas une seconde écriture littéraire de la scène.

Pour notre exemple :

Vendredi, deuxième rendez-vous : Mara et Julian ont visité ensemble l’exposition nocturne. Julian a rendu la clé en laiton prêtée pour le studio. Mara a admis éviter une conversation difficile avec Leena. Julian a proposé de l’écouter sans contacter Leena lui-même. Ils ont convenu de se retrouver au studio dimanche après-midi. Plus tard, Mara l’a invité chez elle pour un café. Ils n’ont pas discuté d’exclusivité.

La clé rendue signifie que Julian ne l’a plus. La promesse sur Leena signifie qu’il ne doit pas l’appeler soudainement. Le rendez-vous de dimanche reste un projet, pas une visite achevée. La dernière phrase garde l’incertitude au lieu de transformer une soirée chaleureuse en relation officielle.

Le résumé peut omettre l’éclairage répété de l’exposition tout en gardant ces changements. C’est une mémoire sélective au service de l’histoire, pas une archive sans perte. Gardez la conversation originale pour retrouver les mots exacts.

Entrées de lorebook : ce qui ne doit apparaître qu’au bon moment

Un lorebook sert aux faits occasionnels : lieu, objet partagé, personnage secondaire ou événement antérieur important. Le studio n’a pas besoin d’une longue explication dans chaque dialogue de cuisine.

La documentation World Info décrit l’insertion conditionnelle par clés et autres réglages. Sauvegarder une entrée et l’activer sont distincts. Elle n’aide pas la prochaine réponse sans insertion effective.

Pour la clé, faites une entrée autonome :

Clé en laiton du studio : Mara l’a prêtée à Julian lors de sa première visite. Il l’a rendue à l’exposition du vendredi. Il ne possède actuellement aucune clé du studio. L’échange était un premier geste de confiance, pas une permission permanente d’entrer à volonté.

« Clé » seul déclenche trop largement une histoire parlant de clés d’hôtel, touches de piano ou décisions clés. Utilisez des expressions distinctives mentionnables naturellement, comme « clé du studio » ou « clé en laiton ». Un titre caché ou une liste de mots ne remplace pas l’explication ; le contenu inséré doit se suffire.

Pour cet exemple :

1. Dans World Info, créez ou choisissez un lorebook de l’histoire. Collez le paragraphe dans Content et entrez studio key, brass key dans Key. Gardez l’entrée activée.
2. Ouvrez Character Management → Chat Lore et choisissez le livre pour cette conversation. Si un livre est déjà lié, Chat Lore ouvre l’éditeur ; Shift+Click sur ordinateur ou appui long sur mobile rouvre le choix.
3. Mentionnez « brass key » dans une continuation, puis ouvrez Prompt Itemization sur la réponse. Cherchez le paragraphe de restitution dans la requête. Sa présence confirme l’insertion, pas son bon usage par la réponse.

Mémoire par recherche : ce qui peut servir dans une grande archive

La recherche retrouve les éléments liés à la conversation plutôt que d’insérer tout l’historique. Elle aide les histoires à nombreux chapitres, mais peut ramener une ancienne situation : proximité thématique ne signifie pas « vérité actuelle ».

La documentation Chat Vectorization explique la recherche dans le chat passé et le compromis de cache. Le guide Data Bank traite les documents joints et leurs périmètres. Ils ont des fonctions distinctes ; aucun n’est un interrupteur magique de continuité parfaite.

Pour une romance courte avec peu d’événements, commencez par résumés corrigés et entrées claires. Ajoutez la recherche à un besoin réel qu’ils gèrent mal : par exemple un détail du chapitre douze important au trente. Garder la relation actuelle en note permanente est plus simple que la faire retrouver à chaque tour.

Faits de personnage, état actuel et événements passés ont des fonctions différentes ; le dialogue récent maintient la voix.

Une petite configuration avant toute installation

Vous pouvez réparer un chat sans reconstruire l’interface. La première version utile demande seulement définition, note d’état et résumé lisible. Vous avez un endroit pour le fait qui disparaît.

Sauvegardez d’abord la conversation avant modification des mémoires. SillyTavern propose export et checkpoints dans son guide de gestion des chats. Le texte simple facilite la lecture ; JSONL garde les métadonnées pour réimporter. Images et pièces jointes sont séparées.

Faites trois modifications :

1. Retirez les conditions initiales périmées. Cherchez « Mara et Julian ne se sont jamais rencontrés » ou « Julian n’a pas gagné sa confiance ». Gardez-les seulement si la fiche est volontairement un template initial et si le prompt dit que les événements ultérieurs les remplacent. Sinon elles ramènent l’histoire au début.
2. Décrivez l’état actuel en moins de quelques paragraphes. Lieu, présents, relation, action immédiate et dernier choix sans réponse. Omettez ce qui ne change pas la prochaine réplique.
3. Résumez les anciens événements pertinents. Promesses, résolutions, découvertes et plans. Marquez les questions ouvertes « non établi » au lieu de laisser le modèle combler les trous.

Vous pouvez copier cette note manuelle :

Histoire en cours de Mara, 32 ans, et Julian, 35 ans. Ils se sont rencontrés plusieurs fois et sont chez Mara après leur deuxième rendez-vous. Ils s’intéressent mutuellement l’un à l’autre sans accord d’exclusivité. Mara a parlé de son conflit avec Leena ; Julian a promis de ne pas contacter Leena en son nom. La visite du studio est prévue dimanche et n’a pas encore eu lieu. Mara a proposé un café et attend la réponse. Écris la réaction de Mara à la prochaine action de Julian sans décider celle-ci à sa place.

Continuez avec une phrase modeste sans nouveau contexte : « Julian accepte le café et demande quel mug elle recommande. » Vérifiez que Mara reste chez elle, le traite comme une connaissance et garde le problème familial à sa juste place. Vous ne testez pas tout le modèle, mais la suffisance de l’état réparé pour une suite ordinaire.

Si le reset continue, inspectez encore la requête. La note peut être désactivée, un lorebook la contredire ou l’interface utiliser un autre chat ou persona. Si la requête est correcte, corrigez ou régénérez la mauvaise réponse avant qu’elle ne devienne exemple du tour suivant. Continuer comme si l’erreur s’était produite peut en faire un fait historique.

Écrivez des résumés qui gardent les changements plutôt que l’atmosphère

Un résumé vague peut sembler raisonnable tout en perdant le détail essentiel. « Mara et Julian ont vécu une soirée émouvante et se sont rapprochés » laisse presque tout ouvert : secret révélé ? promesse ? dispute résolue ? prochain rendez-vous ?

Séparez observations et interprétations. Si Mara dit confier son appareil à Julian, gardez cette confiance précise, pas « elle lui fait totalement confiance ». Si Julian soupçonne une lettre cachée, gardez le soupçon, pas une découverte. La fiction adulte comporte implications et hésitations ; la mémoire doit les conserver plutôt que les lisser.

Voici une demande de résumé manuel hors format requis par une extension :

Résume la scène achevée comme des notes de continuité d’une fiction en cours. Garde actions établies, changements de relation, promesses, objets rendus ou transférés, découvertes, lieu actuel et plans inachevés. Précise les témoins des révélations privées. Distingue faits confirmés, suppositions, possibilités imaginées et intentions futures. N’ajoute ni motivation, ni engagement, ni événement non établi par le dialogue. Termine par la dernière action sans résolution. Utilise une langue concise et simple, avec les noms plutôt que des pronoms ambigus.

C’est une aide d’écriture, pas un preset universel testé. Elle convient à un résumé manuel en texte. Une extension attendant du JSON structuré doit conserver son format ; le remplacer par cette prose peut casser la création mémoire.

Prenons un résumé volontairement erroné :

Mara et Julian sont devenus un couple après l’exposition. Elle lui a tout raconté sur sa sœur et donné accès au studio. Il a décidé d’aider en appelant Leena. Ils sont allés à l’appartement et ont bu un café.

Presque chaque phrase change l’histoire. « Devenus un couple » invente un engagement. « Tout » exagère la révélation. « Accès » ignore la clé rendue. « Décidé » invente un choix de Julian. « Bu un café » saute l’offre encore en attente.

Réparez selon la conversation, pas par une formulation plus élégante. Le bon résumé est la note factuelle précédente. Devant un résumé automatique, cherchez la conservation des décisions réellement prises, pas le style d’une quatrième de couverture.

Rendez explicites les absences importantes

Le plus important est parfois ce qui n’a pas eu lieu : exclusivité non discutée, Julian n’a pas rencontré Leena, contenu de la lettre non révélé, visite de dimanche non réalisée.

Ces phrases empêchent les raccourcis narratifs. Utilisez-les en cas de confusion plausible, pas pour lister tout ce qui n’est jamais arrivé. « Pas encore de discussion d’exclusivité » compte ; « ils n’ont jamais visité Mars » ne compte pas.

Gardez une cause émotionnelle concrète

Un registre totalement sec conserve les faits mais perd leur importance. Gardez une cause précise : « Mara s’est détendue quand Julian a rendu la clé sans demander à la garder. » La suite a matière à réagir sans imposer une nouvelle personnalité permanente.

Comparez à « Mara est désormais heureuse ». Pourquoi, combien de temps, dans quelle scène ? La cause concrète autorise ensuite des sentiments mêlés. L’étiquette vague la réduit à une humeur jusqu’à la prochaine actualisation.

Séparez l’archive du récapitulatif actif

Une archive détaillée peut coexister avec un récapitulatif court. L’archive répond à « que s’est-il passé dans ce chapitre ? » ; l’actif à « que doit respecter la prochaine réponse ? ». Ils n’ont pas besoin de même longueur.

Après dix scènes, l’archive peut inclure rencontre, studio, exposition, appartement et plans de dimanche. La scène d’appartement nécessite seulement relation actuelle, promesse pertinente et arrêt du dialogue. Si la clé revient, récupérez son historique spécifique.

Cela évite aussi de transformer la mémoire en devoirs. Ne réécrivez pas toute l’histoire tous les deux messages. Enregistrez les changements significatifs, gardez un petit état actuel et laissez les détails ordinaires dans l’historique récent jusqu’à la fin de scène.

Utilisez Summarize intégré pour un récapitulatif glissant simple

L’extension Summarize intégrée est un premier choix raisonnable pour garder le fil général. Ouvrez-la dans Extensions et choisissez une source fonctionnelle. Main API utilise la connexion active. Lisez le premier Current summary et corrigez-le avant de vous y fier.

Le guide officiel Summarize documente aussi Pause et Restore Previous. Ils aident lorsqu’une mise à jour invente un engagement ou omet une promesse. Arrêtez les mises à jour pour réparer, ou restaurez l’ancien résumé puis ajoutez les bons changements.

Choisissez l’intervalle selon votre conversation, pas comme un nombre rituel. Vingt réponses courtes peuvent peu avancer ; vingt longues peuvent contenir confrontation, révélation et déplacement. Actualisez avant sortie des faits importants de l’historique actif et après un changement de scène pertinent pour la suite.

Pour commencer, résumez manuellement aux fins de scène. Lisez deux ou trois résultats et repérez les omissions habituelles. Activez ensuite un intervalle adapté à vos longueurs réelles. Vous aurez une base utile au lieu de découvrir une semaine plus tard que chaque résumé changeait la relation.

Le résumé glissant est pratique, mais recomprimer l’ancien peut perdre de petits faits. Protégez une promesse durable dans sa propre entrée plutôt que d’espérer sa survie. Le récapitulatif dit « promesse sur Leena toujours active », l’entrée garde sa portée exacte.

Ne confiez pas toute la voix au résumé. Il garde les événements. Les messages récents et un court dialogue conservent humour sec, rythme et registre. Ajouter un long style dans chaque note les rend moins lisibles et peut submerger la conversation lorsque plusieurs s’activent.

Utilisez Memory Books pour des souvenirs modifiables par scène

ST Memory Books sert lorsqu’un seul récapitulatif glissant ne suffit plus. Au lieu d’une synthèse changeante, gardez des souvenirs individuels et corrigez ceux qui comptent. Pour une longue romance, premier rendez-vous, révélation familiale et clé rendue restent des registres séparés lisibles.

Une discussion SillyTavern récente cite les extensions de mémoire, notamment STMB, comme amélioration de l’expérience de son auteur. Une autre discussion sur les extensions de résumé montre le choix entre lorebooks modifiables et outils plus automatiques. Ce sont des préférences individuelles, pas une preuve contrôlée d’amélioration pour tout modèle.

Commencez par le guide de démarrage du projet pour installation, sélection et première mémoire manuelle. Choisissez un livre adapté, le profil Current SillyTavern Settings, marquez début et fin d’une scène terminée, puis créez une mémoire. Ouvrez-la avant l’automatisation.

Lisez les prérequis actuels avec une connexion locale ou Text Completion. Le projet décrit des exigences supplémentaires et une sortie structurée ; un modèle bon en dialogue peut mal produire le JSON requis. Conservez le format intégré pendant le premier essai.

Choisissez un événement court terminé. L’exposition convient : début, objet rendu, révélation et plan. Sélectionner toute la soirée jusqu’à l’échange inachevé d’appartement augmente la confusion entre faits achevés et prochaine possibilité.

Une fois le manuel fonctionnel, le guide utilisateur Memory Books décrit création automatique, sélection de scènes et autres commandes. Il suggère vingt à trente messages au départ, sans garantir l’adéquation à toute scène. Lisez les premières entrées et ajustez à votre écriture.

La routine est simple : laissez l’extension garder les changements ordinaires et corrigez les évolutions qui nuiraient à la continuité si déformées. Pour l’exposition, vérifiez auteur de la restitution, témoins du problème familial, plan de dimanche en attente et engagement de couple réellement établi ou non.

N’installez pas trois résumeurs ensemble. Leurs trois versions légèrement différentes peuvent concurrencer la même soirée dans la requête. Commencez par un système d’événements et une note actuelle claire ; ajoutez un outil pour un autre problème précisément nommé.

Corrigez les faits, pas le style : clé rendue et plan inachevé doivent le rester dans la mémoire.

Actualisez la relation sans réécrire le personnage

La dérive relationnelle est particulièrement frustrante en NSFW, où les scènes dépendent de confiance, familiarité et incertitude. Un modèle gardant le lieu mais oubliant la relation peut écrire une scène techniquement cohérente qui sonne complètement faux.

Utilisez deux registres : l’un explique les événements qui ont changé la relation, l’autre son état actuel. Le premier est historique ; le second présent.

Événement historique :

Après l’exposition, Mara a invité Julian chez elle. Elle a dit être à l’aise seule avec lui et apprécier qu’il ne l’ait pas pressée sur Leena. C’était leur deuxième rendez-vous. Aucun n’a proposé l’exclusivité.

Relation actuelle :

Mara et Julian se fréquentent et montrent leur intérêt avec aisance. Ils découvrent encore leurs préférences respectives. Ils n’ont pas convenu d’exclusivité et ne doivent pas présumer des décisions futures de l’autre.

S’ils s’engagent ensuite, actualisez le second et gardez le premier en historique. Une mémoire ultérieure peut dire « Dimanche : accord d’exclusivité ». L’état actuel porte alors la nouvelle relation. L’incertitude du vendredi reste historique, pas une consigne présente concurrente.

Ne réduisez pas toute la relation à un score. Une confiance de quatre-vingts sur cent ne dit pas si Mara confie un secret, un objet ou une présentation familiale. Les nombres peuvent servir une mécanique de jeu volontaire, mais remplacent mal une phrase sur la vraie relation.

Gardez consentement et préférences concrets. « Mara préfère discuter des changements avant de s’engager » guide une nouvelle invitation. « Mara a accepté la visite de dimanche » enregistre un accord précis. Aucun ne vaut accord illimité à la suite.

Le but n’est pas d’insérer une leçon dans l’histoire, mais de préserver les choix que le résumé risque d’effacer. Une relation intéresse parce que des questions restent ouvertes. La mémoire les reporte sans répondre à la place de l’utilisateur.

Empêchez les anciens souvenirs de supplanter les nouveaux

Une recherche peut ramener le bon sujet au mauvais moment. Parler du studio peut activer une ancienne dispute et sa réconciliation. Sans ordre ni résolution, le modèle peut rouvrir le conflit.

Datez les entrées avec un changement clair. « Première visite : Mara était mal à l’aise quand Julian a déplacé les éclairages sans demander » vaut mieux que « Mara est mal à l’aise avec Julian au studio », qui ressemble à une condition permanente.

Écrivez la résolution comme autre événement :

Deuxième visite : Julian s’est excusé d’avoir déplacé le matériel et a demandé avant de toucher autre chose. Mara a accepté. Le désaccord est résolu ; elle préfère toujours que les visiteurs demandent avant de déplacer son matériel.

Régler la dispute n’efface pas la préférence. La relation s’améliore et la règle demeure. C’est plus utile que supprimer tous les souvenirs négatifs ou ignorer tous les anciens problèmes.

Si une entrée obsolète s’active toujours, réécrivez son présent en faits historiques. Si elle ne vaut rien hors état périmé, désactivez-la. Gardez l’état actif à un seul endroit, sans notes imbriquées « ignore la mémoire précédente ».

Marquez les plans : « prévu », « terminé », « annulé », « modifié ». « Rendez-vous au studio dimanche » peut paraître actuel. « Plan en attente : dimanche après-midi, pas encore réalisé » prête moins à confusion.

Quand dimanche arrive, notez visite ou annulation et actualisez le plan. Si l’histoire avance de deux semaines, retirez l’invitation expirée de l’état actuel, sans quoi elle peut revenir comme action urgente longtemps après.

Attribuez les secrets à ceux qui les connaissent réellement

L’une des pires erreurs est le secret divulgué par le narrateur. Un résumé peut dire correctement que Mara a expliqué son conflit à Julian. Puis une scène de groupe donne à Leena le détail de cet échange sans qu’on le lui ait rapporté.

Mémoire d’événement et connaissances du personnage diffèrent. L’archive peut savoir qu’un événement a eu lieu ; chaque personnage ne doit réagir qu’à ce qu’il a vu ou appris. Inscrivez la distinction dans la mémoire du secret.

Par exemple :

Conversation privée vendredi soir : Mara a dit à Julian ne pas avoir répondu à la lettre de Leena. Julian l’a entendu directement. Leena sait qu’elle a envoyé la lettre, mais ignore cette discussion. Personne d’autre n’était présent.

Écrivez ensuite depuis Leena. Elle peut remarquer le malaise ou demander si la lettre est arrivée. Elle ne doit pas connaître la promesse de Julian sans événement le lui apprenant.

En groupe, gardez les noms explicites. « Elle lui a parlé d’elle » est fragile avec trois femmes et deux hommes. « Mara a parlé de Leena à Julian » est moins littéraire mais bien plus utile.

Cela ne garantit pas une séparation parfaite dans les sorties, mais donne une limite inspectable. Si le secret fuit encore, corrigez avant de poursuivre et cherchez un résumé qui le présente comme public.

Ne supprimez pas tout le secret : vous corrigeriez Leena en retirant ce que Julian doit garder. Préservez le même événement avec les bons témoins au lieu d’aplatir toute information privée.

Séparez les branches avant une autre issue

Explorer les issues fait partie du roleplay. Une branche peut voir Julian accepter dimanche, une autre demander du temps. Elles partagent définitions et histoire antérieure, pas les registres modifiables des événements suivants.

Nommez-les simplement « Dimanche accepté » et « Dimanche reporté ». Gardez un état propre à chacune et vérifiez le livre attaché avant création. Si les deux écrivent dans un livre évolutif commun, la recherche peut dire à la branche acceptée que l’invitation a été refusée.

Un checkpoint garde le chat à la bifurcation, mais ne supposez pas que toutes les extensions ou sources externes isolent leurs données de la même façon. Examinez le livre actif après branchement. Lisez la documentation actuelle sur copie et verrouillage avant de vous y fier.

En cas de contamination, identifiez les entrées postérieures. Copiez les pertinentes vers la bonne branche et désactivez-y les autres. Partagez l’avant-branche seulement s’il est inchangé. Un trait permanent peut être commun ; l’issue d’un échange propre à une branche ne le peut pas.

Pour redémarrer, distinguez trois intentions. « Nouvelle conversation avec le même personnage » peut partir du scénario initial. « Même histoire dans un nouveau chat » demande état et mémoires pertinentes. « Histoire alternative avec la même distribution » demande un historique évolutif séparé. Les confondre fait mémoriser un rendez-vous inexistant dans cette version.

À l’export ou synchronisation d’appareil, emportez sources de mémoire et chat. Une conversation visible ne prouve pas le transfert du lorebook, document ou état d’extension. Ouvrez les sources sur destination et vérifiez un fait incontestable avant de poursuivre.

Les issues alternatives peuvent partager le passé ; leurs événements ultérieurs demandent des mémoires séparées.

Changez de modèle sans lui faire deviner toute l’histoire

Un changement peut modifier la voix malgré les mêmes faits, la quantité d’historique disponible et l’interprétation du preset. Le nouveau modèle n’hérite pas d’une mémoire invisible ; il voit ce que l’interface envoie.

Préparez une transmission compacte : identité, relation, dernière scène pertinente, plans en attente et court exemple de voix. Omettez l’archive complète sauf besoin réel de la scène suivante.

Pour Mara :

Continue une histoire existante. Mara est une photographe de 32 ans à l’humour sec qui préfère les gestes pratiques. Julian a 35 ans et est contrôlé par l’utilisateur. Ils se fréquentent après leur deuxième sortie, pas une première rencontre. Ils sont chez Mara. Julian a accepté le café. La visite au studio dimanche reste en attente. Il a promis de ne pas contacter Leena en son nom. Mara parle brièvement ; elle esquive avec une petite plaisanterie puis répond honnêtement. Ne décide pas la réponse de Julian.

Un exemple original de voix peut être : « Le mug ébréché, c’est pour les gens que j’aime. La belle porcelaine, pour ceux que j’essaie d’impressionner. » Il transmet rythme et personnalité sans mur de commandes stylistiques.

Pour comparer, donnez la même transmission et demandez une continuation du café. Regardez lieu, plan, limite de connaissances et voix. Ne comparez pas un ancien modèle après deux heures de dialogue façonné à un nouveau ayant reçu une seule phrase d’accueil.

Le guide des modèles de roleplay traite ce choix distinct. Réparez d’abord la mémoire lorsque le prompt contient le mauvais fait. Un modèle plus capable peut suivre un mauvais résumé ; un moins cher peut suffire à une scène bien organisée.

Séparez les règles de contenu de ce contrôle. Un refus ne prouve pas un rendez-vous oublié. Une suite chaleureuse mais moins adulte n’est pas automatiquement un échec de mémoire. Regardez l’état envoyé et la réponse avant de changer outil, prompt ou modèle.

Un changement de modèle nécessite les mêmes faits et un petit exemple de voix, pas une nouvelle première rencontre.

Réduisez le coût de mémoire sans perdre l’essentiel

Les longues entrées coûtent sur les API au token : le texte de chaque requête contribue à l’usage d’entrée. Créer les mémoires peut demander des appels séparés. Une extension gratuite à installer n’est pas nécessairement gratuite à exploiter.

Vous pouvez raisonner sans prix de modèle précis. Supposons qu’une requête utilise quarante mille tokens d’entrée contre douze mille pour une version ciblée. Sur cinquante réponses, cela fait deux millions contre six cent mille tokens, avant cache ou autres détails de prix. Ce sont des calculs illustratifs, pas une facture mesurée ni une économie promise.

La vraie question est quels vingt-huit mille tokens ont disparu. Des descriptions répétées et scènes périmées peuvent être retirées sans perte utile. Si c’était la seule promesse de Julian, la requête peut coûter moins et fonctionner moins bien. La compression vaut lorsqu’elle garde les changements significatifs.

Résumer chaque message peut aussi coûter davantage et créer des mémoires inutiles. Une offre de café simple ne mérite peut-être pas un job ; une révélation sur Leena probablement oui. Commencez aux fins de scène ou selon l’intervalle disponible, et lisez si les limites produisent des entrées cohérentes.

La recherche peut compliquer le cache car le contenu choisi change à chaque tour, compromis signalé officiellement par Chat Vectorization. Si votre API bénéficie de prompts répétés, comparez l’usage réel après activation au lieu de supposer que moins de messages visibles fait toujours baisser la facture.

Pour une session personnelle, les économies simples viennent souvent d’une fiche allégée, d’un état court et de résumés automatiques non redondants. Pour une application, identifiez si la mémoire se génère à chaque tour, en arrière-plan ou à une limite choisie. Les schémas de requêtes et coûts diffèrent.

Ne rendez pas chaque fait toujours actif pour éviter les erreurs de recherche : vous renverriez toute l’archive. Réservez l’espace permanent à identité, état actuel et contraintes essentielles ; le reste apparaît selon pertinence.

Quand l’outil semble fonctionner mais que l’histoire casse encore

Une notification de réussite peut seulement signifier qu’une mémoire a été créée. Elle ne prouve ni exactitude, ni activation, ni bon usage. Suivez le fait à travers ces étapes.

Ouvrez d’abord l’entrée. Si elle dit que Julian a gardé la clé, corrigez avant la recherche. Aucun réglage d’activation ne rend vrai un mauvais texte. Si la restitution manque, ajoutez-la ou régénérez depuis la bonne scène.

Examinez ensuite source et activation. Livre lié au chat ? Mot-clé jamais employé ? Filtre excluant le personnage ? Place dans le budget ? Vérifiez les options de l’entrée au lieu de relever tous les plafonds globaux.

Inspectez enfin la requête. La mémoire peut être sauvegardée et éligible mais déplacée par une autre source. Cherchez « a rendu la clé en laiton » et la contradiction « garde la clé du studio ». Trouver les deux explique l’échec malgré une bonne mémoire apparente.

Lisez alors la suite générée. Avec fait correct et sans contradiction, essayez une phrase d’état plus directe pour cette scène. Si l’échec continue, autre génération ou modèle peut convenir. Vous avez exclu la mémoire absente ou corrompue au lieu de changer d’outil aveuglément.

Gardez la question petite. « Pourquoi le modèle est-il mauvais en mémoire ? » se résout mal. « Pourquoi donne-t-il une clé à Julian alors que l’entrée dit qu’il l’a rendue ? » mène à source, déclencheur, requête et correction. C’est une réparation terminable avant la scène suivante.

Une routine reproductible pour une longue fiction adulte

Avant la session, lisez l’état actuel plutôt que tout l’historique. Confirmez lieu, relation, plans et qui doit décider. Trente secondes peuvent repérer un état périmé avant dix nouveaux messages.

Pendant la session, laissez le dialogue ordinaire tranquille. Sauvegardez lorsqu’un changement survient : promesse, découverte, résolution, limite, objet transféré ou plan réalisé. Avec l’automatique, examinez les entrées autour de ces changements sans relire chaque échange trivial.

À la fin de scène, séparez événement et présent. Enregistrez ce qui s’est passé puis remplacez la note par l’endroit où l’histoire s’arrête. N’ajoutez pas un nouveau « présent » sous trois anciens présents.

Avant une branche, copiez ou séparez l’évolutif. Avant un modèle, préparez transmission et voix. Avant un appareil, confirmez les sources transférées. Chaque action évite un reset différent, sans rallonger la fiche.

Le résultat visé est modeste mais précieux : promesse gardée, relation sans redémarrage et prochaine scène commençant au point d’arrêt précédent. Commencez par un fait gênant. Le voir dans la bonne mémoire et dans la requête réelle donne une base bien plus solide pour juger la réponse suivante.