Votre agent doit-il interroger des tables ou un graphe pour se souvenir ?
La mémoire d'agent est partout dans les architectures récentes : elle limite les hallucinations et ancre les réponses d'un LLM dans vos propres données. Reste un choix structurant, souvent tranché à l'intuition : stocker cette connaissance dans des tables relationnelles et l'interroger en SQL, ou la modéliser en graphe et l'interroger en SPARQL. Igor Suhorukov a publié une expérience chiffrée qui apporte des éléments concrets. Voici ce qu'on peut en retenir pour vos projets PHP/Symfony et PostgreSQL.
Le protocole : une même donnée, deux représentations
L'expérience part d'un seul corpus, un article technique sur les performances de PostgreSQL face à ClickHouse. Son contenu a été extrait dans 34 tables PostgreSQL, puis projeté sous forme de graphe grâce à un mapping R2RML (un standard qui décrit comment exposer des tables relationnelles comme des triplets RDF).
Les deux représentations ont ensuite été branchées sur un agent via MCP. Quinze questions portant sur l'article lui ont été posées dans trois configurations :
- uniquement via SQL ;
- uniquement via SPARQL ;
- avec un agent libre de choisir l'un ou l'autre.
L'ensemble a tourné sur trois LLM à poids ouverts, déployables sur votre propre infrastructure ou même un poste de travail. L'intérêt est double : les données et les questions ne transitent par aucun fournisseur ni agrégateur, et l'expérience reste reproductible chez vous.
Pourquoi la sémantique change la donne
L'auteur s'appuie sur une étude de Sequeda et al. : sur une base SQL d'entreprise, GPT-4 répondait juste dans 16 % des cas, contre 54 % sur un graphe de connaissances bâti au-dessus de la même base. Un détail compte beaucoup : le graphe disposait d'une ontologie avec des descriptions, alors que le schéma SQL ne fournissait que le DDL, c'est-à-dire des types et des noms de tables et de colonnes.
La leçon est utile même si vous restez en relationnel. Ce qui aide le modèle, ce n'est pas forcément le langage de requête, mais la quantité de sens que porte le schéma. Quelques pistes concrètes :
- documenter vos tables et colonnes (commentaires PostgreSQL, descriptions exposées à l'agent) ;
- nommer les relations de façon explicite plutôt que de laisser l'agent deviner une jointure ;
- exposer à l'agent un vocabulaire métier, pas seulement la structure physique.
Autrement dit, un schéma SQL bien décrit peut réduire une partie de l'écart que l'étude attribue au graphe.
Vecteurs, sécurité et choix du stockage
L'auteur a aussi comparé deux options pour la recherche sémantique : Lance et pgvector. Pour une équipe déjà sur PostgreSQL, pgvector a l'avantage de garder les embeddings à côté des données métier, avec les mêmes sauvegardes, les mêmes droits et la même exploitation. Les mesures détaillées sont dans l'article d'origine, à consulter avant de trancher pour votre volumétrie.
Un point mérite l'attention de toute équipe qui donne un accès SQL à un agent : au cours des tests, DeepSeek a imaginé une injection SQL pour répondre à une question. Un agent qui compose librement ses requêtes est un utilisateur imprévisible. Quelques garde-fous s'imposent :
- un rôle de base en lecture seule, limité aux tables utiles ;
- des timeouts et des limites de lignes retournées ;
- une journalisation des requêtes générées ;
- une vue ou une couche d'accès plutôt que le schéma brut.
Sur ce dernier point, un graphe en lecture seule exposé via SPARQL réduit naturellement la surface d'attaque, ce qui peut peser dans la décision.
Par où commencer
Pour tester chez vous sans tout reconstruire :
- Choisissez un jeu de questions représentatif de votre domaine (une quinzaine suffit pour une première mesure).
- Évaluez d'abord le SQL avec un schéma enrichi de descriptions, en pgvector pour la recherche sémantique.
- Ajoutez ensuite une couche graphe si les jointures complexes ou la sémantique métier font chuter la précision.
- Laissez enfin l'agent choisir entre les deux et comparez les résultats.
Conclusion
Cette expérience rappelle qu'on choisit mieux une architecture de mémoire en la mesurant qu'en suivant une mode. Avant de migrer vers un graphe, enrichissez votre schéma relationnel, sécurisez l'accès de l'agent et comparez sur vos propres questions. Le détail des mesures, des modèles testés et de la comparaison Lance contre pgvector se trouve dans l'article d'Igor Suhorukov.
