Miért buknak el az AI- és data science projektek? 7 ok és a megelőzés

Mennyire gyakori a kudarc?

A RAND Corporation 2024-es kutatása szerint az AI-projektek több mint 80 százaléka elbukik, ami az AI-t nem használó IT-projektek bukási arányának a kétszerese. A szám önmagában is beszédes, de az igazán érdekes az, amit a kutatás a kudarc okairól ír.

A RAND öt gyökérokot nevez meg: a vezetés félreérti, milyen problémát kell megoldani, vagy rossz mutatóra optimalizál; nincs elég jó minőségű adat a tanításhoz; a szervezet a legújabb technológiát helyezi a valódi üzleti probléma elé; alulfinanszírozott az adatkezelési és üzemeltetési infrastruktúra; és van, hogy a feladat egyszerűen túlmutat azon, amire a technológia ma képes.

Öt okból négy nem technikai. Ez megegyezik azzal, amit mi is látunk a saját projektjeinkben, és amit ez a cikk 2019-ben is állított: a probléma szinte soha nem az eszközválasztás.

A hét ok egy táblázatban

1. Senki nem tudja, mit jelent az adat

Ez a leggyakoribb és a legkevésbé látványos akadály. Multinacionális cégeknél is előfordul, hogy nem tudnak válaszolni arra, hány ügyfelük van, mert a különböző divíziók mást értenek "ügyfél" alatt. Ugyanez igaz szinte minden mezőre: mért érték vagy számított? Ki állította elő, és milyen szabály szerint?

Amíg ez nem tisztázott, a projekt nem tud haladni, mert minden eredményt megkérdőjelez valaki azzal, hogy "nem így értjük". A megoldás nem technológiai: adatgazdákat kell találni, és le kell írni, mit jelent az adat. Ez az adatvagyon-felmérés első lépése is.

2. Senkinek nem érdeke, hogy válasz szülessen

Nagy szervezetekben az adat hatalom. Az osztályok nem szívesen adják ki az adataikat, mert félnek a számonkéréstől, vagy mert a birtoklást előnynek érzik. Ilyenkor a data scientist könnyen közös ellenséggé válik: az ő munkája teszi láthatóvá azt, amit eddig nem kellett megmutatni.

Ez ellen egyetlen dolog véd igazán: ha a projekt célja az adatgazdának is jó. Ha az elemzés eredménye rá nézve csak kockázat, nem lesz együttműködés, akármilyen vezetői utasítás van.

3. Nincs bizalom az eredményben

Az emberek jobban ragaszkodnak az intuíciójukhoz, mint gondolnánk, és amikor az adat ellentmond a megérzésnek, jellemzően az adatot hibáztatják. "Biztos elromlott az analytics." "Mérési hiba lehet."

Ennek van egy kevésbé ismert oka is: azt, hogy megbánunk-e egy döntést, nem elsősorban a helyessége határozza meg, hanem az, ahogyan meghoztuk. Egy megérzés alapján hozott rossz döntést könnyebb elviselni, mint egy adat alapján hozottat. Erről bővebben az adatvezérelt döntéshozatal posztunkban írtunk.

A védekezés itt az, hogy a sikerkritériumot még az eredmény ismerete előtt rögzítjük, és hogy a módszer átlátható legyen.

4. Nem születik döntés az adatok alapján

Van adat, megbízható is, az elemzés kész, és mégsem történik semmi. Az okok általában hétköznapiak: nincs rá forrás, jogi akadály van, nincs ember, aki végrehajtsa, vagy egy belső szabály tiltja.

Ez a legdemoralizálóbb változat, mert a csapat joggal kérdezi, minek mérünk, ha úgysem csinálunk vele semmit. Megelőzni úgy lehet, hogy már a projekt elején megnevezzük, ki fog dönteni az eredmény alapján, és milyen beavatkozás követi. Ha erre nincs válasz, a projekt nem kész az indulásra.

5. Rossz az üzleti kérdés

Az ideális adatprojekt egy konkrét üzleti problémából indul. A gyakorlatban viszont gyakran fordítva megy: előbb gyűlik az adat, aztán keresünk rá felhasználást. Ez nem mindig baj, de sokkal nehezebb út.

A különbség az, hogy az üzleti kérdésből induló projektnél tudjuk, mit fogunk máshogy csinálni, ha megvan a válasz. Ezért kezdődik a CRISP-DM módszertan is az üzleti cél megértésével, nem az adatéval.

6. Túl nagy elvárásokkal indultunk

Az "adat az új olaj" gondolat túlzott optimizmust szül. Gyakran hangzik el, hogy "húsz százalék veszteség biztosan kivehető" vagy "van az adatokban húsz százalék profit". Aztán kiderül, hogy az adat rosszul van tárolva, nincs benne a keresett összefüggés, vagy közbejön az előző öt probléma valamelyike.

Ez nem azt jelenti, hogy nincs benne érték. Azt jelenti, hogy az értéket meg kell becsülni, mielőtt elköteleződünk mellette.

7. Hiányoznak a kompetenciák

Az ideális data scientist, aki egyszerre ért mélyen a szakterülethez, az üzlethez, a változáskezeléshez és a technológiához, nem létezik. Aki ilyet keres, sokáig fog keresni.

Ez csapattal oldható meg, nem hőssel. És érdemes őszintén megnézni, melyik rész hiányzik belőlünk: ha a domain tudás megvan, de az elemzés nem, az más helyzet, mint fordítva.

Plusz egy sikerkritérium: a visszajelzési idő

Van egy ökölszabály arról, mitől jó egy adatbányászati projekt. Hat kritériumot szokás felsorolni:

1. Sok sorból álló adathalmaz.
2. Attribútumokban gazdag adatbázis.
3. Tiszta adatok.
4. Az adat jól reprezentálja az előrejelzendő eseményt.
5. Jól mérhető megtérülés szervezeti szinten.
6. Akcióképes tématerület, ahol a menedzsment tud változtatni a folyamaton.

Van viszont egy hetedik, amiről ritkán esik szó, pedig sokszor ez dönt: milyen gyorsan kapunk visszajelzést arról, hogy jó döntést hoztunk-e.

Egy mobilszolgáltató lemorzsolódási projektje azért tankönyvi példa, mert mind a hét teljesül: nagy ügyfélbázis, gazdag adat (hívásszokások, számlázás, készüléktípus), viszonylag tiszta adatok, mérhető kampányhatékonyság, és több csatorna a beavatkozásra.

Amiért ez a modellválasztást is eldönti

Itt van a gondolat üzleti éle. Egy webáruház ajánlórendszerénél órák vagy napok alatt látszik, hogy működik-e. Ilyenkor a fekete doboz is vállalható, mert ha rossz, gyorsan kiderül és lehet korrigálni.

Egy banknál vagy biztosítónál viszont évek múlva derül ki, hogy jó volt-e a döntés. Ott nem lehet megvárni a visszajelzést, tehát csak olyan modell vállalható, amit előre meg lehet érteni és meg lehet védeni. Ez az egyik legerősebb üzleti érv a magyarázható mesterséges intelligencia mellett: nem elvi kérdés, hanem a visszajelzési idő következménye.

Érdemes tehát a projekt elején feltenni a kérdést: mennyi idő múlva tudom meg, hogy igazam volt?

Mi változott a generatív AI-jal?

A hét ok közül egy sem tűnt el, de kettő új formát kapott.

A rossz kérdés könnyebben elrejthető. Egy nyelvi modellre épülő prototípus néhány nap alatt látványos. Ettől úgy tűnhet, hogy a projekt halad, miközben azt a kérdést, hogy ez mit változtat a működésben, még senki nem tette fel. A RAND ezt bottom-up kudarcnak nevezi: a technológia megelőzi a problémát.

Az elvárás magasabbról indul. Egy demó minősége és egy éles rendszer megbízhatósága között nagyobb a szakadék, mint a klasszikus modelleknél, mert a demót emberi szemmel nézzük, az éles rendszert pedig ezer eset alapján ítéljük meg. Ezért kell saját tesztkészlet és kiértékelési szempontrendszer, mielőtt bárki dátumot ígér.

Így csökkenthető a kockázat

Három lépés a projekt elején többet ér, mint bármilyen technológiai döntés később.

1. Use-case kidolgozás. Az üzleti kérdés megfogalmazása, a sikerkritérium számszerűsítése és annak tisztázása, ki fog dönteni az eredmény alapján. Ez véd az 1., a 4. és az 5. ok ellen.
2. Megtérülés-számítás és szimuláció. A döntés előtt látható a várható hatás, a teljes költség, a megvalósíthatóság és a megtérülés. Ez véd a 6. ok ellen, és alapot ad a 3. ellen is. Erre való a megtérülés-számítás és megoldásszimuláció.
3. Pilot projekt. Kis léptékű, valódi adaton futó megvalósítás, ami megmutatja, hol akad el a dolog, még azelőtt, hogy nagy összeg állna mögötte.

Ellenőrzőlista indulás előtt

Nyolc kérdés. Ha háromnál többre nincs válasz, a projekt még nem áll készen.

1. Le van írva, mit jelent a projekthez szükséges néhány legfontosabb adat, és ki felel érte?
2. Van vezetői mandátum az adatok megszerzésére?
3. Az adatgazdának is jó, ha a projekt sikerül?
4. Rögzítettük számszerűen, mit tekintünk sikernek?
5. Megneveztük, ki fog dönteni az eredmény alapján?
6. Van forrás és jogi lehetőség a beavatkozásra?
7. Megbecsültük a várható megtérülést, nem csak reméljük?
8. Tudjuk, mennyi idő múlva derül ki, hogy jó döntést hoztunk?

Gyakori kérdések

Az AI-projektek hány százaléka bukik el? A RAND Corporation 2024-es kutatása szerint több mint 80 százaléka, ami az AI-t nem használó IT-projektek bukási arányának a kétszerese. A kutatás öt gyökérokot nevez meg, és ebből négy nem technikai jellegű.

Mi a leggyakoribb ok? A tapasztalatunk szerint az, hogy nincs közös adatdefiníció, és az, hogy nem születik döntés az eredmény alapján. Mindkettő szervezeti, nem technológiai kérdés, és mindkettő a projekt elején kezelhető a legolcsóbban.

Mitől lesz jó egy adatprojekt? Hét feltételtől: elég sok és elég gazdag adattól, tiszta adatoktól, attól hogy az adat valóban az előrejelzendő eseményt írja le, mérhető megtérüléstől, olyan területtől ahol lehet beavatkozni, és a gyors visszajelzési időtől.

Miért számít a visszajelzési idő? Mert ez dönti el, mennyi kockázatot vállalhatunk a modellel. Ahol órák alatt kiderül az eredmény, ott a fekete doboz is vállalható. Ahol évek múlva, ott csak olyan modell, amit előre meg lehet érteni.

Elkerülhetők ezek a buktatók? Teljesen nem, de a többségük a projekt első néhány hetében kiszűrhető. Ezért javasoljuk, hogy a use-case kidolgozása és a megtérülés-számítás előzze meg a fejlesztési döntést.

Kisebb cégnél is igaz ez? Az 1., 2. és 7. ok ott jellemzően kisebb, mert kevesebb a szereplő. A 4. és az 5. viszont ugyanúgy jelen van, sőt kisebb szervezetben egy félrement projekt aránylag nagyobb veszteség.

Források

• James Ryseff, Brandon F. De Bruhl, Sydne J. Newberry: The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed. RAND Corporation, 2024.