>assumere un ingegnere AI >sto per inviare un'offerta >chiedi al candidato se è esperto in pytorch o sviluppo web >lui non capisce >spiega le differenze tra pytorch e sviluppo web >lui ancora non capisce >estrae un diagramma illustrato che spiega cos'è pytorch e cos'è lo sviluppo web >lui ride e dice "sono un buon ingegnere, signore" >assumilo >importa requests

Ogni singola persona che chiede di riportare indietro il 4o è mentalmente malata, e sono stanco di fingere il contrario

Va bene, parliamo di framework, librerie, RL e del motivo per cui probabilmente non mi piace il tuo codice preferito di RL. Sì, incluso quello. La cosa insolita riguardo a RL è che l'algoritmo è la parte facile. GRPO è un'equazione a una sola riga su alcuni logprobs. Se hai i dati, calcolare la perdita è banale, e poi presumibilmente lo stai usando con una libreria di backpropagation a tua scelta. Ma questo è il problema: ottenere i dati. È una vera seccatura. Nel RL normale devi fare rollouts, forse troncare alcuni episodi e gestire le conclusioni di conseguenza. Se non vuoi essere una lumaca, vorrai vettorizzare l'ambiente e adattare l'algoritmo per questo. Se vuoi fare un LLM, devi fare tutta la fuffa che fa sì che gli LLM si adattino in memoria. Devi fare attenzione ai tuoi prompt, mascherare le parti giuste per la perdita. Hai bisogno di un buon motore di generazione (vLLM), il che rende poi difficile aggiornare i pesi. Se vuoi fare RL LLM multi-agente multi-turno, tanto vale fare un sudoku impegnativo. Anche se abbiamo molte divergenze su praticamente qualsiasi cosa relativa a RL, penso che la Pufferlib di @jsuarez5341 esemplifichi questo punto in modo splendido. È senza dubbio incredibile in quello che fa: addestrare algoritmi RL in ambienti simulati molto, molto rapidamente. Ma gran parte della sua novità è pura infrastruttura. Gli algoritmi di base sono per lo più gli stessi di anni fa, e sono disposto a scommettere che rappresentano meno del 10% dello sforzo ingegneristico complessivo. Naturalmente, questo ha implicazioni sul codice che devi scrivere per fare qualsiasi cosa oltre a eseguire gli esempi integrati. Quello che trovo ripetutamente è che per molti problemi di ricerca sufficientemente non banali (leggi: interessanti), ci vuole un tempo simile per (a) scrivere la cosa da zero/a partire da semplici primitive, o (b) adattare un framework esistente per accogliere idee folli. Nel primo caso, ti concentri sulla scrittura della logica effettiva. Nel secondo, ti destreggi con il framework per permetterti di aggiungere la logica. So cosa mi piace di più. Tutto questo è perché l'algoritmo è la parte facile. L'infrastruttura è la seccatura. Quindi, ogni volta che sei in una posizione per scegliere - usa gli strumenti che semplificano l'infrastruttura e scrivi tu stesso il ciclo di addestramento. Non costruire framework, costruisci librerie. Ti ringrazierai in seguito. Un grande saluto al mio supervisore di Master di un tempo, che è stato il primo a dirmi di abbandonare rllib e semplicemente scrivere PPO da solo in PyTorch. E a @hallerite per avermi ispirato a scrivere finalmente questo sfogo. Potrei scrivere un post di sforzo adeguato con esempi in un certo momento in futuro se la gente lo richiede.