PKM, RAG, Wiki et systèmes de mémoire : une explication claire

PKM, RAG, wikis et les systèmes de mémoire IA sont souvent discutés comme s’ils résolaient le même problème. Ce n’est pas le cas. Ils traitent tous du savoir, mais ils opèrent à différents niveaux :

• Le PKM aide les humains à réfléchir.
• Les wikis aident les groupes à préserver le savoir partagé.
• Le RAG aide les machines à récupérer un savoir externe.
• Les systèmes de mémoire aident les agents IA à maintenir le contexte dans le temps.

Confondre ces systèmes mène à une mauvaise architecture.

On obtient des wikis remplis de notes personnelles, des systèmes RAG sans source de vérité, des couches de mémoire qui se font passer pour des bases de données et des outils PKM surchargés d’automatisations pour lesquelles ils n’ont jamais été conçus.

Un meilleur modèle consiste à les voir comme différentes parties d’un spectre de systèmes de connaissance.

Cet article compare le PKM, le RAG, les wikis et les systèmes de mémoire IA par leur structure, leur récupération, leur propriété, leur évolution et leurs cas d’utilisation réels.

La version courte

Système	Utilisateur principal	Objectif principal	Idéal pour
PKM	Individuel	Développer le savoir personnel	Réflexion, apprentissage, synthèse
Wiki	Équipe ou groupe public	Maintenir le savoir partagé	Documentation, politiques, référence
RAG	Système machine	Récupérer le contexte pour la génération	Réponses IA sur des données externes
Mémoire IA	Agent IA	Maintenir le contexte dans le temps	Agents à long terme et personnalisation

La distinction la plus importante est la suivante :

Le PKM et les wikis structurent le savoir. Le RAG récupère le savoir. Les systèmes de mémoire font évoluer le contexte de l’agent.

C’est le modèle mental fondamental.

Pourquoi ces systèmes sont confondus

Ils se chevauchent dans leur comportement visible.

Tous peuvent :

• stocker des notes
• récupérer des informations
• répondre aux questions
• organiser les références
• connecter les idées

Mais ils diffèrent par leur intention.

Un système PKM n’est pas simplement un wiki privé. Un wiki n’est pas simplement une base de données RAG. Un pipeline RAG n’est pas une mémoire IA. Un système de mémoire IA n’est pas un remplacement pour la documentation structurée.

La confusion vient du fait de traiter le « savoir » comme une chose unique.

En pratique, le savoir a plusieurs couches :

1. Capture
2. Structure
3. Récupération
4. Interprétation
5. Réutilisation
6. Évolution

Différents systèmes optimisent différentes étapes.

Les quatre paradigmes

1. PKM

PKM signifie gestion des connaissances personnelles (Personal Knowledge Management).

C’est la pratique de capturer, organiser, connecter et utiliser le savoir pour le travail personnel.

Les systèmes PKM typiques incluent :

• Obsidian
• Logseq
• Notion
• des dossiers Markdown bruts
• les systèmes Zettelkasten
• les systèmes de « deuxième cerveau »

Le PKM est piloté par l’humain.

L’objectif n’est pas seulement le stockage. L’objectif est une meilleure réflexion.

Ce en quoi le PKM est bon

Le PKM fonctionne bien pour :

• apprendre un nouveau domaine
• développer des idées originales
• connecter les notes dans le temps
• écrire des articles ou des livres
• suivre la recherche personnelle
• construire un deuxième cerveau

Un bon système PKM est désordonné d’une manière utile. Il soutient les pensées inachevées, les idées partielles, le contexte privé et les concepts évolutifs.

C’est pourquoi le PKM n’est pas la même chose que la documentation.

La documentation veut de la clarté. Le PKM tolère l’ambiguïté.

Modes de défaillance du PKM

Le PKM échoue souvent lorsqu’il devient :

• une décharge
• un projet de taxonomie de dossiers
• une esthétique de productivité
• un hobby d’optimisation d’outils
• une archive privée que personne n’utilise

Le principal risque est la collecte sans synthèse.

Si vous ne faites que sauvegarder des informations, vous n’avez pas un système de connaissance. Vous avez une décharge personnelle.

Prise de position

Le PKM devrait optimiser la réutilisation, pas la capture.

Capturer tout semble productif, mais cela crée de la dette. La vraie valeur apparaît lorsque les notes deviennent connectées, réécrites, compressées et utilisées dans les productions.

2. Wiki

Un wiki est une base de connaissances structurée conçue pour la référence partagée.

Les systèmes wiki typiques incluent :

• DokuWiki
• MediaWiki
• Confluence
• BookStack
• des sites de documentation basés sur Git
• des bases de connaissances d’entreprise internes

Un wiki est généralement plus formel que le PKM.

Il devrait répondre à :

Que savons-nous, et où est la version actuelle ?

Ce en quoi les wikis sont bons

Les wikis fonctionnent bien pour :

• la documentation d’équipe
• les runbooks opérationnels
• les connaissances produit
• les documents de politique
• la référence technique
• le matériel d’intégration
• les connaissances stables d’un domaine

Un wiki est un contrat social.

Il dit :

Cette page est l’endroit où ce savoir vit.

Cela rend la propriété et la maintenance critiques.

Modes de défaillance des wikis

Les wikis échouent souvent parce qu’ils deviennent obsolètes.

Problèmes courants :

• pas de propriétaires de page
• captures d’écran dépassées
• pages dupliquées
• versions canoniques floues
• trop de hiérarchie
• pas de rythme de maintenance

Un wiki avec des informations anciennes est pire qu’aucun wiki, car il crée une fausse confiance.

Prise de position

Un wiki devrait être ennuyeux.

C’est un compliment.

Un bon wiki n’est pas l’endroit où les idées naissent. C’est l’endroit où le savoir stable est préservé après qu’il soit devenu utile aux autres.

3. RAG

RAG signifie génération augmentée par la récupération (Retrieval-Augmented Generation).

C’est une architecture IA où un système récupère des informations externes pertinentes avant de demander à un modèle de langage de générer une réponse.

Un pipeline RAG basique a généralement :

1. Documents
2. Découpage (Chunking)
3. Embeddings ou index de recherche
4. Récupération
5. Rééquilibrage (Reranking) optionnel
6. Assemblage du prompt
7. Génération LLM

Le RAG est piloté par la machine.

L’objectif n’est pas de créer du savoir. L’objectif est de donner au modèle un contexte pertinent au moment de la requête.

Ce en quoi le RAG est bon

Le RAG fonctionne bien pour :

• la réponse aux questions sur des documents
• les assistants de recherche internes
• les bots de support
• les assistants de documentation technique
• la recherche de conformité
• la recherche sur de grands corpus
• connecter les LLMs à des informations mises à jour

Le RAG est particulièrement utile lorsque le modèle ne peut ou ne devrait pas mémoriser l’information.

Modes de défaillance du RAG

Le RAG échoue souvent lorsque les équipes le traitent comme une recherche magique.

Problèmes courants :

• mauvais découpage
• récupération faible
• contexte bruyant
• métadonnées manquantes
• pas de source de vérité
• documents obsolètes
• évaluation faible
• pas de boucle de rétroaction humaine

Le RAG ne corrige pas une mauvaise gestion des connaissances.

Si le contenu sous-jacent est fragmenté, dépassé ou contradictoire, le système RAG fera remonter ce désordre avec confiance.

Prise de position

Le RAG n’est pas une stratégie de connaissance.

Le RAG est une stratégie d’accès.

Il aide les machines à accéder au savoir, mais il ne décide pas quel savoir est valide, maintenu, canonique ou utile.

4. Systèmes de mémoire IA

Les systèmes de mémoire IA donnent aux agents un contexte persistant au-delà d’un simple prompt ou d’une conversation.

Ils peuvent stocker :

• les préférences utilisateur
• les décisions passées
• les faits à long terme
• l’historique des tâches
• les résumés
• les réflexions
• les entités extraites
• les mémoires épisodiques
• les mémoires sémantiques

Les exemples et idées connexes incluent :

• les niveaux de mémoire style MemGPT
• la mémoire à long terme des agents
• la mémoire épisodique
• la mémoire sémantique
• la mémoire vectorielle
• la mémoire de profil
• la mémoire d’état des outils
• les agents réflexifs

La mémoire IA est pilotée par l’agent.

L’objectif est la continuité.

Ce en quoi la mémoire IA est bonne

Les systèmes de mémoire IA fonctionnent bien pour :

• les assistants personnels
• les agents de codage à long terme
• les agents de recherche
• les agents de support client
• les systèmes de tutorat
• l’automatisation des flux de travail
• les compagnons persistants
• l’exécution de tâches multi-sessions

La mémoire compte lorsque le système doit se comporter comme s’il se souvient.

Modes de défaillance de la mémoire IA

Les systèmes de mémoire sont dangereux lorsqu’ils sont non gérés.

Problèmes courants :

• se souvenir de faits incorrects
• stocker trop d’informations
• risque de confidentialité
• préférences obsolètes
• mauvais classement de la mémoire
• empoisonnement de la mémoire
• pas de mécanisme d’oubli
• confondre mémoire et vérité

Un système de mémoire a besoin de gouvernance.

Il devrait répondre à :

• Qu’est-ce qui doit être rappelé ?
• Qui l’a approuvé ?
• Combien de temps doit-il vivre ?
• Quand doit-il être oublié ?
• Comment est-il corrigé ?

Prise de position

La mémoire IA n’est pas simplement un contexte long.

Le contexte long permet à un modèle de voir plus à la fois. La mémoire décide de ce qui survit dans le temps.

Ce sont des problèmes différents.

Tableau des différences fondamentales

Dimension	PKM	Wiki	RAG	Mémoire IA
Utilisateur principal	Individuel	Équipe ou groupe public	Système IA	Agent IA
Fonction principale	Réflexion	Référence partagée	Récupération à la requête	Contexte persistant
État du savoir	Évolutif	Stabilisé	Récupéré	Adaptatif
Structure	Flexible	Explicite	Basée sur l’index	Apprise ou extraite
Style de récupération	Recherche et liaison humaine	Navigation et recherche	Récupération sémantique ou hybride	Pertinence plus saillance
Propriété	Personnelle	Propriétaires de page ou d’équipe	Mainteneurs du système	Contrôlé par l’agent ou l’utilisateur
Horizon temporel	Long terme personnel	Long terme partagé	Moment de la requête	Multi-session
Meilleure production	Insight	Référence fiable	Réponse fondée	Continuité
Risque principal	Accumulation	Obsolescence	Mauvaise récupération	Mauvaise mémoire
Bonne métrique	Réutilisation dans la réflexion	Confiance et fraîcheur	Qualité de la réponse	Continuité utile

Structure vs récupération vs évolution

La manière la plus simple de comprendre ces systèmes est de comparer ce qu’ils optimisent. Les implications architecturales de cette distinction sont explorées en profondeur dans Récupération vs Représentation dans les Systèmes de Connaissance.

Le PKM optimise l’évolution personnelle

Le PKM concerne la façon dont votre compréhension change.

Vous collectez du matériel, le réécrivez, le connectez et le transformez en quelque chose d’utile.

La production est souvent :

• un meilleur modèle mental
• un article écrit
• une décision
• une direction de recherche
• un insight réutilisable

Le PKM n’est pas principalement une recherche rapide. C’est une interprétation à long terme.

Les wikis optimisent la structure partagée

Les wikis concernent le savoir stable.

Ils demandent :

• Quelle est la réponse actuelle ?
• Qui en est propriétaire ?
• Où les gens devraient-ils aller ?
• Qu’est-ce qui doit être mis à jour ?

Un wiki fonctionne quand les gens lui font confiance.

Le RAG optimise la récupération machine

Le RAG concerne la récupération du bon contexte au bon moment.

Il demande :

• Quels documents sont pertinents ?
• Quels segments doivent être utilisés ?
• Combien de contexte tient-il ?
• Que le modèle doit-il citer ?

Le RAG fonctionne lorsque la qualité de la récupération est élevée et que le corpus source est digne de confiance.

La mémoire IA optimise la continuité

Les systèmes de mémoire concernent la persistance à travers les sessions.

Ils demandent :

• Qu’est-ce que l’agent doit se souvenir ?
• Qu’est-ce qui doit être oublié ?
• Quelle mémoire importe maintenant ?
• Comment la mémoire doit-elle changer le comportement ?

La mémoire fonctionne lorsqu’elle améliore le futur comportement sans polluer l’agent avec un contexte obsolète ou incorrect.

Quand utiliser le PKM

Utilisez le PKM lorsque le savoir est personnel, inachevé ou exploratoire.

Bons scénarios :

• apprendre les systèmes distribués
• planifier des articles
• rechercher l’architecture des LLM
• collecter des notes de livres
• construire un deuxième cerveau
• suivre les expériences personnelles

Utilisez le PKM lorsque vous réfléchissez encore.

Exemple

Vous apprenez l’évaluation du RAG.

Vous collectez :

• des articles
• des notes de benchmarks
• des diagrammes
• des idées d’implémentation
• des échecs de vos propres expériences

Cela appartient d’abord au PKM.

Plus tard, une fois que le savoir se stabilise, vous pouvez publier un article ou le transformer en documentation.

Quand utiliser un wiki

Utilisez un wiki lorsque le savoir doit être partagé et maintenu.

Bons scénarios :

• intégration d’équipe
• documentation API
• runbooks opérationnels
• registres de décision d’architecture
• connaissances produit
• instructions de déploiement
• procédures de support

Utilisez un wiki lorsque d’autres ont besoin d’une réponse fiable.

Exemple

Votre équipe a une seule manière correcte de déployer un site Hugo sur S3 et CloudFront.

Cela n’appartient pas seulement aux notes privées de quelqu’un.

Cela appartient à un wiki ou à un système de documentation avec une propriété claire.

Quand utiliser le RAG

Utilisez le RAG lorsqu’un système IA a besoin d’accéder à un savoir externe au moment de la requête.

Bons scénarios :

• chatbot sur la documentation
• assistant de recherche sur les documents internes
• assistant de support sur les articles d’aide
• assistant juridique ou de conformité
• recherche sur de grands ensembles de documents
• assistant développeur sur la documentation du code

Utilisez le RAG lorsque le problème est :

Le modèle a besoin d’informations qui existent en dehors de ses poids.

Exemple

Vous avez des centaines d’articles techniques et vous voulez qu’un assistant réponde aux questions en les utilisant.

Le RAG est un bon choix.

Mais seulement si les documents sont assez propres pour être récupérés.

Quand utiliser la mémoire IA

Utilisez la mémoire IA lorsqu’un agent a besoin de continuité.

Bons scénarios :

• agents de codage qui se souviennent des conventions du projet
• assistants personnels qui se souviennent des préférences
• agents de recherche qui continuent de longues investigations
• agents de tutorat qui se souviennent des progrès des étudiants
• agents de support qui se souviennent des interactions précédentes
• agents autonomes qui suivent les objectifs

Utilisez la mémoire lorsque le système doit s’améliorer dans le temps.

Exemple

Un agent de codage devrait se souvenir :

• le projet utilise Go
• les tests s’exécutent avec une commande spécifique
• l’utilisateur préfère des dépendances minimales
• les migrations de base de données suivent une convention

Ce n’est pas seulement de la récupération. C’est un contexte opérationnel persistant.

Comment ces systèmes se combinent

Les systèmes les plus utiles sont des hybrides.

Une architecture de connaissance mature pourrait ressembler à ceci :

1. PKM pour l’exploration personnelle
2. Wiki pour le savoir partagé stable
3. RAG pour l’accès machine
4. Mémoire IA pour la continuité des agents à long terme

Chaque couche a un rôle.

Modèle 1. PKM vers Wiki

C’est le pipeline de connaissance humaine.

Flux :

1. Capturer des notes en privé
2. Connecter les idées
3. Distiller les insights
4. Publier un savoir stable
5. Maintenir comme référence partagée

C’est ainsi que la recherche personnelle devient une connaissance organisationnelle.

Exemple

Vous recherchez des outils de connaissance auto-hébergés dans Obsidian.

Après avoir testé DokuWiki, Nextcloud et les systèmes Markdown statiques, vous écrivez un guide stable sur votre site ou le wiki de l’équipe.

Le PKM a créé l’insight. Le wiki préserve le résultat.

Modèle 2. Wiki vers RAG

C’est le pipeline d’accès machine.

Flux :

1. Maintenir des pages wiki canoniques
2. Les indexer
3. Récupérer les sections pertinentes
4. Générer des réponses fondées
5. Lier vers les sources

C’est l’un des modèles RAG les plus propres.

Le wiki reste la source de vérité. Le RAG devient la couche d’accès.

Exemple

Un bot de support répond aux questions en utilisant un wiki produit.

Le bot ne devrait pas remplacer le wiki. Il devrait citer et rediriger les utilisateurs vers les pages canoniques.

Modèle 3. RAG plus mémoire

C’est le pipeline de continuité de l’agent.

Flux :

1. Le RAG récupère des faits externes
2. La mémoire stocke le contexte utilisateur ou de tâche
3. L’agent combine les deux
4. Le comportement futur s’améliore

Le RAG répond à :

Que dit la base de connaissances ?

La mémoire répond à :

Qu’est-ce qui compte pour cet utilisateur, ce projet ou cette tâche ?

Exemple

Un agent de codage utilise le RAG pour récupérer la documentation du framework.

Il utilise la mémoire pour se souvenir que votre projet évite les ORM, préfère sqlc et utilise la journalisation structurée.

Ce sont des types de connaissance différents.

Modèle 4. PKM plus assistant IA

C’est le pipeline de réflexion hybride.

Flux :

1. L’humain capture des notes
2. L’IA résume et suggère des liens
3. L’humain édite et valide
4. La connaissance devient plus structurée
5. Certaines pages passent au wiki ou à la publication

L’IA augmente le système PKM, mais elle ne devrait pas posséder la vérité.

Exemple

Un assistant IA peut suggérer des connexions entre des notes sur le RAG, les systèmes de mémoire et le Wiki LLM.

Mais l’humain décide quelles connexions sont significatives.

Erreurs d’architecture courantes

Erreur 1. Traiter le RAG comme un wiki

Le RAG n’est pas une base de connaissances.

Il ne crée pas automatiquement une structure canonique. Il récupère ce qui existe.

Si les documents source sont mauvais, le RAG devient une interface confiante vers un mauvais savoir.

Erreur 2. Traiter la mémoire comme une base de données

La mémoire IA est un contexte sélectif, pas un stockage général.

Une base de données stocke des enregistrements. La mémoire change le comportement.

Si vous avez besoin de faits exacts, utilisez une base de données ou une base de connaissances. Si vous avez besoin de continuité, utilisez la mémoire.

Erreur 3. Traiter le PKM comme de la documentation

Le PKM peut être désordonné.

La documentation ne devrait pas l’être.

Les notes privées peuvent contenir des idées à moitié formées. La documentation partagée devrait contenir un savoir stable et maintenu.

Erreur 4. Traiter un wiki comme un outil de réflexion

Un wiki peut soutenir la réflexion, mais il n’est pas idéal pour l’exploration précoce.

Si chaque pensée précoce doit devenir une page polie, les gens cessent d’écrire.

Utilisez le PKM pour la réflexion brute. Utilisez les wikis pour le savoir durable.

Erreur 5. Traiter le contexte long comme de la mémoire

Le contexte long n’est pas de la mémoire.

Il n’aide que tant que le contexte est présent.

La mémoire persiste, sélectionne, met à jour et parfois oublie.

Guide de décision

Utilisez ce modèle de décision simple.

Si le savoir est privé et évolutif

Utilisez le PKM.

Si le savoir est partagé et stable

Utilisez un wiki.

Si une IA doit répondre à partir de documents externes

Utilisez le RAG.

Si un agent a besoin de continuité dans le temps

Utilisez la mémoire.

Si vous avez besoin des quatre

Construisez un système en couches.

Ne forcez pas un outil à faire chaque travail.

Le spectre des systèmes de connaissance

Ces systèmes forment un spectre de la pensée humaine à la continuité IA.

Couche	Système	Rôle
Pensée humaine	PKM	Explorer et synthétiser
Structure partagée	Wiki	Préserver et maintenir
Accès machine	RAG	Récupérer et générer
Continuité de l’agent	Mémoire	Persister et s’adapter

La direction importe.

Le savoir commence souvent comme une pensée personnelle, devient une structure partagée, est indexé pour la récupération machine, puis devient partie du comportement persistant de l’agent.

C’est la pile de connaissance moderne.

Où LLM Wiki s’insère

Les systèmes de type LLM Wiki se situent entre le wiki et l’architecture IA.

Ce n’est pas du RAG classique.

Au lieu de récupérer des segments uniquement au moment de la requête, ils tentent de pré-structurer le savoir en pages, résumés, entités et liens.

Cela les rapproche des systèmes de connaissance compilée.

Un placement utile :

Système	Position
Wiki	Savoir structuré maintenu par l’humain
RAG	Récupération machine à la requête
LLM Wiki	Savoir structuré par la machine à l’ingestion
Mémoire	Contexte persistant de l’agent

C’est pourquoi le LLM Wiki appartient près de l’architecture des systèmes de connaissance, pas à l’intérieur du RAG ordinaire.

Exemples pratiques

Exemple 1. Blog technique personnel

Un blogueur technique pourrait utiliser :

• PKM pour les notes de recherche
• site Hugo comme savoir publié
• liaison interne comme structure de type wiki
• RAG plus tard pour la recherche sur le site
• mémoire IA pour les préférences de l’assistant d’écriture

C’est une architecture solide.

Elle garde le jugement humain au centre tout en permettant le support IA.

Exemple 2. Équipe d’ingénierie

Une équipe d’ingénierie pourrait utiliser :

• PKM pour l’apprentissage individuel
• wiki pour les standards et les runbooks
• assistant RAG pour les documents internes
• mémoire pour les agents de codage travaillant dans les dépôts

Le wiki devrait rester canonique.

L’assistant RAG ne devrait pas inventer de processus. La couche de mémoire devrait se souvenir des préférences du projet, pas remplacer les décisions d’architecture.

Exemple 3. Flux de travail de recherche IA

Un chercheur pourrait utiliser :

• PKM pour les notes de papier
• wiki pour les résumés stables
• RAG pour la recherche de littérature
• mémoire pour les agents de recherche à long terme

Cela fonctionne parce que chaque couche gère une échelle de temps différente.

Sécurité et gouvernance

Les systèmes de connaissance deviennent risqués lorsqu’ils stockent des informations sensibles ou obsolètes.

Gouvernance du PKM

Questions :

• Qu’est-ce qui devrait rester privé ?
• Qu’est-ce qui devrait être publié ?
• Qu’est-ce qui devrait être supprimé ?

Gouvernance du Wiki

Questions :

• Qui possède chaque page ?
• Quand a-t-elle été revue pour la dernière fois ?
• Qu’est-ce qui est canonique ?

Gouvernance du RAG

Questions :

• Quelles sources sont indexées ?
• Les réponses sont-elles citées ?
• Comment la récupération est-elle évaluée ?
• Quel contenu est exclu ?

Gouvernance de la mémoire

Questions :

• Qu’est-ce qui est rappelé ?
• Les utilisateurs peuvent-ils inspecter la mémoire ?
• Les utilisateurs peuvent-ils supprimer la mémoire ?
• Comment les mauvaises mémoires sont-elles corrigées ?

La mémoire a besoin de la gouvernance la plus stricte car elle peut influencer silencieusement le comportement futur.

Note sur le SEO et la stratégie de contenu

Si vous gérez un site technique, cette distinction n’est pas seulement architecturale. Elle est aussi éditoriale.

Vous pouvez mapper le contenu comme ceci :

• Les pages PKM expliquent les pratiques de connaissance humaine.
• Les pages Wiki expliquent les systèmes de connaissance structurés.
• Les pages RAG expliquent l’ingénierie de récupération.
• Les pages Mémoire expliquent le comportement IA persistant.
• Les pages Architecture comparent et connectent les paradigmes.

Cela donne à votre site un maillage d’autorité propre au lieu d’un tas d’articles IA vaguement liés.

Conclusion finale

Le PKM, le RAG, les wikis et les systèmes de mémoire IA ne sont pas des concurrents.

Ce sont des réponses différentes à des questions différentes.

Le PKM demande :

Comment puis-je mieux réfléchir avec le temps ?

Un wiki demande :

Que savons-nous, et où est la version de confiance ?

Le RAG demande :

Quel contexte externe le modèle doit-il utiliser maintenant ?

La mémoire IA demande :

Qu’est-ce que cet agent doit se souvenir pour l’avenir ?

Une fois que vous séparez ces questions, l’architecture devient évidente.

Utilisez le PKM pour réfléchir. Utilisez les wikis pour la vérité partagée. Utilisez le RAG pour la récupération. Utilisez la mémoire pour la continuité.

L’avenir n’est pas un système de connaissance qui remplace tous les autres.

L’avenir est une architecture de connaissance en couches. Pour les outils, méthodes et plateformes auto-hébergées à travers tout le spectre de la gestion des connaissances, les cartes piliers de grappes cartographient le territoire.

Sources et lectures complémentaires

• https://cloud.google.com/use-cases/retrieval-augmented-generation
• https://aws.amazon.com/what-is/retrieval-augmented-generation/
• https://www.ibm.com/think/topics/retrieval-augmented-generation
• https://www.ibm.com/think/topics/knowledge-management
• https://arxiv.org/abs/2310.08560
• https://research.memgpt.ai/
• https://zettelkasten.de/posts/building-a-second-brain-and-zettelkasten/