>een AI-engineer aannemen >staat op het punt een aanbod te doen >vraag de kandidaat of hij met pytorch of web dev werkt >hij begrijpt het niet >leg de verschillen tussen pytorch en web dev uit >hij snapt het nog steeds niet >haal een geïllustreerd diagram tevoorschijn dat uitlegt wat pytorch is en wat web dev is >hij lacht en zegt "ik ben een goede engineer, meneer" >neem hem aan >import requests

Iedereen die eist dat 4o terugkomt, is geestelijk ziek, en ik ben moe van het doen alsof dat niet zo is.

Laten we het hebben over frameworks, bibliotheken, RL, en waarom ik waarschijnlijk niet van jouw favoriete RL-codebase hou. Ja, inclusief die ene. Het ongebruikelijke aan RL is dat het algoritme het gemakkelijke deel is. GRPO is een enkele regel vergelijking op enkele logprobs. Als je de data hebt, is het berekenen van het verlies triviaal, en dan gebruik je het vermoedelijk met een backprop-bibliotheek naar keuze. Maar dat is het probleem - het verkrijgen van de data. Het is een pijn in de kont. In reguliere RL moet je rollouts doen, misschien enkele afleveringen inkorten, en de eindes dienovereenkomstig afhandelen. Als je geen slak wilt zijn, wil je de omgeving vectoriseren en het algoritme daarvoor aanpassen. Als je een LLM wilt doen, moet je al die onzin doen die ervoor zorgt dat LLM's in het geheugen passen. Je moet voorzichtig zijn met je prompts, de juiste delen voor het verlies maskeren. Je hebt een degelijke generatie-engine (vLLM) nodig, wat het dan weer moeilijk maakt om de gewichten bij te werken. Als je multi-agent multi-turn LLM RL wilt doen, kun je net zo goed commit sudoku doen. Hoewel we het over bijna alles dat met RL te maken heeft oneens zijn, denk ik dat @jsuarez5341's Pufferlib dit punt prachtig illustreert. Het is zonder twijfel ongelooflijk in wat het doet - het trainen van RL-algoritmes in gesimuleerde omgevingen heel, heel snel. Maar het meeste van zijn nieuwheid is pure infra. De kernalgoritmes zijn grotendeels hetzelfde als ze al jaren zijn, en ik durf te wedden dat ze minder dan 10% van de totale engineering-inspanning vertegenwoordigen. Natuurlijk heeft dit implicaties voor de code die je moet schrijven om iets te doen dat verder gaat dan het uitvoeren van de ingebouwde voorbeelden. Wat ik keer op keer ontdek, is dat voor veel voldoende niet-triviale (lees: interessante) onderzoeksproblemen, het een vergelijkbare hoeveelheid tijd kost om (a) het ding vanaf nul/simpele primitieve te schrijven, of (b) een bestaande framework aan te passen om gekke ideeën te accommoderen. In het eerste geval richt je je op het schrijven van de daadwerkelijke logica. In het laatste geval wring je het framework om je in staat te stellen de logica toe te voegen. Ik weet wat ik beter vind. Dit alles komt omdat het algoritme het gemakkelijke deel is. De infra is de pijn in de kont. Dus wanneer je in een positie bent om te kiezen - gebruik de tools die infra vereenvoudigen, en schrijf de trainingslus zelf. Bouw geen frameworks, bouw bibliotheken. Je zult jezelf later dankbaar zijn. Grote shout-out naar mijn Master's supervisor van vroeger, die de eerste was die me vertelde om rllib te laten vallen en gewoon PPO zelf in PyTorch te schrijven. En naar @hallerite voor het inspireren van me om deze rant eindelijk op te schrijven. Ik zou op een gegeven moment in de toekomst een fatsoenlijke effortpost met voorbeelden kunnen schrijven als de mensen erom vragen.