Få mest muligt ud af dine data

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 der 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.