Amazon Comprehend kunngjør lavere merknadsgrenser for egendefinert enhetsgjenkjenning

Amazon Comprehend er en NLP-tjeneste (natural-language processing) du kan bruke til å automatisk trekke ut enheter, nøkkelfraser, språk, følelser og annen innsikt fra dokumenter. For eksempel kan du umiddelbart begynne å oppdage enheter som personer, steder, kommersielle varer, datoer og mengder via Amazon Comprehend-konsoll, AWS kommandolinjegrensesnitteller Amazon Comprehend APIer. I tillegg, hvis du trenger å trekke ut enheter som ikke er en del av Amazon Forstå innebygde enhetstyper, kan du opprette en egendefinert enhetsgjenkjenningsmodell (også kjent som tilpasset enhet gjenkjenner) for å trekke ut termer som er mer relevante for ditt spesifikke bruksområde, som navn på varer fra en produktkatalog, domenespesifikke identifikatorer og så videre. Å lage en nøyaktig enhetsgjenkjenner på egen hånd ved å bruke maskinlæringsbiblioteker og rammeverk kan være en kompleks og tidkrevende prosess. Amazon Comprehend forenkler modelltreningsarbeidet ditt betraktelig. Alt du trenger å gjøre er å laste inn datasettet med dokumenter og merknader, og bruke Amazon Comprehend-konsollen, AWS CLI eller API-er for å lage modellen.

For å trene en tilpasset enhetsgjenkjenner, kan du gi opplæringsdata til Amazon Comprehend as merknader eller enhetslister. I det første tilfellet gir du en samling av dokumenter og en fil med merknader som spesifiserer plasseringen der enheter forekommer i settet med dokumenter. Alternativt, med enhetslister, gir du en liste over enheter med deres tilsvarende enhetstypeetikett, og et sett med uannoterte dokumenter der du forventer at enhetene dine skal være til stede. Begge tilnærmingene kan brukes til å trene en vellykket tilpasset enhetsgjenkjenningsmodell; Det er imidlertid situasjoner der én metode kan være et bedre valg. For eksempel, når betydningen av spesifikke enheter kan være tvetydig og kontekstavhengig, anbefales det å gi merknader fordi dette kan hjelpe deg med å lage en Amazon Comprehend-modell som er i stand til bedre å bruke kontekst når du trekker ut enheter.

Å kommentere dokumenter kan kreve ganske mye innsats og tid, spesielt hvis du vurderer at både kvaliteten og kvantiteten av merknader har en innvirkning på den resulterende enhetsgjenkjenningsmodellen. Upresise eller for få merknader kan føre til dårlige resultater. For å hjelpe deg med å sette opp en prosess for innhenting av merknader, tilbyr vi verktøy som f.eks Amazon SageMaker Ground Truth, som du kan bruke til å kommentere dokumentene dine raskere og generere en utvidet manifestkommentarfil. Men selv om du bruker Ground Truth, må du fortsatt sørge for at treningsdatasettet ditt er stort nok til å bygge entitetsgjenkjenneren din.

Inntil i dag, for å begynne å trene en Amazon Comprehend-tilpasset enhetsgjenkjenner, måtte du gi en samling på minst 250 dokumenter og minimum 100 merknader per enhetstype. I dag kunngjør vi at vi, takket være nylige forbedringer i modellene som ligger til grunn for Amazon Comprehend, har redusert minimumskravene for opplæring av en gjenkjenner med CSV-kommentarfiler i ren tekst. Du kan nå bygge en egendefinert enhetsgjenkjenningsmodell med så få som tre dokumenter og 25 merknader per enhetstype. Du kan finne mer informasjon om nye tjenestegrenser i Retningslinjer og kvoter.

For å vise frem hvordan denne reduksjonen kan hjelpe deg med å komme i gang med å lage en egendefinert enhetsgjenkjenner, kjørte vi noen tester på noen få åpen kildekode-datasett og samlet inn ytelsesberegninger. I dette innlegget leder vi deg gjennom benchmarking-prosessen og resultatene vi oppnådde mens vi jobbet med delutvalgte datasett.

Datasett klargjøring

I dette innlegget forklarer vi hvordan vi trente en Amazon Comprehend-tilpasset enhetsgjenkjenner ved å bruke kommenterte dokumenter. Generelt kan merknader gis som en CSV-fil, En utvidet manifestfil generert av Ground TruthEller en PDF-fil. Vårt fokus er på CSV-klartekstkommentarer, fordi dette er typen merknader som påvirkes av de nye minimumskravene. CSV-filer skal ha følgende struktur:

File, Line, Begin Offset, End Offset, Type
documents.txt, 0, 0, 13, ENTITY_TYPE_1
documents.txt, 1, 0, 7, ENTITY_TYPE_2

De relevante feltene er som følger:

• filet – Navnet på filen som inneholder dokumentene
• linje – Nummeret på linjen som inneholder enheten, som starter med linje 0
• Begynn Offset – Tegnforskyvningen i inndatateksten (i forhold til begynnelsen av linjen) som viser hvor enheten begynner, tatt i betraktning at det første tegnet er på posisjon 0
• Sluttforskyvning – Tegnforskyvningen i inndatateksten som viser hvor enheten slutter
• typen – Navnet på enhetstypen du vil definere

I tillegg, når du bruker denne tilnærmingen, må du gi en samling opplæringsdokumenter som .txt-filer med ett dokument per linje, eller ett dokument per fil.

For våre tester brukte vi SNIPS benchmark for naturlig språkforståelse, et datasett med crowdsourcede ytringer fordelt på syv brukerhensikter (AddToPlaylist, BookRestaurant, GetWeather, PlayMusic, RateBook, SearchCreativeWork, SearchScreeningEvent). Datasettet ble publisert i 2018 i sammenheng med oppgaven Snips Voice Platform: et innebygd talespråkforståelsessystem for private-by-design stemmegrensesnitt av Coucke, et al.

SNIPS-datasettet er laget av en samling JSON-filer som kondenserer både merknader og råtekstfiler. Følgende er et utdrag fra datasettet:

{
   "annotations":{
      "named_entity":[
         {
            "start":16,
            "end":36,
            "extent":"within the same area",
            "tag":"spatial_relation"
         },
         {
            "start":40,
            "end":51,
            "extent":"Lawrence St",
            "tag":"poi"
         },
         {
            "start":67,
            "end":70,
            "extent":"one",
            "tag":"party_size_number"
         }
      ],
      "intent":"BookRestaurant"
   },
   "raw_text":"I'd like to eat within the same area of Lawrence St for a party of one"
}

Før vi opprettet enhetsgjenkjenneren vår, transformerte vi SNIPS-kommentarene og råtekstfilene til en CSV-kommentarfil og en .txt-dokumentfil.

Følgende er et utdrag fra vår annotations.csv file:

File, Line, Begin Offset, End Offset, Type
documents.txt, 0, 16, 36, spatial_relation
documents.txt, 0, 40, 51, poi
documents.txt, 0, 67, 70, party_size_number

Følgende er et utdrag fra vår documents.txt file:

I'd like to eat within the same area of Lawrence St for a party of one
Please book me a table for three at an american gastropub 
I would like to book a restaurant in Niagara Falls for 8 on June nineteenth
Can you book a table for a party of 6 close to DeKalb Av

Sampling konfigurasjon og benchmarking prosess

For eksperimentene våre fokuserte vi på et undersett av enhetstyper fra SNIPS-datasettet:

• Bokrestaurant – Enhetstyper: spatial_relation, poi, party_size_number, restaurant_name, city, timeRange, restaurant_type, served_dish, party_size_description, country, facility, state, sort, cuisine
• GetWeather – Enhetstyper: condition_temperature, current_location, geographic_poi, timeRange, state, spatial_relation, condition_description, city, country
• Spille musikk – Enhetstyper: track, artist, music_item, service, genre, sort, playlist, album, year

Dessuten subsamplet vi hvert datasett for å få forskjellige konfigurasjoner når det gjelder antall dokumenter samplet for opplæring og antall merknader per enhet (også kjent som skudd). Dette ble gjort ved å bruke et tilpasset skript designet for å lage delsamplede datasett der hver enhetstype vises minst k ganger, innen et minimum av n dokumenter.

Hver modell ble trent ved å bruke en spesifikk delprøve av opplæringsdatasettene; de ni modellkonfigurasjonene er illustrert i følgende tabell.

For å måle nøyaktigheten til modellene våre har vi samlet inn evalueringsberegninger som Amazon Comprehend automatisk beregner når de trener en enhetsgjenkjenner:

• Precision – Dette indikerer andelen av enheter oppdaget av gjenkjenneren som er korrekt identifisert og merket. Fra et annet perspektiv kan presisjon defineres som tp / (tp + fp), Hvor tp er antall sanne positive (korrekte identifikasjoner) og fp er antall falske positiver (feil identifikasjon).
• Husker – Dette indikerer andelen av enhetene i dokumentene som er korrekt identifisert og merket. Det er beregnet som tp / (tp + fn), Hvor tp er antall sanne positive og fn er antall falske negativer (glippede identifikasjoner).
• F1-poengsum – Dette er en kombinasjon av presisjons- og gjenkallingsmålinger, som måler den generelle nøyaktigheten til modellen. F1-poengsummen er det harmoniske gjennomsnittet av presisjons- og gjenkallingsmålingene, og beregnes som 2 * Presisjon * Tilbakekalling / (Presisjon + tilbakekalling).

For å sammenligne ytelsen til våre enhetsgjenkjennere fokuserer vi på F1-score.

Med tanke på at du, gitt et datasett og en underprøvestørrelse (i form av antall dokumenter og bilder), kan generere forskjellige underprøver, genererte vi 10 underprøver for hver av de ni konfigurasjonene, trente enhetsgjenkjenningsmodellene, samlet inn ytelsesmålinger, og gjennomsnitt dem ved hjelp av mikro-gjennomsnitt. Dette tillot oss å få mer stabile resultater, spesielt for underprøver med få skudd.

Resultater

Følgende tabell viser mikro-gjennomsnittet F1-poengsum beregnet på ytelsesmålinger returnert av Amazon Comprehend etter opplæring av hver enhetsgjenkjenner.

Følgende kolonnediagram viser fordelingen av F1-poengsum for de ni konfigurasjonene vi trente som beskrevet i forrige seksjon.

Vi kan observere at vi klarte å trene tilpassede enhetsgjenkjenningsmodeller selv med så få som 25 merknader per enhetstype. Hvis vi fokuserer på de tre minste subsampled datasettene (snips-BookRestaurant-subsample-A, snips-GetWeather-subsample-Aog snips-PlayMusic-subsample-A), ser vi at vi i gjennomsnitt klarte å oppnå en F1-score på 84 %, noe som er et ganske bra resultat tatt i betraktning det begrensede antallet dokumenter og merknader vi brukte. Hvis vi ønsker å forbedre ytelsen til modellen vår, kan vi samle inn flere dokumenter og merknader og trene en ny modell med mer data. For eksempel med middels store delprøver (snips-BookRestaurant-subsample-B, snips-GetWeather-subsample-Bog snips-PlayMusic-subsample-B), som inneholder dobbelt så mange dokumenter og merknader, oppnådde vi i gjennomsnitt en F1-score på 88 % (5 % forbedring mht. subsample-A datasett). Til slutt, større delutvalgte datasett (snips-BookRestaurant-subsample-C, snips-GetWeather-subsample-Cog snips-PlayMusic-subsample-C), som inneholder enda flere kommenterte data (omtrent fire ganger antallet dokumenter og merknader som brukes til subsample-A datasett), ga ytterligere 2 % forbedring, noe som økte den gjennomsnittlige F1-poengsummen til 90 %.

konklusjonen

I dette innlegget kunngjorde vi en reduksjon av minimumskravene for opplæring av en egendefinert enhetsgjenkjenner med Amazon Comprehend, og kjørte noen benchmarks på åpen kildekode-datasett for å vise hvordan denne reduksjonen kan hjelpe deg i gang. Fra og med i dag kan du opprette en enhetsgjenkjenningsmodell med så få som 25 merknader per enhetstype (i stedet for 100), og minst tre dokumenter (i stedet for 250). Med denne kunngjøringen senker vi adgangsbarrieren for brukere som er interessert i å bruke Amazon Comprehend tilpasset enhetsgjenkjenningsteknologi. Du kan nå begynne å kjøre eksperimentene dine med en veldig liten samling av kommenterte dokumenter, analysere foreløpige resultater og gjenta ved å inkludere flere merknader og dokumenter hvis du trenger en mer nøyaktig enhetsgjenkjenningsmodell for din brukssituasjon.

For å lære mer og komme i gang med en tilpasset enhetsgjenkjenner, se Anerkjennelse av tilpasset enhet.

Spesiell takk til mine kolleger Jyoti Bansal og Jie Ma for deres verdifulle hjelp med dataforberedelse og benchmarking.

Om forfatteren

Luca Guida er løsningsarkitekt hos AWS; han er basert i Milano og støtter italienske ISV-er i deres skyreise. Med en akademisk bakgrunn innen informatikk og ingeniørfag begynte han å utvikle sin AI/ML lidenskap på universitetet. Som medlem av NLP-fellesskapet (natural language processing) i AWS, hjelper Luca kundene med å lykkes mens de tar i bruk AI/ML-tjenester.