#LLM #AI #Development

Dal budget fisso al reasoning adattivo: come far pensare meglio (e non di più) i LLM

Negli ultimi mesi ho visto team spremere i modelli con prompt sempre più lunghi, temperature esoteriche e sampling a pioggia. Funziona finché la carta di credito regge. Il punto è che molte pipeline usano un budget fisso per ogni query: stesso numero di campioni, stessi passaggi di ragionamento, stessa profondità. È comodo, ma inefficiente. Un problema facile merita poche risorse; uno davvero duro, il contrario.

Il collo di bottiglia dei budget fissi

L’inference-time scaling ha reso i LLM più affidabili sui problemi complessi: generi più tracce di ragionamento, valuti, selezioni e prosegui. Il difetto? È spesso statico: decidi a priori quante tracce e quanti step. Risultato: sprechi compute sulle domande ovvie e resti corto su quelle che richiedono esplorazione.

Illustrazione di percorsi di ragionamento che si diramano e si riducono dinamicamente

La proposta del MIT: instance-adaptive scaling con PRM calibrati

Un gruppo del MIT (Navid Azizan, Young-Jin Park, Kristjan Greenewald, Kaveh Alim, Hao Wang) ha presentato un metodo che regola durante l’inferenza quante ipotesi generare e quanto spingersi in profondità. La chiave è un Process Reward Model (PRM) che valuta le soluzioni parziali e, soprattutto, è calibrato: invece di un numero secco, fornisce un intervallo di probabilità, cioè un’incertezza attendibile.

Con questo segnale, il modello allarga o restringe il ventaglio di percorsi. Se è fiducioso, riduce rami e passi; se l’incertezza sale, investe più compute. Nei test su ragionamento matematico, l’approccio ha usato fino a la metà del calcolo rispetto ai metodi standard, a parità di accuratezza. In diversi casi, modelli più piccoli hanno eguagliato o superato modelli più grandi su problemi difficili. Presentato a NeurIPS, il lavoro punta anche a code generation e agenti.

Il trucco non è far pensare sempre di più i LLM, ma insegnare loro quando valga la pena farlo e quando fermarsi.

Cosa cambia per chi porta i LLM in produzione

Tradotto in architettura, significa passare da pipeline monolitiche a controller che decidono compute e profondità per istanza. Impatto concreto:

Costi e energia: dimezzare il compute medio senza perdere qualità non è cosmetico; è margine e sostenibilità.
SLA: latenza variabile per query; serve definire una soglia massima e meccanismi di early-exit.
Affidabilità: con PRM calibrato riduci overconfidence e sprechi di token su percorsi inutili.
Dimensionamento: più richieste servite da modelli piccoli, con escalation selettiva ai modelli grandi solo quando necessario.

Uno scheletro di controller adattivo (pseudocodice)

// Controller di reasoning adattivo con PRM calibrato
async function solve(query, opts) {
  const cfg = {
    maxTokens: 8000,           // budget totale
    maxDepth: 8,               // passi di ragionamento
    kMin: 1, kMax: 8,          // rami / candidati per step
    stopThreshold: 0.85,       // fiducia per early-exit
    escalateThreshold: 0.35,   // sotto: prova escalation
    ...opts
  };

  let state = initState(query);
  for (let depth = 0; depth < cfg.maxDepth; depth++) {
    const k = adaptK(state.prmUncertainty, cfg.kMin, cfg.kMax);
    const candidates = await llm.generateContinuations(state.frontier, { k });

    // PRM restituisce intervalli [lo, hi] di probabilità per candidato
    const intervals = await prm.scoreIntervals(query, candidates);
    const calibrated = calibrate(intervals); // isotonic/temperature/ensemble

    const best = selectTop(calibrated, candidates);
    if (best.hi >= cfg.stopThreshold) return best.answer; // early-exit

    if (confidenceTooLow(calibrated, cfg.escalateThreshold)) {
      if (!state.escalated) {
        state = await escalateModel(state, query); // es. passaggio a modello più grande
        continue;
      }
    }

    state = expandFrontier(state, calibrated, candidates); // prosegui sui rami promettenti
    if (state.tokensUsed >= cfg.maxTokens) break; // rispetto del budget
  }

  return finalize(state); // migliore tra i candidati, con citazioni/trace
}

Note pratiche: logga intervalli di confidenza e decisioni del controller; senza osservabilità l’adaptive reasoning è un salto nel buio.

Edge e domotica: quando escalare al cloud

Scenario reale: hub domestico con LLM locale per intent e routine smart home. Il PRM locale stima l’incertezza: se l’intervallo di probabilità è ampio o basso, l’hub apre più rami (finché resta nei limiti energetici). Se non basta, escalation al cloud per un passaggio più profondo. Privacy: l’escalation invia solo lo sketch del problema, non l’audio grezzo. Risultato: reattività on-device quando è facile, qualità quando serve.

Calibrare il PRM: dal “numero magico” all’incertezza utile

Il paper evidenzia che i PRM tendono a sovrastimare la probabilità di successo. La soluzione è una calibrazione che produca range di probabilità, non valori puntuali. In pratica:

Raccogli tracce di ragionamento etichettate (parziali e finali) su dati simili alla produzione.
Allena/ri-addestra il PRM e applica tecniche di calibrazione (temperature scaling, isotonic regression o ensemble per intervalli).
Valida con reliability diagrams e expected calibration error per step, non solo sull’output finale.

Rischi e trade-off da mettere a budget

Variabilità di latenza e costo: introdurre caps duri per query e policy di degrade.
Shift di distribuzione: un PRM ben calibrato oggi può degradare domani; pianifica ricalibrazioni periodiche.
Sicurezza: più passaggi = più superficie per injection e data leak; filtri e sandbox sulle tracce.
Explainability: conserva gli step scelti/rifiutati per audit e debug.

Dove stiamo andando

L’idea sta già filtrando nei prodotti come “adaptive reasoning”. Il lavoro del MIT, presentato a NeurIPS e sostenuto da MIT-IBM Watson AI Lab, MIT-Amazon Science Hub, MIT-Google Program for Computing Innovation e MathWorks, mostra che c’è sostanza: meno compute, stessa (o migliore) qualità, e modelli piccoli che finalmente giocano in serie A. Per chi costruisce agenti o tool di code generation, vale la pena ripensare il controller dell’inferenza. Non serve far pensare il modello a oltranza: serve fargli scegliere bene quando pensare.