Riferimento API AlphaEvolve

Questo documento funge da riferimento API autorevole e di livello di produzione e da specifica di sistema per l'API AlphaEvolve Cloud nei livelli conversazionali di Google Cloud Discovery Engine. Definisce le gerarchie di risorse nidificate precise, gli endpoint REST e gRPC, i vincoli a livello di campo, le macchine a stati del ciclo di vita, le matrici di diagnostica degli errori, le regole di sandboxing della sicurezza e i workflow di integrazione necessari per progettare un controller e un ciclo di valutazione lato client completamente automatizzati.

Macchine a stati del ciclo di vita unificate

L'agente AlphaEvolve coordina due macchine a stati indipendenti per monitorare l'avanzamento della campagna sperimentale e gestire la pubblicazione e l'esecuzione delle singole mutazioni del programma.

Stati del ciclo di vita dell'esperimento

Un esperimento rappresenta la campagna di ottimizzazione complessiva. Viene elaborato come una risorsa lato server persistente e passa attraverso i seguenti stati:

  • CREATED: lo stato di inizializzazione. La risorsa è dichiarata e configurata, ma non ha ancora generato le generazioni iniziali né inviato chiamate API.

  • RUNNING: lo stato di valutazione attivo. Il motore esegue contemporaneamente il campionamento dei candidati principali, la generazione di mutazioni del codice tramite la combinazione di LLM e lo streaming delle attività ai valutatori.

  • PAUSED: uno stato di attesa temporaneo attivato manualmente o tramite una idle_timeout protettiva automatica. La generazione del codice si interrompe e i worker esistenti mettono in pausa la distribuzione delle metriche.

  • COMPLETED: uno stato terminale che indica che la ricerca ha soddisfatto correttamente l'allocazione target max_programs o ha raggiunto il limite di generazione strutturale.

  • FAILED: uno stato di errore terminale che indica che l'esecuzione del trattamento è stata interrotta a causa di problemi sistemici dell'ambiente, ad esempio eccezioni non rilevate delle credenziali API, danneggiamento dell'archivio dati o panico consecutivo del runner.

Stati del programma

La sequenza di convalida in fase di runtime viene applicata alle singole varianti candidate.

Ogni mutazione del codice generato si comporta come un'entità di programma isolata che passa attraverso una sequenza di stati operativi granulari all'interno del database della popolazione.

  1. INITIALIZED: la voce del programma viene creata nel database, monitorando la sua genealogia ancestrale e i collegamenti al programma genitore.

  2. GENERATING: un'attività viene inviata attivamente al backend del mix di modelli linguistici per creare o modificare i blocchi di codice funzionali specifici.

  3. EVALUATING: il payload del codice è bloccato da un processo di valutazione del worker ed eseguito all'interno di un ambiente di test harness isolato.

  4. COMPLETED: i punteggi di esecuzione e gli approfondimenti strutturali descrittivi vengono salvati in modo sicuro nel database evolutivo e il programma viene aggiunto al pool di selezione.

Meccanismi di concorrenza e blocco

I programmi vengono acquisiti dai loop dei worker utilizzando un meccanismo di token di blocco atomico per evitare condizioni di competizione o sovraccarico di punteggio duplicato nelle topologie distribuite. Il valutatore deve inviare lo schema di punteggio finalizzato insieme al token di blocco della corrispondenza esatta per eseguire il commit dei risultati nel database.

Schemi di configurazione e impostazioni

Panoramica delle configurazioni, dei parametri e dei valori predefiniti dello schema principale utilizzati dal runtime del motore AlphaEvolve.

AlphaEvolveExperimentConfig

Definisce i parametri strutturali principali e i vincoli programmatici dell'esperimento evolutivo eseguito.

Nome campo Tipo Predefinito Vincoli / Limiti di valore Descrizione tecnica
title string Obbligatorio Massimo 256 caratteri Nome visualizzato univoco dell'esperimento.
problemDescription string Obbligatorio Massimo 5000 caratteri La specifica formale del problema. Viene inserito direttamente nei contesti dei prompt per stabilire le regole.
programmingLanguage string Obbligatorio Valore in formato libero Lingua di destinazione del codebase evoluto (ad esempio, "python", "cpp", "verilog", "cuda", "julia", "java").
runSettings oggetto Obbligatorio Mappa allo schema RunSettings Parametri di pacing e timeout.
generationSettings oggetto Obbligatorio Mappa allo schema GenerationSettings Selezione del modello e parametri di contesto.
evolutionSettings oggetto Obbligatorio Mappa allo schema EvolutionSettings Parametri di selezione dei genitori e di diversità.
notes string Obbligatorio Massimo 1000 caratteri Annotazioni facoltative per la documentazione dell'esecuzione.

RunSettings

Regola la velocità effettiva, i limiti di parallelizzazione e i timeout automatici del sistema.

Nome campo Tipo Predefinito Vincoli / Limiti di valore Descrizione tecnica
maxPrograms int32 100 Min: 1, Max: 100000 Budget totale di esecuzione (programmi da generare e valutare).
concurrency int32 1 Min: 1, Max: 30 Numero di mutazioni di programmi paralleli attive nella coda. Non sono consentiti valori superiori a 30.
maxDuration string null Stringa dayTimeDuration ISO 8601
Min: >=0, Max: 7 giorni		 Tempo totale di esecuzione consentito prima dell'interruzione dell'esperimento.
idleTimeout string null Stringa dayTimeDuration ISO 8601
Min: >=0, Max: 24 ore		 Durata dell'inattività prima della transizione automatica a "PAUSA".

Impostazioni di generazione

Lo schema GenerationSettings controlla l'assemblaggio dei prompt, le finestre contestuali e le configurazioni del modello per le mutazioni:

  • context (stringa): documentazione di riferimento, API supplementari o regole facoltative fornite dall'utente. È vivamente consigliato di non superare i 200.000 token. Le dimensioni del contesto superiori a 200.000 token diluiscono l'attenzione del modello e peggiorano la qualità della mutazione.

  • includeFullProgramInPrompt (booleano): valore predefinito false.

    • true: il prompt di mutazione include # EVOLVE-BLOCK modificabile e il boilerplate immutabile circostante (altamente consigliato per ragionamenti strutturali complessi).

    • false: è visibile solo il blocco modificabile, salvando il contesto del token.

Impostazioni di evoluzione

Lo schema EvolutionSettings controlla la generazione di nuovi valori del modello a isole e le probabilità di campionamento del modello principale:

  • parentSamplingConfig → paretoSamplingConfig → paretoSamplingProbability (float): la probabilità (da 0,0 a 1,0) di campionare i programmi principali direttamente dalla frontiera di Pareto attiva anziché utilizzare la selezione standard basata sul fitness. Questo parametro deve essere impostato su 0.0 (disattivato) se le metriche ottimizzate restituiscono una sola metrica scalare.

Modelli di dati dei programmi candidati

Questa sezione descrive gli schemi e le rappresentazioni dei dati utilizzati per definire e organizzare le strutture del codice candidato all'interno del database della popolazione.

AlphaEvolveProgramContent

Definisce i file e la composizione strutturale del programma candidato.

  • files (array di AlphaEvolveSourceFile): un elenco di tutti i file che compongono la base di codice candidata. Questa raccolta è rigorosamente limitata a un massimo di 50 file per programma candidato.

  • description (stringa): un riepilogo generato automaticamente che descrive le modifiche programmatiche suggerite dal modello di generazione (max 1000 caratteri).

AlphaEvolveSourceFile

Rappresenta un singolo file di codice sorgente nel codebase.

  • path (stringa): il percorso di destinazione relativo allo spazio di lavoro (massimo 256 caratteri). Se configuri un workspace Python, il punto di ingresso del file eseguibile principale deve essere denominato esattamente "initial_program.py".

  • content (stringa): la stringa del codice sorgente non elaborato che comprende i blocchi di implementazione funzionale. L'impronta totale del codebase cumulativo combinata in tutti i file deve essere inferiore a 4000-5000 righe di codice (LOC).

  • programLanguage (stringa): il tag di mappatura del parser della lingua. Questa stringa deve corrispondere esplicitamente alla lingua designata nella configurazione dell'esperimento principale.

  • description (stringa): un riepilogo facoltativo che delinea l'architettura o lo scopo individuale del file, che viene esposto al LLM durante i passaggi di mutazione (max 500 caratteri).

AlphaEvolveProgramEvaluation

Il payload strutturato inviato dalle istanze del runner client al database evolutivo dopo l'esecuzione del runtime.

  • scores (AlphaEvolveScores): valori numerici standardizzati e oggettivi delle metriche. Le best practice prevedono di limitare questo valore a 3-5 metriche distinte; un numero eccessivo di dimensioni target peggiora le prestazioni del comparatore Pareto multi-obiettivo.

  • insights (array di AlphaEvolveEvaluationInsight): etichette semantiche diagnostiche e tracce di esecuzione in linguaggio naturale restituite per assistere i successivi tentativi di generazione di mutazioni dell'LLM (massimo 10 elementi consigliati).

Formati di formulazione e importazione dei punteggi

Regola di massimizzazione

AlphaEvolve funziona fondamentalmente come un algoritmo di ricerca locale monotono e massimizza rigorosamente tutte le metriche numeriche. Se la pipeline di valutazione monitora un target di minimizzazione (ad esempio, la minimizzazione della latenza dell'applicazione in millisecondi o la riduzione dell'utilizzo della memoria), devi negare il valore prima di inviarlo di nuovo al database: submitted_score = -latency_ms.

Idealmente, i punteggi dovrebbero essere continui. Le metriche booleane o altamente discrete non forniscono un segnale di gradiente sufficiente per un'esplorazione efficace.

Schema di importazione con un solo obiettivo

Utilizza il seguente JSON quando l'evaluation harness esegue l'ottimizzazione in base a una singola funzione obiettivo scalare.

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

Schema di importazione multi-obiettivo

Utilizza il seguente JSON quando trasmetti parametri di monitoraggio multi-obiettivo indipendenti per attivare le routine di ottimizzazione della frontiera di Pareto lato server.

{
  "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."
      }
    ]
  }
}

Recupero ed esecuzione di query sui dati dei programmi

Il sistema AlphaEvolve registra la telemetria, le metriche di esecuzione e il codice sorgente completo di ogni mutazione generata, consentendo agli sviluppatori di eseguire query su questo datastore storico utilizzando l'API o la CLI per monitorare l'avanzamento dell'ottimizzazione ed estrarre i candidati al codice con il rendimento migliore.

Recupero dei programmi tramite l'API REST

È possibile eseguire query sulle risorse del programma valutate dal database utilizzando l'endpoint ListAlphaEvolvePrograms standard con parametri di query di filtro e ordinamento:

  • Filtro per stato: esegui query sui programmi che corrispondono a uno stato del ciclo di vita specifico:

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

  • Ordinamento basato sulle metriche: recupera i candidati ordinati in base alle metriche ottimizzate:

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

Recupero dei programmi tramite l'interfaccia a riga di comando

Per estrarre i candidati con il maggior numero di completamenti direttamente dal terminale, esegui il seguente comando:

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

Esempi completi di utilizzo dell'interfaccia a riga di comando

La CLI AlphaEvolve offre agli sviluppatori un controllo amministrativo rapido e il monitoraggio delle campagne direttamente dalla shell:

  • Elenca tutti gli esperimenti in una sessione conversazionale:

    ae experiment list

  • Elenca tutti i programmi candidati mutati per un esperimento specifico:

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

    Sostituisci EXPERIMENT_NICKNAME con il nome dell'esperimento.

  • Recupera i candidati di codice completati con il rendimento migliore:

    ae results best EXPERIMENT_NICKNAME --top 5

    Sostituisci EXPERIMENT_NICKNAME con il nome dell'esperimento.

  • Riprendere una campagna in pausa:

    ae experiment resume EXPERIMENT_NICKNAME

    Sostituisci EXPERIMENT_NICKNAME con il nome dell'esperimento.

Directory degli endpoint API REST principali

Tutti gli endpoint sono versionati in v1alpha dell'API Discovery Engine. Google Cloud

Pattern del percorso della risorsa padre

L'URI della risorsa padre nidificata è strutturato come segue: projects/{project}/locations/{location}/collections/{collection}/ engines/{engine}/sessions/{session}

Crea esperimento (POST)

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

  • Corpo della richiesta: AlphaEvolveExperimentConfig (vedi la sezione 2.1)

  • Risposta: risorsa AlphaEvolveExperiment contenente la campagna inizializzata.

  • Stato HTTP: 200 OK

Esempi di payload dell'API

  1. Esempio di corpo della richiesta (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. Esempio di corpo della risposta (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
        }
      }
    }
  }
}

Avvia esperimento (POST)

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

  • Corpo della richiesta: StartExperimentRequest

  • Avviso di ritiro:il campo del corpo initialProgram è ritirato e ignorato.

  • Risposta: GoogleLongrunningOperation (LRO).

  • Stato HTTP:200 OK (lo stato di transizione da CREATED a RUNNING)

Esempi di payload dell'API

  1. Esempio di corpo della richiesta

    {
  "desiredProgramsCount": 1
}

  2. Esempio di corpo della risposta (200 OK - operazione a lunga esecuzione)

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

Acquisire programmi (POST)

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

  • Corpo della richiesta: AcquireProgramsRequest

    • desiredProgramsCount (int32): conteggio batch facoltativo dei programmi mutati da recuperare (il valore predefinito è 1 se non impostato).

  • Stati delle risposte:

    • 200 OK: restituisce la risposta contenente le risorse AlphaEvolveProgram bloccate.

    • 204 No Content: la coda è vuota o la campagna è in pausa. I corridori devono dormire (ad esempio, 15 secondi) e riprovare.

Esempi di payload dell'API

  1. Esempio di corpo della richiesta

    {
  "desiredProgramsCount": 1
}

  2. Esempio di corpo della risposta (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. Esempio di corpo della risposta (204 No Content)

Codice di stato HTTP 204 restituito con un contesto di payload vuoto.

Invia valutazioni dei programmi (POST)

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

  • Corpo della richiesta: SubmitProgramsEvaluationsRequest

    • evaluationSubmissions (array): contiene lockToken corrispondenti, il percorso della risorsa di programma qualificata e il payload di valutazione (punteggi e insight).

  • Risposta: SubmitProgramsEvaluationsResponse (vuota).

  • Stato HTTP: 200 OK (salva i punteggi, rilascia il blocco attivo e registra gli approfondimenti)

Esempi di payload dell'API

  1. Esempio di corpo della richiesta

    {
  "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. Esempio di corpo della risposta (200 OK)

    {}

Riprendi esperimento (POST)

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

  • Corpo della richiesta: ResumeExperimentRequest

  • Risposta: GoogleLongrunningOperation (LRO).

  • Stato HTTP:200 OK (lo stato di transizione da PAUSED a RUNNING)

Esempi di payload dell'API

  1. Esempio di corpo della richiesta

    {}

  2. Esempio di corpo della risposta (200 OK - operazione a lunga esecuzione)

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

Elenca programmi (GET)

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

  • Parametri di query:

    • stateFilter (stringa): facoltativo. Filtro standard dell'elenco, ad esempio stateFilter = 'COMPLETED'.

    • orderBy (stringa): facoltativo. Ordinamento basato sulle metriche, ad esempio accuracy desc.

  • Risposta: ListAlphaEvolveProgramsResponse.

  • Stato HTTP: 200 OK

Esempi di payload dell'API

  1. Esempio di URL di query della richiesta

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

  2. Esempio di corpo della risposta (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"
}

Codice diagnostico e riferimento per la risoluzione dei problemi

Matrice dei codici diagnostici API

Stato HTTP Tipo di errore Causa di sistema Soluzione alternativa o azione di mitigazione
400 INVALID_ARGUMENT Tag di commento # EVOLVE-BLOCK-START / # EVOLVE-BLOCK-END mancanti; sintassi dello schema JSON non valida; limiti di file o LOC superati. Verifica che i commenti a blocchi siano inseriti all'interno dei corpi delle funzioni utilizzando una sintassi valida della lingua di destinazione. Verifica che il conteggio dei file e i limiti LOC siano rispettati.
403 PERMISSION_DENIED L'utente o il account di servizio non dispone del ruolo Utente Discovery Engine o di una licenza Gemini Enterprise assegnata. Verifica le licenze Gemini Enterprise attive. Assicurati che le credenziali predefinite dell'applicazione siano configurate correttamente per sia l'utente che il progetto eseguendo:

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

Nota:Model Armor non è supportato nelle configurazioni AlphaEvolve.
408 LOCK_TIMEOUT Il runner client ha superato la durata di esecuzione; il blocco del programma è scaduto nella coda. Applica timeout lato client rigorosi di 30 minuti. Se superato, invia immediatamente i punteggi di penalità per mancata esecuzione per sbloccare la coda.
429 RESOURCE_EXHAUSTED Superamento dei limiti di esecuzione simultanea attiva o delle quote del modello. Implementa il backoff esponenziale lato client; configura impostazioni di concorrenza conservative all'interno di RunSettings.
503 SERVICE_UNAVAILABLE Servizio di backend sovraccarico o in fase di manutenzione. Implementa un ciclo di nuovi tentativi con backoff esponenziale randomizzato sul lato client.

Correzione dei "rilasci silenziosi"

Un'intercettazione del filtro di sicurezza (eliminazione silenziosa) si verifica quando i modelli linguistici lato server contrassegnano ed eliminano i prompt candidati mutati a causa di formulazioni sensibili o attivazioni di regole di sicurezza. Il server disattiva l'output, facendo sì che la coda restituisca risposte vuote e i runner client potrebbero attendere a tempo indeterminato.

Correzione della soluzione temporanea:

  • Sanitizza il contesto: rimuovi frasi cariche di emotività o sensibili alla sicurezza da problemDescription.

  • Approfondimenti sui filtri:analizza e tronca le tracce di eccezioni non elaborate o i log stderr del terminale nel payload insights per evitare di riprodurre contenuti di sistema non sicuri che attivano filtri downstream.

  • Localizza i set di dati:non inserire record di addestramento o grandi corpora di testo all'interno dei prompt; caricali localmente nell'ambiente client durante l'esecuzione del ciclo di valutazione.

Best practice per la valutazione lato client

Il collo di bottiglia del "codice spaghetti"

La formattazione non ottimale del codice sorgente peggiora la qualità dell'ottimizzazione: "Spaghetti code == Noisy search space". Prima di inserire i marcatori EVOLVE-BLOCK:

  • Riorganizza i blocchi di codice in modo che le variabili e le firme delle funzioni siano denominate in modo chiaro.

  • Aggiungi docstring descrittive e concise che spieghino cosa fa e perché ogni funzione o variabile.

  • Assicurati che tutte le dipendenze esterne e immutabili (come l'importazione di moduli helper o il caricamento di dati statici) si trovino al di fuori di # EVOLVE-BLOCK.

Allocazione della finestra contestuale

Per massimizzare la creatività delle mutazioni, limita il payload del codice inviato all'API. Il contesto totale del programma deve rimanere tra 150.000 e 200.000 token. Grandi blocchi di boilerplate statici e immutabili consumano l'attenzione del modello e peggiorano le prestazioni. Sposta gli script di utilità, le pipeline di importazione dati e le librerie di convalida pesanti interamente nell'evaluator lato client.

Inizializza prima il programma iniziale

Prima di eseguire AlphaEvolve, utilizza un agente di codifica standard per eseguire il debug sia della base di codice iniziale sia del valutatore:

  • Prepara il seme:correggi i bug di sintassi evidenti, i problemi di compilazione e i casi limite.

  • Verifica il punteggio iniziale:verifica che il punteggio di base sia ragionevole e che il valutatore sia completamente deterministico (stesso codice + stesso input = stesso punteggio).

  • Test con input non validi:esegui il valutatore con funzioni intenzionalmente danneggiate per verificare che rilevi i problemi del compilatore, gestisca correttamente i cicli infiniti e restituisca punteggi di penalità negativi elevati.

Evitare baseline eccessivamente ottimizzate

Non utilizzare come seme un programma di base già altamente ottimizzato. Se il tuo programma iniziale è già quasi ottimale, AlphaEvolve avrà difficoltà a eseguire la ricerca locale perché c'è pochissimo margine di miglioramento. Inizia con una baseline ragionevole, ma non ottimizzata al massimo. In questo modo, AlphaEvolve ha spazio per esplorare e trovare la soluzione migliore.

Misure di salvaguardia per l'esecutore lato client

Gli valutatori lato client devono applicare salvaguardie rigorose per impedire che candidati dannosi, che richiedono molte risorse o che non rispondono blocchino i worker paralleli:

  • Timeout rigorosi:impone un limite di esecuzione rigoroso di 30 minuti (o meno, a seconda della struttura dello spazio di ricerca).

  • Invio della penalità per timeout: se una variante del programma candidato supera il limite di timeout, termina immediatamente il thread di esecuzione. Non consentire l'interruzione del processo candidato. Compila e invia immediatamente un punteggio di penalità per errore grave (ad esempio -100000.0) insieme a un insight di debug descrittivo al server per sbloccare la coda del programma.

  • Filtri di sicurezza AST:esegui sempre un controllo di ispezione dell'Abstract Syntax Tree (AST) sul payload del codice sorgente in entrata prima della compilazione. Interrompi immediatamente l'esecuzione e applica una penalità per errore grave se vengono rilevati primitivi di esecuzione o reflection con limitazioni (ad esempio eval, exec, getattr o setattr).

Ulteriori risorse

Per maggiori informazioni, consulta le seguenti risorse: