L'équipe ERNIE de Baidu a présenté le 9 novembre, sur son blog technique, le système de recherche automatique ERNIE Evolve. Selon le blog, plusieurs agents s'y répartissent le travail d'une recherche : choisir l'orientation, formuler des hypothèses, modifier le code, lancer les évaluations et vérifier les résultats. L'équipe l'a fait tourner sur quatre tâches d'optimisation publiques, dont trois ont vu les meilleurs résultats existants dépassés ; elle a en outre réalisé trois optimisations sur le déploiement d'inférence de son propre ERNIE-5.5-Flash.
Cinq rôles, deux boucles
Le système se compose d'une boucle externe et d'une boucle interne. Le blog résume ainsi :
« La boucle externe décide quoi rechercher ; la boucle interne s'occupe de bien mener une direction. »
Le Director, dans la boucle externe, choisit dans la base d'expérience et la base de connaissances la prochaine direction à valider et décide du code de départ : le code d'origine, la meilleure version de l'historique, une version intermédiaire ou le dernier commit du dépôt amont. Dans la boucle interne, le Selector choisit à chaque tour une version candidate comme point de départ et rédige l'hypothèse du tour ; il se fonde non seulement sur le score, mais aussi sur les modifications de code, les causes d'échec et les résultats passés. L'Executor modifie le code dans un environnement isolé.
Les deux autres rôles font office de garde-fous. L'Evaluator est placé hors du dépôt optimisé, invisible pour tous les agents, et une amélioration n'est acceptée que si elle dépasse le seuil de bruit ; le Reviewer vérifie que la modification ne s'écarte pas de la direction du tour et que le résultat n'exploite pas une faille de l'évaluation. Une version qui dévie ne peut pas devenir la meilleure, et une version qui exploite une faille est invalidée sur-le-champ. Le défaut le plus courant des systèmes d'optimisation automatique est d'apprendre à flatter le score sans que le code s'améliore réellement ; ces deux verrous visent précisément cela.
Les résultats sur les tâches publiques
| Tâche | Meilleur résultat antérieur | ERNIE Evolve |
|---|---|---|
| NanoChat AutoResearch (BPB sur l'ensemble de validation, plus bas = mieux) | 0,8878 | 0,8763 |
| NanoGPT Speedrun Track 1 (temps d'entraînement pour atteindre l'objectif) | 39,9 secondes | 38,9 secondes |
| NanoGPT Speedrun Track 3 (étapes d'entraînement pour atteindre l'objectif) | 2690 étapes | 2590 étapes |
| SOL-ExecBench (score SOL moyen, plus haut = mieux) | 0,827 | 0,819 |
Sur SOL-ExecBench, le système n'a pas pris la première place, mais il devance Recursive (0,676) et Hyra-1.0 (0,736). Les résultats d'optimisation des tâches publiques sont déposés sur le dépôt GitHub ernie-research/ERNIE-Evolve-Results ; quant à savoir si le système ERNIE Evolve lui-même sera ouvert, le blog n'en dit rien.
Un calcul sur l'optimisation de l'inférence
Sur les tâches industrielles, les chiffres sont plus élevés. Dans le scénario à faible latence du Kunlunxin P800, le système a effectué quatre tours sur quatre directions de recherche, porté la vitesse de génération à 623,6 % de la référence et passé tous les contrôles de justesse. Le blog mentionne une découverte clé : le chemin de communication d'origine n'avait en réalité pas activé la communication à faible latence DeepEP. Dans l'accélération de plus de six fois, la part due à la détection de cette configuration inopérante et celle due aux nouvelles méthodes d'optimisation ne sont pas détaillées par le blog.
Pour l'inférence déterministe, le débit a progressé de 33,7 %, le temps de génération par token a diminué de 26 %, la latence du premier token de 12 %, et le déterminisme est resté intact, en environ 3 jours. Pour le décodage GPU poussé à l'extrême, le système a proposé 7 directions, dont 3 ont apporté une amélioration ; la vitesse de décodage a augmenté de 14,9 % et la précision est identique à la référence.
Un calcul approximatif : avec 33,7 % de débit en plus, la même charge de requêtes nécessite environ 75 % des cartes d'avant (1 ÷ 1,337). Si cette optimisation pouvait être transposée telle quelle sur un cluster en production, l'économie serait d'environ un quart de la puissance de calcul d'inférence. Le nombre d'heures de GPU consommées par chacune des trois tâches n'est pas divulgué par le blog ; pour l'instant, le calcul ne se fait que du côté des gains, le côté des coûts reste vide.
Le blog est très direct sur la difficulté :
« La référence inclut déjà des optimisations dédiées des ingénieurs pour l'inférence déterministe ; les améliorations restantes ne sont souvent que de 1 % – 2 % chacune, comparables aux fluctuations de mesure. »
Plusieurs hypothèses ont été réfutées par les expériences ; par exemple, une seule communication entre cartes est déjà proche de la limite basse de latence, et cette piste s'est arrêtée là.
En fin de billet, l'équipe indique que l'extension de l'auto-amélioration récursive (RSI) doit rester contrôlable et pouvant être mise en pause, et faire l'objet d'évaluations de sécurité et d'une supervision humaine. D'après les tâches divulguées, ERNIE Evolve modifie pour l'instant des scripts d'entraînement et du code d'inférence, et ne touche pas encore au processus d'entraînement du modèle lui-même.
Sources : blog technique ERNIE de Baidu, dépôt open source ERNIE-Evolve-Results, CocoLoop ; recoupement des résultats des quatre tâches publiques et de l'ampleur des trois optimisations d'inférence d'ERNIE-5.5-Flash.