Second cerveau organisationnel de Meta : pourquoi la mémoire des agents IA devrait être stockée dans des fichiers plutôt que dans les poids des modèles

L’Organizational Second Brain de Meta montre clairement l’intérêt de conserver les connaissances institutionnelles qui évoluent rapidement dans des fichiers explicites, plutôt que d’essayer d’intégrer chaque correction, politique et jugement d’expert dans les poids du modèle. Meta synthétise les connaissances des experts dans un système de fichiers structuré que les humains et les agents peuvent lire, relier par des dépendances, tester après chaque modification, versionner, réviser et améliorer sans réentraîner le modèle sous-jacent. Le modèle fournit l’intelligence ; la couche de connaissances préserve ce que l’organisation a appris.

Cela ne signifie pas que toute forme de mémoire de l’IA doit être stockée au format Markdown ni que le RAG est obsolète. Les poids du modèle fournissent toujours les connaissances générales, la recherche documentaire reste utile pour les ressources de référence peu denses, et l’état des tâches en cours peut être stocké dans des bases de données ou des environnements d’exécution d’agents. Meta s’attaque à un problème plus ciblé, mais de plus en plus important : comment préserver les connaissances organisationnelles qui évoluent au fil du temps, nécessitent une traçabilité et doivent survivre au modèle qui les utilise.

Qu’est-ce que l’Organizational Second Brain de Meta ?

L’Organizational Second Brain de Meta est une architecture interne d’agents IA conçue pour capturer les connaissances spécialisées qui resteraient autrement dispersées dans des documents ou enfermées dans l’esprit des experts. Meta décrit le système comme un expert secondaire dans un domaine, plutôt que comme un chatbot polyvalent.

Selon l’architecture officielle de l’Organizational Second Brain de Meta, le système combine quatre couches interdépendantes :

Le point important est que Meta ne s’appuie pas sur le réentraînement du modèle chaque fois qu’un expert corrige l’agent. Les corrections peuvent plutôt devenir des modifications apportées à des fichiers de connaissances externes ou à des procédures de raisonnement.

Cela transforme une interaction avec un expert, simple correction temporaire dans un chat, en un actif organisationnel potentiellement permanent.

Pourquoi des milliers de documents ne constituent-ils pas la même chose qu’une mémoire pour les agents ?

Un dossier rempli de documents est une archive. Il ne devient une mémoire utile pour les agents que lorsque le système comprend ce qui compte, comment les sources sont liées et quand certaines règles ou interprétations s’appliquent.

Les grandes organisations disposent déjà d’une quantité considérable de documents écrits : politiques, spécifications, décisions historiques, listes de contrôle, rapports, notes de projet, normes et documentation interne. Le problème est que les connaissances les plus précieuses se trouvent souvent entre ces documents.

Un expert peut savoir :

• quelle politique prévaut lorsque deux règles entrent en conflit,
• quelle exception ne s’applique que dans une condition précise,
• quelle décision historique reste pertinente,
• quelle terminologie l’organisation utilise en interne,
• lorsqu’un cas est suffisamment ambigu pour nécessiter une escalade,
• et pourquoi deux situations apparemment similaires doivent être traitées différemment.

Un système de recherche classique peut retrouver les documents sources, mais le modèle doit malgré tout souvent reconstruire cette interprétation à partir de zéro à chaque fois.

Meta présente cela comme l’une des faiblesses du fait de considérer les documents bruts eux-mêmes comme des connaissances organisationnelles. Un agent qui récupère des fragments au moment de l’inférence doit constamment déduire le raisonnement de l’organisation à partir de ces fragments, ce qui peut être lent et incohérent.

Meta avait déjà rencontré un problème similaire plus tôt en 2026. Dans ses travaux précédents sur la compilation des connaissances informelles en fichiers de contexte pour les agents, plus de 50 agents spécialisés ont analysé plus de 4 100 fichiers répartis dans quatre référentiels et produit 59 fichiers de contexte concis. Meta a signalé des tests préliminaires montrant environ 40 % d’appels d’outils en moins par agent et par tâche.

La leçon est similaire : davantage d’informations brutes ne produit pas automatiquement un meilleur comportement des agents. Il manque souvent une couche : une structure synthétisée.

Pourquoi Meta stocke-t-il les connaissances de ses agents dans des fichiers structurés ?

Meta organise plus de 200 fichiers selon une taxonomie stricte, plutôt que de conserver un document d’instructions gigantesque. Ces fichiers représentent différents types de connaissances institutionnelles et différentes responsabilités de routage.

Meta utilise également des en-têtes YAML pour déclarer les relations entre les fichiers. Un fichier peut indiquer ce qu’il depends_on et les autres fichiers dont il est referenced_by.

Un exemple simplifié pourrait ressembler à ceci :

---
type: position
topic: customer-data-retention
depends_on:
  - data-classification.md
referenced_by:
  - privacy-review-recipe.md
applies_when:
  - customer_pii = true
---

# Conservation des données clients

## Position
Définir ici la position actuelle de l’organisation.

## Limites
Documenter les cas où la position s’applique et ceux où elle ne s’applique pas.

## Exceptions
Répertorier les exceptions connues.

## Effectuer une escalade lorsque
Décrire les cas nécessitant l’examen d’un expert.

Il s’agit d’un exemple illustratif plutôt que d’une copie des fichiers internes de Meta, mais il montre pourquoi les fichiers structurés en texte brut sont attrayants.

Ils sont :

• lisibles par les humains,
• lisibles par machine,
• faciles à comparer,
• faciles à mettre en relation,
• faciles à vérifier statiquement,
• faciles à versionner,
• et réversibles individuellement.

Le graphe des dépendances est également important lorsqu’un agent propose une modification. Si un fichier de règles change, le système peut identifier les procédures, index et règles en aval susceptibles d’être affectés, plutôt que de supposer que la modification existe de manière isolée.

Le second cerveau de Meta remplace-t-il le RAG ?

Non. Meta conserve délibérément à la fois une couche de connaissances organisée et la récupération. Ces deux éléments répondent à des problèmes d’information différents.

Meta répartit les informations en fonction de leur densité et de leur fréquence d’utilisation prévue.

La couche organisée stocke les informations dont l’agent aura probablement besoin de manière répétée et qui représentent l’interprétation évolutive de son domaine par l’organisation. Les ressources peu abondantes restent accessibles grâce à une récupération sémantique ou lexicale lorsqu’un cas particulier l’exige.

Cela concorde avec la distinction plus large établie par les recherches originales sur la génération augmentée par récupération, qui distinguent les connaissances stockées de manière paramétrique dans un modèle de la mémoire externe explicite et non paramétrique, qui peut être récupérée lorsque cela est nécessaire.

Meta ajoute en pratique une couche supplémentaire entre ces deux extrêmes.

POIDS DU MODÈLE
Intelligence générale
        |
        v
CONNAISSANCES CURATÉES
Positions
Règles
Interprétation
Cadres décisionnels
        |
        v
RAG / RECHERCHE
Preuves détaillées
Archives historiques
Références rares
        |
        v
SOURCES BRUTES

Voici une manière utile de décrire cette division :

Le RAG aide l’agent à trouver des éléments probants. Une couche de connaissances organisée évite qu’il ne redécouvre à chaque fois, en partant de zéro, l’interprétation de l’organisation.

Pourquoi un agent d’IA devrait-il séparer ce qu’il sait de la manière dont il raisonne ?

L’une des décisions de conception les plus importantes de Meta consiste à séparer les connaissances déclaratives du raisonnement procédural.

Les fichiers de connaissances décrivent ce que l’organisation sait ou croit savoir. Les « recettes » de Meta décrivent la manière dont l’agent doit traiter un problème.

Cette séparation facilite le diagnostic des défaillances.

Si l’agent parvient à la mauvaise conclusion, les responsables de la maintenance peuvent demander :

• Les connaissances adéquates existaient-elles ?
• Le bon fichier a-t-il été chargé ?
• Le poste organisationnel lui-même était-il erroné ou obsolète ?
• Ou bien la procédure de raisonnement a-t-elle mal utilisé des connaissances pourtant exactes ?

Meta indique que l’ajout d’un nouveau poste organisationnel peut consister à ajouter un fichier de connaissances et à mettre à jour un index de routage sans modifier la recette de raisonnement. À l’inverse, un problème de méthodologie peut être corrigé en modifiant la recette sans réécrire les faits sous-jacents du domaine.

Cette modularité devient de plus en plus précieuse à mesure que la base de connaissances s’agrandit.

Comment la divulgation progressive a-t-elle réduit d’environ 80 % l’utilisation des jetons par Meta ?

Les grandes fenêtres de contexte ne rendent pas inutile l’architecture de l’information. Un modèle peut techniquement accepter des centaines de milliers, voire des millions de jetons, mais cela ne signifie pas que chaque politique, référence et instruction doit être chargé pour chaque tâche.

L’implémentation précédente de Meta utilisait une structure d’instructions relativement plate et une recherche sémantique susceptible d’intégrer dans la fenêtre de contexte un grand volume de contenus aux niveaux de pertinence variés.

Le système de recettes a modifié le fonctionnement pour adopter une divulgation progressive.

ANCIENNE APPROCHE

Tâche
  |
  v
Grand ensemble d’instructions
+ nombreuses sources récupérées
+ contexte général étendu
  |
  v
Modèle


DIVULGATION PROGRESSIVE

Tâche
  |
  v
Étape 1
Charger uniquement les instructions et les connaissances de l’étape 1
  |
  v
Étape 2
Charger uniquement les instructions et les connaissances de l’étape 2
  |
  v
Étape 3
Ne récupérer des éléments probants qu’en cas de besoin

Après le passage à des étapes pilotées par des recettes, Meta indique que chaque requête n’accédait qu’à un petit sous-ensemble ciblé du système de connaissances et que le nombre de jetons consommés par tour avait diminué d’environ 80%.

Cela ne revient pas à dire que le Second Brain a réduit de 80 % le coût total de l’IA. Le résultat concerne spécifiquement la consommation de jetons par tour après la restructuration de la stratégie de chargement du contexte.

La leçon plus générale est importante :

La meilleure question n’est pas « Quelle quantité de contexte le modèle peut-il conserver ? », mais « De quelle quantité minimale de contexte cette étape a-t-elle besoin pour résoudre correctement le problème ? »

Comment Meta transforme-t-elle les retours des experts en mémoire permanente pour les agents ?

La boucle d’auto-amélioration est sans doute la partie la plus importante de l’architecture de Meta, car stocker les connaissances est facile comparé au fait de les conserver exactes au fil du temps.

Meta considère la maintenance comme un problème de compilation. Les corrections des experts passent par quatre étapes :

1. Diagnostiquez les retours et identifiez leur cause racine.
2. Compilez le problème en modifications minimales et vérifiées.
3. Validez que la modification corrige le problème sans introduire de régressions.
4. Examinez la modification proposée avec un expert du domaine.

La phase de diagnostic cherche à déterminer si une erreur provient de connaissances manquantes, d’une procédure de raisonnement défaillante ou d’une véritable ambiguïté.

Si la bonne réponse figurait déjà dans le contenu source, mais que l’agent a tout de même échoué, Meta considère qu’il s’agit d’un problème méthodologique. Si l’information nécessaire était absente, il s’agit d’une lacune de connaissances. Si les experts eux-mêmes ne sont pas d’accord, le cas peut être transmis à un niveau supérieur plutôt que de forcer le système à encoder une certitude erronée.

L’étape de compilation propose ensuite des modifications minimales. Meta indique que des agents distincts examinent des problèmes tels que l’impact sur les références croisées, les conflits avec les positions existantes, les doublons, les effets sur le budget de tokens et la couverture des tests.

Un nouvel évaluateur adversarial reçoit les modifications proposées sans la justification initiale de l’amélioration et tente d’y déceler des contradictions ou des cas limites. Une validation structurelle déterministe vérifie ensuite des problèmes tels que les références rompues, les cycles de dépendances, les collisions d’identifiants et les contraintes de taille des fichiers.

Le processus peut se résumer ainsi :

CORRECTION PAR UN EXPERT
        |
        v
DIAGNOSTIQUER LA CAUSE RACINE
        |
        v
PROPOSER UNE MODIFICATION MINIMALE
        |
        v
EXAMEN ADVERSARIAL
        |
        v
VALIDATION STRUCTURELLE
        |
        v
REJOUER + TESTS DE RÉGRESSION
        |
        v
EXAMEN HUMAIN
        |
        v
INTÉGRER LA MODIFICATION
        |
        v
AJOUTER L’ÉCHEC À LA SUITE DE TESTS

Dès qu’un correctif est intégré, le scénario d’échec initial devient une partie de la suite de tests de régression. Les modifications futures doivent donc préserver ce comportement nouvellement corrigé.

Meta fait état de zéro régression au cours de ses cycles d’amélioration pendant la période de développement de six semaines décrite dans la publication, tandis que des évaluations individuelles qui prenaient auparavant plusieurs jours ont été réduites à quelques minutes. Ces résultats sont ceux du déploiement interne de Meta, et non ceux d’un benchmark indépendant.

Pourquoi les fichiers sont-ils plus faciles à mettre à jour que les poids du modèle ?

Pour les connaissances institutionnelles qui évoluent rapidement, les fichiers rendent les changements visibles. C’est l’argument le plus fort en faveur du titre.

Cela ne signifie pas que l’édition des modèles est inutile ou impossible. Des travaux comme les recherches sur l’édition des modèles MEMIT étudient comment modifier directement les associations factuelles à l’intérieur des modèles Transformer.

Meta pose une question architecturale différente :

Si les connaissances organisationnelles évoluent fréquemment et que les humains doivent inspecter chaque mise à jour importante, pourquoi intégrer ces connaissances au modèle dès le départ ?

Meta affirme que la sortie finale de son pipeline d’amélioration est un diff qu’un expert du domaine peut examiner rapidement. Son principe de conception plus large consiste à conserver cette complexité dans du texte qui reste versionné, comparable par diff et réversible.

Cela rapproche la maintenance des connaissances de la gestion de configuration logicielle, plutôt que du réentraînement des modèles.

Le Markdown et le YAML deviennent-ils une couche de mémoire portable pour les agents d’IA ?

La conception de Meta s’inscrit dans un mouvement plus large vers des représentations des connaissances que les humains et les agents peuvent inspecter directement.

En avril 2026, Andrej Karpathy a publié le modèle de wiki LLM. L’idée consiste à faire maintenir progressivement par un LLM un wiki structuré persistant, plutôt qu’à reconstruire les connaissances transversales à partir de résultats RAG bruts à chaque requête.

La propriété essentielle est l’accumulation.

Source A
   |
   v
Wiki structuré

Source B
   |
   v
Mettre à jour les pages existantes
Ajouter des relations
Signaler les contradictions

Source C
   |
   v
Les connaissances s’enrichissent
sans repartir de zéro

La spécification Open Knowledge Format de Google pousse la même idée vers l’interopérabilité. OKF v0.2 définit un format délibérément minimal, fondé sur des répertoires de fichiers Markdown avec un front matter YAML, lisibles par les humains et les agents sans nécessiter de registre de schémas central ni d’environnement d’exécution propriétaire.

Cela suggère une orientation potentiellement importante :

Les connaissances des agents en texte brut pourraient devenir une couche d’interopérabilité.

Si les connaissances importantes d’une organisation existent sous forme de fichiers explicites plutôt que d’être dissimulées dans le système de mémoire propriétaire d’un seul fournisseur, cette même couche de connaissances peut théoriquement être utilisée par différents agents et différents modèles.

              CONNAISSANCES
            Markdown / YAML
                 |
       +---------+---------+
       |         |         |
       v         v         v
    Claude     Gemini     Qwen
       |         |         |
       +---------+---------+
                 |
              AGENTS

Le modèle devient remplaçable. Les connaissances accumulées ne sont pas obligées de l’être.

Si la mémoire de l’agent IA devient un ensemble de fichiers, où ces fichiers doivent-ils être stockés ?

Dès que les connaissances des agents deviennent un ensemble durable de fichiers, une nouvelle question d’infrastructure se pose : ces fichiers ont besoin des mêmes protections que toute autre donnée organisationnelle précieuse.

Une couche de connaissances sérieuse peut contenir :

• des positions sélectionnées,
• des décisions d’experts,
• des taxonomies,
• des recettes de raisonnement,
• de la logique de routage,
• des cas d’évaluation,
• des documents sources,
• des citations,
• des améliorations générées par les agents,
• et des versions historiques.

Cela crée des exigences qui ont peu à voir avec la taille du LLM :

Ces exigences peuvent être mises en œuvre sur une station de travail, un serveur privé, un NAS pour les connaissances durables des agents, un dépôt Git ou un environnement cloud contrôlé. L’architecture de Meta n’impose aucun produit de stockage particulier.

L’idée principale est que les connaissances des agents commencent à ressembler moins à un contexte de prompt éphémère qu’à un actif de données durable.

Pourquoi le contrôle de version ne suffit-il pas pour la mémoire de l’IA ?

Le contrôle de version de type Git est extrêmement utile pour les connaissances structurées des agents, car il fournit des différences, un historique, une révision, des branches et un retour en arrière logique. Mais ce n’est pas une stratégie complète de protection des données.

Le contrôle de version répond principalement à la question :

Qu’est-ce qui a changé ?

Les instantanés du système de fichiers pour une récupération rapide répondent à une autre question :

Puis-je restaurer rapidement l’intégralité de l’état de travail tel qu’il était avant une modification problématique ?

La sauvegarde répond à une autre question :

Puis-je récupérer les données si le système de stockage d’origine lui-même est perdu ou corrompu ?

Cette distinction devient encore plus importante lorsque les agents sont autorisés à mettre à jour leur propre couche de connaissances.

Une modification incorrecte peut être facile à annuler dans Git. Un dépôt corrompu, une collection de pièces jointes manquante, un index vectoriel endommagé, une archive de sources brutes supprimée par erreur ou un périphérique de stockage défaillant relèvent d’une tout autre catégorie de problèmes.

Si la base de connaissances devient partie intégrante du fonctionnement d’une organisation, sa protection doit être considérée comme une infrastructure de données plutôt que comme une simple question d’ingénierie des prompts.

À quoi ressemble une pile de connaissances locale et durable pour un agent ?

Une architecture pratique de la mémoire d’un agent peut séparer l’intelligence, les connaissances curatées, la recherche, les données sources et la protection au lieu de les forcer à coexister dans une seule couche.

MODÈLE D’IA
Claude / Gemini / Qwen / autre
        |
        v
ENVIRONNEMENT D’EXÉCUTION DE L’AGENT
Outils / routage / sessions
        |
        v
CONNAISSANCES CURATÉES
Positions
Taxonomie
Recettes
Règles
        |
        v
RAG / RECHERCHE
Index
Embeddings
Recherche lexicale
        |
        v
SOURCES BRUTES
PDF
Documents
Code
Archives historiques
        |
        v
PROTECTION DES DONNÉES
Contrôle de version
Instantanés
Sauvegarde

L’avantage de cette architecture est l’indépendance.

Le modèle peut changer sans qu’il soit nécessaire de réécrire la base de connaissances. Le moteur de recherche peut changer sans supprimer les sources brutes. Le framework d’agent peut être remplacé sans perdre les décisions des experts. Le matériel de stockage peut être mis à niveau sans modifier la structure logique des connaissances elles-mêmes.

Il s’agit d’une définition bien plus durable de la mémoire de l’IA que « tout ce que le chatbot actuel se trouve à retenir dans son contexte ».

Le Second Brain de Meta montre-t-il vers quoi évolue la mémoire des agents d’IA ?

L’architecture de Meta suggère que l’actif à long terme d’un système d’agent d’IA pourrait de plus en plus être la couche de connaissances plutôt que le modèle.

Les modèles continueront de progresser rapidement. Les organisations peuvent passer de modèles propriétaires de pointe à des modèles locaux à poids ouverts, à des agents spécialisés, ou à des combinaisons des trois.

Les connaissances institutionnelles évoluent selon une échelle de temps différente.

Une entreprise peut passer des années à découvrir :

• quelles procédures fonctionnent réellement,
• quelles exceptions comptent,
• quelle terminologie évite les ambiguïtés,
• quelles décisions historiques restent pertinentes,
• et quelles corrections d’experts ne devraient plus jamais avoir besoin d’être redécouvertes.

Ces connaissances ne doivent pas devenir jetables simplement parce que le modèle de raisonnement change.

La conception de Meta montre également que la mémoire fondée sur des fichiers ne remplace pas toutes les autres techniques de mémoire. L’architecture la plus robuste est en couches :

des poids de modèle pour l’intelligence générale, des fichiers structurés pour les connaissances institutionnelles entretenues, le RAG pour les éléments probants épars, des recettes pour la méthodologie, l’état d’exécution pour les tâches actives, et le contrôle de version ainsi que les sauvegardes pour la durabilité.

Le résultat change notre façon de concevoir un « second cerveau » pour l’IA.

Ce n’est pas simplement une fenêtre de contexte plus grande.

Ce n’est pas un dossier rempli de PDF.

Ce n’est pas une base de données vectorielle à lui seul.

Et il ne s’agit pas de connaissances définitivement prisonnières d’un seul modèle.

Un second cerveau durable est un système de connaissances entretenu qui peut être inspecté, corrigé, testé, restauré et transmis au modèle suivant.

Le modèle peut être remplacé le mois prochain. Les connaissances qu’une organisation a mis des années à constituer doivent lui survivre.

FAQ : le Second Brain organisationnel de Meta et la mémoire des agents IA

Qu’est-ce que le Second Brain organisationnel de Meta ?

Il s’agit d’une architecture interne d’agent IA conçue par Meta pour préserver les connaissances organisationnelles spécialisées. Elle combine des fichiers de connaissances structurés, des recettes de raisonnement composables, de l’évaluation et une boucle d’auto-amélioration qui transforme les corrections des experts en mises à jour testées, sans réentraîner le modèle sous-jacent.

Meta stocke-t-elle toute la mémoire de ses agents IA dans des fichiers Markdown ?

Non. Le système utilise une couche de connaissances structurée fondée sur des fichiers pour les connaissances institutionnelles à forte valeur, tout en conservant une récupération sémantique et lexicale pour les documents de référence plus rares. Le modèle lui-même fournit toujours l’intelligence générale, et d’autres états d’exécution peuvent résider en dehors des fichiers de connaissances.

Le Second Brain de Meta remplace-t-il le RAG ?

Non. Meta combine délibérément des connaissances sélectionnées avec le RAG. Les positions fréquemment utilisées, les cadres de décision et les interprétations sont synthétisés dans des fichiers structurés, tandis que les spécifications détaillées, les archives historiques et les éléments rarement nécessaires restent accessibles par récupération.

Pourquoi ne pas simplement utiliser une fenêtre de contexte d’un million de jetons ?

Une grande fenêtre de contexte ne rend pas le contexte non pertinent gratuit ou utile. Meta a constaté qu’une divulgation progressive par étapes permettait à chaque étape du raisonnement de charger uniquement les instructions et les connaissances dont elle avait besoin, réduisant d’environ 80 % le nombre de jetons consommés par tour par rapport à son approche précédente, qui chargeait davantage de contenu.

Pourquoi conserver les connaissances organisationnelles en dehors des poids du modèle ?

Les fichiers externes sont plus faciles à inspecter, modifier, citer, versionner, comparer, tester et restaurer pour les humains. Ils permettent également à l’organisation de conserver les mêmes connaissances lorsqu’elle change de fournisseur de modèles ou met à niveau le LLM sous-jacent.

Que sont les recettes de raisonnement de Meta ?

Les recettes sont des instructions procédurales qui définissent comment l’agent doit analyser une tâche. Elles sont délibérément séparées des fichiers de connaissances : les fichiers de connaissances décrivent les faits et les positions de l’organisation, tandis que les recettes décrivent le processus de raisonnement utilisé pour les appliquer.

Comment le Second Brain de Meta apprend-il des experts ?

Les corrections des experts sont analysées afin d’en déterminer les causes profondes, converties en modifications minimales, vérifiées par une validation contradictoire et structurelle, testées avec des suites de rejeu et de régression, puis examinées par un expert humain. Les corrections réussies sont ajoutées à la suite de régression afin que les futures mises à jour les préservent.

La mémoire d’agent fondée sur des fichiers est-elle identique à une base de données vectorielle ?

Non. Une base de données vectorielle est avant tout un mécanisme de récupération. Les fichiers de connaissances structurés peuvent conserver des interprétations sélectionnées, des règles, des dépendances, des limites de raisonnement, des citations et des modifications vérifiées par des humains. Les deux peuvent être utilisés ensemble.

Les mêmes fichiers de connaissances peuvent-ils fonctionner avec différents modèles d’IA ?

Potentiellement, oui. Les formats indépendants du modèle, tels que Markdown et YAML, peuvent être utilisés par différents environnements d’exécution d’agents, à condition que les outils associés comprennent le schéma et les règles de routage. C’est l’une des raisons pour lesquelles les formats de connaissances portables suscitent davantage d’intérêt.

La mémoire d’un agent a-t-elle besoin d’un NAS ou d’un serveur domestique ?

Pas nécessairement. Les connaissances peuvent résider sur n’importe quel système de stockage fiable et autorisé. Un serveur local ou un NAS pour des connaissances IA partagées et persistantes devient utile lorsque la base de connaissances doit également prendre en charge les instantanés, les grandes archives de sources et les sauvegardes indépendantes.