Denne klumme er et debatindlæg og er alene udtryk for skribenternes synspunkter.
Den leverandøruafhængige softwarekonference QCon har fået en lillesøster i form af QCon.ai, der blev afholdt for første gang april 2018.
Dette foregik selvfølgelig i San Francisco, der med Google, Facebook, Salesforce etc. er centrum for anvendt AI og machine learning.
Der findes allerede en del konferencer og symposier fokuseret på forskning inden for AI og machine learning, men QCon.ai er anderledes fordi den henvender sig specifikt til praktikerne.
Som mange andre mener vi i Nine A/S, at udbredelse af machine learning er et af de største tekniske skift, der er sket i de seneste 20 år, og derfor havde vi sendt en håndfuld deltagere afsted.
Ud over de mange spændende tekniske indlæg bemærkede jeg tre særligt tre temaer, der gik igen på tværs af talerne.
Hvordan springer I fra modeludvikling til produktion?
Ét er at sætte en data scientist til at oprense data, opsætte hypoteser og udlede sammenhænge i data, og derfra danne en god forudsigelsesmodel - noget andet er at kunne og turde sætte modellen i produktion.
For det første bruges der i dag typisk Java, .NET og PHP i forretningsapplikationer, hvorimod Python eller R er de mest udbredte sprog til machine learning, og det er ret bøvlet at blande programmeringssprogene sammen.
Dette kan umiddelbart løses med to forskellige strategier: Enten kan man adskille træningen og modelanvendelse, f.eks. ved at gen-implementere modellen på den relevante driftsplatform, og indlæse vægtene fra den trænede model.
Dette blev beskrevet af blandt andre Spark-committer Holden Karau fra Google.
En anden strategi, som er særligt egnet til mere komplicerede modeller såsom neurale netværk, er at sætte modelkoden i produktion, men pakke den i ind i en container og afvikle dem som en separat service.
Forretningssystemet kan så kalde ind til denne. Daniel Whitenack fra Pachyderm demonstrerede netop denne teknik. Vi har i Nine gode erfaringer med tilsvarende teknikker.
De store cloud-ML leverandører har selvfølgelig knækket dén nød, men det kræver at man allerede er i båd hos dem. På QCon.ai demonstrerede blandt andre Asif Khan (Amazon) hvorledes overgangen fra træning til drift kan gøres i Amazon Web Services.
For det andet er der spørgsmålet om hvilke kvalitetssikringsprocesser, der skal bruges inden de nytrænede vægte sættes i produktion (eller helt nye modeller): Klassiske QA processer siger ‘ja’ eller ‘nej’ til om systemet gør som det skal.
Med ML kommer der gråzoner ind, hvor systemet måske for det meste svarer som forventet, men hvor det kan være svært at afgøre, om funktionaliteten er blevet værre eller bedre end i sidste version.
Holden Karau beskrev nogle af de faldgruber, man skal styre udenom “for at undgå at ødelægge sin karriere en søndag aften”, men hovedbudskabet var “vær forsigtig”.
Både for QA/test og DevOps er der behov for nye metoder for at indarbejde machine learning i arbejdsgangene.
Kan I forklare hvorfor jeres ML-modeller svarer som de gør?
Et andet gennemgående tema på QCon.ai var muligheden for at forklare ML-modeller.
Et eksempel: En virksomhed med behov for at kreditvurdere sine kunder, kan tage sine historiske data om gode og dårlige betalere, og oplære en model til at svare ja eller nej på om en kunde må få et lån.
Her er dilemmaet at den mest nøjagtige model måske ikke er den, der er nemmest at forklare kunder - eller for den sags skyld kundeservicen.
Som blandt andre Leah McGuire og Mayukh Bhaowal fra Salesforce forklarede, er det efter amerikansk lovgivning slet ikke OK blot at sige “computer says no”: Kreditvurderingsmodeller skal kunne forklares - og i EU har Margrethe Vestager sagt noget tilsvarende.
Derfor kan det godt være en bedre løsning at tage en enklere model som f.eks. lineær regression fremfor et et dybt neuralt netværk, da en enklere model også vil være nemmere at forklare.
Denne type forklaring kaldes en global forklaring, da man kan fortælle hvordan hele modellen virker.
Modsat globale forklaringer, findes der lokale forklaringer, hvor man ud fra et konkret tilfælde kan afgrænse hvad der medfører den enkelte forudsigelse.
Mike Lee Williams fra Cloudera demonstrerede LIME (i Python) som netop kan vise denne afgrænsning, ud fra tabeldata, tekster eller billeder.
I eksemplet ville man kunne forklare en kunde hvilke faktorer, der konkret betyder at de afvises. I billedgenkendelse får man fremhævet hvilke dele af billedet, der påvirker forudsigelsen mest.
Kan I stå inde for de slagsider, jeres data indeholder?
Machine learning modeller er jo blot en række talparametre sat sammen i ét stort regnestykke, der optimeres til at efterligne jeres udvalgte data.
Hvis data afspejler ét aspekt af verden - eksempelvis kønsstereotyper, vil modellen blindt reproducere det, uden skelen til etiske eller politiske vinkler.
I den afsluttende keynote ved QCon.ai problematiserede Rachel Thomas fra fast.ai disse slagsider i ML, såsom at nogle modeller til billedgenkendelse fungerer bedst på hvide mænd. Disse følger direkte af de data, der bruges i træningen.
Et eksempel på dette er i GloVe-modellen, der bruges som led i "forståelsen" af tekst, eksempelvis til at skelne mellem positive og negativt ladede sætninger ("sentiment analysis"):
GloVe er trænet på et stort korpus tekst, og omsætter enkeltord til vektorer ud fra deres brug, sådan at man for eksempel kan udlede at "dronning” er til "kvinde" som "konge" er til "mand".
Men er det meningen, at "mand" er tættere på "programmør" end "kvinde" er det?
Selvom det følger direkte af det tekstkorpus, modellen er trænet ud fra, giver det en utilsigtet slagside (bias).
Det er ikke kun køn, der møder bias i sprogmodeller: Et andet eksempel er omtale af mexicansk mad, der lider under den negative presse om mexicanske indvandrere i USA og derfor scores lavere end f.eks. italiensk mad.
Google Translate bruger en tilsvarende teknik, og er trænet på oversatte tekster side-om-side. Derfor bliver det tyrkiske (ikke-kønnede) "o bir doktor" på engelsk til "he is a doctor", mens "o bir hemşire" bliver til "she is a nurse". Prøv selv!
Data lyver ikke, men fortæller de den historie, vi ønsker at fortælle?
Sammensat - men godt sammensat
Min oplevelse var at QCon.ai var skruet ret godt sammen, med enkelte skønhedsfejl.
Selvom der var områder, jeg gerne ville have hørt mere om, var jeg godt tilfreds med indholdet.
Talerne var virkelig kvalificerede og indholdet var ikke kun teknik for teknikkens skyld.
Af tre dages indhold var der kun en enkelt tale, der faldt igennem - den lød halvt som salgstale, halvt som jobopslag. Vi kom derfor hjem med nye ML-teknikker i værktøjsbæltet, men også med lidt klogere på emner som de tre ovennævnte.
Kig selv nærmere på QCon.ai websitet, hvor også en del af præsentationerne kan findes.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.