Sfide

Oltre lo scaling: i nuovi spazi di ottimizzazione per il progresso dell'IA

Di Marc Molas·26 maggio 2026·9 min di lettura

Nella Parte 1 abbiamo coperto perché lo scaling non è più un asse di progresso affidabile. Nella Parte 2 abbiamo passato in rassegna le quattro leve che guidano il tasso reale di rendimento per unità di compute. La chiusura naturale della serie — e la parte del saggio di Sara Hooker che ho trovato più energizzante — è la domanda: dove dovrebbe andare il campo adesso?

La risposta di Hooker è che stiamo entrando in un'era di spazi di ottimizzazione espansi. Gli informatici erano abituati ad avere una grande leva (addestrare un modello più grande con più dati) e questo era insieme abilitante e limitante. Il nuovo panorama ci dà un set molto più ampio di cose da ottimizzare, e molte di esse sono drammaticamente sotto-esplorate. Vediamo quelle che evidenzia, poi affrontiamo due chiarimenti importanti che fa in chiusura.

1. Esplorazione gradient-free: il compute in inference come leva di prima classe

Per gli ultimi 30 anni, il modo di rendere migliore un modello è stato aggiornare i suoi parametri. Più training, più dati, più pesi. La svolta in corso adesso è che molto compute viene speso in inference, non in training — e, cosa cruciale, gran parte di esso è gradient free, cioè il modello stesso non cambia.

Hooker raggruppa questa famiglia di tecniche come i nuovi spazi di ottimizzazione "compute light" e "gradient free" (la sua Figura 5 li separa esplicitamente):

Best-of-N sampling. Campiona più completion, le segna, restituisci la migliore.
Search e planning sopra le generazioni. Tree search, varianti di beam search, loop agentici che esplorano alternative.
Tool use. Un modello che può chiamare una calcolatrice, un database, un interprete di codice o un altro modello prende di fatto in prestito capacità che non deve memorizzare.
Retrieval-augmented generation. Già citata nella Parte 2 — vive in questa categoria.
Sciami agentici. Più istanze di modello che si coordinano per risolvere un problema che una sola non riuscirebbe a risolvere.
Model merging. Combinare i parametri di più modelli fine-tuned senza ulteriore training.
Compute adattivo. Spendere più compute in inference sui problemi difficili, meno su quelli facili.

La stima di Davidson et al. (2023) è il numero da copertina: tecniche in inference possono portare miglioramenti 5×–20× rispetto alla performance base post-training, con footprint minimo rispetto al costo del pre-training. È un rapporto di leva enorme, e oggi viene catturato dai team che hanno scelto di investire in questo strato invece di aspettare la prossima classe di taglia di modello.

L'implicazione strategica è sottile ma importante. Le tecniche in inference sono ingegneria, non training. Premiano i team che sanno consegnare, strumentare, valutare e iterare in fretta. Il collo di bottiglia si sposta da "hai abbastanza GPU per addestrare" a "hai abbastanza velocità ingegneristica per comporre, valutare e consegnare". Questa è genuinamente una buona notizia per le organizzazioni che non poggiano su una linea di capex da hyperscaler — che, di nuovo, è la maggior parte di noi.

2. Lo spazio malleabile dei dati

Il secondo nuovo spazio di ottimizzazione di Hooker è quello che chiama spazio malleabile dei dati, e potrebbe essere lo shift filosoficamente più interessante di tutto il saggio.

Per la maggior parte della storia dell'IA, i dataset sono stati artefatti congelati — MNIST, ImageNet, SQuAD, C4. Ne sceglievi uno, ci addestravi sopra, riportavi i numeri. Il dataset era uno snapshot del mondo che eri riuscito a raccogliere. L'assunzione fondamentale del machine learning era IID — campioni estratti in modo indipendente e identico da una distribuzione fissa. Accettavamo qualunque cosa il mondo ci consegnasse.

Cosa cambia quando la generazione di dati sintetici diventa abbastanza economica da trattare i dati stessi come qualcosa che si ottimizza?

Puoi orientare la distribuzione verso ciò che vuoi davvero — incluse capacità, lingue, edge case, bilanciamento demografico — invece di accettare ciò che il corpus si trova a contenere.
Puoi bersagliare direttamente la long tail. Se il tuo modello è debole su una categoria specifica, puoi generare o sintetizzare esempi per essa invece di sperare che il prossimo scrape ne contenga di più.
Puoi ridurre il gap fra distribuzione in training e distribuzione in inference. Storicamente c'è stato un mismatch cronico: i dati di training sono determinati da ciò che riuscivi a raccogliere; gli input in inference sono determinati da ciò che gli utenti fanno davvero. I dati sintetici possono chiudere quel gap deliberatamente.
Puoi rendere visibili popolazioni invisibili. La linea di lavoro Aya (Aryabumi et al. 2024; Üstün et al. 2024; Dang et al. 2024b) riguarda in gran parte l'uso di dati sintetici e traduzione per dare copertura multilingue che il web aperto non fornisce.

È una rottura netta con "campioni IID dalla natura". Siamo ora in grado di inclinare intenzionalmente la distribuzione verso ciò che speriamo di rappresentare, invece di accettare un campione casuale di ciò che è. È sia una capacità enorme sia una responsabilità enorme — i dati sintetici fatti male compongono il bias invece di sistemarlo.

Per i team di prodotto, il takeaway pratico è che dovreste trattare i vostri dati di training/fine-tuning come una cosa che progettate, non una cosa che raccogliete. Se il tuo modello è debole su una slice che conta, hai una leva che cinque anni fa non esisteva.

3. Design e interfaccia

Il terzo spazio di ottimizzazione che Hooker mette in evidenza è quello per cui la maggior parte degli informatici è meno attrezzata: come il sistema interagisce con il mondo.

Il sistema più intelligente sarà sempre più definito dal costruire un algoritmo che possa interagire con il mondo. Significa che per la prima volta i ricercatori che si curano dell'intelligenza devono essere ossessionati anche da come un modello interagisce. Quello che era prima il dominio ristretto di UX designer, artisti e specialisti di interazione uomo-macchina dovrebbe ora essere di grande interesse per tutti gli informatici.

Questo atterra duro perché inverte un assunto culturale di lunga data. Il progresso dell'IA è stato storicamente vincolato dall'algoritmo e ha trattato l'interfaccia come un wrapper. Hooker sta dicendo che l'interfaccia sta diventando parte dell'algoritmo — e i sistemi più capaci saranno sistemi multi-componente la cui intelligenza emerge da come i componenti sono composti e da come toccano il mondo, non dal fatto che un singolo modello diventi più grande.

Si lega all'onda dei sistemi agentici ma la riformula. I sistemi agentici interessanti non sono "modello più grande + tool". Sono superfici di interazione progettate con cura: dove il modello prende informazioni, dove può agire, cosa viene mostrato all'umano, cosa l'umano approva, come il feedback scorre indietro. È HCI, product design e systems engineering — ed è esattamente il tipo di lavoro che è stato storicamente sottovalutato nei lab di IA.

Per chiunque consegni feature IA in prodotto, è una buona notizia. La disciplina che hai già in UX, in trust-and-safety review, nel design dei workflow, nell'architettura human-in-the-loop — è ora lavoro IA di prima classe. Non è più un wrapper attorno alla capacità "vera".

Cosa questo non significa: il chiarimento ambientale

Hooker sta attenta a tagliare la strada a una specifica lettura sbagliata del saggio, e voglio ripeterlo perché è importante. La morte lenta dello scaling del compute di training non significa che l'impronta ambientale dell'IA si stia restringendo. È l'opposto:

La maggioranza dei requisiti energetici dei workload IA non sta nel training, ma nel costo di produzionizzare un workload ML e servirlo a miliardi di utenti. Anche se la dimensione del modello tende a calare, l'adozione diffusa dell'IA significa che i requisiti energetici complessivi probabilmente continueranno a salire.

In altre parole: modelli più piccoli e più performanti vengono deployati in molti più posti, quindi l'impronta aggregata di energia e acqua dell'IA continua a crescere anche se il costo di training per-modello potenzialmente si appiattisce. Le linee di lavoro di Strubell et al. (2019a), Patterson et al. (2021), Luccioni et al. (2025) e Wu et al. (2022) sono ancora portanti. Semmai, il futuro inference-heavy che Hooker descrive rende l'efficienza di serving, l'utilizzazione dell'hardware e il deployment carbon-aware più importanti, non meno.

Ho scritto in passato delle regioni operative sovrane fattibili su questa stessa tensione — che la storia del costo dell'IA è sempre più determinata dall'infrastruttura di serving, non dal training. Il framing di Hooker lo rafforza.

Torneremo mai allo scaling?

La risposta di Hooker qui è misurata e vale la pena citarla:

Finché siamo bloccati con i transformer come architettura non ha senso continuare a scalare il compute. La nostra architettura attuale mostra tutti i segni di plateau nei rendimenti da compute aggiuntivo. Mentre il progresso ha ruotato attorno alle deep neural network per l'ultimo decennio, molto suggerisce che il prossimo passo significativo richiederà un'architettura interamente diversa.

L'implicazione è che lo scaling tornerà quando arriverà una nuova architettura che rompe la curva attuale dei rendimenti e ne apre una nuova — esattamente come hanno fatto i transformer nel 2017. Ma scalare l'architettura attuale è, sempre di più, capex che insegue rendimenti decrescenti. I lab di frontiera che guideranno la prossima ondata non saranno quelli che hanno scalato più duro. Saranno quelli che avranno scommesso su un paradigm shift.

Cosa porto a casa dall'intera serie

Tre fili tratti dal saggio di Hooker che credo contino di più per chiunque consegni IA nel 2026:

Il lavoro interessante è tornato nelle mani degli ingegneri. Per un decennio, il progresso IA è stato la storia di chi poteva permettersi più compute. Lo shift verso tecnica algoritmica, design dei dati, compute in inference e interfaccia significa che la differenziazione interessante torna a essere giudizio ingegneristico — scelta dell'architettura di retrieval, curation dei dati di training, design dei loop di agente, struttura dello human-in-the-loop. È territorio recuperabile per team che non hanno un budget di training da 100M$.
Gli assunti dominanti su policy e capex invecchiano veloce. Soglie di compute nella legislazione, framework di "responsible scaling", roadmap vendor basate su "l'anno prossimo, più grande" — sono tutti artefatti di un assunto ora empiricamente debole. Qualsiasi piano che dipenda da loro merita una rilettura.
La prossima architettura è il premio. Catastrophic forgetting, sample inefficiency, l'incapacità di specializzare regioni di conoscenza — sono i problemi duri che l'architettura attuale non sa risolvere. Chiunque li risolva resetta il campo. È una scommessa molto più interessante di "più parametri".

Hooker chiude il saggio con una citazione di Turing che calza al momento: "Possiamo vedere solo una breve distanza davanti, ma vediamo molto là che ha bisogno di essere fatto." La ragione per cui atterra è che, per un lungo tratto, l'informatica si è sentita come se non avesse molto da fare — aveva una cosa da fare, molto costosamente. Siamo finalmente dall'altra parte. La vista da qui è più incerta, ma il lavoro è di nuovo più interessante.

Questo è il post finale della serie. La Parte 1 ha coperto perché più grande non è più sempre meglio. La Parte 2 ha attraversato cosa guida davvero il tasso di rendimento sul compute.

Riferimento: Sara Hooker, On the slow death of scaling, 2025.