Structured Distillation for Personalized Agent Memory: 11x Token Reduction with Retrieval Preservation

Ce papier présente une méthode de distillation structurée qui compresse l'historique des conversations d'un agent IA personnalisé avec un facteur 11, réduisant la taille des tokens tout en préservant la qualité de la recherche grâce à une représentation textuelle structurée et à des stratégies d'hybridation de la recherche.

L'essentiel

Le Problème : La mémoire à courte vue de l'IA

Imaginez que vous travaillez avec un assistant très intelligent, mais qui a une mémoire de poisson rouge. À chaque fois que vous commencez une nouvelle session de discussion, il oublie tout ce que vous avez fait la semaine dernière, le mois dernier, ou même il y a 10 minutes.

Si vous lui dites : "Rappelle-toi comment on a réglé ce bug de connexion il y a trois semaines ?", il vous répondra : "Désolé, je ne sais pas de quoi vous parlez."

Pour qu'il se souvienne, vous devez lui relire tout l'historique de vos conversations. Le problème ? Ces conversations sont énormes. C'est comme essayer de lire un roman entier de 500 pages juste pour trouver une phrase précise. C'est lent, ça coûte cher (en temps de calcul), et ça sature la "mémoire à court terme" de l'IA.

La Solution : Le "Résumé Structuré" (La Distillation)

Les chercheurs (Sydney Lewis) ont eu une idée brillante : ne pas supprimer l'histoire, mais la résumer intelligemment pour créer un index.

Imaginez que vous avez une bibliothèque de 10 000 livres (vos conversations).

1. L'approche actuelle (Grosse erreur) : On essaie de réduire chaque livre à 2 pages de résumé flou. On perd des détails importants, et si on résume un résumé, on perd encore plus. C'est le "résumé par la force".
2. L'approche du papier (La distillation) : On garde les 10 000 livres intacts sur une étagère (sur votre ordinateur). Mais on crée un petit catalogue de 10 000 fiches.

Chaque fiche (appelée "objet distillé") ne contient que l'essentiel :

• Le cœur de l'échange : "On a changé le délai d'attente de la connexion."
• Le contexte précis : "L'erreur était 'Timeout 5000'."
• Les fichiers touchés : "Fichier config.py."
• La "pièce" du souvenir : "C'est dans la catégorie 'Bases de données'."

Ce catalogue est 11 fois plus petit que les conversations originales. Au lieu de lire 371 mots pour chaque échange, l'IA n'a plus besoin que de 38 mots pour comprendre de quoi il s'agit.

L'Expérience : Le Test de la Mémoire

Les chercheurs ont voulu savoir : "Si on utilise ce petit catalogue pour chercher, va-t-on trouver les bonnes réponses aussi bien qu'en lisant les livres entiers ?"

Ils ont pris 4 000 conversations d'un seul développeur et ont posé 200 questions types, comme :

• "Comment on a résolu l'erreur de connexion ?"
• "Quel fichier contenait le bug ?"

Ils ont testé deux méthodes de recherche :

1. La recherche par mots-clés (BM25) : Comme chercher un mot précis dans un livre.
2. La recherche sémantique (Vecteurs) : Comme demander à un bibliothécaire : "Montrez-moi les livres qui parlent de la même idée, même si les mots sont différents."

Les Résultats : Une Surprise

Voici ce qu'ils ont découvert, avec des analogies simples :

1. La recherche par mots-clés échoue avec le résumé
Si vous cherchez un mot précis (ex: "erreur 5000") dans le petit catalogue, vous ne le trouvez pas toujours. Pourquoi ? Parce que le résumé a parfois remplacé "erreur 5000" par "problème de temps". C'est comme chercher le mot "pomme" dans un résumé qui dit "fruit rouge". Le résumé a perdu les mots exacts.

• Verdict : La recherche par mots-clés sur le résumé est moins bonne.

2. La recherche par "idée" (Vecteurs) fonctionne parfaitement
C'est là que la magie opère. Quand on demande au système de chercher par "idée" (sémantique), le petit catalogue est aussi bon que les livres entiers.

• Verdict : Même si le résumé est court, il garde l'essence de l'idée. L'IA comprend que "problème de temps" et "erreur 5000" parlent de la même chose.
• Résultat clé : Avec cette méthode, on garde 96% de la qualité de recherche, tout en divisant la taille des données par 11 !

3. Le meilleur des deux mondes
Le vrai gagnant est une combinaison : utiliser les mots-clés sur les livres originaux (pour les détails précis) ET la recherche par idée sur le petit catalogue (pour comprendre le contexte). Ensemble, ils sont même un tout petit peu meilleurs que de chercher uniquement dans les livres originaux.

Pourquoi c'est génial ? (L'Analogie du "Palais de Mémoire")

Imaginez que votre mémoire d'IA est un Palais.

• Avant : Le palais était rempli de tonnes de papiers en vrac. Pour trouver une info, il fallait fouiller dans des montagnes de papier. C'était lent et encombré.
• Maintenant : On a créé un système d'indexation.
  • L'IA ne garde en tête que les fiches de l'index (le résumé court). C'est léger, ça rentre dans sa poche.
  • Si l'index dit "Regarde dans la pièce des Bases de Données, fichier A", l'IA va chercher le vrai document (le livre entier) sur l'étagère pour vous le montrer.

Le résultat ?

• Vous pouvez garder des mois de conversations dans la mémoire de l'IA sans qu'elle ne "crash".
• Elle se souvient de tout ce qui est important.
• Si vous avez besoin des détails exacts (le code précis, le message d'erreur exact), elle va les chercher dans le document original.

En résumé

Ce papier nous dit : On n'a pas besoin de supprimer nos souvenirs pour les faire tenir dans la tête d'une IA.

Il suffit de créer un résumé structuré (comme une étiquette sur une boîte) qui garde les mots-clés importants et les idées. Cela permet à l'IA de se souvenir de tout, de répondre vite, et de vous montrer les détails originaux quand vous en avez besoin. C'est comme passer d'un tas de feuilles volantes à un classeur parfaitement rangé.

Résumé technique

1. Problématique : La mémoire asymétrique et le coût du contexte

L'article aborde un problème fondamental dans les interactions humain-agent IA : l'asymétrie de la mémoire.

• Le constat : L'humain se souvient de fragments d'interactions passées (décisions, erreurs résolues), tandis que l'agent commence chaque session avec une mémoire vierge ("zero-shot").
• La contrainte technique : Pour rendre l'agent conscient de son historique, il faut charger les conversations passées dans le contexte (fenêtre d'attention). Cependant, une conversation typique dans le corpus étudié contient en moyenne 371 tokens. Charger 500 échanges représenterait près de 200 000 tokens, ce qui est coûteux et épuise rapidement les fenêtres de contexte des LLM.
• L'approche actuelle et ses limites : Les systèmes actuels utilisent souvent la "compaction" (résumé itératif par un LLM) pour réduire la taille du contexte. Cette méthode est lossy (perte d'information) et non structurée : elle dégrade l'information au fil du temps et ne conserve pas les détails techniques précis (noms de fichiers, paramètres, messages d'erreur) nécessaires à la recherche future.

Objectif de l'article : Déterminer si l'historique d'un utilisateur unique peut être distillé en une couche de mémoire compacte et structurée, permettant une recherche efficace (rappel) tout en conservant le texte original (verbatim) pour consultation approfondie, sans sacrifier la qualité de la récupération d'information.

2. Méthodologie : Distillation Structurée et Architecture à deux niveaux

L'auteur propose une méthode de distillation structurée qui transforme chaque échange de conversation en un objet composé, plutôt qu'un simple résumé textuel.

A. Segmentation et Distillation

• Unité de base : Un "échange" (un demi-coup utilisateur + la réponse complète de l'agent).
• Objet distillé (Palace Object) : Chaque échange est converti en un objet contenant quatre champs :
  1. exchange_core : Ce qui a été accompli (1-2 phrases, analogue à un message de commit).
  2. specific_context : Un détail technique distinctif (analogue à un "diff", contenant les valeurs exactes, erreurs, paramètres).
  3. thematic_room_assignments : 1 à 3 "salons" thématiques générés par LLM (ex: file:auth_middleware, concept:retry_timeout).
  4. files_touched : Chemins de fichiers extraits par regex (non générés par LLM).
• Principe du vocabulaire survivant : Le LLM est contraint de réutiliser les termes exacts de la conversation pour les champs clés, évitant la paraphrase libre qui perdrait les identifiants techniques.
• Compression : Le texte distillé (core + context) moyenne 38 tokens contre 371 pour le texte original, soit un ratio de compression de 11x.

B. Architecture de Recherche

Le système sépare l'index de recherche de l'affichage :

• Couche d'index (Distillée) : Utilisée pour le routage et le classement initial. Elle est légère et permet de faire tenir des milliers d'échanges dans un prompt.
• Couche de vérité (Verbatim) : Le texte original complet est conservé localement. Lorsqu'un résultat est sélectionné, l'utilisateur lit l'échange original non modifié.
• Moteurs de recherche :
  • Vectoriel : HNSW et Exact (cosine similarity) sur les embeddings des objets distillés.
  • Lexical : BM25 (Okapi et FTS) sur les objets distillés et le texte verbatim.
• Modes de recherche : L'étude évalue 107 configurations, incluant des modes "purs" (un seul moteur sur une seule couche) et des modes "trans-couches" (fusion de BM25 sur le verbatim et HNSW sur le distillé).

3. Évaluation Expérimentale

• Corpus : 4 182 conversations d'un seul développeur sur 6 projets d'ingénierie logicielle (14 340 échanges).
• Requêtes : 201 requêtes de rappel conçues pour tester la récupération de concepts, de phrases et de termes exacts.
• Grading : 5 modèles LLM locaux (7-12B paramètres) ont noté la pertinence des résultats (échelle 0-3) selon les conventions TREC. Un modèle "Opus" calibré a résolu les désaccords.
• Métriques principales : MRR (Mean Reciprocal Rank), Note Moyenne, P@1, nDCG@10.

4. Résultats Clés

A. Compression et Préservation de la Qualité

• Compression : Réduction de 371 à 38 tokens par échange (11x).
• Performance globale : La meilleure configuration pure distillée (Distill Core+Rooms avec recherche Exacte) atteint un MRR de 0,717, soit 96 % du meilleur résultat verbatim (0,745).
• Dépendance au mécanisme de recherche : C'est le résultat le plus critique.
  • Recherche Vectorielle (HNSW, Exact) : Aucune dégradation statistiquement significative après correction de Bonferroni. Les 20 configurations vectorielles distillées préservent la qualité de rappel.
  • Recherche Lexicale (BM25) : Dégradation significative pour toutes les configurations (10/10). La compression supprime le vocabulaire spécifique nécessaire à la correspondance exacte de mots-clés.

B. Complémentarité et Fusion Trans-Couche

• La fusion des signaux améliore les résultats. La configuration trans-couche combinant BM25(Verbatim) + HNSW(Distillé) atteint un MRR de 0,759, dépassant légèrement la meilleure configuration pure verbatim (0,745).
• Cela démontre que la distillation ne fait pas que perdre de l'information ; elle crée un signal complémentaire (structure sémantique et métadonnées) que la recherche purement lexicale sur le texte brut ne capture pas.

C. Analyse par Type de Requête

• Les requêtes de termes exacts (noms de fichiers, IDs) sont parfois mieux résolues par la version distillée grâce aux métadonnées structurées (files_touched).
• Les requêtes conceptuelles souffrent davantage de la compression, car le contexte sémantique large est plus difficile à préserver sans le texte brut.

5. Contributions et Signification

1. Méthode de Distillation Structurée : Une approche qui transforme l'historique de conversation en objets indexables (résumé, contexte technique, métadonnées) plutôt qu'en simples résumés textuels.
2. Preuve de Viabilité à 11x : Démonstration qu'une compression de 11x est possible pour la mémoire d'agent sans détruire la capacité de rappel, à condition d'utiliser la bonne méthode de recherche (vectorielle).
3. Architecture à Deux Niveaux : Proposition d'un système où l'agent utilise une mémoire de travail compacte (distillée) pour le routage, tout en gardant la vérité terrain (verbatim) accessible pour l'affichage. Cela résout le problème de la fenêtre de contexte limitée sans perte d'information critique.
4. Analyse Mécanique : Mise en évidence que la qualité de la distillation dépend entièrement du mécanisme de recherche sous-jacent (le vectoriel fonctionne, le lexical échoue sur du texte compressé).

Conclusion

L'article conclut que la distillation structurée est une solution viable pour la mémoire personnalisée des agents. Elle permet de stocker des milliers d'échanges (ex: 1 000 échanges dans ~39 000 tokens au lieu de ~407 000) tout en maintenant une qualité de rappel élevée. Le système proposé permet à l'agent de "se souvenir" des décisions passées et des contextes techniques, comblant le fossé de mémoire asymétrique entre l'humain et la machine, tout en laissant le texte original disponible pour une vérification détaillée.

L'implémentation et le pipeline d'analyse sont disponibles en open-source, bien que les données privées du corpus ne le soient pas.