Semantica : mémoire sémantique des agents IA

Le site officiel de Semantica présente 13 modules prêts pour la production, répartis entre graphes de contexte, raisonnement, provenance et algorithmes de graphe (présentation officielle des capacités). Cela suffit à poser le bon diagnostic : Semantica est une infrastructure de contexte et de traçabilité pour agents IA, pas un simple historique de conversations. Si votre priorité est de retrouver rapidement quelques passages dans un chatbot, restez sur un stockage simple. Si votre agent doit relier des faits, gérer leurs versions, expliquer ses décisions et partager une mémoire fiable entre plusieurs processus, une approche de type Semantica mérite une évaluation.

Cette analyse s’adresse aux ingénieurs qui conçoivent une mémoire persistante pour un agent, aux architectes d’entreprise qui doivent retrouver l’origine d’une décision et aux responsables techniques qui comparent recherche vectorielle, RAG classique et graphe de contexte.

Dernière mise à jour : 13 août 2026. Les capacités et le positionnement ont été vérifiés dans la documentation officielle, le dépôt du projet, les notes de version et les pages de référence disponibles à cette date.

Pourquoi l’historique de conversation devient-il insuffisant ?

Un historique de chat conserve généralement une suite de messages. Cette structure est pratique pour afficher une session, mais elle représente mal les objets durables dont un agent a besoin : une personne, un contrat, une préférence, une règle métier, un incident ou une décision passée.

Prenons un agent chargé de préparer une recommandation pour un client. Une conversation peut contenir successivement :

• une adresse ancienne puis une adresse corrigée ;
• une contrainte budgétaire valable uniquement pendant une période ;
• une préférence exprimée par un utilisateur mais non confirmée ;
• une décision prise après validation humaine ;
• une information provenant d’un document dont la version a ensuite été retirée.

Dans une liste de messages, ces éléments restent voisins sans devenir nécessairement des faits structurés. L’agent doit alors reconstruire les entités et les relations à chaque nouvelle requête. Cette reconstruction peut produire quatre défauts concrets :

1. Le contexte est dépendant du texte récupéré. Une information importante peut être absente du segment transmis au modèle.
2. Les changements sont difficiles à distinguer. Une nouvelle valeur peut être interprétée comme un doublon ou comme une contradiction.
3. Les liens entre faits sont implicites. Le système sait qu’un document mentionne une décision, mais pas toujours quelle règle, quelle personne ou quel événement y est relié.
4. La mémoire devient coûteuse à maintenir. Plus les conversations s’accumulent, plus il faut résumer, dédupliquer et filtrer avant chaque appel au modèle.

Semantica tente de déplacer cette responsabilité vers un Context Graph, c’est-à-dire un graphe persistant et interrogeable d’entités, de relations et de décisions. La documentation décrit notamment des fenêtres de validité temporelle sur les nœuds et les arêtes, ainsi que des requêtes permettant d’examiner l’état historique du graphe (référence du module Context Graph).

Le gain ne vient donc pas seulement de la mémoire longue. Il vient de la possibilité de demander : « quelle relation était valable à cette date ? », « quelle source a introduit ce fait ? » ou « quelle décision dépendait de cette information ? ».

Point de vigilance : un graphe ne transforme pas automatiquement une extraction incertaine en vérité. Si l’ingestion, la résolution d’entités ou les règles de mise à jour sont mal conçues, vous obtiendrez une mémoire structurée mais fausse.

Semantica et les bases vectorielles : deux rôles différents

La recherche vectorielle répond à une question de proximité : quels documents ou fragments ressemblent le plus à la requête ? Elle est très utile pour retrouver une explication, un passage de manuel ou un exemple de code. Elle ne suffit pas toujours à déterminer quelle affirmation est actuellement valide.

Une Semantic Memory destinée à un agent doit plutôt distinguer au moins plusieurs types d’informations :

• les faits durables sur des entités ;
• les événements qui se sont produits à un moment donné ;
• les relations entre personnes, ressources, systèmes ou documents ;
• les décisions prises et leur résultat ;
• les règles utilisées pour produire une conclusion ;
• les sources et les conditions de validité ;
• les versions remplacées, annulées ou contestées.

Le tableau suivant résume le choix technique.

Besoin du système	Stockage conversationnel	Recherche vectorielle / RAG	Graphe de contexte de type Semantica
Retrouver un passage similaire	Correct	Très adapté	Possible, mais rarement nécessaire seul
Relier des entités et relations	Faible	Partiel	Central
Gérer une information ancienne et une nouvelle	Résumé manuel	Dépend des métadonnées	Modèle temporel et versionnement plus explicites
Identifier la source d’un fait	Variable	Possible avec citations	Fonction structurante de la provenance
Expliquer une décision	Faible	Limitée au contexte récupéré	Décisions, règles et chaînes causales enregistrables
Partager un contexte entre plusieurs agents	Risque de doublons	Possible avec une base commune	Prévu, mais soumis aux règles d’accès et d’écriture
Complexité de déploiement	Faible	Moyenne	Élevée

La documentation officielle indique que Semantica peut fonctionner avec des moteurs vectoriels et des stockages de graphes, ce qui confirme une logique de complémentarité plutôt que de remplacement systématique (liste des intégrations et formats). Vous pouvez donc conserver la recherche vectorielle pour le rappel sémantique, puis utiliser le graphe pour vérifier les relations, les dates, les sources et les dépendances.

La différence est importante pour les équipes qui demandent : Semantica peut-il s’intégrer à un système RAG existant ? Techniquement, le positionnement annoncé est précisément celui d’une couche ajoutée à une architecture existante, sans imposer un changement de fournisseur de modèle ou de cadre d’agent (documentation de démarrage). En pratique, l’intégration exige toutefois de décider quelles informations sont envoyées dans le graphe, quelles données restent dans l’index vectoriel et quelle couche est autorisée à écrire.

Quand la similarité vectorielle masque-t-elle un conflit ?

Deux passages peuvent être très proches sémantiquement tout en décrivant des états différents. Une politique de remboursement et sa version modifiée peuvent partager les mêmes termes. Un dossier audio ou vidéo peut contenir plusieurs exports presque identiques, dont un seul a été validé. Dans ces cas, le meilleur score de similarité ne constitue pas une preuve de validité.

Pour éviter ce piège, votre modèle de mémoire doit conserver des métadonnées opérationnelles :

• la source, avec le document, l’événement d’ingestion ou l’auteur ;
• la date d’enregistrement, distincte de la date à laquelle le fait est réputé valable ;
• la période de validité, lorsque le fait peut changer ;
• le statut, par exemple actif, remplacé, révoqué ou en conflit ;
• le niveau de confiance, si l’information provient d’une extraction automatique ;
• la relation avec les faits voisins, afin de repérer les incohérences.

Semantica documente une couche de provenance reliant les faits à leur source et à leur événement d’ingestion. Le projet mentionne aussi l’utilisation de PROV-O, le modèle de provenance du W3C, mais cette compatibilité déclarée ne doit pas être transformée en certification réglementaire automatique (documentation officielle sur la provenance, spécification W3C PROV-O).

Pour un agent qui analyse des dossiers financiers, médicaux, industriels ou juridiques, cette distinction change le protocole de réponse. Au lieu de produire directement une conclusion, l’agent peut :

1. récupérer les faits pertinents ;
2. vérifier leur période de validité ;
3. comparer les sources concurrentes ;
4. appliquer une règle explicite ;
5. enregistrer la décision et son contexte ;
6. signaler une incertitude non résolue.

Cette séquence est plus lente et plus coûteuse qu’une simple recherche dans des passages. Elle devient pertinente lorsque l’erreur ne se limite pas à une réponse imprécise, mais entraîne une action difficile à annuler.

Le Context Graph convient aux dépendances de la mémoire longue

La mémoire longue ne signifie pas seulement conserver davantage de contenu. Elle consiste à préserver les relations qui permettent de réutiliser ce contenu correctement.

Dans un agent chargé d’assister une équipe de production vidéo, par exemple, il peut être utile de relier :

• un projet à ses versions de scénario ;
• une scène à une piste audio ;
• une piste à une licence ;
• une licence à une date d’expiration ;
• une décision de montage à un retour client ;
• un export final aux ressources effectivement utilisées.

Une base vectorielle peut retrouver un commentaire similaire à « remplacer la musique d’introduction ». Elle ne sait pas nécessairement que la piste proposée avait déjà été rejetée pour des raisons de licence. Le graphe, lui, peut représenter la relation entre la ressource, la décision et l’événement de rejet, à condition que ces relations aient été correctement extraites et enregistrées.

C’est la raison pour laquelle un Context Graph est adapté aux environnements où les questions portent sur les dépendances :

• « quels projets utilisent cette ressource ? » ;
• « quelles décisions ont été prises à partir de cette version ? » ;
• « quelle information était connue avant la validation ? » ;
• « quelles conséquences découlent de la révocation de ce fait ? ».

La documentation du projet décrit également des mécanismes de recherche de précédents, d’analyse d’impact et de chaînes causales pour les décisions (référence du serveur MCP et des décisions). Ces fonctions peuvent aider un agent à réutiliser une décision passée, mais elles ne garantissent pas qu’une décision future sera correcte. Le système doit encore définir les critères de comparaison et la politique d’escalade vers un humain.

Plusieurs agents peuvent-ils partager une mémoire fiable ?

Le partage d’une mémoire commune réduit les répétitions, mais il ajoute un problème de gouvernance. Un agent de support, un agent d’analyse et un agent d’exécution ne devraient pas nécessairement avoir les mêmes droits.

Vous devez séparer au minimum :

• les données qu’un agent peut lire ;
• les données qu’il peut proposer ;
• les données qu’il peut valider ;
• les données qu’il peut révoquer ;
• les décisions qui nécessitent une approbation humaine ;
• les journaux qui ne peuvent plus être modifiés.

Sans cette séparation, un agent spécialisé peut écrire une hypothèse dans la mémoire globale, puis un autre agent la traiter comme un fait confirmé. Le problème n’est pas propre à Semantica : il apparaît dès qu’une mémoire devient partagée. Le graphe rend simplement la relation plus visible, ce qui facilite l’audit mais expose aussi les erreurs de modélisation.

Voici le choix le plus raisonnable selon votre situation :

• Un seul agent, faible risque, sessions courtes : historique compact ou stockage documentaire.
• Un agent avec connaissances durables : RAG enrichi de métadonnées, avec processus clair de mise à jour.
• Plusieurs agents partageant des entités et décisions : couche de contexte commune, permissions et schéma versionné.
• Décisions sensibles ou révisables : graphe avec provenance, statut, règles et journal de décision.

Pour préparer l’environnement d’exécution, vous pouvez comparer les exigences d’un environnement temporaire avec celles de votre infrastructure permanente. Si vous devez tester plusieurs agents sur une machine dédiée avant de modifier votre environnement principal, un environnement Mac distant peut servir de support temporaire. Les règles d’accès, la sauvegarde et l’isolement des données doivent être définis avant de déployer plusieurs agents sur une même machine. Vous pouvez également consulter les informations générales sur l’infrastructure destinée aux charges de développement IA afin de distinguer les besoins de mémoire applicative des besoins de calcul. Pour comparer cette architecture avec une autre solution d’exécution, examinez aussi les critères de persistance, de supervision et d’accès distant, plutôt que la seule puissance brute. L’objectif n’est pas de louer une machine avant d’avoir défini le modèle de mémoire : un mauvais schéma de données restera mauvais, même sur une infrastructure plus puissante.

L’enregistrement d’une décision explicable

Une décision exploitable ne devrait pas être stockée comme une phrase finale isolée. Conservez plutôt une structure qui relie :

1. les entrées utilisées ;
2. la version du graphe au moment du calcul ;
3. les règles déclenchées ;
4. les faits écartés et la raison de leur exclusion ;
5. la sortie produite ;
6. l’action exécutée ou proposée ;
7. la validation humaine éventuelle ;
8. les conséquences observées après l’action.

Le site officiel présente record_decision() et des fonctions d’analyse de l’impact ou de l’influence d’une décision. Le serveur documenté expose également des outils pour interroger le graphe et exécuter des règles conditionnelles (référence du serveur MCP). Ces éléments positionnent Semantica comme une infrastructure de décision traçable, non comme un moteur qui rend automatiquement vos réponses conformes à une loi ou à une norme.

Pour évaluer la valeur réelle du système, demandez à votre équipe de répondre à une question précise : pouvez-vous expliquer pourquoi l’agent a produit cette sortie, avec les sources et l’état des données disponibles à ce moment-là ? Si la réponse est non, la provenance peut justifier l’investissement. Si vous avez seulement besoin de citer les trois passages les plus proches d’une question, l’architecture complète risque d’être disproportionnée.

Première étape : cartographier les faits que l’agent doit retenir

Avant l’installation, listez les objets récurrents : clients, fichiers, produits, tickets, contrats, scènes, machines ou règles. Pour chaque objet, indiquez les relations qui doivent être interrogées.

Ne commencez pas par « stocker tout le chat ». Commencez par une question de décision : quelle information l’agent devra-t-il réutiliser dans trente jours, et quel lien permettra de vérifier qu’elle est encore valable ?

Deuxième étape : séparer les types de mémoire

Définissez ce qui relève de la mémoire sémantique, de l’événementiel et du procédural :

• sémantique : faits et caractéristiques relativement stables ;
• événementielle : actions, incidents, validations et changements ;
• procédurale : règles, méthodes et séquences d’exécution.

Cette séparation évite de traiter une préférence temporaire comme une propriété permanente ou un résultat d’exécution comme une règle générale.

Troisième étape : définir les règles d’écriture

Précisez qui peut créer un fait, le modifier, le remplacer ou le révoquer. Ajoutez une étape de validation pour les informations extraites avec une confiance faible.

Une extraction automatique devrait pouvoir rester « à confirmer » plutôt que d’entrer directement dans le contexte de référence. Cette précaution est particulièrement importante lorsque plusieurs agents écrivent dans le même graphe.

Quatrième étape : conserver la provenance dès l’ingestion

Enregistrez la source, la date, la version du document et l’événement qui a produit l’extraction. Si vous attendez avant d’ajouter ces informations, vous devrez ensuite reconstruire l’historique à partir de journaux incomplets.

Le projet documente des exports vers plusieurs formats de graphes et de données structurées, ainsi qu’une logique de provenance exploitable lors des requêtes (formats et flux d’ingestion). Testez toutefois l’export avec vos propres données : la présence d’un format annoncé ne signifie pas que votre schéma métier sera immédiatement portable sans adaptation.

Cinquième étape : tester les conflits et les retours arrière

Préparez au moins cinq scénarios avant la mise en production :

• une information corrigée deux fois ;
• deux sources contradictoires ;
• une décision annulée ;
• un document supprimé ou remplacé ;
• une question portant sur l’état historique du système.

Mesurez ensuite si l’agent retrouve la bonne version, cite la bonne source et signale l’incertitude. Ne mesurez pas uniquement le taux de récupération : une réponse bien retrouvée mais fondée sur un fait révoqué reste une erreur.

Sixième étape : dimensionner l’exploitation et les droits

Un service de mémoire persistante implique des sauvegardes, une supervision, une stratégie de restauration, une gestion des secrets et une politique de rétention. Les graphes peuvent également devenir plus difficiles à maintenir lorsque les ontologies évoluent ou que les entités sont mal fusionnées.

Si vous déployez un environnement de test pour plusieurs agents, prévoyez un accès distant stable et des règles d’isolement claires. Une machine temporaire de validation peut être utile pour comparer plusieurs scénarios avant de modifier votre infrastructure permanente.

Expérience de conception : faites d’abord échouer le système sur les contradictions, les suppressions et les changements de date. Une démonstration avec des faits parfaitement cohérents ne révèle presque aucun coût de gouvernance.

Quand ne faut-il pas introduire Semantica ?

Semantica n’est pas le choix automatique pour tout agent doté d’une mémoire. Vous pouvez rester sur une architecture plus simple si :

• le robot répond à des questions ponctuelles ;
• les conversations ne dépassent pas une session ;
• aucune décision ne doit être expliquée après coup ;
• les données sont peu nombreuses et rarement modifiées ;
• un opérateur vérifie systématiquement chaque sortie ;
• le prototype sert uniquement à valider une interface.

Dans ces situations, un index documentaire, un historique résumé et quelques métadonnées peuvent offrir un meilleur rapport entre coût et résultat.

En revanche, une couche de graphe devient défendable lorsque vous avez plusieurs de ces signaux :

• les mêmes entités sont utilisées par plusieurs agents ;
• les faits changent régulièrement ;
• les sources sont nombreuses ou hiérarchisées ;
• les décisions doivent être rejouées ;
• les erreurs ont un impact financier, opérationnel ou contractuel ;
• vous devez distinguer une hypothèse, une information confirmée et une information révoquée.

Votre décision en quatre branches

• Si vous cherchez principalement des passages similaires, choisissez d’abord un RAG classique avec métadonnées.
• Si vous devez relier des entités, des événements et des versions, évaluez un Context Graph.
• Si vous devez expliquer une décision, ajoutez provenance, règles et journal de décision avant d’augmenter la taille du modèle.
• Si vous avez besoin d’un partage entre agents, définissez les permissions et le processus de validation avant d’ouvrir l’écriture globale.

Le point important est de ne pas confondre une mémoire plus riche avec une mémoire automatiquement fiable. Semantica peut structurer les relations, conserver des traces et exposer des chemins de raisonnement ; la qualité dépend toujours de votre schéma, de vos règles d’ingestion et de vos contrôles.

Si votre solution actuelle repose uniquement sur des résumés de conversations, elle perd les relations entre entités et rend les corrections difficiles à vérifier. Si elle repose uniquement sur la recherche vectorielle, elle peut rapprocher des faits incompatibles sans savoir lequel doit prévaloir. Si elle utilise une mémoire partagée sans droits précis, un agent peut propager une hypothèse aux autres. Dans ces cas, une architecture durable mérite un environnement de test isolé plutôt qu’un déploiement précipité sur votre poste principal. Kvmjet peut être pertinent lorsque vous devez louer temporairement une machine Mac pour valider un agent, tester un déploiement autogéré ou comparer plusieurs scénarios sans acheter immédiatement du matériel. Pour commencer, vérifiez d’abord si votre problème est un problème de recherche, de conflit ou d’audit ; ensuite seulement, choisissez l’infrastructure adaptée.