Le workflow complet du runtime EvoX

Le runtime EvoX n'est pas un simple appel d'inférence ponctuel, mais un système d'exécution en boucle fermée dédié à l'exploration évolutive . Il organise les capacités du modèle, celles des outils et le retour de l'environnement en un pipeline fonctionnant en continu : le modèle propose des candidats, le runtime transforme ces candidats en calculs réels, l'environnement renvoie des résultats observables, le mécanisme d'évolution effectue ses choix sur cette base, et le système de persistance consolide les résultats validés comme point de départ de la prochaine itération.

Les six maillons de la boucle fermée

Le modèle propose des candidats: en s'appuyant sur la définition actuelle du problème, l'état historique et les contraintes, il génère des candidats au niveau des paramètres, des opérateurs, des stratégies, voire des programmes, déterminant ainsi par quelles entrées l'espace de recherche est exploré.
Les outils s'exécutent et déclenchent des changements dans l'environnement: le runtime invoque les évaluateurs, les modèles de simulation/surrogate, les bibliothèques d'opérateurs et les workflows, transformant les candidats en calculs réels et en changements observables de l'environnement.
L'environnement renvoie un retour: l'environnement de la tâche fournit des métriques, des violations de contraintes, des modes d'échec et des trajectoires d'exécution ; ces signaux servent à la fois à la notation et à orienter la prochaine série de propositions.
Le mécanisme d'évolution effectue la sélection: par la mise à jour de la population, la mutation/le croisement, la sélection Pareto ou par préférences, il conserve les candidats à forte valeur et modifie ou élimine les candidats à faible valeur.
Le runtime organise le calcul: il assure l'orchestration des modules, la gestion de l'état, l'ordonnancement, l'allocation des ressources de calcul hétérogènes et une exécution reproductible, permettant de découpler les algorithmes des problèmes et de les combiner à la demande.
Le système persistant hérite des résultats: il conserve l'état au niveau du projet à travers les contextes des agents, la validation stricte déterminant quels résultats sont consolidés comme base de référence fiable.

Deux mécanismes souvent sous-estimés

La persistance au niveau du projet à travers les contextes des agents: le contexte d'une session disparaît à la fin de la conversation, alors que l'évolution nécessite une accumulation entre les sessions. EvoX enregistre les candidats, les traces d'évaluation et les conclusions dans un stockage au niveau du projet, permettant à une nouvelle session d'agent de charger directement l'historique sans avoir à refaire le travail déjà accompli.

Validation stricte et héritage de l'historique: tous les résultats ne méritent pas d'entrer dans la base de référence. La passerelle de validation contrôle les métriques, les contraintes et la reproductibilité ; seules les versions validées sont inscrites dans l'historique et héritées par les itérations suivantes. L'héritage devient ainsi un accélérateur fiable, et non un amplificateur d'erreurs.

La portée de la boucle fermée

Grâce à cette boucle fermée, l'itération suivante ne repart pas de zéro : elle poursuit l'évolution à partir de résultats éprouvés. Le modèle propose les possibilités, le système se charge de la validation, de la sélection et de l'accumulation — c'est là le socle de fonctionnement continu de la recherche AI Native.

Rappel essentiel

Distinguez bien « une seule génération » de « une itération évolutive » : la première ne produit que des candidats, tandis que la seconde inclut également l'exécution, le retour, la sélection, la validation et l'héritage. S'il manque un seul maillon, le système ne peut plus s'améliorer en continu.

Schéma d'architecture du workflow en boucle fermée du runtime EvoX

Observez le schéma d'architecture du workflow en boucle fermée du runtime EvoX et décrivez les points clés que vous relevez.

Question 1

Dans le workflow en boucle fermée du runtime EvoX, quel est l'ordre correct des maillons ?

Proposition de candidats → Ordonnancement du runtime et exécution des outils → Retour de l'environnement → Sélection évolutive → Validation et persistance → Héritage de l'historique, puis retour au modèle/Agent

Héritage de l'historique → Exécution du runtime → Proposition de candidats → Retour de l'environnement → Sélection évolutive

Retour de l'environnement → Proposition de candidats → Sélection évolutive → Validation et persistance → Exécution du runtime

Proposition de candidats → Sélection évolutive → Retour de l'environnement → Exécution du runtime → Héritage de l'historique

Question 2

Quelle est la responsabilité centrale du runtime dans la boucle fermée ?

Assurer l'orchestration des modules, la gestion de l'état, l'ordonnancement, l'allocation des ressources de calcul hétérogènes et une exécution reproductible, afin de découpler les algorithmes des problèmes et de les combiner

Remplacer directement l'évaluateur, fournir les métriques finales et décider quel candidat retenir

Se contenter d'enregistrer des journaux, sans participer à aucun calcul réel

Se charger de proposer les candidats, le modèle ne faisant qu'exécuter

Question 3

Un candidat présente une violation de contrainte lors de l'évaluation par l'environnement. Quelle est la manière de procéder la plus conforme à la conception en boucle fermée ?

L'inscrire directement dans l'historique du projet et le conserver définitivement comme exemple négatif

Ignorer la violation et ne conserver que le résultat au meilleur indicateur principal

Arrêter immédiatement toute la tâche et ne plus générer de nouveaux candidats

Transmettre la violation comme signal de retour aux étapes d'évolution et de validation : le candidat peut être éliminé, ou corrigé puis intégré à l'itération suivante

Question 4

Concernant « la persistance au niveau du projet à travers les contextes des agents », quelle affirmation est correcte ?

Elle conserve les candidats, les traces d'évaluation et les conclusions sous forme d'état au niveau du projet, permettant à une nouvelle session d'agent de charger directement la base de référence historique

Elle équivaut à écrire les poids du modèle sur le disque

Elle est maintenue par le modèle lui-même au cours du dialogue, indépendamment du runtime

Elle ne conserve que le texte contextuel de la conversation en cours et devient caduque dès la fin de la session

Question 5

Pourquoi la « validation stricte » est-elle une condition préalable à l'héritage de l'historique ?

Parce que la validation peut remplacer entièrement le retour de l'environnement

Parce que la validation génère une nouvelle série de candidats

Parce que la validation accélère l'ordonnancement du runtime

Parce que seuls les résultats ayant passé les vérifications de métriques, de contraintes et de reproductibilité sont aptes à servir de base de référence fiable héritée par les itérations suivantes

Cas pratique : sélection et héritage des candidats dans une itération de tâche EvoX

Lisez le scénario ci-dessous, puis répondez aux questions.

Une équipe utilise le runtime EvoX pour optimiser la stratégie de contrôle d'un système de simulation. Au cours d'une session, l'agent a généré 40 configurations candidates ; le runtime a ordonnancé par lots les évaluateurs de simulation et les modèles surrogate, renvoyant pour chaque candidat des métriques multi-objectifs (performance et consommation d'énergie) ainsi que plusieurs enregistrements de violation de contraintes ; le mécanisme d'évolution a conservé 8 candidats selon le front de Pareto ; la passerelle de validation a vérifié la reproductibilité de 1 de ces candidats avant de l'inscrire dans l'historique du projet. La session suivante charge cet historique et poursuit la mutation et l'optimisation à partir de ce candidat déjà validé.

1. En vous appuyant sur le workflow en boucle fermée, indiquez quels signaux précis relèvent du « retour de l'environnement » dans ce scénario, et quels maillons de la boucle ils influencent respectivement.

Réponse :
Les signaux de retour sont de trois types : ① les métriques multi-objectifs (performance, consommation d'énergie) — elles influencent la conservation et le classement lors de la sélection évolutive, ainsi que le jugement de conformité lors de la validation ; ② les enregistrements de violation de contraintes — ils déterminent si un candidat est éliminé ou corrigé puis réintégré à l'itération suivante, tout en décidant de sa capacité à passer la validation ; ③ les trajectoires d'évaluation et les informations de reproductibilité consignées par le runtime — elles étayent la décision de la passerelle de validation et fournissent des indices pour la prochaine série de propositions. Le retour de l'environnement sert donc à la fois la sélection de l'itération en cours et l'accumulation de compétences d'une itération à l'autre.

2. Si l'équipe supprimait la passerelle de validation et inscrivait les 8 candidats Pareto dans l'historique du projet, quels risques cela entraînerait-il ? Expliquez du point de vue de « l'héritage de l'historique » et de « l'évolution continue ».

Réponse :
① Du point de vue de l'héritage de l'historique : les résultats non validés peuvent être non reproductibles ou comporter encore des violations de contraintes non traitées ; dès qu'ils sont considérés comme une base de référence fiable, les sessions suivantes héritent de conclusions douteuses, et les erreurs s'accumulent et s'amplifient dans le temps. ② Du point de vue de l'évolution continue : une fois la base de référence corrompue, la mutation et l'optimisation s'articulent autour d'un point de départ erroné, ce qui augmente le coût de recherche tout en réduisant les gains ; l'historique, dilué par de nombreuses entrées peu fiables, ne permet plus à l'équipe de déterminer quel groupe constitue réellement une conclusion de validation exploitable. Conclusion : sans validation stricte, l'héritage passe d'« accélérateur » à « amplificateur d'erreurs » ; la passerelle de validation est donc un maillon indispensable de la boucle fermée.