Håndtering af data er afgørende for at få succes med ML og AI.
Og det behøver ikke være uoverskueligt, beretter Stefan Pedersen fra AI, ML og softwareudviklings-virksomheden WaveAccess.
Virksomheder har samlet data og kundeoplysninger i årevis, men at udvinde værdien af de store datamængder er fortsat den største udfordring. Men kunstig intelligens (AI) og Machine Learning (ML) giver mulighed for at få mest muligt ud af de tilgængelige data og få dem til at arbejde for sig.
Desværre er det ideelle grundlag – realistiske, korrekte og korrekt mærkede data i den rigtige mængde – næsten aldrig tilfældet. Ufuldstændige data, små mængder data om specifikke eksempler, manglende eller upålidelig mærkning og datafejl er de mest almindelige problemer skjult i datahåndteringen. Men hvis man accepterer substandard-data, vil resultatet også være substandard, uanset evner hos datafolkene eller anvendte algoritmer. Men det er muligt at undgå eller minimere problemerne.
Ufuldstændige data behøver ikke være en stopklods
Den mest almindelige faldgrube med ufuldstændige data sker, når en ellers acceptabel mængde data ikke fuldt ud beskriver et problem på grund af, at emneområdet er for snævert. Der er to løsninger på det. Den første er at starte på en ny iteration og udviklingsfase for at forbedre ML-systemet. Den anden er at sikre levering af alle forventede inputdata fra starten af projektet. Dette er mere en forebyggende foranstaltning og derfor den generelt foretrukne løsning.
Problemet og løsningen kan illustreres ved følgende. Hvis en virksomhed bruger et system til at forudsige begivenheder, fungerer løsningen muligvis kun for et bestemt område, sæson eller varetype. F.eks. et system til at forudsige skibskurser. Sådanne systemer giver stor hjælp til forebyggelse af skibsulykker – systemet forudsiger dem perfekt. Men hvis et firma nu bruger den samme løsning til at forudsige skibsulykker i et helt andet farvand, vil systemet mislykkes, fordi forholdene (mængden af skibe, navigationsregler, undersøiske strømme) ikke er de samme.
Dette kan undgås ved at levere alle de tilgængelige inputdata i starten af projektet.
Mindre delopgaver kan være løsningen
Selv med et stort antal tilgængelige dataprøver er det næsten umuligt at få etableret en ML-kvalitetsmodel, hvis der kun er lille viden om prøverne. Nogle gange kan problemet løses ved at opdele den oprindelige opgave i flere mindre delopgaver. Men hvis det ikke er en mulighed, kan det virke at skifte fokus til et andet område og ændre projektets mål.
Målet for vellykkede AI-projekter kan ændre sig afhængigt af de tilgængelige data, hvilket vores erfaring også viser. For eksempel besluttede en online sælger af luksusture at øge konverteringerne via deres websted. Virksomheden havde klaret sig ekstremt godt, og salgssystemet fungerede effektivt. Men med væksten i kundebasen kunne de ikke følge med antallet af anmodninger og behandle dem til tiden. Det oprindelige mål var at finde de henvendelser, hvor kunderne med størst sandsynlighed ville købe billetter. Dette viste sig at være et urealistisk mål. De tilgængelige data indeholdt kun et tidspunkt for henvendelser, land og by for afgang og ankomst, type og klasse for flyvning. Der var absolut ingen oplysninger om kunder.
At rette opmærksomheden mod et andet område virkede derfor fornuftigt – og at forudsige sandsynligheden for, hvilke kunder der var mere tilbøjelige til straks at gribe telefonen, blev en mulighed. Systemet placerede de mest lovende henvendelser først i køen.
De mest marginale kundeemner blev tildelt de mest kvalificerede sælgere for at forbedre chancerne for at lukke salget.
Resultatet efter blot 6 måneder var en reduktion i lead-behandlingstiden med 3 gange, og salget steg med 17% – tre gange mere end forventet.
Spar på ressourcerne – få selv styr på mærkningen
Machine Learning handler om at undervise algoritmerne ved at “give dem” de rigtige svar. Data skal derfor mærkes med “dette er korrekt” eller “dette er falsk”. Virksomheder har tendens til at flytte opgaven med at generere disse etiketter til deres teknologipartnere. Men i sidste ende ville det være meget billigere at tildele interne eksperter og løse problemet sammen med udvikleren.
Lad os tage et eksempel på problemet og dets konsekvenser (for sundhedsindustrien). Ultralydbilleder af halspulsårerne bruges til at detektere kolesterol-plak: en unormal fortykning af arterievæggene der kan indikere udviklingen af hjerte-kar-sygdomme.
Efter arteriescreeningen beskriver en tekniker manuelt, hvad han eller hun ser på scanningen. Denne konklusion vil sammen med scanningen blive givet til en læge, der fortolker resultaterne. At beskrive scanningen er et travlt arbejde. Der bruges meget tid på at se scanningsvideoerne og manuelle målinger. For at optimere et sådant system har en udvikler brug for alle historiske optegnelser over scanningerne sammen med præcis information om arterier (denne nøjagtige information er datamærkning).
Imidlertid bliver disse rådata ofte sendt til en udvikler. Sådanne data kan gemmes i forskellige formater, og kan omfatte unødvendige mærker og uklare beskrivelser. Udfra vores erfaring får dette en udvikler til at dykke dybere ned i emnet hvilket tager et stykke tid.
Målet med projektet vil blive nået, men en virksomhed kan spare ressourcer, hvis mærkningen udføres af dens egne medarbejdere. Resultatet er en fuldautomatisk og omkostningseffektiv arbejdsplads
Lad ikke ML-modellen lære af sine fejl
Masser af virksomhedssystemer indeholder oplysninger der er indtastet manuelt, og kan blive en kilde til fejl. De data, der bruges til test af Machine Learning-modellen, skal være fejlfri. En lille mængde tilfældige fejl, der ikke følger noget mønster, påvirker ikke rigtig resultaterne. Men hvis der er et antal fejl, der følger en vis afhængighed, lærer algoritmen at reproducere den. Det er hvad vi mener med, at ML-modellen ikke skal lære af sine fejl. Sørg for det rigtige udgangspunkt, det er det modellen vil gentage og lære af.
Hemmeligholdte data er ikke noget problem
Virksomheder behandler data som et centralt aktiv, hvilket er fair nok. Det er meget almindeligt, at nogle oplysninger skjules selv for medarbejderne. Er der derfor nogen løsning i forhold til at bygge en prototype uden at udsætte følsomme data?
Faktisk er der ikke noget problem, , når det kommer til datasikkerhed, fordi anonymiserede data er perfekt egnet til at udvikle en PoC. Hvis en virksomhed endnu ikke er klar til at dele sine databaser til opbygning af en model, kan den levere et anonymiseret datasæt – et sæt reelt depersonaliserede data. Dette er win-win-tilgangen: Virksomheden viser ikke private data, før den sørger for, at modellen opfører sig ordentligt i et fuldskala-projekt. Denne tilgang er udfra vores erfaring absolut godkendt.
Succesen gemmer sig i forberedelsene
Det virker måske ikke så udfordrende at komme med en fornuftig model, når data er perfekte – men i det virkelige liv sker det næsten aldrig. 99% af tiden mangler der reelle dataværdier, der er støj, outliers, overdreven information og andre faktorer, der gør det sværere at bruge.
Af den grund er dataforbehandling af eksperter betragtet som den mest tidskrævende – og derfor den dyre – del af et Data Science-baseret projekt.
Korrekt håndterede, velstrukturerede data og effektive, specifikke funktioner er derfor de vigtigste succesfaktorer for projektet.
