Hindsight face aux bases de données vectorielles : comment concevoir la mémoire à long terme, la recherche et la mise à jour des connaissances d’un agent IA ?

Votre agent retrouve des passages pertinents, mais ne réutilise pas correctement ce qu’il a appris lors d’une session précédente ?

La réponse rapide : ne choisissez pas entre Hindsight et une base vectorielle comme s’il s’agissait de solutions équivalentes. La base vectorielle peut assurer une recherche par similarité ; une couche de mémoire organise aussi ce qui est retenu, rappelé, actualisé et gouverné. Pour des documents, une recherche vectorielle peut suffire ; pour des expériences d’agent qui évoluent, évaluez une architecture de mémoire et validez-la sur vos propres données.

Cet article s’adresse aux développeurs dont la recherche fonctionne, mais dont l’agent exploite mal les échanges précédents ; aux architectes qui conçoivent une mémoire persistante ; et aux équipes de production qui doivent gérer confidentialité, séparation des utilisateurs et traçabilité. Si votre besoin se limite à trouver des passages dans un corpus statique, concentrez-vous d’abord sur la recherche documentaire plutôt que sur une mémoire d’agent complète.

Une mémoire d’agent n’est pas une base de recherche

Une base de données vectorielle compare des représentations numériques pour aider à retrouver des éléments proches d’une requête. Elle peut être utile pour rechercher dans des documents, des descriptions de produits ou des notes. Mais « trouver un contenu similaire » ne répond pas à toutes les questions qu’un agent doit résoudre : faut-il conserver cette information ? À quel utilisateur appartient-elle ? Est-elle encore valable ? Dans quelle situation doit-elle être rappelée ?

La mémoire à long terme d’un agent désigne donc une chaîne de responsabilités, pas seulement un index. Elle comprend la sélection et l’écriture des informations, leur organisation, la récupération au moment opportun, leur usage dans le contexte de l’agent et leur maintenance. Selon le système, ces responsabilités sont réparties entre le code de l’application, une base de données, des tâches de traitement et une couche spécialisée.

La documentation officielle de Hindsight distingue notamment des interfaces consacrées à la conservation des informations et à leur rappel. Elle décrit également des unités de mémoire et des opérations de maintenance dans l’API des mémoires, ainsi que les paramètres de la recherche dans l’API de rappel. Ce sont des indications sur la conception et les interfaces du projet, pas la preuve qu’il sera plus précis ou plus rapide que votre système actuel.

À l’inverse, une implémentation de base vectorielle ne représente pas à elle seule toutes les fonctions d’un agent. Par exemple, la documentation de pgvector sur la recherche, les filtres et les index concerne une implémentation particulière. Ne généralisez pas ses possibilités à toutes les bases vectorielles, et ne confondez pas les fonctions de cette brique avec une politique complète de mémoire.

Ce que votre agent doit se rappeler change le choix

Pour un corpus de procédures, la mémoire recherchée est souvent un passage accompagné de sa source et de métadonnées utiles. L’utilisateur pose une question ; l’application cherche des extraits et les fournit au modèle. Si les documents sont maintenus séparément et que l’agent n’a pas à apprendre des interactions antérieures, une base de recherche peut être une architecture proportionnée.

Le besoin se transforme lorsque l’agent doit réutiliser des expériences. Il peut s’agir d’une préférence indiquée par un utilisateur, d’une contrainte découverte pendant une tâche, d’un résumé de projet ou d’un fait qui devra être corrigé plus tard. Stocker chaque échange comme un fragment équivalent à un paragraphe peut créer des doublons, mélanger des informations temporaires avec des faits durables et compliquer le rappel d’un élément utile hors de son contexte d’origine.

Les interfaces de Hindsight documentent des opérations orientées vers la conservation de souvenirs, ainsi que la consultation de documents par des interfaces distinctes. Vous pouvez examiner l’interface de conservation et l’API des documents pour comprendre les ressources manipulées. La distinction entre « mémoire structurée » et « fragment vectorisé » est toutefois une lecture architecturale à valider sur votre cas : elle ne garantit pas que chaque expérience d’agent sera correctement résumée, classée ou rappelée.

Cas concret — assistant de montage et de création. Imaginez un agent qui aide une équipe à préparer des contenus audio et vidéo. La recherche documentaire peut retrouver la procédure de livraison ou une fiche de format. La mémoire de projet, elle, peut devoir rappeler une préférence éditoriale, une contrainte de validation ou une décision prise lors d’une session précédente. Si ces deux catégories sont mélangées sans provenance ni statut, l’agent risque de présenter une ancienne préférence comme une exigence actuelle. La solution ne consiste pas forcément à ajouter un nouveau produit : elle consiste d’abord à définir des types d’information et à vérifier comment ils sont injectés dans le contexte.

L’étude publiée avec le projet apporte des éléments sur son approche, mais ses résultats restent liés à ses protocoles et à ses jeux d’évaluation. Consultez l’article de recherche sur Hindsight pour examiner ces conditions. Ne transformez pas un résultat de recherche en promesse de performance pour votre application : votre corpus, vos règles d’écriture, vos utilisateurs et vos questions peuvent être différents.

La qualité du rappel se mesure sur vos questions

Une recherche sémantique peut être adéquate pour retrouver un texte qui parle d’un sujet proche. Un agent, lui, peut avoir besoin d’une information précise qui n’est pas formulée comme la question actuelle : une décision prise auparavant, une contrainte attachée à un projet ou un souvenir dont la validité dépend de son auteur et de son ancienneté.

Les filtres peuvent réduire les résultats hors sujet, par exemple en limitant une recherche à un projet ou à un utilisateur. Mais leur disponibilité, leur syntaxe et leur comportement dépendent de la solution mise en œuvre. La documentation de pgvector est utile pour vérifier les options exposées par cette extension ; elle ne permet pas de conclure que toutes les bases offrent les mêmes filtres, index ou compromis.

Pour comparer deux architectures, constituez un jeu de validation tiré de vos usages réels. Il doit inclure les questions auxquelles l’agent doit répondre, les souvenirs ou documents attendus, les éléments qui ne doivent pas être retournés et les cas où aucune réponse ne doit être produite. Exécutez les mêmes requêtes sur les mêmes données, avec des règles d’écriture comparables, puis consignez les résultats.

Évaluez séparément plusieurs dimensions : l’élément attendu est-il retrouvé ? Le résultat appartient-il au bon utilisateur et au bon projet ? La source permet-elle de vérifier le contenu ? Un souvenir obsolète apparaît-il encore ? Enfin, l’agent utilise-t-il le résultat correctement, ou l’introduit-il hors contexte ? Cette dernière vérification évite de réduire la qualité de la mémoire au classement des passages.

À retenir : sans test reproductible avec les mêmes questions, les mêmes données et les mêmes règles d’accès, une affirmation comme « le rappel est meilleur » reste une hypothèse. Notez aussi la version des interfaces et des paramètres utilisés pour que l’équipe puisse refaire la comparaison après une modification.

Questions fréquentes sur le choix d’une mémoire

Une base vectorielle peut-elle constituer seule la mémoire à long terme d’un agent ?

Oui, si votre définition de la mémoire se limite à indexer et retrouver des éléments, et si votre application prend en charge les autres responsabilités. Vous devez notamment décider quoi écrire, comment associer les données à un utilisateur, quand les actualiser et comment traiter les demandes d’effacement. La base peut assurer une partie importante du système, mais elle ne définit pas automatiquement ces règles.

Quelle est la différence entre Hindsight et une base de données vectorielle ?

La comparaison porte sur deux niveaux d’architecture. Une base vectorielle fournit une capacité de recherche par similarité, avec des fonctionnalités propres à son implémentation. Hindsight expose des interfaces conçues autour de la conservation et du rappel d’informations utiles à un agent. Pour choisir, comparez les responsabilités effectivement couvertes, les données prises en charge et les opérations de maintenance, pas seulement la présence d’une recherche sémantique.

Hindsight doit-il être associé à une base de données vectorielle ?

Pas par principe. Vérifiez d’abord si la solution que vous évaluez couvre les besoins de recherche documentaire et de mémoire de votre application. Une combinaison peut être pertinente lorsque les rôles sont clairement séparés, par exemple un index documentaire d’un côté et les souvenirs de l’agent de l’autre. Elle ajoute toutefois des copies, de la synchronisation et des possibilités de conflit qu’il faut tester.

Comment actualiser ou supprimer les souvenirs d’un agent ?

Définissez un processus avant la mise en production : identifiez le souvenir, vérifiez son propriétaire, corrigez ou retirez l’information dans la source de vérité, puis contrôlez les index et autres copies. Prévoyez aussi le cas d’une information qui devient obsolète sans demande explicite. Les obligations applicables doivent guider vos règles de conservation et d’effacement, et pas seulement les capacités de recherche.

Les mises à jour et les suppressions sont des décisions de gouvernance

Ajouter un souvenir ne signifie pas que la connaissance devient exacte. Si l’utilisateur corrige une préférence, si une procédure change ou si une donnée perd sa validité, vous devez savoir quelle version fait autorité. Sans cette règle, votre système peut conserver simultanément l’information ancienne et sa correction, puis rappeler l’une ou l’autre selon la requête.

Distinguez au minimum ces opérations dans votre architecture :

• Ajout : qui peut créer un souvenir, à partir de quelles sources, et avec quelle provenance ?
• Correction : une nouvelle valeur remplace-t-elle l’ancienne, ou les deux versions restent-elles disponibles avec un statut clair ?
• Expiration : quels éléments ne doivent plus être proposés après un événement ou une échéance définie par votre métier ?
• Suppression : quelles copies, index, journaux et caches doivent être vérifiés après une demande d’effacement ?
• Isolement : comment empêcher une recherche de mélanger les données de deux utilisateurs, équipes ou projets ?
• Traçabilité : pouvez-vous expliquer pourquoi une information a été écrite, modifiée, rappelée ou retirée ?

Le règlement européen sur la protection des données contient des exigences relatives aux principes de traitement et à l’effacement. Consultez le texte du RGPD sur EUR-Lex et faites vérifier son application à votre situation par les personnes compétentes. L’enjeu technique dépasse la suppression d’une ligne : si l’information a été transformée, copiée ou réindexée ailleurs, vous devez déterminer comment la modification se propage.

Point de vigilance : reconstruire un index peut actualiser les éléments présents dans cet index, mais ne prouve pas que toutes les autres copies ont été corrigées ou supprimées. Associez chaque donnée à une source de vérité et testez le parcours complet d’une correction ou d’un effacement.

La séparation des utilisateurs mérite une vérification dédiée. Un filtre absent d’une requête, une métadonnée mal propagée ou une tâche de mise à jour exécutée avec un mauvais périmètre peuvent provoquer un rappel indu. Documentez donc où les règles d’accès sont appliquées et incluez dans vos tests des requêtes conçues pour détecter un mélange de contextes. La fonctionnalité annoncée par un produit ne remplace pas ce contrôle dans votre application.

Choisissez selon les données, les changements et le coût d’exploitation

Utilisez cette liste de décision avant de sélectionner une architecture. Cochez les conditions qui correspondent à votre système, puis retenez l’option associée ; si plusieurs besoins s’appliquent, testez une combinaison en précisant les responsabilités de chaque composant.

• [ ] Vos données sont surtout des documents stables à retrouver par sujet. Commencez par une base de recherche vectorielle ou par votre mécanisme documentaire existant. Ajoutez des métadonnées de source, de version et de périmètre, puis mesurez la pertinence sur vos questions.
• [ ] L’agent doit réutiliser des expériences entre les sessions. Évaluez une couche de mémoire qui rende explicites la conservation, le rappel et la maintenance. Vérifiez que son modèle correspond à vos catégories de souvenirs et à votre façon de les corriger.
• [ ] Les informations changent fréquemment ou peuvent devenir obsolètes. Définissez d’abord la source de vérité et le processus d’actualisation. Une recherche efficace sur un index périmé reste une recherche sur une information périmée.
• [ ] Plusieurs utilisateurs ou projets partagent l’infrastructure. Exigez des règles d’isolement testables et contrôlez chaque chemin de lecture, d’écriture et d’effacement.
• [ ] Vous avez besoin à la fois de recherche documentaire et de mémoire d’agent. Une combinaison peut être pertinente, à condition d’attribuer chaque type de donnée à un composant et de préciser la synchronisation et la source faisant autorité. Si vous ne pouvez pas définir ces responsabilités, revenez à une architecture plus simple.
• [ ] Les exigences de confidentialité ne sont pas encore traduites en règles. Ne placez pas de données sensibles dans une mémoire persistante avant d’avoir défini les accès, la conservation, l’export et la suppression.

Les compromis d’exploitation font également partie de la sélection. Une couche spécialisée peut réduire le travail d’assemblage de certaines fonctions, mais introduire une dépendance et des interfaces supplémentaires à maintenir. Une base vectorielle peut rester familière à votre équipe et s’intégrer à votre stockage, mais il faudra peut-être écrire vous-même la logique de sélection des souvenirs, leurs statuts et leurs règles de maintenance. Ce sont des hypothèses à vérifier avec votre équipe, pas des avantages universels.

Pour formaliser le choix, attribuez à chaque exigence un responsable technique et un test de validation : l’écriture des faits, la recherche de documents, le rappel des expériences, l’isolement des utilisateurs et l’effacement. Si une exigence n’a ni propriétaire ni procédure de test, elle risque de rester une promesse implicite. Vous pourrez alors comparer les solutions sur les tâches qu’elles prennent réellement en charge, au lieu de choisir sur la seule étiquette « mémoire » ou « vectorielle ».

Validez d’abord l’architecture, puis choisissez l’environnement d’exécution

Avant de retenir une solution, faites tourner le même ensemble de cas sur votre système actuel et sur la variante envisagée. Conservez les requêtes, les résultats, les erreurs de périmètre et les opérations de mise à jour dans un jeu de test reproductible. Séparez les faits documentés par le projet, les conclusions que vous tirez de votre architecture et les résultats mesurés chez vous : cette distinction évite de confondre une interface disponible avec un résultat garanti.

Le choix d’un environnement d’exécution vient ensuite. Une infrastructure existante peut être plus simple si votre agent dépend déjà de services Linux, de bases accessibles à distance et d’outils de déploiement maîtrisés ; ses limites apparaissent lorsque vous devez reproduire des comportements propres à macOS, vérifier une application Apple ou tester un flux créatif lié à l’audio, à la vidéo ou au design. Pour comprendre les caractéristiques de l’infrastructure proposée, vous pouvez consulter la présentation de l’infrastructure Kvmjet. Un Mac ne remplace ni la base de données ni la politique de mémoire, et n’est pas nécessaire pour chaque agent. En revanche, si votre validation exige réellement macOS ou des outils de création sur cette plateforme, un Mac disponible à la demande peut éviter d’acheter une machine dédiée uniquement pour des tests ponctuels. Vous pouvez examiner les nœuds Mac M4 proposés par Kvmjet à Singapour ; pour un service qui doit tourner en continu avec une charge stable ou accéder à des périphériques physiques spécifiques, comparez plutôt la location à l’achat d’un poste dédié.

Votre décision entre Hindsight et une base vectorielle doit donc partir des données à conserver, de leur rythme de changement et des exigences de gouvernance. Si vous avez défini ces critères et que votre équipe a besoin d’un environnement temporaire pour vérifier une chaîne de création ou de test sur macOS, la location d’un Mac peut compléter l’évaluation — sans remplacer les essais de rappel, de correction et de suppression qui valident réellement votre architecture.