Olen viime aikoina jutellut monien ihmisten kanssa, jotka työskentelevät RL:n parissa, ja olen huomannut jotain mielenkiintoista — aina kun keskustelu siirtyy RL Infraan, se melkein aina suuntautuu yhteen aiheeseen: junapäättelyjen linjaukseen. Kuinka pitää koulutus- ja päättelykäytännöt johdonmukaisina. Kuinka hallita off-policy -tutkintoa. Kuinka käsitellä logarit-ongelmaeroja asynkronin käyttöönoton jälkeen. Nämä ovat kaikki tärkeitä kysymyksiä, epäilemättä. Mutta olen yhä vakuuttuneempi siitä, että RL Infra kärsii merkittävästä huomion väärinjakamisesta. Lainaan kehyksen äskettäisestä keskustelusta kollegan kanssa, ja kutsun tätä RL Infra-tynnyrivaikutukseksi. Tynnyri pitää sisällään vain sen lyhyin sauva. RL-koulutusjärjestelmän läpimenokyky ja oikeellisuus toimivat samalla tavalla — ne eivät määräydy moduulin mukaan, jonka olet eniten optimoinut, vaan sen mukaan, jonka olet eniten laiminlyönyt. Junapäättelyjen kohdistus voi olla se sauva, jonka olet hionut ja kiillottanut täydelliseksi. Mutta jos hiekkalaatikon vakaus on katastrofi, palkitsemisputkesi pysähtyy jatkuvasti ja kokonaisvaltainen havaittavuus on käytännössä olematon — mitä hyötyä täydellisestä linjauksesta on? Järjestelmän kapasiteetti on jo rajoitettu kaikilla muilla heikkouksilla. Tämä eroaa perustavanlaatuisesti siitä, miten päättelyjärjestelmän optimointi toimii. SGLangilla on päättelymoottorina valtava strategiatila optimointiin, mutta sen putki on suhteellisen lineaarinen — prosessipyyntö, esitäyttö, dekoodaus. Voit eristää pullonkaulat moduuli kerrallaan, ja komponenttien välinen kytkentä on hallittavissa. RL-koulutus on aivan eri asia — painajaismaisen monijärjestelmäinen silmukka: käyttöönoton generointi riippuu päättelymoottorista, palkkiolaskenta ulkoisista ympäristöistä, politiikan päivitykset koulutuskehyksestä ja seuraava käyttöönottokierros päivitetyn politiikan mukaan. Jos jokin linkki katkeaa, koko silmukka romahtaa. Valitettavasti viime vuoden aikana näkemäni perusteella on edelleen monia vakavasti aliarvioituja heikkoja kohtia: Agentin hiekkalaatikko-luotettavuus. Tämä on luultavasti likaisin, raskain ja vähiten akateemisesti hohdokkain työ RL Infrassa nykyään. Agenttipohjainen RL tarvitsee luotettavan suoritushiekkalaatikon julkaisuihin — kuulostaa yksinkertaiselta, mutta osoittautuu painajaiseksi. Konttien vakaus, kylmäkäynnistyksen viive, resurssien eristyksen luotettavuus, hiekkalaatikkotilan hallinta – nämä vaikuttavat paperilla irrotetuilta, mutta markkinoilla olevat hiekkalaatikkotuotteet jäävät jatkuvasti odotuksia alas. Agenttien hiekkalaatikko ei ole algoritmiongelma, mutta se määrittää suoraan datan generoinnin tehokkuuden, joka puolestaan määrittää koulutusnopeutesi. Havaittavuus. Esikoulutuksen virheenkorjaus on melko suoraviivaista — seuraa häviökäyrää, tarkista gradienttinormi, ja yleensä pystyt paikantamaan ongelman. Mutta RL:n debuggaus vaatii kokonaisvaltaisia jäljitysmahdollisuuksia: käyttöönoton laatujakaumia, palkkiotilastoja, off-policy astetta, politiikan päivitysten suuruudet ja jopa logprob-diffudien attribuutio (tuleeko ero päättelypuolelta vai asynkronisen koulutuksen versioviiveestä?). Valitettavasti suurin osa kohtaamieni joukkueiden kanssa lentää näissä ulottuvuuksissa käytännössä sokkona. Tämä johtaa kiusalliseen tilanteeseen — kun koulutustulokset ovat heikot, et edes tiedä, mitä moduulia syyttää. Mittakaava-ongelma. Monet RL Infra -optimoinnit osoittavat mitattavan vaikutuksen vain riittävässä mittakaavassa. Pienimuotoiset kokeet eivät usein paljasta merkittävää eroa — ei siksi, että optimointi olisi turhaa, vaan koska kohina on liian korkea ja askelmäärä liian pieni, jotta signaali ehtisi esiin. Silti laajamittaiset kokeet ovat kohtuuttoman kalliita. Tämä luo noidankehän: et voi todistaa, että optimointisi toimii pienessä mittakaavassa, joten et voi turvata resursseja laajamittaisiin kokeisiin; Ja ilman laajamittaista validointia optimointisi on ikuisesti jumissa ajatuksessa "teoriassa sen pitäisi auttaa." Alan sijoitukset RL Infraan ovat vakavasti ristiriidassa sen todellisen monimutkaisuuden kanssa. Useimmat tiimit käsittelevät sitä kuin korjaustyötä esikoulutusinfrastruktuurin päälle — ota valmis koulutuskehys, kiinnitetään päättelymoottori, liimaa ne yhteen skripteillä ja kutsuu sitä RL Infraksi. Mutta RL-koulutuksen ja esikoulutuksen järjestelmämonimutkaisuus ei ole edes samalla tasolla. Esikoulutusputket ovat lineaarisia, homogeenisia ja niillä on käytännössä nolla ulkoista riippuvuutta. RL-koulutusputket ovat syklisiä, heterogeenisiä ja vahvasti riippuvaisia ulkoisista ympäristöistä. Soveltamalla edellisen arkkitehtonista ajattelutapaa jälkimmäiseen tulee varmasti seinään laajassa mittakaavassa. Todellinen vaikeus järjestelmätekniikassa ei ole yksittäisen moduulin viemisessä äärimmilleen — kyse on moduulien ja globaalin kompromissin välisen yhteyden ymmärtämisestä. Tämä pätee päättelyjärjestelmiin, ja erityisesti RL Infraan, jossa kytkentämitat ovat suurempia, palautesilmukat pidempiä ja virheenkorjauksen tiedon tiheys on paljon pienempi. Haluan päättää kahteen kysymykseen, joita olen pohtinut, ja kuulisin mielelläni muiden tämän alan ammattilaisilta: Missä tarkalleen ottaen junapäättelyn rajatuotot alkavat vähentyä? Kun asynkronisuus otetaan käyttöön, off-policy -tutkinto on jo merkittävä. Onko tuo lähtökohta, onko lisähyöty jatkolinjauksesta itse asiassa korkeampaa sijoitetun pääoman tuottoa kuin saman insinöörityön sijoittaminen hiekkalaatikon vakauteen, palkitsemisputkien optimointiin tai havaittavuusinfrastruktuuriin? Minulla on oma alustava vastaukseni, mutta mielestäni tämä kysymys ansaitsee vakavaa pohdintaa useammalta ihmiseltä — sen sijaan, että linjaus olisi etusijalla vain siksi, että se on näkyvin aihe. Ja siksi se on näkyvin: junapäättelyjen kohdistus sisältää selkeän matemaattisen formalisoinnin ja tuottaa elegantteja ablaatioita — se sopii luonnollisesti artikkeleihin. Mutta miten kirjoitat artikkelin hiekkalaatikon vakaudesta? Miten kehystät konttiorkestroinnin luotettavuuden akateemisena tarinana? Et oikeasti voi. Näin ollen nämä ongelmat jätetään kollektiivisesti huomiotta. Vaikka RL Infra -järjestelmä saavuttaisi bittitason junapäättelyn kohdistuksen, kokonaistehokkuus voi silti olla surkea — koska pullonkaula siirtyi muualle jo kauan sitten. Missä määrin RL Infra voidaan standardoida? Päättelyjärjestelmillä on suhteellisen hyvin määritellyt vertailumittarit — TTFT, TBT, Läpimeno. Nämä objektiiviset indikaattorit mahdollistavat optimointien vaikutusten selkeän arvioinnin. Mutta mitkä ovat RL Infran arviointistandardit? Koulutuksen läpimeno? Näytteen tehokkuus? Koko seinäkellon aika? Optimaalinen arkkitehtuuri voi vaihdella dramaattisesti eri skenaarioissa (koodin generointi vs. agentti vs. päättely). Jos meillä ei ole edes yksimielisyyttä siitä, miltä "hyvä RL Infra" näyttää, insinööriosaamisen kerääminen ja uudelleenkäyttö tällä alalla on erittäin vaikeaa. Onko RL kriittinen polku mallin kyvykkyyksien parantamisessa — tuo arvio on vielä kehittymässä. Mutta jos vastaus on kyllä, infra on aliarvioituin pullonkaula tällä tiellä. Ei siksi, etteikö kukaan työskentelisi sen parissa, vaan siksi, että kollektiivinen huomio on väärinkäytetty. Barrel Effectin julmuus on tämä: kuinka korkea tahansa korkein sauvasi on, se ei voi pelastaa järjestelmää. RL Infra ei ole toissijainen huolenaihe. Se on itsenäinen, korkean monimutkaisuuden järjestelmätekniikan ala. Vain käsittelemällä sitä ensiluokkaisena kansalaisena meillä on mahdollisuus saavuttaa oikean elämän skaala.