Définir l'espace de recherche et les variables de décision

Pour définir l'espace de recherche et les variables de décision d'un cas d'utilisation d'AlphaEvolve, il est nécessaire de formuler correctement le problème sous forme de code et de fournir une solution de référence fonctionnelle sur laquelle l'heuristique évolutive peut itérer et s'améliorer.

Ce processus inclut les étapes suivantes :

  • Fournir le contexte cible : établissez le contexte, les règles de domaine et les limites de performances pour le cas d'utilisation de l'optimisation.

  • Fournir une référence propre : fournissez un code clair et bien structuré qui implémente correctement une solution de référence pour le problème cible.

  • Ajouter des tags aux degrés de liberté : annotez le codebase avec des commentaires EVOLVE-BLOCK explicites pour marquer les variables de décision, les structures logiques ou les routines spécifiques que l'agent peut modifier et explorer pour identifier des solutions plus performantes.

Structure d'un programme initial

Un programme initial est composé de deux types de blocs principaux qui déterminent les limites de la recherche évolutive :

  1. Blocs de code immuables : code récurrent, fonctions d'assistance et dépendances qui limitent l'espace de recherche ou exécutent des tâches qui n'ont pas d'impact sur les performances de la solution (comme les étapes de prétraitement standards ou les routines de traitement des données).

  2. Blocs de code modifiables (EVOLVE-BLOCK) : régions ciblées contenant des variables de décision, des structures logiques ou des expressions analytiques spécifiques que l'agent est autorisé à explorer et à modifier.

    import numpy as np
# Code to constrain the search space (Immutable)
def def_preprocessing():
    """Feature engineering and preprocessing."""
    pass

# EVOLVE-BLOCK-START
# Mutable block: Provides degrees of freedom for AlphaEvolve to optimize
def model_tuning():
    """Model tuning function: parametrized to take features."""
    pass
# EVOLVE-BLOCK-END

# Boilerplate code that does not impact solution performance (Immutable)
def batch_predictions():
    """Inference function: batch predictions to test performance."""
    pass

Les règles de mise en forme de EVOLVE-BLOCK sont les suivantes :

  • Lignes autonomes : les repères de commentaire EVOLVE-BLOCK-START et EVOLVE-BLOCK-END doivent apparaître seuls sur leur propre ligne. Ne placez pas de code ni d'autre contenu sur la même ligne qu'un repère, à l'exception des espaces blancs et des préfixes de commentaire (tels que # ou //).
  • Code modifiable requis : la région entre les repères de début et de fin doit contenir au moins une ligne de code modifiable. Les blocs ne contenant que des espaces blancs, des commentaires ou des docstrings sont rejetés avec une erreur de validation, car il n'existe aucune logique modifiable pour AlphaEvolve.
  • Pas d'imbrication : les blocs evolve imbriqués ne sont pas acceptés.

Bonnes pratiques pour limiter l'espace de recherche

La façon dont vous organisez vos importations immuables et placez vos blocs d'évolution montre explicitement les limites opérationnelles d'AlphaEvolve.

Gérer les importations et les dépendances de bibliothèques

AlphaEvolve ne peut pas déterminer de manière inhérente quelles bibliothèques externes sont valides pour votre environnement de production.

Pour autoriser l'exploration ouverte : si un package de machine learning ou mathématique est acceptable pour maximiser votre métrique, placez les importations dans le EVOLVE-BLOCK modifiable. Cela permet à AlphaEvolve de remplacer les frameworks alternatifs (par exemple, en remplaçant sklearn par TensorFlow ou xgboost).

Pour appliquer des chaînes d'outils strictes : si tous les modèles doivent provenir d'un package spécifique, déclarez ce package comme une importation immuable en dehors du bloc evolve. Si AlphaEvolve nécessite des modules internes supplémentaires de ce package pendant la recherche, il peut toujours les importer localement dans son espace modifiable sans enfreindre la contrainte globale.

Éviter un espace de recherche trop limité

Formulez autant de contraintes strictes que possible sous forme de blocs de code immuables dans le programme initial ou dans le contexte textuel supplémentaire fourni par l'utilisateur. Cela réduit les risques que l'agent explore des solutions structurellement irréalisables.

Toutefois, ne limitez pas l'espace de recherche au point de rendre l'approche évolutive redondante. Par exemple, forcer AlphaEvolve à n'utiliser que des régressions linéaires à paramètre unique réduit le problème à un espace de configuration étroit qui pourrait être analysé par des utilitaires de recherche par quadrillage standards. Utilisez plutôt des contraintes souples comme pénalités négatives dans vos critères d'évaluation pour guider l'exploration sans l'étouffer.

Placement stratégique des blocs pour des objectifs ciblés

La modification du champ d'application de votre EVOLVE-BLOCK modifie l'objectif d'optimisation de l'ensemble de votre pipeline :

Optimiser la calibration hors échantillon (OOS) : si votre objectif est une découverte algorithmique générale, encapsulez le bloc autour de l'ensemble de la routine de réglage et d'initialisation du modèle.

Optimiser l'ajustement structurel : si vous souhaitez conserver un framework linéaire, mais découvrir des expressions analytiques complexes ou des transformations mathématiques personnalisées, isolez votre bloc modifiable strictement autour de la logique de transformation des caractéristiques, en gardant l'architecture du modèle en aval fixe et immuable.

Préserver la hiérarchie modulaire (exemples HDL/Verilog) : lorsque vous optimisez les configurations de blocs de code structurels, conservez les balises EVOLVE-BLOCK-START et EVOLVE-BLOCK-END strictement dans les limites de la définition du module. Cela empêche l'heuristique de recherche d'effectuer des déplacements structurellement non valides, comme essayer de remplacer un seul module proprement contenu par plusieurs sous-modules flottants non mappés.