Definir o espaço de pesquisa e as variáveis de decisão

Definir o espaço de pesquisa e as variáveis de decisão para um caso de uso do AlphaEvolve requer a formulação adequada do problema como código e o fornecimento de uma solução de referência funcional que a heurística evolutiva possa iterar e melhorar.

Esse processo inclui:

  • Fornecer o contexto de destino: estabeleça o contexto, as regras de domínio e os limites de desempenho para o caso de uso de otimização.

  • Fornecer um valor de referência limpo: forneça um código claro e bem estruturado que implemente corretamente uma solução de valor de referência para o problema em questão.

  • Marcar graus de liberdade: anote a base de código com comentários EVOLVE-BLOCK explícitos para marcar as variáveis de decisão, estruturas lógicas ou rotinas específicas que o agente pode modificar e explorar para identificar soluções de melhor desempenho.

Estrutura de um programa inicial

Um programa inicial é composto por dois tipos de blocos principais que determinam os limites da pesquisa evolutiva:

  1. Blocos de código imutáveis: código boilerplate, funções auxiliares e dependências que restringem o espaço de pesquisa ou executam tarefas que não afetam o desempenho da solução (como etapas de pré-processamento padrão ou rotinas de processamento de dados).

  2. Blocos de código mutáveis (EVOLVE-BLOCK): as regiões de destino que contêm variáveis de decisão, estruturas lógicas ou expressões analíticas específicas que o agente pode explorar e modificar.

    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
    

As regras de formatação do EVOLVE-BLOCK incluem:

  • Linhas independentes: os marcadores de comentário EVOLVE-BLOCK-START e EVOLVE-BLOCK-END precisam aparecer sozinhos nas próprias linhas. Não coloque código ou outro conteúdo na mesma linha de um marcador, exceto espaços em branco e prefixos de comentário (como # ou //).
  • Código editável obrigatório: a região entre os marcadores de início e fim precisa conter pelo menos uma linha de código editável. Os blocos que contêm apenas espaços em branco, comentários ou docstrings são rejeitados com um erro de validação, porque não há lógica mutável para o AlphaEvolve evoluir.
  • Sem aninhamento: blocos de evolução aninhados não são aceitos.

Práticas recomendadas para restringir o espaço de pesquisa

A forma como você organiza as importações imutáveis e posiciona os blocos de evolução mostra explicitamente os limites operacionais do AlphaEvolve.

Gerenciar importações e dependências de bibliotecas

O AlphaEvolve não pode determinar de forma inerente quais bibliotecas externas são válidas para seu ambiente de produção.

Para permitir a exploração aberta: se qualquer pacote matemático ou de machine learning for aceitável para maximizar sua métrica, coloque as importações dentro do EVOLVE-BLOCK mutável. Isso dá ao AlphaEvolve a liberdade de substituir frameworks alternativos (como substituir o sklearn pelo TensorFlow ou xgboost).

Para aplicar cadeias de ferramentas estritas: se todos os modelos precisarem vir de um pacote específico, declare esse pacote como uma importação imutável fora do bloco de evolução. Se o AlphaEvolve precisar de mais módulos internos desse pacote durante a pesquisa, ele ainda poderá importá-los localmente no espaço mutável sem violar a restrição global.

Evite um espaço de pesquisa excessivamente restrito

Formule o máximo possível de restrições rígidas como blocos de código imutáveis no programa inicial ou no contexto de texto adicional fornecido pelo usuário. Isso minimiza as chances de o agente explorar soluções estruturalmente inviáveis.

No entanto, não restrinja o espaço de pesquisa ao ponto em que uma abordagem evolutiva se torne redundante. Por exemplo, forçar o AlphaEvolve a usar apenas regressões lineares de parâmetro único reduz o problema a um espaço de configuração estreito que pode ser analisado por utilitários de pesquisa em grade padrão. Em vez disso, use restrições flexíveis como penalidades negativas nos critérios de avaliação para orientar a exploração sem sufocá-la.

Posicionamento estratégico de blocos para objetivos específicos

Variar o escopo do EVOLVE-BLOCK muda todo o objetivo de otimização do pipeline:

Otimização da calibragem fora da amostra (OOS, na sigla em inglês): se o objetivo é uma descoberta algorítmica ampla, envolva toda a rotina de ajuste e inicialização do modelo com o bloco.

Otimização do ajuste estrutural: se você quiser preservar um framework linear, mas descobrir expressões analíticas complexas ou transformações matemáticas personalizadas, isole o bloco mutável estritamente em torno da lógica de transformação de recursos, mantendo a arquitetura do modelo downstream fixa e imutável.

Preservação da hierarquia modular (exemplos de HDL/Verilog): ao otimizar as configurações de blocos de código estruturais, mantenha as tags EVOLVE-BLOCK-START e EVOLVE-BLOCK-END estritamente dentro dos limites de definição do módulo. Isso impede que a heurística de pesquisa faça movimentos estruturalmente inválidos, como tentar substituir um único módulo contido de forma limpa por vários submódulos flutuantes não mapeados.