Amazon Comprehend tillkännager lägre anteckningsgränser för anpassad enhetsigenkänning

Amazon Comprehend är en NLP-tjänst (natural-language processing) som du kan använda för att automatiskt extrahera enheter, nyckelfraser, språk, känslor och andra insikter från dokument. Du kan till exempel omedelbart börja upptäcka enheter som personer, platser, kommersiella föremål, datum och kvantiteter via Amazon Comprehend-konsol, AWS-kommandoradsgränssnitt, eller Amazon Comprehend API: er. Dessutom, om du behöver extrahera enheter som inte är en del av Amazon Förstå inbyggda entitetstyper, kan du skapa en anpassad enhetsigenkänningsmodell (även känd som anpassad enhet igenkännare) för att extrahera termer som är mer relevanta för ditt specifika användningsfall, som namn på objekt från en produktkatalog, domänspecifika identifierare och så vidare. Att skapa en korrekt enhetsidentifierare på egen hand med hjälp av maskininlärningsbibliotek och ramverk kan vara en komplex och tidskrävande process. Amazon Comprehend förenklar ditt modellträningsarbete avsevärt. Allt du behöver göra är att ladda din datauppsättning med dokument och kommentarer och använda Amazon Comprehend-konsolen, AWS CLI eller API:er för att skapa modellen.

För att träna en anpassad enhetsidentifierare kan du tillhandahålla träningsdata till Amazon Comprehend as anteckningar eller entitetslistor. I det första fallet tillhandahåller du en samling dokument och en fil med anteckningar som anger platsen där enheter förekommer inom dokumentuppsättningen. Alternativt, med entitetslistor, tillhandahåller du en lista över entiteter med deras motsvarande enhetstypetikett och en uppsättning dokument utan anteckningar där du förväntar dig att dina entiteter ska finnas. Båda metoderna kan användas för att träna en framgångsrik anpassad enhetsigenkänningsmodell; Det finns dock situationer där en metod kan vara ett bättre val. Till exempel, när innebörden av specifika entiteter kan vara tvetydig och kontextberoende, rekommenderas att tillhandahålla annoteringar eftersom detta kan hjälpa dig att skapa en Amazon Comprehend-modell som bättre kan använda kontext när du extraherar entiteter.

Att kommentera dokument kan kräva ganska mycket ansträngning och tid, särskilt om du anser att både kvaliteten och kvantiteten av anteckningar har en inverkan på den resulterande enhetens erkännandemodell. Oprecisa eller för få anteckningar kan leda till dåliga resultat. För att hjälpa dig att sätta upp en process för att skaffa annoteringar tillhandahåller vi verktyg som t.ex Amazon SageMaker Ground Sannhet, som du kan använda för att kommentera dina dokument snabbare och generera en utökad manifestanteckningsfil. Men även om du använder Ground Truth måste du fortfarande se till att din träningsdatauppsättning är tillräckligt stor för att framgångsrikt bygga din enhetsidentifierare.

Fram till idag, för att börja utbilda en anpassad enhetsidentifierare från Amazon Comprehend, var du tvungen att tillhandahålla en samling på minst 250 dokument och minst 100 anteckningar per enhetstyp. Idag tillkännager vi att vi, tack vare de senaste förbättringarna i modellerna bakom Amazon Comprehend, har minskat minimikraven för att utbilda en igenkännare med CSV-anteckningsfiler i vanlig text. Du kan nu bygga en anpassad enhetsigenkänningsmodell med så få som tre dokument och 25 anteckningar per enhetstyp. Du kan hitta mer information om nya servicegränser i Riktlinjer och kvoter.

För att visa upp hur den här minskningen kan hjälpa dig att komma igång med skapandet av en anpassad enhetsidentifierare, körde vi några tester på några datauppsättningar med öppen källkod och samlade in prestandastatistik. I det här inlägget går vi igenom benchmarkingprocessen och resultaten vi fick när vi arbetade med delsamplade datamängder.

Dataset förberedelse

I det här inlägget förklarar vi hur vi tränade en anpassad enhetsidentifierare från Amazon Comprehend med hjälp av kommenterade dokument. I allmänhet kan anteckningar tillhandahållas som en CSV-fil, En utökad manifestfil genererad av Ground Truth, Eller en PDF-fil. Vårt fokus ligger på CSV-anteckningar i klartext, eftersom det är den typen av anteckningar som påverkas av de nya minimikraven. CSV-filer bör ha följande 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 relevanta fälten är följande:

• Fil – Namnet på filen som innehåller dokumenten
• linje – Numret på raden som innehåller entiteten, som börjar med rad 0
• Börjar Kompensera – Teckenförskjutningen i inmatningstexten (relativt början av raden) som visar var enheten börjar, med tanke på att det första tecknet är på position 0
• Slutförskjutning – Teckenförskjutningen i inmatningstexten som visar var enheten slutar
• Typ – Namnet på den enhetstyp som du vill definiera

När du använder detta tillvägagångssätt måste du dessutom tillhandahålla en samling utbildningsdokument som .txt-filer med ett dokument per rad eller ett dokument per fil.

För våra tester använde vi SNIPS Natural Language Understanding benchmark, en datauppsättning med crowdsourcade yttranden fördelade på sju användaravsikter (AddToPlaylist, BookRestaurant, GetWeather, PlayMusic, RateBook, SearchCreativeWork, SearchScreeningEvent). Datauppsättningen publicerades 2018 i samband med uppsatsen Snips Voice Platform: ett inbyggt talat språkförståelsesystem för privata designade röstgränssnitt av Coucke, et al.

SNIPS-datauppsättningen är gjord av en samling JSON-filer som kondenserar både anteckningar och råtextfiler. Följande är ett utdrag från datamängden:

{
   "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"
}

Innan vi skapade vår enhetsidentifierare omvandlade vi SNIPS-annoteringarna och råtextfilerna till en CSV-anteckningsfil och en .txt-dokumentfil.

Följande är ett utdrag ur vår annotations.csv fil:

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öljande är ett utdrag ur vår documents.txt fil:

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

Samplingskonfiguration och benchmarkingprocess

För våra experiment fokuserade vi på en undergrupp av entitetstyper från SNIPS-datauppsättningen:

• Bokrestaurang – 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
• Spela musik – Enhetstyper: track, artist, music_item, service, genre, sort, playlist, album, year

Dessutom subsamplade vi varje datamängd för att få olika konfigurationer vad gäller antal dokument som samplats för utbildning och antal kommentarer per enhet (även känd som skott). Detta gjordes genom att använda ett anpassat skript designat för att skapa delsamplade datamängder där varje enhetstyp förekommer minst k gånger, inom ett minimum av n dokument.

Varje modell tränades med hjälp av ett specifikt delprov av träningsdatauppsättningarna; de nio modellkonfigurationerna illustreras i följande tabell.

För att mäta noggrannheten i våra modeller har vi samlat in utvärderingsmått som Amazon Comprehend automatiskt beräknar när man tränar en enhetsidentifierare:

• Precision – Detta indikerar andelen enheter som identifieras av igenkännaren som är korrekt identifierade och märkta. Ur ett annat perspektiv kan precision definieras som tp / (tp + fp)Där tp är antalet sanna positiva (korrekta identifieringar) och fp är antalet falska positiva (felaktiga identifieringar).
• Recall – Detta anger andelen enheter som finns i dokumenten som är korrekt identifierade och märkta. Det är beräknat som tp / (tp + fn)Där tp är antalet sanna positiva och fn är antalet falska negativ (missade identifieringar).
• F1-poäng – Det här är en kombination av precisions- och återkallningsmått, som mäter modellens övergripande noggrannhet. F1-poängen är det harmoniska medelvärdet av precisions- och återkallningsmåtten och beräknas som 2 * Precision * Recall / (Precision + Recall).

För att jämföra prestandan för våra enhetsidentifierare fokuserar vi på F1-poäng.

Med tanke på att du, givet en datauppsättning och en delsamplingsstorlek (i termer av antal dokument och bilder), kan generera olika delprov, genererade vi 10 delprov för var och en av de nio konfigurationerna, tränade enhetsigenkänningsmodellerna, samlade in prestandamått och medelvärde för dem med hjälp av mikrogenomsnitt. Detta gjorde det möjligt för oss att få mer stabila resultat, särskilt för delprover med få skott.

Resultat

Följande tabell visar de mikrogenomsnittliga F1-poängen beräknade på prestationsstatistik som returneras av Amazon Comprehend efter att ha tränat varje enhetsidentifierare.

Följande kolumndiagram visar fördelningen av F1-poäng för de nio konfigurationer vi tränade enligt beskrivningen i föregående avsnitt.

Vi kan observera att vi framgångsrikt kunde träna anpassade enhetsigenkänningsmodeller även med så få som 25 kommentarer per enhetstyp. Om vi ​​fokuserar på de tre minsta delsamplade datamängderna (snips-BookRestaurant-subsample-A, snips-GetWeather-subsample-Aoch snips-PlayMusic-subsample-A), ser vi att vi i genomsnitt kunde uppnå en F1-poäng på 84 %, vilket är ett ganska bra resultat med tanke på det begränsade antalet dokument och kommentarer vi använde. Om vi ​​vill förbättra prestandan för vår modell kan vi samla in ytterligare dokument och kommentarer och träna en ny modell med mer data. Till exempel med medelstora delprover (snips-BookRestaurant-subsample-B, snips-GetWeather-subsample-Boch snips-PlayMusic-subsample-B), som innehåller dubbelt så många dokument och kommentarer, fick vi i genomsnitt ett F1-poäng på 88 % (5 % förbättring med avseende på subsample-A datauppsättningar). Slutligen, större delsamplade datamängder (snips-BookRestaurant-subsample-C, snips-GetWeather-subsample-Coch snips-PlayMusic-subsample-C), som innehåller ännu mer kommenterade data (ungefär fyra gånger antalet dokument och kommentarer som används för subsample-A datauppsättningar), gav ytterligare 2 % förbättring, vilket höjde den genomsnittliga F1-poängen till 90 %.

Slutsats

I det här inlägget tillkännagav vi en minskning av minimikraven för att utbilda en anpassad enhetsidentifierare med Amazon Comprehend, och körde några riktmärken på datauppsättningar med öppen källkod för att visa hur denna minskning kan hjälpa dig att komma igång. Från och med idag kan du skapa en enhetsigenkänningsmodell med så få som 25 kommentarer per enhetstyp (istället för 100) och minst tre dokument (istället för 250). Med detta tillkännagivande sänker vi inträdesbarriären för användare som är intresserade av att använda Amazon Comprehends anpassade teknologi för enhetsigenkänning. Du kan nu börja köra dina experiment med en mycket liten samling av kommenterade dokument, analysera preliminära resultat och iterera genom att inkludera ytterligare kommentarer och dokument om du behöver en mer exakt enhetsigenkänningsmodell för ditt användningsfall.

För att lära dig mer och komma igång med en anpassad enhetsidentifierare, se Anpassning av anpassad enhet.

Ett särskilt tack till mina kollegor Jyoti Bansal och Jie Ma för deras värdefulla hjälp med dataförberedelse och benchmarking.

Om författaren

Luca Guida är en lösningsarkitekt på AWS; han är baserad i Milano och stödjer italienska ISV:er i deras molnresa. Med en akademisk bakgrund inom datavetenskap och teknik började han utveckla sin AI/ML-passion på universitetet. Som medlem av NLP-gemenskapen (natural language processing) inom AWS hjälper Luca kunder att bli framgångsrika samtidigt som de använder AI/ML-tjänster.