Comment la mémoire partagée et la mémoire personnelle peuvent-elles coexister dans un agent IA familial ?
Les mémoires partagées et personnelles peuvent coexister dans un même agent familial d’IA lorsque la mémoire est modélisée sous forme d’enregistrements à portée définie, avec des propriétaires et des règles d’accès explicites, plutôt que comme une transcription ou une collection de vecteurs couvrant tout le foyer.
Le problème architectural n’est pas de savoir si plusieurs personnes peuvent interroger le même modèle. Il s’agit de déterminer si le pipeline de mémoire peut distinguer, au moment de l’écriture, un fait concernant le foyer d’une préférence privée, préserver cette distinction dans le stockage, la faire respecter lors de la récupération, puis la supprimer ou la remplacer sans modifier l’état d’une autre personne.
La mémoire familiale nécessite plusieurs niveaux de portée
Une conception utile sépare au moins la mémoire personnelle, la mémoire du foyer volontairement partagée et l’état de session à courte durée de vie. « Le modèle du lave-linge est X » peut relever du foyer, tandis que « Je préfère une température de 19 °C dans la chambre » devrait normalement rester associé à la personne qui l’a exprimé. Les déductions de session ne devraient pas devenir silencieusement une mémoire durable dans l’un ou l’autre niveau de portée.
Une étude de 2026 consacrée à une infrastructure de mémoire multiutilisateur décrit des configurations de mémoire privée, partagée et gouvernée, au lieu de traiter la mémoire multiutilisateur comme un stockage unique et indifférencié. Pour un agent domestique, la principale implication de conception est que le partage constitue une décision de politique associée à une mémoire, et non un effet secondaire du fait que plusieurs utilisateurs pointent vers la même base de données.
La limite de portée doit être appliquée avant la récupération. Si le système récupère les mémoires de tout le monde et demande au modèle de langage d’« ignorer les éléments privés », l’isolation a déjà échoué. Le modèle ne devrait recevoir que les enregistrements que l’utilisateur authentifié et le contexte actuel du foyer sont autorisés à utiliser.
Le propriétaire, la provenance et le niveau de confiance doivent accompagner la mémoire
Une préférence durable devrait indiquer qui l’a formulée, d’où elle provient, si elle a été explicitement exprimée ou déduite, quand elle a été observée et si un enregistrement plus récent la remplace. Sans provenance, un agent familial ne peut pas distinguer une instruction directe d’un schéma fragile déduit du comportement d’une seule personne.
L’analyse 2026 d’Oracle sur la mémoire typée multilocataire préconise une identité de locataire explicite et une isolation au niveau du schéma, plutôt que de s’appuyer sur des conventions dans les prompts. Un déploiement domestique est plus restreint, mais la même leçon de modélisation des données s’applique : les identifiants de l’utilisateur et du foyer doivent être stockés avec l’enregistrement et leur utilisation doit être contrôlée sous la couche des prompts.
L’article connexe de ZimaSpace sur les préférences domestiques incorrectes explique ce qui se produit lorsqu’un comportement déduit se transforme en vérité partagée. L’architecture présentée ici évite cet échec en faisant de la promotion d’un état personnel ou déduit vers la mémoire du foyer une transition explicite.
La politique de récupération est le point où le mélange des mémoires devient généralement visible
Deux espaces de stockage correctement séparés peuvent tout de même se divulguer des informations si une requête de récupération omet le filtre utilisateur, si une clé de cache ignore l’identité ou si une recherche sémantique partagée renvoie des enregistrements avant le filtrage des autorisations. L’isolation de la mémoire doit donc être maintenue tout au long de la requête : recherche, reclassement, mise en cache et construction du prompt.
Un modèle d’implémentation 2026 consacré à la récupération de mémoire par utilisateur présente une récupération à portée de locataire, dans laquelle chaque utilisateur voit son propre état tandis que l’application peut continuer à utiliser un service de mémoire partagé. Le mécanisme essentiel n’est pas la bibliothèque utilisée, mais l’association de l’espace de récupération à une identité fiable plutôt qu’à un texte fourni par le modèle.
La mémoire partagée doit être ajoutée comme une seconde portée autorisée, et non comme solution de repli lorsque la récupération personnelle ne renvoie rien. Cette distinction empêche que « aucune information connue sur cet utilisateur » devienne « utiliser la préférence de quelqu’un d’autre ». L’absence d’un fait personnel est plus sûre qu’une substitution accidentelle entre utilisateurs.
La suppression et la résolution des conflits prouvent que les portées sont bien réelles
Un système familial finit par rencontrer des préférences contradictoires, des utilisateurs qui quittent le foyer, des faits corrigés et des demandes de suppression. Si la mémoire d’une personne ne peut pas être supprimée sans effacer les connaissances partagées du foyer, ou si un fait partagé ne peut pas être révisé sans réécrire les historiques privés, le modèle de stockage initial n’était pas réellement cloisonné.
L’analyse de WorkOS sur l’autorisation granulaire de la récupération montre pourquoi le contrôle d’accès doit accompagner les données pendant la récupération, plutôt que d’être vérifié uniquement lors de la connexion. Pour la mémoire familiale, ce même point de contrôle permet aux règles de suppression et de visibilité par enregistrement de rester effectives lorsque les mémoires sont vectorisées ou récupérées sémantiquement.
Testez l’architecture avec deux comptes familiaux et un compte du foyer. Enregistrez des préférences contradictoires, promouvez un fait vers la portée partagée, révoquez l’accès d’un utilisateur, supprimez son enregistrement privé, puis effectuez des requêtes avec chaque identité. La conception n’est valide que si les faits partagés restent accessibles, si les préférences personnelles ne passent jamais d’un compte à l’autre et si la suppression élimine la mémoire prévue sans perte collatérale.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce que la dérive des représentations vectorielles, et quand faut-il reconstruire un index de recherche privé ?
Décoder la dérive du modèle, du prétraitement, du corpus et des requêtes ; distinguer la surveillance de l’incompatibilité ; et déterminer quand un index...
Qu’est-ce que la compatibilité des tokeniseurs et pourquoi peut-elle perturber le changement de modèle ?
Décodez l’identité du vocabulaire, la sémantique des tokens spéciaux, les modèles de chat, les tokens mis en cache, les adaptateurs et les vérifications de...
Qu’est-ce que la résidence d’un modèle et quand un service d’IA local doit-il conserver les poids chargés ?
Comprendre la persistance des poids, les niveaux de cache, les démarrages à froid, l’éviction, le multiplexage, la pression mémoire et les situations où un...
