Referência da API AlphaEvolve

Este documento serve como referência de API e especificação de sistema autoritária e de nível de produção para a API AlphaEvolve Cloud nas camadas conversacionais do Discovery Engine Google Cloud. Ele define as hierarquias de recursos aninhados precisas, os endpoints REST e gRPC, as restrições no nível do campo, as máquinas de estado do ciclo de vida, as matrizes de diagnóstico de erros, as regras de sandbox de segurança e os fluxos de trabalho de integração necessários para projetar um controlador e um loop de avaliação totalmente automatizados do lado do cliente.

Máquinas de estado unificadas do ciclo de vida

O agente AlphaEvolve coordena duas máquinas de estado independentes para monitorar a progressão da campanha de teste e gerenciar a veiculação e a execução de mutações individuais do programa.

Estados do ciclo de vida do experimento

Um experimento representa a campanha de otimização geral. Ele é processado como um recurso permanente do lado do servidor e passa pelos seguintes estados:

  • CREATED:o estado de inicialização. O recurso foi declarado e configurado, mas ainda não gerou gerações iniciais nem enviou chamadas de API.

  • RUNNING:o estado ativo da avaliação. O mecanismo está simultaneamente amostrando candidatos principais, gerando mutações de código pela combinação de LLMs e transmitindo tarefas para avaliadores.

  • PAUSED:um estado de espera temporário acionado manualmente ou por um idle_timeout de proteção automatizado. A geração de código é interrompida, e os workers atuais pausam a entrega de métricas.

  • COMPLETED:um estado terminal que indica que a pesquisa atingiu a alocação de meta max_programs ou o limite de geração estrutural.

  • FAILED:um estado de erro terminal que indica que problemas sistêmicos no ambiente, como exceções de credenciais de API não capturadas, corrupção do repositório de dados ou falhas consecutivas do executor, interromperam a execução do processamento.

Estados do programa

A sequência de validação de tempo de execução é aplicada a variantes candidatas individuais.

Cada mutação de código gerada se comporta como uma entidade de programa isolada que passa por uma sequência de estados operacionais granulares no banco de dados da população.

  1. INITIALIZED:a entrada do programa é criada no banco de dados, rastreando sua linhagem ancestral e vinculações de programas principais.

  2. GENERATING:uma tarefa é enviada ativamente para o back-end de combinação de modelos de linguagem para criar ou alterar os blocos de código funcionais específicos.

  3. EVALUATING:o payload de código é bloqueado por um processo de worker de avaliação e executado em um ambiente de teste isolado.

  4. COMPLETED:as pontuações de execução e os insights estruturais descritivos são enviados com segurança ao banco de dados evolutivo, e o programa é adicionado ao pool de seleção.

Mecânicas de simultaneidade e bloqueio

Os programas são adquiridos por loops de worker usando um mecanismo de token de bloqueio atômico para evitar condições de corrida ou sobrecarga de pontuação duplicada em topologias distribuídas. O avaliador precisa enviar o esquema de pontuação finalizado junto com o token de bloqueio de correspondência exata para confirmar os resultados no banco de dados.

Esquemas de configuração e configurações

Visão geral das principais configurações, parâmetros e padrões de esquema usados pelo ambiente de execução do mecanismo AlphaEvolve.

AlphaEvolveExperimentConfig

Define os parâmetros estruturais principais e as restrições programáticas da execução do experimento evolutivo.

Nome do campo Tipo Padrão Restrições / limites de valor Descrição técnica
title string Obrigatório Máximo de 256 caracteres Nome de exibição exclusivo do experimento.
problemDescription string Obrigatório Máximo de 5.000 caracteres A especificação formal do problema. Ele é injetado diretamente nos contextos de comandos para estabelecer regras.
programmingLanguage string Obrigatório Valor de formato livre Linguagem de destino do codebase evoluído (por exemplo, "python", "cpp", "verilog", "cuda", "julia", "java").
runSettings objeto Obrigatório Mapeia para o esquema RunSettings Parâmetros de ritmo e tempo limite.
generationSettings objeto Obrigatório Mapeia para o esquema GenerationSettings Seleção de modelo e parâmetros de contexto.
evolutionSettings objeto Obrigatório Mapeia para o esquema EvolutionSettings Parâmetros de seleção e diversidade de famílias.
notes string Obrigatório Máximo de 1.000 caracteres Anotações opcionais para documentação de execução.

RunSettings

Governa a taxa de transferência, os limites de paralelização e os tempos limite automáticos do sistema.

Nome do campo Tipo Padrão Restrições / limites de valor Descrição técnica
maxPrograms int32 100 Mínimo: 1, Máximo: 100.000 Orçamento total de execução (programas para gerar e avaliar).
concurrency int32 1 Mín: 1, Máx: 30 Número de mutações de programa paralelas ativas na fila. Valores maiores que 30 não são permitidos.
maxDuration string null String ISO 8601 dayTimeDuration
Min: >=0, Max: 7 Days		 Tempo total permitido antes da interrupção do experimento.
idleTimeout string null String ISO 8601 dayTimeDuration
Min: >=0, Max: 24 Hrs		 Duração da inatividade antes da transição automática para `PAUSED`.

Configurações de geração

O esquema GenerationSettings controla a montagem de comandos, as janelas de contexto e as configurações de modelo para mutações:

  • context (string): documentação de referência, APIs complementares ou regras opcionais fornecidas pelo usuário. Recomendamos usar menos de 200.000 tokens. Tamanhos de contexto que excedem 200.000 tokens diluem a atenção do modelo e degradam a qualidade da mutação.

  • includeFullProgramInPrompt (bool): false padrão.

    • true: o comando de mutação inclui o # EVOLVE-BLOCK mutável e o boilerplate imutável ao redor (altamente recomendado para raciocínio estrutural complexo).

    • false: apenas o bloco mutável fica visível, salvando o contexto do token.

Configurações de evolução

O esquema EvolutionSettings controla a nova geração de modelos de ilha e as probabilidades de amostragem de elementos principais:

  • parentSamplingConfig → paretoSamplingConfig → paretoSamplingProbability (ponto flutuante): a probabilidade (0,0 a 1,0) de amostrar programas principais diretamente da fronteira de Pareto ativa em vez de usar a seleção padrão com base na adequação. Esse parâmetro precisa ser definido como 0.0 (desativado) se as métricas otimizadas retornarem apenas uma métrica escalar única.

Modelos de dados de programas candidatos

Esta seção descreve os esquemas e as representações de dados usados para definir e organizar estruturas de código candidatas no banco de dados da população.

AlphaEvolveProgramContent

Define os arquivos e a estrutura do programa candidato.

  • files (matriz de AlphaEvolveSourceFile): uma lista de todos os arquivos que compõem a base de código candidata. Essa coleção é limitada a um máximo de 50 arquivos por programa candidato.

  • description (string): um resumo gerado automaticamente que descreve as mudanças programáticas sugeridas pelo modelo de geração (máximo de 1.000 caracteres).

AlphaEvolveSourceFile

Representa um arquivo de código-fonte individual na base de código.

  • path (string): o destino do caminho relativo ao espaço de trabalho (máximo de 256 caracteres). Se você estiver configurando um espaço de trabalho do Python, o ponto de entrada do arquivo executável principal precisa ser chamado exatamente "initial_program.py".

  • content (string): a string de código-fonte bruto que compreende os blocos de implementação funcional. A pegada total cumulativa da base de código combinada em todos os arquivos precisa ser inferior a 4.000 a 5.000 linhas de código (LOC).

  • programLanguage (string): a tag de mapeamento do analisador de idioma. Essa string precisa corresponder explicitamente ao idioma designado na configuração do experimento principal.

  • description (string): um resumo opcional que descreve a arquitetura ou a finalidade individual do arquivo, que é exposta ao LLM durante as transmissões de mutação (máximo de 500 caracteres).

AlphaEvolveProgramEvaluation

O payload estruturado enviado pelas instâncias do executor do cliente de volta ao banco de dados evolutivo após a execução do tempo de execução.

  • scores (AlphaEvolveScores): valores de métricas numéricas padronizadas e objetivas. As práticas recomendadas restringem isso a 3 a 5 métricas de ponto flutuante distintas. O excesso de dimensões de destino prejudica o desempenho do comparador de Pareto multi-objetivo.

  • insights (matriz de AlphaEvolveEvaluationInsight): rótulos semânticos de diagnóstico e rastreamentos de execução em linguagem natural transmitidos para ajudar nas tentativas subsequentes de geração de mutações do LLM. Recomendamos um máximo de 10 itens.

Formulação de pontuação e formatos de ingestão

A regra de maximização

O AlphaEvolve opera fundamentalmente como um algoritmo de escalada de colina monotônica e maximiza estritamente todas as métricas numéricas. Se o pipeline de avaliação rastrear uma meta de minimização (como minimizar a latência do aplicativo em milissegundos ou reduzir o uso de memória), negue o valor antes de enviá-lo de volta ao banco de dados: submitted_score = -latency_ms.

O ideal é que as pontuações sejam contínuas. Métricas booleanas ou altamente discretas não fornecem um indicador de gradiente suficiente para uma exploração eficaz de hill climbing.

Esquema de ingestão de objetivo único

Use o JSON a seguir quando o mecanismo de avaliação otimizar uma única função objetiva escalar.

```json
{
  "scores": {
    "scores": [
      {
        "metric": "accuracy",
        "score": 0.95
      }
    ]
  },
  "insights": {
    "insights": [
      {
        "label": "validation",
        "text": "Passed syntax and basic compilation."
      }
    ]
  }
}
```

Esquema de ingestão com vários objetivos

Use o JSON a seguir ao transmitir parâmetros independentes de rastreamento multiobjetivo para ativar rotinas de otimização da fronteira de Pareto do lado do servidor.

{
  "scores": {
    "scores": [
      {
        "metric": "accuracy",
        "score": 0.95
      },
      {
        "metric": "latency",
        "score": -42.5
      }
    ]
  },
  "insights": {
    "insights": [
      {
        "label": "verification",
        "text": "Passed 5 out of 5 unit tests."
      },
      {
        "label": "latency_warning",
        "text": "Latency regression of 3% observed on large dataset."
      }
    ]
  }
}

Como buscar e consultar dados de programas

O sistema AlphaEvolve registra a telemetria, as métricas de execução e o código-fonte completo de cada mutação gerada, permitindo que os desenvolvedores consultem esse repositório de dados históricos usando a API ou a CLI para acompanhar o progresso da otimização e extrair os candidatos de código de melhor desempenho.

Recuperação de programas usando a API REST

É possível consultar os recursos de programa avaliados no banco de dados usando o endpoint ListAlphaEvolvePrograms padrão com parâmetros de consulta de filtragem e classificação:

  • Filtragem por estado: consulte programas que correspondam a um estado específico do ciclo de vida:

    GET /v1alpha/{parent}/alphaEvolvePrograms?state_filter=COMPLETED

  • Classificação com base em métricas: recupere candidatos classificados com base em métricas otimizadas:

    GET /v1alpha/{parent}/alphaEvolvePrograms?order_by=accuracy desc,latency&page_size=5

Recuperação de programas usando a CLI

Para extrair os principais candidatos concluídos diretamente do terminal, execute o comando a seguir:

ae results best <experiment-nickname> --top 5

Exemplos completos de uso da CLI

A CLI AlphaEvolve oferece aos desenvolvedores controle administrativo rápido e monitoramento de campanhas diretamente do shell:

  • Listar todos os experimentos em uma sessão de conversa:

    ae experiment list

  • Listar todos os programas candidatos mutantes de um experimento específico:

    ae program list EXPERIMENT_NICKNAME \
  --state=COMPLETED \
  --order_by="accuracy desc"

    Substitua EXPERIMENT_NICKNAME pelo nome do experimento.

  • Recupere os candidatos a código concluído com melhor performance:

    ae results best EXPERIMENT_NICKNAME --top 5

    Substitua EXPERIMENT_NICKNAME pelo nome do experimento.

  • Retomar uma campanha pausada:

    ae experiment resume EXPERIMENT_NICKNAME

    Substitua EXPERIMENT_NICKNAME pelo nome do experimento.

Diretório endpoint de API REST principal

Todos os endpoints são versionados em v1alpha da API Google Cloud Discovery Engine.

Padrão de caminho do recurso pai

O URI do recurso pai aninhado verdadeiro é estruturado como: projects/{project}/locations/{location}/collections/{collection}/ engines/{engine}/sessions/{session}

Criar experimento (POST)

  • Caminho: POST v1alpha/{parent=projects/*/locations/*/collections/*/engines/*/ sessions/*}/alphaEvolveExperiments

  • Corpo da solicitação:AlphaEvolveExperimentConfig (consulte a seção 2.1)

  • Resposta:recurso AlphaEvolveExperiment que contém a campanha inicializada.

  • Status HTTP:200 OK

Exemplos de payload da API

  1. Exemplo de corpo da solicitação (POST /alphaEvolveExperiments)

    {
  "config": {
    "title": "Sorting Optimization Campaign",
    "problemDescription": "Optimize the custom_heuristic function.",
    "programLanguage": "python",
    "notes": "Exploring convergence with Gemini 3.5 Flash.",
    "runSettings": {
      "maxPrograms": 250,
      "concurrency": 8,
      "maxDuration": "86400s",
      "idleTimeout": "1800s"
    },
    "generationSettings": {
      "context": "Ensure custom_heuristic is in-place.",
      "includeFullProgramInPrompt": true,
      "models": [
        {
          "name": "gemini-3.5-flash",
          "weight": 1.0
        }
      ]
    },
    "evolutionSettings": {
      "parentSamplingConfig": {
        "paretoSamplingConfig": {
          "paretoSamplingProbability": 0.0
        }
      }
    }
  }
}

  2. Exemplo de corpo da resposta (200 OK)

    {
  "name": "projects/.../sort-opt-01",
  "state": "CREATED",
  "createTime": "2026-06-23T13:30:00Z",
  "config": {
    "title": "Sorting Optimization Campaign",
    "problemDescription": "Optimize the custom_heuristic function.",
    "programLanguage": "python",
    "notes": "Exploring convergence with Gemini 3.5 Flash.",
    "runSettings": {
      "maxPrograms": 250,
      "concurrency": 8,
      "maxDuration": "86400s",
      "idleTimeout": "1800s"
    },
    "generationSettings": {
      "context": "Ensure custom_heuristic is in-place.",
      "includeFullProgramInPrompt": true,
      "models": [
        {
          "name": "gemini-3.5-flash",
          "weight": 1.0
        }
      ]
    },
    "evolutionSettings": {
      "parentSamplingConfig": {
        "paretoSamplingConfig": {
          "paretoSamplingProbability": 0.0
        }
      }
    }
  }
}

Iniciar experimento (POST)

  • Caminho: POST v1alpha/{name=projects/*/locations/*/collections/*/engines/*/ sessions/*/alphaEvolveExperiments/*}:start

  • Corpo da solicitação:StartExperimentRequest

  • Aviso de descontinuação:o campo de corpo initialProgram foi descontinuado e é ignorado.

  • Resposta:GoogleLongrunningOperation (LRO).

  • Status HTTP:200 OK (transiciona o estado de CREATED para RUNNING)

Exemplos de payload da API

  1. Exemplo de corpo da solicitação

    {
  "desiredProgramsCount": 1
}

  2. Exemplo de corpo da resposta (200 OK - operação de longa duração)

    {
  "name": "projects/.../operations/start-op-7788",
  "metadata": {
    "@type": "type.googleapis.com/.../AlphaEvolveStartExperimentMetadata",
    "createTime": "2026-06-23T13:31:00Z"
  },
  "done": false
}

Adquirir programas (POST)

  • Caminho: POST v1alpha/{parent=projects/*/locations/*/collections/*/engines/*/ sessions/*/alphaEvolveExperiments/*}:acquirePrograms

  • Corpo da solicitação:AcquireProgramsRequest

    • desiredProgramsCount (int32): contagem opcional de lote de programas mutados a serem recuperados (o padrão é 1 quando não definido).

  • Status da resposta:

    • 200 OK: retorna uma resposta que contém recursos AlphaEvolveProgram bloqueados.

    • 204 No Content: a fila está vazia ou a campanha está pausada. Os executores precisam ficar inativos (por exemplo, 15 segundos) e tentar de novo.

Exemplos de payload da API

  1. Exemplo de corpo da solicitação

    {
  "desiredProgramsCount": 1
}

  2. Exemplo de corpo da resposta (200 OK)

    {
  "programs": [
    {
      "name": "projects/.../alphaEvolvePrograms/prog-102",
      "lockToken": "token_uuid_8877_x99",
      "state": "EVALUATING",
      "createTime": "2026-06-23T13:32:00Z",
      "content": {
        "description": "Mutated candidate program.",
        "files": [
          {
            "path": "initial_program.py",
            "programLanguage": "python",
            "description": "Primary sorting executable.",
            "content": "def custom_heuristic(arr, _):\n    ..."
          }
        ]
      }
    }
  ]
}

  3. Exemplo de corpo de resposta (204 No Content)

Status HTTP 204 retornado com um contexto de payload vazio.

Enviar avaliações de programas (POST)

  • Caminho: POST v1alpha/{parent=projects/*/locations/*/collections/*/engines/*/ sessions/*/alphaEvolveExperiments/*}:submitProgramsEvaluations

  • Corpo da solicitação:SubmitProgramsEvaluationsRequest

    • evaluationSubmissions (matriz): contém lockToken correspondentes, o caminho qualificado do recurso do programa e o payload de avaliação (pontuações e insights).

  • Resposta:SubmitProgramsEvaluationsResponse (vazia).

  • Status HTTP:200 OK (salva pontuações, libera o bloqueio ativo e registra insights)

Exemplos de payload da API

  1. Exemplo de corpo da solicitação

    {
  "evaluationSubmissions": [
    {
      "lockToken": "token_uuid_8877_x99",
      "program": "projects/.../alphaEvolvePrograms/prog-102",
      "evaluation": {
        "scores": {
          "scores": [
            {
              "metric": "latency_performance",
              "score": evaluation_payload["score"]
            }
          ]
        },
        "insights": {
          "insights": [
            {
              "label": "benchmark",
              "text": "Completed test case in 12.45ms."
            }
          ]
        }
      }
    }
  ]
}

  2. Exemplo de corpo da resposta (200 OK)

    {}

Retomar experimento (POST)

  • Caminho: POST v1alpha/{name=projects/*/locations/*/collections/*/engines/*/ sessions/*/alphaEvolveExperiments/*}:resume

  • Corpo da solicitação:ResumeExperimentRequest

  • Resposta:GoogleLongrunningOperation (LRO).

  • Status HTTP:200 OK (transiciona o estado de PAUSED de volta para RUNNING)

Exemplos de payload da API

  1. Exemplo de corpo da solicitação

    {}

  2. Exemplo de corpo da resposta (200 OK - operação de longa duração)

{
  "name": "projects/.../operations/resume-op-9900",
  "metadata": {
    "@type": "type.googleapis.com/.../AlphaEvolveResumeExperimentMetadata",
    "createTime": "2026-06-23T13:45:00Z"
  },
  "done": false
}

Listar programas (GET)

  • Caminho: GET v1alpha/{parent=projects/*/locations/*/collections/*/engines/*/ sessions/*/alphaEvolveExperiments/*}/alphaEvolvePrograms

  • Parâmetros de consulta:

    • stateFilter (string): opcional. Filtro de lista padrão, por exemplo, stateFilter = 'COMPLETED'.

    • orderBy (string): opcional. Ordenação com base em métricas, por exemplo, accuracy desc.

  • Resposta:ListAlphaEvolveProgramsResponse.

  • Status HTTP:200 OK

Exemplos de payload da API

  1. Exemplo de URL de consulta de solicitação

    GET v1alpha/projects/.../alphaEvolveExperiments/sort-opt-01/
  alphaEvolvePrograms?stateFilter=COMPLETED&orderBy=latency_performance%20desc
  &pageSize=1

  2. Exemplo de corpo da resposta (200 OK)

    {
  "alphaEvolvePrograms": [
    {
      "name": "projects/.../alphaEvolvePrograms/prog-102",
      "state": "COMPLETED",
      "createTime": "2026-06-23T13:32:00Z",
      "evaluation": {
        "scores": {
          "scores": [
            {
              "metric": "latency_performance",
              "score": -12.45
            }
          ]
        },
        "insights": {
          "insights": [
            {
              "label": "benchmark",
              "text": "Completed test case in 12.45ms."
            }
          ]
        }
      }
    }
  ],
  "nextPageToken": "token_page_1_next"
}

Código de diagnóstico e referência de solução de problemas

Matriz de códigos de diagnóstico da API

Status HTTP Tipo de erro Causa do sistema Solução alternativa ou ação de mitigação
400 INVALID_ARGUMENT Tags de comentário # EVOLVE-BLOCK-START / # EVOLVE-BLOCK-END ausentes, sintaxe de esquema JSON inválida, limites de arquivo ou LOC excedidos. Verifique se os comentários de bloco estão colocados dentro de corpos de função usando uma sintaxe válida da linguagem de destino. Verifique se a contagem de arquivos e os limites de LOC são respeitados.
403 PERMISSION_DENIED O usuário ou a conta de serviço não tem a função de usuário do Discovery Engine ou uma licença do Gemini Enterprise atribuída. Verifique as licenças ativas do Gemini Enterprise. Verifique se as credenciais padrão do aplicativo estão configuradas corretamente para o usuário e o projeto executando:

gcloud auth application-default login --project=<<PROJECT_ID>>

Observação:o Model Armor não é compatível com configurações do AlphaEvolve.
408 LOCK_TIMEOUT O executor do cliente excedeu a duração da execução. O bloqueio do programa expirou na fila. Aplicar tempos limite rigorosos de 30 minutos no lado do cliente. Se excedido, envie imediatamente as pontuações de penalidade de falha para limpar o bloqueio da fila.
429 RESOURCE_EXHAUSTED Excedeu os limites de execução simultânea ativa ou cotas de modelo. Implemente a espera exponencial do lado do cliente e configure definições de simultaneidade conservadoras em RunSettings.
503 SERVICE_UNAVAILABLE O serviço de back-end está sobrecarregado ou em manutenção. Implemente um loop de repetição com espera exponencial aleatória no lado do cliente.

Corrigindo "quedas silenciosas"

Uma interceptação do filtro de segurança (descarte silencioso) ocorre quando os modelos de linguagem do lado do servidor sinalizam e descartam solicitações candidatas mutantes devido a frases sensíveis ou acionadores de regras de segurança. O servidor silencia a saída, fazendo com que a fila retorne respostas vazias, e os executores de clientes podem esperar indefinidamente.

Remediação alternativa:

  • Remova frases sensíveis à segurança ou emocionalmente carregadas do problemDescription.

  • Filtrar insights:analise e trunque rastreamentos de exceção brutos ou registros stderr do terminal no payload insights para evitar a repetição de conteúdo do sistema não seguro que aciona filtros downstream.

  • Localize conjuntos de dados:não coloque registros de treinamento ou grandes corpora de texto em comandos. Carregue-os localmente no ambiente do cliente durante a execução do loop de avaliação.

Práticas recomendadas de avaliação do lado do cliente

O gargalo do "código espaguete"

A formatação de origem abaixo do ideal prejudica a qualidade da otimização: "Código espaguete == Espaço de pesquisa ruidoso". Antes de colocar marcadores EVOLVE-BLOCK:

  • Refatore os blocos de código para que as variáveis e assinaturas de função sejam nomeadas claramente.

  • Adicione docstrings descritivas e concisas explicando o que cada função ou variável faz e por quê.

  • Verifique se todas as dependências externas e imutáveis (como importação de módulos auxiliares ou carregamento de dados estáticos) estão fora do # EVOLVE-BLOCK.

Alocação da janela de contexto

Para maximizar a criatividade da mutação, limite o payload de código enviado à API. O contexto total do programa precisa ficar entre 150 mil e 200 mil tokens. Grandes blocos de código estático e imutável consomem a atenção do modelo e prejudicam o desempenho. Mova scripts utilitários, pipelines de ingestão de dados e bibliotecas de validação pesadas totalmente para o avaliador do lado do cliente.

Primeiro, prepare o programa inicial

Antes de executar o AlphaEvolve, use um agente de programação padrão para depurar a base de código inicial e o avaliador:

  • Inicialize a seed:corrija bugs óbvios de sintaxe, problemas de compilação e casos extremos.

  • Verifique a pontuação inicial:confira se a pontuação de base é razoável e se o avaliador é totalmente determinista (mesmo código + mesma entrada = mesma pontuação).

  • Teste com entradas inválidas:execute o avaliador com funções intencionalmente corrompidas para confirmar se ele detecta problemas do compilador, processa loops infinitos corretamente e retorna pontuações de penalidade negativas altas.

Evitar valores de referência otimizados demais

Não transmita um programa de base já altamente otimizado como uma seed. Se o programa inicial já estiver quase ideal, o AlphaEvolve terá dificuldade em fazer a otimização por escalada de colina porque há muito pouco espaço para melhorias. Comece com um valor de referência razoável, mas não totalmente otimizado. Isso dá ao AlphaEvolve espaço para explorar e fazer hill-climbing.

Proteções do executor do lado do cliente

Os avaliadores do lado do cliente precisam aplicar salvaguardas rigorosas para evitar que candidatos maliciosos, com uso intensivo de recursos ou sem resposta atrasem os trabalhadores paralelos:

  • Tempos limite estritos:impõem um corte de execução estrito de 30 minutos (ou menos, dependendo da estrutura do espaço de pesquisa).

  • Envio de penalidade de tempo limite:se uma variante de programa candidata exceder o limite de tempo limite, encerre a execução da linha de execução imediatamente. Não permita que o processo de candidato falhe. Em vez disso, compile e envie instantaneamente uma pontuação de penalidade de falha grave (por exemplo, -100000.0) junto com um insight de depuração descritivo de volta ao servidor para liberar o bloqueio da fila do programa.

  • Filtros de segurança da AST:sempre execute uma verificação de inspeção da árvore de sintaxe abstrata (AST, na sigla em inglês) na carga útil do código-fonte recebido antes da compilação. Interrompa imediatamente a execução e aplique uma penalidade grave de falha se forem detectadas reflexão restrita ou primitivos de execução (como eval, exec, getattr ou setattr).

Outros recursos

Para saber mais, acesse os recursos a seguir: