Compresser l'historique des conversations sans perdre l'essentiel
Le résumé naïf détruit exactement ce que les utilisateurs redemandent plus tard. La stratégie d'iRemember : séparation épisodes/faits, compression progressive sous condition de couverture, préservation des ancres temporelles et évaluation par questions sondes.
Les agents long-horizon finissent par se heurter à un mur : l'historique grossit, la récupération devient plus bruitée, les budgets de contexte restent finis. La compression est la réponse évidente — et le résumé naïf est l'erreur évidente.
Nous l'avons appris sur iRemember : notre premier résumeur rendait les conversations plus courtes et l'assistant moins intelligent. Les utilisateurs demandaient « qu'a-t-il promis exactement ? » et le résumait répondait « ont discuté de plans ». Cet article décrit la stratégie qui l'a remplacée.
Les résumés répondent à la mauvaise question
Un résumé optimise la cohérence narrative. Les requêtes mémoire sont probatoires : promesses exactes, dates, chiffres, qui-a-dit-quoi. Ce sont précisément les détails que les résumés aplatissent.
Règle numéro un : compresser les épisodes, garder les faits. Tout ce que l'extracteur a classé comme fait durable vit de manière autonome et ne dépend jamais de la survie d'un résumé. Les résumés ne portent que l'atmosphère et le fil.
Compression progressive sous condition
La compression s'exécute du plus ancien sous une condition de couverture :
- Prendre le plus vieux segment non compressé
- Vérifier que chaque fait durable qu'il contient existe comme mémoire structurée autonome
- Si oui -> remplacer le segment par un résumé compact de l'épisode
- Si non -> extraire d'abord, compresser au cycle suivant
La condition compte plus que la qualité du résumeur. Un résumé brillant par-dessus un fait non extrait, c'est une perte de données définitive.
Préserver les ancres temporelles
Les dates relatives se dégradent le plus vite. « Après le voyage à Rabat » devient sans signification quand le voyage lui-même a été compressé. Notre compresseur doit résoudre les ancres relatives en plages absolues (« 2026-03-14 -> 2026-03-20 ») avant de supprimer quoi que ce soit. Cette seule règle a corrigé la majorité de nos échecs de récupération temporelle — le même mode de défaillance que souligne LongMemEval.
Évaluer par questions sondes, pas à l'intuition
Avant de compresser un segment, nous générons des questions sondes répondables depuis son texte brut (« quel budget a-t-elle validé ? »). Après compression, chaque sonde doit rester répondable depuis le magasin conservé. Tout échec bloque le cycle de compression et renvoie le segment vers l'extraction.
La compression cesse d'être un acte de foi pour devenir une opération testée — même philosophie que le contrôle d'écriture : rien ne quitte le système sans preuve qu'on peut le perdre.
Des chiffres, honnêtement
Sur notre jeu interne (~120 sessions compressées) : taux de réussite des sondes de 97,2 % après adoption de la condition + règles d'ancrage, contre 81 % avec un résumé simple. Stockage réduit de ~60 %. Pas un papier de benchmark — mais une méthode reproductible et des chiffres publiés.
FAQ
Pourquoi ne pas simplement résumer l'ancien historique ?
Les résumés préservent le récit mais détruisent les spécificités récupérables. Les utilisateurs demandent « qu'a-t-elle promis exactement ? », pas « de quoi parlait cette discussion ? ». Compressez les épisodes, gardez les faits intacts.
Quand faut-il compresser l'historique ?
Progressivement et du plus ancien, sous condition de couverture structurée : un segment n'est compressible que lorsque chaque fait durable qu'il contient existe comme mémoire structurée autonome.
Comment vérifier que la compression n'a rien perdu ?
Par questions sondes. Avant de compresser un segment, on génère des questions répondables depuis son texte brut ; après compression, elles doivent rester répondables depuis le magasin conservé. Tout échec bloque la compression.