

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Riferimento agli iperparametri
<a name="model-customize-mtrl-hyperparams"></a>

La tabella seguente elenca tutti gli iperparametri configurabili per i lavori di formazione RL su più turni. Le impostazioni predefinite per le ricette sono riportate di seguito.


| Categoria | Parametri | Predefinita | Choice | Spiegazione | 
| --- | --- | --- | --- | --- | 
| Archiviazione | global\_batch\_size | 128 | {32, 64, 128} | Numero di istruzioni uniche per fase di allenamento. | 
| Archiviazione | dimensione del gruppo | 8 | [2, 32] | Implementazioni per prompt utilizzate per calcolare i vantaggi basati sul gruppo (GRPO/RLOO). | 
| R.L | metodo\_vantaggio | basato su gruppi | monte\_carlo, basato sul gruppo, basato sul gruppo, basato sul gruppo per turno, rloo, reinforce\_pp, reinforce\_pp\_baseline, opo, gruppo\_passk, gpg | Metodo per calcolare i vantaggi delle implementazioni. | 
| R.L | loss\_fn | ppo | importance\_sampling, ppo, cispo | Formulazione di perdita RL. | 
| RL | clip\_low\_threshold | 0.8 | [0, 1] | Limite inferiore per il calcolo del rapporto di probabilità della politica π \_new/π \_old nella perdita surrogata. PPO-style  | 
| RL | clip\_high\_threshold | 1.2 | [1, 10] | Limite superiore per calcolare il rapporto di probabilità politica nella perdita. | 
| sampling\_params | temperature | 1 | [0, 2] | Temperatura di campionamento applicata ai logit prima del campionamento. | 
| sampling\_params | campionamento\_top\_p | 1 | [0, 1] | Nucleus-sampling limite. Campioni solo dal set più piccolo di token la cui probabilità cumulativa è ≥ top\_p. | 
| sampling\_params | sampling\_max\_tokens | 4096 | [512, 8192] | Numero massimo di token che il modello può generare per turno durante il lancio. | 
| val\_sampling\_params | sampling\_max\_tokens | 4096 | [512, 8192] | Numero massimo di token che il modello può generare per turno durante la valutazione. | 
| val\_metrics\_config | pass\_k\_values | [1, 2, 4, 8, 16, 32] | n/a | Elenco di valori k per il calcolo delle metriche pass @k. | 
| val\_metrics\_config | soglia di successo | 1 | n/a | Soglia di ricompensa per il calcolo di un'implementazione come «riuscita». | 
| Schedule | max\_epochs | 1 | [1, 30] | Numero totale di passaggi sui dati. | 
| Schedule | max\_steps | 50 | [1, 1000] | Iterazioni totali dell'allenamento. | 
| Schedule | val\_every | 10 | [0, 100] | Intervallo di valutazione (passaggi). | 
| Modello | model\_name\_or\_path | obbligatorio |  | Modello da perfezionare (ad esempio, "«). GPT-OSS-20B | 
| Modello | lora\_rank | 32 | [16,64] | Il rango dell'adattatore LoRa che controlla la capacità dell'adattatore. | 
| Modello | lora\_alpha | 64 | [16,128] | Fattore di scala LoRa. Magnitudine di aggiornamento effettiva ∝ alpha/rank. | 
| Modello | learning\_rate | 4,00 E-05 | (0, 1e-2] | Tasso di apprendimento di Adam. | 
| Modello | adam\_beta1 | 0.9 | [0, 0.999999] | Tasso di decadimento esponenziale per la media corrente del gradiente (primo momento) in Adam. | 
| Modello | adam\_beta2 | 0,95 | [0, 0,999999] | Tasso di decadimento esponenziale per la media corrente del gradiente quadrato (secondo momento) in Adam. | 
| Modello | adam\_eps | 1,00 E-08 | [1e-16, 1e-2] | Piccola costante aggiunta al denominatore per la stabilità numerica nella regola di aggiornamento di Adam. | 
| Modello | adam\_weight\_decay | 0 | [0, 1] | Coefficiente di decadimento del peso disaccoppiato (). AdamW-style | 
| Modello | adam\_grad\_clip\_norm | 1 | [0, 100] | Norma di gradiente globale massima. | 
| Implementazione | rollout\_max\_concurrency | 96 | [32, 96] | I massimi processi di rollout in volo possono avvenire in parallelo. | 
| Implementazione | rollout\_timeout | 600 | [300, 86400] | Gestione degli errori: tempo trascorso il quale consideriamo il fallimento del rollout. | 
| Implementazione | rollout\_max\_retries | 3 | [1, 10] | Numero di tentativi di riprova per implementazioni non riuscite. | 
| async\_config | policy max\_steps\_off | 3 | [0, 10] | Soglia di stabilità nell'allenamento asincrono. Quando è 0, è un allenamento sincrono. | 

## Le migliori pratiche per la regolazione degli iperparametri
<a name="model-customize-mtrl-hyperparams-best-practices"></a>

Quando una sequenza è piatta o in fase di collasso, i sei parametri seguenti rappresentano quasi tutta la spiegazione.

### Tasso di apprendimento
<a name="model-customize-mtrl-hp-bp-lr"></a>

`learning_rate`Controlla l'ampiezza del passo compiuto dall'ottimizzatore a ogni iterazione di allenamento. Nell'RL a turni multipli, il segnale di gradiente per fase varia a seconda dell'attività: un ambiente a ricompensa sparsa con risultati binari produce molti gruppi in cui tutti i rollout ottengono lo stesso punteggio, con zero vantaggi per l'intero gruppo. Solo i gruppi con risultati misti producono un segnale di gradiente, quindi il gradiente utile di ogni fase viene diluito. Il tasso di apprendimento deve essere inferiore per allinearsi al segnale più debole, oppure la corsa richiede più passaggi.

Un ambiente ricco di ricompense, in cui le traiettorie all'interno di un gruppo ottengono in modo affidabile punteggi diversi, produce vantaggi costanti e diversi da zero per la maggior parte dei gruppi, e il tasso di apprendimento predefinito è spesso già sufficiente.

La dimensione effettiva dei passaggi dipende anche dalla configurazione LoRa, vale a dire l'entità effettiva degli aggiornamenti, quindi una frequenza di apprendimento fissa varia a seconda della capacità dell'adattatore. `learning_rate × alpha/rank`

### Funzione di perdita e intervallo di ritaglio
<a name="model-customize-mtrl-hp-bp-loss"></a>

Se non conoscete MTRL, importance sampling (`importance_sampling`) è un buon punto di partenza prima di passare ad algoritmi avanzati basati sul clipping. PPO e CISPO utilizzano `clip_low_threshold` e limitano il rapporto di probabilità, vale `clip_high_threshold` a dire quanto la politica può `policy_new(action|state) / policy_old(action|state)` cambiare in una singola fase di formazione.

Un rapporto tra `1.0` significa nessun cambiamento. La soglia inferiore (ad esempio`0.8`) impedisce alla politica di disimparare in modo aggressivo le azioni che preferiva in precedenza. La soglia superiore (ad esempio`1.2`) impedisce alla banca di impegnarsi eccessivamente in azioni che risultavano soddisfacenti in un unico batch.
+ **PPO** with `(clip_low_threshold, clip_high_threshold) = (0.8, 1.2)` è la linea di base sicura per ogni prima esecuzione.
+ **CISPO** richiede un ampio ritaglio asimmetrico. `clip_low_threshold = 1.0`Inizia `clip_high_threshold = 6.0` con,. CISPO consente di ridurre liberamente le probabilità di cattiva azione e si affida esclusivamente alla clip superiore per prevenire l'instabilità.

Si consiglia di modificare le soglie di clipping in caso di rallentamento o insufficiente allenamento.

### Dimensione del batch e dimensione del gruppo
<a name="model-customize-mtrl-hp-bp-batch"></a>

Questi due parametri determinano congiuntamente la quantità di segnale di gradiente utile ricevuta da ogni fase di allenamento.

`global_batch_size`controlla quanti prompt unici sono inclusi in un passaggio dell'ottimizzatore. I batch più grandi (128) generano una media dei gradienti rispetto a più prompt, producendo curve di ricompensa più fluide e aggiornamenti più stabili. I batch più piccoli (32) sono più economici per fase e sono utili per iterazioni rapide, ma producono gradienti più rumorosi. Per le esecuzioni di produzione, 128 è una buona impostazione predefinita; per il debug o lo screening degli iperparametri, 32 va bene.

`group_size`determina quante implementazioni indipendenti vengono generate per ogni prompt. Queste implementazioni vengono confrontate tra loro per ottenere vantaggi in termini di calcolo. Se tutte le implementazioni ricevono la stessa ricompensa (tutte hanno successo o tutte falliscono), il vantaggio è pari a zero e il gruppo non produce alcun segnale di gradazione. Il valore predefinito è `group_size = 8`. Riducilo se c'è abbastanza diversità nel gruppo, aumentala se l'ambiente richiede maggiore diversità.

Implementazioni totali per fase =. `global_batch_size × group_size` In contesti con ricompense sparse, in cui la maggior parte dei gruppi non produce alcun segnale, spesso è più efficiente mantenere la dimensione del gruppo moderata e aumentare invece la dimensione del batch o il numero di passaggi.

### Off-policy parzialità
<a name="model-customize-mtrl-hp-bp-offpolicy"></a>

Nell'addestramento asincrono, `max_steps_off_policy` controlla il grado di obsolescenza di un'implementazione prima che venga scartata. L'impostazione predefinita di nasconde la latenza di coda del server di rollout. `3` Tuttavia, i rollout obsoleti hanno rapporti di importanza che si discostano sostanzialmente da quelli della clip`1.0`, e quando tali rapporti raggiungono i limiti delle clip non forniscono alcun segnale di gradiente.

**Impostato su 0 quando il debug collassa.** La stupidità asincrona si accompagna ad aggiornamenti ponderati in base all'importanza e può oscurare le cause principali. Imposta su`0`, stabilizza, quindi riattiva una volta compreso il problema. Per gli ambienti in cui le implementazioni sono rapide, `max_steps_off_policy = 1` può essere un'impostazione predefinita migliore.

### Numero massimo di token di campionamento
<a name="model-customize-mtrl-hp-bp-maxtokens"></a>

`sampling_max_tokens`è il limite di generazione per turno. Se il limite è troppo basso, le risposte del modello vengono troncate a metà riflessione e il modello riceve una ricompensa per un tentativo incompleto. La policy impara quindi ad associare quei prefissi troncati a risultati negativi, sopprimendo i comportamenti esplorativi che avrebbero avuto successo se si avesse avuto più spazio.

L'impostazione predefinita di 4096 funziona per la maggior parte delle attività. Aumenta a 8192 per i modelli con risposte troppo thinking/reasoning lunghe. La regola di dimensionamento è: `max_turns × (sampling_max_tokens + expected_tool_output) + prompt ≤ max_sequence_length` con un certo margine.

**Diagnostica: monitor**. `rollout/tokens/response_max` Se le traiettorie si raggruppano esattamente in corrispondenza del limite massimo, il modello viene troncato silenziosamente e probabilmente perde il segnale. `val_sampling_params.sampling_max_tokens`dovrebbe corrispondere all'allenamento.

### Rollout configuration (Configurazione rollout)
<a name="model-customize-mtrl-hp-bp-rollout"></a>

Questi parametri controllano il modo in cui vengono prodotte le implementazioni e il modo in cui il trainer gestisce le implementazioni lente o fallite.
+ `rollout_max_concurrency`— Controlla quante implementazioni sono in corso contemporaneamente. L'impostazione predefinita di 96 funziona bene per la maggior parte delle configurazioni. Impostarlo su un valore troppo alto in modalità asincrona produce implementazioni obsolete e può sovraccaricare il motore di inferenza.
+ `rollout_timeout`— Quanto tempo (in secondi) attendere una singola implementazione prima di considerarla fallita. L'impostazione predefinita di 600 è la dimensione adatta agli ambienti tipici in cui si utilizzano strumenti. Impostandolo su un valore troppo basso tronca le implementazioni che avrebbero avuto successo con più tempo.
+ `rollout_max_retries`— Controlla i tentativi di ripetizione in caso di implementazioni non riuscite. Se la percentuale di errori permanenti supera circa l'1%, il problema è nella configurazione dell'ambiente, non nel numero di tentativi.

### Parametri di supporto
<a name="model-customize-mtrl-hp-bp-supporting"></a>
+ **Capacità LoRa (`lora_rank`e`lora_alpha`).** L'entità effettiva dell'aggiornamento per fase è proporzionale a`alpha/rank`, il che funge da moltiplicatore sul tasso di apprendimento. L'impostazione predefinita è `lora_rank = 32, lora_alpha = 64` (rapporto 2:1). Valuta la possibilità di aumentarlo solo se tutto il resto è ben regolato e la curva di ricompensa è ancora stabile: raddoppia entrambi insieme (64/128) per aumentare la capacità e mantenere lo stesso tasso di apprendimento effettivo.
+ **temperature = 1,0, sampling\_top\_p = 1,0 per l'allenamento.** Per quanto riguarda la formazione RL, si desidera diversificare le implementazioni all'interno di un gruppo, in modo che la linea di base del gruppo abbia un segnale adeguato. La temperatura 1,0 è una buona impostazione predefinita. Per la valutazione, utilizzate temperature = 0,0 (decodifica avida) in modo che le curve di valutazione siano deterministiche e confrontabili tra le esecuzioni.
+ **pass\_k\_values.** Pass @1 è la metrica di valutazione principale. Pass @G (dove G = group\_size) è un utile controllo di integrità: se pass @G è molto alto, la maggior parte dei prompt è troppo facile; se pass @G è molto basso, la maggior parte dei prompt è troppo difficile e il segnale di gruppo è scarso.
+ **max\_steps e max\_epochs.** `max_steps = 50`per lo screening (sufficiente per vedere se la curva si sta muovendo), 100 per la produzione. Il collasso del CISPO tende a comparire tra i passaggi 40—80. `max_epochs = 1`è l'impostazione predefinita; più epoche riutilizzano gli stessi prompt con nuove implementazioni, il che può essere utile se il set di prompt è piccolo ma rischia di essere troppo adatto a una distribuzione ristretta dei prompt.
+ **adam\_beta2 = 0,95.** Inferiore al valore predefinito SFT di 0,999. In RL, le statistiche sui gradienti non sono stazionarie, quindi l'ottimizzatore deve tenere traccia della varianza recente del gradiente in modo più aggressivo.
+ **weight\_decay = 0,0.** LoRa limita già gli aggiornamenti tramite parametrizzazione di basso livello. L'aggiunta del decadimento del peso aggrava la regolarizzazione in modi che non sono stati ben caratterizzati per la messa a punto di RL.
+ **adam\_grad\_clip\_norm = 1,0.** Limita la norma globale del gradiente. Se il collasso è correlato a grandi picchi pre-clip, scendi a 0,5. Se la norma si attesta esattamente a 1,0 per molti passaggi e la ricompensa è fissa, la clip potrebbe essere il collo di bottiglia: alzate la soglia a 2,0 con cautela.