A három eszköz három különböző problémára
A prompttervezés (prompt engineering) azt változtatja meg, hogyan viselkedik a modell, anélkül hogy a súlyaihoz hozzányúlnál. Utasítást, szerepet, példákat és formátumot adsz, a modell pedig ezekre reagál. A visszakereséssel bővített generálás (retrieval-augmented generation, RAG) azt oldja meg, hogy a modell a saját, naprakész és privát tudásoddal dolgozzon, amit inferenciakor a promptba emelsz. A finomhangolás (fine-tuning) magát a modellt tanítja tovább egy saját, címkézett adathalmazon, tehát a kívánt viselkedést beleégeti a súlyokba. Ez a három eszköz nem egymás alternatívája ugyanarra a bajra, hanem három különböző bajra ad választ. Ezért az első kérdés soha nem az, hogy melyik a legjobb, hanem az, hogy mi hiányzik a rendszernek.
Tudás vagy viselkedés
A legtöbb rossz döntés abból ered, hogy a mérnök összekeveri a tudás és a viselkedés hiányát. Ha a modell egy konkrét, friss vagy céges tényt nem ismer, például egy belső szabályzat aktuális változatát, azt finomhangolással nem lehet megbízhatóan pótolni. A finomhangolás nem lexikonszerű tudásfeltöltés, és a betáplált tényeket a modell hajlamos elmosni vagy összekeverni. Erre való a RAG, amely a pontos tényt inferenciakor, forrással együtt teszi a modell elé. Fordítva, ha a modell tudja a választ, de rossz formában, rossz hangnemben vagy megbízhatatlan szerkezetben adja, az viselkedési kérdés. Ilyenkor előbb prompttervezéssel próbálkozunk, és csak akkor lépünk a finomhangoláshoz, ha a kívánt viselkedés promptból nem stabilizálható, vagy a stabilizáláshoz olyan hosszú prompt kellene, amit már nem éri meg minden kérésnél elküldeni.
RAG erre való
- Friss, változó vagy privát tények bevitele
- Forrásmegjelölés és nyomon követhetőség
- Nagy vagy gyakran frissülő tudásbázis
- A tudás cseréje kód nélkül, az indexben
Finomhangolás erre való
- Stabil stílus, hangnem, kimeneti forma
- Egy szűk feladat sok, hasonló példával
- Rövidebb prompt, olcsóbb futás nagy forgalomnál
- Olyan viselkedés, amit promptból nehéz elérni
Az adatigény szabja meg a sorrendet
A három eszköz nagyon eltérő mennyiségű adatot kíván. A prompttervezéshez elég néhány gondosan megválasztott példa, ezt hívjuk kevés példás tanulásnak (few-shot). A RAG-hoz nem címkézett tanítóadat kell, hanem jó minőségű, feldarabolt és indexelt dokumentumforrás, tehát a munka nagy része adatelőkészítés, nem tanítás. A finomhangoláshoz ezzel szemben nagyszámú, jó minőségű bemenet és elvárt kimenet pár szükséges, és a modell csak akkor tanul belőle jól, ha ezek konzisztensek. Chip Huyen egy elterjedt hüvelykujjszabályt idéz, amely szerint egy jól megírt prompt nagyságrendileg százas nagyságú tanítópéldával ér fel, bár ez feladatonként erősen szór. A gyakorlati következtetés egyszerű. Prompttal indulsz, mert azonnal kísérletezhetsz, RAG-gal bővíted, amint tudás hiányzik, és csak akkor finomhangolsz, amikor már összegyűlt elég példa és a feladat leírása stabil.
A költség két helyen jelentkezik
A költséget mindig két oldalról kell nézni, a fejlesztési és a futási oldalról. A prompttervezés fejlesztési költsége alacsony, mert azonnal iterálsz, viszont a futási költsége magas lehet, ha a viselkedés eléréséhez hosszú rendszerutasítás és sok példa kell, hiszen ezeket minden egyes kérésnél elküldöd és megfizeted. A RAG fejlesztési költsége közepes, mert az indexet fel kell építeni és karban kell tartani, a futási költsége pedig a promptba emelt dokumentumok hosszával nő. A finomhangolás fejlesztési költsége a legmagasabb, mert adatot kell gyűjteni és tanítani, cserébe viszont a kívánt viselkedést a modellbe égeti, így rövidebb prompttal is működik, és nagy forgalomnál a kérésenkénti költség jelentősen csökkenhet. Éppen ezért a finomhangolás gyakran nem minőségi, hanem költségdöntés, amely akkor térül meg, ha a rendszer már sok, egymáshoz hasonló kérést szolgál ki.
A finomhangolás nem feltétlenül a teljes modell
Amikor finomhangolásra jut a döntés, egy fontos mérnöki választás következik, hogy a modell összes súlyát tanítod tovább, vagy csak egy kis részét. A teljes finomhangolás sok erőforrást igényel, és megvan az a kockázata, hogy a modell a saját, korábban jól működő általános képességeiből felejt, amit katasztrofális felejtésnek (catastrophic forgetting) hívunk. Ezért a gyakorlatban gyakran a paraméterhatékony finomhangolást (parameter-efficient fine-tuning) választjuk, amely a modell nagy részét befagyasztja, és csak kisszámú új paramétert tanít mellé. Ennek egy elterjedt formája az alacsony rangú adapterek beillesztése, amikor a modell mellé kis, betanítható rétegeket teszünk, az eredeti súlyokat pedig változatlanul hagyjuk. Ez lényegesen olcsóbb, kisebb az adatigénye, és mivel az adapter külön él, több feladathoz több adaptert is tarthatsz ugyanahhoz az alapmodellhez. A tanulság az, hogy a finomhangolás nem egyetlen, mindent vagy semmit döntés, hanem egy skála, amelyen a feladat mérete és a rendelkezésre álló adat szabja meg, milyen mélyen nyúlsz a modellhez.
A gyakorlatban a három együtt él
Éles rendszerben ritkán kell választani, mert a három eszköz jól kombinálódik. Egy tipikus fejlett felállásban egy finomhangolt modell adja a stabil hangnemet és a megbízható kimeneti formát, a RAG hozza a friss és forrásolt tényeket, a prompt pedig összefogja a feladatot, meghúzza a korlátokat és beállítja a példákat. A mérnöki fegyelem az, hogy egyszerre csak egy változót mozgass, és minden lépést a hatodik leckében tárgyalt evalokkal ellenőrizz. Ha előbb finomhangolsz, majd rögtön hozzányúlsz a RAG-hoz és a prompthoz is, nem fogod tudni, melyik változtatás mit okozott. A helyes sorrend tehát nemcsak olcsóbb, hanem mérhetőbb is. Prompttal a legtöbbet elérni, RAG-gal a tudást pótolni, és finomhangolással megszilárdítani azt, ami már bevált.
A döntési sorrend, amit érdemes tartani. Kezdd prompttervezéssel, mert azonnal iterálsz és mérsz. Adj hozzá RAG-ot, amint tudás hiányzik, mert azt a finomhangolás nem pótolja megbízhatóan. Finomhangolj utoljára, amikor a feladat leírása már stabil, összegyűlt elég konzisztens példa, és a rövidebb prompt futási költsége vagy egy nehezen prompttolható viselkedés indokolja.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →