Mémoire active et mémoire persistante en IA : comment l’IA se souvient, retrouve des informations et oublie

La mémoire active désigne les informations dont un système d’IA dispose pour accomplir la tâche en cours. La mémoire persistante correspond aux informations que l’application qui l’entoure conserve afin de pouvoir les réutiliser ultérieurement. La façon dont ces deux mémoires s’articulent détermine si un assistant peut poursuivre un projet, appliquer une préférence, corriger une hypothèse dépassée ou cesser de faire réapparaître un élément qu’il aurait dû oublier.

Prenons l’exemple d’un assistant qui vous aide à préparer un rapport de recherche. Au cours d’une conversation, il peut se référer au plan, à vos dernières modifications et aux sources que vous venez de lui fournir. Si vous ouvrez une autre conversation une semaine plus tard, la continuité dépend d’un mécanisme différent : l’application a-t-elle enregistré les informations pertinentes, peut-elle les retrouver et les transmettre de nouveau au modèle ?

C’est pourquoi une IA peut sembler se souvenir d’un détail tout en en oubliant un autre au cours du même échange. Le souvenir résulte d’une chaîne d’opérations. Une défaillance peut survenir lors de la collecte, du stockage, de la recherche, de la sélection, de l’interprétation ou de la mise à jour des informations.

Ce guide examine cette chaîne en détail. Pour découvrir une taxonomie plus générale de la mémoire épisodique, sémantique et procédurale, consultez notre introduction aux types de mémoire des agents d’IA. Nous nous intéressons ici à la frontière entre ce qui est actif à l’instant présent et ce qui peut persister au-delà de la tâche en cours.

Que signifient réellement mémoire active et mémoire persistante ?

Ces termes décrivent des distinctions architecturales utiles, mais ne forment pas une paire universellement normalisée. Les interfaces des produits et les articles de recherche emploient de manière parfois similaire les expressions « mémoire de travail », « mémoire à court terme », « contexte », « état » et « mémoire à long terme ». Pour les expliquer avec précision, il faut donc d’abord les définir.

Dans cet article, le contexte actif désigne les informations fournies au modèle pour qu’il produise sa réponse actuelle : consignes, messages, résultats d’outils sélectionnés, éléments récupérés et autres données que le modèle peut traiter. L’état actif de la tâche est une notion plus large. Il peut comprendre un plan, une liste de contrôle ou des variables gérées par l’application, mais qui n’ont pas encore été intégrées au contexte du modèle. Nous employons « mémoire active » comme terme générique pratique pour désigner cet ensemble de travail actuel, tout en distinguant ces deux notions lorsque c’est nécessaire.

La mémoire persistante désigne les informations conservées au-delà d’une réponse ou d’une session et qui restent disponibles pour une utilisation ultérieure. Il peut s’agir d’une préférence enregistrée, d’une note de projet, d’un compte rendu d’événement, d’un champ structuré dans une base de données ou d’un point de sauvegarde permettant de reprendre une tâche inachevée. La persistance décrit la conservation des informations ; elle ne garantit pas qu’elles seront partagées dans toutes les conversations.

Il faut donc distinguer deux questions : Les informations existent-elles toujours ? et Le modèle les recevra-t-il lorsqu’il en aura besoin ? Une transcription enregistrée peut répondre à la première question sans résoudre la seconde.

L’exception importante : un état à court terme peut être enregistré

« À court terme » ne signifie pas toujours « stocké uniquement dans une mémoire vive volatile ». L’état de travail d’une conversation peut être sauvegardé dans une base de données sous forme de point de contrôle, puis rétabli après une interruption. La documentation de LangChain sur la mémoire, par exemple, distingue l’état associé à un fil de discussion, conservé au moyen de points de contrôle, de la mémoire à plus long terme, organisée dans des espaces de noms distincts.

Imaginez un agent d’assistance qui se met en pause en attendant qu’un client téléverse un reçu. Le point de sauvegarde enregistré correspond à ce dossier d’assistance. Il est durable, mais ne devrait pas automatiquement devenir une information générale sur le client ni apparaître dans des demandes sans rapport avec ce dossier.

Pour évaluer une fonctionnalité de mémoire, il est utile de s’interroger sur trois dimensions : sa durée de conservation, son périmètre et sa disponibilité lors de l’appel de modèle en cours. Une appellation comme « à long terme » ne répond complètement à aucune de ces questions.

Mémoire active et mémoire persistante en un coup d’œil

Un même fait peut figurer dans les deux colonnes. Une préférence de projet enregistrée est persistante ; la copie insérée dans l’invite du jour est active. Supprimer cette copie de l’invite ne supprime pas nécessairement l’original enregistré.

Que se passe-t-il pendant une réponse unique de l’IA ?

Dans une application classique fondée sur un modèle de langage, le logiciel environnant prépare une entrée, le modèle génère une sortie, puis le logiciel détermine la suite. L’entrée peut contenir la conversation visible, mais aussi des instructions système, des descriptions d’outils, des notes récupérées et des informations que l’utilisateur ne voit pas dans la transcription de la conversation.

Ce contexte assemblé constitue les éléments de preuve immédiatement accessibles au modèle. Si un message antérieur n’est plus inclus, le modèle ne peut pas en retrouver de manière fiable le contenu exact simplement parce que l’application l’a affiché auparavant. Il peut déduire une réponse plausible à partir des indices environnants, mais la déduction n’est pas la remémoration.

Un outil étend ce à quoi le système peut accéder. Le modèle peut demander un fichier de projet, en recevoir le contenu et l’utiliser dans une réponse ultérieure. Le fichier était accessible à l’application avant de devenir un élément de preuve actif. Cette distinction explique pourquoi un agent peut accéder à une vaste archive sans la lire intégralement à chaque interaction.

En interne, les implémentations de transformeurs conservent également un état de calcul, notamment des caches qui évitent de répéter certaines opérations. Ces mécanismes favorisent l’efficacité de l’inférence, mais il ne faut pas les confondre avec un dossier modifiable, tenant compte des autorisations, qui consignerait les préférences ou l’historique de projet d’un utilisateur. Une réponse plus rapide ne prouve pas qu’une mémoire personnelle a été créée.

Pourquoi une fenêtre de contexte plus grande ne résout pas le problème de la mémoire

Une fenêtre de contexte plus grande permet à une application de fournir davantage de contenu à la fois. Cela peut être utile lorsque la réponse dépend des liens entre différentes parties d’un long document ou entre plusieurs sources connexes. Toutefois, cela ne détermine pas quelles informations doivent être conservées, quelle version fait autorité ni si un utilisateur est autorisé à y accéder.

Le fait de faire tenir des informations dans une fenêtre de contexte ne garantit pas non plus que le modèle les utilisera correctement. L’étude Perdu au milieu a montré que les modèles testés pouvaient obtenir des résultats différents selon l’emplacement des éléments de preuve pertinents dans les longues entrées. Ce résultat invite à évaluer l’utilisation effective du contexte, plutôt qu’à considérer la capacité annoncée comme une garantie de mémorisation ; il ne constitue pas une prédiction fixe des performances de tous les modèles plus récents.

Imaginons qu’une archive de projet contienne quarante discussions sur une date de lancement. Trente-neuf mentionnent la date initiale, et la dernière modification approuvée la repousse. Fournir les quarante discussions pose un problème de lecture et de hiérarchie des sources. Un relevé de l’état actuel soigneusement tenu à jour et lié à la modification approuvée peut faciliter l’établissement de la réponse pertinente.

Un contexte étendu et une récupération sélective peuvent donc se compléter. La récupération permet de trouver un ensemble utile d’éléments de preuve ; un contexte suffisamment grand permet au modèle de les examiner ensemble. Le choix de conception dépend de la tâche, du volume des sources et des conséquences d’une réserve omise.

Comment l’information devient une mémoire persistante

La création d’une mémoire durable commence par une décision d’enregistrement. Une application peut sauvegarder une instruction explicite de l’utilisateur, déduire un fait potentiel d’une conversation, conserver un événement ou créer un résumé. Chaque méthode produit un type différent d’élément de preuve.

« Pour le projet Cedar, utiliser les unités métriques » est une préférence de projet explicite. « L’utilisateur semble préférer les unités métriques » est une déduction. « Les trois derniers rapports Cedar utilisaient les unités métriques » est une observation. Un dossier utile conserve ces distinctions au lieu de les fondre en une affirmation sans réserve valable pour toutes les tâches à venir.

Contenu d’un dossier utile

Pour un assistant de projet hypothétique, une fiche pourrait contenir l’énoncé, l’identifiant du projet, l’utilisateur ou l’organisation auquel il se rapporte, l’interaction dont il provient, un horodatage, un statut de validité et toute exception. Ces champs permettent de déterminer d’où vient l’information et si elle s’applique toujours.

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

Il s’agit d’un schéma donné à titre d’exemple, et non d’une norme universelle. Il vise à montrer pourquoi une mémoire doit contenir plus qu’une phrase. Une référence à la source facilite la vérification ; la portée évite les généralisations abusives ; un champ de statut permet d’apporter des corrections.

Écritures immédiates ou traitement en arrière-plan

Une écriture immédiate peut rendre une correction explicite disponible dès la requête suivante. Un traitement en arrière-plan peut examiner une interaction terminée, regrouper les doublons ou produire un résumé plus réfléchi. La documentation de LangChain décrit ces deux approches et leurs compromis, notamment le travail supplémentaire qu’une écriture immédiate ajoute au processus de réponse.

Une conception pratique pourrait enregistrer immédiatement une préférence confirmée, puis traiter ultérieurement une longue session de recherche. Elle doit néanmoins gérer l’intervalle entre ces deux étapes. Si le système indique à l’utilisateur qu’il a enregistré une préférence avant que l’écriture ait abouti, la conversation suivante peut révéler une rupture de continuité.

Les écritures en mémoire doivent également prévoir une stratégie en cas d’échec. Si le stockage est temporairement indisponible, l’application peut signaler que l’enregistrement n’a pas abouti ou conserver une opération en attente clairement identifiée comme telle. Présenter une tentative d’écriture comme une mémoire enregistrée donne une expérience trompeuse à l’utilisateur.

Comment la mémoire persistante réintègre le contexte actif

La récupération repose sur une série de décisions concernant l’admissibilité, la pertinence et les éléments de preuve. Le système doit d’abord déterminer l’utilisateur, le locataire, le projet ou la tâche dont il peut consulter les données. Il recherche ensuite des fiches candidates et sélectionne celles à inclure dans le contexte de la réponse.

La méthode de récupération doit être adaptée à la question. La question « Quelle est l’échéance approuvée pour Cedar ? » trouvera peut-être sa meilleure réponse dans une recherche exacte dans les champs du projet. La question « Avons-nous déjà rencontré cette erreur de déploiement ? » pourrait tirer parti d’une recherche par mots-clés et par similarité sémantique dans les incidents passés. Une base de données vectorielle est une option parmi d’autres dans ce processus, et non une exigence pour toute mémoire.

La recherche sémantique est particulièrement utile lorsque la formulation change. Une requête portant sur « des rapports concis » pourrait correspondre à une préférence enregistrée pour de « courts résumés de direction ». Toutefois, une déclaration connexe peut concerner un autre client ou une version abandonnée du projet. La similarité permet de repérer des éléments candidats ; elle ne prouve ni leur véracité ni l’autorisation de les utiliser.

La récupération doit prévoir le cas où rien n’est trouvé

Prenons la question : « Quel plafond de dépenses ai-je approuvé le mois dernier ? » Si aucun montant approuvé ne peut être retrouvé, une réponse utile indique que les éléments de preuve manquent et demande des précisions. Fournir un chiffre plausible revient à transformer une absence de mémoire en autorisation inventée.

L’interface de mémoire devrait donc distinguer une correspondance confirmée, une correspondance incertaine, un conflit et l’absence de document à l’appui. Ces résultats peuvent entraîner des comportements différents : répondre directement, nuancer la réponse, demander une précision ou refuser d’agir sur la base d’une hypothèse non étayée.

Même après la recherche, l’interprétation reste importante. Une entrée indiquant « budget maximal proposé : 5 000 $; approbation en attente » ne doit pas devenir « budget approuvé : 5 000 $ ». Conserver les réserves dans la représentation stockée et dans le contexte fourni est aussi important que de trouver le bon document.

Exemple détaillé : se souvenir d’un projet au fil du temps

Imaginons un assistant qui aide une équipe à produire le rapport de recherche Cedar. L’exemple qui suit est hypothétique, mais il met en lumière plusieurs choix courants en matière de conception de la mémoire.

Session 1 : définir le projet

L’utilisateur demande un rapport, précise qu’il faut utiliser les unités métriques, fournit trois sources et indique que le brouillon doit être remis vendredi. Le contexte actif comprend ces instructions et les extraits des sources. L’état actif de la tâche consigne les sections terminées et les affirmations qui restent à vérifier.

Les éventuelles entrées persistantes ont des objectifs différents. La préférence pour les unités métriques relève du projet. L’échéance du brouillon concerne l’étape en cours. Les sources fournies doivent être versées aux archives documentaires du projet. Les affirmations non vérifiées doivent figurer dans une liste de recherches en attente, en conservant leur caractère incertain.

Session 2 : reprendre le travail avec les bons éléments

Trois jours plus tard, l’utilisateur demande de terminer la section consacrée aux méthodes. L’assistant a besoin du plan le plus récent, des sources pertinentes, de l’état actuel de la tâche et de la règle de mise en forme applicable. Il n’a pas nécessairement besoin de chaque phrase écartée lors de la séance de remue-méninges précédente.

Si le point d’étape indique que la revue de la littérature est terminée, l’assistant devrait tout de même ouvrir le document enregistré avant de modifier les sections qui l’entourent. « Terminé » décrit l’avancement ; le document lui-même atteste ce qui a été achevé. Des liens durables vers les documents peuvent être plus utiles qu’un résumé qui tente d’en reproduire l’intégralité.

Session 3 : appliquer une exception sans tout réécrire

L’utilisateur demande une édition destinée aux clients qui utilise à la fois les unités métriques et impériales. La tâche en cours doit donc employer les deux systèmes. La modification de la règle générale du projet dépend du libellé et de la portée de la demande : « pour cette édition » est plus restreint que « à partir de maintenant, utilise les deux systèmes ».

Un assistant attentif consigne une exception propre à cette édition. Un assistant qui généralise à l’excès modifie la préférence globale et introduit des erreurs dans les rapports ultérieurs. Il s’agit d’une défaillance de la mémoire, même si toutes les opérations d’écriture dans la base de données et toutes les demandes de recherche aboutissent.

Session 4 : terminer le travail et supprimer les données temporaires

Après la livraison, l’étape doit être marquée comme terminée. Une instruction telle que « poursuivre le rapport » devrait amener l’assistant à consulter la version livrée et à demander quelle révision est nécessaire, plutôt qu’à reprendre une ancienne liste de tâches. Les notes de travail temporaires peuvent expirer conformément aux règles du projet, tandis que le rapport final et les décisions importantes restent accessibles.

La valeur de la mémoire persistante apparaît clairement ici : elle réduit les explications répétées et améliore la continuité. Son coût est tout aussi évident : l’application doit maintenir les liens entre les préférences, les exceptions, les documents et l’évolution de l’état des tâches.

Résumé, condensation et risque de perdre l’exception

Les interactions longues peuvent accumuler plus d’informations qu’il n’en faut pour la réponse suivante. La condensation remplace une partie de cet historique par une représentation plus brève. Un résumé peut conserver l’objectif, les décisions, les questions en suspens et les liens vers les travaux sous-jacents.

Les recommandations d’Anthropic sur l’ingénierie du contexte décrivent la condensation et les notes stockées hors de la fenêtre de contexte comme des méthodes permettant d’assurer la continuité lors de travaux prolongés. Ces deux techniques modifient les informations disponibles pour les réponses ultérieures ; leur qualité est donc importante.

La compression est sélective. Un résumé tel que « Utiliser les unités métriques » est plus court que « Utiliser les unités métriques, sauf dans l’édition destinée aux clients, qui exige les deux systèmes ». Il est également erroné dans l’un des cas importants du projet. L’exception perdue peut se retrouver discrètement dans les résumés suivants et devenir difficile à retracer.

Pour notre assistant Cedar, un meilleur relais conserverait la règle générale, son exception, les sections terminées, les vérifications restantes et les références aux fichiers les plus récents. Les détails exacts, comme les montants approuvés ou les identifiants, devraient rester dans des documents sources ou des enregistrements structurés lorsque les approximations risquent d’être préjudiciables.

Les résumés devraient également préserver l’incertitude. « Nous avons envisagé d’utiliser le sondage B » ne doit pas devenir « Le sondage B a été choisi ». Si l’historique condensé présente des décisions provisoires comme définitives, le système crée un faux souvenir en tentant d’économiser du contexte.

Comment l’IA devrait gérer les corrections et les conflits mémoriels

La mémoire persistante perd de son utilité si elle ne peut pas évoluer. Les projets changent, les préférences évoluent et les informations antérieures se révèlent parfois erronées. Ajouter une correction sous la forme d’un nouvel enregistrement sans préciser son statut peut laisser le système de récupération choisir entre deux affirmations contradictoires.

Une mise à jour plus utile indique ce que les nouveaux éléments viennent remplacer. Si le responsable du projet reporte la date de lancement du 15 novembre au 29 novembre, l’ancien enregistrement peut être marqué comme remplacé et lié à la nouvelle décision. Les questions portant sur l’échéance actuelle s’appuient sur la nouvelle version ; celles portant sur le plan initial peuvent consulter la version historique.

La récence ne suffit pas à résoudre tous les conflits. Une note de brouillon récente peut faire moins autorité qu’une politique approuvée plus ancienne. Un utilisateur peut être autorisé à modifier une préférence personnelle sans l’être à modifier une règle applicable à toute l’organisation. La politique de mise à jour doit tenir compte de la nature du fait et de l’autorité de sa source.

Certaines contradictions doivent rester sans résolution jusqu’à ce qu’une personne les clarifie. Si deux responsables de projet donnent des dates incompatibles sans préciser explicitement que l’une remplace l’autre, l’assistant peut présenter les deux sources et demander laquelle fait foi. Choisir silencieusement l’enregistrement le plus similaire ou le plus récent masque une décision que le système n’est peut-être pas habilité à prendre.

Que signifie l’oubli pour l’IA ?

L’oubli ne se résume pas à un simple interrupteur. Un produit peut cesser d’insérer un fait dans les requêtes, l’exclure des recherches courantes, le marquer comme obsolète, supprimer son enregistrement mémoire ou effacer d’autres copies conservées. Ces opérations ont des effets différents sur les comportements futurs et sur les données conservées.

Sortir du contexte actif

Un fait peut disparaître de la prochaine entrée du modèle parce que des messages anciens ont été omis ou résumés. Cela réduit ce que le modèle peut utiliser immédiatement. La transcription originale ou l’enregistrement en mémoire peut toutefois subsister et réapparaître lors d’une récupération ultérieure.

Expiration ou neutralisation du rappel

Une échéance dépassée peut rester dans une archive tout en étant exclue des requêtes portant sur le travail en cours. La neutralisation est utile lorsqu’il y a lieu de conserver les données historiques, mais ne doit pas être présentée comme une suppression complète. Une recherche historique ou un processus administratif peut toujours accéder à l’enregistrement.

Suppression de la mémoire stockée

La suppression d’un enregistrement durable doit également porter sur les représentations utilisées pour le récupérer qui en dérivent. Si une phrase est retirée d’un profil, mais reste présente dans un résumé consultable, l’assistant peut reconstituer la même préférence ultérieurement. Selon l’architecture, les enregistrements sources, les représentations vectorielles, les résumés, les caches et les répliques peuvent nécessiter des opérations de suppression distinctes.

Les sauvegardes et les journaux peuvent suivre leurs propres calendriers de conservation. Un produit doit expliquer clairement ces limites et empêcher que du contenu supprimé redevienne actif lors d’une restauration. « Nous n’utiliserons plus cette mémoire » et « toutes les copies conservées ont été supprimées » sont deux engagements différents.

Modification des paramètres du modèle

La suppression d’une mémoire externe ne modifie pas, à elle seule, les paramètres du modèle. Si des informations ont été utilisées lors de l’entraînement, les traiter dans le modèle est un problème distinct qui concerne les processus d’entraînement et de déploiement. De même, supprimer une mémoire personnelle ne peut garantir que le modèle ne générera jamais un fait similaire à partir de connaissances générales ou d’indices fournis dans une nouvelle requête.

Un test pertinent de l’oubli consiste donc à vérifier à la fois si le système stocke encore l’information et si ses mécanismes habituels de récupération peuvent la réintroduire. Une seule réponse du type « J’ai oublié » ne prouve ni l’un ni l’autre.

Mémoire, RAG, entraînement et mise en cache : où se situent les limites

La génération augmentée par récupération, ou RAG, fournit au modèle des éléments externes pendant la génération. Les travaux initiaux sur le RAG associaient les paramètres du modèle à un index de documents interrogeable. Un système de mémoire personnelle peut lui aussi recourir à la récupération, mais il doit également prévoir des règles pour créer, mettre à jour et retirer les données issues des interactions.

Un manuel d’entreprise peut être récupéré sans pour autant constituer un souvenir concernant l’utilisateur. Une note portant sur une interaction précédente peut être récupérée à partir d’un simple fichier, sans index vectoriel. La récupération est un mécanisme ; c’est l’objectif et le cycle de vie des données sous-jacentes qui déterminent le type de système mis en place.

L’entraînement et le réglage fin modifient les paramètres du modèle. La mémoire externe ordinaire, elle, modifie les éléments fournis au modèle. Un assistant qui suit une préférence nouvellement enregistrée peut se comporter différemment alors même que les poids de son modèle restent inchangés.

La mise en cache des prompts et de l’inférence permet de réutiliser des calculs antérieurs lorsque cela est pris en charge. Elle peut améliorer l’efficacité, mais ne permet pas à elle seule de déterminer si une information mémorisée est à jour, autorisée ou adaptée à de futures tâches. Ces couches peuvent coexister ; pour diagnostiquer un problème, il faut donc identifier celle qui est responsable du comportement observé.

MemGPT en fournit un exemple architectural marquant : ce système explorait le transfert d’informations entre un contexte limité et des niveaux de mémoire externe, en s’inspirant du fonctionnement d’un système d’exploitation. La leçon à en tirer est qu’il faut gérer explicitement les transferts d’informations, plutôt que de supposer que le stockage augmente automatiquement et sans limite le contexte immédiatement accessible au modèle.

Pourquoi la mémoire persistante peut rendre les erreurs plus durables

Une réponse erronée peut affecter une interaction. Un souvenir erroné peut en affecter beaucoup. Si un assistant déduit qu’un utilisateur a approuvé une décision, enregistre cette déduction comme un fait, puis cite ultérieurement l’enregistrement, sa propre erreur antérieure peut alors prendre l’apparence d’un élément de preuve indépendant.

Pour notre assistant de projet, la source originale doit rester distincte de l’interprétation du modèle. Un résumé d’une décision peut faciliter la navigation, mais toute action lourde de conséquences doit s’appuyer sur la décision approuvée elle-même. La répétition d’une déduction non étayée dans plusieurs notes générées ne la transforme pas en plusieurs confirmations indépendantes.

La mémoire persistante ouvre également la voie à la contamination des instructions. Un document non fiable pourrait contenir une phrase demandant à l’assistant de modifier son comportement à l’avenir. Enregistrer cette phrase comme règle de fonctionnement ferait franchir à un contenu externe une frontière d’autorité. L’application doit traiter ce contenu en fonction de sa source, au lieu de le promouvoir au rang d’instruction fiable simplement parce qu’il figure dans un espace de stockage de mémoire.

Les environnements partagés ajoutent une autre frontière à respecter. Un fait peut être pertinent pour une question tout en appartenant à un autre client ou projet. Les contrôles d’accès doivent limiter la récupération des informations avant qu’elles ne parviennent au modèle. Demander au modèle d’ignorer les données auxquelles il n’est pas autorisé à accéder après les lui avoir déjà fournies est une approche moins robuste.

Comment évaluer le fonctionnement réel de la mémoire

Une démonstration convaincante demande souvent à l’assistant de répéter une préférence enregistrée. Une évaluation rigoureuse suit l’évolution des informations sur plusieurs sessions et vérifie si la mémoire améliore l’exécution de la tâche.

LongMemEval évalue l’extraction d’informations, le raisonnement entre plusieurs sessions, le raisonnement temporel, la mise à jour des connaissances et la capacité à s’abstenir de répondre. Ces catégories montrent pourquoi la qualité de la mémoire à long terme ne se résume pas à retrouver une phrase correspondante. Les résultats publiés sur les bancs d’essai doivent être interprétés en fonction des systèmes et des configurations testés, et non considérés comme représentatifs de tous les produits actuellement disponibles.

Pour le flux de travail Cedar, une évaluation pourrait introduire une préférence, reprendre le projet, ajouter une exception, réviser une échéance, supprimer une note, puis poser des questions conçues pour faire ressortir les souvenirs obsolètes ou non étayés. Il faudrait également tester le même modèle sans la fonctionnalité de mémoire afin de déterminer si le système ajouté améliore les résultats.

• Exactitude de l’enregistrement : Le système a-t-il enregistré l’énoncé voulu, avec sa portée et ses réserves ?
• Utilité de la récupération : A-t-il trouvé les éléments nécessaires à la tâche sans encombrer le contexte d’un historique sans rapport ?
• Gestion des mises à jour : Une correction a-t-elle remplacé le fait actuel tout en préservant les distinctions historiques utiles ?
• Abstention : L’assistant a-t-il reconnu l’absence de données à l’appui ?
• Isolement : Les données sont-elles restées réservées au bon utilisateur, au bon locataire et au bon projet ?
• Oubli : La suppression ou l’expiration a-t-elle empêché la récupération ultérieure prévue, y compris à partir de résumés dérivés ?
• Coût opérationnel : Les améliorations justifiaient-elles l’augmentation de la latence, du nombre d’appels au modèle, du stockage et de la maintenance ?

Les défaillances doivent être retracées jusqu’à l’étape où elles surviennent. Une réponse manquante peut s’expliquer par un échec de l’écriture, un périmètre de recherche inadapté, une mauvaise décision de classement, une réserve omise ou un modèle qui a mal interprété des éléments probants pertinents. Augmenter la taille du contexte ne corrigera pas toutes ces défaillances.

Choisir la bonne architecture mémoire

Un résumé ponctuel d’un document peut ne nécessiter que le document en cours et les instructions. Une analyse interrompue gagne à être accompagnée d’un point de reprise. Un assistant de projet récurrent peut avoir besoin de décisions versionnées et de références aux artefacts. Un assistant intervenant dans de nombreuses sessions utilisateur peut avoir besoin d’un espace de stockage distinct et modifiable pour les préférences.

Commencez par préciser la question à laquelle la mémoire devra répondre à l’avenir. « Qu’est-ce qui reste à terminer ? » appelle un état de la tâche. « Quel format ce client exige-t-il ? » appelle une préférence dont le champ d’application est défini. « Pourquoi avons-nous rejeté cette approche ? » appelle un relevé de décision étayé par des éléments probants. À des questions différentes correspondent des représentations différentes.

Privilégiez un petit nombre de relevés clairs et attribuables plutôt qu’une archive sans discernement présentée comme une personnalisation. Distinguez l’état actuel des événements passés, conservez les liens vers les artefacts sources et intégrez dès le départ les possibilités de correction et de suppression à la conception.

La mémoire active donne à un système d’IA un présent cohérent. La mémoire persistante peut lui assurer une continuité dans le temps. La qualité de cette continuité dépend des décisions prises entre les deux : ce qui est enregistré, ce qui est réutilisé, quelle version fait foi et ce qui peut être supprimé.