Comment apprendre aux agents LLM à mémoriser le contexte et à reproduire des articles scientifiques

Récemment, je suis tombé sur le benchmark PaperGuru, dans lequel les auteurs ont décidé de s'attaquer à un problème désagréable des agents autonomes. Les fenêtres de contexte des modèles modernes ont atteint un million de tokens. Pourtant, les tâches sur plusieurs jours où un agent doit explorer des dépôts, lire des dizaines d'articles et écrire du code fonctionnel échouent toujours.

Généralement, tout se résume à la mémoire. Les bases de données vectorielles trouvent des fragments de texte par similarité cosinus, mais passent complètement à côté des relations dans le temps. Si un article a été mis à jour ou si une bibliothèque est devenue obsolète, un RAG standard mélangera joyeusement un fragment obsolète dans le prompt. Dans le dépôt PaperGuru-Benchmark, les chercheurs de l'équipe AutoTrustAI ont publié une architecture de mémoire à long terme avec conscience du cycle de vie des données (Lifecycle-Aware Memory, ou LAM), ainsi que les résultats de tests sur des benchmarks complexes.

Quel est le problème du RAG standard ?

Lorsqu'un agent rédige une grande revue de littérature ou reproduit du code à partir d'un article PDF, la recherche par embedding plat trébuche sur des choses basiques.

Premièrement, les informations deviennent obsolètes. Si une méthode a été réfutée dans un article plus récent, une base de données plate n'en sait rien.

Deuxièmement, les preuves nécessaires se trouvent souvent non pas dans le fragment qui ressemble à la requête par mots-clés, mais à deux liens de distance dans le graphe de citations.

Troisièmement, à mesure que les archives grandissent, les coûts de recherche augmentent et l'agent commence à se noyer dans le bruit.

Les auteurs ont formulé quatre règles pour travailler avec la mémoire :

1. Gestion de version du contenu. Le système suit les modifications, les dépréciations et les retraits d'articles.
2. Pertinence structurelle à plusieurs sauts. La recherche traverse le graphe de relations, pas seulement la similarité vectorielle.
3. Coût de requête borné avec une croissance infinie des archives.
4. Traçabilité des preuves. Chaque affirmation de l'agent est liée à une source spécifique.

Architecture Capital Chunk Memory

Au lieu de découpe le texte en fragments uniformes et de les verser dans Chroma ou Pinecone, l'architecture PaperGuru divise la mémoire en deux couches. La première couche s'appelle les chunk heads. Ce sont des en-têtes compacts avec des métadonnées pour chaque artefact, utilisés pour un routage rapide. La deuxième couche, les chunk contents, stocke le texte brut et est chargée de manière paresseuse uniquement lorsque cela est réellement nécessaire.

Le routeur s'appuie sur un graphe d'artefacts temporel. Le graphe contient deux types de relations : structurelles (par exemple, cites, implements, benchmarked-on) et causales (deprecated-by, retracted-by, superseded-by).

Le pipeline de génération se compose de quatre étapes :

• Recherche : recherche rapide des en-têtes d'artefacts correspondants dans les archives.
• Extraction : extraction des fragments nécessaires et assemblage de soi-disant cartes de preuves.
• Raisonnement : un cycle de génération et de critique où le modèle rédige et vérifie la logique.
• Vérification : validation finale avec vérification des références sources.

Ce que montrent les tests

Les auteurs ont testé le système sur deux benchmarks difficiles : PaperBench d'OpenAI et SurveyBench.

PaperBench évalue la capacité d'un modèle à prendre un PDF d'article ML et à écrire un dépôt fonctionnel avec reproduction d'expériences. La référence humaine (un doctorant ML avec un budget de 48 heures) est de 41%.

PaperGuru a montré un résultat moyen de 66,05% sur 23 articles, battant toutes les solutions de référence publiées. Le meilleur résultat précédent d'autres agents était de 35,74%.

Sur 19 articles sur 20 avec des références connues, la nouvelle architecture mémoire a montré une amélioration significative. Par exemple, pour reproduire l'article sur le classifier-free guidance, le résultat a augmenté de 68%. La seule baisse s'est produite sur la tâche PINN (-4,47%), où la référence d'origine utilisait des heuristiques manuelles spécifiques au domaine.

Sur SurveyBench, qui évalue la qualité de rédaction de grandes revues scientifiques, le système a obtenu 94,66% sur la qualité du contenu sous un juge basé sur Claude Opus.

Il vaut la peine de regarder la métrique Richness. Elle ne compte pas les évaluations subjectives des modèles de langage, mais la présence réelle de graphes compilés, de tableaux, de code fonctionnel et de citations correctes dans le matériel généré.

Ici, PaperGuru a obtenu 43,76%, tandis que la moitié des approches concurrentes ont obtenu zéro, générant du texte brut sans structure.

Ce qu'il y a dans le dépôt

Le dépôt fait environ 350 Mo et contient beaucoup de matériaux pratiques :

• Infrastructure de benchmark complète avec des pipelines d'évaluation reproductibles
• Embeddings pré-calculés et structures de graphe pour tous les articles du benchmark
• Implémentations de référence des composants de l'architecture LAM
• Scripts d'évaluation et outils de visualisation
• Soumissions prêtes à l'emploi pour les 23 articles PaperBench

Tous les graphes du README peuvent être reconstruits localement. Le dossier assets/figures/ contient un fichier data.json avec toutes les métriques et un script de construction :

python scripts/rebuild_graphs.py

Qui devrait étudier ce projet

Si vous construisez des systèmes d'agents qui travaillent avec de grandes bases de code ou une documentation technique complexe, ce dépôt offre d'excellentes pistes de réflexion. L'idée de diviser la mémoire en en-têtes légers et un graphe de relations causales se transfère facilement aux bases de connaissances d'entreprise.

Les soumissions prêtes à l'emploi dans le dossier PaperBench/submissions/ seront utiles pour ceux qui testent leurs propres pipelines de génération de code à partir d'articles. Vous pouvez y voir comment structurer la reproduction de pipelines ML complexes, lorsque le modèle doit produire non pas un seul script, mais un arbre de projet fonctionnel avec des dépendances et des tests.