85% van AI-projecten faalt

85% van de AI-projecten die faalt. Wat zijn nou eigenlijk de faalfactoren? Wat kun je eraan doen?

En hoe zorg je dat jouw project juist bij de succesvolle 50% zit? Je hoort het in deze aflevering.

Iedere twee weken duiken we dieper in het nieuws rondom AI. En hoe je AI inzet in je organisatie.

Ik ben Mark Wolffenbuttel, chapterlead AI zorg bij Info Support.

En ik ben Joop Snijder, head of research center artificial intelligence, ook bij Info Support.

Hey Mark, vandaag een nieuwe aflevering. De vorige keer zeiden we dat we zouden gaan

kijken naar wat is de juiste mix van een AI-project of een AI-team. Maar misschien

kunnen we iets verder uitzoomen. Om te kijken van, want we zien dat 85% van de AI-projecten

faalt. Dat is ook uit onderzoek gebleken. Gartner heeft dat bijvoorbeeld uitgezocht.

Misschien is het aardig om te kijken van, wat maakt het nou, behalve een team, nog meer waarom

eventueel AI-projecten falen. En hoe kan je er nou voor zorgen dat jouw project daar niet bij hoort.

Dus dat hij wel een succes krijgt. Lijkt je dat wat? Ja lijkt me een goed idee Joop, want van het 15%

succes is te laag. Dat moet omhoog. Welke onderwerpen horen daar nou aan bod te komen?

Nou in ieder geval weet je, er zijn ik denk vijf onderwerpen die we kunnen behandelen. De eerste

is, je gaat kijken of een project technisch haalbaar is. Je gaat kijken of de scope wel

goed is afgebakend. Meestal zien we ook dat er onduidelijke succescriteria aan het falen

te grondslag liggen. We kunnen iets vertellen, volgens mij heb je ook een mooi voorbeeld over

de horde nemen van experiment naar productie. Ja zeker. En wat ik dan al zei, die juiste

teamsamenstelling. Volgens mij kunnen wij daar ook wel wat over vertellen. Nou goed idee,

technisch niet haalbaar. Wij zijn natuurlijk een technische club. Proberen we daar ook zoveel

mogelijk tips en tricks te geven. Maar wat is daar dan, waar waar je het vaak fout ziet gaan Joop?

Nou je moet je in ieder geval bedenken dat het onderwerp van AI machine learning zit echt nog

wel in de researchhoek. Er vindt veel research in plaats. Dat betekent dat er een grote ontwikkeling

plaatsvindt op dit vakgebied. Bijvoorbeeld iets wat twee jaar geleden nog niet kon,

waarbij de techniek gewoon nog niet zo ver was, komt nu wel. Maar dat betekent ook dat als je

nu zou starten met een project, dat je goed moet nadenken, kan het met de huidige stand van de

techniek. Dus wat je typisch doet is dat je na gaat kijken van zijn daar research papers, is er

wetenschappelijk onderzoek gedaan naar dit gebied. Zitten er misschien zelfs code bij de research

papers. Is de techniek die je wil gaan gebruiken misschien zelfs al in een cloud dienst verwerkt.

Levert bijvoorbeeld Microsoft of Amazon of Google, leveren die dat bijvoorbeeld al in

een cloud diensten. Dat helpt enorm. Zelf doen we ook heel veel wetenschappelijk onderzoek in

ons research center bijvoorbeeld. Dat maakt dat je een gevoel krijgt van of iets technisch haalbaar

is of niet. Maar dat blijft toch een beetje lastig. Dus onze tip daar is ook vooral maak het klein.

Maak het heel behapbaar en zoek dat ook eerst even uit. Kijk als je het aan ons vraagt dan,

nou ja we hebben wel een gevoel. Als je dit nog nooit gedaan hebt, moet je echt wel aan de research

kant gaan zoeken hoe de stand van de techniek op dit moment is. En waarom is het nou zo belangrijk

dat je daar eerst mee begint? Nou vooral dus die technische haalbaarheid. Het is dat we kunnen

al heel veel bedenken zelf en we soms overschatten we de stand van de huidige techniek. Dat alles al

kan en alles mogelijk is. Maar dat is gewoon niet zo. Dat schijt voort. Je moet je voorstellen,

laten we zeggen een jaar of twee drie geleden als je daar met met spraak iets wilde doen,

en zeker in een andere taal dan Engels, was dat ontzettend moeilijk. Zat het echt op het

randje van wel haalbaar niet haalbaar. Nou daar zijn zoveel ontwikkelingen in geweest dat je dat

vandaag de dag al heel veel beter kan doen. En dat zou in het Nederlands, als je met spraak aan de

gang gaat, nou daar heb je een grotere kans dat dat goed gaat dan twee jaar geleden. Als we zo

direct twee drie jaar verder zijn, dan zeggen we waarschijnlijk alles is eitje. Ja ik denk ook dat

het voor een bedrijf belangrijk is dat het de eerste stap dat stukje research zich eigen te

maken. Want het blijft natuurlijk niet maar bij één experiment. Ja precies. Ja je gaf in de intro

natuurlijk ook aan, dat je zegt van nou maak het, je zei net alweer maak het klein, maar je gaf in

de intro ook aan van de scope is soms wat matig afgebakend. Nou ja die scope dat is iets wat we

veel zien. Want onze geest kan natuurlijk van alles en nog wat bedenken. Wij maken het zo groot

als dat het nodig is. Oh van als dit kan, dan kan dit ook en misschien dat ook wel. Maar juist de

kunst om dat toe te passen op je bedrijfsdoelstellingen en het dan ook nog eens klein

te maken, dat is natuurlijk wel een hele kunst. Want hoe doen wij dat? Nou wat wij in ieder geval,

we hebben een soort van vuistregel. Is van we maken de scope zo klein en de hypothese die we

willen gaan bewijzen maken we zo klein dat je die binnen vijf dagen moet hebben kunnen bewijzen. Of

in ieder geval ja bewezen qua levensvatbaarheid. En daar hebben we een canvas voor ontwikkeld,

het AI experiment canvas. Die het dwingt om na te denken aan doelstellingen te koppelen en het

zo klein te maken dat je het en technisch haalbaar krijgt en dat je echt een heel duidelijke scope

krijgt. Van ja als iets maar in vijf dagen, als je daar maar vijf dagen voor hebt om het te valideren,

moet je het ook heel klein maken. Want je gaat met een heel klein team vijf dagen aan de slag

en daarna moet je kunnen zeggen ja het is levensvatbaar of niet. Levensvatbaar houdt zoiets

in als we vinden het goed genoeg, het voldoet aan de juiste criteria om te kunnen zeggen van

we durven hier meer geld en tijd in te stoppen. Ja want dat is het natuurlijk. Het is niet alleen

scope afbaken, het ook uiteindelijk je budget beschikbaar stellen voor het juiste experiment.

Want je kan er geen twintig tegelijk doen, dat dat zou heel erg duur worden. Maar die ene juiste

wel alleen van twintig naar één komen, daar helpt natuurlijk ook wel een stukje focus voor. Want

anders krijg je de eigen fantasie die een beetje op hol slaat. Juist weer toe te passen op de

bedrijfdoelstellingen. Ga ik mijn proces efficiënter maken? Wil ik mijn concurrentiepositie verbeteren?

Wil ik mijn klanten beter van dienst zijn? Wil ik groeien? Dat zijn allemaal aspecten die kan

je naast mekaar zetten. Je vult ze in middels een ideation workshop of iets in die richting.

Gebruik het canvas en daarmee kan je eigenlijk de kant en klaren experimenten, experiment ready

eigenlijk, naast elkaar zetten om te kijken wat is het dan op dat moment nog steeds haalbaar voor

ons in vijf dagen. Nou dan zie je natuurlijk veel dat, nou je begint heel groot, het wordt steeds

kleiner en daar helpt zo'n canvas ook bij om dat ook te doen en ook presenteerbaar te maken. Maar

dan ben je er nog natuurlijk niet. Want je hebt je canvas en dan heb je een scope en die heb je

afgebakend. Wanneer is het een succes dan? Wat we zien als we dit soort experimenten aangaan,

is dat we het hier echt wel heel diep moeten ingaan en zeker onze klanten keuzes moeten

laten maken. Dat is de succes criteria. Wat je gaat doen is zeggen van waar moet het experiment

echt een bijdrage aan leveren. Jij noemde het net al, dus dat kan zijn omzetverhoging,

kostenverlaging, hogere klanttevredenheid, er kan van alles en nog wat zijn. En dat zo specifiek

maken en keuzes maken, dat je zegt ja maar we willen daarvan één, willen we er echt beïnvloeden

met het experiment. Dus we willen aan het eind van die vijf dagen zien dat we daar verandering

in teweeg kunnen brengen. De moeilijkheid zit vaak in, dat wordt gezegd van ja maar we willen en de

kosten verlagen en de omzet verhogen en het liefst nog de klanttevredenheid erbij verhogen.

Ja met tientallen procenten. Ja en soms kan dat in zekere zin, van als je bijvoorbeeld de kosten

verlaagt of daarmee bijvoorbeeld de winst verhoogt en zo. Maar dan zeggen we nee we gaan optimaliseren

op één van die doelstellingen, want daar ga je mee aan de slag. Dat zou wel heel gaaf zijn als je

binnen vijf dagen dat daadwerkelijk kan aantonen. En alles wat daar omheen zit en ook mee beweegt,

dat is bijvangst. Ja en waar weeg je het tegen af? Want als je het hebt over handmatige processen,

mensenwerk en je wil bijvoorbeeld minder foutreductie laten zien, dan zeg je nou we moeten

naar nul fouten, want nu gaan we het automatiseren. Dat komt vaak omdat we ervan uitgaan dat de mens

nagenoeg geen fouten maakt of dat in ieder geval tot in staat is om te herstellen. En daarom gaan

we altijd uit van die grens van 100 procent, van dat moet 100 procent goed zijn. Maar ook het

mensenwerk, en dat weten we stiekem natuurlijk wel, is nooit 100 procent goed. Maar we gaan,

als we het echt zouden gaan meten, gaan we niet zeggen nee maar we doen het nu voor 70 procent

goed. Dus daarom is het criteria vaak 100 procent moet goed zijn. Terwijl als je weet van oké we

maken ook wel wat fouten, we kunnen daar in efficiënter te werk gaan, we kunnen daar sneller

reageren, is dat bijvangst? Want je kan daarna zien van oké we gaan van 80 procent goed beantwoorden,

bijvoorbeeld e-mails, naar 85 procent. Alleen daar besparen we zoveel manuren mee in de week,

dat we die weer kunnen gebruiken om onze klantvredenheid omhoog te brengen. En dat maakt

het vaak moeilijk. En daar moet echt bij geholpen worden om daar succescriteria op te stellen. Want

als 100 procent in het achterhoofd blijft zitten, dan ga je niet heel snel komen tot daadwerkelijk

een succesvol experiment. Terwijl het al misschien met een paar procentjes echt wel succesvol kan

zijn. En dat zie je bijvoorbeeld terug in de zorg. Op het moment dat je zegt van nou wij zien nu dat

85 procent van de mensen met behandeling kunnen worden genezen en we maken daar een paar procent

meer van, dan zijn dat een heleboel daadwerkelijke echte mensenlevens. En dan is een 1 procent al

voldoende. [Muziek]

Nou we hebben nu drie eigenlijk van de vijf criteria gezien waarop AI-projecten falen.

Dat is technisch niet haalbaar, scoopslecht afgebakend, onduidelijke succescriteria. We

hadden ook de horde na productie die niet wordt genomen. Hoe zien we dat, Mark?

Ja ik zou de horde na productie willen benoemen en aanvullen met op het moment dat je al in

productie bent, wat dan? Dat zijn de twee die we het meeste zien. Wat je veel ziet is dat op het

moment dat je eigenlijk je lijstje klaar hebt met wat moet er gebeuren, nadat je hebt besloten met

z'n allen van een experiment is geslaagd, is succesvol. We gaan dat in productie proberen

te brengen. We gaan dat binnen de organisatie optuigen. Nou dan dan krijg je eigenlijk een

vaak ook wel technisch lijstje met van wat je nodig hebt om dat te realiseren. Nou wat je daarin

ziet is dat je hebt je data nodig, je hebt je omgeving nodig, dus je hebt ook daadwerkelijk

de locatie nodig waar het model gaat draaien. Je hebt allerlei aspecten nodig en kennis nodig

rondom softwareontwikkeling, want je hebt toch iets wat naar productie gaat. Je moet iets vaker

kunnen uitrollen, je hebt verschillende versies en dat is best wel moeilijk voor veel bedrijven.

Daarin zie je dus dat het komen tot uiteindelijk in productie een lastige horde is omdat je al

die andere stappen eerst moet doen. Eigenlijk zou je kunnen zeggen dat het maken van het model,

daar wordt heel veel aandacht en tijd aan besteed, maar dat is een relatief klein stuk ten opzichte

van als je uiteindelijk er een volledig werkend product van wil maken. Ja het gros van het werk

zit daaromheen natuurlijk. Hoe breng je data bronnen bij elkaar, hoe zet je je model in

productie ter acceptatie, ter test. Hoe krijg je hem schaalbaar, hoe zorg je ervoor dat je...

Wat ik een mooie vind, waar vaak niet aan gedacht wordt, is het zogenaamd het sluiten van wat we

dan noemen het data vliegwiel. Dat is bij machine learning, AI, wat je nodig hebt is je wil ook dat

er nieuwe gevallen geleerd kunnen worden. Dat doet hij niet automatisch, dus je moet steeds

meer data verzamelen van nieuwe gevallen. Dus je moet gaan nadenken in je product ontwerp,

hoe je dat voor elkaar gaat krijgen. Hoe je niet alleen die nieuwe data krijgt, maar zeker als je

supervised learning toepast, waarbij je data labelt. Dat je zegt van ja deze data betekent het volgende,

moet je nagaan denken van ja hoezo. Het liefst heb je natuurlijk dat je gebruikers van je product

ook meteen nieuwe data die voorhanden is, die getraind zou moeten worden, dat ze die ook

kunnen labelen. Maar dat betekent wat ook in je productontwikkeling. Dus er zit inderdaad best

heel veel software ontwikkeling omheen. Nou ja de start is vaak makkelijk, want je hebt

één databronnetje of een databron, je hebt een stukje code en je hebt je model. Dat gaat allemaal

nog prima. Dan kom je bij de volgende stap, dat is wat wij noemen code model data. Dat is altijd iets

wat je constant moet herhalen. Die code ontwikkelt zich, het model ontwikkelt zich, maar de data

breidt ook uit. Misschien wil je meerdere bronnen gaan toevoegen, wil je meerdere versies van het

model uitproberen. Dat is typisch engineerwerk wat heel vaak bij de bedrijven over het hoofd

wordt gezien, of misschien waar kennis en kunde echt aan ontbreekt binnen een organisatie. Dan

komen we volgens mij bij de juiste teamsamenstelling. Wat je daar vooral ziet is dat modellen worden

gemaakt door data scientists. Maar daar zijn eigenlijk twee typen data scientists zijn te

onderscheiden. We hebben dat al eens een keer aangestipt in de eerdere aflevering van onze

podcast. Je hebt de type A van analist en de type B van bouwer. Zou je ze even zo kunnen splitsen.

Die bouwers heb je wel nodig. Dat zijn data scientists die modellen kunnen maken, maar ook

kunnen uitrollen, kunnen programmeren. Zodanig dat je daar echt een geïncapsuleerde software

van kan maken die zo naar productie kan. Dus je moet heel goed nadenken over je teamsamenstelling.

Dus we zien dat de teamsamenstelling toch ook wel een van de faalfactoren kan zijn bij een

AI project. Dus data scientist is in ieder geval nodig. Even denken. Dat is met name type B. Dat

data scientist type B is natuurlijk daarin nodig. Dat is vaak wat wij zien aanwezig binnen het

bedrijf of instelling. Wat heel vaak gedacht wordt is dat de IT afdeling ook de data afdeling is.

Maar verantwoordelijk is voor alle data rollen en data bronnen en het aanleveren van de data.

Maar een data engineer, het liefst dan ook nog eens met domeinkennis, dat is echt een apart

beroep. Een data engineer zorgt ervoor dat data bronnen bij elkaar komen. Zorgt ervoor dat je

data uit een database kan halen en waar het nodig is weer daarin terug kan stoppen. En dat is echt

een vak apart. Dat is niet de IT afdeling. Die weet ook precies van wat die data betekent. Dat

dat in het ene veld wat gelijk heet in een ene bron en bij een andere bron. Dat die weet van

ja maar de inhoud betekent echt wel wat anders. Dat soort zaken heb je nodig. Dat je niet zomaar

combinaties maakt van data. En een data engineer zorgt daadwerkelijk voor dat stukje selectiedata

dat je nodig hebt en niet voor maar een hele database dump. Dan hebben we een data engineer,

we hebben een data scientist type B. Wat hebben we nog meer nodig? De software engineer natuurlijk.

Want je hebt echt software engineering skills nodig. Opzetten van een DevOps pipeline. Het

maken van bijvoorbeeld een frontend rond het model. Zorgen dat de verzamelde nieuwe data ook

weer dat data vliegwiel dat dat dat het in de product ontwikkeld wordt. En ik zou zeggen zelf

altijd een product owner. Iemand die functionele beslissingen neemt. Die in ieder geval verantwoordelijk

is voor die product ontwikkeling. Hoe moet dat er uiteindelijk uitzien? Dat soort zaken die iemand

hebt die daar echt besluiten in kan nemen. Ja, maar product owner is denk ik ook belangrijk in

het uiteindelijk aanhaken van de business kant van het verhaal. Want die is ook een soort ambassadeur