Generatív mesterséges intelligencia-termék fejlesztése: mit kell először tudni?

Bevezetés

A generatív mesterséges intelligenciát könnyű kipróbálni, de lényegesen nehezebb olyan termékké alakítani, amelyre az emberek támaszkodhatnak. Egy csapat néhány nap alatt összekapcsolhat egy nyelvi modellt egy csevegőfelülettel. Azonban teljesen más kérdés, hogy az adott felület képes legyen kezelni a valódi ügyfélkéréseket, tiszteletben tartani a hozzáférési jogosultságokat, a vállalati adatokkal dolgozni, valamint helyreállni a hibás válaszok után.

Azok számára, akik üzleti alkalmazásokhoz fontolgatják a generatív mesterséges intelligencia bevezetését, az első döntés nem az, hogy melyik modellt használják. Hanem az, hogy a probléma egyáltalán új terméket igényel-e. A kész mesterséges intelligencia-eszközök a legtöbb igényt kielégíthetik, míg egy egyedi megvalósítás akkor ésszerűbb, ha a meglévő szoftver nem képes alkalmazkodni a szükséges munkafolyamathoz. Az utóbbit mérlegelő vállalatok konzultálhatnak a SysGears generatív mesterséges intelligencia mérnökeivel, hogy feltárják az adott felhasználási esetre szabott termék műszaki követelményeit.

Egy generatív mesterséges intelligencia-termék lényegesen többet jelent annál, mint hogy egy modellt helyezünk el egy vállalati márkájú felület mögé. A modell ugyan kezelheti a nyelvet, de az alkalmazás többi része határozza meg, hogy milyen információkra támaszkodhat, képes-e más szoftverekkel együttműködni, és mi történik, ha a válasza nem találja el a célt. Ezek a döntések ugyanolyan mértékben befolyásolják a termék hasznosságát, mint maga a modellválasztás.

Egy belső asszisztens félrevezetheti az alkalmazottakat, ha elavult szabályzati dokumentumot hív elő. Ha hozzáférést biztosítunk neki az ügyféladatokhoz, a hozzáférési jogosultságok ugyanolyan fontossá válnak, mint a válaszok minősége. Ha az alkalmazás az adatokat is módosíthatja, egy meggyőző, de helytelen válasz valódi károkat okozhat.

Ezek nem olyan részletek, amelyeket a bevezetés után lehetne kijavítani. Befolyásolják az architektúrát, a szükséges mérnöki munkát és a mesterséges intelligencia fejlesztési költségeit, beleértve azt is, hogy mi szükséges a termék működésének fenntartásához. Egy vállalkozásnak át kell gondolnia ezeket a kérdéseket, mielőtt elkötelezi magát a fejlesztés mellett, amíg még van lehetőség a hatókör szűkítésére, vagy arra, hogy úgy döntsön, egy meglévő eszköz is megfelelne a feladatra.

Kezdjük egy olyan problémával, amely generatív mesterséges intelligenciát igényel

Egy meggyőző bemutató elterelheti a figyelmet egy meglehetősen hétköznapi üzleti problémáról. Ha például az alkalmazottak túl sok időt töltenek a belső dokumentációk átkutatásával, egy szemantikai keresőrendszer is elegendő lehet. Ha viszont hosszú dokumentumokat kell értelmezniük, konkrét részleteket kiemelniük, és több forrásból származó információk felhasználásával válaszokat kell megfogalmazniuk, egy nyelvi modell jelentősebb hozzáadott értéket jelenthet.

A különbség már a kezdetektől fontos. A generatív mesterséges intelligencia akkor éri meg a befektetést, ha a szoftvernek értelmet kell adnia rendezetlen, strukturálatlan anyagoknak, vagy olyan szöveget kell megfogalmaznia, amely a kontextustól függ. Fix szabályok által irányított feladat esetén azonban egy hagyományos szkript futtatása gyakran olcsóbb és megbízhatóbb.

Vegyünk például egy forgalmazót, aki folyamatos termékérdeklődésekkel foglalkozik. Az ügyfelek ugyanazt a terméket a legkülönbözőbb módon írják le, így egy generatív mesterséges intelligencia-alkalmazás értelmezhetné a kéréseiket, előhívhatná a releváns specifikációkat, és megfogalmazhatna egy választ. A készletszintek már más kérdés. Ezeket az élő készletnyilvántartásokból kell lekérni, míg az árajánlatnak a vállalat árazási szabályait kell követnie, nem pedig azt a számot, amelyet a modell éppen előállít.

Ezt a munkamegosztást érdemes egyértelműen tisztázni: hagyjuk, hogy a modell a nyelvvel foglalkozzon, a kiszámítható műveleteket pedig – amennyire csak lehetséges – hagyjuk a hagyományos szoftverekre.

Mielőtt bármilyen fejlesztésbe kezdenénk, határozzuk meg pontosan, mi is az, amit valójában javítani szeretnénk. Lehet, hogy az értékesítőknek kevesebb időre lesz szükségük az árajánlat összeállításához; lehet, hogy az ügyfelek választ kapnak anélkül, hogy várniuk kellene egy ügyfélszolgálati munkatársra. Akárhogy is legyen, rögzítsük, hogyan működik a folyamat jelenleg. Ellenkező esetben előfordulhat, hogy a csapat végül az új AI-felület bevezetését ünnepli anélkül, hogy tudná, vajon ez valóban megkönnyítette-e a munkát.

Fejlesztés vagy vásárlás: mennyi ellenőrzésre van valójában szükség?

A „fejlesztés vagy vásárlás” döntést gyakran a teljes tulajdonjog és a kényelem közötti választásként állítják be. A gyakorlatban azonban számos köztes lehetőség is létezik.

A kész AI-eszközök ésszerű kiindulási pontot jelentenek, ha egy vállalkozásnak olyan ismerős funkciókra van szüksége, mint az írási segítség, az értekezletek összefoglalása, a dokumentumelemzés vagy az általános célú kutatás. Ezek a termékek általában kevesebb mérnöki munkát igényelnek, és a gyártók gondoskodnak az alapul szolgáló infrastruktúra nagy részéről. A vállalat kipróbálhatja, hogy az alkalmazottak hasznosnak találják-e egy adott funkciót anélkül, hogy előbb egy dedikált fejlesztési projektet kellene finanszíroznia.

A baj akkor kezdődik, amikor egy általános célú eszköznek olyan folyamatba kell illeszkednie, amelyre nem tervezték. Előfordulhat például, hogy nem tud kommunikálni egy régebbi adatbázissal, vagy nem alkalmazza a megfelelő hozzáférési jogosultságokat, ha az alkalmazottak különböző szerepkörökben dolgoznak. Előfordulhat továbbá, hogy a kimeneti adatokat át kell alakítani, mielőtt egy másik üzleti rendszer felhasználhatná azokat. Az API-k és a konfigurációs lehetőségek segíthetnek áthidalni ezeket a hiányosságokat, de nem feltétlenül fedik le egy már kialakult munkafolyamat sajátosságait.

Egy egyedi AI-termék akkor válik indokoltabbá, ha maga a munkafolyamat jelent versenyelőnyt, ha a meglévő termékek nem tudnak megfelelni egy lényeges követelménynek, vagy ha az alkalmazásnak szoros integrációra van szüksége a saját fejlesztésű adatokkal és a belső rendszerekkel.

Egy harmadik lehetőség az, hogy saját alkalmazást építsünk egy külső szolgáltató által üzemeltetett modell köré. A vállalat kifejleszti a felületet és az azt alátámasztó logikát, összekapcsolja a rendszert a meglévő szoftverével, és saját módszert alakít ki az eredmények tesztelésére. Maga a modell API-n keresztül érhető el, így nincs szükség egy alapmodell nulláról történő betanítására. Ez lehetőséget ad a vállalkozásnak arra, hogy a terméket a saját munkafolyamatához igazítsa, bár ez továbbra is függ a szolgáltató árazásától, a modell elérhetőségétől és a szolgáltatási korlátoktól.

Ez utóbbi különbségre érdemes odafigyelni. Egy egyedi AI-alkalmazás fejlesztése és egy új AI-modell kidolgozása két különböző feladat. Egy alapmodell betanítása jelentős számítási erőforrásokat, speciális szakértelmet, megfelelő adatokat és folyamatos kísérletezést igényel. A legtöbb vállalkozásnak nincs szüksége arra, hogy ezt a terhet vállalja. Elég lehet egy meglévő modell, kiegészítve a vállalati dokumentumokból történő adatlekéréssel vagy gondosan megtervezett eszközhozáféréssel.

Válasszuk ki a munkafolyamathoz igazodó architektúrát

Miután az üzleti indoklás egyértelművé vált, a következő kihívás annak eldöntése, hogy az alkalmazás hogyan fog működni. A modell csupán egy komponens, és nem feltétlenül az, amelyik a legtöbb fejlesztői időt igényli.

Egy dokumentum-asszisztens esetében gyakran érdemes megfontolni a visszakereséssel kiegészített generálást (RAG). Ahelyett, hogy kizárólag arra támaszkodna, amit a modell a képzés során megtanult, az alkalmazás releváns szövegrészeket keres ki egy jóváhagyott információforrásból, és beépíti azokat a promptba. A modell ezután ezeket az anyagokat felhasználva fogalmazza meg a választ.

A belső irányelveken vagy az aktuális termékinformációkon alapuló válaszok relevánsabbak lehetnek, feltéve, hogy a visszakeresés megfelelően működik. Ez azonban nem biztos. Előfordulhat, hogy a keresés egy elavult dokumentumot hoz elő, kihagy egy fontos figyelmeztetést, vagy olyan szövegrészt ad át a modellnek, amelyet az aztán helytelenül értelmez.

Az adatlekérdezést önmagában is tesztelni kell. Az, hogy a dokumentumokat hogyan osztják fel szakaszokra, befolyásolhatja a rendszer találatait, és még egy jó keresési eredmény is haszontalan, ha olyan forrásból származik, amelyet a felhasználó nem láthat. Az alkalmazott hozzáférési jogait át kell vinni az adatlekérdezési folyamatra is, ahelyett, hogy azokat felülírnák, mert a keresés véletlenül korlátozott hozzáférésű anyagot hozott felszínre. Magának az alkalmazásnak kell érvényesítenie a jogosultságokat. Nem szabad rábízni a modellre, hogy ezt a döntést meghozza.

A finomhangolás más célt szolgál. Segíthet a modell viselkedésének, válaszformátumának vagy az ismétlődő feladatminták kezelésének adaptálásában, ha megfelelő edzéspéldák állnak rendelkezésre. Nem helyettesíti egyértelműen a visszakeresést, ha a fő probléma a változó tényekhez való hozzáférés. A tavalyi termékkatalógusra finomhangolt modell nem fogja automatikusan tudni, mi változott ma reggel.

Egy szűk hatókörű alkalmazásnak elegendő lehet egy prompt és egy modell-API, legalábbis kezdetben. Ez attól függ, mennyire kiszámíthatóak a bemenetek, és mit várnak el a rendszertől a kimenettel kapcsolatban. Ha minden választ össze kell vetni egy nagy mennyiségű belső dokumentációval, akkor szükségessé válhat az adatlekérés; egyszerűbb feladat esetén ez csak felesleges terhet jelenthet.

Az első verziót tartsuk egyszerűnek, és próbáljuk ki valódi kérésekkel, ne csak kifinomult bemutató-bemenetekkel. Nézzük meg, hogyan kezeli a homályos kérdéseket vagy a hiányzó információkat. Ha inkább blöfföl, mintsem beismerje a hiányosságot, azt meg kell oldani, mielőtt további mozgó alkatrészeket adnánk hozzá.