Wie geef je de schuld als AI-projecten mislukken? De technologie? Uw machine learning en data science-team? verkopers? De data? Je kunt zeker de schuld geven aan het oplossen van het verkeerde probleem met AI, of het toepassen van AI als je AI helemaal niet nodig hebt. Maar wat gebeurt er als je een zeer geschikte applicatie voor AI hebt en het project nog steeds mislukt? Soms komt het neer op een simpele aanpak: doe er niet zo lang over.
Tijdens een recent Enterprise Data & AI-evenement deelde een presentator dat hun AI-projecten gemiddeld 18 tot 24 maanden nodig hebben om van concept tot productie te gaan. Dit is gewoon veel te lang. Er zijn veel redenen waarom AI-projecten mislukken en een veel voorkomende reden is dat het te lang duurt voordat uw project in productie gaat. AI-projecten zouden geen 18 of 24 maanden moeten duren om van pilot naar productie te gaan. Voorstanders van best-practices agile-methodologieën zouden je vertellen dat dit de ouderwetse “waterval”-manier is om dingen te doen die rijp is voor allerlei problemen.
Maar ondanks de wens om ‘agile’ te zijn met korte, iteratieve sprints van AI-projecten, hebben organisaties vaak moeite om hun AI-projecten van de grond te krijgen. Ze weten gewoon niet hoe ze korte, iteratieve AI-projecten moeten doen. Dit komt omdat veel organisaties hun AI-projecten uitvoeren alsof het “proofs-of-concept” in onderzoeksstijl zijn. Wanneer bedrijven beginnen met een proof of concept (POC)-project, in plaats van een pilot, zorgt dit ervoor dat ze falen. Bewijs van concepten leidt vaak tot mislukkingen omdat ze niet gericht zijn op het oplossen van een probleem in de echte wereld, maar eerder op het testen van een idee met behulp van idealistische of simplistische gegevens in een niet-realistische omgeving. Als gevolg hiervan werken deze organisaties met gegevens die niet representatief zijn voor de echte wereldgegevens, met gebruikers die niet veel in het project hebben geïnvesteerd en mogelijk niet werken in systemen waar het model daadwerkelijk zal leven. Degenen die succesvol zijn met AI-projecten hebben één simpel advies: laat de proof-of-concept achterwege.
AI-piloten vs. Proof of Concepts
Een proof-of-concept is een project dat een proef- of testrun is om te illustreren of iets mogelijk is en om te bewijzen dat uw technologie werkt. Proof of concepts (POC’s) worden uitgevoerd in zeer specifieke, gecontroleerde, beperkte omgevingen in plaats van in real-world omgevingen en gegevens. Dit is ongeveer de manier waarop AI is ontwikkeld in onderzoeksomgevingen. Toevallig komen veel AI-projecteigenaren, datawetenschappers, ML-ingenieurs en anderen uit die onderzoeksomgeving waar ze erg vertrouwd mee zijn.
Het probleem met deze POC’s is dat ze niet echt bewijzen of de specifieke AI-oplossing in productie zal werken. Integendeel, ze alleen als het zal werken in deze beperkte omstandigheden. Uw technologie werkt misschien geweldig in uw POC, maar valt dan uit elkaar wanneer ze in productie wordt genomen met scenario’s uit de echte wereld. Als u een proof of concept uitvoert, moet u mogelijk opnieuw beginnen en een pilot uitvoeren, waardoor uw project veel langer duurt dan oorspronkelijk verwacht, wat kan leiden tot problemen met personeel, middelen en budget. Andrew Ng kwam precies dit probleem tegen toen ze probeerden hun POC-benadering van medische beelddiagnose naar een echte wereldomgeving te brengen.
Proof-of-Concept-mislukkingen aan het licht gebracht
POC’s mislukken om verschillende redenen. De AI-oplossing is mogelijk alleen getraind op gegevens van goede kwaliteit die in de echte wereld niet bestaan. Dit was inderdaad de reden die door Andrew Ng werd aangehaald voor het falen van hun AI-oplossing voor medische beeldvorming die niet werkte buiten de goed verzorgde datagrenzen van Stanford-ziekenhuizen. Deze POC AI-oplossingen kunnen ook mislukken omdat het model niet heeft gezien hoe echte gebruikers, in tegenstelling tot goed opgeleide mensen, ermee omgaan. Er is echter een probleem met de echte wereldomgeving. Als gevolg hiervan krijgen organisaties die alleen projecten uitvoeren als een POC, pas de kans om deze problemen te begrijpen als u te ver bent.
Een ander voorbeeld van POC-storing is met autonome voertuigen (AV’s). AV’s werken vaak erg goed in gecontroleerde omgevingen. Er is geen afleiding, geen kinderen of dieren die de weg op rennen, geweldig weer en andere veelvoorkomende problemen waarmee bestuurders worden geconfronteerd. De AV presteert zeer goed in deze hypergecontroleerde omgeving. In veel real-world scenario’s weten AV’s niet hoe ze met veel specifieke real-world problemen moeten omgaan.Er is een reden waarom we geen autonome voertuigen van niveau 5 op de weg zien. Ze werken alleen in deze zeer gecontroleerde omgevingen en functioneren niet als een pilot die kan worden opgeschaald.
Een ander voorbeeld van falende AI POC-systemen is de Pepper-robot van Softbank. Pepper, nu stopgezet als een AI-project, was een collaboratieve robot die bedoeld was om te communiceren met klanten in musea, supermarkten en toeristische gebieden. De robot werkte heel goed in testomgevingen, maar toen hij in de echte wereld werd uitgerold, stuitte hij op problemen. Toen het werd ingezet in een Britse supermarkt, die veel hogere plafonds had dan de Amerikaanse supermarkten waar het werd getest, had Pepper moeite om de klanten te begrijpen. Het bleek ook de klanten bang te maken. Niet iedereen was enthousiast dat een robot hen benaderde tijdens het winkelen. Omdat Pepper niet echt in een pilot is getest, werden deze problemen nooit goed ontdekt en aangepakt, waardoor de hele release werd ingetrokken. Als ze maar een pilot hadden uitgevoerd waarbij ze de robot eerst op een of twee plaatsen in een echte wereldomgeving hadden uitgerold, zouden ze deze problemen hebben gerealiseerd voordat ze tijd, geld en middelen in een mislukt project hadden gestopt.
Piloten bouwen vs. Proofs-of-Concept
In tegenstelling tot een POC, richt een “pilot”-project zich op het bouwen van een klein testproject in de echte wereld, met behulp van real-world gegevens in een gecontroleerde, beperkte omgeving. Het idee is dat je een probleem uit de echte wereld gaat testen, met gegevens uit de echte wereld, op een systeem in de echte wereld met gebruikers die het model misschien niet hebben gemaakt. Op deze manier, als het pilotproject werkt, kunt u zich concentreren op het opschalen van het project in plaats van het toepassen van een POC op een geheel andere omgeving. Als gevolg hiervan zal een succesvol proefproject een organisatie tijd, geld en andere middelen besparen. En als het niet werkt, ontdek je snel wat de problemen in de echte wereld zijn en werk je om die problemen aan te pakken om je model te laten werken. Net als een piloot die een vliegtuig naar zijn eindbestemming leidt, leidt een pilootproject jouw AI-oplossingen naar een bestemming die productie is. Waarom zou je potentieel miljoenen uitgeven aan een project dat in de echte wereld misschien niet werkt als je dat geld en die tijd kunt besteden aan een pilot die dan alleen nog moet worden opgeschaald naar een productieniveau? Succesvolle AI-projecten beginnen niet met proof of concepts, ze beginnen met pilots.
Het is veel beter om een heel kleine pilot uit te voeren en een heel klein probleem op te lossen dat kan worden opgeschaald met een grote kans op succes, dan te proberen een groot probleem op te lossen met een proof of concept dat zou kunnen mislukken. Deze benadering van kleine, iteratieve successen gericht op pilots is een hoeksteen van best-practice AI-methodologieën zoals CRISP-DM of CPMAI die als doel hebben begeleiding te geven bij het ontwikkelen van kleine pilots met behulp van korte iteratieve stappen om snelle resultaten te verkrijgen. Door je te concentreren op de zeer iteratieve, real-world AI-pilot zal je project gebaseerd zijn op die ene eenvoudige methode die veel AI-implementeerders met groot succes zien.
.
0 Comments