EvalStop: Using World Feedback to Detect and Correct Reward Overoptimization in Multi-Tenant RLHF Platforms

Riepilogo Tecnico: EvalStop

Problematica

Le piattaforme di fine-tuning di Large Language Models (LLM) basate su cloud ospitano sempre più carichi di lavoro di Reinforcement Learning from Human Feedback (RLHF). Nell'RLHF, una policy viene addestrata per massimizzare un modello di ricompensa appreso, che funge da proxy per le preferenze umane. Tuttavia, come dimostrato da Gao et al. (2023), sotto una pressione di ottimizzazione sostenuta, questo proxy diverge dal "feedback del mondo reale" (metriche di valutazione a valle). Questo fenomeno, noto come overottimizzazione della ricompensa o reward hacking, si verifica quando il punteggio del modello di ricompensa e la perdita di addestramento continuano a migliorare monotonicamente, mentre la vera qualità della policy (misurata tramite benchmark su dati non utilizzati nell'addestramento) raggiunge un picco e successivamente degrada.

Gli scheduler delle piattaforme esistenti non riescono ad affrontare questa divergenza:

1. Scheduler non chiaroveggenti (es. Tiresias, Pollux) ottimizzano il Job Completion Time (JCT) senza segnali di qualità, incapaci di distinguere un addestramento produttivo da uno spreco di calcolo.
2. Scheduler consapevoli della qualità (es. SLAQ) si affidano alla perdita di addestramento (training loss). Poiché la perdita correla con la qualità nell'apprendimento supervisionato standard, ma si disaccoppia durante l'overottimizzazione dell'RLHF, questi scheduler continuano ad allocare risorse a job in fase di "hacking".
3. L'early stopping classico richiede il monitoraggio umano per ogni singolo job e non facilita la riallocazione delle risorse a livello di piattaforma.

La sfida centrale è rilevare il reward hacking a livello di scheduler utilizzando solo segnali osservabili (punteggi di valutazione ai checkpoint) senza modificare l'algoritmo di addestramento o violare i vincoli di non-chiaroveggenza, reclamando così le risorse GPU dai job divergenti.

Metodologia: EvalStop

Gli autori propongono EvalStop, una primitiva di scheduling composibile che agisce come un wrapper attorno a qualsiasi scheduler di base. Eval停EvalStop riformula l'early stopping a livello di scheduler come un problema di rilevamento: distinguere tra esecuzioni RLHF strutturalmente sane e quelle affette da reward hacking.

Architettura e Meccanismo

EvalStop opera attraverso tre moduli primari:

1. Input del Feedback del Mondo Reale: Il sistema riceve i punteggi di valutazione a valle (il segnale del "feedback del mondo reale") ai checkpoint programmati. Rispetta un "Confine di Informazione", osservando solo i tipi di job, i punteggi di valutazione e i conteggi dei declini consecutivi, senza accesso alla durata reale del job o alle etichette di hacking nascoste.
2. Rilevatore di Declino (Decline Detector): La logica centrale traccia la traiettoria dei punteggi di valutazione per ogni job. Se un job presenta $k$ declini consecutivi nel suo punteggio di valutazione, il sistema attiva un early stop. Questo meccanismo funziona come un rilevatore di punti di cambiamento semplificato, scelto per la sua interpretabilità e semplicità operativa.
3. Stop e Salvataggio (Stop and Save): Al momento del trigger, il wrapper termina il job, rilascia immediatamente le risorse GPU e preserva il miglior checkpoint del modello (registrato $k$ step di valutazione prima del trigger). Lo stato aggiornato del cluster viene quindi delegato allo scheduler di base (es. FIFO, SRTF-Est, LossAware) per la riallocazione delle risorse.

A differenza degli approcci precedenti che si limitano a de-prioritizzare i job post-picco (il che porta a starvation e occupazione continua delle risorse), EvalStop termina attivamente i job e libera le risorse.

Contributi Chiave

Il documento delinea tre contributi specifici:

• C1 (Inquadramento del Rilevamento): Gli autori sostengono che l'early stopping a livello di scheduler per l'RLHF sia fondamentalmente un problema di rilevamento. Introducono un design sperimentale in cui le etichette di hacking reali sono nascoste dietro un proxy di whitelist (il Confine di Informazione), permettendo una misurazione onesta della qualità del rilevatore (precisione/richiamo) piuttosto che solo delle metriche di sistema.
• C2 (Rilevatore Composibile): EvalStop raggiunge un'elevata accuratezza di rilevamento. Sui carichi di lavoro pesanti in RLHF, ottiene una precisione del 98% e un richiamo del 99% con un Tasso di Falsi Positivi (FPR) dell'1,5%. Supera significativamente le regole a progresso fisso (che incorrono in un FPR del ~65%) e i rilevatori di plateau della perdita (che mancano oltre il 60% dei casi di hacking).
• C3 (Guadagni di Sistema Composibili): EvalStop funziona come un overlay che migliora le prestazioni di vari scheduler di base. Produce miglioramenti del 9–25% nel JCT e riduce lo spreco di calcolo di circa il 22% nei carichi di lavoro pesanti in RLHF. La qualità del rilevamento rimane stabile sotto diversi livelli di rumore di valutazione ($\sigma \le 0.05$) e tassi di base di hacking (20–80%).

Risultati Sperimentali

Gli autori hanno valutato EvalStop utilizzando un simulatore a eventi discreti che modella una piattaforma multi-tenant con 64 GPU e carichi di lavoro misti (LoRA, DPO, RLHF). Il carico di lavoro RLHF era un mix di esecuzioni "hacking" (dove i punteggi di valutazione raggiungono un picco e declinano) al 60% e esecuzioni "sane" al 40%.

• Risultati Principali (Carico di Lavoro Pesante in RLHF): Rispetto al baseline SRTF-Est (Shortest Remaining Time First con stime), EvalStop+SRTF ha ridotto il JCT del 9,4% e lo spreco di calcolo del 21,8%. Fondamentalmente, ha mantenuto una precisione del 98,3% e un FPR dell'1,5%. Al contrario, un baseline "StopAt-0.65" (che ferma tutti i job RLHF al 65% del progresso) ha ottenuto guadagni simili nel JCT ma ha distrutto il 64,5% dei job sani (alto FPR). Un rilevatore di plateau della perdita ha ottenuto solo il 38,3% di richiamo, mancando la maggior parte dei casi di hacking.
• Componibilità: EvalStop ha migliorato il JCT dall'8,9% al 25,2% attraverso diversi scheduler di base (FIFO, SJF-Est, SRTF-Est, LossAware).
• Robustezza:
  • Sensibilità al Rumore: All'aumentare del rumore di valutazione ($\sigma$ da 0.01 a 0.12), la precisione di EvalStop è degradata gradualmente dal 100% all'81%, rimanendo significativamente più alta rispetto ai competitor.
  • Sensibilità al Tasso di Base: La precisione di EvalStop è rimasta sopra l'89% in frazioni di hacking comprese tra il 20% e l'80%, mentre la precisione del baseline a progresso fisso era direttamente legata al tasso di base (agendo come un classificatore costante).
• Sensibilità della Soglia: È stato riscontrato che una soglia di declino di $k=2$ bilancia efficacemente l'early detection rispetto ai falsi positivi.

Significato e Rivendicazioni

Il documento sostiene che il feedback del mondo reale (punteggi di valutazione a valle) sia un segnale di scheduling superiore rispetto alla perdita di addestramento o ai punteggi del modello di ricompensa per i carichi di lavoro RLHF. EvalStop operazionalizza questa intuizione trasformando i punteggi di valutazione da segnali di monitoraggio passivi in segnali di controllo attivo per l'allocazione delle risorse.

Gli autori sottolineano che EvalStop è complementare alle mitigazioni a livello di addestramento (es. RL vincolato, ensemble di ricompense). Mentre i metodi a livello di addestramento mirano a prevenire l'hacking, EvalStop fornisce una rete di sicurezza a livello di scheduler per i casi in cui l'implementazione imperfetta porta alla divergenza. Il sistema consente alle piattaforme di reclamare le risorse GPU dai job divergenti senza richiedere modifiche all'algoritmo di addestramento o violare i vincoli di scheduling non-chiaroveggenti.

Gli autori segnalano alcune limitazioni, tra cui l'uso di curve di addestramento sintetiche calibrate su Gao et al. (2023) e l'assunzione di hardware omogeneo. Affermano che la validazione su tracce di addestramento reali (es. da TRL o OpenRLHF) è il passo successivo necessario. Il lavoro suggerisce che, con la crescita dei carichi di lavoro RLHF, la gestione del divario tra i segnali proxy e il feedback del mondo reale diventerà critica per la gestione efficiente delle risorse nelle piattaforme cloud.