Addestramento delle policy

Addestramento senza GPU propria

Addestrare una policy di manipolazione è un carico di lavoro per GPU, e i moderni modelli vision-language-action richiedono più VRAM di quanta ne abbia una tipica workstation. Su AY-Robots l'addestramento gira su GPU cloud gestite dalla piattaforma: si sceglie un dataset e un tipo di policy, si avvia l'esecuzione e se ne segue il progresso dal browser. Non serve configurare CUDA, non ci sono driver da far combaciare, e non c'è un ambiente da mantenere.

L'input è sempre un dataset cloud da Dashboard > Datasets. Qualsiasi cosa registrata tramite sessioni di teleoperazione o caricata in formato LeRobot è idonea, inclusi i dataset uniti. Conviene curare i dati prima di addestrare: gli episodi etichettati Failure di norma vanno esclusi dal set di addestramento, e dieci minuti di revisione nel browser degli episodi risparmiano ore di tempo GPU spese ad apprendere da dimostrazioni scadenti.

Policy supportate

Sono supportate quattro famiglie di policy. Differiscono per dimensione, costo di addestramento e quanto riescono ad assorbire dai dati, quindi la scelta giusta dipende più dall'attività e dal dataset che da una classifica generale.

Avviare un'esecuzione

1. 1
   Scegliere il dataset

   Aprire Dashboard > Training e selezionare il dataset su cui addestrare. Vengono mostrati il conteggio degli episodi e il tipo di robot, così è possibile confermare di aver scelto quello giusto.

2. 2
   Scegliere la policy

   Selezionare uno dei tipi di policy supportati. In caso di dubbio, conviene iniziare con ACT: è il modo più economico per scoprire se il proprio dataset è abbastanza buono da addestrare qualcosa in generale.

3. 3
   Avviare

   Avviare l'esecuzione. Riceve un job id e una propria pagina dedicata, ed è possibile chiudere il browser: l'addestramento continua lato server e la pagina mostra lo stato in diretta ogni volta che si torna a controllarla.

La pagina dell'esecuzione di addestramento

Ogni esecuzione ha una pagina dedicata che risponde alle due domande che contano davvero durante l'addestramento: sta imparando, ed è la macchina in salute. Il progresso dell'apprendimento è mostrato come grafici della loss, della pianificazione del learning rate e della norma del gradiente. Una loss che si appiattisce subito o una norma del gradiente che esplode segnalano presto che l'esecuzione non merita di essere attesa.

Lo stato di salute della macchina viene mostrato accanto: utilizzo e memoria della GPU, più le metriche host della macchina di addestramento. Una timeline delle fasi mostra dove si trova attualmente l'esecuzione, dalla preparazione dell'ambiente al caricamento dei dati, fino al ciclo di addestramento stesso e al caricamento dei checkpoint. Quando qualcosa non torna, il visualizzatore di log integrato mostra i log di addestramento grezzi senza bisogno di accesso SSH, il che di solito basta per capire se il problema è nel dataset o nell'esecuzione stessa.

Checkpoint e ripresa

I checkpoint sono memorizzati per singola esecuzione, non in un pool condiviso, quindi i checkpoint elencati nella pagina di un'esecuzione appartengono sempre esattamente a quella esecuzione e alla sua configurazione. Questo conta più di quanto sembri: mescolare checkpoint tra esecuzioni con impostazioni diverse è una classica fonte di policy silenziosamente compromesse.

Se un'esecuzione viene interrotta, è possibile riprenderla dal suo ultimo checkpoint invece di ricominciare da capo. Anche i checkpoint intermedi sono utili di per sé: quando un'esecuzione lunga inizia a fare overfitting verso la fine, un checkpoint precedente spesso funziona meglio sul braccio reale rispetto a quello finale.

Eseguire la policy addestrata sul proprio braccio

Una policy completata può essere distribuita direttamente sul proprio robot. Nel cockpit, si seleziona la policy addestrata per il braccio collegato e si avvia l'inferenza: la policy ora produce i comandi ai giunti che prima venivano prodotti tramite teleoperazione. Il braccio deve essere dello stesso tipo di robot su cui è stato registrato il dataset, e la scena dovrebbe somigliare alle scene di addestramento, incluso il posizionamento delle telecamere.

Conviene trattare le prime esecuzioni di inferenza come esperimenti, non come dimostrazioni. Tenere l'arresto di emergenza a portata di mano, partire da uno stato iniziale vicino a quanto dimostrato, e aspettarsi che la policy sia sensibile a dettagli che potrebbero passare inosservati: una telecamera spostata, un'illuminazione diversa o un oggetto mai presente nel dataset.

Quanti episodi servono

L'errore di addestramento più comune sulla piattaforma non è un iperparametro sbagliato, ma addestrare su troppo pochi dati e concludere che il tipo di policy non funziona. Come regola generale per una singola attività da tavolo: circa 50 episodi danno una policy con generalizzazione ristretta, che riesce a partire da stati iniziali vicini a quelli dimostrati. Circa 100-200 episodi danno una robustezza utilizzabile in tutto lo spazio di lavoro per quell'attività, a condizione di aver variato il posizionamento degli oggetti tra un episodio e l'altro.

I tipi di policy più capaci non cambiano questa regola. Un fine-tune di GR00T su 20 episodi generalizzerà comunque male; ciò che i modelli più grandi offrono è un tetto più alto una volta che i dati sono disponibili. Se il budget è limitato, conviene spenderlo prima in episodi più vari che in un modello più grande.

Domande frequenti