Réflexions sur ChatGPT et les systèmes de mémoire de Claude : Ce qu'il faut pour permettre une récupération conversationnelle à la demande

Dans les systèmes d'agents d'IA de haute qualité, la conception de la mémoire est beaucoup plus complexe qu'il n'y paraît à première vue. Elle doit répondre à trois questions fondamentales : Comment l'historique des conversations doit-il être stocké ? Quand le contexte passé doit-il être récupéré ? Et qu'est-ce qui doit être récupéré exactement ?

Ces choix déterminent directement le temps de réponse d'un agent, l'utilisation des ressources et, en fin de compte, le plafond de ses capacités.

Les modèles tels que ChatGPT et Claude sont de plus en plus "conscients de la mémoire" à mesure que nous les utilisons. Ils se souviennent des préférences, s'adaptent aux objectifs à long terme et maintiennent la continuité entre les sessions. En ce sens, ils fonctionnent déjà comme des mini-agents d'intelligence artificielle. Pourtant, sous la surface, leurs systèmes de mémoire sont construits sur des hypothèses architecturales très différentes.

Des analyses récentes de rétro-ingénierie des mécanismes de mémoire de ChatGPTet de Claude révèlent un contraste évident. ChatGPT s'appuie sur l'injection de contexte précalculé et la mise en cache en couches pour offrir une continuité légère et prévisible. Claude, en revanche, adopte le style RAG, la récupération à la demande avec des mises à jour dynamiques de la mémoire pour équilibrer la profondeur de la mémoire et l'efficacité.

Ces deux approches ne sont pas simplement des préférences de conception, elles sont façonnées par les capacités de l'infrastructure. Milvus 2.6 introduit la combinaison de la récupération hybride dense-sparse, du filtrage scalaire efficace et du stockage hiérarchisé que la mémoire conversationnelle à la demande requiert, rendant la récupération sélective suffisamment rapide et économique pour être déployée dans les systèmes du monde réel.

Dans ce billet, nous verrons comment les systèmes de mémoire de ChatGPT et de Claude fonctionnent réellement, pourquoi ils ont divergé au niveau de l'architecture, et comment les avancées récentes dans des systèmes comme Milvus rendent la récupération conversationnelle à la demande pratique à l'échelle.

Le système de mémoire de ChatGPT

Au lieu d'interroger une base de données vectorielle ou de récupérer dynamiquement les conversations passées au moment de l'inférence, ChatGPT construit sa "mémoire" en assemblant un ensemble fixe de composants contextuels et en les injectant directement dans chaque invite. Chaque composant est préparé à l'avance et occupe une position connue dans l'invite.

Cette conception permet de préserver la personnalisation et la continuité de la conversation tout en rendant la latence, l'utilisation des jetons et le comportement du système plus prévisibles. En d'autres termes, la mémoire n'est pas quelque chose que le modèle recherche à la volée, c'est quelque chose que le système conditionne et remet au modèle chaque fois qu'il génère une réponse.

À un niveau élevé, une invite ChatGPT complète se compose des couches suivantes, classées de la plus globale à la plus immédiate :

[0] Instructions du système

[1] Instructions du développeur

[2] Métadonnées de la session (éphémères)

[3] Mémoire de l'utilisateur (faits à long terme)

[4] Résumé des conversations récentes (conversations passées, titres + extraits)

[5] Messages de la session en cours (cette discussion)

[6] Votre dernier message

Parmi ces éléments, les composants [2] à [5] constituent la mémoire effective du système, chacun jouant un rôle distinct.

Métadonnées de session

Les métadonnées de session représentent des informations de courte durée, non persistantes, qui sont injectées une fois au début d'une conversation et supprimées à la fin de la session. Leur rôle est d'aider le modèle à s'adapter au contexte d'utilisation actuel plutôt que de personnaliser le comportement à long terme.

Cette couche capture des signaux relatifs à l'environnement immédiat de l'utilisateur et à ses habitudes d'utilisation récentes. Les signaux typiques sont les suivants

• des informations sur l'appareil - par exemple, si l'utilisateur est sur un téléphone portable ou un ordinateur de bureau

• Attributs du compte - tels que le niveau d'abonnement (par exemple, ChatGPT Go), l'âge du compte et la fréquence d'utilisation globale.

• Mesures comportementales - y compris les jours actifs au cours des 1, 7 et 30 derniers jours, la durée moyenne de la conversation et la distribution de l'utilisation du modèle (par exemple, 49 % des demandes traitées par GPT-5).

Mémoire des utilisateurs

La mémoire de l'utilisateur est la couche de mémoire persistante et modifiable qui permet de personnaliser les conversations. Elle stocke des informations relativement stables, telles que le nom de l'utilisateur, son rôle ou ses objectifs de carrière, ses projets en cours, ses résultats passés et ses préférences en matière d'apprentissage, et est injectée dans chaque nouvelle conversation afin de préserver la continuité au fil du temps.

Cette mémoire peut être mise à jour de deux manières :

• Lesmises à jour explicites se produisent lorsque les utilisateurs gèrent directement la mémoire à l'aide d'instructions telles que "se souvenir de ceci" ou "supprimer ceci de la mémoire".

• Lesmises à jour implicites se produisent lorsque le système identifie des informations qui répondent aux critères de stockage d'OpenAI, comme un nom confirmé ou un titre de poste, et les enregistre automatiquement, sous réserve du consentement par défaut de l'utilisateur et des paramètres de la mémoire.

Résumé des conversations récentes

Le résumé de la conversation récente est une couche contextuelle légère, intersession, qui préserve la continuité sans rejouer ou récupérer l'historique complet des conversations. Au lieu de s'appuyer sur une récupération dynamique, comme dans les approches traditionnelles basées sur les RAG, ce résumé est précalculé et injecté directement dans chaque nouvelle conversation.

Cette couche résume uniquement les messages de l'utilisateur, à l'exclusion des réponses de l'assistant. Sa taille est volontairement limitée (environ 15 entrées en général) et elle ne retient que les signaux de haut niveau concernant les intérêts récents plutôt que le contenu détaillé. Comme elle ne s'appuie pas sur les enchâssements ou la recherche de similarités, elle maintient la latence et la consommation de jetons à un niveau peu élevé.

Messages de la session en cours

Les messages de la session en cours contiennent l'historique complet des messages de la conversation en cours et fournissent le contexte à court terme nécessaire à des réponses cohérentes, au fur et à mesure. Cette couche comprend à la fois les entrées de l'utilisateur et les réponses de l'assistant, mais uniquement tant que la session reste active.

Comme le modèle fonctionne avec une limite fixe de jetons, cet historique ne peut pas croître indéfiniment. Lorsque la limite est atteinte, le système supprime les premiers messages pour faire de la place aux plus récents. Cette troncature n'affecte que la session en cours : la mémoire à long terme de l'utilisateur et le résumé des conversations récentes restent intacts.

Le système de mémoire de Claude

Claude adopte une approche différente de la gestion de la mémoire. Plutôt que d'injecter un ensemble important et fixe de composants de mémoire dans chaque invite, comme le fait ChatGPT, Claude combine la mémoire persistante de l'utilisateur avec des outils à la demande et une récupération sélective. Le contexte historique n'est récupéré que lorsque le modèle le juge pertinent, ce qui permet au système de faire un compromis entre la profondeur contextuelle et le coût de calcul.

Le contexte de l'invite de Claude est structuré comme suit :

[0] Invite du système (instructions statiques)

[1] Mémoires de l'utilisateur

[2] Historique de la conversation

[3] Message actuel

Les principales différences entre Claude et ChatGPT résident dans la manière dont l'historique des conversations est récupéré et dont la mémoire de l'utilisateur est mise à jour et maintenue.

Mémoires d'utilisateurs

Dans Claude, les mémoires d'utilisateurs forment une couche de contexte à long terme similaire à la mémoire d'utilisateur de ChatGPT, mais avec un accent plus marqué sur les mises à jour automatiques en arrière-plan. Ces mémoires sont stockées dans un format structuré (enveloppé dans des balises de style XML) et sont conçues pour évoluer progressivement dans le temps avec une intervention minimale de l'utilisateur.

Claude prend en charge deux modes de mise à jour :

• Mises à jour implicites - Le système analyse périodiquement le contenu des conversations et met à jour la mémoire en arrière-plan. Ces mises à jour ne sont pas appliquées en temps réel, et les mémoires associées aux conversations supprimées sont progressivement élaguées dans le cadre d'une optimisation continue.

• Mises à jour explicites - Les utilisateurs peuvent gérer directement la mémoire par le biais de commandes telles que "se souvenir de ceci" ou "supprimer ceci", qui sont exécutées via un outil dédié memory_user_edits.

Par rapport à ChatGPT, Claude confie au système lui-même la responsabilité d'affiner, de mettre à jour et d'élaguer la mémoire à long terme. Cela réduit la nécessité pour les utilisateurs de conserver activement ce qui est stocké.

Historique des conversations

Pour l'historique des conversations, Claude ne s'appuie pas sur un résumé fixe qui est injecté dans chaque message. Au lieu de cela, il récupère le contexte passé uniquement lorsque le modèle décide que c'est nécessaire, en utilisant trois mécanismes distincts. Cela permet d'éviter de reporter un historique non pertinent et de contrôler l'utilisation des jetons.

Composant	Objectif	Comment il est utilisé
Fenêtre mobile (conversation en cours)	Stocke l'historique complet des messages de la conversation en cours (et non un résumé), de manière similaire au contexte de session de ChatGPT	Injecté automatiquement. La limite de jetons est de ~190K ; les messages plus anciens sont supprimés une fois la limite atteinte.
conversation_search outil	Recherche des conversations passées par sujet ou mot-clé, renvoyant des liens de conversation, des titres et des extraits de messages de l'utilisateur/assistant.	Déclenché lorsque le modèle détermine que des détails historiques sont nécessaires. Les paramètres sont query (termes de recherche) et max_results (1-10).
recent_chats outil	Récupère les conversations récentes dans un intervalle de temps spécifié (par exemple, "les 3 derniers jours"), les résultats étant formatés de la même manière que dans le cas de l'outil de recherche. conversation_search	Déclenché lorsque le contexte récent et temporel est pertinent. Les paramètres comprennent n (nombre de résultats), sort_order, et l'intervalle de temps.

Parmi ces composants, conversation_search est particulièrement remarquable. Il peut faire apparaître des résultats pertinents même pour des requêtes formulées en termes vagues ou multilingues, ce qui indique qu'il opère à un niveau sémantique plutôt que de s'appuyer sur une simple correspondance de mots-clés. Il s'agit probablement d'une recherche basée sur l'intégration ou d'une approche hybride qui traduit ou normalise d'abord la requête sous une forme canonique, puis applique une recherche par mot-clé ou une recherche hybride.

Dans l'ensemble, l'approche de Claude en matière de recherche à la demande présente plusieurs points forts notables :

• L'extraction n'est pas automatique: Les appels d'outils sont déclenchés par le propre jugement du modèle. Par exemple, lorsqu'un utilisateur fait référence au "projet dont nous avons discuté la dernière fois", Claude peut décider d'invoquer conversation_search pour récupérer le contexte pertinent.

• Un contexte plus riche en cas de besoin: Les résultats récupérés peuvent inclure des extraits de la réponse de l'assistant, alors que les résumés de ChatGPT ne capturent que les messages de l'utilisateur. Claude est donc mieux adapté aux cas d'utilisation qui nécessitent un contexte conversationnel plus approfondi ou plus précis.

• Une meilleure efficacité par défaut: Le contexte historique n'étant injecté qu'en cas de besoin, le système évite de reporter de grandes quantités d'historique non pertinent, réduisant ainsi la consommation inutile de jetons.

Les compromis sont tout aussi clairs. L'introduction de la recherche à la demande augmente la complexité du système : les index doivent être construits et maintenus, les requêtes exécutées, les résultats classés et parfois reclassés. La latence de bout en bout devient également moins prévisible qu'avec un contexte précalculé et toujours injecté. En outre, le modèle doit apprendre à décider quand l'extraction est nécessaire. Si ce jugement échoue, il se peut que le contexte pertinent ne soit jamais récupéré.

Les contraintes de la recherche à la demande à la Claude

L'adoption d'un modèle de recherche à la demande fait de la base de données vectorielle un élément essentiel de l'architecture. La recherche par conversation impose des exigences inhabituellement élevées en matière de stockage et d'exécution des requêtes, et le système doit répondre à quatre contraintes en même temps.

1. Tolérance de faible latence

Dans les systèmes conversationnels, la latence P99 doit généralement rester inférieure à ~20 ms. Les retards au-delà de ce seuil sont immédiatement perceptibles par les utilisateurs. Cela laisse peu de place à l'inefficacité : la recherche vectorielle, le filtrage des métadonnées et le classement des résultats doivent tous être soigneusement optimisés. Un goulot d'étranglement à n'importe quel moment peut dégrader l'ensemble de l'expérience conversationnelle.

2. Exigences en matière de recherche hybride

Les requêtes des utilisateurs couvrent souvent plusieurs dimensions. Une requête telle que "discussions sur RAG de la semaine écoulée" combine pertinence sémantique et filtrage temporel. Si une base de données ne prend en charge que la recherche vectorielle, elle peut renvoyer 1 000 résultats sémantiquement similaires, mais le filtrage de la couche d'application les réduira à une poignée, ce qui gaspillera la majeure partie du calcul. Pour être pratique, la base de données doit prendre en charge de manière native les requêtes vectorielles et scalaires combinées.

3. Séparation du stockage et du calcul

L'historique des conversations présente un schéma d'accès chaud-froid évident. Les conversations récentes font l'objet de requêtes fréquentes, tandis que les plus anciennes sont rarement consultées. Si tous les vecteurs devaient rester en mémoire, le stockage de dizaines de millions de conversations consommerait des centaines de gigaoctets de mémoire vive, un coût irréaliste à l'échelle. Pour être viable, le système doit prendre en charge la séparation du stockage et du calcul, en conservant les données chaudes en mémoire et les données froides dans le stockage d'objets, les vecteurs étant chargés à la demande.

4. Diverses formes de requêtes

La recherche de conversations ne suit pas un modèle d'accès unique. Certaines requêtes sont purement sémantiques (par exemple, "l'optimisation des performances dont nous avons discuté"), d'autres sont purement temporelles ("toutes les conversations de la semaine dernière"), et beaucoup combinent des contraintes multiples ("les discussions liées à Python mentionnant FastAPI au cours des trois derniers mois"). Le planificateur de requêtes de la base de données doit adapter les stratégies d'exécution aux différents types de requêtes, plutôt que de s'appuyer sur une recherche brute universelle.

Ensemble, ces quatre défis définissent les contraintes fondamentales de la recherche conversationnelle. Tout système cherchant à mettre en œuvre une recherche à la demande de type Claude doit les relever de manière coordonnée.

Pourquoi Milvus 2.6 fonctionne-t-il bien pour la recherche conversationnelle ?

Les choix de conception de Milvus 2.6 s'alignent étroitement sur les exigences fondamentales de la recherche conversationnelle à la demande. Vous trouverez ci-dessous une ventilation des capacités clés et de leur correspondance avec les besoins réels en matière de recherche conversationnelle.

Recherche hybride avec des vecteurs denses et épars

Milvus 2.6 prend en charge de manière native le stockage de vecteurs denses et épars dans la même collection et la fusion automatique de leurs résultats au moment de la requête. Les vecteurs denses (par exemple, les encastrements à 768 dimensions générés par des modèles tels que BGE-M3) capturent la similarité sémantique, tandis que les vecteurs épars (généralement produits par BM25) préservent les signaux exacts des mots-clés.

Pour une requête telle que "discussions sur le RAG de la semaine dernière", Milvus exécute en parallèle la recherche sémantique et la recherche par mot-clé, puis fusionne les résultats par le biais d'un reranking. Par rapport à l'utilisation de l'une ou l'autre approche seule, cette stratégie hybride permet d'obtenir un taux de rappel nettement plus élevé dans des scénarios conversationnels réels.

Séparation stockage-calcul et optimisation des requêtes

Milvus 2.6 prend en charge le stockage hiérarchisé de deux manières :

• Données chaudes en mémoire, données froides dans le stockage d'objets

• Les index en mémoire, les données vectorielles brutes dans le stockage d'objets.

Avec cette conception, le stockage d'un million d'entrées de conversation peut être réalisé avec environ 2 Go de mémoire et 8 Go de stockage d'objets. Avec un réglage approprié, la latence P99 peut rester inférieure à 20 ms, même lorsque la séparation stockage-computation est activée.

Déchiquetage JSON et filtrage scalaire rapide

Milvus 2.6 active le déchiquetage JSON par défaut, en aplatissant les champs JSON imbriqués dans un stockage en colonnes. Cela améliore les performances du filtrage scalaire de 3 à 5 fois selon les références officielles (les gains réels varient en fonction du modèle de requête).

La recherche conversationnelle nécessite souvent un filtrage par métadonnées telles que l'identifiant de l'utilisateur, l'identifiant de la session ou l'intervalle de temps. Avec JSON Shredding, des requêtes telles que "toutes les conversations de l'utilisateur A au cours de la semaine écoulée" peuvent être exécutées directement sur des index en colonnes, sans avoir à analyser de manière répétée des blobs JSON complets.

Contrôle open-source et flexibilité opérationnelle

En tant que système open-source, Milvus offre un niveau de contrôle architectural et opérationnel que les solutions fermées à boîte noire n'offrent pas. Les équipes peuvent régler les paramètres d'index, appliquer des stratégies de hiérarchisation des données et personnaliser les déploiements distribués en fonction de leurs charges de travail.

Cette flexibilité réduit la barrière à l'entrée : les équipes de petite et moyenne taille peuvent construire des systèmes de recherche conversationnelle à l'échelle d'un million ou d'une dizaine de millions sans dépendre de budgets d'infrastructure surdimensionnés.

Pourquoi ChatGPT et Claude ont pris des chemins différents

À un niveau élevé, la différence entre les systèmes de mémoire de ChatGPT et de Claude se résume à la façon dont chacun gère l'oubli. ChatGPT favorise l'oubli proactif : une fois que la mémoire dépasse les limites fixées, le contexte plus ancien est abandonné. Ceci échange l'exhaustivité contre la simplicité et un comportement prévisible du système. Claude favorise l'oubli différé. En théorie, l'historique des conversations peut croître sans limite, le rappel étant délégué à un système de récupération à la demande.

Pourquoi les deux systèmes ont-ils choisi des voies différentes ? Avec les contraintes techniques exposées ci-dessus, la réponse devient claire : chaque architecture n'est viable que si l'infrastructure sous-jacente peut la supporter.

Si l'approche de Claude avait été tentée en 2020, elle aurait probablement été irréalisable. À l'époque, les bases de données vectorielles présentaient souvent des temps de latence de plusieurs centaines de millisecondes, les requêtes hybrides étaient mal supportées et l'utilisation des ressources augmentait de manière prohibitive à mesure que les données s'accroissaient. Dans ces conditions, la recherche à la demande aurait été considérée comme une ingénierie excessive.

En 2025, le paysage a changé. Les progrès réalisés en matière d'infrastructure, sous l'impulsion de systèmes tels que Milvus 2.6, ontrendu viables en production la séparation du stockage et du calcul, l'optimisation des requêtes, la recherche hybride dense et éparse et le déchiquetage JSON. Ces progrès réduisent la latence, contrôlent les coûts et rendent la recherche sélective pratique à l'échelle. En conséquence, les outils à la demande et la mémoire basée sur la recherche sont devenus non seulement réalisables, mais aussi de plus en plus attrayants, en particulier en tant que base pour les systèmes de type agent.

En fin de compte, les choix d'architecture dépendent de ce que l'infrastructure rend possible.

Conclusion

Dans les systèmes réels, la conception de la mémoire n'est pas un choix binaire entre un contexte précalculé et une récupération à la demande. Les architectures les plus efficaces sont généralement hybrides, combinant les deux approches.

Un modèle courant consiste à injecter des conversations récentes par le biais d'une fenêtre contextuelle glissante, à stocker les préférences stables de l'utilisateur dans une mémoire fixe et à récupérer l'historique plus ancien à la demande par le biais d'une recherche vectorielle. Au fur et à mesure de la maturation d'un produit, cet équilibre peut être modifié progressivement - d'un contexte principalement précalculé à un contexte de plus en plus axé sur la recherche - sans nécessiter de réinitialisation architecturale perturbatrice.

Même si l'on commence par une approche précalculée, il est important de concevoir le produit en tenant compte de la migration. La mémoire doit être stockée avec des identifiants clairs, des horodatages, des catégories et des références aux sources. Lorsque l'extraction devient viable, des embeddings peuvent être générés pour la mémoire existante et ajoutés à une base de données vectorielle avec les mêmes métadonnées, ce qui permet d'introduire la logique d'extraction de manière progressive et avec un minimum de perturbations.

Vous avez des questions ou souhaitez approfondir l'une des fonctionnalités de la dernière version de Milvus ? Rejoignez notre canal Discord ou déposez des questions sur GitHub. Vous pouvez également réserver une session individuelle de 20 minutes pour obtenir des informations, des conseils et des réponses à vos questions dans le cadre des Milvus Office Hours.