Behandle boliglånsdokumenter med intelligent dokumentbehandling ved hjelp av Amazon Textract og Amazon Comprehend

Organisasjoner i utlåns- og boliglånsbransjen behandler tusenvis av dokumenter daglig. Fra en ny boliglånssøknad til refinansiering av boliglån involverer disse forretningsprosessene hundrevis av dokumenter per søknad. Det er begrenset automatisering tilgjengelig i dag for å behandle og trekke ut informasjon fra alle dokumentene, spesielt på grunn av varierende formater og oppsett. På grunn av det store antallet applikasjoner er det en tidkrevende, svært manuell, feilutsatt og kostbar prosess å fange strategisk innsikt og hente nøkkelinformasjon fra innholdet. Eldre verktøy for optisk tegngjenkjenning (OCR) er uoverkommelige, feilutsatte, involverer mye konfigurering og er vanskelige å skalere. Intelligent dokumentbehandling (IDP) med AWS-tjenester for kunstig intelligens (AI) hjelper med å automatisere og akselerere behandlingen av boliglånssøknaden med mål om raskere beslutninger av høy kvalitet, samtidig som de totale kostnadene reduseres.

I dette innlegget viser vi hvordan du kan bruke maskinlæringsfunksjoner (ML) med amazontekstog Amazon Comprehend å behandle dokumenter i ny boliglånssøknad, uten behov for ML-kompetanse. Vi utforsker de ulike fasene av IDP som vist i den følgende figuren, og hvordan de kobles til trinnene som er involvert i en søknadsprosess for boliglån, som for eksempel innsending av søknad, underwriting, verifisering og avslutning.

Selv om hver boliglånssøknad kan være unik, tok vi hensyn til noen av de vanligste dokumentene som er inkludert i en boliglånssøknad, for eksempel skjemaet Unified Residential Loan Application (URLA-1003), 1099-skjemaer og pantebrev.

Løsningsoversikt

Amazon Textract er en ML-tjeneste som automatisk trekker ut tekst, håndskrift og data fra skannede dokumenter ved å bruke forhåndsopplærte ML-modeller. Amazon Comprehend er en NLP-tjeneste (natural-language processing) som bruker ML til å avdekke verdifull innsikt og sammenhenger i tekst og kan utføre dokumentklassifisering, navnentitetsgjenkjenning (NER), emnemodellering og mer.

Følgende figur viser fasene til IDP når det gjelder fasene i en søknadsprosess for boliglån.

Ved starten av prosessen lastes dokumenter opp til en Amazon enkel lagringstjeneste (Amazon S3) bøtte. Dette setter i gang en dokumentklassifiseringsprosess for å kategorisere dokumentene i kjente kategorier. Etter at dokumentene er kategorisert, er neste trinn å trekke ut nøkkelinformasjon fra dem. Vi utfører deretter berikelse for utvalgte dokumenter, som kan være ting som redaksjonering av personlig identifiserbar informasjon (PII), dokumentmerking, metadataoppdateringer og mer. Det neste trinnet innebærer å validere dataene som er hentet ut i tidligere faser for å sikre fullstendigheten av en boliglånssøknad. Validering kan gjøres via forretningsvalideringsregler og valideringsregler på tvers av dokumenter. Konfidenspoengsummen til den utvunnede informasjonen kan også sammenlignes med en fastsatt terskel, og automatisk rutes til en menneskelig anmelder gjennom Amazon Augmented AI (Amazon A2I) hvis terskelen ikke er nådd. I den siste fasen av prosessen sendes de utpakkede og validerte dataene til nedstrømssystemer for videre lagring, prosessering eller dataanalyse.

I de følgende avsnittene diskuterer vi fasene av IDP når det gjelder fasene av en boliglånsøknad i detalj. Vi går gjennom fasene av IDP og diskuterer typer dokumenter; hvordan vi lagrer, klassifiserer og trekker ut informasjon, og hvordan vi beriker dokumentene ved hjelp av maskinlæring.

Dokumentlagring

Amazon S3 er en objektlagringstjeneste som tilbyr bransjeledende skalerbarhet, datatilgjengelighet, sikkerhet og ytelse. Vi bruker Amazon S3 for å trygt oppbevare boliglånsdokumentene under og etter søknadsprosessen for boliglån. EN søknadspakke for boliglån kan inneholde flere typer skjemaer og dokumenter, for eksempel URLA-1003, 1099-INT/DIV/RR/MISC, W2, lønnsslipper, kontoutskrifter, kredittkortutskrifter og mer. Disse dokumentene sendes inn av søkeren i pantesøknadsfasen. Uten manuelt å se gjennom dem, er det kanskje ikke umiddelbart klart hvilke dokumenter som er inkludert i pakken. Denne manuelle prosessen kan være tidkrevende og kostbar. I neste fase automatiserer vi denne prosessen ved å bruke Amazon Comprehend for å klassifisere dokumentene i deres respektive kategorier med høy nøyaktighet.

Dokumentklassifisering

Dokumentklassifisering er en metode som gjør at et stort antall uidentifiserte dokumenter kan kategoriseres og merkes. Vi utfører denne dokumentklassifiseringen ved å bruke en Amazon Comprehend tilpasset klassifiserer. En tilpasset klassifisering er en ML-modell som kan trenes med et sett med merkede dokumenter for å gjenkjenne klassene som er av interesse for deg. Etter at modellen er opplært og distribuert bak et vertsbasert endepunkt, kan vi bruke klassifikatoren til å bestemme kategorien (eller klassen) et bestemt dokument tilhører. I dette tilfellet trener vi en tilpasset klassifisering i flerklasse-modus, som kan gjøres enten med en CSV-fil eller en utvidet manifestfil. For formålet med denne demonstrasjonen bruker vi en CSV-fil for å trene klassifisereren. Se vår GitHub repository for hele kodeeksemplet. Følgende er en oversikt på høyt nivå over trinnene som er involvert:

1. Pakk ut UTF-8-kodet ren tekst fra bilde- eller PDF-filer ved å bruke Amazon Textract Oppdag Dokumenttekst API.
2. Forbered treningsdata for å trene en tilpasset klassifisering i CSV-format.
3. Tren opp en tilpasset klassifisering ved å bruke CSV-filen.
4. Distribuer den opplærte modellen med et endepunkt for sanntids dokumentklassifisering eller bruk multi-class-modus, som støtter både sanntids- og asynkrone operasjoner.

Følgende diagram illustrerer denne prosessen.

Du kan automatisere dokumentklassifisering ved å bruke det distribuerte endepunktet for å identifisere og kategorisere dokumenter. Denne automatiseringen er nyttig for å verifisere om alle de nødvendige dokumentene er til stede i en boliglånspakke. Et manglende dokument kan raskt identifiseres, uten manuell inngripen, og varsles til søkeren mye tidligere i prosessen.

Dokumentutvinning

I denne fasen trekker vi ut data fra dokumentet ved hjelp av Amazon Textract og Amazon Comprehend. For strukturerte og semistrukturerte dokumenter som inneholder skjemaer og tabeller, bruker vi Amazon Textract Analyser Dokument API. For spesialiserte dokumenter som ID-dokumenter, tilbyr Amazon Textract AnalyseID API. Noen dokumenter kan også inneholde tett tekst, og du må kanskje trekke ut forretningsspesifikke nøkkelord fra dem, også kjent som enheter. Vi bruker tilpasset enhetsgjenkjenning evne til Amazon Comprehend til å trene en tilpasset enhetsgjenkjenner, som kan identifisere slike enheter fra den tette teksten.

I de følgende avsnittene går vi gjennom eksempeldokumentene som er til stede i en boliglånssøknadspakke, og diskuterer metodene som brukes for å trekke ut informasjon fra dem. For hvert av disse eksemplene er en kodebit og en kort eksempelutgang inkludert.

Trekk ut data fra Unified Residential Loan Application URLA-1003

En Unified Residential Loan Application (URLA-1003) er et industristandard søknadsskjema for boliglån. Det er et ganske komplekst dokument som inneholder informasjon om boliglånsøkeren, type eiendom som kjøpes, beløp som finansieres og andre detaljer om eiendomskjøpets art. Følgende er et eksempel på URLA-1003, og vår intensjon er å trekke ut informasjon fra dette strukturerte dokumentet. Fordi dette er et skjema, bruker vi AnalyzeDocument API med en funksjonstype av FORM.

FORM-funksjonstypen trekker ut skjemainformasjon fra dokumentet, som deretter returneres i nøkkelverdi-parformat. Følgende kodebit bruker amazon-textract-textractor Python-bibliotek for å trekke ut skjemainformasjon med bare noen få linjer med kode. Bekvemmelighetsmetoden call_textract() kaller AnalyzeDocument API internt, og parameterne som sendes til metoden abstraherer noen av konfigurasjonene som APIen trenger for å kjøre utvinningsoppgaven. Document er en praktisk metode 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.

from textractcaller.t_call import call_textract, Textract_Features
from trp import Document

response_urla_1003 = call_textract(input_document='s3://<your-bucket>/URLA-1003.pdf', 
                                   features=[Textract_Features.FORMS])
doc_urla_1003 = Document(response_urla_1003)
for page in doc_urla_1003.pages:
    forms=[]
    for field in page.form.fields:
        obj={}
        obj[f'{field.key}']=f'{field.value}'
        forms.append(obj)
print(json.dumps(forms, indent=4))

Merk at utdataene inneholder verdier for avmerkingsbokser eller alternativknapper som finnes i skjemaet. For eksempel, i eksempelet URLA-1003-dokumentet Kjøp alternativet ble valgt. Den tilsvarende utgangen for alternativknappen trekkes ut som "Purchase" (tast) og "SELECTED” (verdi), som indikerer at alternativknappen ble valgt.

[
    { "No. of Units": "1" },
    { "Amount": "$ 450,000.00" },
    { "Year Built": "2010" },
    { "Purchase": "SELECTED" },
    { "Title will be held in what Name(s)": "Alejandro Rosalez" },
    { "Fixed Rate": "SELECTED" },
    ...
]

Trekk ut data fra 1099 skjemaer

En søknadspakke for boliglån kan også inneholde en rekke IRS-dokumenter, for eksempel 1099-DIV, 1099-INT, 1099-MISC og 1099-R. Disse dokumentene viser søkerens inntjening via renter, utbytte og andre diverse inntektskomponenter som er nyttige under underwriting for å ta beslutninger. Følgende bilde viser en samling av disse dokumentene, som er like i struktur. Men i noen tilfeller inneholder dokumentene skjemainformasjon (merket med røde og grønne avgrensningsbokser) samt tabellinformasjon (merket med gule avgrensningsramme).

For å trekke ut skjemainformasjon bruker vi lignende kode som forklart tidligere med AnalyzeDocument API. Vi passerer en ekstra funksjon av TABELL til API for å indikere at vi trenger både skjema- og tabelldata hentet fra dokumentet. Følgende kodebit bruker AnalyzeDocument API med FORMS- og TABLES-funksjoner på 1099-INT-dokumentet:

from textractcaller.t_call import call_textract, Textract_Features
from trp import Document
response_1099_int = call_textract(input_document='s3://<your-bucket>/1099-INT-2018.pdf',
                                  features=[Textract_Features.TABLES, 
                                            Textract_Features.FORMS])
doc_1099_int = Document(response_1099_int)
num_tables=1
for page in doc_1099_int.pages:     
    for table in page.tables:
        num_tables=num_tables+1
        for r, row in enumerate(table.rows):
            for c, cell in enumerate(row.cells):
                print(f"Cell[{r}][{c}] = {cell.text}")
        print('n')

Fordi dokumentet inneholder en enkelt tabell, er utdata fra koden som følger:

Table 1
-------------------
Cell[0][0] = 15 State 
Cell[0][1] = 16 State identification no. 
Cell[0][2] = 17 State tax withheld 
Cell[1][0] = 
Cell[1][1] = 34564 
Cell[1][2] = $ 2000 
Cell[2][0] = 
Cell[2][1] = 23543 
Cell[2][2] = $ 1000

Tabellinformasjonen inneholder celleposisjonen (rad 0, kolonne 0, og så videre) og den tilsvarende teksten i hver celle. Vi bruker en praktisk metode som kan transformere disse tabelldataene til en lettlest rutenettvisning:

from textractprettyprinter.t_pretty_print import Textract_Pretty_Print, get_string, Pretty_Print_Table_Format
print(get_string(textract_json=response_1099_int, 
                 table_format=Pretty_Print_Table_Format.grid, 
                 output_type=[Textract_Pretty_Print.TABLES]))

Vi får følgende utgang:

+----------+-----------------------------+-----------------------+
| 15 State | 16 State identification no. | 17 State tax withheld |
+----------+-----------------------------+-----------------------+
|          | 34564                       | $ 2000                |
+----------+-----------------------------+-----------------------+
|          | 23543                       | $ 1000                |
+----------+-----------------------------+-----------------------+

For å få utdataene i et CSV-format som er lett å konsumere, må formattypen Pretty_Print_Table_Format.csv kan føres inn i table_format parameter. Andre formater som TSV (tabseparerte verdier), HTML og Latex støttes også. For mer informasjon, se Textract-PrettyPrinter.

Trekk ut data fra et pantebrev

En søknadspakke for boliglån kan inneholde ustrukturerte dokumenter med tett tekst. Noen eksempler på tette tekstdokumenter er kontrakter og avtaler. Et pantebrev er en avtale mellom en boliglånsøker og långiver eller kredittforetak, og inneholder opplysninger i tette tekstavsnitt. I slike tilfeller gjør mangelen på struktur det vanskelig å finne sentral forretningsinformasjon som er viktig i søknadsprosessen for boliglån. Det er to måter å løse dette problemet på:

I følgende eksempel på boliglånsnotatet er vi spesielt interessert i å finne ut det månedlige betalingsbeløpet og hovedbeløpet.

For den første tilnærmingen bruker vi Query og QueriesConfig praktiske metoder for å konfigurere et sett med spørsmål som sendes til Amazon Textract AnalyzeDocument API-kall. I tilfelle dokumentet er flersidig (PDF eller TIFF), kan vi også spesifisere sidetallene der Amazon Textract skal se etter svar på spørsmålet. Følgende kodebit viser hvordan du oppretter spørringskonfigurasjonen, foretar et API-kall og deretter analyserer svaret for å få svarene fra svaret:

from textractcaller import QueriesConfig, Query
import trp.trp2 as t2

#Setup the queries
query2 = Query(text="What is the principal amount borrower has to pay?", alias="PRINCIPAL_AMOUNT", pages=["1"])
query4 = Query(text="What is the monthly payment amount?", alias="MONTHLY_AMOUNT", pages=["1"])

#Setup the query config with the above queries
queries_config = QueriesConfig(queries=[query1, query2, query3, query4])
#Call AnalyzeDocument with the queries_config
response_mortgage_note = call_textract(input_document='s3://<your-bucket>/Mortgage-Note.pdf',
                                       features=[Textract_Features.QUERIES],
                                       queries_config=queries_config)
doc_mortgage_note: t2.TDocumentSchema = t2.TDocumentSchema().load(response_mortgage_note) 

entities = {}
for page in doc_mortgage_note.pages:
    query_answers = doc_mortgage_note.get_query_answers(page=page)
    if query_answers:
        for answer in query_answers:
            entities[answer[1]] = answer[2]
print(entities)

Vi får følgende utgang:

{
    'PRINCIPAL_AMOUNT': '$ 555,000.00',
    'MONTHLY_AMOUNT': '$2,721.23',
}

For den andre tilnærmingen bruker vi Amazon Comprehend OppdagEntiteter API med pantebrevet, som returnerer enhetene den oppdager i teksten fra en forhåndsdefinert sett med enheter. Dette er enheter som Amazon Comprehend-enhetsgjenkjenneren er forhåndsutdannet med. Men fordi vårt krav er å oppdage spesifikke enheter, blir en tilpasset enhetsgjenkjenner fra Amazon Comprehend trent med et sett med eksempler på pantebrevsdokumenter og en liste over enheter. Vi definerer enhetsnavnene som PRINCIPAL_AMOUNT og MONTHLY_AMOUNT. Treningsdata utarbeides etter Amazon Comprehend-opplæringen retningslinjer for utarbeidelse av data for tilpasset enhetsgjenkjenning. Enhetsgjenkjenneren kan trenes med dokumentanmerkninger eller med enhet lister. For formålet med dette eksemplet bruker vi enhetslister for å trene modellen. Etter at vi har trent modellen, kan vi distribuere den med en endepunkt i sanntid eller i batch-modus for å oppdage de to enhetene fra dokumentinnholdet. Følgende er trinnene involvert for å trene en tilpasset enhetsgjenkjenner og distribuere den. For en fullstendig kodegjennomgang, se vårt GitHub-lager.

1. Forbered opplæringsdataene (entitetslisten og dokumentene med (UTF-8-kodet) ren tekstformat).
2. Start enhetsgjenkjenningsopplæringen ved å bruke CreateEntityRecognizer API som bruker treningsdataene.
3. Distribuer den trente modellen med et endepunkt i sanntid ved å bruke Opprett endepunkt API.

Trekk ut data fra et amerikansk pass

Amazon Textract analysere identitetsdokumenter kapasitet kan oppdage og trekke ut informasjon fra USA-baserte ID-dokumenter som førerkort og pass. De AnalyzeID API er i stand til å oppdage og tolke implisitte felt i ID-dokumenter, noe som gjør det enkelt å trekke ut spesifikk informasjon fra dokumentet. Identitetsdokumenter er nesten alltid en del av en lånesøknadspakke, fordi den brukes til å bekrefte identiteten til låntakeren under garantiprosessen, og for å validere riktigheten av låntakerens biografiske data.

Vi bruker en bekvemmelighetsmetode kalt call_textract_analyzeid, som kaller AnalyzeID API internt. Vi gjentar deretter svaret for å hente de oppdagede nøkkelverdi-parene fra ID-dokumentet. Se følgende kode:

from textractcaller import call_textract_analyzeid
import trp.trp2_analyzeid as t2id

response_passport = call_textract_analyzeid(document_pages=['s3://<your-bucket>/Passport.pdf'])
doc_passport: t2id.TAnalyzeIdDocument = t2id.TAnalyzeIdDocumentSchema().load(response_passport)

for id_docs in response_passport['IdentityDocuments']:
    id_doc_kvs={}
    for field in id_docs['IdentityDocumentFields']:
        if field['ValueDetection']['Text']:
            id_doc_kvs[field['Type']['Text']] = field['ValueDetection']['Text']
print(id_doc_kvs)

AnalyzeID returnerer informasjon i en struktur kalt IdentityDocumentFields, som inneholder de normaliserte nøklene og deres tilsvarende verdi. For eksempel, i følgende utgang, FIRST_NAME er en normalisert nøkkel og verdien er ALEJANDRO. I eksempelet på passbildet er feltet for fornavnet merket som "Given Names / Prénoms / Nombre", men AnalyzeID klarte å normalisere det til nøkkelnavnet FIRST_NAME. For en liste over støttede normaliserte felt, se Identitetsdokumentasjon Responsobjekter.

{
    'FIRST_NAME': 'ALEJANDRO',
    'LAST_NAME': 'ROSALEZ',
    'DOCUMENT_NUMBER': '918268822',
    'EXPIRATION_DATE': '31 JAN 2029',
    'DATE_OF_BIRTH': '15 APR 1990',
    'DATE_OF_ISSUE': '29 JAN 2009',
    'ID_TYPE': 'PASSPORT',
    'ENDORSEMENTS': 'SEE PAGE 27',
    'PLACE_OF_BIRTH': 'TEXAS U.S.A.'
}

En boliglånspakke kan inneholde flere andre dokumenter, for eksempel en lønnsslipp, W2-skjema, kontoutskrift, kredittkortutskrift og ansettelsesbekreftelsesbrev. Vi har eksempler for hvert av disse dokumentene sammen med koden som kreves for å trekke ut data fra dem. For den komplette kodebasen, sjekk ut notatbøkene i vår GitHub repository.

Dokumentberikelse

En av de vanligste formene for dokumentberikelse er redaksjon av sensitiv eller konfidensiell informasjon på dokumenter, som kan være pålagt på grunn av personvernlover eller -forskrifter. For eksempel kan en boliglånsøkers lønnsslipp inneholde sensitive PII-data, som navn, adresse og SSN, som kan trenge redaksjon for utvidet lagring.

I det foregående eksempelbetalingsdokumentet utfører vi redaksjon av PII-data som SSN, navn, bankkontonummer og datoer. For å identifisere PII-data i et dokument bruker vi Amazon Comprehend PII-deteksjon kapasitet via DetectPIIEntities API. Denne API-en inspiserer innholdet i dokumentet for å identifisere tilstedeværelsen av PII-informasjon. Fordi denne APIen krever inndata i UTF-8-kodet ren tekstformat, trekker vi først ut teksten fra dokumentet ved å bruke Amazon Textract Oppdag Dokumenttekst API, som returnerer teksten fra dokumentet og også returnerer geometriinformasjon som avgrensingsrammedimensjoner og koordinater. En kombinasjon av begge utdataene brukes deretter til å tegne redaksjoner på dokumentet som en del av berikelsesprosessen.

Se gjennom, valider og integrer data

Uttrukket data fra dokumentutvinningsfasen kan trenge validering mot spesifikke forretningsregler. Spesifikk informasjon kan også valideres på tvers av flere dokumenter, også kjent som cross-doc validering. Et eksempel på cross-doc validering kan være å sammenligne søkerens navn i ID-dokumentet med navnet i pantesøknadsdokumentet. Du kan også gjøre andre valideringer som eiendomsverdiberegninger og betingede garantibeslutninger i denne fasen.

En tredje type validering er relatert til konfidenspoengsummen til de ekstraherte dataene i dokumentutvinningsfasen. Amazon Textract og Amazon Comprehend gir en konfidenspoengsum for oppdagede skjemaer, tabeller, tekstdata og enheter. Du kan konfigurere en konfidenspoengterskel for å sikre at bare riktige verdier sendes nedstrøms. Dette oppnås via Amazon A2I, som sammenligner konfidensskårene til oppdagede data med en forhåndsdefinert konfidensgrense. Hvis terskelen ikke er oppfylt, rutes dokumentet og den utpakkede utgangen til et menneske for gjennomgang gjennom et intuitivt brukergrensesnitt. Kontrolløren iverksetter korrigerende tiltak på dataene og lagrer dem for videre behandling. For mer informasjon, se Kjernekonsepter for Amazon A2I.

konklusjonen

I dette innlegget diskuterte vi fasene av intelligent dokumentbehandling når det gjelder faser av en boliglånsøknad. Vi så på noen vanlige eksempler på dokumenter som kan finnes i en søknadspakke for boliglån. Vi diskuterte også måter å trekke ut og behandle strukturert, semistrukturert og ustrukturert innhold fra disse dokumentene. IDP gir en måte å automatisere ende-til-ende dokumentbehandling av boliglån som kan skaleres til millioner av dokumenter, forbedre kvaliteten på søknadsbeslutninger, redusere kostnadene og betjene kundene raskere.

Som et neste trinn kan du prøve kodeeksemplene og notatbøkene i vår GitHub repository. For å lære mer om hvordan IDP kan hjelpe dokumentbehandlingsarbeidsmengdene dine, besøk Automatiser databehandling fra dokumenter.

Om forfatterne

Anjan Biswas er en senior AI Services Solutions Architect med fokus på AI/ML og Data Analytics. Anjan er en del av det verdensomspennende AI-tjenesteteamet og jobber med kunder for å hjelpe dem med å forstå og utvikle løsninger på forretningsproblemer med AI og ML. 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 AI-tjenester.

Dwiti Pathak er en Senior Technical Account Manager basert i San Diego. Hun er fokusert på å hjelpe halvlederindustrien med å engasjere seg i AWS. På fritiden liker hun å lese om nye teknologier og spille brettspill.

Balaji Puli er en løsningsarkitekt basert i Bay Area, CA. Hjelper for tiden utvalgte helsevesenskunder i Nordvest i USA med å akselerere sin AWS-skyadopsjon. Balaji liker å reise og elsker å utforske ulike retter.