Librarian Agents : des LLM préparent l'espace de travail à l'avance et gagnent 33 points de pourcentage sur BrowseComp-Plus

Des chercheurs présentent Librarian Agents, un framework dans lequel un agent LLM restructure à l'avance un ensemble de documents non structurés en système de fichiers hiérarchique, qu'un second agent exploite ensuite pour répondre. Sur BrowseComp-Plus, la méthode surpasse de 33 points de pourcentage les meilleures solutions de référence fondées sur le retrieval et le precompute. Sur le benchmark BRIGHT, sur des domaines que le modèle n'a pas vus à l'entraînement, le gain moyen de justesse atteint 31 points, sans fine-tuning spécifique à la tâche.

Le problème de départ est familier à quiconque a construit des agents au-dessus de grands corpus. Le retrieval classique est réactif : la requête arrive, le système extrait des fragments, le modèle tente d'en tirer une réponse. Lorsqu'il faut relier des faits issus de plusieurs documents, c'est précisément cette étape qui devient le goulot d'étranglement. Les structures précalculées, comme les graphes de connaissances, n'aident que partiellement : elles reposent sur des heuristiques rigides, qui ignorent quelles questions seront posées par la suite.

L'asymétrie sur laquelle repose l'idée

Les auteurs partent d'un constat sur les environnements agentiques actuels, Claude Code par exemple. Ces agents se repèrent bien dans un système de fichiers existant : ils ouvrent des fichiers, suivent des liens, rassemblent le contexte nécessaire à la tâche en cours. Mais presque personne ne leur apprend l'inverse, c'est-à-dire à créer l'espace de travail qui sera utilisé ensuite.

Librarian Agents comble cette lacune. L'agent bâtisseur reçoit les documents bruts et produit une hiérarchie de fichiers synthétiques reliés entre eux par des liens. Cet espace de travail est ensuite confié à l'agent répondeur. La construction est formulée comme un processus de décision markovien, et la politique du bâtisseur est optimisée par apprentissage par renforcement. La récompense est directement liée à la justesse finale des réponses de l'agent downstream, et non à des métriques intermédiaires comme la qualité de la recherche.

Ce que montrent les expériences

D'après le résumé de l'article, les résultats se présentent ainsi :

• BrowseComp-Plus : +33 points de pourcentage par rapport aux meilleures solutions de référence en retrieval et en precompute.
• BRIGHT : gain moyen de justesse de 31 points en zero-shot, sur des domaines inconnus.
• Le coût de construction de l'espace de travail est amorti lorsque les requêtes sur un même corpus se répètent.
• Ce qui est entraîné : la politique du bâtisseur, et non l'agent répondeur.

C'est la transférabilité qui compte ici. Si le bâtisseur s'était contenté d'apprendre par cœur la structure de jeux de données précis, il aurait échoué sur BRIGHT. Un gain à deux chiffres sur de nouveaux domaines indique que l'entraînement par RL a fait émerger des pratiques générales d'organisation des connaissances : comment regrouper, quoi placer dans des fichiers de synthèse, où poser des liens croisés.

Le travail comporte aussi des inconnues. Le résumé ne donne ni la taille des modèles, ni le coût absolu de construction, ni le comportement de l'espace de travail lorsque le corpus est mis à jour fréquemment. Ces points sont à chercher dans le texte intégral de l'article.

Que tester pour les équipes qui construisent des agents

La conclusion pratique touche à l'architecture. Si le corpus est relativement stable et que les requêtes se répètent (base de connaissances interne, documentation produit, archive de recherches), préparer l'espace à l'avance est plus rentable que de chercher à chaque fois de zéro. Le coût de construction se divise par le nombre de requêtes : plus elles sont nombreuses, meilleure est l'économie.

Deuxième point : évaluez la préparation du corpus à l'aune de la justesse finale des réponses. C'est la récompense utilisée dans l'article, et elle écarte les structures élégantes mais inutiles. Troisième point : testez sur des domaines mis de côté, faute de quoi il est facile de confondre l'ajustement à ses propres données avec une réelle qualité. Pour les corpus qui changent vite, calculez d'abord le coût d'une reconstruction, car dans ce scénario le gain est moins évident.