Knowledge Graph vs Vector Database pour la mémoire de l'agent

Les deux sont décrits comme des « mémoires IA ». Les deux apparaissent dans les diagrammes d’architecture. Mais ils résolvent des problèmes différents, et utiliser le mauvais est l’une des erreurs les plus coûteuses dans les systèmes agents de production.

Voici une comparaison honnête : comment chacun fonctionne, où chacun excelle et pourquoi la plupart des équipes doivent comprendre la différence avant de concevoir quoi que ce soit.

Comment fonctionnent les bases de données vectorielles

Une base de données vectorielle convertit le contenu en représentations numériques de grande dimension (embeddings) et les stocke indexés par similarité. Lorsque vous interrogez une base de données vectorielle, vous demandez : « Quel contenu stocké est sémantiquement similaire à cette entrée ? »

La mécanique :

1. Le texte (ou autre contenu) passe via un modèle d'intégration (OpenAI, Cohere, etc.)
2. Le résultat est un vecteur — une liste de 768 ou 1 536 nombres à virgule flottante représentant la signification
3. Ces vecteurs sont stockés et indexés (généralement avec une indexation HNSW ou FIV)
4. Au moment de la requête, votre requête est également intégrée et la recherche du voisin le plus proche trouve les vecteurs stockés les plus similaires.

Dans quels domaines les bases de données vectorielles sont-elles efficaces :

• Recherche sémantique ("trouver un contenu similaire à celui-ci")
• Génération augmentée par récupération (RAG) — extraction du contexte pertinent avant un appel LLM
• Correspondance floue sur de grands corpus non structurés
• Déduplication et clustering de similarité

La caractéristique critique : Les bases de données vectorielles sont des magasins sans état. Ils détiennent le contenu et permettent la récupération. Ils ne raisonnent pas sur les relations entre les éléments. Ils ne sont pas mis à jour en fonction des résultats. Chaque requête est indépendante.

Comment fonctionnent les graphiques de connaissances

Un graphe de connaissances stocke les entités et les relations, et non le contenu brut. Un KG représente le monde comme un réseau structuré de nœuds typés et d'arêtes étiquetées.

Exemple : une entité peut être Company: Acme Corp, avec des relations telles que employs → Person: Jane Smith, operates_in → Geography: Germany, similar_to → Company: TechStart GmbH. Ce ne sont pas seulement des cooccurrences : ce sont des relations explicites, typées et traversables.

La mécanique :

1. Les données sont structurées en triplets sujet-prédicat-objet (ou équivalent sous forme de graphe de propriétés)
2. Les relations sont des citoyens de premier ordre : elles ont des types, des propriétés et peuvent transporter des métadonnées
3. Les requêtes parcourent le graphe (Cypher, SPARQL, Gremlin) plutôt que de rechercher des similitudes
4. Les nouveaux apprentissages ajoutent des nœuds et des arêtes ; les relations sont mises à jour en fonction de ce que le système observe

Dans quels domaines les graphiques de connaissances sont-ils efficaces :

• Raisonnement multi-sauts (« que savent les collègues de Jane de ce marché ? »)
• Découverte de relations et parcours de chemin
• Stocker des connaissances structurées du domaine qui évoluent au fil du temps
• Transport de mémoire qui persiste et se met à jour lors des exécutions d'agents
• Encodage des corrections humaines et des commentaires sous forme de faits structurés

La caractéristique critique : Les graphiques de connaissances sont dynamiques et relationnels. Ils modélisent la cause, la connexion et la structure, pas seulement la similitude.

Comparaison face à face

	Vector Database	Knowledge Graph
Abstraction de base	Similitude	Relation
Modèle de requête	Recherche du voisin le plus proche	Parcours du graphique
État	Apatride (magasin ; n'apprend pas)	Avec état (mises à jour avec de nouvelles observations)
Idéal pour	Récupérer du contenu pertinent	Raisonnement sur des faits structurés
Gère l'ambiguïté	Oui (flou par conception)	Structuré (relations explicites)
Apprentissage croisé	Non	Oui
Types de relations	Implicite (intégrations)	Explicite (bords étiquetés)
Modèle de mise à jour	Ajouter/supprimer des vecteurs	Ajouter/mettre à jour/supprimer des nœuds et des bords
Raisonnement multi-sauts	Faible	Fort
Corrections humaines	Difficile à intégrer	Fonctionnement de première classe
Outils typiques	Pomme de pin, Weaviate, Qdrant, Chroma	Neo4j, Memgraph, Amazon Neptune, AgentLed KG

Quand les bases de données vectorielles sont le bon choix

Si votre cas d'utilisation principal est la récupération (trouver du contenu pertinent à partir d'un grand corpus non structuré), une base de données vectorielle est correcte.

Les pipelines RAG sont l'exemple canonique. Vous disposez d’une base de connaissances de documents, de politiques ou de conversations passées. Avant chaque appel LLM, vous récupérez les fragments les plus pertinents. Le LLM produit une meilleure réponse car il possède un contexte pertinent. Le travail de la base de données vectorielle est la récupération, pas le raisonnement.

Utilisez une base de données vectorielle lorsque :

• Vous avez besoin d'une recherche sémantique sur de grands ensembles de documents
• Vous construisez une couche RAG pour un LLM
• Votre contenu est principalement du texte non structuré
• Vous n'avez pas besoin que le système se souvienne d'une session à l'autre
• La similarité est le principal signal de récupération

Quand les Knowledge Graphs sont le bon choix

Si vos agents ont besoin de transmettre des connaissances structurées sur plusieurs exécutions (en se souvenant de ce qui a fonctionné, de ce qui a échoué, des relations importantes), une base de données vectorielle échouera. Il vous faut un graphique.

Le mode d'échec de l'utilisation d'une base de données vectorielle pour la mémoire de l'agent est prévisible : l'agent s'exécute 100 fois et l'exécution 101 démarre avec les mêmes connaissances que l'exécution 1. Il peut récupérer des interactions passées similaires, mais il ne peut pas raisonner à leur sujet. Il peut trouver « quelque chose comme ceci s'est déjà produit » mais ne peut pas appliquer « ce que nous avons appris lorsque cela s'est produit auparavant ».

Utilisez un graphique de connaissances lorsque :

• Vos agents doivent s'améliorer au fil du temps sans reconfiguration humaine
• Vous stockez des connaissances structurées du domaine (entités, entreprises, personnes, processus)
• Vous devez raisonner sur les relations, pas seulement récupérer un contenu similaire
• Les retours humains et les corrections doivent mettre à jour le comportement du système
• Questions de traversée multi-sauts ("trouver des pistes connectées aux investisseurs de notre portefeuille")

Comment le Knowledge Graph de AgentLed stocke les apprentissages du flux de travail

Le KG de AgentLed est spécifiquement conçu autour du cas d'utilisation agentique : non pas la récupération de documents, mais la mémoire opérationnelle.

Lorsqu'un agent termine l'exécution d'un workflow, plusieurs types d'apprentissages peuvent être réécrits dans le KG :

Faits sur les performances : quelle approche (modèle, invite, source de données) a produit la meilleure qualité de sortie pour un type de tâche donné. Stocké en tant que propriétés sur les nœuds d'exécution de flux de travail.

Corrections humaines : lorsqu'un réviseur modifie le résultat d'un agent ou fournit des commentaires, cette correction est écrite sous forme de fait structuré. "Pour l'appariement des investisseurs, le chevauchement des portefeuilles est un signal plus fort que la concentration sectorielle déclarée." Cela devient une connaissance traversable, et non une entrée de journal enfouie.

Relations entre entités : à mesure que les agents interagissent avec les données (entreprises, personnes, produits, processus), ils construisent un graphique de relations. Une entreprise rencontrée pour la première fois en tant que client potentiel peut ensuite être liée à un concurrent, à un investisseur commun et à un signal d'embauche. Ces liens persistent.

Étalonnage de confiance : le KG suit non seulement ce que l'agent a fait, mais également son degré de confiance et si cette confiance était justifiée. Au fil du temps, cela calibre l'incertitude de l'agent : il apprend quand signaler un examen humain plutôt que de procéder de manière autonome.

Nœuds de modèle : les structures récurrentes sont représentées explicitement. "Intro chaleureuse de LinkedIn + connexion partagée avec l'investisseur = taux de réponse élevé pour cet ICP" devient un nœud de modèle nommé que les étapes de décision en aval peuvent interroger directement.

Résultat : un agent exécutant l'itération de flux de travail 50 est sensiblement différent de l'itération 5 en cours d'exécution. Il n'est pas recyclé : le modèle sous-jacent est le même. Mais il fonctionne dans un contexte structuré plus riche sur ce qui a fonctionné et ce qui n'a pas fonctionné.

L'idée fausse la plus répandue : vous n'êtes pas obligé de choisir

Les systèmes agents sophistiqués utilisent souvent les deux, chacun là où il convient.

Une architecture typique :

1. Couche de base de données vectorielle : récupération RAG avant les appels LLM. Extrayez les documents, politiques ou contenus antérieurs pertinents pour ancrer le contexte du modèle.
2. Couche KG : Mémoire opérationnelle. Stockez les apprentissages structurés, les relations entre entités, les corrections humaines et les modèles de performances.

La base de données vectorielle répond : « qu’est-ce qui est pertinent ? » Le KG répond « que savons-nous ? » Ils sont complémentaires et non concurrents.

Là où les équipes se trompent, c'est en traitant une base de données vectorielle comme un substitut à la mémoire structurée ou en créant des schémas graphiques élaborés alors qu'elles ont simplement besoin d'une recherche sémantique. Faites correspondre l'outil au problème.

Conseils pratiques

Si vous créez un pipeline RAG pur pour les questions et réponses sur les documents : utilisez une base de données vectorielle.

Si vous créez des agents autonomes qui doivent s'améliorer au fil du temps, mémorisez les relations spécifiques au domaine et intégrez les commentaires humains : utilisez un graphique de connaissances.

Si vous créez des workflows agents à grande échelle qui nécessitent à la fois de la récupération et de la mémoire : utilisez les deux, à différentes couches de la pile.

La décision d’architecture est importante dès le début. Une base de données vectorielle à laquelle on demande d'agir comme mémoire développera des solutions de contournement (filtres de métadonnées, réindexation manuelle, hacks d'intégration) qui aggravent la dette technique. Un KG choisi pour la recherche de similarité semblera excessif et ajoutera une complexité inutile.

Obtenez d'abord le bon calque. Les choix d'outillage au sein de chaque couche sont secondaires.