Cos'è l'RLVR (ricompensa verificabile)?

RLVR è la sigla di Reinforcement Learning with Verifiable Rewards: un modo di addestrare un modello linguistico in cui il premio non viene da un valutatore umano che dice "questa risposta mi piace di più", ma da un verificatore automatico che controlla se il risultato è corretto: il test unitario passa o fallisce, la risposta al problema di matematica coincide con quella nota, il formato richiesto è rispettato o no. Il nome si deve al paper Tülu 3 dell'Allen Institute for AI (arXiv:2411.15124), che lo descrive come una tecnica che assegna una ricompensa costante solo quando si verifica che la generazione del modello è corretta, applicata a problemi con esito controllabile come GSM8K, MATH e il rispetto di istruzioni con vincoli misurabili (IFEval). La differenza con l'RLHF classico è tutta qui: non serve nessuno che legga la risposta e dica se gli piace, basta un verificatore che esegua un controllo meccanico e restituisca un punteggio.

Leggi anche: RLHF vs DPO vs GRPO · Le tre tecniche con cui i modelli imparano a comportarsi bene dopo l'addestramento: dal rinforzo con feedback umano alle preferenze dirette.

Perché conviene, e dove si ferma

DeepSeek ha portato l'idea alla sua conseguenza più estrema con DeepSeek-R1-Zero (arXiv:2501.12948), addestrato con reinforcement learning puro su ricompense a regole, senza modello di ricompensa neurale per il ragionamento. È la stessa svolta di post-training descritta nella voce su RLHF, DPO e GRPO, ma qui l'attenzione è su un'altra domanda: da dove viene la ricompensa, non con quale algoritmo la si ottimizza. Il vantaggio dichiarato da DeepSeek è esplicito: un modello di ricompensa neurale può subire reward hacking nel reinforcement learning su larga scala, cioè il modello impara a ingannare il valutatore invece di migliorare davvero, e richiede risorse di calcolo aggiuntive per addestrarlo e mantenerlo. Un verificatore a regole non ha questo problema quando la correttezza è oggettiva: o il test passa o no, non c'è margine di persuasione. Il costo evitato è anche quello dell'etichettatura umana: nessun annotatore deve confrontare coppie di risposte, il segnale esiste già nel problema stesso. Il limite è altrettanto netto: funziona solo dove esiste un modo automatico di dire se la risposta è giusta, quindi matematica, codice con test, formati strutturati, non la scrittura di un'email persuasiva o un giudizio di stile. E anche un verificatore a regole non è immune al proprio tipo di inganno: un modello può imparare a superare il test senza risolvere il problema che il test intende misurare, per esempio scrivendo codice che riconosce i casi dell'esame invece di scrivere la logica generale, la forma di reward hacking specifica dell'RLVR.

Un esempio enterprise

Un fornitore di strumenti per sviluppatori vuole addestrare un modello a scrivere codice che supera la suite di test di un repository interno. Con l'RLHF classico servirebbe far leggere migliaia di diff a revisori umani e chiedere quale versione preferiscono, un collo di bottiglia lento e costoso. Con l'RLVR il segnale è già nella pipeline CI esistente: il modello genera una patch, la suite di test gira, il risultato (verde o rosso) è la ricompensa. È questo tipo di segnale, l'esecuzione reale dei test e non un giudizio soggettivo di leggibilità, a rendere l'RLVR adatto agli agenti di coding che lavorano dentro un agent harness.

Perché conta per chi decide

Chi valuta un vendor che dichiara di allineare un modello con l'RLVR dovrebbe chiedere due cose: su quale porzione del caso d'uso il verificatore automatico esiste davvero, e come viene controllato il reward hacking del verificatore stesso, cioè se qualcuno ha verificato che il modello risolve il problema e non solo il test che lo misura. La prima domanda separa un'affermazione di marketing da un caso d'uso reale: fuori da matematica, codice e pochi altri domini strutturati, un verificatore affidabile di solito non esiste, e chi lo propone come soluzione universale sta semplificando. La seconda è la stessa disciplina che si applica a qualunque suite di evals: un punteggio alto sul verificatore dice che il modello ha superato quel verificatore, non che ha risolto il problema di business.