Une mémoire locale contre l'IA oublieuse : Hindsight et ses 94,6 % de récupération longue portée

Une promesse faite au milieu d'une longue conversation tient-elle encore trois cents messages plus tard ? Pour les modèles de langage standard, la réponse est le plus souvent non ; à mesure que la fenêtre grandit, les détails enfouis au milieu s'effacent. Le présentateur apporte un remède nommé mémoire locale apprenante : Hindsight, un système ouvert qui permet à l'assistant de code de tirer les leçons des échanges passés et de devenir plus juste à chaque usage.

Pourquoi les approches classiques plafonnent

L'approche naïve qui remplit la fenêtre de tout le contexte fait gonfler les coûts au fil des échanges et perd le détail critique dans la foule. La génération augmentée par récupération classique stocke les morceaux de texte tels quels, sans suivre les relations, les changements d'hypothèses ni l'obsolescence. La philosophie du dépôt GitHub tranche à cet endroit précis : l'objectif n'est pas de se souvenir de l'historique, mais de faire apprendre l'assistant au fil du temps. Cette distinction répond aussi au vieux débat entre adeptes des graphes de connaissances et partisans de la recherche vectorielle pure.

Les chiffres frappent au premier regard. Sur le volet S de LongMemEval, avec 500 questions, Hindsight adossé à un modèle ouvert de 20 milliards de paramètres annonce 83,6 % de précision globale, tandis que GPT-4o en contexte complet plafonne à 60,2 % sur la même série. Avec une épine dorsale Gemini-3, le score grimpe à 91,4 % au total, avec 94,9 % sur les mises à jour de connaissances et 91,0 % sur le raisonnement temporel. Le tableau de bord Vectorize met en avant 94,6 % de récupération longue portée, et les notes GitHub précisent que le tableau principal a été reproduit de façon indépendante avec le centre Sanghani de Virginia Tech.

À l'intérieur du moteur : une mémoire à quatre couches

Au lieu d'entasser une pile d'échanges dispersés dans un seul fichier texte, le système répartit le savoir dans quatre réserves spécialisées. La première garde les faits durables sur l'utilisateur, les dates et l'espace de travail ; la seconde tient un journal d'activité qui consigne les tâches accomplies avec les outils employés et leurs résultats. La troisième suit les hypothèses de travail qui évoluent avec les besoins, et la quatrième conserve des pages de mémoire ordonnées rédigées discrètement en arrière-plan. Les notes d'architecture DeepWiki montrent comment ces couches reposent sur Postgres avec des index pgvector, tandis que l'examen de l'Agent Memory Atlas explique la séparation entre documents bruts et faits du monde, faits d'expérience, observations et réflexions.

Retrouver un souvenir passe par le dispositif TEMPR, dont quatre bras courent en parallèle. La recherche sémantique apparie des mots différents au sens identique, le balayage exact des mots-clés capture les chaînes précises comme les noms de fonctions et les codes d'erreur, le graphe de relations suit les liens entre personnes, outils et sujets pour réunir le contexte manqué par la recherche plate, et le filtre temporel écarte les entrées périmées pour se concentrer sur les apprentissages récents. La documentation Vectorize sur la récupération explique que rien n'est décidé à l'avance sur le bras adapté à une requête ; tous les bras pertinents s'exécutent, puis un réordonnancement affine les résultats.

Le récit des coûts est l'affirmation la plus audacieuse du projet. Comme les recherches en mémoire s'exécutent sur l'appareil, chaque requête évite la facture infonuagique, et le serveur autorise le passage entre une vingtaine de fournisseurs de modèles sans reconstruire la base. La bibliothèque Python tient en quelques centaines de mégaoctets de mémoire vive, de quoi cohabiter avec un éditeur sur un portable ordinaire. Les guides Docker et client sur GitHub décrivent une installation qui démarre dans un conteneur unique avec Postgres embarqué et peut se brancher à des modèles entièrement locaux via Ollama.

Installation et première banque

Le récit d'installation reste volontairement simple : ouvrir un environnement virtuel, installer le client avec pip, au choix déposer une clé Gemini dans le fichier d'environnement ou prendre le chemin du modèle local. Le client parle trois verbes ; retain écrit le savoir, recall cherche les souvenirs et reflect produit une réponse adaptée à partir du savoir accumulé d'une banque. Chaque banque porte sa propre configuration, les points multi-locataires se séparent par identité de banque, et un habillage de deux lignes branche la mémoire sur un assistant existant. L'exemple Python sur GitHub montre ces trois appels montés en quelques lignes autour du cas Alice.

Le moment le plus vivant de la démonstration ingère un dossier produit fictif nommé Pulse Grid. Le dossier concentre des faits comme une accélération de base sans réécriture, 14 grands clients, 4 milliards de requêtes par jour, une facture serveurs de 38 000 dollars par mois, trois grands clients dont les contrats se terminent le mois prochain et un pic de latence d'une demi-seconde sous forte charge. L'assistant extrait d'abord ces faits dans une banque de mémoire, puis fait passer le même jeu de faits à travers trois filtres de personnalité. Les résultats atterrissent à la fois dans un fichier Markdown et un tableau HTML sobre qui juxtapose les profils.

Kyra : trois personas, trois verdicts

Le système de personnalité Kyra règle le rapport aux preuves sur trois axes. Le profil investisseur pousse la suspicion au maximum, rabat la chaleur émotionnelle au plancher et interroge comme un vice-président sans pitié : si l'essentiel du revenu repose sur trois contrats qui s'achèvent le mois prochain, combien de temps la trésorerie tient-elle ? Le profil d'ingénieur senior maximise l'adhésion littérale aux règles et réfute le discours de réplication quasi instantanée avec la mesure d'une demi-seconde. Le profil de soutien atténue le doute, relève la chaleur et souligne qu'une accélération sans réécriture est un vrai soulagement pour des développeurs fatigués. Une même mémoire rend trois verdicts cohérents mais distincts, en trois tempéraments.

La traduction vers le travail quotidien est rapide : repérer tôt le risque d'épuisement de trésorerie dans les dossiers de jeunes pousses, collecter les signaux d'alerte avant les résiliations, passer au crible des milliers de notes de projet sans payer chaque requête, et filtrer clés secrètes et données personnelles des textes entrants avant toute écriture en mémoire. Le présentateur insiste sur ce dernier point ; les chaînes dangereuses sont écartées avant inscription. Trois verbes et des axes de personnalité composent non pas un robot conversationnel unique, mais une infrastructure de mémoire reconfigurable par rôle.

Les contreparties sont elles aussi comptées franchement. La première installation télécharge quelques centaines de mégaoctets de poids de modèle, et chaque morceau de texte écrit en mémoire déclenche un appel de modèle sur le chemin d'ajout ; les utilisateurs infonuagiques ont donc intérêt à grouper les morceaux. Plutôt que d'évincer l'ancien savoir au hasard, le système affine le savoir existant avec soin, si bien que les consignes du milieu de session restent aussi nettes que les derniers messages. L'article de l'ACL sur aclanthology donne à ce trio conservation, récupération et réflexion un cadre formel, et l'inventaire des composants sur DeepWiki montre ce qui tourne où en production, des interfaces HTTP et MCP jusqu'aux schémas Postgres.