Bygg godt utformede IDP-løsninger med et tilpasset objektiv – Del 4: Ytelseseffektivitet | Amazon Web Services

Når en kunde har en produksjonsklar intelligent dokumentbehandling (IDP) arbeidsmengde, mottar vi ofte forespørsler om en velarbeidet gjennomgang. For å bygge en bedriftsløsning må utviklerressurser, kostnader, tid og brukeropplevelse balanseres for å oppnå ønsket forretningsresultat. De AWS godt arkitektert rammeverk gir en systematisk måte for organisasjoner å lære operasjonelle og arkitektoniske beste praksiser for utforming og drift av pålitelige, sikre, effektive, kostnadseffektive og bærekraftige arbeidsbelastninger i skyen.

IDP Well-Architected Custom Lens følger AWS Well-Architected Framework, og vurderer løsningen med seks pilarer med granulariteten til en spesifikk AI eller maskinlæring (ML), og gir veiledning for å takle vanlige utfordringer. IDP-velarkitektert tilpasset linse i Godt bygd verktøy inneholder spørsmål angående hver av pilarene. Ved å svare på disse spørsmålene kan du identifisere potensielle risikoer og løse dem ved å følge forbedringsplanen din.

Dette innlegget fokuserer på Ytelse Effektivitet søyle av IDP-arbeidsmengden. Vi dykker dypt ned i å designe og implementere løsningen for å optimalisere for gjennomstrømning, latens og generell ytelse. Vi starter med å diskutere noen vanlige indikatorer på at du bør gjennomføre en velarbeidet gjennomgang, og introduserer de grunnleggende tilnærmingene med designprinsipper. Deretter går vi gjennom hvert fokusområde fra et teknisk perspektiv.

For å følge med på dette innlegget, bør du være kjent med de tidligere innleggene i denne serien (Del 1 og Del 2) og retningslinjene i Veiledning for intelligent dokumentbehandling på AWS. Disse ressursene introduserer vanlige AWS-tjenester for IDP-arbeidsbelastninger og foreslåtte arbeidsflyter. Med denne kunnskapen er du nå klar til å lære mer om produksjon av arbeidsmengden din.

Vanlige indikatorer

Følgende er vanlige indikatorer for at du bør gjennomføre en gjennomgang av et godt arkitektonisk rammeverk for ytelseseffektivitet-pilaren:

• Høy latenstid – Når latensen for optisk tegngjenkjenning (OCR), enhetsgjenkjenning eller ende-til-ende-arbeidsflyten tar lengre tid enn din forrige benchmark, kan dette være en indikator på at arkitekturdesignet ikke dekker belastningstesting eller feilhåndtering.
• Hyppig struping – Du kan oppleve struping av AWS-tjenester som amazontekst på grunn av forespørselsgrenser. Dette betyr at arkitekturen må justeres ved å gjennomgå arkitekturarbeidsflyten, synkron og asynkron implementering, transaksjoner per sekund (TPS)-beregning og mer.
• Feilsøkingsvansker – Når det er en dokumentprosessfeil, har du kanskje ikke en effektiv måte å identifisere hvor feilen er plassert i arbeidsflyten, hvilken tjeneste den er relatert til, og hvorfor feilen oppstod. Dette betyr at systemet mangler innsyn i logger og feil. Vurder å revidere loggdesignen til telemetridataene og legge til infrastruktur som kode (IaC), for eksempel dokumentbehandlingsrørledninger, til løsningen.

indikatorer	Beskrivelse	Arkitektonisk gap
Høy latens	OCR, enhetsgjenkjenning eller ende-til-ende arbeidsflytforsinkelse overskrider tidligere benchmark	Load Testing Feilhåndtering
Hyppig struping	Begrensning av AWS-tjenester som Amazon Textract på grunn av forespørselsgrenser	Synkronisering vs Asynkron TPS-beregning
Vanskelig å feilsøke	Ingen innsyn i plassering, årsak og årsak til dokumentbehandlingsfeil	Loggdesign Dokumentbehandlingsrørledninger

Design prinsipper

I dette innlegget diskuterer vi tre designprinsipper: delegere komplekse AI-oppgaver, IaC-arkitekturer og serverløse arkitekturer. Når du møter en avveining mellom to implementeringer, kan du gå tilbake til designprinsippene med forretningsprioriteringene til organisasjonen din, slik at du kan ta beslutninger effektivt.

• Delegering av komplekse AI-oppgaver – Du kan aktivere raskere AI-adopsjon i organisasjonen din ved å overføre ML-modellutviklingslivssyklusen til administrerte tjenester og dra nytte av modellutviklingen og infrastrukturen som tilbys av AWS. I stedet for å kreve at datavitenskaps- og IT-teamene dine bygger og vedlikeholder AI-modeller, kan du bruke forhåndsopplærte AI-tjenester som kan automatisere oppgaver for deg. Dette lar teamene dine fokusere på arbeid med høyere verdi som skiller virksomheten din, mens skyleverandøren håndterer kompleksiteten ved opplæring, distribusjon og skalering av AI-modellene.
• IaC-arkitekturer – Når du kjører en IDP-løsning, inkluderer løsningen flere AI-tjenester for å utføre ende-til-ende arbeidsflyten kronologisk. Du kan bygge løsningen med arbeidsflytrørledninger ved hjelp av AWS trinnfunksjoner for å forbedre feiltoleranse, parallell behandling, synlighet og skalerbarhet. Disse fordelene kan gjøre deg i stand til å optimalisere bruken og kostnadene for underliggende AI-tjenester.
• server~~POS=TRUNC arkitekturer – IDP er ofte en hendelsesdrevet løsning, initiert av brukeropplastinger eller planlagte jobber. Løsningen kan skaleres ut horisontalt ved å øke ringetakstene for AI-tjenestene, AWS Lambdaog andre involverte tjenester. En serverløs tilnærming gir skalerbarhet uten å overprovisionere ressurser, og forhindrer unødvendige utgifter. Overvåkingen bak den serverløse designen hjelper til med å oppdage ytelsesproblemer.

Med disse tre designprinsippene i tankene, kan organisasjoner etablere et effektivt grunnlag for AI/ML-adopsjon på skyplattformer. Ved å delegere kompleksitet, implementere spenstig infrastruktur og designe for skala, kan organisasjoner optimalisere AI/ML-løsningene sine.

I de følgende avsnittene diskuterer vi hvordan vi kan møte vanlige utfordringer i forhold til tekniske fokusområder.

Fokusområder

Når vi vurderer ytelseseffektivitet, vurderer vi løsningen fra fem fokusområder: arkitekturdesign, dataadministrasjon, feilhåndtering, systemovervåking og modellovervåking. Med disse fokusområdene kan du gjennomføre en arkitekturgjennomgang fra ulike aspekter for å forbedre effektiviteten, observerbarheten og skalerbarheten til de tre komponentene i et AI/ML-prosjekt, data, modell eller forretningsmål.

Arkitektur design

Ved å gå gjennom spørsmålene i dette fokusområdet vil du gjennomgå den eksisterende arbeidsflyten for å se om den følger beste praksis. Den foreslåtte arbeidsflyten gir et felles mønster som organisasjoner kan følge og forhindrer prøving-og-feil-kostnader.

Basert på foreslått arkitektur, følger arbeidsflyten de seks stadiene datafangst, klassifisering, utvinning, berikelse, gjennomgang og validering og forbruk. I de vanlige indikatorene vi diskuterte tidligere, kommer to av tre fra arkitekturdesignproblemer. Dette er fordi når du starter et prosjekt med en improvisert tilnærming, kan du møte prosjektbegrensninger når du prøver å tilpasse infrastrukturen din til løsningen din. Med arkitekturdesigngjennomgangen kan det improviserte designet kobles fra som stadier, og hver av dem kan revurderes og omorganiseres.

Du kan spare tid, penger og arbeid ved å implementere klassifiseringer i arbeidsflyten din, og dokumenter går til nedstrømsapplikasjoner og APIer basert på dokumenttype. Dette øker dokumentprosessens observerbarhet og gjør løsningen enkel å vedlikeholde når du legger til nye dokumenttyper.

Dataledelse

Ytelsen til en IDP-løsning inkluderer ventetid, gjennomstrømning og ende-til-ende brukeropplevelse. Hvordan du administrerer dokumentet og dets utpakkede informasjon i løsningen er nøkkelen til datakonsistens, sikkerhet og personvern. I tillegg må løsningen håndtere høye datavolumer med lav ventetid og høy gjennomstrømning.

Når du går gjennom spørsmålene til dette fokusområdet, vil du gjennomgå dokumentarbeidsflyten. Dette inkluderer datainntak, dataforbehandling, konvertering av dokumenter til dokumenttyper akseptert av Amazon Textract, håndtering av innkommende dokumentstrømmer, ruting av dokumenter etter type og implementering av retningslinjer for tilgangskontroll og oppbevaring.

For eksempel, ved å lagre et dokument i de forskjellige behandlede fasene, kan du reversere behandlingen til forrige trinn om nødvendig. Datalivssyklusen sikrer pålitelighet og samsvar for arbeidsbelastningen. Ved å bruke Amazon Textract-tjenestekvotekalkulator (se følgende skjermbilde), asynkrone funksjoner på Amazon Textract, Lambda, Step Functions, Amazon enkel køtjeneste (Amazon SQS), og Amazon enkel varslingstjeneste (Amazon SNS), kan organisasjoner automatisere og skalere dokumentbehandlingsoppgaver for å møte spesifikke arbeidsbelastningsbehov.

Feilhåndtering

Robust feilhåndtering er avgjørende for å spore dokumentprosessens status, og det gir driftsteamet tid til å reagere på unormal atferd, for eksempel uventede dokumentvolumer, nye dokumenttyper eller andre uplanlagte problemer fra tredjepartstjenester. Fra organisasjonens perspektiv kan riktig feilhåndtering forbedre systemets oppetid og ytelse.

Du kan dele opp feilhåndtering i to hovedaspekter:

• AWS-tjenestekonfigurasjon – Du kan implementere logikk på nytt med eksponentiell backoff for å håndtere forbigående feil som struping. Når du starter behandlingen ved å kalle en asynkron Start*-operasjon, som f.eks StartDocumentTextDetection, kan du spesifisere at fullføringsstatusen for forespørselen publiseres til et SNS-emne i Varslingskanal konfigurasjon. Dette hjelper deg med å unngå strupegrenser på API-anrop på grunn av polling av Get* API-ene. Du kan også implementere alarmer i Amazon CloudWatch og utløses for å varsle når uvanlige feiltopper oppstår.
• Feilrapport forbedring – Dette inkluderer detaljerte meldinger med et passende detaljnivå etter feiltype og beskrivelser av feilhåndteringssvar. Med riktig feilhåndteringsoppsett kan systemene være mer motstandsdyktige ved å implementere vanlige mønstre som å automatisk prøve intermitterende feil på nytt, bruke strømbrytere for å håndtere kaskadefeil og overvåkingstjenester for å få innsikt i feil. Dette gjør at løsningen kan balansere mellom gjenforsøksgrenser og forhindrer uendelige kretssløyfer.

Modellovervåking

Ytelsen til ML-modeller overvåkes for degradering over tid. Etter hvert som data og systemforhold endres, spores modellens ytelses- og effektivitetsmålinger for å sikre at omskolering utføres når det er nødvendig.

ML-modellen i en IDP-arbeidsflyt kan være en OCR-modell, enhetsgjenkjenningsmodell eller klassifiseringsmodell. Modellen kan komme fra en AWS AI-tjeneste, en åpen kildekode-modell på Amazon SageMaker, Amazonas grunnfjell, eller andre tredjepartstjenester. Du må forstå begrensningene og brukstilfellene for hver tjeneste for å identifisere måter å forbedre modellen med menneskelig tilbakemelding på og forbedre tjenesteytelsen over tid.

En vanlig tilnærming er å bruke tjenestelogger for å forstå ulike nivåer av nøyaktighet. Disse loggene kan hjelpe datavitenskapsteamet med å identifisere og forstå ethvert behov for omskolering av modellen. Organisasjonen din kan velge omskoleringsmekanismen – den kan være kvartalsvis, månedlig eller basert på vitenskapelige beregninger, for eksempel når nøyaktigheten faller under en gitt terskel.

Målet med overvåking er ikke bare å oppdage problemer, men å lukke sløyfen for å kontinuerlig foredle modeller og holde IDP-løsningen i ytelse etter hvert som det ytre miljøet utvikler seg.

Systemovervåking

Etter at du har implementert IDP-løsningen i produksjonen, er det viktig å overvåke nøkkeltall og automatiseringsytelse for å identifisere områder for forbedring. Beregningene bør inkludere forretningsberegninger og tekniske beregninger. Dette gjør at selskapet kan evaluere systemets ytelse, identifisere problemer og gjøre forbedringer av modeller, regler og arbeidsflyter over tid for å øke automatiseringshastigheten for å forstå den operasjonelle effekten.

På forretningssiden er beregninger som utvinningsnøyaktighet for viktige felt, total automatiseringshastighet som indikerer prosentandelen av dokumenter behandlet uten menneskelig innblanding, og gjennomsnittlig behandlingstid per dokument avgjørende. Disse forretningsberegningene hjelper til med å kvantifisere sluttbrukeropplevelsen og driftseffektiviteten.

Tekniske beregninger, inkludert feil- og unntaksfrekvenser som oppstår gjennom hele arbeidsflyten, er avgjørende for å spore fra et ingeniørperspektiv. De tekniske beregningene kan også overvåke på hvert nivå fra ende til annen og gi en omfattende oversikt over en kompleks arbeidsmengde. Du kan dele beregningene ned i forskjellige nivåer, for eksempel løsningsnivå, ende-til-ende arbeidsflytnivå, dokumenttypenivå, dokumentnivå, enhetsgjenkjenningsnivå og OCR-nivå.

Nå som du har gjennomgått alle spørsmålene i denne søylen, kan du vurdere de andre pilarene og utvikle en forbedringsplan for din IDP-arbeidsmengde.

konklusjonen

I dette innlegget diskuterte vi vanlige indikatorer som du kan trenge for å utføre en gjennomgang av et godt arkitektt rammeverk for ytelseseffektivitet-pilaren for din IDP-arbeidsmengde. Vi gikk deretter gjennom designprinsippene for å gi en oversikt på høyt nivå og diskutere løsningsmålet. Ved å følge disse forslagene med henvisning til IDP Well-Architected Custom Lens og ved å gjennomgå spørsmålene etter fokusområde, bør du nå ha en prosjektforbedringsplan.

---

Om forfatterne

Mia Chang er en ML Specialist Solutions Architect for Amazon Web Services. Hun jobber med kunder i EMEA og deler beste praksis for å kjøre AI/ML-arbeidsbelastninger på skyen med bakgrunnen hennes innen anvendt matematikk, informatikk og AI/ML. Hun fokuserer på NLP-spesifikke arbeidsmengder, og deler sin erfaring som konferansetaler og bokforfatter. På fritiden liker hun å gå tur, brettspill og brygge kaffe.

Brijesh Pati er en Enterprise Solutions Architect hos AWS. Hans primære fokus er å hjelpe bedriftskunder å ta i bruk skyteknologier for arbeidsbelastningene deres. Han har bakgrunn fra applikasjonsutvikling og bedriftsarkitektur og har jobbet med kunder fra ulike bransjer som sport, finans, energi og profesjonelle tjenester. Hans interesser inkluderer serverløse arkitekturer og AI/ML.

Rui Cardoso er partnerløsningsarkitekt hos Amazon Web Services (AWS). Han fokuserer på AI/ML og IoT. Han jobber med AWS-partnere og støtter dem i å utvikle løsninger i AWS. Når han ikke jobber, liker han å sykle, gå på tur og lære nye ting.

Tim Condello er en senior arkitekt for kunstig intelligens (AI) og maskinlæring (ML) spesialistløsninger hos Amazon Web Services (AWS). Hans fokus er naturlig språkbehandling og datasyn. Tim liker å ta kundeideer og gjøre dem om til skalerbare løsninger.

Sherry Ding er en senior arkitekt for kunstig intelligens (AI) og maskinlæring (ML) spesialistløsninger hos Amazon Web Services (AWS). Hun har lang erfaring innen maskinlæring med doktorgrad i informatikk. Hun jobber hovedsakelig med kunder i offentlig sektor på ulike AI/ML-relaterte forretningsutfordringer, og hjelper dem med å akselerere sin maskinlæringsreise på AWS Cloud. Når hun ikke hjelper kunder, liker hun utendørsaktiviteter.

Suyin Wang er AI/ML Specialist Solutions Architect hos AWS. Hun har en tverrfaglig utdanningsbakgrunn innen maskinlæring, finansiell informasjonstjeneste og økonomi, sammen med mange års erfaring med å bygge datavitenskap og maskinlæringsapplikasjoner som løste forretningsproblemer i den virkelige verden. Hun liker å hjelpe kunder med å identifisere de riktige forretningsspørsmålene og bygge de riktige AI/ML-løsningene. På fritiden elsker hun å synge og lage mat.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/build-well-architected-idp-solutions-with-a-custom-lens-part-4-performance-efficiency/