Egy egyszerű AI alkalmazás felépítése

Egy kérés útja

Egy egyszerű AI alkalmazás mindig ugyanazt a néhány lépést járja be. Először fogadja a felhasználó bemenetét, például egy beírt kérdést vagy egy feltöltött szöveget. Ezután a szerveroldalon összeáll a prompt. A fejlesztő itt köti össze az állandó rendszerüzenetet a felhasználó aktuális kérésével, és ha kell, hozzáadja a szükséges háttéradatot. A kész prompt megy az API-n át a modellhez. A modell visszaküldi a választ, amit a szerver esetleg ellenőriz vagy megtisztít, majd megjelenít a felhasználónak. Ennyi a mag. Minden összetettebb AI termék ennek a hurokból ismétlődő változata.

Az igazán fontos döntés nem technikai, hanem terjedelmi. Mi az a legszűkebb feladat, amit az alkalmazás jól megold. Ha ezt élesen meghúzzuk, a modell megbízhatóbb lesz, a prompt egyszerűbb, a hibák pedig könnyebben megtalálhatók. Egy asszisztens, amelyik mindent tud, jellemzően semmit nem csinál igazán jól. Egy asszisztens, amelyik egy dolgot old meg pontosan, sokkal használhatóbb.

A modellhívás emellett csak az egyik szereplő ebben a láncban. A legtöbb valódi munkát körülötte a hagyományos, kiszámítható kód végzi. Az fogadja a bemenetet, az illeszti be a megfelelő adatokat a promptba, az ellenőrzi és tárolja a választ, és az kezeli a hibákat. A modell egyetlen, jól körülírt feladatra van a láncban, ott, ahol a nyelvi ügyessége igazán számít. Ez a felosztás azért fontos, mert a rendszer megbízhatósága nagyrészt attól függ, mennyi múlik a kiszámítható kódon és mennyi a modell bizonytalanabb kimenetén. Minél tisztábban választjuk szét a kettőt, annál könnyebb megérteni, hol keletkezik egy hiba, és annál stabilabb lesz a végeredmény.

Szűken kezdeni, tudatosan bővíteni

Kísértő a vágy, hogy az első verzió mindent tudjon. A tapasztalat viszont azt mutatja, hogy a jó AI termékek fordítva épülnek. Előbb egyetlen feladatot oldanak meg jól, például egy adott típusú email megfogalmazását, vagy egy dokumentum egyfajta összefoglalását. Amikor ez már stabil, akkor jön a következő képesség. Ez a lépcsőzetes építkezés azért működik jobban, mert minden bővítésnél tudjuk, mi az, ami eddig biztosan jó volt, így könnyű észrevenni, ha valami elromlik.

A szűk kezdés a költségek szempontjából is előnyös. Egy jól körülírt feladathoz rövidebb prompt és kevesebb próbálkozás elég, ami kevesebb elhasznált tokent jelent. Emellett a felhasználónak is világosabb, mit vár tőle az alkalmazás. Egy éles, pontos ígéret mindig meggyőzőbb, mint egy homályos, mindent tudó rendszer, amelyről kiderül, hogy a részletekben elakad.

A bővítés ilyenkor nem a semmiből indul, hanem egy szilárd alapról. Ha a mag már megbízhatóan teszi a dolgát, egy új képesség hozzáadása kisebb kockázat, mert pontosan tudjuk, mi volt eddig jó, és mihez képest mérjük az újat. Ez a lépcsőzetesség egyben a tanulás módja is. Minden bővítésnél jobban megértjük, mire képes a modell a mi konkrét feladatunkban, és hol vannak a határai. Aki fordítva jár el, és rögtön egy sokfunkciós rendszert épít, az elveszíti ezt a visszajelzést, mert nem tudja, melyik rész felelős azért, hogy a végeredmény ingatag.

Amit már az elején be kell tervezni

Egy dolgozó alkalmazás nemcsak a sikeres esetet kezeli, hanem a hibásat is. Mi történik, ha a modell nem válaszol időben, ha üres vagy értelmetlen szöveget ad vissza, vagy ha a felhasználó olyat kér, amit nem szabad teljesíteni. Ezeket az eseteket nem elég reménykedve figyelmen kívül hagyni. Az igazán használható termék előre eldönti, mit mutat ilyenkor a felhasználónak, és biztosít egy nyugodt visszaesési utat, például egy udvarias üzenetet vagy egy ismételt próbálkozást.

Érdemes már az első verziónál naplózni is, hogy mi ment a modellhez és mi jött vissza. Enélkül szinte lehetetlen megérteni, miért viselkedik néha furcsán a rendszer. A naplózásnál viszont ügyelni kell arra, hogy érzékeny felhasználói adat ne kerüljön oda, ahol nem lenne szabad tárolni. Ez a fajta gondosság különbözteti meg a bemutatóra jó ötletet a valóban használható terméktől.

Miben más egy AI app tesztelése

A hagyományos szoftvernél többnyire egyértelmű, mi a helyes eredmény. Egy összeadás vagy egy bejelentkezés vagy sikerül, vagy nem. Egy nyelvi modellnél ez ritkán ilyen éles. Ugyanarra a kérésre sok különböző válasz lehet egyszerre jó, és a modell nem is mindig ad szó szerint ugyanazt. Ezért a jó és a rossz kimenet határa elmosódottabb, és nem elég egyetlen elvárt választ ellenőrizni. Inkább azt vizsgáljuk, hogy a válasz megfelel-e néhány feltételnek. Odaillő-e, tartja-e a kért formát, elkerüli-e, amit tilos.

A gyakorlatban érdemes összegyűjteni néhány valós, jellemző esetet, és ezeken rendszeresen kipróbálni az alkalmazást, valahányszor a promptot vagy a modellt megváltoztatjuk. Így kiderül, ha egy módosítás egy korábban jól kezelt esetet elrontott. Külön figyelmet érdemelnek a szélső helyzetek, például a nagyon rövid vagy nagyon hosszú bemenet, az üres mező, a félreérthető kérdés vagy a szándékosan kellemetlen kérés. Egy AI alkalmazás minőségét gyakran nem az átlagos, hanem éppen ezek a nehéz esetek döntik el. Aki ezeket eleve végigpróbálja, az sokkal kevesebb kellemetlen meglepetést él meg éles használatban.