Neljännessä artikkelissa vLLM:ien toteuttamisesta tyhjästä kiinnitämme huomiomme toiseen näennäisesti yksinkertaiseen mutta ratkaisevaan Transformer-arkkitehtuurin komponenttiin: RMSNormiin (Root Mean Square Normalization). Katsotaanpa ensin, mitä normalisointi on, oletetaan, että olet juuri suorittanut loppukokeen ja kolmen kurssin tulokset tulevat esiin: Matematiikka: 120/150 Englanti: 80/100 Fysiikka: 160/200 Mikä kurssi on paras? Jos vertaat 120, 80, 160 suoraan, tulet fysiikan parhaaseen johtopäätökseen. Mutta todellinen tilanne on, että kolme kenttää ovat itse asiassa yhtä hyviä. Matematiikka: 120/150 = 80 % Englanti: 80/100 = 80 % Fyysinen: 160/200 = 80 % Tämä on normalisoinnin ydinajatus: eri ulottuvuuksien ja eri alueiden tietojen muuntaminen yhtenäiseksi vertailustandardiksi. Miksi hermoverkot on normalisoitava? Kuvittele, että pelaat viestipeliä. Ensimmäinen henkilö sanoi "Pidän omenoista", ja kun se siirtyi kymmenennelle henkilölle, siitä tuli "Pidän ananaksesta". Tämä on syvien hermoverkkojen kohtaama ongelma. Jokainen verkon kerros tekee joitain laskelmia syötteelle ja välittää sitten tulokset seuraavalle tasolle. Ongelmana on, että kerrosten määrän kasvaessa nämä arvot muuttuvat yhä hallitsemattommiksi - joko räjähtävät tai katoavat jälkiä jättämättä. Kuten viestipelissä, tieto vääristyy vähitellen lähetyksen aikana. Normalisointikerroksen lisääminen malliin voi vähentää gradientin räjähdyksen tai katoamisen todennäköisyyttä, ja mallin koulutusprosessista tulee vakaampi. Normalisointitekniikka on kehittynyt BatchNormista LayerNormiin ja lopulta RMSNormiin, ja siitä on tullut suurten mallien vakiokokoonpano. Artikkelini vie sinut normalisointitekniikan evoluutiohistoriaan, jos olet kiinnostunut, voit tarkistaa alkuperäisen artikkelin.

Clauden agenttitaidot ovat pohjimmiltaan "kontekstin purkamista", joka siirtää pitkät taitotiedot pois asiayhteydestään ja lataa ne tarvittaessa. Sattumalta Manus' Peak jakoi äskettäin myös joitain "kontekstuaalisia purkamisvinkkejä". Manuksella on monia työkaluja, mutta se ei anna mallille täydellistä määritelmää näistä työkaluista. Joten mistä se tietää, mitä työkaluja on olemassa ja miten niitä kutsutaan? Kuvittele, että annat sinulle uuden tietokoneen, mistä tiedät, mitä työkaluja on saatavilla? Keskivertokäyttäjä avaa sovellusluettelon, ja ohjelmoija "ls /usr/bin" nähdäkseen, mitä komentoja on saatavilla. Vastaavasti Manuksen ratkaisu on kertoa mallille järjestelmäkehotteessa, että tietyssä kansiossa on monia esiasennettuja komentoriviapuohjelmia. Yleisimmin käytetyt työkalut (ls, grep, cat, vähemmän, enemmän jne.) on oletusarvoisesti sisäänrakennettu järjestelmän kehotteisiin. Sen sijaan, että kertoisit mallille, miten työkaluja käytetään, luettele vain työkalun nimi ja kerro sitten, miten --help-parametria käytetään työkalun käytön ymmärtämiseen. Parasta on, että nämä komentotulkin toimintamallit on opittu, joten sillä on vahva yleistyskyky, ja uusien työkalujen lisäämiseksi sinun tarvitsee vain laittaa komento kansioon. Huomasin, että Manus todella noudatti Unixin filosofiaa loppuun asti: KISS (Keep It Simple, Stupid).