Mennyire tudnak magyarul az LLM-ek?
Teszteljünk, különben sohasem fogjuk megtudni.
Az utóbbi időben egyre több ügyfeles beszélgetésen merül fel, hogy valamilyen AI modellt alkalmazzunk a megoldásainkban. Legtöbbször persze a jelenleg népszerű RAG-ekről van szó, ebben nincs semmi újdonság. Abban viszont van, hogy az igények arra fókuszálnak, hogy az AI magyarul kommunikáljon, viszont a jelenlegi megoldások inkább az angol nyelvterületen szeretnének nagyon szakítani.
A szakmai háttérbeszélgetésekben gyakran visszatérő elem az “én már otthon próbáltam az xyz modellt, és egész jól beszélt magyarul”.
Sajnos az ehhez hasonló szubjektív mintavételezéssel nem tudok mit kezdeni, magyar nyelvű HumanEval meg nincs. De mondok rosszabbat: magyar nyelvű tesztekre koncentráló leaderboard sincs sehol. Innen jött az ötlet, hogy kellene készíteni valami hasonlót, vagy legalább megmérni.
Valami olyasmi lebeg a szemem előtt, amit az automatikus tesztekhez hasonlóan le lehet futtatni az újonnan megjelenő modelleken, és kapunk belőle egy objektív mérőszámot, ami megmondja, hogy érdemes-e komolyabb (humán) teszteket folytatni a modell képességeivel kapcsolatban.
Hungarian Language Understanding teszt
Nyilván magamtól nem állok neki teszteket gyártani, mert nem vagyok nyelvész. Viszont Google a barátom, és rátaláltam a Nyelvtudományi Kutatóközpont HuLU csomagjára, és elkezdtem játszani az adatokkal. A HuLU több tesztből áll:
- HuCOLA (Linguistic Acceptability): a megadott mondat nyelvtani helyességet vizsgáljuk. Pl.: “Az Angliáról való könyv tetszik.” => hamis
- HuCoPA (Choice of Plausible Alternatives): egy mondatnál a kiváltó okot, vagy a lehetséges hatását vizsgáljuk, a modellnek a két lehetséges válaszból a helyeset kell kiválasztania. Pl.: “A fürdőt elöntötte a víz.” Lehetséges ok: 1 — “A WC túlcsordult.”. 2 — “Elromlott a bojler.” => 1
- HuRTE — Recognizing Textual Entailment: az vizsgálja, hogy az alap mondatból következik-e a hipotézis. Pl.: “Még nem találtak tömegpusztító fegyvereket Irakban.” Hipotézis: “Tömegpusztító fegyvereket találtak Irakban.” => hamis
- HuSST — Hungarian Stanford Sentiment Treebank: a mondat hangulatát vizsgálja pozitív/semleges/negatív skálán. pl.: “Hatásokkal teli, de túl langyos filmbiográfia.” => negatív
- HuCB — Hungarian Commitment Bank: azt vizsgálja, hogy egy alap mondat, és egy felvetés milyen kapcsolatban állnak egymással ellentmondás/semleges/tartalmaz skálán. Pl.: “ ‘Piroska néni pályafutása végére teljesen megőrült’ Kár érte! Az énekóra volt a csúcs. De ne képzeljétek el, hogy csütörtök, 6. órában!” Felvetés: “A beszélő szerint csütörtökön 6. órában jó volt az ének óra.” => ellentmondás
- HuWLNI — ezzel egyenlőre nem foglalkozunk, majd később.
Fontos, hogy ezek a tesztek a nyelvhelyesség felismerésre koncentrálnak és nem a generálási képességekre. A tesztelésnél emiatt élnem kell egy alapvető feltételezéssel:
Hipotézis: az LLM-ek esetében a nyelvhelyesség-felismerési és a nyelvhelyes generálási képességek között szoros kapcsolat található.
A feltételezést arra alapozom, hogy sok esetben megfigyelhető az LLM modellek működésében hasonló “áthallások”, és ezt nem árt tesztelni. Meg, hát, valahol el kell kezdeni…
Probléma megközelítés
Ha egy automata tesztet szeretnénk összerakni, akkor meg kell vizsgálnunk, hogy pontosan mit és hogyan szeretnénk végrehajtani. Kezdjük az elején.
Adatok
Mivel a HuLU adatszett több részből áll, az adatok különböző szerkezetűek, de a közös tulajdonságuk az, hogy JSON adatformátumban kapjuk meg őket.
Ez annyiból jó, hogy legalább a kódolási problémával nem kell küzdeni, viszont egyből meg is mutatja, a feldolgozás során készülni kell a forrásfile-ok közötti különbségek kezelésére.
Modellek és platformok
Az teljesen világos, hogy egy átfogó teszt esetében sok modell-t kell végigpörgetni a teszteken. Az implementációs és az empirikus tapasztalatok azt mutatják, hogy a zárt modellek jobban odafigyelnek a többnyelvűségre, ezeket viszont (néhány kivételtől eltekintve) csak a saját platformjukon lehet megszólítani. Külön élvezetessé teszi, hogy mindegyik platformnak saját formátumú API-ja van.
Amire figyelni kell a modellek meghajtásakor:
- párhuzamosíthatósági kérdések
- throtling beállítások / paraméterek
- timeout-ok kezelése
- platform-specifikus authentikációs megoldások
Ezek nem könnyítik meg a feladatot.
Prompt-ok
A HuLU adatszett hat különböző tesztsorozatból áll. A kiértékelés során mindegyik adatszetthez külön végrehajtó prompt-ot készítettem:
- A feladat / prompt nyelve magyar. Erre azért van szükség, mert elvárható, hogy egy, a nyelvet jól beszélő LLM-et jól lehessen irányítani. Ha ezen a feladaton is elbukik a modell, akkor alapból sem alkalmazható.
- Nincs túlbonyolított prompt engineering. Nem az a célja a teszteknek, hogy esetleges modell-specifikus prompt-al a maximumot hozzuk ki a tesztből, hanem az, hogy megfigyeljük az LLM-ek egymáshoz képest mennyire jól végzik el a feladatot.
- A nyelvi modellt arra instruáljuk, hogy a válaszait numerikus értékekkel fogalmazza meg. Nem a label értékét szeretnénk viszont látni, így egyfajta átfordítási képességet is magában hordoz a feladat.
A promptok előkészítésénél külön figyelembe vettem azt is, hogy a kisebb modellek is tudjanak egy-egy jó választ adni mindegyik kérdésre. A nagyobb modelleknek ezek után nem szabad, hogy különösebb problémájuk legyen a végrehajtáskor.
Eredmény-tisztítás
A futtatások során kiderült, hogy a bonyolultabb feladatoknál nem, vagy csak nagyon nehezen lehet a generálást arra kényszeríteni, hogy csak egy-egy számmal válaszoljon. Ezért beiktattam egy regexp-et, ami kiszűri a válaszból az első számot, és ezt már össze lehet hasonlítani az elvárt eredménnyel. Ez egyébkén analóg azzal, amit egy éles alkalmazásban végeznénk, szóval ezzel a kis segítséggel nem követünk el főbenjáró bűnt.
Hozzuk össze
A különböző adatkörök, a hozzájuk kapcsolódó prompt-ok, a különböző platformok, és az általuk futtatott modellek, valamint a kiértékelések elvégzésére készítettem egy TypeScript megoldást, ami ezt mind egységesen el tudja végezni:
A teszt eredményeket Excelbe menti el, mert a manuális vizsgálatkor egyszerűbb kezelni / vizualizálni az adatokat:
Teszt eredmények
Ennyi előkészület után jöjjenek az eredmények. A tesztek értékénél a + jel jelenti, hogy MCC értéket számolok (ahol bináris klasszifikációs probléma van), a * pedig pontossági értéket (ahol a kimenet kettőnél több választható érték közüli lehet).
Fontos megjegyezni, hogy az eredmények egyenlőre csak egy részleges adatszetten vannak futtatva, a tréning adatok első száz tételén. Ez részben azért van, mert a modellek mennyiségére koncentráltam, és arra, hogy látszódjanak az esetleges trendek.
Szabadon hozzáférhető modellek eredményei
A szabadon hozzáférhető (open source) modellektől alapvetően nem várunk sokat. A tapasztalatok korábban is azt mutatták, hogy “igen, tudnak valamit, de a generálási képességeik egy old-school Google translate szintjén megragadtak”, ezért itt csak figyelemmel kísérjük a fejlődésüket.
Referenciának az első sor random reference mutatója a mérvadó: ez azt mutatja, ha teljesen véletlenszerűen válaszolunk, akkor milyen eredményt kapnánk (a statisztikailag elvárt eredménytől való eltérés azért van, mert a tesztek label-jei nem egyenletes eloszlásúak).
A teszteknél az első oszlop a minőséget jelző érték, a második szám pedig az, hogy hány minta volt értékelhetetlen (a modell nem válaszolt úgy, hogy ki lehessen belőle nyerni bármilyen releváns numerikus értéket).
Zárt ökoszisztémában elérhető modellek eredményei
Ezeknél a modelleknél az OpenAI / Anthropic verseny az érdekes, mert mindenkinek van (jó) tapasztalata az ChatGPT-vel, és a legtöbb helyről az Opus-t GPT-4-verőnek aposztrofálják.
Referenciának itt már nem a véletlenszerű eredménygenerálást, hanem a legjobb szabadon elérhető modell-t (Llama3 70B) érdemes megadni.
Az IBM Granite modellje (deklaráltan kizárólag angol forrásokra építve) már az első (legegyszerűbb) magyar nyelvi feladaton is teljesen elbukott, ezért nem folytattam a további elemzését.
Kiértékelés
Modellek viselkedése
Amikor lefuttatsz 65 tesztet, akkor szükségszerűen érnek meglepetések:
- Az év elején megjelent Gemma 7B modell méretéhez képest rendkívül jó válaszokat adott
- A Sonnet és a Granite modellek a tőlük elvárthoz képest nagyon rosszul tejesítettek
- A nemrég megjelent Llama 3 70B egy tesztet kivéve folyamatosan jobban teljesített, mint az Anthropic Haiku modell.
A legfontosabb jelenségnek azt mondanám, hogy a régi (Llama2) és az új (Gemma / Llama3) modellek között nagyságrendi eltérések találhatók. Tized-akkora méret ellenére tudnak jobb teszt eredményeket produkálni, és ez igaz a magyar nyelvre speciálisan tovább-oktatott modell (Puli Llumix) esetében is.
A legfontosabb eredmény pedig az, hogy a szabadon elérhető modellek meg sem közelítik a nagy, zárt modellek minőségét. Ezt “tudtuk, csak nem sejtettük”, most viszont kis is lehetett mutatni.
Tesztek
A tesztek kapcsán felfigyeltem arra, hogy több modell is néhány tesztadat esetében konzekvensen hibás választ generál. Itt érdekesnek tartanám egyesével megvizsgálni ezeket az eseteket, de őszintén szólva nem érzem magamban sem az erőt, sem a tudást, hogy ellent mondjak a tesztadatokat készítő szakembereknek.
A másik fontos megfigyelés a kettőnél több választási lehetőségből dolgozó feladatok (HuSST, HuCB) esetében történt: a modellek konzekvensen hibásan ismerik fel a neutrális-ra klasszifikálandó teszteket.
A negatív és a pozitív példákat probléma (és néha hiba nélkül) felismerik — ez a jelenség az összes modellnél megfigyelhető.
Összefoglaló
Természetesen a jelenlegi állapotban még nem tudok válaszolni az alapvető kérdésre, mivel ez még csak az út eleje. Az viszont ígéretes, hogy a szubjektív tapasztalatokat visszaadják a tesztek: GPT-4 és Opus modellek nagyságrenddel jobbak, mint minden más. Ezek alapján szilárd bennem a meggyőződés, hogy jó úton járok.
Folytatása következik…
