La cible d'optimisation représente le nombre unique qu'AlphaEvolve maximise à chaque génération. Avant d'écrire du code d'évaluateur, répondez aux trois questions suivantes :
Que représente cette valeur ?
Comment le système la calcule-t-il ?
Où le calcul est-il exécuté ?
AlphaEvolve nécessite une computation de cible automatisée et programmatique pour chaque solution candidate, sans intervention humaine. Cette automatisation permet à AlphaEvolve de résoudre le problème. Si une personne doit juger manuellement la qualité d'une solution, AlphaEvolve ne peut pas la rechercher.
Tenez compte des éléments suivants pour estimer les performances d'une solution candidate générée en fonction des différents objectifs d'optimisation et contraintes de validation :
- Les objectifs d'optimisation peuvent-ils être calculés directement à l'aide d'une logique métier ou produit, sans avoir besoin de mesure empirique ?
- Les objectifs d'optimisation peuvent-ils être mesurés directement en exécutant des tests de performances et de charge sur le code de la solution générée ?
- Les objectifs d'optimisation peuvent-ils être estimés à l'aide de fonctions de substitution déterministes établies et de méthodes de simulation fiables ?
- Les objectifs d'optimisation peuvent-ils être estimés en concevant une fonction de substitution personnalisée (telle qu'un modèle prédictif ou un autre estimateur non déterministe) qui nécessite un réglage sur des observations empiriques et une validation sur des données hors échantillon ?
Étapes de base pour quantifier votre cible
Suivez une approche structurée pour vous assurer qu'AlphaEvolve dispose d'une boucle de rétroaction automatisée et fiable pour guider sa recherche. Suivez les étapes ci-dessous pour établir votre métrique, définir comment elle est mesurée et déterminer où l'exécution a lieu.
1. Exprimer la cible sous la forme d'un score unique qui augmente à mesure que les solutions s'améliorent
Configurez votre métrique d'optimisation principale pour qu'elle évolue de manière linéaire ou monotone avec les gains de performances réels afin que le chemin de recherche présente un gradient directionnel clair.
Maximisation scalaire : AlphaEvolve maximise toujours une valeur scalaire. Convertissez tout ce qui vous intéresse en un seul nombre, où une valeur plus élevée est préférable. Pour minimiser la latence, le coût ou l'erreur, annulez-la :
score = -latency_msMonotonie : le score doit être monotone, c'est-à-dire qu'il doit augmenter chaque fois que la solution s'améliore réellement. Un score qui évolue de manière incohérente ne donne aucune direction à la recherche.
Exécution déterministe : le score est calculé dans votre évaluateur, jamais par le LLM ni par une personne. Calculez-le de manière déterministe afin que le même candidat obtienne toujours le même score.
Analyse conjointe pour les objectifs subjectifs : si vous ne pouvez pas écrire de formule de notation, mais que vous pouvez comparer deux solutions à l'œil nu, créez-en une avec une analyse conjointe. Générez des paires de résultats candidats, demandez à un expert du domaine de choisir la meilleure paire, ajustez une régression logistique sur ces choix et utilisez le modèle ajusté comme métrique. Cela transforme le jugement subjectif en un score déterministe et différentiable. N'utilisez pas de grille LLM brute comme score en direct, car elle est lente, bruyante et facile à pirater. Distillez-la d'abord dans une fonction fixe.
2. Choisir comment le score est calculé
La façon dont vous produisez le nombre dépend de ce que vous mesurez. Choisissez la méthode dans le tableau qui correspond à votre objectif. Presque tous les déploiements réels utilisent l'une de ces quatre méthodes, et beaucoup en combinent deux : une méthode peu coûteuse pour générer la recherche et une méthode coûteuse pour confirmer les gagnants.
| Méthode de mesure | Utilisez-la lorsque la cible est… | Comment le score est-il produit ? | Ce dont il a besoin pour s'exécuter |
|---|---|---|---|
| Calcul direct | Une quantité que vous pouvez calculer sous forme fermée à partir de la sortie du candidat à l'aide d'une logique métier ou produit | L'évaluateur exécute le candidat et applique une formule (somme, ratio, nombre, coût) | Le propre processus du contrôleur, sans infrastructure supplémentaire |
| Test de performances ou de charge | Le temps d'exécution, le débit ou la mémoire du code candidat lui-même | Exécutez le candidat sur du matériel représentatif et mesurez-le. Vérifiez d'abord l'exactitude. | Le matériel cible (GPU, TPU ou CPU) ; échauffement et meilleur des N pour réduire le bruit de synchronisation |
| Substitution / simulation déterministe | Coûteux ou bruyant à mesurer directement, mais un proxy fiable ou une relecture des conditions réelles existe | Calculez un proxy déterministe ou rejouez des scénarios d'exploitation fixes et amorcés | N'importe quel environnement ; entièrement reproductible avec des amorces fixes |
| Validation hors échantillon | La qualité d'un modèle ou d'un pipeline de données produit par le candidat | Entraînez/ajustez le candidat, puis notez-le sur des données mises en attente ou fraîchement générées | Votre pile d'entraînement/d'évaluation ; une division stricte entre l'entraînement et la validation ; revalidez les gagnants sur l'ensemble mis en attente |
Pour en savoir plus, consultez l'annonce AlphaEvolve sur le Google Cloud blog.
Si aucune de ces méthodes ne peut produire un nombre automatiquement, le problème n'est pas encore prêt pour AlphaEvolve. La tâche principale consiste alors à construire une substitution ou une simulation qui le peut.
3. Gérer plusieurs objectifs et contraintes
Les objectifs réels combinent généralement plusieurs préoccupations. Utilisez l'une des deux méthodes suivantes pour les gérer :
Mélange scalaire (le plus simple, recommandé pour commencer) : redimensionnez chaque métrique sur une plage comparable, annulez celles que vous minimisez, puis ajoutez-les : score = w1*A - w2*L - w3*M.
Préférez les sommes additives aux ratios tels que A/(L⋅M), qui sont numériquement instables.
Renvoie un dictionnaire de scores nommés : laissez AlphaEvolve les optimiser conjointement. L'évaluateur peut renvoyer plusieurs métriques nommées au lieu d'un seul nombre :
```JSON
{
"scores": [
{"metric": "accuracy", "score": 0.95},
{"metric": "latency_ms", "score": -120.0}
]
}
```
Une valeur plus élevée est préférable pour chacune d'elles. Annulez donc tout ce que vous minimisez. Cela déclenche une véritable recherche multi-objectif, et pas seulement un rapport : la base de données de population conserve le meilleur programme par métrique (MAP-Elites), maintient une frontière de Pareto sur les métriques et échantillonne les parents de manière diversifiée sur les différentes métriques. Il peut également extraire directement les parents de la frontière de Pareto lorsque cet échantillonnage est activé. Un seul score de titre génère toujours la montée en puissance signalée, mais chaque métrique renvoyée façonne la recherche.
Limitez-vous à 3 à 5 métriques : avec trop de métriques, la dominance de Pareto dégénère. Presque tous les programmes ne sont pas dominés par quelque chose et la recherche s'égare. Agrégez ou supprimez les métriques au-delà de ce seuil.
Isolez l'exactitude et la faisabilité : conservez l'exactitude comme porte d'entrée, et non comme partie de la fonction de récompense. Un candidat incorrect ou irréalisable obtient un score d'échec, quelle que soit sa rapidité ou son coût. Il s'agit de la principale défense contre l'agent qui joue avec votre métrique.
Optimisation des contraintes : conservez un objectif comme contrainte et optimisez l'autre, en appliquant une pénalité lorsque la contrainte est enfreinte. L'exécution de ce workflow à plusieurs niveaux de contrainte trace le front de Pareto.
4. Décider où l'évaluateur s'exécute
AlphaEvolve n'exécute jamais directement votre évaluateur. Il propose des programmes candidats et reçoit des scores. Vous hébergez et exécutez le code qui calcule le score. L' environnement est entièrement votre choix et un candidat qui ne peut pas s'exécuter sur Google Cloud n'est pas un bloqueur. Vous exécutez l'évaluateur partout où l'objectif peut être mesuré et vous renvoyez le score.
Pour garantir un déploiement efficace et sécurisé, vous devez aligner votre infrastructure de calcul sur votre stratégie de mesure spécifique tout en respectant les limites d'exécution universelles. Suivez les consignes ci-dessous pour sélectionner votre environnement d'exécution et comprendre les limites opérationnelles de base qui s'appliquent à toutes les configurations.
Faire correspondre l'environnement d'exécution à la méthode de mesure
Calcul direct ou substitution : le propre processus du contrôleur ou un seul conteneur Cloud Run.
Test de performances ou de charge : le matériel cible, tel qu'un nœud GPU ou TPU sur GKE, votre propre matériel sur site ou personnalisé, ou un outil tiers ou ISV (par exemple, un simulateur EDA ou Verilog).
Validation hors échantillon ou tâches lourdes : votre pile d'entraînement répartie sur Cloud Run ou GKE, ou déchargée par Google Cloud lot à l'aide du Cluster Toolkit pour les charges de travail HPC ou d'accélérateur volumineuses.
Deux limites s'appliquent quel que soit l'environnement
Essayez de limiter chaque évaluation à environ 10 minutes ou moins afin que la boucle évolutive continue de fonctionner. Pour les objectifs coûteux, utilisez une cascade d'évaluation : vérifiez chaque candidat et n'exécutez l'évaluation complète que pour les candidats prometteurs.
Vous êtes propriétaire des contrôles d'accès, de sécurité et de mise en réseau de l'évaluateur. AlphaEvolve ne déploie ni ne gère l'évaluateur, ni sur Google Cloud ni ailleurs.
Une fois que vous avez choisi la métrique, la façon de la calculer et l'endroit où elle s'exécute, consultez les modèles d'implémentation d'évaluateur pour savoir comment structurer l'évaluateur.