Contexte hiérarchique : une hiérarchie de connaissances pour les agents d'IA

Un agent doté d’un seul fichier mémoire à plat n’oublie pas les choses ; il est incapable de cesser de se souvenir de ce dont on ne l’a pas interrogé. La solution est un contexte hiérarchique où chaque couche de connaissances entre via un déclencheur différent.

Le mode de défaillance n’est pas l’oubli, c’est l’inverse. Dans un dépôt à plat unique, chaque fait vit au même endroit, entre dans le contexte de la même manière et est donc disponible de la même manière — toujours. Demandez à l’agent au sujet d’un e-mail client et il raconte la configuration du routeur en rédigeant la réponse ; demandez-lui de dépanner un service et il mentionne le tarif de parrainage cité le mois dernier. La pile de mémoire est un monolithe : toute modification d’une préoccupation touche toutes les autres, et le rayon d’action de chaque requête est le corpus entier.

Le conseil standard est comportemental : enseigner à l’agent ce qui est pertinent pour le sujet actuel. C’est l’équivalent logiciel d’écrire « faites attention » sur un porteur de charge — l’agent peut être instruit et il s’y conformera presque toujours, jusqu’au jour où il ne le sera plus. L’alternative structurelle est une connaissance qui ne peut entrer dans une conversation que si l’activité qui en a besoin est déjà en cours. Cet article définit cette structure comme une hiérarchie de connaissances à cinq niveaux — ce que chaque niveau est, ce qui déclenche son injection, ce qui y appartient et où il échoue — et l’applique à un configuré concret multi-domaines : un profil général, un pour un homelab, un pour les affaires personnelles, un pour le travail, un pour l’éducation.

Nommer la hiérarchie

Il n’existe pas de terme normalisé par l’industrie, la définition ci-dessus est donc explicite. Une hiérarchie de connaissances est une organisation stratifiée de ce que l’agent sait, où chaque strate diffère par trois propriétés : la manière dont elle entre dans le contexte du modèle, la taille maximale qui lui est accordée et la durée pendant laquelle elle est censée rester exacte. Au niveau de l’architecture des connaissances, les paradigmes voisins — PKM, RAG, wikis et systèmes mémoire — sont comparés dans PKM vs RAG vs Wiki vs Systèmes mémoire, et les contrats d’exécution que les assistants implémentent réellement sont cartographiés dans Systèmes mémoire dans les assistants IA. Les deux se situent dans le cluster Gestion des connaissances, qui couvre les fondements, les méthodes et les outils des systèmes de connaissances humains. Cet article ajoute la classification basée sur les déclencheurs et la frontière de profil qui rendent le placement exécutable.

Deux lignées expliquent la forme de la hiérarchie.

La première est la hiérarchie mémoire du CPU. Un processeur ne stocke pas chaque octet dont il pourrait avoir besoin dans le même registre. Il a le cache L1 — petit, toujours résident, accédé sans aucune décision — le L2, la mémoire principale et le disque, chaque couche étant plus grande, plus lente d’accès et consultée uniquement lorsque les couches supérieures n’ont pas la réponse. La règle de conception n’est pas « garder tout rapide ». C’est la plupart des données ne comptent que rarement ; payez le coût d’accès uniquement quand cela compte. Un agent avec un seul fichier mémoire à plat est un CPU avec tout bourré dans le L1 : le fichier de registre est immense, donc tout est visible, y compris les octets que l’instruction actuelle n’a pas demandés. MemGPT a fait le même mouvement pour les agents, modélisant la mémoire comme des niveaux avec des déplacements explicites entre des dépôts rapides et lents.

La seconde est la taxonomie mémoire cognitive, qui divise les connaissances en mémoire procédurale (comment faire les choses), mémoire sémantique (faits sur le monde) et mémoire épisodique (ce qui s’est passé, quand, pour qui). La taxonomie compte parce que les modes de défaillance diffèrent selon le type : une connaissance procédurale qui devient obsolète est un bogue dans votre flux de travail, une connaissance sémantique qui devient obsolète est un fait erroné, et une connaissance épisodique qui fuit est un incident de confidentialité. Une hiérarchie organisée par type de contenu, et non par emplacement, vous indique quelles défaillances sont dangereuses.

L’axe organisateur pour cet article n’est aucun des deux ci-dessus. Classer les connaissances par ce qui cause leur entrée dans le contexte. Le déclencheur d’injection est le mécanisme, et le mécanisme est ce que vous pouvez réellement appliquer. Un système d’agent offre exactement quatre déclencheurs :

• Toujours. Injecté dans chaque tour, inconditionnellement.
• Déclencheur de tâche. Chargé lorsque l’activité actuelle correspond à une condition déclarée.
• Rappel sémantique. Affiché lorsque le message actuel est similaire à quelque chose de stocké.
• Référence explicite. Récupéré parce qu’une tâche nomme le fichier ou la requête.

Chaque niveau de la hiérarchie est défini par le déclencheur qui l’alimente. C’est tout le design, et le reste de cet article est un développement d’un seul tableau.

Les cinq niveaux

Lisez le tableau selon la colonne déclencheur, et non à l’horizontale. Le niveau 0 et le niveau 1 sont le cache L1 : ils payent pour leur privilège de résidentialité par leur petitesse. Le niveau 2 est le cache d’instructions : tiré sur une condition de branche, la tâche correspondant au déclencheur de la compétence. Le niveau 3 est le disque : il peut être énorme parce que rien n’entre dans le contexte jusqu’à ce qu’une étape d’une tâche lise explicitement un fichier nommé. Le niveau 4 est le plus difficile — c’est la mémoire principale, accédée par similarité, qui est le seul déclencheur de la liste qui n’implique pas une décision prise par vous ou par la tâche. La similarité est une porte probabiliste, et c’est pourquoi elle a besoin des contrôles externes les plus stricts, que la section profils fournit. L’image de l’armoire en haut de cet article encode la même idée : plus un niveau est élevé, plus librement son contenu entre dans une conversation, et la cloison vitrée marque où s’arrête l’étagère d’un domaine.

Niveau 0 : identité

SOUL.md, ou tout ce que votre agent appelle son prompt système. Son rôle est de définir qui, pas quoi : ton, valeurs, limites de refus et politique mémoire. La politique mémoire appartient ici parce qu’il s’agit de la seule instruction qui doit être en vigueur avant que toute mémoire ne soit consultée. Un fichier d’identité qui commence à lister des noms de serveurs, des noms de clients ou des taux a déjà échoué — il est devenu du contenu du niveau 1 portant la badge du niveau 0, et il entre maintenant dans chaque conversation, y compris celles où il ne doit pas apparaître.

Niveau 1 : mémoire résidente

Les fichiers mémoire persistants : notes générales et profil utilisateur. Deux règles gouvernent ce niveau, et ce sont les règles qui séparent une hiérarchie fonctionnelle d’une pile.

Premièrement, pointeurs, pas faits. Si un fait sert un seul domaine, il n’appartient pas ici. La bonne entrée n’est pas le fait lui-même mais un panneau indicateur :

Faits infra : wiki/infra/ + banque mémoire 'homelab'.
Clients et contrats : wiki/business/clients/ + banque 'business'.

Le panneau indicateur est neutre en termes de domaine, il est donc sûr de le transporter partout. Le fait auquel il pointe n’est chargé que par l’activité qui a nommé la destination.

Deuxièmement, un budget dur, appliqué. Si le dépôt n’a pas de limite de caractères, il se remplit, et le remplissage se fait toujours avec le sujet le plus récemment discuté — donc une semaine d’infra évacue silencieusement ou entoure le contexte général avec de l’infra. Un budget presque plein force le tri, et le tri est le seul mécanisme qui garde ce niveau honnête. L’implémentation Hermes est un exemple fonctionnel : MEMORY.md plafonné à 2 200 caractères et USER.md à 1 375, injecté comme un bloc figé au début de la session, est documenté dans Système mémoire de l’agent Hermes.

Niveau 2 : connaissances procédurales

Les compétences sont la manière dont l’agent encode comment : la procédure, les pièges et — crucialement pour cet article — les pointeurs vers les niveaux plus profonds. Une compétence pour l’administration d’un homelab nomme quel répertoire de wiki détient l’inventaire et quelle banque mémoire rappeler. Une compétence pour le travail client nomme le dépôt de contrats et la banque affaires. La description de la compétence est son déclencheur : c’est la condition de branche qui décide si la procédure, et donc ses pointeurs, entre dans le contexte ou non.

C’est le niveau qui fait fonctionner la hiérarchie opérationnellement, parce qu’il est la couture entre « quelle activité a lieu » et « quelles données cette activité peut voir ». Une tâche au sujet d’un e-mail client charge la compétence client ; la compétence client nomme la banque affaires et le répertoire des contrats ; la banque homelab et le répertoire infra sont simplement jamais référencés depuis un chemin que la tâche a parcouru.

Le mode de défaillance est le débordement de données : coller la liste réelle des clients ou la table réelle des IP dans le corps de la compétence. Alors les données sont toujours chargées quand la procédure l’est, et le déclencheur de la procédure est devenu la frontière d’exposition des données. Les compétences portent le chemin vers les données, et rien d’autre de sensible.

Niveau 3 : données de référence

Le wiki, l’arborescence de notes, le système d’enregistrement. C’est le niveau avec le moins de contraintes et le moins de surprises, parce que c’est le seul niveau avec un chemin d’accès déterministe : quelque chose entre dans le contexte uniquement parce qu’une étape d’une tâche a lu explicitement ce fichier. Tables, inventaires, contrats, runbooks, statistiques — le genre de choses que vous conserveriez dans une base de données ou un système de gestion de configuration. Lorsque le corpus est maintenu par LLM, le motif Wiki LLM s’applique : la synthèse a lieu à l’ingestion, et le résultat est stocké sous forme de pages structurées et liées.

La raison pour laquelle les données de référence appartiennent ici et non au niveau 4 est que la qualité de récupération est le mauvais outil pour les tables. Le rappel sémantique est excellent pour « quoi le client X a-t-il confirmé au sujet de l’échéance » et terrible pour « quel est le port du service sur l’hôte Y » — ce dernier a exactement une ligne correcte, et un réclasseur renvoyant les trois paragraphes les plus proches est une faiblesse. La recherche déterministe gagne pour les données de référence ; la similarité gagne pour les épisodes. Gardez-les séparés, et le motif d’accès de chaque niveau correspond à la forme de son contenu.

Le mode de défaillance est l’obsolétude, qui est un problème de maintenance, pas un problème d’architecture : l’enregistrement dérive de la réalité et l’agent, faisant tout correctement, travaille à partir d’une table fausse. L’atténuation est la même dont a besoin tout système d’enregistrement — un rédacteur par fichier, journaux de modifications et un rythme d’audit — plus les pratiques de détection de dérive et de vérification de contradictions couvertes dans Maintenance du Wiki LLM : Dérive, Contradictions et Revue.

Niveau 4 : mémoire récupérée

Un backend mémoire avec rappel automatique par tour : la mémoire épisodique et relationnelle de l’agent. Décisions et leurs dates, « le client X a confirmé Y », « nous avons essayé Z et ça n’a pas fonctionné ». C’est là que vit la partie dynamique et auto-organisée du système — et où l’histoire de la sécurité devient intéressante, parce que le rappel sémantique est une porte probabiliste et les portes probabilistes fuient.

« Question de facturation pour le client X » et « quel hôte exécute le serveur de facturation » sont proches dans l’espace d’incrustation. Une seule banque qui détient à la fois les enregistrements client et l’inventaire de l’infrastructure affichera, avec une probabilité non négligeable, ce dernier dans le premier. Vous pouvez restreindre cela avec des étiquettes et des restrictions de rappel, et vous devriez — mais un filtre d’étiquettes sur un corpus mixte est une discipline, pas une structure. La réponse structurelle est de cesser de mélanger : une banque par domaine, afin que le rayon de fuite d’un rappel soit, par construction, un domaine. Choisir le backend lui-même — politique de capture, dépendances, contraintes d’auto-hébergement — est une comparaison separate, couverte dans Comparaison des fournisseurs de mémoire pour agents.

Deux détails mécaniques comptent lorsque vous câblez ce niveau. Les chemins d’écriture et les chemins de lecture sont des contrôles séparés : une banque peut être incluse dans le rappel tout en étant exclue de la rétention, c’est ainsi que vous construisez un profil qui lit tout et n’écrit rien. Et chaque banque devrait porter sa propre mission de rétention — une courte déclaration de ce que cette banque existe à détenir. Une banque affaires avec la mission « correspondance client, termes contractuels, état de négociation ; jamais de détails d’infrastructure » extraira en conséquence, parce que l’extraction est un appel LLM qui lit la mission. Le livret de personnalisation d’OpenAI traite la consolidation comme l’étape la plus sensible et sujette aux erreurs d’un cycle de vie mémoire — la mission de rétention est le contrat qui garde cette étape honnête.

Profils : la frontière qui rend la séparation structurelle

Jusqu’ici, la hiérarchie sépare les connaissances par niveau — nécessaire mais pas suffisant. Les cinq niveaux ci-dessus sont l’anatomie d’un agent. La question avec laquelle cet article a commencé porte sur les domaines : homelab, personnel, travail, éducation, et le contexte général qui les englobe.

Le mécanisme de séparation des domaines est le profil — une instance complète et indépendante de l’agent : son propre fichier d’identité, sa propre mémoire résidente, son propre répertoire de compétences, ses propres tâches planifiées et, de manière décisive, son propre câblage de banques mémoire. Un profil n’est pas une étiquette sur une conversation ; c’est un système séparé qui se trouve partager une machine. Lorsque vous exécutez agent -p homelab, vous obtenez un processus dont l’ensemble du niveau 0 au niveau 4 est limité au domaine homelab, et dont le bassin de rappel ne peut contenir la banque affaires parce que la banque affaires n’est tout simplement pas dans sa configuration.

C’est la différence entre les deux réponses au problème de fuite. « Ne pas divulguer l’infrastructure dans les conversations commerciales » est une instruction de prompt — une probabilité. « Le bassin de rappel du profil affaires n’inclut pas la banque infrastructure » est une configuration — une garantie. La hiérarchie vous dit ce qui va où ; la frontière de profil est ce qui rend le placement impossible à contourner depuis l’intérieur de la conversation.

L’exemple détaillé, cinq domaines :

Deux cellules dans ce tableau font le gros du travail.

La ligne de banque du profil commun est « aucune, lecture seule ». La conversation générale est où vous posez des questions transversales, donc elle devrait pouvoir voir tous les faits rappelés de chaque domaine — mais elle ne doit pas écrire dans aucun d’eux. Les bavardages dans une session générale sont exactement le matériau que vous ne voulez pas extrait dans la mémoire durable d’un domaine, et le câblage en lecture seule retire le choix au modèle entièrement. Si le câblage du backend prend en charge les listes de banques en rappel uniquement (séparées des banques d’écriture), c’est une ligne de configuration par banque de domaine ; si ce n’est pas le cas, le profil commun rappelle depuis une banque générale dédiée et vous acceptez une vue inter-domaine plus faible.

Les lignes de rappel des profils de domaine sont vides. Chaque profil de domaine voit exactement une banque. Le profil homelab ne rappelera jamais un terme contractuel d’un client, non parce qu’on lui a dit de ne pas le faire, mais parce que le terme n’est pas dans le bassin qu’il interroge. C’est la séparation bidirectionnelle pour laquelle toute l’exercice existe : elle fonctionne symétriquement par construction, sans instruction impliquée dans les deux directions.

Trois conséquences opérationnelles en découlent, et c’est pourquoi l’approche par profils coûte plus cher que l’approche à agent unique mais en vaut la peine pour quiconque dont les domaines sont vraiment disjoints.

• Le déclencheur devient la surface. Si le travail homelab a lieu dans un terminal que vous lancez avec -p homelab, et le travail client sur un compte de messagerie acheminé au profil travail, alors quel chapeau vous portez est une propriété de la manière dont vous avez invoqué l’agent, pas un drapeau que vous devez vous souvenir d’état. La désorientation — exécuter accidentellement des tâches client dans le contexte homelab — devient aussi visible que d’exécuter le mauvais shell.
• Le travail planifié hérite de la frontière. Les tâches cron et les sous-tâches déléguées s’exécutent dans le profil qui les possède. Une vérification d’infra nocturne planifiée dans le profil homelab ne peut pas faire dériver de contenu d’affaires dans la banque homelab, parce qu’elle ne l’a jamais eu.
• Le système de fichiers est partagé, et c’est la limite honnête. Les profils séparent le contexte, pas l’accès. Le terminal de chaque profil peut lire les fichiers de chaque profil ; la frontière protège les conversations, pas les disques. Donc les niveaux qui tiennent du matériel véritablement sensible ont besoin de leur propre discipline : les identifiants dans un fichier d’environnement ou un dépôt de secrets plutôt que dans le texte brut du wiki, le wiki hors de tout dépôt public, et des autorisations par répertoire là où le système d’exploitation aide. Traitez la frontière de profil comme un pare-feu pour le contexte — excellent dans son travail — et ne vous laissez pas la faire passer pour un pare-feu pour les données.

Amorçage depuis une pile à plat

La hiérarchie est généralement atteinte depuis le bas : un agent qui a commencé avec un fichier mémoire et qui garde maintenant tout dedans. L’ordre de migration compte, parce que chaque étape n’est bon marché que lorsque la précédente est faite.

D’abord, séparez le bassin de rappel. Créer une banque mémoire par domaine est un changement de configuration, pas une réécriture de contenu — et c’est l’étape avec la plus forte levier, parce que la fuite de rappel s’arrête le jour où les banques se séparent. Le contenu peut migrer ensuite ; la frontière ne devrait pas attendre.

Deuxièmement, budgétez le niveau 1. Définissez un plafond de caractères sur les fichiers résidents, puis auditez ce qui y est déjà contre le plafond. Les faits spécifiques au domaine deviennent des pointeurs vers l’endroit où ils vivront ; ce qui reste est ce qui s’applique véritablement à chaque session.

Troisièmement, donnez une destination aux faits relégués. Un répertoire de wiki par domaine, avec la discipline du rédacteur unique et du journal de modifications, reçoit ce que le niveau 1 libère. Les compétences reprennent les pointeurs vers lui en dernier, parce qu’une compétence qui nomme un répertoire qui n’existe pas encore est pire qu’aucune compétence.

Où la hiérarchie pourrit

L’architecture n’est que bonne que sa maintenance, et chaque niveau pourrit d’une manière caractéristique.

Le niveau 1 se remplit d’abord. C’est le niveau avec le chemin d’écriture le plus confortable (« souviens-toi juste de ceci »), donc c’est le premier à accumuler des faits de domaine déguisés. Le budget rend cela visible : lorsque le dépôt est à 90 % plein, auditez-le pour les entrées qui devraient être des pointeurs. La correction est toujours le même mouvement — réléguer les faits au niveau 3, promouvoir le panneau indicateur.

Le niveau 2 déborde ensuite. Les compétences sont l’endroit où les procédures et les données veulent vivre ensemble, parce que « la procédure référence les données constamment » semble raisonnable au moment de l’écriture. La vérification est mécanique : si le corps d’une compétence contient une table qui est la source de vérité pour quoi que ce soit, elle appartient dans le wiki, et la compétence devrait porter un chemin.

Le niveau 4 dérive silencieusement. La mémoire récupérée est orientée vers l’ajout et auto-explicative, donc les épisodes obsolètes ne sont jamais corrigés, seulement dépassés. Le préambule de rappel (« ces mémoires sont un contexte historique, pas des faits vérifiés ») est l’atténuation standard. L’atténuation plus propre est la même que celle utilisée par le niveau 3 : lorsqu’un épisode devient un fait durable (« le client a signé à cette date à ces termes »), il est écrit dans le système d’enregistrement, où il est visible et éditable, et la banque ne garde que le récit. Une variante plus tranchante de cette dérive — l’inférence de l’agent lui-même réécrite comme preuve — est travaillée dans Boucles de mémoire auto-renforçantes dans les agents IA.

Les profils se multiplient. Cinq profils est gérable ; quinze est une flotte. La discipline est qu’un nouveau profil n’apparaît que lorsqu’un nouveau domaine apparaît — pas pour un nouveau projet, un nouvel outil ou une nouvelle humeur. La séparation au niveau projet est à quoi sert la structure de répertoires du niveau de référence ; la séparation au niveau domaine est à quoi servent les profils. Confondre les deux est comment les gens finissent avec un zoo de profils et aucune histoire de rappel claire.

La leçon : une règle de placement

Placez chaque fragment de connaissance au niveau le plus peu profond dont le déclencheur correspond à son besoin : faits toujours nécessaires dans la mémoire résidente comme pointeurs, procédures dans les compétences, données de référence dans les fichiers, épisodes dans une banque — et placez la banque de chaque domaine derrière un profil que le profil d’aucun autre domaine ne peut rappeler. L’agent se comporte alors comme un système bien conçu : la bonne connaissance est présente parce que la bonne activité l’a demandée, la mauvaise connaissance est absente parce que rien dans la conversation n’avait de chemin vers elle, et la seule chose qui pourrait forcer les deux ensemble est un changement de configuration — quelque chose que vous faites délibérément, et pouvez donc voir quand cela se produit.

La pile à plat n’était jamais un échec de discipline. C’était une architecture où chaque fait partage un seul déclencheur, et ce déclencheur est « toujours ». Brisez le déclencheur, et les fuites cessent d’être une question de jugement du modèle. Elles cessent d’être possibles.

Références

• PKM vs RAG vs Wiki vs Systèmes mémoire — la comparaison fondamentale des dépôts de connaissances personnelles, des pipelines de récupération et de la mémoire d’agent
• Systèmes mémoire dans les assistants IA — la pile de mémoire d’exécution dans laquelle cette hiérarchie s’insère
• Récupération vs Représentation dans les systèmes de connaissances — pourquoi la forme de votre dépôt détermine ce qu’il peut répondre
• Hub Mémoire des systèmes IA