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 AlphaEvolve, vous devez formuler correctement le problème sous forme de code et fournir une solution de référence fonctionnelle que l'heuristique évolutive peut itérer et améliorer.

Ce processus comprend les étapes suivantes :

  • Fournir le contexte cible : établissez l'arrière-plan, les règles de domaine et les limites de performances pour le cas d'utilisation d'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.

  • Marquer les degrés de liberté : annotez la base de code 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 transformer et explorer afin d'identifier des solutions plus performantes.

Structure d'un programme initial

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

  1. Blocs de code immuables : code passe-partout, fonctions d'assistance et dépendances qui limitent l'espace de recherche ou exécutent des tâches qui n'ont pas d'incidence sur les performances de la solution (telles que les étapes de prétraitement standard ou les routines de gestion 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 à transformer.

    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 EVOLVE-BLOCK incluent les éléments suivants :

  • Lignes autonomes : les marqueurs de commentaire EVOLVE-BLOCK-START et EVOLVE-BLOCK-END doivent apparaître seuls sur leurs propres lignes. Ne placez pas de code ni d'autre contenu sur la même ligne qu'un marqueur, à l'exception des préfixes d'espace et de commentaire (tels que # ou //).
  • Code modifiable requis : la région située entre les marqueurs de début et de fin doit contenir au moins une ligne de code modifiable. Les blocs ne contenant que des espaces, des commentaires ou des chaînes de documentation sont rejetés avec une erreur de validation, car il n'existe aucune logique modifiable pour qu'AlphaEvolve évolue.
  • Aucune imbrication : les blocs d'évolution imbriqués ne sont pas pris en charge.

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 des frameworks alternatifs (par exemple, remplacer 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 d'évolution. Si AlphaEvolve nécessite des modules internes supplémentaires de ce package lors de 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 de texte 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 qu'une approche évolutive devienne redondante. Par exemple, forcer AlphaEvolve à n'utiliser que des régressions linéaires à un seul paramètre 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 des pénalités négatives dans vos critères d'évaluation pour guider l'exploration sans la limiter.

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

La modification de la portée de votre EVOLVE-BLOCK modifie l'objectif d'optimisation de l'ensemble de votre pipeline :

Optimiser la calibration hors échantillon : si votre objectif est une découverte algorithmique large, 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 conservant l'architecture du modèle en aval fixe et immuable.

Conserver la hiérarchie modulaire (exemples HDL/Verilog) : lors de l'optimisation des configurations de blocs de code structurel, conservez les balises EVOLVE-BLOCK-START et EVOLVE-BLOCK-END strictement à l'intérieur des limites de la définition du module. Cela empêche l'heuristique de recherche d'effectuer des mouvements structurellement non valides, par exemple en essayant de remplacer un seul module clairement contenu par plusieurs sous-modules flottants non mappés.