Trasformazione del problema: dalla scelta dell'algoritmo al processo esplorativo

Nelle applicazioni reali del calcolo evolutivo, un errore di partenza comune è chiedersi subito, davanti a un compito: «Devo usare DE o PSO?». Questa domanda mettela scelta dell'algoritmoall'ingresso della risoluzione, ma risponde solo a «con quale strumento cercare», non a «che cosa cercare, che cosa è buono, che cosa non si può assolutamente violare». Ciò che determina davvero il successo o il fallimento èla qualità della definizione del problema.

La cosiddettatrasformazione del problemaconsiste nel riscrivere «quale algoritmo scegliere» come «progettare un processo esplorabile»: prima si chiarisce che cosa può cambiare nel problema reale, come valutare i cambiamenti e quali vincoli devono essere soddisfatti; poi si lascia che l'algoritmo generi e selezioni iterativamente i candidati in questo spazio di ricerca. La scelta dell'algoritmo diventa così una fase della progettazione del processo esplorativo, non il suo punto di partenza.

Quattro definizioni da stabilire prima di tutto

Oggetti variabili: stabilisce quali parametri, strutture, strategie o processi possono essere modificati, definendo così lo spazio di ricerca e i confini della codifica. Senza di esso, le soluzioni candidate non possono essere rappresentate né generate.
Metodo di valutazione: definisce come giudicare la bontà dei cambiamenti, includendo funzione obiettivo, metriche di valutazione, direzione delle preferenze e misure di fattibilità e diversità. Il modo in cui si valuta determina di fatto la direzione della ricerca.
Vincoli fondamentali: distingue i vincoli rigidi, che devono essere soddisfatti, dalle preferenze flessibili, che ammettono compromessi. Mescolare i vincoli rigidi nella funzione obiettivo «scontandoli» porta facilmente a soluzioni apparentemente ben valutate ma di fatto non implementabili.
Processo esplorativo: formalizza il problema come un ciclo chiuso «generazione dei candidati — valutazione — feedback — rigenerazione», in cui i risultati della valutazione influenzano la generazione successiva, invece di fissare l'approccio risolutivo una volta per tutte.

La differenza introdotta dalla trasformazione

Di fronte a un compito di ottimizzazione di parametri, l'approccio abituale è «scegliere prima un algoritmo — ad esempio DE o PSO — e poi iniziare a tarare i parametri». Dopo la trasformazione, l'approccio consiste nel rispondere in sequenza a tre domande: quali parametri sono regolabili? Con quali metriche (o quali metriche in conflitto tra loro) valutarli? Quali vincoli non possono assolutamente essere violati? Una volta risposto a queste tre domande, il compito è già stato formalizzato come un problema multi-obiettivo collegabile a un risolutore evolutivo; a quel punto decidere quale algoritmo usare e con quale configurazione di operatori esplorare è solo una decisione ingegneristica sostituibile all'interno del ciclo chiuso. In altre parole, l'algoritmo non è la risposta in sé: è solo una componente configurabile del processo esplorativo, mentre è la qualità della definizione del problema a determinare il limite superiore dell'esplorazione.

Errori comuni

Attribuire lo «scarso rendimento dell'algoritmo» direttamente all'algoritmo stesso, trascurando tre aspetti più fondamentali: una definizione vaga dello spazio di ricerca, metriche di valutazione scollegate dai reali obiettivi di business e l'assenza di vincoli rigidi. Correggere prima la definizione del problema e solo dopo parlare di sostituzione dell'algoritmo è spesso più efficace che cambiare algoritmo ripetutamente.

Il processo di trasformazione del problema

La figura riscrive il compito risolutivo da «prima DE o PSO?» a un processo esplorabile: prima si delineano oggetti variabili, metodo di valutazione e vincoli fondamentali, poi generazione dei candidati, valutazione, feedback e rigenerazione formano un ciclo chiuso. La scelta dell'algoritmo è quindi solo una componente sostituibile all'interno del ciclo chiuso: è la qualità della definizione del problema a determinare il limite superiore dell'esplorazione.

Domanda 1

Quando si trasforma «quale algoritmo scegliere» in «progettare un processo esplorabile», che cosa bisogna chiarire per prima cosa?

Stabilire quali parametri, strutture, strategie o processi possono essere modificati, definendo lo spazio di ricerca e i confini della codifica

Fissare prima la dimensione della popolazione a 100

Decidere prima se usare DE o PSO

Determinare prima il numero totale di generazioni

Domanda 2

Quale delle seguenti descrizioni del ruolo del «metodo di valutazione» nella trasformazione del problema è la più accurata?

Il metodo di valutazione è determinato automaticamente dall'algoritmo scelto ed è indipendente dal compito

Il metodo di valutazione deve definire come giudicare la bontà dei cambiamenti, includendo funzione obiettivo, metriche, preferenze e misure di fattibilità e diversità

Il metodo di valutazione va calcolato una sola volta, all'ultima iterazione

Il metodo di valutazione consiste nel massimizzare l'accuratezza: non servono altre metriche

Domanda 3

Un servizio online richiede, per il deployment, che «la latenza P99 non superi gli 80 millisecondi». Nella trasformazione del problema, a quale categoria appartiene?

Una dimensione di codifica dello spazio di ricerca

Un vincolo rigido da soddisfare: nessuna soluzione prodotta dall'esplorazione può violarlo

Una preferenza flessibile, negoziabile e rinunciabile se necessario

Un bonus nella funzione obiettivo

Domanda 4

Qual è la differenza chiave tra formalizzare il problema come ciclo chiuso «generazione dei candidati — valutazione — feedback — rigenerazione» e la scelta dell'algoritmo fatta una volta per tutte?

Il ciclo chiuso è sicuramente più veloce dal punto di vista computazionale rispetto a una scelta unica

Il ciclo chiuso fa sì che i risultati della valutazione modifichino la generazione successiva, adattando continuamente la direzione della ricerca invece di fissarla fin dall'inizio

Il ciclo chiuso non richiede più di definire alcun vincolo

Il ciclo chiuso può esistere solo se si usano algoritmi di tipo populazionale

Domanda 5

Perché si afferma che «l'algoritmo non è la risposta in sé»?

Perché nell'implementazione degli algoritmi ci sono sempre difetti

Perché è la qualità della definizione del problema a determinare il limite superiore dell'esplorazione, mentre l'algoritmo è solo una componente configurabile e sostituibile del processo esplorativo

Perché gli algoritmi sono instabili se eseguiti su hardware parallelo

Perché gli algoritmi evolutivi convergono inevitabilmente verso un ottimo locale

Caso di studio: ottimizzazione multi-obiettivo di un modello di ranking per le raccomandazioni

Leggi il seguente scenario, riscrivi il compito da «scegliere l'algoritmo» a «progettare un processo esplorabile» e rispondi a due domande.

Un sistema di raccomandazione online deve ottimizzare il proprio modello di ranking. Gli oggetti regolabili includono: tasso di apprendimento, coefficiente di regolarizzazione, numero di livelli di rete, numero di attention head e strategia di combinazione delle feature. Il team vuole migliorare al contempo l'AUC offline e ridurre il costo di inferenza online. Le metriche disponibili sono: AUC offline sul set di validazione, latenza P99 di inferenza online, numero di parametri del modello, numero di feature. I requisiti di deployment noti sono: latenza P99 non superiore a 80 millisecondi, occupazione di memoria GPU non superiore a 12GB e modello finale direttamente distribuibile sul framework di inferenza esistente. Nel rispetto di questi requisiti, il team preferisce modelli con meno parametri e latenza inferiore. Al momento il dibattito nel team si concentra su: usare DE o PSO?

1. Riscrivi il compito come definizione del problema «oggetti variabili — metodo di valutazione — vincoli fondamentali», indicando chiaramente quali sono vincoli rigidi e quali preferenze flessibili.

Risposta:
Oggetti variabili (spazio di ricerca e codifica): tasso di apprendimento, coefficiente di regolarizzazione, numero di livelli di rete, numero di attention head, strategia di combinazione delle feature — queste grandezze continue e strutture discrete costituiscono insieme la codifica delle soluzioni candidate. Metodo di valutazione: si tratta di un problema multi-obiettivo — l'AUC offline va massimizzata, mentre la latenza P99 online e il numero di parametri del modello vanno minimizzati; inoltre la diversità tra candidati può fungere da metrica aggiuntiva. Poiché tra AUC e latenza esiste un evidente conflitto di obiettivi, il risultato della valutazione deve essere un insieme di candidati, non un punteggio unico. Vincoli fondamentali: latenza P99 ≤ 80 millisecondi, memoria GPU ≤ 12GB, distribuzione diretta sul framework di inferenza esistente: questi tre sono vincoli rigidi da soddisfare, e qualunque soluzione candidata che li violi è non fattibile. Preferenze flessibili: «meno parametri, latenza inferiore» è una preferenza negoziabile nel rispetto dei vincoli rigidi, utile per ordinare le soluzioni fattibili, non per filtrarle.

2. Perché non si dovrebbe chiedere subito «DE o PSO?». Descrivi come organizzare il compito in un processo esplorativo a ciclo chiuso e spiega come garantire che i risultati siano implementabili.

Risposta:
La scelta dell'algoritmo è una fase interna alla progettazione del processo, non il punto di partenza della risoluzione: finché spazio di ricerca, metodo di valutazione e vincoli non sono chiari, qualsiasi confronto tra algoritmi manca di una base comune, e discutere «DE o PSO» significa solo confrontare due processi esplorativi non ancora definiti. Organizzazione del ciclo chiuso: ① generazione dei candidati — campionamento di iperparametri e configurazioni strutturali nello spazio di ricerca; ② valutazione — calcolo parallelo dell'AUC sul set di validazione, misura o stima della latenza di inferenza e dell'occupazione di memoria GPU, con verifica dei vincoli rigidi; ③ feedback — aggiornamento della distribuzione di ricerca e della pressione selettiva in base al confronto multi-obiettivo e alle preferenze, concentrando le risorse nelle regioni più promettenti; ④ rigenerazione — produzione di una nuova generazione di candidati con la distribuzione aggiornata, in un ciclo continuo. Garanzia di implementabilità: trattare latenza P99, memoria GPU e compatibilità con il framework come vincoli rigidi, scartando direttamente le soluzioni non fattibili già in fase di generazione o valutazione, per evitare soluzioni «dalle metriche belle ma non distribuibili»; per metriche costose come la latenza si può prima filtrare con modelli surrogati o test su piccola scala, per poi validare completamente un numero ridotto di candidati. Il risultato finale è un insieme di soluzioni candidate ben distribuite sul compromesso tra obiettivi, da sottoporre alle decisioni di ingegneria e prodotto; la scelta dell'algoritmo specifico (DE, PSO o strategia ibrida) è solo la selezione di una componente sostituibile all'interno del ciclo chiuso.