Intelligent dokumentbehandling med AWS AI-tjenester: Del 2

Amazons intelligente dokumentbehandling (IDP) hjelper deg å fremskynde forretningsbeslutningssyklusene dine og redusere kostnadene. På tvers av flere bransjer må kunder behandle millioner av dokumenter per år i løpet av virksomheten. For kunder som behandler millioner av dokumenter, er dette et kritisk aspekt for sluttbrukeropplevelsen og en toppprioritet for digital transformasjon. På grunn av de varierte formatene behandler de fleste firmaer manuelt dokumenter som W2-er, krav, ID-dokumenter, fakturaer og juridiske kontrakter, eller bruker eldre OCR-løsninger (optisk tegngjenkjenning) som er tidkrevende, feilutsatte og kostbare. En IDP-pipeline med AWS AI-tjenester gir deg mulighet til å gå utover OCR med mer nøyaktig og allsidig informasjonsutvinning, behandle dokumenter raskere, spare penger og flytte ressurser til oppgaver med høyere verdi.

I denne serien gir vi en oversikt over IDP-rørledningen for å redusere tiden og kreftene det tar å innta et dokument og få nøkkelinformasjonen inn i nedstrømssystemer. Følgende figur viser stadiene som vanligvis er en del av en IDP-arbeidsflyt.

I denne todelte serien diskuterer vi hvordan du kan automatisere og intelligent behandle dokumenter i stor skala ved hjelp av AWS AI-tjenester. I del 1, diskuterte vi de tre første fasene av IDP-arbeidsflyten. I dette innlegget diskuterer vi de gjenværende arbeidsflytfasene.

Løsningsoversikt

Følgende referansearkitektur viser hvordan du kan bruke AWS AI-tjenester som amazontekst og Amazon Comprehend, sammen med andre AWS-tjenester for å implementere IDP-arbeidsflyten. I del 1 beskrev vi datafangst- og dokumentklassifiseringsstadiene, der vi kategoriserte og merket dokumenter som kontoutskrifter, fakturaer og kvitteringsdokumenter. Vi diskuterte også utvinningsstadiet, hvor du kan trekke ut meningsfull forretningsinformasjon fra dokumentene dine. I dette innlegget utvider vi IDP-pipelinen ved å se på Amazon Comprehend standard- og tilpassede enheter i utvinningsfasen, utføre dokumentanriking, og også kort se på mulighetene til Amazon Augmented AI (Amazon A2I) for å inkludere en menneskelig gjennomgangsarbeider i gjennomgangs- og valideringsstadiet.

Vi bruker også Amazon Comprehend Medical som en del av denne løsningen, som er en tjeneste for å trekke ut informasjon fra ustrukturert medisinsk tekst nøyaktig og raskt og identifisere forhold mellom utvunnet helseinformasjon, og lenke til medisinske ontologier som ICD-10-CM, RxNorm og SNOMED CT.

Amazon A2I er en maskinlæringstjeneste (ML) som gjør det enkelt å bygge arbeidsflytene som kreves for menneskelig vurdering. Amazon A2I bringer menneskelig vurdering til alle utviklere, fjerner de udifferensierte tunge løftene knyttet til å bygge menneskelige vurderingssystemer eller administrerer et stort antall menneskelige anmeldere, enten det kjører på AWS eller ikke. Amazon A2I integreres med amazontekst og Amazon Comprehend for å gi deg muligheten til å introdusere menneskelige gjennomgangstrinn i din IDP-arbeidsflyt.

Forutsetninger

Før du setter i gang, se del 1 for en oversikt på høyt nivå over IDP og detaljer om datafangst, klassifisering og utvinningsstadier.

Utvinningsfase

I del 1 av denne serien diskuterte vi hvordan vi kan bruke Amazon Textract-funksjoner for nøyaktig datautvinning for alle typer dokumenter. For å forlenge denne fasen bruker vi Amazon Comprehend forhåndsopplærte enheter og en Amazon Comprehend tilpasset enhetsgjenkjenner for ytterligere dokumentutvinning. Hensikten med den tilpassede enhetsgjenkjenneren er å identifisere spesifikke enheter og generere tilpassede metadata om dokumentene våre i CSV- eller menneskelest format for senere å bli analysert av forretningsbrukerne.

Navngitt enhetsgjenkjenning

Named entity recognition (NER) er en underoppgave for naturlig språkbehandling (NLP) som involverer å sile gjennom tekstdata for å finne substantivfraser, kalt navngitte enheter, og kategorisere hver med en etikett, for eksempel merke, dato, hendelse, plassering, organisasjoner , person, mengde eller tittel. For eksempel, i uttalelsen "Jeg abonnerte nylig på Amazon Prime," er Amazon Prime den navngitte enheten og kan kategoriseres som en merkevare.

Amazon Comprehend lar deg oppdage slike tilpassede enheter i dokumentet ditt. Hver enhet har også en poengsum på konfidensnivå som Amazon Comprehend returnerer for hver enhetstype. Følgende diagram illustrerer prosessen for enhetsgjenkjenning.

For å hente entiteter fra tekstdokumentet kaller vi comprehend.detect_entities() metode og konfigurer språkkoden og teksten som inndataparametere:

def get_entities(text):
    try:
        #detect entities
        entities = comprehend.detect_entities(LanguageCode="en", Text=text)  
        df = pd.DataFrame(entities["Entities"], columns = ['Text', 'Type'])
        display(HTML(df.to_html(index=False)))
    except Exception as e:
        print(e)

Vi driver get_entities() metode på bankdokumentet og få enhetslisten i resultatene.

Selv om enhetsutvinning fungerte ganske bra for å identifisere standard enhetstyper for alt i bankdokumentet, ønsker vi at spesifikke enheter skal gjenkjennes for vårt brukstilfelle. Mer spesifikt må vi identifisere kundens spare- og kontrollkontonummer i kontoutskriften. Vi kan trekke ut disse viktige forretningsvilkårene ved å bruke Amazon Comprehend tilpasset enhetsgjenkjenning.

Tren opp en Amazon Comprehend tilpasset enhetsgjenkjenningsmodell

For å oppdage de spesifikke enhetene vi er interessert i fra kundens kontoutskrift, trener vi en egendefinert enhetsgjenkjenner med to egendefinerte enheter: SAVINGS_AC og CHECKING_AC.

Deretter trener vi en tilpasset enhetsgjenkjenningsmodell. Vi kan velge en av to måter å gi data til Amazon Comprehend: merknader eller enhetslister.

Annoteringsmetoden kan ofte føre til mer raffinerte resultater for bildefiler, PDF-er eller Word-dokumenter fordi du trener en modell ved å sende inn mer nøyaktig kontekst som merknader sammen med dokumentene dine. Merknadsmetoden kan imidlertid være tidkrevende og arbeidskrevende. For å gjøre dette blogginnlegget enkelt, bruker vi metoden for enhetslister, som du kun kan bruke for vanlige tekstdokumenter. Denne metoden gir oss en CSV-fil som skal inneholde ren tekst og dens tilsvarende enhetstype, som vist i det foregående eksempelet. Enhetene i denne filen kommer til å være spesifikke for våre forretningsbehov (sparing og kontrollkontonumre).

For mer informasjon om hvordan du forbereder treningsdataene for ulike brukstilfeller ved bruk av merknader eller entitetslister metoder, se Forberedelse av treningsdata.

Følgende skjermbilde viser et eksempel på enhetslisten vår.

Lag et Amazon Comprehend-tilpasset NER-endepunkt i sanntid

Deretter oppretter vi et egendefinert enhetsgjenkjenner sanntidsendepunkt ved å bruke modellen vi trente. Vi bruker Opprett endepunkt API via comprehend.create_endpoint() metode for å lage sanntidsendepunktet:

#create comprehend endpoint
model_arn = entity_recognizer_arn
ep_name = 'idp-er-endpoint'

try:
    endpoint_response = comprehend.create_endpoint(
        EndpointName=ep_name,
        ModelArn=model_arn,
        DesiredInferenceUnits=1,    
        DataAccessRoleArn=role
    )
    ER_ENDPOINT_ARN=endpoint_response['EndpointArn']
    print(f'Endpoint created with ARN: {ER_ENDPOINT_ARN}')
    %store ER_ENDPOINT_ARN
except Exception as error:
    if error.response['Error']['Code'] == 'ResourceInUseException':
        print(f'An endpoint with the name "{ep_name}" already exists.')
        ER_ENDPOINT_ARN = f'arn:aws:comprehend:{region}:{account_id}:entity-recognizer-endpoint/{ep_name}'
        print(f'The classifier endpoint ARN is: "{ER_ENDPOINT_ARN}"')
        %store ER_ENDPOINT_ARN
    else:
        print(error)

Etter at vi har trent opp en egendefinert enhetsgjenkjenner, bruker vi det egendefinerte sanntidsendepunktet til å trekke ut noe beriket informasjon fra dokumentet og deretter utføre dokumentredigering ved hjelp av de egendefinerte enhetene gjenkjent av Amazon Comprehend og avgrensningsboksinformasjon fra Amazon Textract.

Anrikningsfase

I dokumentanrikningsstadiet kan vi utføre dokumentanriking ved å redigere personlig identifiserbar informasjon (PII) data, tilpassede forretningstermer og så videre. Vårt forrige eksempeldokument (en kontoutskrift) inneholder kundenes spare- og brukskontonummer, som vi ønsker å redigere. Fordi vi allerede kjenner disse egendefinerte enhetene ved hjelp av vår Amazon Comprehend-tilpassede NER-modell, kan vi enkelt bruke Amazon Textract-geometridatatypen for å redigere disse PII-enhetene uansett hvor de vises i dokumentet. I den følgende arkitekturen redigerer vi sentrale forretningsvilkår (sparing og brukskonto) fra kontoutskriftsdokumentet.

Som du kan se i det følgende eksempelet, er sjekk- og sparekontonumrene skjult i kontoutskriften nå.

Tradisjonelle OCR-løsninger sliter med å trekke ut data nøyaktig fra de fleste ustrukturerte og semistrukturerte dokumenter på grunn av betydelige variasjoner i hvordan dataene er lagt ut på tvers av flere versjoner og formater av disse dokumentene. Du må kanskje implementere tilpasset forbehandlingslogikk eller til og med manuelt trekke ut informasjonen fra disse dokumentene. I dette tilfellet støtter IDP-rørledningen to funksjoner du kan bruke: Amazon Comprehend tilpassede NER- og Amazon Textract-spørringer. Begge disse tjenestene bruker NLP for å hente ut innsikt om innholdet i dokumenter.

Utvinning med Amazon Textract-spørringer

Når du behandler et dokument med Amazon Textract, kan du legge til den nye spørringsfunksjonen i analysen din for å spesifisere hvilken informasjon du trenger. Dette innebærer å sende et NLP-spørsmål, for eksempel "Hva er kundens personnummer?" til Amazon Textract. Amazon Textract finner informasjonen i dokumentet for det spørsmålet og returnerer den i en svarstruktur atskilt fra resten av dokumentets informasjon. Forespørsler kan behandles alene, eller i kombinasjon med andre FeatureType, Eksempel Tables or Forms.

Med Amazon Textract-spørringer kan du trekke ut informasjon med høy nøyaktighet uavhengig av hvordan dataene er lagt ut i en dokumentstruktur, for eksempel skjemaer, tabeller og avmerkingsbokser, eller plassert i nestede seksjoner i et dokument.

For å demonstrere søkefunksjonen trekker vi ut verdifull informasjon som pasientens for- og etternavn, doseringsprodusenten og så videre fra dokumenter som et COVID-19-vaksinasjonskort.

Vi bruker textract.analyze_document() funksjon og spesifiser FeatureType as QUERIES samt legge til spørringene i form av naturlig språkspørsmål i QueriesConfig.

Følgende kode er kuttet ned for forenklingsformål. For hele koden, se GitHub eksempelkode forum analyze_document().

response = None
with open(image_filename, 'rb') as document:
    imageBytes = bytearray(document.read())

# Call Textract
response = textract.analyze_document(
    Document={'Bytes': imageBytes},
    FeatureTypes=["QUERIES"],
    QueriesConfig={
            "Queries": [{
                "Text": "What is the date for the 1st dose covid-19?",
                "Alias": "COVID_VACCINATION_FIRST_DOSE_DATE"
            },
# code trimmed down for simplification
#..
]
}) 

For spørringsfunksjonen textract.analyze_document() funksjonen gir ut alle OCR-ORD og LINJER, geometriinformasjon og konfidenspoeng i responsen JSON. Vi kan imidlertid bare skrive ut informasjonen vi spurte etter.

Document er en innpakningsfunksjon som brukes til å analysere JSON-svaret fra APIen. Det gir en abstraksjon på høyt nivå og gjør API-utdataene iterable og enkle å få informasjon ut av. For mer informasjon, se Textract Response Parser og Teksttraktor GitHub-repos. Etter at vi har behandlet svaret, får vi følgende informasjon som vist på skjermbildet.

import trp.trp2 as t2
from tabulate import tabulate

d = t2.TDocumentSchema().load(response)
page = d.pages[0]

query_answers = d.get_query_answers(page=page)

print(tabulate(query_answers, tablefmt="github"))

Gjennomgang og valideringsfase

Dette er den siste fasen av vår IDP-pipeline. På dette stadiet kan vi bruke forretningsreglene våre til å sjekke om et dokument er fullstendig. For eksempel, fra et forsikringsskadedokument trekkes skade-ID-en ut nøyaktig og vellykket. Vi kan bruke AWS serverløse teknologier som f.eks AWS Lambda for ytterligere automatisering av disse forretningsreglene. Dessuten kan vi inkludere en menneskelig arbeidsstyrke for dokumentgjennomganger for å sikre at spådommene er nøyaktige. Amazon A2I akselererer byggearbeidsflyter som kreves for menneskelig gjennomgang for ML-spådommer.

Med Amazon A2I kan du tillate menneskelige anmeldere å trå til når en modell ikke er i stand til å lage en høykonfidensprediksjon eller revidere spådommene sine fortløpende. Målet med IDP-pipelinen er å redusere mengden menneskelig input som kreves for å få nøyaktig informasjon inn i beslutningssystemene dine. Med IDP kan du redusere mengden menneskelig input for dokumentprosessene dine, så vel som de totale kostnadene for dokumentbehandling.

Etter at du har hentet ut all den nøyaktige informasjonen fra dokumentene, kan du legge til forretningsspesifikke regler ved hjelp av Lambda-funksjoner og til slutt integrere løsningen med nedstrøms databaser eller applikasjoner.

For mer informasjon om hvordan du oppretter en Amazon A2I-arbeidsflyt, følg instruksjonene fra Forberedelse til modul 4 trinn på slutten av 03-idp-document-enrichment.ipynb i vår GitHub repo.

Rydd opp

For å forhindre fremtidige belastninger på AWS-kontoen din, slett ressursene som vi leverte i oppsettet av depotet ved å gå til Oppryddingsseksjon i vår repo.

konklusjonen

I dette todelte innlegget så vi hvordan man bygger en ende-til-ende IDP-pipeline med liten eller ingen ML-erfaring. Vi diskuterte de ulike stadiene av pipelinen og en praktisk løsning med AWS AI-tjenester som Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical og Amazon A2I for å designe og bygge bransjespesifikke brukstilfeller. I første innlegg av serien demonstrerte vi hvordan du bruker Amazon Textract og Amazon Comprehend for å trekke ut informasjon fra ulike dokumenter. I dette innlegget gjorde vi et dypdykk i hvordan man trener en Amazon Comprehend-tilpasset enhetsgjenkjenner til å trekke ut egendefinerte enheter fra dokumentene våre. Vi utførte også dokumentberikelsesteknikker som redaksjon ved hjelp av Amazon Textract samt enhetslisten fra Amazon Comprehend. Til slutt så vi hvordan du kan bruke en Amazon A2I arbeidsflyt for menneskelig gjennomgang for Amazon Textract ved å inkludere et privat arbeidsteam.

For mer informasjon om de fullstendige kodeeksemplene i dette innlegget, se GitHub repo.

Vi anbefaler at du går gjennom sikkerhetsdelene av amazontekst, Amazon Comprehendog Amazon A2I dokumentasjon og følg retningslinjene. Bruk også litt tid på å se gjennom og forstå prisene for amazontekst, Amazon Comprehendog Amazon A2I.

Om forfatterne

Chin Rane er en AI/ML-spesialistløsningsarkitekt hos Amazon Web Services. Hun brenner for anvendt matematikk og maskinlæring. Hun fokuserer på å designe intelligente dokumentbehandlingsløsninger for AWS-kunder. Utenom jobben liker hun salsa og bachata dans.

Sonali Sahu leder Intelligent Document Processing AI/ML Solutions Architect-teamet hos Amazon Web Services. Hun er en lidenskapelig teknofil og liker å jobbe med kunder for å løse komplekse problemer ved hjelp av innovasjon. Hennes kjernefokusområder er kunstig intelligens og maskinlæring for intelligent dokumentbehandling.

Anjan Biswas er en AI/ML-spesialist Senior Solutions Architect. Anjan jobber med bedriftskunder og brenner for å utvikle, distribuere og forklare AI/ML, dataanalyse og big data-løsninger. Anjan har over 14 års erfaring med å jobbe med globale forsyningskjeder, produksjons- og detaljhandelsorganisasjoner, og hjelper aktivt kunder med å komme i gang og skalere på AWS.

Suprakash Dutta er løsningsarkitekt hos Amazon Web Services. Han fokuserer på digital transformasjonsstrategi, applikasjonsmodernisering og migrering, dataanalyse og maskinlæring. Han er en del av AI/ML-fellesskapet hos AWS og designer intelligente dokumentbehandlingsløsninger.