Byg veldesignede IDP-løsninger med et tilpasset objektiv – Del 4: Ydeevneeffektivitet | Amazon Web Services

Når en kunde har en produktionsklar intelligent dokumentbehandling (IDP) arbejdsbyrde, modtager vi ofte anmodninger om en velstruktureret gennemgang. For at bygge en virksomhedsløsning skal udviklerressourcer, omkostninger, tid og brugeroplevelse balanceres for at opnå det ønskede forretningsresultat. Det AWS velstruktureret rammeværk giver organisationer en systematisk måde at lære operationelle og arkitektoniske bedste praksisser til at designe og drive pålidelige, sikre, effektive, omkostningseffektive og bæredygtige arbejdsbelastninger i skyen.

IDP Well-Architected Custom Lens følger AWS Well-Architected Framework og gennemgår løsningen med seks søjler med granulariteten af ​​en specifik AI eller machine learning (ML) use case og giver vejledningen til at tackle fælles udfordringer. Den IDP velarkitekterede brugerdefinerede linse i Velopbygget værktøj indeholder spørgsmål vedrørende hver af søjlerne. Ved at besvare disse spørgsmål kan du identificere potentielle risici og løse dem ved at følge din forbedringsplan.

Dette indlæg fokuserer på Ydeevne Effektivitet søjle af IDP-arbejdsbyrden. Vi dykker dybt ned i at designe og implementere løsningen for at optimere til gennemløb, latency og overordnet ydeevne. Vi starter med at diskutere nogle almindelige indikatorer for, at du bør gennemføre en vel-arkitekteret gennemgang, og introducerer de grundlæggende tilgange med designprincipper. Derefter gennemgår vi hvert fokusområde ud fra et teknisk perspektiv.

For at følge med i dette indlæg, bør du være bekendt med de tidligere indlæg i denne serie (del 1 , del 2) og retningslinjerne i Vejledning til intelligent dokumentbehandling på AWS. Disse ressourcer introducerer almindelige AWS-tjenester til IDP-arbejdsbelastninger og foreslåede arbejdsgange. Med denne viden er du nu klar til at lære mere om produktion af din arbejdsbyrde.

Fælles indikatorer

Følgende er almindelige indikatorer for, at du bør gennemføre en velstruktureret rammegennemgang for søjlen Performance Efficiency:

• Høj latenstid – Når latensen af ​​optisk tegngenkendelse (OCR), enhedsgenkendelse eller end-to-end workflow tager længere tid end dit tidligere benchmark, kan dette være en indikator for, at arkitekturdesignet ikke dækker belastningstest eller fejlhåndtering.
• Hyppig drosling – Du kan opleve drosling af AWS-tjenester som f.eks amazontekst på grund af anmodningsgrænser. Det betyder, at arkitekturen skal justeres ved at gennemgå arkitekturens arbejdsgang, synkron og asynkron implementering, beregning af transaktioner per sekund (TPS) og meget mere.
• Fejlretningsproblemer – Når der er en dokumentprocesfejl, har du muligvis ikke en effektiv måde at identificere, hvor fejlen er placeret i arbejdsgangen, hvilken service den er relateret til, og hvorfor fejlen opstod. Det betyder, at systemet mangler overblik over logfiler og fejl. Overvej at revidere logningsdesignet af telemetridataene og tilføje infrastruktur som kode (IaC), såsom dokumentbehandlingspipelines, til løsningen.

Indikatorer	Beskrivelse	Arkitektonisk kløft
Høj forsinkelse	OCR, enhedsgenkendelse eller end-to-end workflow-forsinkelse overstiger tidligere benchmark	Load Testing Fejlhåndtering
Hyppig drosling	Drossel af AWS-tjenester som Amazon Textract på grund af anmodningsgrænser	Synkronisering vs Asynkron TPS beregning
Svært at fejlfinde	Ingen indsigt i placering, årsag og årsag til dokumentbehandlingsfejl	Logning design Dokumentbehandlingsrørledninger

Designprincipper

I dette indlæg diskuterer vi tre designprincipper: uddelegering af komplekse AI-opgaver, IaC-arkitekturer og serverløse arkitekturer. Når du støder på en afvejning mellem to implementeringer, kan du gense designprincipperne med din organisations forretningsprioriteter, så du kan træffe beslutninger effektivt.

• Uddelegering af komplekse AI-opgaver – Du kan aktivere hurtigere AI-adoption i din organisation ved at overføre ML-modeludviklingens livscyklus til administrerede tjenester og drage fordel af modeludviklingen og infrastrukturen leveret af AWS. I stedet for at kræve, at dine datavidenskabs- og it-teams bygger og vedligeholder AI-modeller, kan du bruge forudtrænede AI-tjenester, der kan automatisere opgaver for dig. Dette giver dine teams mulighed for at fokusere på arbejde af højere værdi, der adskiller din virksomhed, mens cloud-udbyderen håndterer kompleksiteten af ​​træning, implementering og skalering af AI-modellerne.
• IaC arkitekturer – Når du kører en IDP-løsning, inkluderer løsningen flere AI-tjenester for at udføre end-to-end workflowet kronologisk. Du kan bygge løsningen med workflow-pipelines vha AWS-trinfunktioner for at forbedre fejltolerance, parallel behandling, synlighed og skalerbarhed. Disse fordele kan gøre dig i stand til at optimere brugen og omkostningerne ved underliggende AI-tjenester.
• Serverless arkitekturer – IDP er ofte en begivenhedsdrevet løsning, initieret af brugeruploads eller planlagte job. Løsningen kan skaleres horisontalt ud ved at øge opkaldstaksterne for AI-tjenesterne, AWS Lambdaog andre involverede tjenester. En serverløs tilgang giver skalerbarhed uden at overprovisionere ressourcer, hvilket forhindrer unødvendige udgifter. Overvågningen bag det serverløse design hjælper med at opdage ydeevneproblemer.

Med disse tre designprincipper i tankerne kan organisationer etablere et effektivt grundlag for AI/ML-adoption på cloud-platforme. Ved at uddelegere kompleksitet, implementere robust infrastruktur og designe til skala, kan organisationer optimere deres AI/ML-løsninger.

I de følgende afsnit diskuterer vi, hvordan man løser fælles udfordringer i forhold til tekniske fokusområder.

Fokusområder

Når vi gennemgår ydeevneeffektivitet, gennemgår vi løsningen fra fem fokusområder: arkitekturdesign, datastyring, fejlhåndtering, systemovervågning og modelovervågning. Med disse fokusområder kan du udføre en arkitekturgennemgang fra forskellige aspekter for at forbedre effektiviteten, observerbarheden og skalerbarheden af ​​de tre komponenter i et AI/ML-projekt, data, model eller forretningsmål.

Arkitektur design

Ved at gennemgå spørgsmålene i dette fokusområde vil du gennemgå den eksisterende arbejdsgang for at se, om den følger bedste praksis. Den foreslåede arbejdsgang giver et fælles mønster, som organisationer kan følge, og forhindrer trial-and-error-omkostninger.

Baseret på foreslået arkitektur, følger arbejdsgangen de seks stadier af datafangst, klassificering, ekstraktion, berigelse, gennemgang og validering og forbrug. I de fælles indikatorer, vi diskuterede tidligere, kommer to ud af tre fra problemer med arkitekturdesign. Dette skyldes, at når du starter et projekt med en improviseret tilgang, kan du møde projektbegrænsninger, når du prøver at tilpasse din infrastruktur til din løsning. Med arkitekturdesigngennemgangen kan det improviserede design afkobles som faser, og hver af dem kan revurderes og omorganiseres.

Du kan spare tid, penge og arbejde ved at implementere klassifikationer i din arbejdsgang, og dokumenter går til downstream-applikationer og API'er baseret på dokumenttype. Dette øger dokumentprocessens observerbarhed og gør løsningen ligetil at vedligeholde, når der tilføjes nye dokumenttyper.

Datastyring

Ydeevnen af ​​en IDP-løsning inkluderer latens, gennemløb og end-to-end brugeroplevelse. Hvordan man administrerer dokumentet og dets udtrukne oplysninger i løsningen er nøglen til datakonsistens, sikkerhed og privatliv. Derudover skal løsningen håndtere høje datamængder med lav latency og høj gennemstrømning.

Når du gennemgår spørgsmålene til dette fokusområde, vil du gennemgå dokumentarbejdsgangen. Dette inkluderer dataindtagelse, dataforbehandling, konvertering af dokumenter til dokumenttyper accepteret af Amazon Textract, håndtering af indgående dokumentstrømme, routing af dokumenter efter type og implementering af adgangskontrol og opbevaringspolitikker.

For eksempel, ved at gemme et dokument i de forskellige behandlede faser, kan du vende behandlingen tilbage til det forrige trin, hvis det er nødvendigt. Datalivscyklussen sikrer pålideligheden og compliance for arbejdsbyrden. Ved at bruge Amazon Textract Service Quotas Calculator (se følgende skærmbillede), asynkrone funktioner på Amazon Textract, Lambda, Step Functions, Amazon Simple Queue Service (Amazon SQS), og Amazon Simple Notification Service (Amazon SNS), kan organisationer automatisere og skalere dokumentbehandlingsopgaver for at imødekomme specifikke arbejdsbelastningsbehov.

Fejl ved håndtering

Robust fejlhåndtering er afgørende for sporing af dokumentprocesstatus, og det giver driftsteamet tid til at reagere på enhver unormal adfærd, såsom uventede dokumentmængder, nye dokumenttyper eller andre uplanlagte problemer fra tredjepartstjenester. Fra organisationens perspektiv kan korrekt fejlhåndtering forbedre systemets oppetid og ydeevne.

Du kan opdele fejlhåndtering i to nøgleaspekter:

• AWS service konfiguration – Du kan implementere genforsøgslogik med eksponentiel backoff for at håndtere forbigående fejl som throttling. Når du starter behandlingen ved at kalde en asynkron Start*-operation, som f.eks StartDocumentTextDetection, kan du angive, at afslutningsstatussen for anmodningen offentliggøres til et SNS-emne i Notifikationskanal konfiguration. Dette hjælper dig med at undgå at begrænse begrænsninger for API-kald på grund af polling af Get* API'erne. Du kan også implementere alarmer i amazoncloudwatch og udløses for at advare, når der opstår usædvanlige fejlspidser.
• Fejlrapport forbedring – Dette inkluderer detaljerede meddelelser med et passende detaljeringsniveau efter fejltype og beskrivelser af fejlhåndteringssvar. Med den korrekte fejlhåndteringsopsætning kan systemerne være mere modstandsdygtige ved at implementere almindelige mønstre som automatisk genforsøg af intermitterende fejl, brug af strømafbrydere til at håndtere kaskadefejl og overvågningstjenester for at få indsigt i fejl. Dette gør det muligt for løsningen at balancere mellem genforsøgsgrænser og forhindrer uendelige kredsløbsløkker.

Modelovervågning

Ydeevnen af ​​ML-modeller overvåges for nedbrydning over tid. Efterhånden som data og systemforhold ændrer sig, spores modellens ydeevne og effektivitetsmålinger for at sikre, at genoptræning udføres, når det er nødvendigt.

ML-modellen i en IDP-arbejdsgang kan være en OCR-model, enhedsgenkendelsesmodel eller klassifikationsmodel. Modellen kan komme fra en AWS AI-tjeneste, en open source-model på Amazon SageMaker, Amazonas grundfjeld, eller andre tredjepartstjenester. Du skal forstå begrænsningerne og anvendelsesmulighederne for hver tjeneste for at identificere måder, hvorpå du kan forbedre modellen med menneskelig feedback og forbedre tjenesteydelsen over tid.

En almindelig tilgang er at bruge servicelogfiler til at forstå forskellige niveauer af nøjagtighed. Disse logfiler kan hjælpe datavidenskabsteamet med at identificere og forstå ethvert behov for modelomskoling. Din organisation kan vælge omskolingsmekanismen – den kan være kvartalsvis, månedlig eller baseret på videnskabelige målinger, såsom når nøjagtigheden falder under en given tærskel.

Målet med overvågning er ikke kun at opdage problemer, men at lukke sløjfen for løbende at forfine modeller og holde IDP-løsningen i gang, efterhånden som det eksterne miljø udvikler sig.

Systemovervågning

Når du har implementeret IDP-løsningen i produktionen, er det vigtigt at overvåge nøglemålinger og automatiseringsydelse for at identificere områder, der kan forbedres. Målingerne bør omfatte forretningsmålinger og tekniske målinger. Dette giver virksomheden mulighed for at evaluere systemets ydeevne, identificere problemer og foretage forbedringer af modeller, regler og arbejdsgange over tid for at øge automatiseringshastigheden for at forstå den operationelle effekt.

På forretningssiden er målinger som ekstraktionsnøjagtighed for vigtige felter, overordnet automatiseringshastighed, der angiver procentdelen af ​​dokumenter behandlet uden menneskelig indgriben, og gennemsnitlig behandlingstid pr. dokument altafgørende. Disse forretningsmålinger hjælper med at kvantificere slutbrugeroplevelsen og driftseffektiviteten.

Tekniske målinger, herunder fejl- og undtagelsesrater, der forekommer i hele arbejdsgangen, er essentielle at spore fra et ingeniørmæssigt perspektiv. De tekniske målinger kan også overvåge på hvert niveau fra ende til anden og give et omfattende overblik over en kompleks arbejdsbyrde. Du kan opdele metrikkerne i forskellige niveauer, såsom løsningsniveau, end-to-end workflow-niveau, dokumenttypeniveau, dokumentniveau, enhedsgenkendelsesniveau og OCR-niveau.

Nu hvor du har gennemgået alle spørgsmålene i denne søjle, kan du vurdere de andre søjler og udvikle en forbedringsplan for din IDP-arbejdsbyrde.

Konklusion

I dette indlæg diskuterede vi almindelige indikatorer, som du muligvis har brug for for at udføre en velstruktureret rammegennemgang for Performance Efficiency-søjlen for din IDP-arbejdsbyrde. Vi gennemgik derefter designprincipper for at give et overblik på højt niveau og diskutere løsningsmålet. Ved at følge disse forslag med henvisning til IDP Well-Architected Custom Lens og ved at gennemgå spørgsmålene efter fokusområde, skulle du nu have en projektforbedringsplan.

---

Om forfatterne

Mia Chang er en ML Specialist Solutions Architect for Amazon Web Services. Hun arbejder med kunder i EMEA og deler bedste praksis for at køre AI/ML-arbejdsbelastninger i skyen med sin baggrund i anvendt matematik, datalogi og AI/ML. Hun fokuserer på NLP-specifikke arbejdsbelastninger og deler sin erfaring som konferencetaler og bogforfatter. I sin fritid nyder hun at vandre, brætspil og brygge kaffe.

Brijesh Pati er Enterprise Solutions Architect hos AWS. Hans primære fokus er at hjælpe virksomhedskunder med at anvende cloud-teknologier til deres arbejdsbelastninger. Han har en baggrund inden for applikationsudvikling og virksomhedsarkitektur og har arbejdet med kunder fra forskellige brancher som sport, finans, energi og professionel service. Hans interesser omfatter serverløse arkitekturer og AI/ML.

Rui Cardoso er partnerløsningsarkitekt hos Amazon Web Services (AWS). Han fokuserer på AI/ML og IoT. Han arbejder med AWS Partnere og støtter dem i at udvikle løsninger i AWS. Når han ikke arbejder, nyder han at cykle, vandre og lære nye ting.

Tim Condello er en senior arkitekt inden for kunstig intelligens (AI) og maskinlæring (ML) specialistløsninger hos Amazon Web Services (AWS). Hans fokus er naturlig sprogbehandling og computersyn. Tim nyder at tage kundeideer og omsætte dem til skalerbare løsninger.

Sherry Ding er en senior arkitekt inden for kunstig intelligens (AI) og maskinlæring (ML) specialistløsninger hos Amazon Web Services (AWS). Hun har stor erfaring med maskinlæring med en ph.d.-grad i datalogi. Hun arbejder hovedsageligt med kunder i den offentlige sektor om forskellige AI/ML-relaterede forretningsudfordringer og hjælper dem med at accelerere deres maskinlæringsrejse på AWS Cloud. Når hun ikke hjælper kunder, nyder hun udendørsaktiviteter.

Suyin Wang er AI/ML Specialist Solutions Architect hos AWS. Hun har en tværfaglig uddannelsesbaggrund i Machine Learning, Financial Information Service og Economics, sammen med mange års erfaring med at bygge Data Science og Machine Learning-applikationer, der løste forretningsproblemer i den virkelige verden. Hun nyder at hjælpe kunder med at identificere de rigtige forretningsspørgsmål og bygge de rigtige AI/ML-løsninger. I sin fritid elsker hun at synge og lave mad.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• Kilde: https://aws.amazon.com/blogs/machine-learning/build-well-architected-idp-solutions-with-a-custom-lens-part-4-performance-efficiency/