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 à ces trois questions :
Quelle valeur ce nombre représente-t-il ?
Comment le système le calcule-t-il ?
Où le calcul est-il exécuté ?
AlphaEvolve nécessite strictement un calcul de cible automatisé et programmatique pour chaque solution candidate, sans aucune intervention humaine. Cette automatisation fait du problème un cas d'utilisation idéal pour AlphaEvolve. Si une personne doit juger manuellement de la qualité d'une solution, AlphaEvolve ne peut pas l'explorer.
Utilisez les considérations suivantes pour estimer les performances d'une solution candidate générée sur les 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 nécessiter 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, de méthodes de simulation fiables ?
- Les objectifs d'optimisation peuvent-ils être estimés en concevant une fonction de substitution personnalisée (comme 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 principales 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. Procédez comme suit pour établir votre métrique, définir comment elle est mesurée et déterminer où l'exécution a lieu.
1. Exprimez 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 ait un gradient directionnel clair.
Maximisation scalaire : AlphaEvolve maximise toujours une valeur scalaire. Convertissez tout ce qui vous intéresse en un seul nombre, où plus la valeur est élevée, mieux c'est. Pour minimiser la latence, le coût ou l'erreur, utilisez une valeur négative :
score = -latency_msMonotonicité : le score doit être monotone, 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 à suivre pour l'optimisation.
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 l'analyse conjointe. Générez des paires de sorties candidates, demandez à un expert du domaine de choisir la meilleure de chaque paire, ajustez une régression logistique sur ces choix et utilisez le modèle ajusté comme métrique. Cela transforme un jugement subjectif en un score déterministe et différentiable. N'utilisez pas de grille d'évaluation LLM brute comme score en direct, car elle est lente, bruyante et rapide à pirater les récompenses. Distillez-la d'abord dans une fonction fixe.
2. Choisissez comment le score est calculé
La façon dont vous produisez le nombre dépend de ce que vous mesurez. Choisissez dans le tableau la méthode 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 orienter la recherche et une méthode coûteuse pour confirmer les gagnants.
| Méthode de mesure | Utilisez-le lorsque la cible est… | Comment le score est-il calculé ? | 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 processus du contrôleur lui-même, sans infrastructure supplémentaire |
| Test de performances ou de charge | L'environnement 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. Concentrez-vous d'abord sur l'exactitude. | Le matériel cible (GPU, TPU ou CPU) ; le préchauffage et le best-of-N pour réduire le bruit de synchronisation |
| Substitut/simulation déterministe | Mesure directe coûteuse ou bruitée, mais il existe un proxy fiable ou une rediffusion des conditions réelles | Calculer un proxy déterministe ou rejouer des scénarios d'exploitation fixes et amorcés | Tout environnement ; entièrement reproductible avec des graines fixes |
| Validation hors échantillon | La qualité d'un modèle ou d'un pipeline de données produit par le candidat | Entraîner/ajuster le candidat, puis l'évaluer sur des données exclues ou fraîchement générées | Votre pile d'entraînement/évaluation ; une répartition stricte entre l'entraînement et la validation ; revalider les gagnants sur l'ensemble d'exclusion |
Pour en savoir plus, consultez l'annonce d'AlphaEvolve sur le blog Google Cloud .
Si aucune de ces méthodes ne permet de produire un nombre automatiquement, le problème n'est pas encore prêt pour AlphaEvolve. La tâche principale consiste alors à créer un substitut 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.
Privilégiez les sommes additives aux ratios tels que A/(L⋅M), qui sont numériquement instables.
Renvoyez 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}
]
}
```
Plus la valeur est élevée, mieux c'est. Vous devez donc inverser tout ce que vous minimisez. Cela déclenche une véritable recherche multi-objectifs, et pas seulement un reporting : la base de données de population conserve le meilleur programme par métrique (MAP-Elites), maintient une frontière de Pareto entre les métriques et échantillonne les parents de manière diversifiée entre les différentes métriques. Il peut également extraire des parents directement de la frontière de Pareto lorsque cet échantillonnage est activé. Un seul score global détermine toujours l'ascension rapportée, mais chaque métrique renvoyée façonne la recherche.
Limitez-vous à trois à cinq métriques : avec trop de métriques, la dominance de Pareto dégénère, presque tous les programmes sont non dominés sur un point et la recherche s'égare. Agrégez ou supprimez les métriques au-delà de ce seuil.
Isoler l'exactitude et la faisabilité : l'exactitude doit être un critère strict, et non un élément 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 manipule votre métrique.
Optimisation des contraintes : définissez un objectif comme contrainte et optimisez l'autre, en appliquant une pénalité lorsque la contrainte n'est pas respectée. L'exécution de ce workflow à plusieurs niveaux de contrainte permet de tracer le front de Pareto.
4. Décider où l'évaluateur s'exécute
AlphaEvolve n'exécute jamais votre évaluateur directement. Il propose des programmes candidats et reçoit des scores. Vous hébergez et exécutez le code qui calcule le score. Le choix de l'environnement vous appartient entièrement. Un candidat qui ne peut pas s'exécuter surGoogle Cloud n'est pas un problème. 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.
Associer l'environnement d'exécution à la méthode de mesure
Calcul direct ou substitution : processus propre au contrôleur ou conteneur Cloud Run unique.
Test de performances ou de charge : 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 d'éditeur indépendant (par exemple, un simulateur EDA ou Verilog).
Validation hors échantillon ou jobs lourds : votre pile d'entraînement est répartie sur Cloud Run ou GKE, ou déchargée versGoogle Cloud Batch à l'aide de 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 pour que la boucle évolutive continue de progresser. Pour les objectifs coûteux, utilisez une cascade d'évaluation pour vérifier chaque candidat, en n'exécutant l'évaluation complète que pour les candidats prometteurs.
Vous êtes responsable de la mise en réseau, de la sécurité et des contrôles d'accès de l'évaluateur. AlphaEvolve ne déploie ni ne gère l'évaluateur, sur Google Cloudou ailleurs.
Une fois que vous avez choisi la métrique, comment la calculer et où l'exécuter, consultez les modèles d'implémentation de l'évaluateur pour savoir comment structurer l'évaluateur.