Récupération vs Représentation dans les Systèmes de Connaissance

La plupart des systèmes de connaissances modernes optimisent la récupération (retrieval), et cela est compréhensible. La recherche est visible, facile à démontrer et semble magique lorsqu’elle fonctionne. Tapez une question, obtenez une réponse.

Mais la récupération n’est qu’une partie du problème. La question plus fondamentale est :

Quelle est la forme des connaissances avant que quoi que ce soit ne tente de les récupérer ?

C’est la représentation — la structure derrière les connaissances :

• notes
• pages
• schémas
• graphes
• entités
• relations
• résumés
• taxonomies
• limites des sources
• versions canoniques

La récupération demande :

Puis-je trouver quelque chose de pertinent ?

La représentation demande :

Les connaissances sont-elles organisées de manière logique ?

Ce ne sont pas le même problème. Un système RAG avec une mauvaise représentation devient une interface rapide vers une archive en désordre. Il peut récupérer des fragments, mais il ne peut pas réparer une structure brisée. Il peut citer des documents, mais il ne peut pas décider lequel est canonique. Il peut assembler du contexte, mais il ne peut pas garantir que les connaissances sous-jacentes sont cohérentes.

C’est pourquoi les systèmes de style LLM Wiki sont intéressants : ils déplacent l’effort du temps de requête au temps d’ingestion. Au lieu de simplement récupérer des fragments lorsqu’un utilisateur pose une question, ils tentent de pré-structurer les connaissances en pages, concepts, résumés et liens. Cela ne rend pas le RAG obsolète — cela signifie que la récupération et la représentation sont des couches différentes, et les bons systèmes de connaissances ont besoin des deux.

La distinction fondamentale

La récupération concerne l’accès ; la représentation concerne le sens.

Un système faible passe souvent directement à la récupération ; un système fort se pose d’abord les questions suivantes :

1. Quels sont les concepts fondamentaux ?
2. Quelle est la source canonique ?
3. Quelles relations sont importantes ?
4. Qu’est-ce qui change avec le temps ?
5. Qu’est-ce qui doit être récupéré ?
6. Qu’est-ce qui doit déjà être représenté ?

C’est la différence entre une recherche sur des documents et un véritable système de connaissances.

Pourquoi la récupération est devenue dominante

La récupération est devenue dominante car elle s’aligne bien avec la pile AI moderne. Un pipeline RAG typique ressemble à ceci :

1. Charger les documents
2. Les diviser en fragments (chunks)
3. Générer des embeddings
4. Stocker les vecteurs
5. Récupérer les fragments pertinents
6. Les ré-ordonner en option
7. Les insérer dans un prompt LLM
8. Générer une réponse

Ce pipeline est pratique : il est relativement facile à construire, fonctionne avec des documents désorganisés, passe à l’échelle pour de grands corpus, évite de réentraîner les modèles et donne aux LLMs accès à l’information actuelle. C’est pourquoi le RAG est devenu le modèle par défaut pour l’« IA sur documents ».

Mais il y a un piège :

Le RAG améliore l’accès aux connaissances. Il n’améliore pas automatiquement les connaissances elles-mêmes.

Si votre contenu est dupliqué, périmé, contradictoire, mal fragmenté ou mal nommé, la récupération mettra ces problèmes en évidence — souvent avec confiance.

Ce que signifie la représentation

La représentation est la manière dont les connaissances sont façonnées avant que la récupération n’ait lieu. Elle répond à des questions comme :

• Ces connaissances sont-elles stockées sous forme de documents, de notes, d’entités ou de faits ?
• Les relations sont-elles explicites ou implicites ?
• Y a-t-il des pages canoniques ?
• Y a-t-il des résumés ?
• Les concepts sont-ils liés ?
• Le système est-il organisé par thème, flux de travail, temps ou propriété ?
• Un humain peut-il le maintenir ?
• Une machine peut-elle raisonner dessus ?

La représentation n’est pas une décoration — elle détermine le type d’opérations possibles.

Formes de représentation

Documents

Les documents sont la représentation la plus courante. Les exemples incluent :

• articles
• PDFs
• manuels
• rapports
• fichiers README
• pages de support
• articles de blog

Les documents sont faciles à écrire pour les humains, mais ils sont souvent difficiles à utiliser pour les machines car ils mélangent faits, narration, contexte, exemples, opinions, sections périmées et explications répétées dans le même conteneur. Les documents sont de bons conteneurs, mais ils ne sont pas toujours de bonnes structures de connaissances.

Notes

Les notes sont plus flexibles que les documents. Elles peuvent être :

• atomiques
• liées
• privées
• inachevées
• centrées sur les concepts

Un système de notes, tel qu’un PKM ou un second brain, peut représenter des connaissances évolutives mieux qu’un dépôt de documents soigneusement polis. De bonnes notes capturent la pensée en cours ; de mauvaises notes deviennent un tiroir à poubelle introuvable.

Wikis

Les wikis représentent les connaissances sous forme de pages maintenues. Un bon wiki possède :

• des pages stables
• des sujets clairs
• des liens internes
• une propriété (ownership)
• des réponses canoniques
• des modèles de mise à jour

Un wiki est plus robuste qu’un dépôt de documents dispersé car il donne une adresse aux connaissances. La « liste de vérification de déploiement » réside à un seul endroit. La « réponse aux incidents » réside à un seul endroit. L’« architecture RAG » réside à un seul endroit. Cela compte car la récupération fonctionne mieux lorsque les connaissances ont une structure stable.

Graphes de connaissances

Les graphes de connaissances représentent les connaissances sous forme d’entités et de relations. Au lieu de stocker uniquement du texte, ils modélisent des éléments tels que :

• Personne travaille sur Projet
• Modèle supporte ContextLength
• Page dépend de Concept
• Service se connecte à BaseDeDonnées
• Outil implémente Protocole

Les graphes sont puissants car les relations deviennent explicites, ce qui aide pour la traversée, l’analyse des dépendances, la résolution des entités, la lignée, le raisonnement et les recommandations. Mais les graphes sont coûteux à maintenir et ils ne sont pas magiques — un mauvais graphe n’est que de la confusion structurée.

Schémas et ontologies

Les schémas définissent la structure attendue ; les ontologies vont plus loin et définissent les types, les relations et les contraintes. Elles répondent à :

• Quels types de choses existent ?
• Quelles propriétés ont-elles ?
• Comment peuvent-elles se relier ?
• Quelles règles s’appliquent ?

Ceci est utile lorsque la justesse est importante, comme dans les connaissances médicales, juridiques, les catalogues de données d’entreprise, les taxonomies de produits et les systèmes de conformité. Le compromis est la rigidité : plus la représentation est formelle, plus elle est coûteuse à faire évoluer.

Représentations générées par LLM

Les systèmes modernes utilisent de plus en plus les LLMs pour créer des représentations. Les exemples incluent :

• résumés
• entités extraites
• pages de sujets
• cartes conceptuelles
• FAQs synthétiques
• plans de documents
• liens croisés
• entrées de glossaire

C’est là que se situent les systèmes de style LLM Wiki. Ils utilisent le modèle non seulement pour répondre aux requêtes, mais pour pré-traiter et structurer les connaissances avant que la requête n’ait lieu. Le RAG dit « récupérer des fragments pertinents au moment de la requête » ; LLM Wiki dit « compiler des structures de connaissances utiles au moment de l’ingestion ». Les deux modèles peuvent coexister dans la même architecture.

Ce que signifie la récupération

La récupération est le processus de recherche d’informations pertinentes. Les méthodes de récupération courantes incluent :

• recherche par mots-clés
• recherche textuelle complète
• recherche vectorielle
• recherche hybride
• filtrage par métadonnées
• traversée de graphe
• ré-ordonnancement
• réécriture de requête
• recherche agentic

La récupération n’est pas une seule chose — c’est une pile de méthodes complémentaires.

Recherche par mots-clés

La recherche par mots-clés correspond aux termes et reste utile car elle est prévisible, débogable, rapide et bonne pour les termes exacts, les IDs, les messages d’erreur, les noms et le code. Sa faiblesse est l’inadéquation sémantique : si l’utilisateur recherche « comment arrêter les réponses répétées » mais que le document dit « pénalité de présence », la recherche par mots-clés peut manquer le meilleur résultat.

Recherche vectorielle

La recherche vectorielle récupère par similarité sémantique. Elle est utile lorsque :

• la formulation diffère
• les concepts sont flous
• les utilisateurs posent des questions en langage naturel
• les documents utilisent une terminologie incohérente

Sa faiblesse est la précision — la recherche vectorielle peut récupérer des choses qui semblent liées mais qui ne sont pas réellement correctes, ce qui est particulièrement risqué dans les systèmes techniques.

Recherche hybride

La recherche hybride combine la récupération par mots-clés et vectorielle, ce qui est souvent supérieur à l’une ou l’autre seule. La recherche par mots-clés attrape les correspondances exactes ; la recherche vectorielle attrape les correspondances conceptuelles. Pour les bases de connaissances techniques, la récupération hybride est généralement un bon point de départ.

Ré-ordonnancement

Le Ré-ordonnancement prend un ensemble initial de résultats récupérés et les réorganise en utilisant un modèle plus puissant. Cela améliore la qualité car l’étape initiale de récupération est souvent large. Un modèle typique récupère 50 fragments, ré-ordonne vers les 5 ou 10 meilleurs, puis ne passe que le meilleur contexte au LLM. Le ré-ordonnancement est l’un des moyens les plus pratiques d’améliorer la qualité du RAG.

Récupération agentic

La récupération agentic transforme la recherche en un processus. Au lieu d’une seule requête, un agent peut :

1. Poser une question initiale
2. Chercher
3. Inspecter les résultats
4. Reformuler la requête
5. Chercher à nouveau
6. Comparer les sources
7. Synthétiser une réponse

C’est plus proche de la recherche que de la simple recherche. C’est utile pour les questions complexes, mais c’est plus lent et plus difficile à contrôler.

La récupération sans représentation est fragile

Un système de récupération ne peut récupérer que ce qui existe. Il ne peut pas fièrement réparer :

• des concepts flous
• des pages dupliquées
• une terminologie incohérente
• une documentation périmée
• une propriété de source manquante
• des déclarations contradictoires
• un lien interne faible
• de mauvaises limites de documents

C’est l’erreur la plus courante dans les projets RAG : les équipes construent une base de données vectorielle et s’attendent à ce qu’elle devienne un système de connaissances. Une base de données vectorielle n’est pas une architecture de connaissances — c’est une couche d’accès.

La représentation sans récupération est isolée

L’échec inverse existe également. Vous pouvez avoir une base de connaissances magnifiquement structurée que personne ne peut trouver. Cela arrive avec :

• des wikis sur-conçus
• des arbres de dossiers profonds
• des taxonomies rigides
• une documentation mal indexée
• des systèmes de notes privés sans découverte
• des graphes sans interfaces utilisables

La représentation donne une structure aux connaissances ; la récupération donne une portée aux connaissances. Vous avez besoin des deux.

La carte des compromis

Vitesse vs cohérence

La récupération est rapide à construire et la représentation prend plus de temps. Si vous avez besoin d’un prototype, la récupération gagne ; si vous avez besoin de confiance à long terme, la représentation est plus importante.

Un prototype RAG pur peut être construit rapidement, mais un système de connaissances fiable nécessite une curation.

Flexibilité vs cohérence

Les documents libres sont flexibles ; les connaissances structurées sont cohérentes. La flexibilité aide lorsque :

• le domaine change rapidement
• les connaissances sont incomplètes
• les utilisateurs explorent
• le système est personnel

La cohérence aide lorsque :

• plusieurs personnes s’y appuient
• les réponses doivent être fiables
• des flux de travail en dépendent
• des systèmes AI les consomment

Plus de personnes ou d’agents dépendent des connaissances, plus la représentation est importante.

Rappel vs précision

Les systèmes de récupération optimisent souvent le rappel en premier, ce qui signifie trouver tout ce qui pourrait être pertinent. Mais de bonnes réponses nécessitent de la précision, ce qui signifie trouver la meilleure preuve plutôt que simplement une preuve liée. La représentation améliore la précision en rendant les concepts et les limites plus clairs — une page bien structurée est plus facile à récupérer avec précision qu’un paragraphe aléatoire enfoui dans un long document.

Coût à l’ingestion vs coût à la requête

Le RAG pousse généralement le travail au moment de la requête. Au moment de la requête, le système :

• réécrit la requête
• récupère des fragments
• ré-ordonne les résultats
• assemble le contexte
• demande au modèle de raisonner sur des fragments

Les systèmes de style LLM Wiki poussent plus de travail au moment de l’ingestion. Au moment de l’ingestion, le système :

• lit les sources
• extrait les concepts
• écrit des résumés
• crée des pages
• lie les idées apparentées
• maintient la structure

Aucun de ceux-ci n’est universellement meilleur — ils optimisent différents coûts.

Pourquoi LLM Wiki existe

LLM Wiki existe car la récupération seule répète souvent le travail. Dans un système RAG normal, chaque requête peut forcer le modèle à interpréter à nouveau des fragments bruts :

1. Récupérer des fragments sur un sujet
2. Demander au LLM d’inférer le concept
3. Générer une réponse
4. Oublier la synthèse
5. Répéter la prochaine fois

LLM Wiki dit :

Arrêtez de re-déduire la même synthèse. Compilez-la.

Au lieu de stocker uniquement des documents bruts, il crée des pages structurées qui résument et connectent les connaissances, ce qui peut améliorer la cohérence, la réutilisation, l’efficacité des tokens, la lisibilité humaine et la maintenance à long terme. Mais cela a un coût : le système doit maintenir le wiki, et si le wiki est faux, périmé ou halluciné, la structure devient dangereuse.

Hallucination RAG vs mauvaise représentation

Les gens blâment souvent le LLM lorsqu’un système RAG donne une mauvaise réponse, et parfois c’est correct. Mais de nombreux échecs sont en réalité des échecs de récupération ou de représentation.

Mode de défaillance 1. Document correct, fragment incorrect

La réponse existe, mais le chunking la divise mal. Le modèle reçoit :

• la moitié d’un paragraphe
• un contexte manquant
• un tableau sans explication
• une définition sans contraintes

Le LLM comble ces lacunes, ce qui ressemble à une hallucination, mais le problème plus profond est une représentation brisée.

Mode de défaillance 2. Fragment lié, réponse incorrecte

La recherche vectorielle récupère quelque chose de sémantiquement similaire mais opérationnellement incorrect. La requête concerne le déploiement en production ; le fragment récupéré discute du développement local. Les termes se chevauchent mais le sens diffère, donc le modèle répond avec des instructions de configuration locale pour un problème de production. C’est de l’imprécision de récupération.

Mode de défaillance 3. Sources contradictoires

Deux documents sont en désaccord — l’un ancien, l’autre nouveau. Le système de récupération les retourne tous les deux, et le LLM les fusionne en une réponse confiante mais invalide. Ce n’est pas seulement un problème de récupération mais un problème de représentation, car la base de connaissances manque d’état canonique.

Mode de défaillance 4. Pas de modèle conceptuel

Le système a de nombreux documents mais aucun modèle du domaine. Il ne sait pas que :

• la « mémoire d’agent » diffère du « RAG »
• le « wiki » diffère du « PKM »
• la « recherche d’embedding » diffère de la « recherche textuelle complète »
• le « déploiement » diffère de l’« hébergement »

Sans représentation conceptuelle, la récupération devient une correspondance floue.

Mode de défaillance 5. La structure générée devient une fausse autorité

Les systèmes LLM Wiki ont leur propre mode de défaillance. Si un LLM génère une page propre à partir de mauvaises sources, le résultat peut sembler plus autoritaire que le matériel original. C’est dangereux : une hallucination polie est pire qu’un document source en désordre. Toute représentation générée a besoin de :

• liens vers les sources
• révision
• règles de mise à jour
• marqueurs de confiance
• propriété (ownership)

Implications pour la conception

Optimiser la récupération lorsque le corpus est vaste et dynamique

La récupération devrait être la priorité lorsque :

• le corpus est immense
• les documents changent fréquemment
• les utilisateurs posent de nombreuses questions imprévisibles
• vous avez besoin d’une couverture large
• une structure parfaite est irréaliste

Exemples : bases de connaissances de support, recherche de documents d’entreprise, assistants de recherche, chat interne sur de nombreux fichiers, découverte juridique et bots de service client. Dans ces cas, investissez dans une forte récupération :

• recherche hybride
• filtres de métadonnées
• ré-ordonnancement
• réécriture de requête
• citation des sources
• ensembles d’évaluation

Optimiser la représentation lorsque la cohérence est importante

La représentation devrait être la priorité lorsque :

• les connaissances doivent être fiables
• les réponses doivent être cohérentes
• les concepts sont réutilisés souvent
• le domaine a une structure claire
• plusieurs systèmes en dépendent

Exemples : connaissances architecturales, documentation produit, règles de conformité, références API, runbooks opérationnels, collections de recherche curated et clusters de blogs techniques. Dans ces cas, investissez dans :

• pages canoniques
• termes de glossaire
• diagrammes
• liens internes
• propriété (ownership)
• versioning
• cadence de révision

Optimiser les deux lorsque les systèmes AI dépendent des connaissances

Si un agent AI dépend des connaissances, la récupération seule est généralement insuffisante. Les agents ont besoin de :

• contexte stable
• règles de tâche claires
• mémoire durable
• références structurées
• limites de source
• comportement de mise à jour

Pour les systèmes agentic, la représentation devient partie intégrante de la conception du système. Un agent de codage n’a pas seulement besoin de récupérer « certains documents » — il doit connaître :

• les conventions du projet
• les décisions architecturales
• les modèles de commandes
• les dépendances interdites
• le flux de travail de test
• les règles de déploiement

Une partie de cela appartient au RAG, une partie à la mémoire, et une partie à la documentation structurée du projet.

Cadre de décision pratique

Si le problème est de trouver des informations

Optimisez la récupération. Exemples :

• « Trouver des pages pertinentes. »
• « Répondre aux questions sur des documents. »
• « Chercher à travers de nombreux PDFs. »
• « Localiser des tickets de support similaires. »

Utilisez :

• recherche textuelle complète
• recherche vectorielle
• récupération hybride
• ré-ordonnancement
• filtrage de métadonnées

Si le problème est de rendre les connaissances cohérentes

Optimisez la représentation. Exemples :

• « Créer une explication canonique. »
• « Résoudre les pages dupliquées. »
• « Définir le modèle de domaine. »
• « Construire une base de connaissances stable. »

Utilisez :

• pages wiki
• cartes conceptuelles
• taxonomies
• graphes de connaissances
• résumés
• schémas

Si le problème est une synthèse répétée

Utilisez une représentation compilée. Exemples :

• « Nous répondons aux mêmes questions conceptuelles répétitivement. »
• « Le système ré-summarise continuellement les mêmes sources. »
• « Nous avons besoin d’une couche de synthèse stable. »

Utilisez :

• LLM Wiki
• résumés curated
• pages de sujets
• pages générées révisées par des humains

Si le problème est la continuité adaptative

Utilisez la mémoire. Exemples :

• « L’agent devrait se souvenir des préférences utilisateur. »
• « L’agent de codage devrait se souvenir des conventions du projet. »
• « L’assistant devrait continuer le travail à travers les sessions. »

Utilisez :

• mémoire d’agent
• magasins de préférences
• mémoire épisodique
• mémoire sémantique
• mémoire de projet

Comment cela s’applique à un blog technique

Un blog technique peut être plus qu’une séquence de posts — il peut devenir un système de connaissances représenté. Les articles sont des documents, les catégories sont une taxonomie faible, les liens internes sont des arêtes de graphe, les pages piliers sont des résumés canoniques, les pages de série sont des chemins curated, et la recherche est la récupération. Si vous publiez uniquement des posts isolés, la récupération doit travailler plus dur. Si vous construisez une forte représentation, la récupération devient plus facile.

Cela signifie :

• des limites de cluster claires
• des slugs stables
• des pages canoniques
• des pages de comparaison
• des explications style glossaire
• des liens internes
• des métadonnées structurées

C’est pourquoi l’architecture du site compte — pas seulement pour le SEO, mais parce que c’est une représentation des connaissances. Le cluster Knowledge Management sur ce site est lui-même un exemple de publication axée sur la représentation.

Comment cela s’applique au RAG

La qualité du RAG dépend fortement de la représentation. Un corpus source bien structuré améliore :

• la qualité des fragments
• la précision de la récupération
• la qualité des citations
• la cohérence des réponses
• la clarté de l’évaluation

Avant de construire un pipeline RAG complexe, demandez :

1. Les documents sources sont-ils actuels ?
2. Les doublons sont-ils supprimés ?
3. Les concepts importants sont-ils clairement nommés ?
4. Les pages sont-elles scoupées correctement ?
5. Les tableaux et blocs de code sont-ils récupérables ?
6. Les réponses canoniques sont-elles évidentes ?
7. Les limites des documents sont-elles significatives ?

Si la réponse est non, de meilleurs embeddings n’aideront que tant.

Comment cela s’applique à LLM Wiki

LLM Wiki est un modèle axé sur la représentation. Il est utile lorsque :

• le corpus est petit ou moyen
• les connaissances sont suffisamment stables pour être résumées
• la synthèse répétée est coûteuse
• les humains bénéficient de pages lisibles
• vous voulez de la structure avant la récupération

Il est moins utile lorsque :

• le corpus est massif
• le contenu change constamment
• la fraîcheur est plus importante que la cohérence
• la gouvernance est faible
• les résumés générés ne peuvent pas être révisés

LLM Wiki n’est pas un remplacement pour le RAG mais une couche différente, et un système fort peut utiliser les deux :

1. LLM Wiki crée des résumés structurés.
2. Le RAG récupère à partir des sources brutes et des pages du wiki.
3. La révision humaine maintient la représentation fiable.

Modèles d’architecture suggérés

Modèle 1. Récupération d’abord

À utiliser lorsque la vitesse compte.

documents
  -> fragments
  -> embeddings
  -> récupération
  -> réponse LLM

Bon pour :

• prototypes
• recherche large
• grands corpus
• expériences précoces

Faiblesse : la cohérence dépend de la qualité de la source.

Modèle 2. Représentation d’abord

À utiliser lorsque la confiance compte.

sources
  -> pages curated
  -> liens internes
  -> base de connaissances maintenue
  -> recherche ou RAG

Bon pour :

• documentation
• connaissances techniques
• contenu à long terme
• connaissances d’équipe

Faiblesse : nécessite de la maintenance.

Modèle 3. Connaissances compilées

À utiliser lorsque la synthèse répétée compte.

sources brutes
  -> extraction LLM
  -> résumés générés
  -> pages de sujets
  -> base de connaissances révisée
  -> récupération

Bon pour :

• systèmes LLM Wiki
• collections de recherche
• bases de connaissances personnelles
• domaines stables

Faiblesse : la structure générée doit être auditée.

Modèle 4. Architecture de connaissances hybride

À utiliser lors de la construction de systèmes sérieux.

documents bruts
  -> couche de connaissances structurées
  -> index de recherche
  -> récupération et ré-ordonnancement
  -> réponse AI
  -> retour et maintenance

Bon pour :

• RAG en production
• systèmes de connaissances internes
• assistants AI
• systèmes de publication technique

Faiblesse : plus de pièces mobiles.

Questions d’évaluation

Pour évaluer la récupération, demandez :

• Le système a-t-il trouvé la bonne source ?
• A-t-il classé la bonne source haut ?
• A-t-il récupéré suffisamment de contexte ?
• A-t-il évité le contexte non pertinent ?
• La réponse a-t-elle cité la bonne source ?

Pour évaluer la représentation, demandez :

• Les connaissances sont-elles structurées clairement ?
• Y a-t-il une page canonique ?
• Les concepts sont-ils nommés de manière cohérente ?
• Les relations sont-elles explicites ?
• Le contenu est-il maintenu ?
• Les humains et les machines peuvent-ils tous les deux l’utiliser ?

N’évaluez pas un système de connaissances uniquement par la qualité de la réponse — une bonne réponse peut masquer une mauvaise structure.

La règle d’opinion

Si votre système échoue occasionnellement, améliorez la récupération. S’il échoue répétitivement dans le même domaine conceptuel, améliorez la représentation.

Une mauvaise récupération manque les bonnes informations. Une mauvaise représentation signifie que les bonnes informations n’existent pas vraiment dans une forme utilisable.

Conclusion

La récupération et la représentation résolvent des problèmes différents : la récupération donne l’accès, la représentation donne la structure. Le RAG est puissant car il rend les connaissances externes disponibles aux LLMs au moment de la requête, mais le RAG ne rend pas automatiquement les connaissances cohérentes, canoniques ou maintenues. C’est pourquoi les wikis, les systèmes PKM, les graphes de connaissances et les systèmes de style LLM Wiki restent importants.

L’avenir n’est pas la récupération contre la représentation, mais des systèmes de connaissances en couches :

• représentation pour la structure
• récupération pour l’accès
• mémoire pour la continuité
• raisonnement pour la synthèse

Si vous construisez un système de connaissances sérieux, ne commencez pas par la base de données vectorielle. Commencez par la forme des connaissances, puis décidez comment elles doivent être récupérées.

Sources et lectures complémentaires

• Google Cloud — Génération Augmentée par Récupération
• AWS — Qu’est-ce que la Génération Augmentée par Récupération ?
• IBM — Génération Augmentée par Récupération
• IBM — Gestion des Connaissances
• Atlan — LLM Wiki vs Base de Connaissances RAG
• Dev.to — RAG vs Mémoire d’Agent vs LLM Wiki
• Starmorph — Guide de Base de Connaissances LLM Wiki de Karpathy