NVIDIA Polar: Rivoluzionare l'Addestramento RL per Agenti LLM con il Proxy API

L'addestramento degli agenti basati su modelli linguistici (LLM) tramite apprendimento per rinforzo (RL) sta raggiungendo livelli di complessità senza precedenti, richiedendo la gestione di strumenti multi-turno, contesti a lungo termine e orchestrazioni multi-agente. La principale sfida ingegneristica risiede nel collegare i software degli agenti esistenti alle pipeline di addestramento senza compromettere il funzionamento degli strumenti stessi. Per rispondere a questa esigenza, il team di ricerca di NVIDIA ha presentato Polar, un framework di rollout che consente di eseguire l'apprendimento per rinforzo su qualsiasi "agent harness" senza la necessità di modificarlo.

Il problema fondamentale: l'integrazione degli Harness

Un "agent harness" è uno strumento come Codex CLI, Claude Code, Qwen Code o Pi, che gestisce prompt di sistema, formattazione dei tool, ingegneria del contesto e modalità di invio delle patch. Questi dettagli influenzano direttamente il comportamento dell'agente durante la fase di valutazione.

Le infrastrutture di RL tradizionali richiedono che la logica dell'harness venga riscritta per adattarsi a un'API di ambiente proprietaria del framework (solitamente nel formato env.init(), env.step(), env.reset() stile OpenAI Gym). Ogni nuovo harness richiede quindi nuovo codice di integrazione, con il rischio di perdere dettagli esecutivi specifici del percorso nativo dell'harness stesso.

Come funziona il Gateway Proxy

Per ogni richiesta in entrata, il gateway proxy esegue quattro passaggi critici:

1. Rilevamento dell'API del provider: identifica se si tratta di chiamate Anthropic Messages, OpenAI Chat Completions o Google generateContent tramite l'analisi dei path e degli header.
2. Normalizzazione della richiesta: converte ruoli, parti di contenuto, definizioni di strumenti e parametri di generazione nel formato OpenAI Chat Completions utilizzato dal server di inferenza locale.
3. Cattura dei dati a livello di token: memorizza messaggi di richiesta/risposta, ID dei token del prompt, ID dei token campionati, motivo della fine (finish reason) e log-probabilities.
4. Restituzione del formato originale: trasforma la risposta nel formato che l'harness si aspetta di ricevere.

Per le richieste in streaming, Polar ottiene una risposta non-streaming dall'upstream ed emette uno stream sintetico, preservando la compatibilità con gli harness che si aspettano eventi server-sent e garantendo al contempo la cattura completa dei token.

Architettura: Rollout Server e Nodi Gateway

Polar è composto da due componenti principali:

• Rollout Server: accetta una TaskRequest e la espande in sessioni indipendenti. Ogni sessione include ID, timeout, specifiche di runtime e dell'agente, e un valutatore. Il server smista le sessioni ai nodi gateway e gestisce i callback al completamento.
• Gateway Nodes: gestiscono il ciclo di vita di ogni sessione (avvio runtime, esecuzione harness, costruzione traiettorie e valutazione). Ospitano l'endpoint proxy per le chiamate al modello, legando la cattura dei dati al registro della sessione.

All'interno di ogni gateway, pool di worker isolati gestiscono le fasi di INIT, RUNNING e POSTRUN. Una memoria buffer (READY buffer) mantiene i runtime inizializzati finché non è disponibile uno slot di esecuzione, evitando che la preparazione pesante della CPU blocchi l'esecuzione dell'agente legata alla GPU.

Ricostruzione della Traiettoria: per_request vs. prefix_merging

Dopo il completamento di una sessione, Polar ricostruisce le traiettorie addestrabili. Sono disponibili due strategie:

La strategia per_request considera ogni chiamata al modello come una traccia indipendente. Sebbene sia accurata per le singole chiamate, frammenta le sessioni multi-turno, producendo centinaia di tracce per un singolo problema e appesantendo i trainer a valle.

La strategia prefix_merging ricostruisce tracce più lunghe dove l'harness mantiene cronologie di conversazione incrementali. Partiziona i completamenti in catene ordinate verificando una stretta relazione di prefisso tra i token. Solo i token campionati dall'assistente sono contrassegnati come addestrabili, mentre ai token interstiziali viene applicata una maschera di perdita pari a zero.

Risultati SWE-Bench Verified

L'addestramento ha utilizzato l'algoritmo GRPO sul modello base Qwen3.5-4B. I risultati mostrano guadagni significativi, specialmente dove l'agente deve interfacciarsi con protocolli di azione non familiari.

Il guadagno più eclatante è stato registrato con Codex: un incremento di 22.6 punti. Poiché Codex presenta uno stile di invio patch insolito per un modello Qwen, Polar ha permesso a GRPO di ottimizzare il comportamento esatto che il modello utilizza durante l'esecuzione reale, collegando il segnale di ricompensa ai token campionati lungo il percorso esecutivo di Codex.

Generazione dati SFT offline

Polar funge anche da servizio di generazione dati offline distribuito. Testato con Qwen3.5-122B su un server con 8 GPU H100, il sistema ha elaborato 1.638 istanze da repository SWE-Gym. Una traiettoria viene accettata nel corpus SFT solo se l'agente risolve tutti i test FAIL_TO_PASS senza compromettere i test PASS_TO_PASS. Il tasso di accettazione totale è stato del 30,8% (504 traiettorie accettate) con un costo di circa 64 ore-GPU.