AANDACHT VOOR HET TESTVAK
Testen staat op de kaart als het over AI gaat! Het wordt in een groot aantal presentaties genoemd. ‘Testing keeps you safe’ werd zelfs letterlijk gezegd tegenover de 6.000 aanwezigen. Tegelijk werd toegegeven dat testen nog niet mainstream is in de AI wereld waarin veel experimenteren en vooruitgang toch wel de boventoon voeren.
Het is niet verwonderlijk dat het rond testen nog vaag blijft. De match met TMap is lastig te maken; in presentaties over testen ging werden vaak ongebruikelijke testsoorten of -vormen gebruikt. Testervaring is relevant, maar voor AI zullen we ons verder moeten verdiepen en specialiseren.
REQUIREMENTS EN ONTWERP
Artificial Intelligence en zeker de machine learning oplossingen zijn meestal een black box. Als je niet verrast wilt worden door de uitkomsten van een AI applicatie, zul je daar tijdens je ontwerp rekening mee moeten houden (‘design for trust’). Bij mensen onderling werkt dit ook ongeveer zo; vertrouwen ontstaat omdat je van de ander weet hoe hij of zij tot een bepaalde uitkomst komt. Bij AI zouden we dat ook willen.
Bij AI is het echter onmogelijk om alle tussenstappen van de beslissing inzichtelijk te maken. De AI wordt getraind met voorbeelden, niet geprogrammeerd met regels die je stuk voor stuk zou kunnen testen. We moeten accepteren dat AI deels een black box blijft. En zoals bij iedere andere black box zullen testers de mogelijke input en gewenste output moeten definiëren. Echter, bij geprogrammeerde applicaties heb je meestal eerst een white box test / unit test gedaan en weet je ongeveer wat je mag verwachten. Bij AI kan dit niet. Daardoor komt de nadruk te liggen op de black box test en moeten we onze gewenste én ongewenste situaties nóg beter beschrijven.
Laten we een voorbeeld nemen van als je dit niet doet. Stel dat je een AI traint om zoveel mogelijk geld te verdienen aan een klant, dan zal dit bij een paar klanten slagen, maar lopen deze klanten daarna weg omdat ze zich slecht behandeld voelen. Amazon kijkt bijvoorbeeld niet naar hoeveel ze per klant verdienen, maar hoe vaak men op hun content klikt. De omzet / winst volgt daarna vanzelf.
En zoals in het tweede blog te lezen was, zijn er vaak verborgen requirements. Bijvoorbeeld menselijke waarden, zoals mooi in een gedachtenexperiment beschreven door Stuart Russell: als je tegen de AI zegt dat hij een kop koffie moet halen, zal hij dat doel behalen. En als dit het enige doel is dat je geeft, dan zal hij er ieder bedrag voor betalen en zo nodig iemand doden die de koffieautomaat zou kunnen uitzetten.
DATA EN TESTEN
Artificial intelligence maakt meestal gebruik van grote hoeveelheden data om trends te ontdekken en voorspellingen te doen. Goede data wordt daarom van groot belang. Daarbij betekent ‘goed’ zowel dat alle velden gevuld zijn, dat er logische waarden in de velden staan, maar ook dat het relevant en generaliseerbaar is. Een mooi voorbeeld werd gegeven door Simon Vermeer van het Erasmus MC over het gebruik van data voor onderzoek: als je alleen de gegevens van de patiënten binnen het eigen ziekenhuis gebruikt, dan zie je niet of deze afwijkt van de rest van Nederland, van Europa of van de wereld.
Een mogelijke oplossing is het opstellen van een generieke datasets. Algemeen toegankelijke datasets met een zeer groot aantal generaliseerbare voorbeelden. En dan uiteraard gedepersonaliseerd of op een hoger niveau geaggregeerd om aan alle wetgeving te voldoen. Het mooiste is natuurlijk als het publiek beschikbaar komt. Maar gezien de waarde van dergelijke goede gegevens, zou deze als ‘commodity’ verhandeld kunnen worden.
Welke variant het ook wordt, het zal niet op korte termijn voorhanden zijn. Simon had daarom ook een tussenstap in gedachten; het toekennen van een bepaalde bruikbaarheidsscore aan de eigen data. Zo weet je in hoeverre je model op de gegevens kan vertrouwen en dat helpt ook om het wel of niet ‘los te laten’ ter ondersteuning van je huidige bedrijfsprocessen.
TECHNISCH EN FUNCTIONEEL TESTEN
De meest basale manier om te testen is een dataset opsplitsen in een trainingset en een testset. Dit gebeurt nu in de AI wereld ook al. Verder is op de World Summit vaak genoemd dat je de beslissingen van de AI moet terugrekenen, al is dat lang niet altijd mogelijk. Als een plan B kunnen we natuurlijk het idee van Evert Haasdijk (zie de eerste blog) gebruiken en een tweede, eenvoudiger model maken dat mensen wél snappen. Het simpele model helpt bij het verklaren van het échte model dat te complex is.
De functionele test bestaat uit het selecteren en testen van de verschillende contexten! Een mooi voorbeeld kwam van een Afrikaanse presentator, die aangaf dat de wegen in Afrika en India totaal anders zijn dan in het westen waar zelfrijdende auto’s nu vooral getraind worden. Bovendien moeten we als tester zelf nog common sense moeten bewaken, zolang de AI dit nog niet zelf kan.
Daarnaast moeten testers én de business collega’s nadenken over ‘safety nets’ ofwel maatregelen voor het scenario waarin de AI toch de fout in gaat. Foutafhandeling 2.0. Een interessant en divers onderwerp, waar we in een later blog zeker dieper op ingaan.
ACCEPTATIETESTEN
In zekere zin blijft de vraag bij acceptatietesten dezelfde; heb ik voldoende praktijkvoorbeelden gezien en heb ik daar voldoende vertrouwen uit gehaald. Er komt wel een dimensie bij: accepteren we dat de AI dit gedeelte van ons denkwerk overneemt? Durf ik de AI te vertrouwen?
Een praktisch voorbeeld werd gegeven over het voorspellen van een longontsteking. De eerste AI variant gaf in 95% van de gevallen een goede voorspelling, De tweede variant deed dit in 80% van de gevallen. Toch zijn ze de tweede variant gaan gebruiken, omdat die variant een verklaring kon geven waarom hij tot die conclusie kwam.
Een groot deel van het accepteren is het goed omgaan met bandbreedtes; wanneer vertrouw ik de AI en wanneer wil ik het zelf nog controleren.
Ook onderdeel van acceptatietesten, maar van een heel andere orde, is het vasthouden van ethische standaarden bij het gebruik van AI; hoe zorg je ervoor dat mensen AI ethisch gebruiken, voor het verbeteren van de mensheid, en niet (alleen) voor het geld.
TESTEN IN PRODUCTIE
Zeker bij een plek waar veel gebruik wordt gemaakt van je dienst en de gevolgen klein zijn, kun je al je varianten en ideeën proberen in je productie omgeving. De meest succesvolle varianten werk je vervolgens verder uit. Of, om te voorkomen dat je je blind staart op één ‘beste’ oplossing, kun je langzaam maar zeker de minst succesvolle varianten stoppen tot de set beste oplossingen overblijft.
Een andere reden om in productie te blijven testen, is dat de AI meestal verder blijft leren en dus ook in de live situatie ‘scheef’ kan gaan. Dit kun je voorkomen door nieuwe trends te blijven herkennen en daarop in te spelen.
SKILLS VOOR DE TOEKOMST
Wie op dit punt in het blog is aangekomen, weet dat je nieuwe skills zal moeten aanleren om te testen in de AI wereld.
Bijvoorbeeld op het gebied van data. Data wordt steeds meer beschikbaar, maar ruwe data heeft geen waarde. Testers zullen moeten begrijpen hoe het verzamelen, prepareren, interpreteren en op waarde schatten van data werkt, zodat we erop kunnen vertrouwen. Tijdens de World Summit werd zelfs aangegeven dat iemand de rol van ‘reliability engineer’ had. Is dat een pseudoniem voor AI tester?
Langs dezelfde lijn moeten wij als testers leren om niet meer te testen via instructies, maar via voorbeelden en relevante data selecties. Het verschil klinkt subtiel, maar is enorm.
Ook de beslissers zullen zich moeten aanpassen. Een belangrijke skill is het beter leren nemen van beslissingen, liefst gedreven door data en statistische relevantie van die data. In ieder blog van Cassie Kozyrkov van Google komt dit wel terug.
Dat leidt tot een mooie afsluitende vraag voor ons als test specialist en kwaliteitsbewaker, namelijk; als we onze boodschap over kwaliteit willen overbrengen, moeten we ons dan richten op de harde cijfers of toch meer op een goed gevoel over de huidige situatie? En zo komen we weer terug op het begrijpen en vertrouwen van AI en de raket van Cassie waar het eerste blog mee begon.
EEN PRAKTISCHE AANPAK VOOR TESTEN VAN AI?
Er zijn aandachtspunten genoeg voor het testen van AI-ondersteunde applicaties. De business wil van goede beslisinformatie worden voorzien en vanuit Salves hebben we dit samengebracht tot één praktische testaanpak voor het testen van AI-applicaties. In één van de volgende blogs vind je het resultaat tot nu toe. Met natuurlijk de uitnodiging om mee te denken, want kwalitatief goede AI is iets waar we allemaal belang bij hebben!
Test Engineer Regio Zuid
- 32 - 40 uur
- €3.000 - €5.500 bruto
- Onbeperkt opleidingsbudget