A GPT-szerű modell fejlesztői szemmel

Egyetlen feladat, sokszor ismételve

Amikor egy nagy nyelvi modell választ ad, könnyű azt hinni, hogy megérti a kérdést, majd megfogalmaz rá egy feleletet. A valóság sokkal egyszerűbb és fejlesztői szempontból sokkal hasznosabb. A modell megkapja az addigi szöveget, és egyetlen kérdésre válaszol. Mi a legvalószínűbb következő szövegdarab. Ezt a darabot hívjuk tokennek. A token nagyjából egy szó vagy egy szótöredék, néha csak néhány karakter. A modell kiszámolja, melyik token illik a leginkább az eddig látott szöveghez, hozzáilleszti, majd az egészet elölről kezdi. Így épül fel a válasz, tokenről tokenre, balról jobbra.

Ez a kép azért fontos, mert eloszlat egy tévhitet. A modell nem egy nagy adatbázisban keres kész válaszokat, és nem egy döntési fát jár be. Egyszerűen folytatja a szöveget úgy, ahogyan a tanulás során látott hasonló szövegek folytatódtak. Amit mi kérdésnek élünk meg, azt a modell csak egy szövegkezdetnek látja, amit ki kell egészíteni.

Honnan tudja, mi a valószínű

A modell képessége nem varázslat, hanem tanulás eredménye. A fejlesztők óriási mennyiségű szöveget adtak neki, könyveket, cikkeket, beszélgetéseket, dokumentációkat, és a tanulás során a modell megpróbálta újra és újra kitalálni a soron következő tokent. Amikor tévedett, apró igazítások történtek benne, hogy legközelebb jobban tippeljen. Ezt sok milliárdszor megismételve a modell rendkívül jó lett abban, hogy felismerje a nyelv mintázatait. Megtanulta, hogy a kérdésre általában válasz jön, hogy a felsorolás elemei hasonló formájúak, hogy egy udvarias levél hogyan zárul.

Fontos, hogy a modell nem a konkrét szövegeket jegyzi meg, hanem a bennük rejlő szabályszerűségeket. Ezért tud olyan mondatot alkotni, amelyet szó szerint soha senki nem írt le. Nem másol, hanem a látott mintázatok alapján állít elő új, illeszkedő szöveget. Fejlesztőként ez azt jelenti, hogy a modell erőssége a nyelvi és fogalmi minták kezelése, nem a pontos tényadatok tárolása.

Ebből egy hasznos gyakorlati következtetés adódik. Ha egy feladat lényegében nyelvi vagy szerkezeti jellegű, például egy szöveg átfogalmazása, egy hangnem megváltoztatása vagy egy vázlat rendezése, akkor a modell jó eséllyel megbízhatóan teljesít, mert pontosan ilyesmiből látott rengeteget. Ha viszont egy feladat pontos, ellenőrizhető tényt kíván, például egy konkrét dátumot, egy jogszabályi számot vagy egy egyedi ügyfél adatait, akkor résen kell lenni. A modell ilyenkor is ad egy magabiztosnak tűnő választ, de az esély a tévedésre sokkal nagyobb. A fejlesztő dolga, hogy a feladatot úgy formálja, hogy a modell a maga erősségén dolgozhasson, a kényes tényeket pedig máshonnan, megbízható forrásból kapja meg.

A token, a nyelv apró építőköve

Érdemes egy kicsit közelebbről megnézni, mi is az a token, mert fejlesztőként nap mint nap ebben mérünk. A token nem pontosan egy szó. Egy gyakori szó lehet egyetlen token, egy ritkább vagy hosszabb szó viszont több darabra hasadhat, és a szóközök, írásjelek is beleszámítanak. A modell tehát nem betűkben és nem is teljes szavakban gondolkodik, hanem ezekben a köztes darabokban. Ez elsőre apró részletnek tűnik, de több ponton is fontos lesz.

Az egyik ilyen pont a költség. Mivel a legtöbb szolgáltató a felhasznált tokenek száma alapján számláz, és a modell sebessége is ettől függ, a token a tényleges elszámolási egység. Érdemes tudni azt is, hogy a magyar szöveg jellemzően több tokenre bomlik, mint egy ugyanolyan hosszú angol mondat, mert a modellek nyelvi darabolása az angolra van a legjobban hangolva. Ez a gyakorlatban azt jelenti, hogy egy magyar nyelvű alkalmazás ugyanazért a tartalomért kicsit többe kerülhet, és ezt jó előre betervezni.

A másik pont a kiszámíthatóság. Mivel a modell tokenről tokenre, valószínűségek alapján halad, ugyanarra a kérésre nem feltétlenül ad szó szerint ugyanolyan választ. Ez egy chatben kellemes, egy tesztelendő alkalmazásban viszont nehezítő tényező. Ha azt szeretnénk, hogy a válasz a lehető legstabilabb legyen, alacsonyra vesszük a hőmérsékletet, és a promptot úgy fogalmazzuk, hogy minél kevesebb teret hagyjon a szabad értelmezésnek. Ha kreativitást várunk, épp fordítva teszünk. Ez a beállítás nem apróság, hanem az egyik első döntés, amit egy AI alkalmazásnál tudatosan meg kell hozni.

Miért számít ez az appfejlesztésben

Ha megértjük, hogy a modell valószínűségeket számol, sok minden a helyére kerül. Rögtön világos lesz, miért ad néha ugyanarra a kérésre kicsit más választ. A legvalószínűbb token nem mindig ugyanaz, és a rendszer szándékosan enged egy kis véletlent, hogy a szöveg természetesebb legyen. Ezt a véletlen mértékét egy beállítással, a hőmérséklettel lehet szabályozni. Alacsony hőmérsékleten a modell szinte mindig a legvalószínűbb tokent választja, ezért kiszámíthatóbb és egyhangúbb. Magasabb értéken bátrabban nyúl a kevésbé valószínű szavakhoz, ezért kreatívabb, de kockázatosabb.

Ebből fakad az is, hogy a modell magabiztosan tud tévedni. Ha egy tény nem szerepelt elég erősen a tanult mintákban, a modell akkor is a legvalószínűbbnek tűnő folytatást írja le, ami lehet, hogy egyszerűen hibás. Ezt a jelenséget hívjuk hallucinációnak. Nem szándékos hazugság, hanem a valószínűségi működés természetes velejárója. Aki appot épít, annak ezzel eleve számolnia kell, és úgy kell megterveznie a rendszert, hogy a fontos tényeket ne bízza vakon a modellre.

Ez a szemlélet vezet el a helyes elvárásokhoz. A modellt nem tévedhetetlen tudásforrásként érdemes kezelni, hanem gyors, nyelvileg ügyes segédként, amelynek a munkáját ott ellenőrizzük, ahol a pontosság tétje nagy. Ahol a szöveg minősége és gördülékenysége a fontos, ott hagyatkozhatunk rá bátrabban. Ahol egy hibás adat kárt okozna, ott az alkalmazásnak külön mechanizmust kell adnia a tények ellenőrzésére. Ez a kettősség végigkíséri majd az egész tananyagot, és sok későbbi döntés innen ered.