>Ansette en AI-ingeniør >i ferd med å sende et tilbud >Spør kandidaten om han er pytorch eller webutvikler >Han forstår ikke >Forklar forskjellene mellom Pytorch og webutvikling >Han skjønner det fortsatt ikke >Trekk ut illustrert diagram som forklarer hva som er Pytorch og hva som er webutvikling >Han ler og sier "Jeg er en god ingeniør, sir" >Ansett ham >importforespørsler

Hver eneste person som krever å bringe tilbake 4o er psykisk syk, og jeg er lei av å late som noe annet

La oss snakke om rammeverk, biblioteker, RL, og hvorfor jeg sannsynligvis ikke liker din favoritt RL-kodebase. Ja, inkludert den. Det uvanlige med RL er at algoritmen er den enkle delen. GRPO er en enkeltlinjes ligning på noen logprobs. Hvis du har dataene, er det trivielt å beregne tapet, og da bruker du dem antagelig med et backprop-bibliotek etter eget valg. Men det er problemet – å få tak i dataene. Det er vondt i ræva. I vanlig RL må du gjøre utrullinger, kanskje avkorte noen episoder og håndtere endene deretter. Hvis du ikke vil være en snegl, vil du vektorisere miljøet og tilpasse algoritmen for det. Hvis du vil gjøre en LLM, må du gjøre alt tullet som gjør at LLM-er passer inn i minnet. Du må være forsiktig med instruksjonene dine, maskere ut de riktige delene for tapet. Du trenger en anstendig generasjonsmotor (vLLM), som da gjør det vanskelig å oppdatere vektene. Hvis du vil gjøre multi-agent multi-turn LLM RL, kan du like gjerne begå sudoku. Selv om vi har mange uenigheter om omtrent alt RL-relatert, synes jeg @jsuarez5341's Pufferlib eksemplifiserer dette poenget vakkert. Den er uten tvil utrolig på det den gjør - å trene RL-algoer på simulerte miljøer veldig veldig raskt. Men det meste av nyheten er ren infra. Kjernealgoritmene er stort sett de samme som de har vært i årevis, og jeg er villig til å vedde på at de representerer mindre enn 10 % av den totale ingeniørinnsatsen. Naturligvis har dette implikasjoner for koden du må skrive for å gjøre noe utover å kjøre de innebygde eksemplene. Det jeg finner gang på gang, er at for mange tilstrekkelig ikke-trivielle (les: interessante) forskningsproblemer, tar det like lang tid å (a) skrive tingen fra bunnen av/fra enkle primitiver, eller (b) tilpasse et eksisterende rammeverk for å imøtekomme sprø ideer. I førstnevnte fokuserer du på å skrive den faktiske logikken. I sistnevnte vrir du rammeverket slik at du kan legge til logikken. Jeg vet hva jeg liker bedre. Alt dette er fordi algoritmen er den enkle delen. Infraet er smerten i rumpa. Så når du er i en posisjon til å velge - bruk verktøyene som forenkler infra, og skriv opplæringssløyfen selv. Ikke bygg rammeverk, bygg biblioteker. Du vil takke deg selv senere. Stort rop til masterveilederen min fra den gang, som var den første som ba meg droppe rllib og bare skrive PPO selv i PyTorch. Og til @hallerite for å inspirere meg til å endelig skrive denne rant. Jeg kan skrive et skikkelig innlegg med eksempler på et tidspunkt i fremtiden hvis folket krever det.