(Kiemelt kép: Unsplash+)
Bár a GenMI szuperjó, kétségtelen, hogy a belőle legtöbbet profitáló vállalatok megtalálták a módját annak, hogy saját információikat integrálják a mesterséges intelligenciás modelljeikbe. Amit azonban nem feltétlenül látunk, az egy világos gondolatmenet arra vonatkozóan, hogy egy vállalatnak hogyan is kellene helyesen megközelítenie a GenMI-stratégiáját. Olvashatunk az interneten arról, hogy a Bloomberg hogyan talált nagy értéket a saját nagy nyelvi modelljének (LLM) nulláról való felépítésében, vagy találkozhatunk számos közösségi médiabeli bejegyzéssel arról, hogy milyen nagyszerű a keresés kiterjesztett generáció (RAG). Hogy egyértelmű legyen, mindegyik taktika kiváló a maga nemében, de ahogyan azt el tudjuk képzelni, nincs egy mindenre megfelelő és mindenható megközelítés és egy kaptafára fel is húzható megoldás.
Ez azt jelenti, hogy ez a cikk nem is fog végleges választ adni a nyájas olvasó vállalatának helyzetére. Inkább az lesz a célunk, hogy keretet adjunk Önnek ahhoz, hogyan gondolkodjanak a GenMI integrálásáról a vállalati információikkal kapcsolatban. Az első részben megpróbálunk egy általános, magas szintű képet adunk arról, hogy mi a három különböző lehetőség amit bevethetnek, de nem térünk ki a legapróbb technikai részletekre. A második részben néhány konkrét szempontot fogunk ismertetni, melyeket érdemes átgondolni, amikor az első részben vázolt lehetőségek közül választunk. Minden további nélkül vágjunk bele!
Hogyan integráljuk a vállalatunk információit a mesterséges intelligenciával?
Magas szinten három különböző módja van annak, hogy saját vállalatunk adatait hasznosítani tudjuk. Ezek a következők: Saját modell építése a semmiből, finomhangolás és visszakeresés kiterjesztett generálás (RAG) A következőkben részletesebben is bemutatjuk, hogy ezek közül melyek ezek, valamint az egyes technikai árnyalatok.
Saját modell építése a semmiből
Ahogyan hangzik, ez az a helyzet, amikor a saját GenMI-modellünket az alapoktól kezdve építjük fel. Így jöttek létre az olyan népszerű modellek, mint az OpenAI ChatGPT vagy az Anthropic Claude, és nyilvánvaló, hogy ezek a modellek nagy sikert arattak. De ennek a sikernek hatalmas ára volt, mind képletesen, mind szó szerint. Ahhoz, hogy egy saját modellt a semmiből, hatékony eredményekkel építsünk, alapvetően rengeteg erőforrásra van szükségünk, többek között rengeteg adatra, rengeteg számítási teljesítményre (ami viszont sok pénzbe kerül), és rengeteg emberi tőkére a modell felépítéséhez szükséges tudáshoz (ami szintén sok befektetésbe és anyagi forrásba kerül).
A másik kihívás az, hogy még egyetlen iparág nem tudta megfogalmazni a GenMI-modell saját vállalatának felépítésének valódi értékét, mert alapvetően senki sem csinálta még ezt előttük. Más szóval, nincs jó összehasonlítási alapunk. Ez is nagyrészt a GenMI-modell nulláról való felépítéséhez szükséges erőforrások tömegére vezethető vissza. Ön is elgondolkodhat azon, hogy „Mennyi adatra van szükségem?” vagy „Mennyi számítási teljesítményre van szükségünk?”. Ezekre a kérdésekre a bejegyzés további részében kitérünk.
Finomhangolás
A finomhangolás nagyjából a középutat jelenti a saját modell nulláról való felépítése és a hamarosan megjelenő harmadik lehetőségünk, a keresés-növelte generálás (RAG) között. A hagyományos mélytanulásban járatosak számára a finomhangolás nagyon hasonlít a transzfer tanulás fogalmához. A finomhangolás egy előzetesen betanított modellel kezdődik, mint kiindulópont, és folytatja a modell betanítását a vállalat saját adatain. Bár ez nem feltétlenül garantálja, hogy olyan teljesítményű lesz, mint egy nulláról elkészített modell, sok vállalat mégis nagy sikereket ért el a finomhangolási taktika alkalmazásával.
A GenMI-térben a finomhangolásnak van egy speciális formája, a Low Rank Adaptation, röviden LoRA. (Találkozhatunk a QLoRA kifejezéssel is, mely ugyanaz az elképzelés, mint a LoRA, kivéve, hogy egy másik koncepciót is magában foglal, melyet kvantálásnak neveznek, innen a Q!) A LoRA azért olyan menő, mert a finomhangolás egy speciális formáját hajtja végre, mely NEM befolyásolja az eredeti, előtanított modell súlyait. Ez azért jó, mert nagy költségeket és erőforrásokat takaríthat meg azáltal, hogy egy előképzett modellt szolgál ki, és az üzleti igények alapján több finomhangolt LoRA-adaptert is képes „forrón cserélni”. Például egy szerverfürt kiszolgálhatja a Mistral 7B ugyanazt a példányát, és ha a marketingosztályról érkezik egy lekérdezés, akkor egyszerűen be lehet kapcsolni a „Marketing LoRA adaptert”. Vagy fordítva, ha az értékesítési csapatának kérdése lenne a modellről, akkor a „Sales LoRA adaptert” is be lehet(ne) kapcsolni.
Ismételjük, ezek a lehetőségek valószínűleg nem lesznek olyan teljesítőképesek, mint egy „scratch-made” modell, de a költség-haszon arányuk sokkal kedvezőbb. Ahelyett, hogy adatok tömegére lenne szükség, a finomhangolás viszonylag kis adatmennyiséggel működik. A finomhangolás számítási költségei is lényegesen alacsonyabbak, mint a scratch-made modell kiképzése. És a teljesítmény valóban jó lehet! Szeretnénk még egyértelműbben leszögezni, hogy a finomhangolás egy rendkívül életképes lehetőség, ha helyesen végzik azt a megfelelő szakemberek.
Visszakeresési kiterjesztett generálás
A harmadik lehetőségünk itt érdekes módon az, amikor egyáltalán nem készítünk és nem is módosítjuk a GenMI modellt. Ehelyett a RAG-ot kihasználó vállalat a felhasználó kérdésének vagy lekérdezésének megválaszolását támogató információkat kontextusként bocsátja a GenMI-modell rendelkezésére. Képzeljünk el például egy jogi céget, mely egy csomó jogi dokumentumot tartalmaz, és a cég ügyvédje szeretné megérteni a jogi precedenst egy adott témában, amelyet X témának nevezünk. Ha az ügyvéd felteszi a kérdést: „Milyen jogi precedensek vannak az X témával kapcsolatban?”, a RAG koncepció a következőképpen működik: A kérdés feltevése előtt (általában a RAG-projekt indításakor) a cég összes jogi dokumentumát vektorbeágyazásokká alakítják. A vektoros beágyazások hosszú, rögzített hosszúságú számlisták, melyek az eredeti szöveget reprezentálják, és az a jó tulajdonságuk, hogy fix hosszúságúak, ez azt jelenti, hogy matematikailag össze tudjuk hasonlítani az egyik beágyazást a másikkal.
Ezt a szövegalapú kérdést vektoros beágyazássá alakítjuk át, és ahogy az előző lépésben megjegyeztük, ezt a vektoros beágyazást használhatjuk arra, hogy összehasonlítsuk a jogi dokumentumok korpuszát reprezentáló összes vektoros beágyazással. Attól függően, hogy hányat szeretnénk, kivonhatjuk a „top K” számú hasonló egyezést. Az itteni példánkban egy hasonló egyezés kezdődhet így: „19xx-ben X témát vitatták meg ebben a konkrét bírósági ügyben…”. Az ügyvédi kérdéshez hasonló találatok meghatározása után az előző lépésből származó kontextust az eredeti kérdéssel együtt betápláljuk a GenMI modellbe. Ezt egy kis „prompt mérnökség”-gel tehetjük meg. Íme egy nagyon egyszerű példa arra, hogyan nézhet ki ez a prompt engineering:
Ön hasznos asszisztens egy jogi cégnél. Kérem, válaszoljon a következő kérdésre vagy lekérdezésre, melyet háromszoros hátsó kereszttel jelölünk a megfelelő szakaszban, a kontextus pedig szintén háromszoros hátsó kereszttel jelöljük a saját megfelelő szakaszában. Kérdés/kérdés: Milyen jogi precedensek vannak az X témával kapcsolatban? Kontextus: 19xx-ben az X témát ebben a konkrét bírósági ügyben vitatták meg A GenMI modell szintetizálja a megfelelő választ az előző lépésben adott felkérés alapján.
Mivel maga a GenMI-modell nem módosul, ez azt jelenti, hogy a RAG-felhasználók a dobozon kívüli megoldások, köztük az olyan kereskedelmi API-k, mint az OpenAI vagy az AWS Bedrockban található API-k felhasználásával is boldogulhatnak. Az egyetlen további dolog, amit egy RAG-felhasználási esetnél figyelembe kell vennie, az az, hogy hogyan fogja kezelni a vektorbeágyazásokat. Jelenleg a legnépszerűbb módja ennek egy vektoradatbázis használata. Ha ezt az utat választjuk, akkor gondosan kell kezelnünk a vektoradatbázis-stratégiánkat, mivel valószínűleg több GenMI-megoldásban is újrafelhasználhatóak lesznek majd ezek az információk.
Megfontolandó szempontok a választáshoz
Most, hogy felvázoltuk a három magas szintű lehetőséget, nézzünk meg néhány olyan szempontot, melyek befolyásolhatják, hogy melyik lehetőséget választjuk.
Számítási komplexitás és költségek
Nem véletlenül ez az első és legfontosabb kérdés. Ezeknek a lehetőségeknek a költségei elég drasztikusan, szinte megfizethetetlenül különböznek egymástól. A saját GenMI-modell vagy finomhangolt modell saját tárhelye szó szerint ezerszer drágább, mint egy kereskedelmi megoldás, például az AWS Bedrock használata. A Hugging Face mérnöke, Phil Schmid szerint a Mistral 7B futtatásához ajánlott SageMaker példánytípus az ml.g5.2xlarge. Egy ilyen típusú példány futtatása óránként 1,51 euróba kerül(het). Egyetlen, kis projekthez általában legalább 3 példányra van szükség a magas rendelkezésre állás és hibatűrés érdekében, így a számítások szerint ez több mint 39 ezer eurót jelent(het) akár. És ez csak egyetlen kis projektre vonatkozik. A legtöbb vállalatnak egynél jóval több projektje lesz nyilvánvalóan!
Ezt állítsuk szembe bármelyik kereskedelmi megoldási szolgáltatással, például az OpenAI-val vagy az AWS Bedrockkal. Bár az árképzés eltérő, a költségek a felső határon 40 euró körül mozognak 1 millió input és output tokenenként. Nehéz közvetlenül mérni a költségeket, mivel a felhasználás vállalatonként eltérő lesz, de nyugodtan mondhatjuk, hogy a kereskedelmi megoldások ma már szinte minden vállalat számára sokkal, de sokkal gazdaságosabbak. Mivel a saját tárhely és a kereskedelmi megoldás használata közötti különbség olyan nagy, a legtöbb vállalat valószínűleg először a RAG-technikákat akarja majd felfedezni. Igaz, ez nem jelenti azt, hogy a RAG feltétlenül a legköltséghatékonyabb, mivel a vektoros adatbázis-opció kiválasztása gyorsan megnövelheti a RAG-megoldás költségeit. Elgondolkodhatunk az OpenAI vagy az AWS Bedrock által nyújtott menedzselt finomhangolási szolgáltatások kihasználásán is. Ezek természetesen csak egy lehetőséget jelentenek, de ez is elvezet minket a következő pontunkhoz.
Információ megőrzési aggályok
Sok vállalatnak különböző okokból hosszú ideig kell megőriznie az információkat. Amikor hosszú időre gondolunk, akkor 25-50 év feletti időtartamra gondolunk. Érdekes módon azzal lehet érvelni, hogy egy finomhangolt GenMI modell a vállalati információk egy védett darabját jelentheti, ami azt jelentené, hogy ez is az információmegőrzési aggályok hatálya alá tartozik. Azért osztjuk meg ezt, mert a fenti pontban a kísértés az lenne, hogy egy menedzselt finomhangolási szolgáltatás igénybevételével csökkentsük a költségeket, de napjainkban az ilyen szolgáltatások igénybevételének feltételei általában nem kedveznek az információmegőrzési irányelveknek. Konkrétan, ezek a menedzselt finomhangolási szolgáltatások általában nem teszik lehetővé, hogy az ügyfél közvetlenül hozzáférjen a mögöttes finomhangolt GenMI-modell artefaktumaihoz, és ezek a menedzselt szolgáltatók nem vállalnak kötelezettséget az e vállalatok információmegőrzési irányelvei által megkövetelt hosszú határidők betartására. Ez nem jelenti azt, hogy a finomhangolásnak vége. Egy vállalat továbbra is elvégezheti a finomhangolást menedzselt szolgáltatás nélkül, így a vállalat továbbra is teljes mértékben ellenőrizheti a modell artifaktumait. Sajnos azonban ezzel újra elővesszük az első pontból eredő problémát, mivel ezek a saját kezelt modell-artefaktumok önhostingot igényelnek, így újra ott vagyunk a költségproblémánál, amit korábban el akartunk kerülni!
Az utasítások hangolása
Ha még nem tudnánk, a legtöbb GenMI-modell, melyet ismerünk, utasítás-tuningoláson esett át a jobb felhasználói élmény érdekében. Az utasításhangolás az emberi visszajelzések felhasználásának folyamata annak érdekében, hogy a modell kedvezőbb eredményeket produkáljon az emberi folyamatok támogatása érdekében. Alapértelmezés szerint az alapvető GenMI modellek NEM utasítás hangoltak. Mit jelent ez? Képzeljük el, hogy egy GenMI alapmodellt egy csomó, egyszerűen csak a Google automatikus kitöltési javaslataiból álló adathalmazon képeztünk ki, és semmi máson. Ha azt a kérdést tennénk fel, hogy „Mi Magyarország fővárosa?”, meglepődhetnénk, ha egy nem utasítás hangolt modell azt válaszolná, hogy „Mi Szlovákia fővárosa?”. Ennek az az oka, hogy a képzés idején a GenMI-modell azt igyekszik utánozni, amit a képzési adatokban látott, és ha csak a Google automatikus kitöltési javaslatokat látta, akkor nagy valószínűséggel valami mást fog kapni, ami egy másik Google automatikus kitöltési javaslatra hasonlít.
Igaz, ez egy kissé drasztikus példa, de a lényeg továbbra is az, hogy nagy valószínűséggel egy utasításra hangolt GenMI-modellt szeretnénk használni az üzleti folyamataink támogatására. Ha a saját GenMI-modellünket a semmiből képezzük ki, ez azt jelenti, hogy mostantól mi felelünk ezért a folyamatért. Az utasítások hangolása az emberi visszajelzésen alapuló megerősített tanulás (RLHF) nevű technikai folyamat segítségével történik, és bár az RLHF közel sem olyan számításigényes, mint a képzés, az RLHF kihívása a megfelelő emberi visszajelzés megszerzése.
Ha nem tudnánk, az olyan cégek, mint az OpenAI és az xAI nagy összegeket fektettek be emberi személyekbe, hogy elvégezzék ezt az emberi szintű hangolást, és amint azt el tudja képzelni, ez egy költséges eljárás. A finomhangolás iránt érdeklődő emberek számára a jó hír az, hogy általában lehetséges egy már instrukciókkal hangolt modell finomhangolása nagyszerű eredményekkel. De azok számára, akik egy modellt a semmiből szeretnének felépíteni, az RLHF sokkal összetettebb problémává válik, melyet kezelniük kell.
Az üzleti folyamatokban használt szemantikai kontextus
Sok vállalat rengeteg adattal rendelkezik, és nagy a kísértés, hogy azt higgyük, talán elég adat áll rendelkezésünkre ahhoz, hogy a semmiből képezzük ki saját GenMI-modellünket. Ez lehet, hogy így is van, de valójában úgy képzeljük, hogy sok vállalat nem lenne képes egy GenMI-modellt csak a saját adatai alapján kellőképpen kiképezni. Ennek az az oka, hogy a legtöbb cég olyan üzleti kifejezésekre támaszkodik, melyeket mi, emberek általában úgy értünk, hogy egy-egy dolgot jelentenek, de nem szabad beérnünk azzal a feltételezéssel, hogy a GenMI modell ugyanúgy képes általánosítani ezeket a szemantikai összefüggéseket is.
Használjunk egy konkrét példát. Tegyük fel, hogy egy főzős weboldalt üzemeltetünk, ahol rengeteg recept van különböző főételekhez. A képzési adathalmaz részeként felhasználjuk az összes receptinformációt, mely valószínűleg olyan dolgokat tartalmaz, mint a hozzávalók és a főzési utasítások. Most tegyük fel, hogy jövünk a kezdő főzőtudásunkkal, és megkérdezzük a GenMI modellünket: „Említetted, hogy egy olyan dolgot főzöl, amit úgy hívnak, hogy pacal. Mi az?” Ha kizárólag receptinformációk alapján képezzük, akkor jó esély van arra, hogy a képzési adatok soha nem írják le explicit módon, hogy mi is az a pacal. Ennek eredményeképpen nagy valószínűséggel egy hallucinált definíciót fogunk kapni arról, hogy mi is az a pacal.
Sajnos ez a helyzet sokkal gyakoribb, mint gondolnánk. Persze, lehet, hogy a vállalatának rengeteg információja van, de az információi valószínűleg rendkívül terület-specifikusak, és nem lennének jól általánosíthatók olyan információkra vonatkozó kérdésekre, melyekkel a GenMI-modell nem találkozott explicit módon. Ráadásul egy nagyon specifikus információkészleten kiképzett GenMI-modellnek nehezebb lesz „logikai készségeket” kifejlesztenie, ami azt jelenti, hogy a logikai érvelés tévesen el fog torzulni egy nagyon specifikus tartományban lévő információk megosztása felé. Ez valószínűleg ellentétes a vállalatunknak a GenMI használatával kapcsolatos céljaival!
Domain-specifikus alapmodellek
Felismerve, hogy a vállalatok értéket fognak találni a doménspecifikusabb GenMI modellek használatában, sok vállalat elkezdte erőfeszítéseit ezeknek a doménspecifikus GenMI modelleknek a létrehozására összpontosítani. A Bloomberget már említettük, mely a pénzügyi szektor számára készített modellt, és az IBM is ugyanezt tette a saját fejlesztésű Granite modellkészletével. Jó esély van rá, hogy ez a jövő útja. Amellett, hogy a szűkebb tartomány üzleti felhasználásra szűkíthető, a szűkebb tartományi modell gyakran kisebb modellt jelent, ami viszont azt is jelenti, hogy valószínűleg olcsóbb a futtatása. Ez nagyszerű hír azoknak az embereknek, akiket érdekel egy doménspecifikusabb modell, mivel ahogyan azt az előző pontokban megjegyeztük, vannak olyan akadályok, mint a képzési költségek és az RLHF-sel kapcsolatos aggályok, melyek miatt egy doménspecifikus GenMI-modell létrehozása a semmiből nem lenne előnytelen opció. Olyan jövőt képzelünk el, ahol ezeknek a domain-specifikus alapmodelleknek a finomhangolása egyre inkább általános gyakorlattá válik, feltéve, hogy le tudjuk csökkenteni a saját hosting költségeit!
Úgy tűnhet számunkra, hogy egyértelmű hierarchia van abban, hogy melyik opciót részesítjük előnyben a legtöbb vállalat számára. Konkrétan úgy tűnik, hogy a legtöbb vállalat először a RAG-ot, majd a finomhangolást szeretné felfedezni, és ha az előbbi lehetőségek valamilyen oknál fogva nem működnek, akkor talán egy új modell létrehozását vizsgálja meg majd a semmiből. Ismételjük, a saját modell nulláról történő létrehozásához szükséges erőforrások olyan megfizethetetlenül drágák (szó szerint és átvitt értelemben is), hogy ezt a lehetőséget a legtöbb vállalat számára nem javasolnánk.
Ha a RAG és a finomhangolás között vacillálnak, akkor azt javasolnánk, hogy kezdjenek el kísérletezni a RAG technikákkal. A RAG-gal való kísérletezés ugyanis általában nagyon egyszerű és költséghatékony. Bár említettük, hogy a RAG felhasználási esetek vektoradatbázist kívánnak használni a vektorbeágyazások tárolására, a kísérletezéshez NEM szükséges vektoradatbázis. Ehelyett akár egy szabványos CSV-t is használhatunk rögtönzött vektoradatbázisként a dolgok kipróbálása során. A fent említett LoRA vagy QLoRA technikák használatát is érdemes megvizsgálni, ha a finomhangolás érdekel inkább minket. Egyszerűen nem tudjuk jó lelkiismerettel ajánlani, hogy bármely vállalat azonnal a „saját modell építése” opcióra ugorjon.
Egy utolsó gondolat: a dolgok minden bizonnyal hamarosan radikálisan megváltozhatnak. Ne feledjük, hogy a csuklónkon lévő okosóra sokkal nagyobb számítási teljesítményt nyújt, mint az 50 évvel ezelőtti legkorszerűbb számítógépek! A technológia fejlődésével ezek közül néhány lehetőség idővel életképesebbé válhat. A változások üteme ezen a téren nagyon gyorsan halad, ezért szeretnénk azt hinni, hogy a finomhangolás kifejezetten a költségek szempontjából idővel sokkal életképesebb opcióvá válik. Reméljük, ez a cikk jó keretet adott ahhoz, hogy hogyan gondolkodjunk a saját vállalati információk kihasználásáról. Izgalmas időszak ez az MI területén dolgozni! Még mindig nagyon a GenMI-forradalom kezdeti napjaiban vagyunk, és izgatottan várjuk, hogyan fognak innen tovább fejlődni a dolgok.
