Hvordan Bias Kan Ødelægge Din AI/ML-Strategi og Hvad Du Kan Gøre Ved Det

’Bias’ i modeller af enhver art beskriver en situation, hvor modellen reagerer urigtigt på prompts eller inputdata, fordi den ikke er blevet trænet med tilstrækkeligt mange højkvalitets- og diverse data til at give en præcis respons. Et eksempel ville være Apples ansigtsgenkendelsesfunktion til telefonlås, som fejlede med en betydeligt højere fejlrate for personer med mørkere hudfarver i forhold til lysere nuancer. Modellen var ikke blevet trænet på tilstrækkeligt mange billeder af personer med mørkere hudfarver. Dette var et relativt lavrisikoeksempel på bias, men det er præcis, hvorfor EU’s AI-lov har foreskrevet krav til at bevise modellens effektivitet (og kontroller) før markedsgangen. Modeller med output, der har indvirkning på forretnings-, finansielle-, sundheds- eller personlige situationer, skal være troværdige, eller de vil ikke blive brugt.

At Tackle Bias Med Data

Store Mængder Af Højkvalitetsdata

Blandt mange vigtige datastyringspraksis er en nøglekomponent til at overvinde og minimere bias i AI/ML-modeller at erhverve store mængder af højkvalitets-, diverse data. Dette kræver samarbejde med multiple organisationer, der har sådanne data. Traditionelt set udfordres dataanskaffelse og samarbejde af privatlivs- og/eller IP-beskyttelsesbekymringer – følsomme data kan ikke sendes til modellens ejer, og modellens ejer kan ikke risikere at lække deres IP til en dataejer. En almindelig løsning er at arbejde med mock eller syntetisk data, som kan være nyttigt, men også har begrænsninger i forhold til at bruge rigtige, fuld-kontekst data. Det er her, hvor teknologier til forbedring af privatliv (PETs) giver de nødvendige svar.

Syntetisk Data: Tæt På, Men Ikke Næsten

Syntetisk data er kunstigt genereret for at efterligne rigtige data. Dette er svært at gøre, men bliver lidt lettere med AI-værktøjer. God kvalitet syntetisk data skal have de samme funktionafstande som rigtige data, eller det vil ikke være nyttigt. Kvalitets syntetisk data kan bruges til effektivt at øge diversiteten af træningsdata ved at udfylde huller for mindre, marginaliserede befolkninger eller for befolkninger, som AI-udbyderen simpelthen ikke har nok data. Syntetisk data kan også bruges til at tackle kanttilfælde, der kan være svære at finde i tilstrækkelige mængder i den virkelige verden. Derudover kan organisationer generere en syntetisk datasaet for at tilfredsstille dataresidens- og privatlivskrav, der blokerer adgangen til de rigtige data. Dette lyder godt, men syntetisk data er kun et stykke af puslespillet, ikke løsningen.

En af de åbenlyse begrænsninger af syntetisk data er afkoblingen fra den virkelige verden. For eksempel vil selvstændige køretøjer, der udelukkende er trænet på syntetisk data, have svært ved at tackle rigtige, uforudsete vejforhold. Derudover arver syntetisk data bias fra de rigtige data, der blev brugt til at generere det – hvilket næsten ødelægger formålet med vores diskussion. I konklusion er syntetisk data et nyttigt valg til finjustering og til at tackle kanttilfælde, men betydelige forbedringer af modellens effektivitet og minimisering af bias afhænger stadig af adgangen til rigtige data.

En Bedre Måde: Rigtige Data Via PETs-aktiverede Arbejdsgange

PETs beskytter data, mens de er i brug. Når det kommer til AI/ML-modeller, kan de også beskytte IP’en for den model, der køres – “to fugle med én sten.” Løsninger, der anvender PETs, giver mulighed for at træne modeller på rigtige, følsomme datasæt, der ikke tidligere var tilgængelige på grund af dataprivatlivs- og sikkerhedsbekymringer. Denne åbning af datastrømme til rigtige data er den bedste mulighed for at reducere bias. Men hvordan ville det faktisk fungere?

For nu starter de førende muligheder med en konfidentiel computermiljø. Derefter følger en integration med en PETs-baseret softwareløsning, der gør det klar til brug ud af æsken, samtidig med at det løser datastyrings- og sikkerhedsbekymringer, der ikke er inkluderet i et standard-trustet execution environment (TEE). Med denne løsning er modellerne og dataene alle krypteret, før de sendes til et sikret computermiljø. Miljøet kan være placeret hvor som helst, hvilket er vigtigt, når det handler om at løse visse data-lokaliseringskrav. Dette betyder, at både modellens IP og sikkerheden for inputdataene opretholdes under beregning – ikke engang udbyderen af det trustede execution environment har adgang til modellerne eller dataene inde i det. De krypterede resultater sendes derefter tilbage til gennemsyn, og logfiler er tilgængelige for gennemsyn.

Dette flow åbner den bedste kvalitetsdata uanset, hvor den er, eller hvem der har den, og skaber en vej til at minimere bias og opnå højeffektive modeller, som vi kan stole på. Dette flow er også, hvad EU’s AI-lov beskrev i deres krav til en AI-regulerings-sandkasse.

At Facilitere Etisk Og Juridisk Overholdelse

At erhverve god kvalitets-, rigtige data er svært. Dataprivatlivs- og lokaliseringskrav begrænser straks de datasæt, som organisationer kan få adgang til. For innovation og vækst at ske, skal data flyde til dem, der kan udtrække værdien af det.

Art 54 i EU’s AI-lov giver krav til “højrisiko”-modtyper i forhold til, hvad der skal være bevist, før de kan tages til markedet. I kort sagt skal holdene bruge rigtige verdensdata inde i en AI-regulerings-sandkasse for at vise tilstrækkelig modell-effektivitet og overholdelse af alle kontroller, der er detaljeret i Titel III, Kapitel 2. Kontrollerne inkluderer overvågning, gennemsigtighed, forklarbarhed, datasikkerhed, dataprotektion, dataminimering og modellbeskyttelse – tænk DevSecOps + Data Ops.

Den første udfordring vil være at finde et rigtigt datasæt at bruge – da dette er inherent følsomt data for sådanne modtyper. Uden tekniske garantier kan mange organisationer tøve med at stole på modellens udbyder med deres data eller ikke have lov til at gøre det. Derudover er måden, hvorpå loven definerer en “AI-regulerings-sandkasse”, en udfordring i sig selv. Nogle af kravene inkluderer en garanti for, at dataene fjernes fra systemet, efter at modellen er blevet kørt, samt styringskontroller, gennemførelse og rapportering for at bevise det.

Mange organisationer har prøvet at bruge færdiglavede data-rene-værelser (DCR’er) og trustede execution environments (TEE’er). Men på egen hånd kræver disse teknologier betydelig ekspertise og arbejde for at operationalisere og opfylde data- og AI-reguleringskrav.
DCR’er er simplere at bruge, men ikke endnu nyttige til mere robuste AI/ML-behov. TEE’er er sikrede servere og har stadig brug for en integreret samarbejdspolitik for at være nyttige, hurtigt. Dette identificerer dog en mulighed for teknologier til forbedring af privatliv at integrere med TEE’er for at fjerne dette arbejde, hvilket gør det lettere at sætte op og bruge en AI-regulerings-sandkasse, og dermed erhverve og bruge følsomme data.

Ved at aktivere brugen af mere diverse og omfattende datasæt på en privatlivsbevarende måde hjælper disse teknologier med at sikre, at AI- og ML-praksis overholder etiske standarder og juridiske krav i forhold til dataprivatliv (f.eks. GDPR og EU’s AI-lov i Europa). I sammenfattende, mens krav ofte mødes med hørlige grynt og suk, er disse krav blot vejledning til at bygge bedre modeller, som vi kan stole på og bruge til vigtige data-drevne beslutninger, samtidig med at vi beskytter privatlivet for de datasubjekter, der bruges til modellens udvikling og tilpasning.