Eilen illalla opetin nanochat d32:lle, kuinka laskea r-kirjain mansikassa (tai vastaavissa muunnelmissa). Ajattelin, että tämä olisi hyvä/hauska esimerkki siitä, kuinka ominaisuuksia lisätään nanochatiin, ja kirjoitin täydellisen oppaan tänne: Tämä tehdään uudella synteettisellä tehtävällä "SpellingBee", joka luo esimerkkejä käyttäjästä, joka pyytää tällaista ongelmaa, ja ihanteellisen ratkaisun avustajalta. Sitten harjoittelemme/SFT:n hienosäätöä näihin LLM:n ominaisuuksien antamiseksi tai harjoittelemme edelleen RL:llä tehdäksemme siitä kestävämmän. On monia yksityiskohtia, jotka on saatava oikein erityisesti pienemmissä mallikooissa, ja opas käy ne läpi. Lyhyenä yleiskatsauksena: - Sinun on varmistettava monipuolisuus käyttäjien kehotteissa/kyselyissä - Erityisesti pienissä malleissa, kuten nanochatissa, sinun on oltava todella varovainen tokenisointitietojen kanssa, jotta LLM:n tehtävä olisi helppoa. Erityisesti sinun on oltava varovainen välilyöntien kanssa, ja sitten sinun on hajautettava päättelylaskelma moniin osittaisen ratkaisun merkkeihin: ensin standardoimme sanan lainausmerkkeihin, sitten kirjoitamme sen (merkkien hajottamiseksi), sitten iteroimme ja pidämme eksplisiittisen laskurin jne. - Kannustan mallia ratkaisemaan mallin kahdella eri tavalla: manuaalisella tavalla (päässään päässä) ja myös käyttämällä Python-tulkkia, johon nanochatilla on pääsy. Tämä on vähän "savua ja peilejä", koska jokainen ratkaisu atm on "puhdas", ilman virheitä. Tehtävää voidaan joko muokata simuloimaan virheitä ja havainnollistamaan palautumisia esimerkin avulla tai suorittaa RL. Todennäköisesti molempien yhdistelmä toimii parhaiten, kun edellinen toimii RL:n priorina ja antaa sille asioita, joiden kanssa työskennellä. Jos nanochat olisi paljon suurempi malli, odottaisit tai toivoisit, että tämä ominaisuus "ponnahtaa helpommin esiin" jossain vaiheessa. Mutta koska nanochat d32 "aivot" ovat ~mehiläisen kokoiset, jos haluamme sen laskevan r:t mansikassa, meidän on tehtävä se yliedustamalla sitä datassa, jotta malli oppisi sen aikaisemmin. Mutta se toimii! :)

Pidän uudesta DeepSeek-OCR-paperista. Se on hyvä OCR-malli (ehkä hieman huonompi kuin pisteet), ja kyllä tiedonkeruu jne., mutta joka tapauksessa sillä ei ole väliä. Mielenkiintoisempaa minulle (erityisesti sydämeltään tietokonenäkönä, joka naamioituu väliaikaisesti luonnollisen kielen ihmiseksi) on se, ovatko pikselit parempia syötteitä LLM:iin kuin teksti. Ovatko tekstimerkit tuhlaavia ja vain kauheita, syötteessä. Ehkä on järkevämpää, että kaikki LLM:ien syötteet ovat aina vain kuvia. Vaikka sinulla sattuisi olemaan puhdas tekstinsyöttö, ehkä haluat mieluummin renderöidä sen ja syöttää sen sitten: - Enemmän tietojen pakkausta (katso paperi) = > lyhyemmät kontekstiikkunat, enemmän tehokkuutta - huomattavasti yleisempi tietovirta => ei pelkkää tekstiä, vaan esim. lihavoitua tekstiä, värillistä tekstiä, mielivaltaisia kuvia. - syöte voidaan nyt käsitellä kaksisuuntaisella huomiolla helposti ja oletuksena, ei autoregressiivisellä huomiolla - paljon tehokkaammin. - Poista Tokenizer (syötteestä)!! Olen jo raivonnut siitä, kuinka paljon en pidä tokenizerista. Tokenisaattorit ovat rumia, erillisiä, eivät päästä päähän -vaiheita. Se "tuo" kaiken Unicoden rumuuden, tavukoodaukset, se perii paljon historiallista taakkaa, turvallisuus-/jailbreak-riskiä (esim. jatkotavuja). Se saa kaksi silmälle identtiseltä näyttävää hahmoa näyttämään kahdelta täysin erilaiselta tokenilta verkon sisällä. Hymyilevä emoji näyttää oudolta merkiltä, ei... todelliset hymyilevät kasvot, pikselit ja kaikki, ja kaikki siirto-oppiminen, joka tuo mukanaan. Tokenizerin on mentävä. OCR on vain yksi monista hyödyllisistä näkö-> tekstitehtävistä. Ja teksti-> tekstitehtävät voidaan tehdä visio->tekstitehtäviksi. Ei päinvastoin. Niin monet Käyttäjän viesti on kuvia, mutta dekooderi (Assistantin vastaus) pysyy tekstinä. On paljon vähemmän selvää, kuinka pikseleitä tulostetaan realistisesti... tai jos haluaisit. Nyt minun on myös taisteltava halua taistella nanochatin vain kuvasyötteellä varustettua versiota...

Mukava, lyhyt postaus, joka havainnollistaa, kuinka yksinkertaista tekstin (diskreetti) diffuusio voi olla. Diffuusio (eli rinnakkainen, iteroitu kohinanpoisto, ylhäällä) on laajalle levinnyt generatiivinen paradigma kuvassa/videossa, mutta autoregressio (eli siirry vasemmalta oikealle alas) on tekstin hallitseva paradigma. Äänen osalta olen nähnyt vähän molempia. Monet diffuusiopaperit näyttävät hieman tiheiltä, mutta jos poistat matemaattisen formalismin, päädyt yksinkertaisiin perusalgoritmeihin, esim. Se on vaniljamuuntajasi, mutta kaksisuuntaisella huomiolla, jossa otat iteratiivisesti uudelleen ja peität kaikki "tokens-kankaan" tokenit kohina-aikataulun perusteella, kunnes saat lopullisen näytteen viimeisessä vaiheessa. (Kaksisuuntainen huomio on paljon tehokkaampaa, ja saat paljon vahvempia autoregressiivisiä kielimalleja, jos harjoittelet sillä, valitettavasti se tekee harjoittelusta paljon kalliimpaa, koska nyt et voi rinnakkaistaa sekvenssin himmeää osaa). Joten autoregressio on '.append(token)':n tekemistä tokens-kankaalle samalla kun se osallistuu vain taaksepäin, kun taas diffuusio päivittää koko token-kankaan '.setitem(idx, token)':lla osallistuessaan kaksisuuntaisesti. Ihmisen ajattelu tuntuu naiivisti hieman enemmän autoregressiolta, mutta on vaikea sanoa, etteikö jossain piilevässä ajattelutilassa olisi enemmän diffuusion kaltaisia komponentteja. Tuntuu täysin mahdolliselta, että voit interpoloida niiden välillä edelleen tai yleistää niitä edelleen. Ja se on osa LLM-pinoa, joka tuntuu edelleen hieman vaihdettavalta. Nyt minun on vastustettava halua harjoitella nanochattia diffuusiolla.