RD-Agent : automatiser la recherche de modèles et de facteurs, pas la réflexion
Research and development (R&D) is crucial for the enhancement of industrial productivity, especially in the AI era, where the core aspects of R&D are mainly focused on data and models. We are committed to automating these high-value generic R&D processes through R&D-Agent, which lets AI drive data-driven AI. 🔗https://aka.ms/RD-Agent-Tech-Report
En bref
- De quoi s’agit-il ?
- Microsoft publie sous licence MIT un cadre Python qui boucle entre proposition, codage et expérimentation sur des scénarios de data science et de finance quantitative. La promesse est claire, le périmètre l'est moins.
- À qui s’adresse-t-il ?
- RD-Agent s'adresse aux équipes qui disposent déjà d'une infrastructure d'exécution et d'un budget de tokens, et qui veulent industrialiser une boucle d'expérimentation répétitive plutôt que la coder à la main. Il ne convient pas à qui cherche un outil de décision sans GPU ni clé d'API, ni à qui doit faire tourner un scénario non listé : la documentation signale elle-même que le scénario data_science est exclu du serveur web rdagent server_ui.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- 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 visé : la boucle, pas le modèle
Le README décrit l'objectif en une phrase : automatiser les processus de R&D à forte valeur générique, en laissant l'IA piloter une IA fondée sur les données. Autrement dit, le projet ne cherche pas à produire un meilleur modèle de langage. Il cherche à remplacer la partie répétitive du travail de recherche appliquée : formuler une hypothèse, écrire le code qui la teste, lancer l'expérience, lire le résultat, recommencer. Le public visé est donc précis. Ce sont des équipes qui ont déjà des données, une métrique d'évaluation et une capacité de calcul, et pour qui le goulot d'étranglement est le nombre d'itérations par semaine, pas l'idée initiale. Le dépôt couvre deux familles de scénarios, la data science et la finance quantitative, et le README renvoie à des travaux distincts pour chacune, dont R&D-Agent-Quant accepté à NeurIPS 2025. Cette séparation est un signal : le cadre n'est pas un agent généraliste, il est instancié par domaine, chaque domaine apportant ses propres contraintes de validation.
Ce que la boucle exécute concrètement
Les éléments fournis décrivent une architecture en scénarios plutôt qu'un pipeline unique. Le dépôt expose un répertoire rdagent/scenarios, et la documentation mentionne des pages dédiées pour le scénario data_science et pour un Kaggle Agent. Un scénario, dans cette organisation, regroupe ce qui est propre au domaine : la façon de représenter une hypothèse, le code généré, et le critère qui décide si l'expérience est conservée. Le README cite aussi un scénario distinct pour l'ingénierie du post-entraînement RL, avec un banc d'essai Agent² RL-Bench qui couvre l'optimisation statique et le RL en ligne avec état. Le point à retenir est que la boucle n'est pas décrite dans le README comme un algorithme unique mais comme un cadre que chaque scénario remplit. Cela a une conséquence pratique : la qualité du résultat dépend moins du cadre que du scénario choisi et de la métrique qu'il optimise. Si votre métrique est mal spécifiée ou facile à satisfaire artificiellement, l'agent optimisera la mauvaise chose avec une régularité parfaite.
Installation et clés de configuration
Le paquet est publié sur PyPI sous le nom rdagent, la plateforme annoncée étant Linux. La documentation de référence se trouve sur rdagent.readthedocs.io. Le README indique que LiteLLM est désormais le backend par défaut pour l'intégration avec plusieurs fournisseurs de modèles, ce qui signifie que la configuration des accès passe par les variables d'environnement attendues par LiteLLM et non par un fichier propre au projet. Le README ne détaille pas ces variables dans l'extrait disponible, il faut donc se référer à la documentation pour les noms exacts. Deux points d'entrée sont nommés explicitement : rdagent server_ui, qui construit et sert une interface web pour l'interaction en temps réel et la consultation des traces, et les guides par scénario, par exemple rdagent/app/finetune/llm/README.md pour le fine-tuning de LLM. Le README précise que l'interface web exclut pour l'instant le scénario data_science. C'est une information de périmètre, pas un détail cosmétique : si votre travail porte sur la data science générale, vous n'aurez pas l'interface de suivi.
Le classement MLE-bench et ce qu'il ne dit pas
Le README met en avant une position de tête sur MLE-bench, un banc d'essai construit sur des jeux de données issus de 75 compétitions Kaggle, avec des colonnes Low, Medium, High et All exprimées en pourcentage de médailles. Le tableau attribue à la configuration R&D-Agent o3(R)+GPT-4.1(D) un score global de 30,22 ± 1,5, contre 22,4 ± 1,1 pour la configuration o1-preview et 34,3 en catégorie Low pour AIDE o1-preview. Ces chiffres sont ceux du README et je ne les ai pas reproduits. Trois réserves méritent d'être posées. D'abord, la notation o3(R)+GPT-4.1(D) suggère une répartition des rôles entre un modèle de raisonnement et un modèle de génération, ce qui implique une configuration à deux fournisseurs et un coût par itération supérieur à une configuration mono-modèle. Ensuite, les écarts-types affichés sont larges sur les catégories Medium et High, ce qui rend les comparaisons fines fragiles. Enfin, un score sur des compétitions Kaggle mesure la capacité à optimiser une métrique publique bien définie, pas la capacité à choisir la bonne question de recherche.
Quand le cadre devient le mauvais outil
La limite la plus nette tient au coût d'itération. Une boucle qui génère du code, l'exécute et recommence consomme des appels de modèle et du calcul à chaque tour, et le tableau MLE-bench suggère que la configuration la plus performante en utilise deux. Sur une tâche où une seule expérience coûte plusieurs heures de GPU, le nombre d'itérations qu'un agent peut réellement tenter dans un budget donné est faible, et l'avantage sur une approche manuelle diminue d'autant. Deuxième limite : le projet est structuré par scénarios, et le README ne liste pas de mécanisme pour en ajouter un sans écrire de code. Si votre domaine n'est ni la data science, ni Kaggle, ni la finance quantitative, ni le fine-tuning, ni le RL, vous partez d'une page blanche. Troisième limite, plus discrète : l'interface web annoncée exclut le scénario data_science, ce qui laisse deviner que tous les scénarios ne sont pas au même niveau de finition. Un cadre qui expose plusieurs scénarios expose aussi leurs écarts de maturité.
Face à un agent de codage généraliste
L'alternative la plus évidente n'est pas un autre agent de R&D, c'est un agent de codage généraliste piloté à la main, du type de ceux qui écrivent et exécutent du code dans un terminal. La différence d'approche est structurelle. Un agent généraliste reçoit une instruction à chaque tour et ne conserve aucune notion de ce qu'est une bonne expérience dans votre domaine. RD-Agent, lui, place la boucle d'expérimentation dans le cadre : le scénario définit ce qu'on propose, ce qu'on exécute et ce qu'on garde, et l'agent itère à l'intérieur de cette structure sans qu'on le relance. Le compromis est symétrique. L'agent généraliste s'adapte à n'importe quelle tâche mais ne progresse pas seul entre deux sessions. RD-Agent progresse seul mais uniquement dans les scénarios prévus, et il faut accepter sa métrique et son format d'hypothèse. Le choix se fait donc sur une question simple : votre travail est-il assez répétitif pour justifier d'écrire un scénario, ou assez varié pour qu'un assistant par tour suffise ?
Licence, versions et coût de suivi
Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Je ne donne pas d'avis juridique : pour un usage en entreprise, la vérification des dépendances, notamment du backend LiteLLM et des fournisseurs de modèles contactés, reste à faire séparément, car la licence du cadre ne couvre pas celles de ses dépendances. Sur le rythme de publication, les releases listées sont v0.8.0 en novembre 2025, v0.7.0 en juillet 2025 et v0.6.1 en juin 2025, avec un dernier push sur la branche main daté de septembre 2026. Le rythme est irrégulier, et un projet de recherche qui publie des articles en parallèle de son code a tendance à faire évoluer ses interfaces entre deux versions mineures. La conséquence pratique est qu'un scénario écrit sur mesure demande un suivi, pas une installation unique. Le coût réel d'adoption se situe moins dans le pip install que dans la maintenance du scénario et dans les appels de modèle que chaque itération consomme.
Conclusion éditoriale
RD-Agent s'adresse aux équipes qui disposent déjà d'une infrastructure d'exécution et d'un budget de tokens, et qui veulent industrialiser une boucle d'expérimentation répétitive plutôt que la coder à la main. Il ne convient pas à qui cherche un outil de décision sans GPU ni clé d'API, ni à qui doit faire tourner un scénario non listé : la documentation signale elle-même que le scénario data_science est exclu du serveur web rdagent server_ui. Avant d'adopter, vérifier trois choses concrètes : le scénario exact que vous visez dans rdagent/scenarios, le backend LLM que vous branchez via LiteLLM, et la version publiée sur PyPI, la dernière release listée étant v0.8.0.
Notes de la communauté