Lag data av høy kvalitet for ML-modeller med Amazon SageMaker Ground Truth

Maskinlæring (ML) har forbedret virksomheten på tvers av bransjer de siste årene – fra anbefalingssystemet på din Prime Video konto, til å dokumentere oppsummering og effektivt søk med Alexasin stemmehjelp. Spørsmålet gjenstår imidlertid om hvordan du skal inkorporere denne teknologien i virksomheten din. I motsetning til tradisjonelle regelbaserte metoder, utleder ML automatisk mønstre fra data for å utføre oppgaven av interesse. Selv om dette omgår behovet for å kurere regler for automatisering, betyr det også at ML-modeller bare kan være like gode som dataene de er trent på. Dataskaping er imidlertid ofte en utfordrende oppgave. På Amazon Machine Learning Solutions Lab, har vi gjentatte ganger støtt på dette problemet og ønsker å lette denne reisen for kundene våre. Hvis du vil avlaste denne prosessen, kan du bruke Amazon SageMaker Ground Truth Plus.

På slutten av dette innlegget vil du kunne oppnå følgende:

• Forstå forretningsprosessene som er involvert i å sette opp en datainnsamlingspipeline
• Identifiser AWS Cloud-tjenester for å støtte og fremskynde datamerkingspipeline
• Kjør en datainnsamlings- og merkeoppgave for tilpassede brukstilfeller
• Lag data av høy kvalitet i henhold til forretningsmessige og tekniske beste praksiser

Gjennom dette innlegget fokuserer vi på dataskapingsprosessen og stoler på AWS-tjenester for å håndtere infrastrukturen og prosesskomponentene. Vi bruker nemlig Amazon SageMaker Ground Truth å håndtere etiketteringsinfrastrukturens pipeline og brukergrensesnitt. Denne tjenesten bruker en pek-og-gå-tilnærming for å samle inn dataene dine fra Amazon enkel lagringstjeneste (Amazon S3) og sett opp en merkearbeidsflyt. For merking gir den deg den innebygde fleksibiliteten til å skaffe dataetiketter ved å bruke ditt private team, en Amazon Mekanisk Turk force, eller din foretrukne merkeleverandør fra AWS Marketplace. Til slutt kan du bruke AWS Lambda og Amazon SageMaker notatbøker å behandle, visualisere eller kvalitetskontrollere dataene – enten før eller etter merking.

Nå som alle bitene er lagt ned, la oss starte prosessen!

Dataopprettingsprosessen

I motsetning til vanlig intuisjon, er det første trinnet for dataskaping ikke datainnsamling. Å jobbe bakover fra brukerne for å artikulere problemet er avgjørende. Hva bryr brukerne seg for eksempel om i den endelige artefakten? Hvor mener eksperter at signalene som er relevante for brukssaken finnes i dataene? Hvilken informasjon om use case-miljøet kan gis for å modellere? Hvis du ikke vet svarene på disse spørsmålene, ikke bekymre deg. Gi deg selv litt tid til å snakke med brukere og felteksperter for å forstå nyansene. Denne første forståelsen vil orientere deg i riktig retning og sette deg opp for suksess.

For dette innlegget antar vi at du har dekket denne innledende prosessen med spesifikasjon av brukerkrav. De neste tre delene leder deg gjennom den påfølgende prosessen med å lage kvalitetsdata: planlegging, oppretting av kildedata og datakommentarer. Pilotsløyfer ved dataoppretting og merknadstrinn er avgjørende for å sikre effektiv oppretting av merkede data. Dette innebærer å iterere mellom dataoppretting, merknader, kvalitetssikring og oppdatering av pipeline etter behov.

Følgende figur gir en oversikt over trinnene som kreves i en typisk dataopprettingspipeline. Du kan jobbe bakover fra brukssaken for å identifisere dataene du trenger (kravspesifikasjon), bygge en prosess for å innhente dataene (planlegging), implementere selve datainnsamlingsprosessen (datainnsamling og merknader), og vurdere resultatene. Pilotkjøringer, uthevet med stiplede linjer, lar deg iterere på prosessen til en datainnsamlingspipeline av høy kvalitet er utviklet.

Planlegging

En standard dataopprettingsprosess kan være tidkrevende og sløsing med verdifulle menneskelige ressurser hvis den utføres ineffektivt. Hvorfor skulle det være tidkrevende? For å svare på dette spørsmålet må vi forstå omfanget av dataopprettingsprosessen. For å hjelpe deg har vi samlet en sjekkliste på høyt nivå og beskrivelse av nøkkelkomponenter og interessenter som du må vurdere. Å svare på disse spørsmålene kan være vanskelig i begynnelsen. Avhengig av din brukssituasjon, kan bare noen av disse være aktuelle.

• Identifiser det juridiske kontaktpunktet for nødvendige godkjenninger – Bruk av data for applikasjonen din kan kreve gjennomgang av lisens eller leverandørkontrakt for å sikre overholdelse av selskapets retningslinjer og brukstilfeller. Det er viktig å identifisere den juridiske støtten din gjennom datainnsamlingen og kommentartrinnene i prosessen.
• Identifiser sikkerhetskontakten for datahåndtering – Lekkasje av kjøpte data kan føre til alvorlige bøter og konsekvenser for din bedrift. Det er viktig å identifisere sikkerhetsstøtten din gjennom datainnsamlingen og kommentartrinnene for å sikre sikker praksis.
• Detaljer brukskrav og definer kildedata og retningslinjer for kommentarer – Det er vanskelig å lage og kommentere data på grunn av den høye spesifisiteten som kreves. Interessenter, inkludert datageneratorer og annotatorer, må være helt på linje for å unngå sløsing med ressurser. For dette formål er det vanlig praksis å bruke et dokument med retningslinjer som spesifiserer alle aspekter av merknadsoppgaven: eksakte instruksjoner, kantsaker, en eksempelgjennomgang og så videre.
• Tilpass forventningene for innsamling av kildedata - Vurder følgende:
  • Utfør forskning på potensielle datakilder – For eksempel offentlige datasett, eksisterende datasett fra andre interne team, selvinnsamlede eller kjøpte data fra leverandører.
  • Utføre kvalitetsvurdering – Lag en analysepipeline i forhold til den endelige brukssaken.
• Juster etter forventningene for å lage datakommentarer - Vurder følgende:
  • Identifiser de tekniske interessentene – Dette er vanligvis en person eller et team i bedriften din som er i stand til å bruke den tekniske dokumentasjonen angående Ground Truth for å implementere en annoteringspipeline. Disse interessentene er også ansvarlige for kvalitetsvurdering av de kommenterte dataene for å sikre at de oppfyller behovene til nedstrøms ML-applikasjonen din.
  • Identifiser dataannotatorene – Disse personene bruker forhåndsbestemte instruksjoner for å legge til etiketter til kildedataene dine i Ground Truth. De kan trenge å ha domenekunnskap, avhengig av brukstilfellet og retningslinjene for kommentarer. Du kan bruke en arbeidsstyrke internt i bedriften din, eller betale for en arbeidsstyrke administrert av en ekstern leverandør.
• Sikre tilsyn med dataopprettingsprosessen – Som du kan se fra de foregående punktene, er dataskaping en detaljert prosess som involverer mange spesialiserte interessenter. Derfor er det avgjørende å overvåke det fra ende til annen mot ønsket resultat. Å ha en dedikert person eller team til å overvåke prosessen kan hjelpe deg med å sikre en sammenhengende, effektiv dataopprettingsprosess.

Avhengig av ruten du bestemmer deg for å ta, må du også vurdere følgende:

• Opprett kildedatasettet – Dette refererer til tilfeller der eksisterende data ikke er egnet for den aktuelle oppgaven, eller juridiske begrensninger hindrer deg i å bruke den. Det skal benyttes interne team eller eksterne leverandører (neste punkt). Dette er ofte tilfellet for høyt spesialiserte domener eller områder med lav offentlig forskning. For eksempel, en leges vanlige spørsmål, plagget legge ned, eller sportseksperter. Det kan være internt eller eksternt.
• Undersøk leverandører og gjennomføre en onboarding-prosess – Når eksterne leverandører brukes, må en kontrakts- og innføringsprosess settes på plass mellom begge enhetene.

I denne delen har vi gjennomgått komponentene og interessentene som vi må vurdere. Men hvordan ser selve prosessen ut? I den følgende figuren skisserer vi en prosessarbeidsflyt for dataoppretting og merknader. Den iterative tilnærmingen bruker små grupper med data kalt piloter for å redusere behandlingstiden, oppdage feil tidlig og unngå å sløse med ressurser på å lage data av lav kvalitet. Vi beskriver disse pilotrundene senere i dette innlegget. Vi dekker også noen beste fremgangsmåter for dataoppretting, merknader og kvalitetskontroll.

Følgende figur illustrerer den iterative utviklingen av en dataopprettingspipeline. Vertikalt finner vi datakildeblokken (grønn) og merknadsblokken (blå). Begge blokkene har uavhengige pilotrunder (dataoppretting/kommentarer, QAQC og oppdatering). Stadig høyere kildedata opprettes og kan brukes til å konstruere merknader av stadig høyere kvalitet.

Oppretting av kildedata

Inndataopprettingsprosessen dreier seg om å iscenesette elementene av interesse, som avhenger av oppgavetypen din. Dette kan være bilder (avisskanning), videoer (trafikkscener), 3D-punktskyer (medisinske skanninger) eller rett og slett tekst (undertekstspor, transkripsjoner). Generelt, når du setter opp oppgaverelaterte elementer, sørg for følgende:

• Gjenspeil den virkelige brukssaken for det eventuelle AI/ML-systemet – Oppsettet for å samle bilder eller videoer for treningsdataene dine bør samsvare nøye med oppsettet for inndataene dine i den virkelige applikasjonen. Dette betyr å ha konsistente plasseringsflater, lyskilder eller kameravinkler.
• Redegjør for og minimer variasjonskilder - Vurder følgende:
  • Utvikle beste praksis for å opprettholde standarder for datainnsamling – Avhengig av granulariteten til brukssaken din, må du kanskje spesifisere krav for å garantere konsistens mellom datapunktene dine. For eksempel, hvis du samler inn bilde- eller videodata fra enkeltkamerapunkter, kan det hende du må sørge for konsekvent plassering av objektene du er interessert i, eller kreve en kvalitetssjekk for kameraet før en datafangstrunde. Dette kan unngå problemer som kameravipping eller uskarphet, og minimere nedstrøms utgifter som å fjerne bilder utenfor rammen eller uskarpe bilder, i tillegg til å måtte sentrere bilderammen manuelt på interesseområdet ditt.
  • Foregrip testtidskilder til variabilitet – Hvis du forventer variasjon i noen av attributtene som er nevnt så langt under testtiden, sørg for at du kan fange opp disse variasjonskildene under oppretting av treningsdata. For eksempel, hvis du forventer at ML-applikasjonen din skal fungere i flere forskjellige lysinnstillinger, bør du sikte på å lage treningsbilder og videoer med forskjellige lysinnstillinger. Avhengig av brukstilfellet kan variasjon i kameraposisjonering også påvirke kvaliteten på etikettene dine.
• Innlemme tidligere domenekunnskap når tilgjengelig - Vurder følgende:
  • Inndata på feilkilder – Domeneutøvere kan gi innsikt i feilkilder basert på mange års erfaring. De kan gi tilbakemelding om de beste fremgangsmåtene for de to foregående punktene: Hvilke innstillinger gjenspeiler den virkelige brukssaken best? Hva er de mulige kildene til variasjon under datainnsamling, eller på tidspunktet for bruk?
  • Domenespesifikke beste praksiser for datainnsamling – Selv om dine tekniske interessenter allerede har en god ide om de tekniske aspektene å fokusere på i bildene eller videoene som samles inn, kan domeneutøvere gi tilbakemelding på hvordan de best kan iscenesette eller samle inn dataene slik at disse behovene blir dekket.

Kvalitetskontroll og kvalitetssikring av opprettede data

Nå som du har satt opp datainnsamlingspipelinen, kan det være fristende å gå videre og samle inn så mye data som mulig. Vent litt! Vi må først sjekke om dataene som samles inn gjennom oppsettet er egnet for din brukssituasjon med ekte ord. Vi kan bruke noen innledende prøver og iterativt forbedre oppsettet gjennom innsikten vi fikk ved å analysere prøvedataene. Arbeid tett med dine tekniske, forretningsmessige og merknadsinteressenter under pilotprosessen. Dette vil sørge for at den resulterende pipeline oppfyller forretningsbehov samtidig som den genererer ML-klare merkede data med minimale kostnader.

Merknader

Annoteringen av innganger er der vi legger den magiske touchen til dataene våre – etikettene! Avhengig av oppgavetypen og dataopprettingsprosessen, kan det hende du trenger manuelle kommentatorer, eller du kan bruke automatiske metoder. Selve dataannoteringspipelinen kan være en teknisk utfordrende oppgave. Ground Truth forenkler denne reisen for dine tekniske interessenter med sin innebygd repertoar av merkearbeidsflyter for vanlige datakilder. Med noen få ekstra trinn lar den deg også bygge tilpassede arbeidsflyter for merking utover forhåndskonfigurerte alternativer.

Still deg selv følgende spørsmål når du utvikler en passende arbeidsflyt for kommentarer:

• Trenger jeg en manuell merknadsprosess for dataene mine? I noen tilfeller kan automatiserte merketjenester være tilstrekkelig for oppgaven. Gjennomgang av dokumentasjonen og tilgjengelige verktøy kan hjelpe deg med å identifisere om manuell merknad er nødvendig for brukssaken din (for mer informasjon, se Hva er datamerking?). Dataopprettingsprosessen kan tillate varierende nivåer av kontroll angående granulariteten til datakommentaren din. Avhengig av denne prosessen kan du også noen ganger omgå behovet for manuell merknad. For mer informasjon, se Bygg et tilpasset Q&A-datasett ved å bruke Amazon SageMaker Ground Truth for å trene en Hugging Face Q&A NLU-modell.
• Hva danner min grunnsannhet? I de fleste tilfeller vil den grunnleggende sannheten komme fra kommentarprosessen din – det er hele poenget! I andre kan brukeren ha tilgang til jordsannhetsetiketter. Dette kan øke hastigheten på kvalitetssikringsprosessen betraktelig, eller redusere kostnadene som kreves for flere manuelle merknader.
• Hva er den øvre grensen for mengden avvik fra min grunnsannhetstilstand? Samarbeid med sluttbrukerne dine for å forstå de typiske feilene rundt disse etikettene, kildene til slike feil og ønsket reduksjon i feil. Dette vil hjelpe deg med å identifisere hvilke aspekter av merkeoppgaven som er mest utfordrende eller sannsynligvis har merknadsfeil.
• Er det eksisterende regler brukt av brukere eller feltutøvere for å merke disse elementene? Bruk og avgrens disse retningslinjene for å lage et sett med instruksjoner for dine manuelle kommentatorer.

Piloter prosessen med inndatakommentarer

Når du piloterer prosessen med inndatakommentarer, bør du vurdere følgende:

• Gjennomgå instruksjonene med annotatorene og feltutøverne – Instruksjonene bør være kortfattede og spesifikke. Be om tilbakemelding fra brukerne dine (Er instruksjonene nøyaktige? Kan vi revidere noen instruksjoner for å sikre at de er forståelige av ikke-feltutøvere?) og annotatorer (Er alt forståelig? Er oppgaven klar?). Hvis mulig, legg til et eksempel på gode og dårlige merkede data for å hjelpe kommentatorene dine med å identifisere hva som forventes, og hvordan vanlige merkefeil kan se ut.
• Samle inn data for merknader – Se gjennom dataene med kunden din for å sikre at de oppfyller de forventede standardene, og for å tilpasse seg forventede resultater fra den manuelle merknaden.
• Gi eksempler til utvalget av manuelle kommentatorer som en testkjøring – Hva er den typiske variansen blant kommentatorene i dette settet med eksempler? Studer variansen for hver merknad i et gitt bilde for å identifisere konsistenstrendene blant kommentatorer. Sammenlign deretter variansene på tvers av bildene eller videorammene for å identifisere hvilke etiketter som er utfordrende å plassere.

Kvalitetskontroll av merknadene

Kvalitetskontroll av merknader har to hovedkomponenter: å vurdere konsistens mellom kommentatorene og å vurdere kvaliteten på selve merknadene.

Du kan tilordne flere annotatorer til samme oppgave (for eksempel tre annotatorer merker nøkkelpunktene på samme bilde), og måle gjennomsnittsverdien sammen med standardavviket til disse etikettene blant annotatorene. Dette hjelper deg med å identifisere avvikende merknader (feil etikett brukt, eller etikett langt unna den gjennomsnittlige merknaden), som kan veilede utfall som kan handles, for eksempel å avgrense instruksjonene eller gi ytterligere opplæring til enkelte annotatorer.

Vurdering av kvaliteten på selve merknadene er knyttet til annotatorvariabilitet og (når tilgjengelig) tilgjengeligheten av domeneeksperter eller grunnleggende sannhetsinformasjon. Er det visse etiketter (på tvers av alle bildene dine) der den gjennomsnittlige variansen mellom kommentatorer er konsekvent høy? Er noen etiketter langt unna dine forventninger om hvor de skal være, eller hvordan de skal se ut?

Basert på vår erfaring kan en typisk kvalitetskontrollløkke for datakommentarer se slik ut:

• Gjenta instruksjonene eller bildeoppsett basert på resultater fra testkjøringen – Er noen objekter okkludert, eller samsvarer ikke bildeoppsetningen forventningene til annotatorer eller brukere? Er instruksjonene villedende, eller savnet du noen etiketter eller vanlige feil i eksemplarbildene dine? Kan du avgrense instruksjonene for annotatorene dine?
• Hvis du er fornøyd med at du har løst noen problemer fra testkjøringen, gjør en bunke med merknader – For å teste resultatene fra batchen, følg den samme kvalitetsvurderingsmetoden for å vurdere variabiliteter mellom annotatorer og mellombilder.

konklusjonen

Dette innlegget fungerer som en guide for forretningsinteressenter for å forstå kompleksiteten ved dataskaping for AI/ML-applikasjoner. Prosessene som beskrives fungerer også som en veiledning for tekniske utøvere for å generere kvalitetsdata mens de optimerer forretningsbegrensninger som personell og kostnader. Hvis det ikke gjøres godt, kan en pipeline for dataoppretting og merking ta opptil 4–6 måneder.

Med retningslinjene og forslagene som er skissert i dette innlegget, kan du unngå veisperringer, redusere tiden til ferdigstillelse og minimere kostnadene i reisen din mot å lage data av høy kvalitet.

---

Om forfatterne

Jasleen Grewal er en Applied Scientist ved Amazon Web Services, hvor hun jobber med AWS-kunder for å løse virkelige problemer ved hjelp av maskinlæring, med spesielt fokus på presisjonsmedisin og genomikk. Hun har en sterk bakgrunn innen bioinformatikk, onkologi og klinisk genomikk. Hun brenner for å bruke AI/ML og skytjenester for å forbedre pasientbehandlingen.

Boris Aronchik er leder i Amazon AI Machine Learning Solutions Lab, hvor han leder et team av ML-forskere og ingeniører for å hjelpe AWS-kunder med å realisere forretningsmål ved å utnytte AI/ML-løsninger.

Miguel Romero Calvo er en anvendt vitenskapsmann ved Amazon ML Solutions Lab hvor han samarbeider med AWS interne team og strategiske kunder for å akselerere virksomheten deres gjennom ML og skyadopsjon.

Lin Lee Cheong er seniorforsker og leder med Amazon ML Solutions Lab-teamet hos Amazon Web Services. Hun jobber med strategiske AWS-kunder for å utforske og bruke kunstig intelligens og maskinlæring for å oppdage ny innsikt og løse komplekse problemer.