OpenResearcher : un pipeline ouvert pour fabriquer des trajectoires de deep research
OpenResearcher: A Fully Open Pipeline for Long-Horizon Deep Research Trajectory Synthesis
En bref
- De quoi s’agit-il ?
- Le dépôt TIGER-AI-Lab/OpenResearcher publie un jeu de données de 96K trajectoires, un modèle 30B-A3B entraîné dessus et un cadre d'évaluation léger. La recette est complète, mais elle suppose une infrastructure de recherche locale que le README ne détaille pas.
- À qui s’adresse-t-il ?
- OpenResearcher convient aux équipes qui veulent entraîner ou évaluer un agent de recherche long avec un corpus local et sans dépendre d'une API de recherche externe. Il ne convient pas à qui cherche un produit clé en main : le dépôt fournit une recette, pas un service.
- Puis-je l’utiliser commercialement ?
- Pas sans autorisation. GitHub ne trouve aucun fichier de licence dans ce dépôt, et sans licence tous les droits sont réservés par défaut : vous pouvez lire le code, mais pas le réutiliser. Consultez le README ou demandez l’accord des auteurs avant de l’utiliser.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 97 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : produire des trajectoires longues sans API de recherche
Entraîner un agent capable de mener une recherche documentaire sur plus de cent tours suppose de disposer de trajectoires annotées. Le README décrit un jeu de données de 96K trajectoires DeepResearch, générées par GPT-OSS-120B avec des outils de navigation natifs, et précise que certaines dépassent 100 tours. C'est ce volume et cette longueur qui distinguent le projet d'un simple jeu de questions-réponses.
La cible est double. D'un côté, des équipes qui entraînent des modèles de recherche et ont besoin de données de distillation. De l'autre, des équipes qui évaluent des agents existants sur BrowseComp-Plus, BrowseComp, GAIA ou xbench-DeepSearch. Le README revendique 54,8 % sur BrowseComp-Plus pour le modèle 30B-A3B publié, en comparaison de GPT-4.1, Claude-Opus-4, Gemini-2.5-Pro, DeepSeek-R1 et Tongyi-DeepResearch. Ces chiffres proviennent du projet lui-même et n'ont pas été reproduits ici.
Deux modes d'exécution : moteur local ou Serper
Le README distingue deux chemins. Le premier, illustré par l'exemple BrowseComp-Plus, s'appuie sur un moteur de recherche local construit au-dessus d'un corpus dédié d'environ 11B tokens, publié sous le nom OpenResearcher-Corpus. Le second, illustré par l'exemple GAIA, passe par l'API Serper et se dispense de moteur local. Le choix n'est pas cosmétique : le mode local supprime la dépendance à une API externe et rend la génération de trajectoires reproductible, au prix d'un stockage et d'une indexation à votre charge. Le mode Serper déplace ce coût vers un service tiers et une clé d'API.
Le README présente l'absence d'API de recherche externe comme un levier de réduction des coûts d'entraînement à grande échelle. C'est plausible pour la génération massive, mais l'argument ne dit rien du coût d'exploitation du corpus lui-même. Le dépôt ne documente pas, dans le matériel fourni, la procédure de construction de l'index ni le temps de mise en place.
Installation et configuration : ce que le dépôt expose
Le README organise la prise en main en quatre blocs : Environment Setup (avec Installation et Deep Research Benchmarks Preparation), Configuration, Quick Start, puis Benchmark OpenResearcher. Les commandes exactes d'installation ne figurent pas dans l'extrait fourni ; il faut se reporter au dépôt pour les obtenir. Ce que l'on peut affirmer, c'est la présence d'une section Configuration distincte, ce qui suggère des clés à renseigner avant de lancer un benchmark.
Les deux exemples nommés dans la table des matières encadrent bien les cas d'usage : Example 1, BrowseComp-Plus with Local Search Engine, et Example 2, GAIA with Serper API (No Local Search Needed). Le second indique explicitement qu'aucune recherche locale n'est requise, ce qui laisse penser que la configuration Serper se limite à une clé d'API. Le premier suppose le corpus en place. Une section Evaluation et une section Quick Commands complètent l'ensemble. Le README mentionne aussi une section optionnelle, Train Your Own OpenResearcher, ajoutée en février 2026.
Le corpus local est le vrai point de friction
Un corpus d'environ 11B tokens n'est pas un détail d'installation. Le README ne précise ni le format des fichiers, ni la taille compressée, ni le moteur d'indexation attendu, ni la mémoire nécessaire. Il indique seulement qu'il s'agit d'un corpus dédié et que le retriever est auto-construit. Pour une équipe qui veut reproduire le pipeline complet, c'est l'inconnue principale : le téléchargement et l'indexation peuvent représenter l'essentiel du temps de mise en route, bien avant le premier appel au modèle.
C'est aussi la limite de pertinence du projet. Si votre besoin est d'évaluer un agent sur quelques dizaines de questions avec une API de recherche, l'exemple GAIA avec Serper suffit et le corpus local devient un coût inutile. Si votre besoin est de générer des trajectoires à grande échelle de façon reproductible, le corpus devient au contraire l'élément central. Le même dépôt sert deux profils que tout oppose sur le plan matériel.
Ce que le dépôt ne dit pas
La licence n'est pas renseignée dans le matériel fourni. Le README ne comporte pas de section licence visible dans l'extrait, et aucune release n'a été récupérée. Avant tout usage en production ou toute redistribution d'un modèle entraîné sur le jeu de données, il faut consulter le fichier de licence du dépôt et les conditions associées aux ressources HuggingFace (OpenResearcher-Dataset, OpenResearcher-30B-A3B, OpenResearcher-Corpus). Ces conditions peuvent différer d'un artefact à l'autre.
Le coût de maintenance est difficile à estimer. Le dépôt est actif (dernier push en juin 2026, pas d'archivage), mais sans release taguée, le suivi des changements repose sur l'historique Git. Les journaux d'évaluation sont publiés séparément sur HuggingFace (OpenResearcher-Eval-Logs), ce qui aide à vérifier les chiffres annoncés sans relancer l'évaluation soi-même. C'est un point appréciable, et rare.
Face à un framework d'agent générique
Un framework d'agent générique, du type de ceux qui orchestrent des appels d'outils autour d'un LLM, laisse à l'utilisateur le soin de constituer ses données d'entraînement. OpenResearcher prend le problème par l'autre bout : il fournit les trajectoires, le modèle entraîné dessus et le cadre d'évaluation, avec un corpus de recherche intégré. La différence n'est pas dans l'API mais dans ce qui est livré : ici, la donnée et le modèle distillable ; là, l'orchestration.
Le revers est la rigidité. Un framework générique s'adapte à n'importe quelle source documentaire. OpenResearcher est calibré sur son corpus et sur des benchmarks de recherche nommés. Le README indique que les données ont été adoptées par la famille Nemotron de NVIDIA et par NeMo Data Designer, ce qui suggère une intégration possible dans des chaînes existantes, mais le dépôt ne documente pas cette intégration dans l'extrait fourni.
Qui doit adopter, qui doit passer
Adoptez OpenResearcher si vous entraînez un modèle de recherche long et cherchez des trajectoires de plus de 100 tours avec une recette de distillation publiée. Adoptez-le aussi si vous voulez évaluer un agent sur BrowseComp-Plus, BrowseComp, GAIA ou xbench-DeepSearch avec un cadre léger, en acceptant de fournir soit le corpus local, soit une clé Serper.
Passez votre chemin si vous cherchez un service de recherche clé en main, ou si votre contrainte matérielle interdit de stocker et d'indexer un corpus de 11B tokens. Passez également si vous avez besoin d'une licence clairement identifiée avant tout engagement : ce point n'est pas résolu par le matériel fourni.
La première vérification à faire est concrète : ouvrir la section Installation du dépôt et confirmer le mode de récupération du corpus OpenResearcher-Corpus, puis comparer l'espace disque requis avec celui de votre machine. La seconde est de lire le fichier de licence. Tant que ces deux points ne sont pas tranchés, le reste de la recette reste théorique.
Conclusion éditoriale
OpenResearcher convient aux équipes qui veulent entraîner ou évaluer un agent de recherche long avec un corpus local et sans dépendre d'une API de recherche externe. Il ne convient pas à qui cherche un produit clé en main : le dépôt fournit une recette, pas un service. Avant de vous engager, vérifiez deux points précis : la licence du dépôt, absente du matériel fourni, et le coût de stockage du corpus OpenResearcher-Corpus, dont le README annonce environ 11B tokens sans en préciser le format ni la taille sur disque.
Notes de la communauté