Évolution de la structure algorithmique : AutoPSO et EvoGO

Dans des méthodes comme MetaDE, l'évolution se produit au niveau desparamètres: l'algorithme interne résout la tâche réelle, tandis que l'algorithme externe ajuste la configuration et la stratégie de l'algorithme interne. Or AutoPSO et EvoGO élèvent l'objet de l'évolution d'un cran supplémentaire — en faisant évoluer directementla structure algorithmique elle-même: comment les composants se combinent, comment les candidats sont générés, comment les règles de mise à jour sont organisées.

Critère : que recherche réellement la couche externe

Pour distinguer « réglage de paramètres » et « modification de structure », il ne faut pas se fier au nom de la méthode, mais auniveau de l'espace de recherche externe. Pour les méthodes comme MetaDE, l'espace de recherche externe est la configuration et la stratégie de l'algorithme interne (valeurs du facteur d'apprentissage, de la probabilité de mutation, de la pression de sélection, etc.) ; celui d'AutoPSO / EvoGO est la structure algorithmique — quels composants participent à la combinaison, à quoi ressemble le processus de génération des candidats, comment l'état est mis à jour.

paramètres: la structure est figée, seules les valeurs sont ajustées. Le champ d'action est l'« intensité » du comportement.
Couche structurelle: les composants et les modes de connexion sont variables. Le champ d'action est la « forme » du comportement.

AutoPSO : décomposer le PSO classique en un bassin de composants

La formule figée de mise à jour vitesse–position du PSO classique est remplacée. AutoPSO décompose ce processus en composants combinables : terme de vitesse, topologie de voisinage, terme de perturbation, stratégie de redémarrage, etc., que l'évolution externe sélectionne et assemble en un nouveau générateur de candidats. Il n'utilise plus la structure de mise à jour classique figée, mais fait de la « structure de mise à jour » elle-même une variable recherchable. Ajuster le facteur d'apprentissage ne change que l'intensité du comportement ; modifier la combinaison des composants change la forme du comportement.

EvoGO : laisser le retour historique décider dans quelle direction modifier la structure

EvoGO met l'accent sur l'intégration du retour historique dans la trajectoire d'évolution structurelle : les trajectoires de recherche passées et les enregistrements de performance ne servent plus seulement à « sélectionner des solutions », mais à décider « dans quelle direction modifier la structure ensuite ». Le retour passe ainsi de filtre de résultats à volant de la mise à jour structurelle — il modifie l'orientation des candidats structurels du prochain cycle, au lieu de simplement choisir un bon résultat parmi un lot de candidats déjà terminés.

Squelette bicouche partagé et implications d'ingénierie

Les deux partagent le même squelette : l'algorithme interne s'exécute sur la tâche réelle, la couche externe fait évoluer la structure en fonction des performances de la couche interne. La condition clé est la densité d'échantillons — l'exécution par lots en parallèle sur GPU d'un grand nombre de tâches internes rend les échantillons appariés « structure–performance » suffisamment denses, afin que la sélection externe ait une signification statistique et ne soit pas dictée par le bruit d'une exécution unique.

Implications d'ingénierie

L'algorithme passe d'« un choix a priori ponctuel » à « un objet améliorable en continu ». Le prix à payer : l'évolution de la couche structurelle engendre naturellement un espace de recherche plus vaste et un coût d'évaluation plus élevé, sa faisabilité dépend donc d'une base parallèle tensorisée — c'est aussi la motivation directe du thème du calcul parallèle sur GPU abordé dans la prochaine section.

Relation d'évolution structurelle entre AutoPSO et EvoGO

Le schéma compare l'évolution au niveau des paramètres et celle au niveau de la structure : la couche externe de MetaDE recherche les valeurs de configuration (facteur d'apprentissage, probabilité de mutation, etc.) avec une structure algorithmique figée ; celle d'AutoPSO et d'EvoGO recherche comment les composants se combinent, comment les candidats sont générés et comment les règles de mise à jour sont organisées. AutoPSO décompose la mise à jour du PSO en un bassin de composants (terme de vitesse, topologie de voisinage, perturbation, redémarrage, etc.) que la couche externe sélectionne et assemble, tandis qu'EvoGO utilise le retour des trajectoires historiques pour décider dans quelle direction modifier la structure ensuite.

Question 1

Quel est le critère le plus déterminant pour savoir si une méthode relève du « réglage de paramètres » ou de la « modification de structure » ?

Si la vitesse de convergence des tâches de la couche interne est plus rapide

Si l'espace de recherche externe porte sur la configuration et la stratégie de l'algorithme interne, ou sur la structure algorithmique elle-même

Si la taille de la population dépasse mille

Si l'accélération GPU est utilisée

Question 2

Quelle est l'approche centrale d'AutoPSO ?

Décomposer l'optimisation par essaim particulaire en un bassin de composants combinables, que l'évolution externe sélectionne et assemble en un nouveau générateur de candidats

Remplacer entièrement la mise à jour vitesse–position par la descente de gradient

Ajuster finement le facteur d'apprentissage de 2,0 à 1,494

Multiplier la taille de la population pour couvrir davantage de solutions

Question 3

Quel changement l'usage du retour historique dans EvoGO introduit-il par rapport aux approches traditionnelles ?

De la sélection des parents à la définition de critères d'arrêt

De l'évaluation de la fitness à l'initialisation de la population

De l'usage exclusif pour « sélectionner des solutions » à celui pour décider « dans quelle direction modifier la structure ensuite »

De la journalisation à la visualisation graphique

Question 4

Pourquoi le squelette bicouche d'AutoPSO / EvoGO nécessite-t-il l'exécution par lots en parallèle sur GPU d'un grand nombre de tâches internes ?

Pour réduire le nombre de composants combinables

Pour que l'algorithme interne n'ait plus besoin d'être évalué

Pour que les échantillons appariés « structure–performance » soient suffisamment denses et que la sélection externe ait une signification statistique

Parce que le coût unitaire de calcul d'un GPU est inférieur à celui d'un CPU

Question 5

Laquelle des modifications suivantes se situe à un niveau inaccessible au réglage des paramètres ?

Ajuster le poids d'inertie de 0,9 à 0,7

Recombiner le terme de vitesse, la topologie de voisinage, le terme de perturbation et la stratégie de redémarrage en un nouveau générateur de candidats

Faire passer la taille de la population de 50 à 100

Faire passer le nombre maximal d'itérations de 500 à 1000

Cas pratique : faire passer un solveur PSO à structure figée à un système à structure évolutive

Lisez le scénario, répondez aux questions et fournissez des indications de conception applicables.

Une équipe dispose déjà d'un solveur d'optimisation par essaim particulaire à structure figée, utilisé pour des tâches d'optimisation de tournées logistiques, actuellement évalué en série sur CPU. L'équipe prévoit de le faire évoluer vers un système « à structure évolutive » : la couche externe se charge de modifier la structure algorithmique, la couche interne résout sur des instances réelles de réseaux routiers, et les enregistrements de recherche historiques doivent être intégrés à la décision de la couche externe. La ressource disponible est un serveur équipé de plusieurs GPU.

1. Expliquez : comment déterminer que cette mise à niveau a bien franchi le pas du « réglage de paramètres » à la « modification de structure » ? Donnez des critères opérationnels.

Réponse :
Le critère est le niveau de l'espace de recherche externe. Si la couche externe ne fait qu'ajuster des configurations numériques comme le poids d'inertie, le facteur d'apprentissage, la taille de la population ou le nombre d'itérations, alors quelle que soit l'ampleur de la plage de valeurs, elle reste au niveau des paramètres et ne modifie que l'intensité du comportement. Ce n'est que lorsque la couche externe peut modifier la combinaison des composants et le mode de génération des candidats — par exemple en resélectionnant et réassemblant le terme de vitesse, la topologie de voisinage, le terme de perturbation et la stratégie de redémarrage en un nouveau générateur de candidats, faisant ainsi évoluer la forme même du comportement — qu'elle franchit véritablement le pas vers la couche structurelle. Test opérationnel : geler tous les hyperparamètres numériques et n'autoriser la couche externe à modifier que la combinaison des composants ; si le comportement de recherche du système peut encore changer fondamentalement, alors la mise à niveau atteint bien la couche structurelle.

2. Pour reproduire l'approche d'EvoGO, comment faire entrer les trajectoires de recherche historiques dans la décision de la couche externe ? Donnez un point de conception concret et expliquez en quoi il diffère de l'usage « limité à la sélection de solutions ».

Réponse :
Point de conception : organiser les enregistrements d'exécution de la couche interne après chaque instanciation de structure en caractéristiques de retour structurées, incluant la combinaison de composants utilisée, la trajectoire de convergence, la forme de la courbe de fitness, les schémas d'échec ou de stagnation, etc. ; puis faire piloter directement ces caractéristiques par les règles de mise à jour structurelle de la couche externe, par exemple en laissant le retour décider « quel composant modifier en priorité, quelle connexion ajouter ou supprimer », plutôt que de simplement trier tous les résultats historiques et prendre le meilleur. La différence avec l'usage « limité à la sélection de solutions » réside dans la direction de l'action : dans le premier cas, le retour est un filtre a posteriori qui n'influence que le choix final parmi les candidats déjà terminés ; dans l'usage à la manière d'EvoGO, le retour est un contrôleur d'orientation a priori qui influence directement la direction des candidats structurels du prochain cycle. En outre, comme l'espace de recherche de la couche structurelle est plus vaste et le coût d'évaluation plus élevé, cette conception doit s'appuyer sur l'exécution par lots en parallèle sur GPU d'un grand nombre de tâches internes, afin d'accumuler des échantillons appariés structure–performance suffisamment denses et de donner à la sélection externe une signification statistique.