Egy megoldás sosem kész egyszerre
Sokan úgy képzelik el az AI bevezetést, hogy egyszer beállítják, aztán magára hagyják, és onnantól megy magától. Ez a legdrágább félreértés. Egy AI megoldás nem olyan, mint egy kapcsoló, amit felkapcsolunk és világít. Sokkal inkább egy élő rendszer, amit körbe kell építeni, és minden körben finomítani. A valóság ugyanis nem áll meg. Új ügyfelek, új kérdések, új helyzetek érkeznek, olyanok, amikre az első verzió tervezésekor nem is gondoltunk. Ha a rendszert magára hagyjuk, akkor pontosan ezeknél az új eseteknél kezd el rossz válaszokat adni, és lassan romlik a minősége, miközben látszólag semmi nem változott benne.
Az AI csak annyira jó, amennyire jól van köré építve a rendszer. Ugyanaz a modell, ugyanaz a Claude vagy bármelyik nyelvi modell, teljesen más eredményt ad attól függően, milyen szabályok, szűrők és visszacsatolás veszik körül. A modell nyersanyag. A termék az, amit köré építünk, és ezt a részt kell körről körre fejleszteni. Ez a szemlélet nem gyengeség, hanem a felnőtt hozzáállás egy AI megoldáshoz. Egyetlen komoly szoftvertermék sem készül el egyetlen kiadással, és egy AI megoldás még ennél is inkább él és mozog, mert a bemenete maga a valóság, ami folyamatosan változik.
A demó a könnyű tíz százalék
Van egy visszatérő tapasztalat mindenkinél, aki AI terméket épített. A demó, ami az első héten elkészül és lenyűgözi a döntéshozókat, a munka nagyjából tíz százaléka. A maradék kilencven a folyamat. Az a rész, ami nem látványos. A kivételek kezelése, a rossz válaszok kigyomlálása, a szűrők finomhangolása, a szabályok bővítése, a mérés és a visszacsatolás. Ez a kilencven százalék dönti el, hogy a megoldás valóban használható lesz-e a mindennapokban, vagy csak egy szép bemutató marad, amit néhány hét után senki nem mer éles ügyfélre engedni.
Ezért csalóka a demó. A bemutatón mindig azt látjuk, amit előre elterveztünk, gondosan kiválasztott kérdésekkel, ideális körülmények között. A valóság viszont nem ilyen. Ott a felhasználók nem a mi forgatókönyvünk szerint kérdeznek, hanem ahogy nekik éppen eszükbe jut, és pont az a néhány eset okozza a legtöbb gondot, amire a demó tervezésekor nem gondoltunk. Aki a bemutató sikere után azt hiszi, hogy készen van, az valójában most ér a nehezebbik feladat elejére.
A folyamat a termék. A demó megmutatja, hogy elvileg működhet. Hogy a gyakorlatban is működjön, a maradék kilencven százalékot kell megcsinálni, és azt nem egyszer, hanem körről körre, ahogy a valóság új eseteket dob be.
Egy fiktív példa a gyakorlatból
Vegyünk egy fiktív magyar példát. A Kertajtó Kft. egy közepes méretű webáruház, amely kerti bútort és eszközöket árul. Az ügyfélszolgálat naponta sok emailt kap, ezért építettek egy AI asszisztenst, amely megválaszolja a leggyakoribb kérdéseket, a szállítási időtől a garanciáig. A bemutatón minden gyönyörűen működött. Az asszisztens udvariasan és pontosan válaszolt a tesztkérdésekre, a vezetőség pedig elégedetten bólintott, hogy készen áll a rendszer.
Aztán jött az éles indulás. Az első héten kiderült, hogy az ügyfelek egészen máshogy fogalmaznak, mint a tesztek. Volt, aki egyszerre három kérdést tett fel egy levélben. Volt, aki dühös volt egy szállítási késés miatt, és az asszisztens a sablonos hangnemével csak olajat öntött a tűzre. Volt, aki olyan terméket keresett, ami már kifutott a kínálatból. Egyik eset sem szerepelt a demóban, mégis mind valós volt, és mind rossz választ szült.
A csapat nem kezdett új modellt keresni, és nem cserélte le az AI-t. Ehelyett elkezdte fejleszteni a folyamatot körülötte. Bevezettek egy szabályt, hogy a dühös hangnemű leveleket az asszisztens ne próbálja lezárni, hanem továbbítsa élő ügyintézőhöz. Beépítettek egy szűrőt, amely felismeri, ha a kérdés kifutott termékről szól, és ilyenkor más választ ad. A több kérdést tartalmazó leveleknél új utasítást kapott a rendszer, hogy minden kérdésre külön térjen ki. Egyik változás sem a modellben történt. Mind a modell köré épített rendszerben.
A második héten újabb esetek bukkantak fel. Egy vásárló számlamódosítást kért, amit az asszisztensnek egyáltalán nem lett volna szabad önállóan kezelnie, mert az könyvelési kérdés. Egy másik ügyfél a konkurencia termékéről kérdezett, összehasonlítást várva. Ezekre megint nem volt felkészülve a rendszer, és megint nem a modell hibázott, hanem a köré épített szabálykészletben volt hiányzó eset. A csapat sorra vette a hibás válaszokat, csoportosította őket, és minden csoporthoz hozzátett egy szabályt vagy egy szűrőt. A harmadik hétre az asszisztens észrevehetően megbízhatóbb lett, pedig a modellhez egyetlen ujjal sem nyúltak hozzá. A javulás teljes egészében a folyamat fejlesztéséből jött.
- Éles használatA rendszer valós ügyfelekkel találkozik, és olyan esetek jönnek, amikre a demó nem készült fel.
- Hibák gyűjtéseÖsszegyűjtjük, hol adott rossz vagy félrevezető választ, és megnézzük, mi volt a közös bennük.
- Szabály vagy szűrőAz új esetet egy új szabállyal vagy szűrővel fedjük le, hogy legközelebb már jól kezelje.
- VisszamérésA következő körben ellenőrizzük, hogy a javítás tényleg működik, és nem rontott el mást.
Nem a modellben, hanem körülötte fejlesztünk
Fontos tisztázni, hol történik ez a fejlesztés. Nem a modell belsejében. A modellt nem tanítjuk újra minden héten, nem nyúlunk a súlyaihoz, és a legtöbb esetben nem is finomhangoljuk. A fejlesztés a modell körül zajlik. A szabályokban, amelyek megmondják, mikor mit tegyen. A szűrőkben, amelyek kiszűrik a kockázatos vagy rossz eseteket, mielőtt kimennének az ügyfélhez. És a visszacsatolásban, amely a rossz válaszokból tanulságot von le a következő körre.
Ez a három elem együtt tanuló rendszert alkot, még akkor is, ha maga a modell nem változik. A rossz válasz nem kudarc, hanem nyersanyag. Minden rossz válasz megmutat egy esetet, amire eddig nem volt szabály, és ebből lesz a következő kör javítása. Így épül a rendszer egyre robusztusabbá, nem egyetlen nagy ugrással, hanem sok apró körrel, amelyek mindegyike lefed még néhány esetet, ami korábban átcsúszott a hálón.
A visszacsatolás ennek a rendszernek a motorja. Enélkül nem tudjuk, hol téved a megoldás, és vakon fejlesztünk. A jó folyamat gondoskodik arról, hogy a rossz válaszok ne tűnjenek el nyomtalanul, hanem összegyűljenek egy helyre, ahol átnézhetők. Valaki rendszeresen megnézi őket, mintázatot keres bennük, és eldönti, melyik érdemel új szabályt. Ez a rész gyakran nem is technikai munka, hanem figyelem és ítélőképesség kérdése. A modell nyers ereje adott. A különbséget az teszi, hogy van-e valaki, aki hétről hétre komolyan veszi a visszacsatolást, és beépíti a tanulságot a következő körbe.
Két hozzáállás, két eredmény
A különbség a sikeres és a félbehagyott AI projektek között gyakran nem a modellen múlik, hanem a hozzáálláson. Az egyik oldalon az van, aki egyszer beállít mindent, és azt hiszi, ezzel kész a munka. A másikon az, aki a beállítást kezdésnek tekinti, és onnantól körről körre fejleszti a rendszert a valós esetek alapján. A modell mindkét esetben ugyanaz lehet. Az eredmény mégis egészen más.
Beállít és magára hagy
- A demó után lezárt projekt
- Új eseteknél romlik a minőség
- A rossz válasz kudarc, amit eltűrünk
- Idővel elveszti a bizalmat
Körről körre fejleszt
- A beállítás csak a kezdet
- Új eseteket új szabály fed le
- A rossz válasz nyersanyag a javításhoz
- Idővel egyre megbízhatóbb
Miért ez a termék igazi része
A terméket és a folyamatot nem lehet szétválasztani. A termék nem a modell, és nem is a demó. A termék az a rendszer, amely a valós esetek folyamatos beépítésével egyre jobban végzi a dolgát. Aki azt hiszi, hogy az AI bevezetés egyszeri beállítás, az a munka tíz százalékánál megáll, és ott is marad. Aki érti, hogy a maradék kilencven a folyamat türelmes, körről körre való fejlesztése, az épít valóban működő terméket. A modell adott. Hogy jó lesz-e belőle termék, az azon múlik, mennyire jól és mennyire kitartóan építjük köré a rendszert.
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 →