Comment fonctionne réellement une mémoire IA persistante

Les poids d'un modèle sont figés. Lui parler ne lui apprend rien, et fermer l'onglet ne le fait pas oublier — il n'y a jamais eu d'endroit où ce souvenir aurait pu aller. Ce que vous vivez comme un assistant qui se souvient de vous est un arrangement beaucoup plus prosaïque : du texte a été enregistré quelque part, et avant que le modèle réponde, un programme est allé retrouver les morceaux pertinents et les a collés devant lui.

C'est toute l'astuce. Mais la qualité d'une mémoire IA est presque entièrement la qualité de l'étape de récupération, et c'est là que les produits de cette catégorie diffèrent énormément tout en se décrivant de façon identique.

La fenêtre de contexte n'est pas une mémoire

On confond les deux en permanence, alors : la fenêtre de contexte est le bureau de travail du modèle. Tout ce qu'il peut prendre en compte maintenant, à ce tour-ci. Elle est vaste dans les modèles actuels, et elle est intégralement effacée entre deux conversations.

La mémoire est un stockage qui survit à la conversation. Le lien entre les deux, c'est que la mémoire *alimente* la fenêtre — sélectivement.

Et elle doit être sélective, parce que l'alternative naïve échoue à la fois sur le coût et sur la justesse. Si vous aviez un an de notes et que vous les déversiez toutes à chaque tour, vous paieriez ces jetons à chaque message, et le modèle ferait moins bien, pas mieux : un détail pertinent enfoui dans cent pages de détails hors sujet se dilue. La récupération existe parce que moins, bien choisi, vaut mieux que plus.

Stocker : la partie qui semble triviale et ne l'est pas

Deux décisions se prennent au moment de l'écriture, et les deux vous poursuivent ensuite.

Quoi garder. Enregistrer des transcriptions entières coûte peu et ne sert presque à rien : vous finissez par chercher dans une botte de foin que vous avez construite vous-même. Enregistrer des faits distillés est bien plus récupérable, mais exige un jugement sur ce qui importait — et toute extraction automatique écartera parfois précisément ce qui vous tenait à cœur. La plupart des produits se situent quelque part sur cet axe, et leur position prédit mieux la sensation au bout de six mois que n'importe quelle liste de fonctionnalités.

Comment le découper. Le texte entre sous forme de fragments, et le fragment est l'unité qui sera récupérée. Trop gros, et un résultat traîne avec lui trois sujets sans rapport. Trop petit, et la phrase revient privée du contexte qui la rendait signifiante. Il n'y a pas de bonne réponse, seulement une réponse réglée.

Trouver : les embeddings, et leur angle mort

Un second modèle — un modèle d'embedding, pas celui avec lequel vous discutez — transforme chaque fragment en un vecteur de quelques centaines à quelques milliers de nombres. Les textes de sens proche atterrissent près les uns des autres. Votre question subit le même traitement, et la recherche devient de la géométrie : renvoyer les fragments les plus proches.

Fait de façon exhaustive, c'est lent ; les vrais systèmes utilisent donc un index approximatif — HNSW est le plus courant, un graphe navigable qui atteint une bonne réponse sans visiter tous les points. Il échange un peu de rappel contre plusieurs ordres de grandeur de vitesse, et dans pgvector c'est un index d'une ligne.

Voici l'angle mort que personne ne mentionne dans son argumentaire. La recherche sémantique est *seulement* sémantique. Demandez un numéro de facture exact, un nom de famille, une version de bibliothèque, un nom de variable — les cas où vous connaissez la chaîne précise — et la similarité vectorielle vous tendra volontiers cinq choses qui *parlent* de ce sujet, sans celle qui contient la chaîne.

C'est pourquoi un index par mots-clés, BM25 ou la recherche plein texte d'une base de données, n'est pas l'ancienne approche que les vecteurs auraient remplacée. C'est la moitié pour laquelle les vecteurs sont mauvais.

Recherche hybride et reranking

Un pipeline de récupération sérieux lance les deux recherches et les fusionne. La fusion standard est la reciprocal rank fusion : chaque résultat est noté selon son *rang* dans chaque liste plutôt que selon un score brut, ce qui contourne le fait qu'une distance cosinus et un score BM25 ne sont pas mesurés dans la même unité et ne peuvent pas s'additionner.

Vient ensuite l'étape qui produit l'essentiel de la qualité perçue, et que beaucoup de produits sautent parce qu'elle coûte du calcul. La fusion vous donne une trentaine de candidats. Un reranker cross-encoder lit la question et chaque candidat *ensemble*, et note à quel point celui-ci répond à celle-là. C'est bien plus juste que de comparer deux vecteurs fabriqués indépendamment, et bien trop lent pour être passé sur tout le stock — d'où le fait qu'il intervienne en dernier, sur une liste courte.

Un avertissement si vous travaillez dans plus d'une langue. Les deux étapes dépendent de modèles, et beaucoup de modèles d'embedding et de reranking sont pensés d'abord pour l'anglais. Un pipeline qui obtient de bons scores en anglais peut se dégrader silencieusement en français ou en allemand, et vous vivrez cela comme « il a oublié », pas comme « le reranker a été entraîné sur la mauvaise distribution ». Si vous ne travaillez pas en anglais, vérifiez que les modèles sont réellement multilingues — multilingual-e5 est une de ces familles.

Quand nous avons fait passer notre propre pipeline de la recherche vectorielle simple à la fusion hybride plus un cross-encoder multilingue, le MRR (mean reciprocal rank) sur notre jeu d'évaluation a progressé de 139 %. Prenez ce chiffre pour ce qu'il est : notre mesure, sur nos données, avec notre découpage. Il dit que l'étape vaut la peine ; ce n'est pas un chiffre que vous devez attendre de reproduire sur un autre corpus.

Les quatre façons dont ça échoue

1. Ça n'a jamais été stocké. L'échec le plus fréquent, et de loin. Rien dans la chaîne de récupération ne peut retrouver un fait qui n'a jamais été écrit, et l'extraction automatique laisse passer des choses.
2. Pas de seuil. Si le système renvoie toujours ses cinq meilleurs résultats, alors quand rien de pertinent n'existe il renvoie cinq choses hors sujet — et le modèle, conciliant, les intègre. Un plancher de similarité qui ne renvoie rien est une fonctionnalité, et son absence explique pourquoi certains assistants se souviennent de travers avec assurance.
3. Les contradictions périmées. Vous avez déménagé ; l'ancien et le nouveau fait sont tous deux dans le stock, tous deux récupérables. Sans pondération par récence ni remplacement explicite, le modèle peut piocher l'un ou l'autre.
4. Le problème de l'aiguille. Les identifiants exacts, dans un système purement vectoriel. Voir plus haut.

Ce qu'il faut demander à un produit de mémoire

Cinq questions, et chacune a une réponse factuelle qu'un éditeur vous donne ou esquive :

• Recherche par mots-clés en plus du vectoriel, ou vectoriel seulement ?
• Y a-t-il une étape de reranking, et avec quel modèle ?
• Y a-t-il un seuil de pertinence sous lequel le système ne renvoie rien ?
• Les modèles d'embedding et de reranking sont-ils multilingues, et évalués dans ma langue ?
• Puis-je voir, modifier et supprimer un souvenir individuel — ou le stock est-il opaque pour moi ?

La dernière ne concerne pas la qualité de la récupération, mais c'est celle qui vous importera en premier, la première fois qu'une chose fausse sera retenue à votre sujet.

Pryzm fait tourner une fusion hybride avec reranker cross-encoder multilingue et un seuil de pertinence, sur PostgreSQL avec index HNSW, et chaque souvenir est visible et supprimable individuellement. La comparaison avec les alternatives est dans notre tableau.