Si l'on veut améliorer un profil d'aile, que signifie au juste « mieux » ?
L'efficacité en croisière mérite d'être accrue, les contraintes de conception doivent être respectées, et chaque évaluation de haute précision consomme du budget de calcul. Un candidat peut être meilleur sur un critère tandis qu'un autre préserve une plus grande marge de manœuvre. Les aligner en une seule liste et désigner le premier n'a rien d'aussi direct qu'on l'imagine.
L'IA peut participer à proposer de nouvelles solutions et à écrire le code des expériences. Se pose ensuite la question de l'évaluation, de la comparaison et de la poursuite de l'exploration.
Le cours AI999 d'EvoClass, « Système d'évolution intelligente EvoX et pratiques de recherche AI Native », suit ce fil : du calcul évolutionnaire vers les problèmes multi-objectifs, puis les socles de calcul modernes, l'évolution des méthodes, et enfin les pratiques de recherche en environnement AI Native. Son intérêt porte sur la manière dont une proposition entre dans l'expérience, et dont le retour modifie la proposition suivante.
Commençons par préciser quelles améliorations méritent d'être conservées
La leçon 3, « Complexité du monde réel et compromis multi-objectifs », aborde, à partir de situations comme la conception de profils d'aile, les relations entre objectifs, contraintes et coût d'évaluation.
Certains indicateurs doivent être élevés autant que possible, tandis que certaines conditions doivent impérativement atteindre un seuil. Il faut d'abord distinguer ces deux types d'exigences pour que la comparaison ait une base.
Face à un ensemble de candidats, si une solution est globalement en retrait sur les indicateurs qui nous intéressent, il y a lieu de l'écarter ; si plusieurs solutions présentent chacune des gains et des coûts, conserver ces différences permet au contraire de rendre les arbitrages ultérieurs plus clairs. Les experts du domaine peuvent, en tenant compte des conditions d'exploitation et des préférences, décider quelles directions méritent d'être poursuivies.
Cela invite aussi le chercheur à examiner sa propre façon d'évaluer. Comment un score total est-il calculé ? Pourquoi les pondérations sont-elles fixées ainsi ? Des contraintes non inscrites au départ ne risquent-elles pas de rendre inutilisable une solution bien notée ?
Ces questions demandent une réponse dans la conception de l'expérience. Sinon, la recherche peut progresser le long du score tout en s'éloignant peu à peu de la tâche réellement visée.
Les candidats se multiplient : où dépenser le budget d'évaluation ?
Conserver plusieurs possibilités entraîne de nouveaux coûts.
La leçon 3 aborde également les modèles substituts : apprendre, à partir des échantillons existants, la relation entre paramètres des candidats et performances, utiliser des prédictions peu coûteuses pour aider à la sélection, puis envoyer les candidats méritant un examen approfondi vers une évaluation de plus haute précision, et réutiliser les résultats pour les mises à jour ultérieures.
Il s'agit ici de distinguer le poids des différents types de preuves. La prédiction du modèle substitut comporte une erreur, et une vérification est particulièrement nécessaire lorsque la recherche s'aventure dans des régions peu explorées. Un score prédit apparemment élevé doit encore être soumis à un examen plus poussé.
Une autre part du coût provient de l'organisation du calcul. La leçon 4, « Socles de calcul modernes et évolution parallèle tensorisée », examine comment organiser population, résultats d'évaluation et états sous forme de tenseurs afin de faire avancer le calcul par lots.
On peut le comprendre ainsi : ranger les paramètres de nombreux candidats selon une structure homogène, de sorte que les opérations exécutables par lots les traitent ensemble. La documentation d'EvoX sur le développement de problèmes personnalisés illustre aussi cette organisation à travers une interface d'évaluation qui reçoit un lot de candidats et renvoie les valeurs d'objectif correspondantes.
Le gain réel reste à mesurer : le temps est-il consacré à la génération de candidats, à la fonction objectif, ou au déplacement des données ? Des lots plus grands mobilisent-ils trop de mémoire graphique ? C'est en consignant séparément ces coûts que l'on sait où intervenir ensuite.
L'évaluation assistée par modèle substitut et le parallélisme par lots traitent respectivement le coût de l'évaluation et l'organisation du calcul. Comprendre leur répartition des rôles aide davantage que d'attendre vaguement qu'« en lancer davantage donnera de meilleurs résultats ».
Quand la recherche stagne, on peut aussi examiner la méthode qui produit les candidats
Après davantage d'itérations, si les résultats ne s'améliorent pas nettement, ce n'est pas seulement le candidat lui-même qu'il vaut la peine d'examiner.
Comment la mutation se produit-elle ? Comment les paramètres sont-ils réglés ? La manière de chercher actuelle convient-elle à ce problème ?
La leçon 5, « Évolution des méthodes : de l'optimisation de solutions à l'optimisation de l'algorithme lui-même », s'appuie sur des travaux comme MetaDE et AutoPSO pour intégrer à la discussion la méthode qui produit les candidats.
Prenons MetaDE : la boucle interne d'évolution différentielle résout le problème objectif, tandis que la boucle externe recherche, selon les performances de résolution, des stratégies et des configurations de paramètres. Ainsi, outre la comparaison des « solutions obtenues », on peut comparer « la manière de chercher des solutions ».
Ce changement de niveau a lui aussi un coût. Lorsque l'on compare des méthodes, le nombre d'évaluations consommées par les boucles interne et externe et le temps d'exécution mobilisé doivent être comptabilisés dans le budget ; les conclusions doivent aussi être replacées dans le contexte des problèmes et conditions testés.
Pour l'apprenant, un exercice possible consiste à établir d'abord une base de référence claire, puis à modifier une seule stratégie, à conserver la configuration et les résultats complets, et à répéter les exécutions. Ainsi, les variations de performance peuvent espérer être expliquées, et il devient plus facile de repérer les modifications qui ne brillent que lors d'une seule exécution.
Une fois le code écrit, que doit laisser la recherche ?
Quand l'IA peut participer à la mise en œuvre de davantage d'expériences, les jugements que le chercheur doit porter ne diminuent pas pour autant.
La discussion de la leçon 6 sur Genesis et l'évolution continue des logiciels porte l'attention sur le projet : comment décomposer les tâches, comment vérifier les modifications de code, comment intégrer les résultats valides à la base du travail ultérieur. La présentation officielle du projet de Genesis organise elle aussi construction, validation et poursuite du développement dans un même parcours de travail.
Toutefois, les conclusions que soutiennent une compilation et des tests réussis doivent être distinguées des conclusions scientifiques. Ils peuvent montrer que le programme satisfait aux exigences déjà vérifiées ; l'efficacité supérieure d'une méthode dépend encore de la formulation du problème, des expériences de contrôle, des indicateurs d'évaluation et de l'analyse des résultats.
La leçon 7, « Paradigme de recherche AI Native et entrée en pratique avec EvoX », ramène cette responsabilité au chercheur : poser la question, définir l'évaluation, juger la direction et critiquer les résultats existants.
Le « goût de la recherche » peut ainsi devenir concret. Choisit-on tel problème parce qu'il est important, ou parce qu'il donne facilement de beaux résultats ? L'évaluation permet-elle de tester sa propre thèse ? Le prochain chercheur, disposant du code, de la description de l'environnement, des paramètres et des journaux d'exécution, pourra-t-il revérifier cette expérience ?
Si vous avez déjà commencé à écrire du code d'expérience avec l'aide de l'IA, vous pouvez partir d'un petit problème que vous êtes capable de vérifier : écrire d'abord objectifs et contraintes, fixer budget et base de référence, puis exécuter, comparer, consigner, et décider ce que l'on conserve pour la prochaine itération. L'aperçu du cours AI999 d'EvoClass offre un point d'entrée pour poursuivre l'apprentissage sur cette voie.
Pour revenir à l'ensemble initial de candidats de profils d'aile, le fruit de la recherche est peut-être provisoirement un ensemble d'arbitrages argumentés : quelles solutions méritent d'être conservées, lesquelles demandent une évaluation complémentaire, quelles directions ne valent plus la peine d'être poursuivies.
Lorsque ces jugements et ces preuves peuvent être repris par l'expérience suivante, une solution encore imparfaite dispose d'un point de départ pour continuer à s'améliorer.
La présentation du cours s'appuie sur les documents actuels d'EvoClass AI999 ; le contexte technique se réfère par ailleurs aux ressources officielles des projets cités en lien. La discussion sur les profils d'aile sert à illustrer les relations entre objectifs et contraintes ; les dispositions expérimentales mentionnées sont des suggestions d'apprentissage et non une évaluation de performance réalisée dans cet article. Les liens vers les leçons renvoient à des supports d'apprentissage en chinois simplifié.