Rakenna hyvin suunniteltuja IDP-ratkaisuja mukautetun objektiivin avulla – Osa 4: Suorituskykytehokkuus | Amazon Web Services

Kun asiakkaalla on tuotantovalmis älykäs asiakirjojen käsittely (IDP) työtaakkaa, saamme usein pyyntöjä hyvin suunniteltua tarkastusta varten. Yritysratkaisun rakentamiseksi kehittäjän resurssit, kustannukset, aika ja käyttäjäkokemus on tasapainotettava, jotta haluttu liiketoimintatulos saavutetaan. The Hyvin suunniteltu AWS-kehys tarjoaa organisaatioille järjestelmällisen tavan oppia toiminnallisia ja arkkitehtonisia parhaita käytäntöjä luotettavien, turvallisten, tehokkaiden, kustannustehokkaiden ja kestävien työkuormien suunnittelua ja käyttöä varten pilvessä.

IDP Well-Architected Custom Lens noudattaa AWS Well-Architected Frameworkia, tarkastelee ratkaisua kuudella pilarilla tietyn tekoälyn tai koneoppimisen (ML) käyttötapauksen tarkkuudella ja tarjoaa ohjeita yleisten haasteiden ratkaisemiseksi. IDP:n hyvin suunniteltu mukautettu linssi Hyvin suunniteltu työkalu sisältää kysymyksiä jokaisesta pilarista. Vastaamalla näihin kysymyksiin voit tunnistaa mahdolliset riskit ja ratkaista ne noudattamalla parannussuunnitelmaasi.

Tämä postaus keskittyy Suorituskyvyn tehokkuuden pilari IDP-työkuormasta. Sukellamme syvälle ratkaisun suunnitteluun ja toteutukseen optimoidaksemme suorituskyvyn, latenssin ja yleisen suorituskyvyn. Aloitamme keskustelemalla joistakin yleisistä indikaattoreista, joiden perusteella sinun pitäisi tehdä hyvin suunniteltu katsaus, ja esittelemme peruslähestymistapoja suunnitteluperiaatteiden kanssa. Sitten käymme läpi jokaisen painopistealueen teknisestä näkökulmasta.

Jotta voit seurata tätä viestiä, sinun tulee tutustua tämän sarjan aikaisempiin viesteihin (Osa 1 ja Osa 2) ja ohjeet Ohjeet älykkääseen asiakirjojen käsittelyyn AWS:ssä. Nämä resurssit esittelevät yhteisiä AWS-palveluita IDP-työkuormille ja ehdotetuille työnkuluille. Tämän tiedon avulla olet nyt valmis oppimaan lisää työkuormasi tuotannosta.

Yleiset indikaattorit

Seuraavat ovat yleisiä indikaattoreita, joiden perusteella sinun tulee suorittaa suorituskykytehokkuuspilarin hyvin suunniteltu kehys:

• Korkea latenssi – Kun optisen merkintunnistuksen (OCR), entiteetin tunnistuksen tai päästä päähän -työnkulun latenssi kestää kauemmin kuin edellinen vertailuarvo, tämä voi olla merkki siitä, että arkkitehtuurin suunnittelu ei kata kuormitustestausta tai virheiden käsittelyä.
• Toistuva kuristus – Saatat kokea AWS-palveluiden, kuten esim Amazonin teksti pyyntörajojen vuoksi. Tämä tarkoittaa, että arkkitehtuuria on säädettävä tarkistamalla arkkitehtuurin työnkulku, synkroninen ja asynkroninen toteutus, tapahtumat sekunnissa (TPS) ja paljon muuta.
• Virheenkorjaus vaikeudet – Kun asiakirjaprosessissa on vika, sinulla ei ehkä ole tehokasta tapaa tunnistaa, missä virhe sijaitsee työnkulussa, mihin palveluun se liittyy ja miksi virhe tapahtui. Tämä tarkoittaa, että järjestelmä ei näe lokeja ja vikoja. Harkitse kaukomittaustietojen kirjaussuunnittelun tarkistamista ja infrastruktuurin lisäämistä koodina (IaC), kuten asiakirjankäsittelyputket, ratkaisuun.

indikaattorit	Kuvaus	Arkkitehtoninen aukko
Korkea viive	Tekstintunnistus, kokonaisuuden tunnistus tai päästä päähän työnkulun viive ylittää aiemman vertailuarvon	Kuormitustesti Virhe käsittely
Toistuva kuristus	AWS-palvelujen, kuten Amazon Textractin, rajoittaminen pyyntörajoitusten vuoksi	Synkronointi vs async TPS-laskenta
Vaikea virheenkorjaus	Ei näkyvyyttä asiakirjojen käsittelyhäiriöiden sijainnista, syystä ja syystä	Hakkuusuunnittelu Asiakirjojen käsittelyputket

Pääperiaatteemme

Tässä viestissä käsittelemme kolmea suunnitteluperiaatetta: monimutkaisten AI-tehtävien delegointi, IaC-arkkitehtuurit ja palvelimettomat arkkitehtuurit. Kun kohtaat kompromissin kahden toteutuksen välillä, voit tarkastella suunnitteluperiaatteita uudelleen organisaatiosi liiketoimintaprioriteettien kanssa, jotta voit tehdä päätöksiä tehokkaasti.

• Monimutkaisten tekoälytehtävien delegointi – Voit mahdollistaa nopeamman tekoälyn käyttöönoton organisaatiossasi siirtämällä ML-mallin kehittämisen elinkaaren hallittuihin palveluihin ja hyödyntämällä AWS:n tarjoamaa mallikehitystä ja infrastruktuuria. Sen sijaan, että vaatisit tietotekniikka- ja IT-tiimejäsi rakentamaan ja ylläpitämään tekoälymalleja, voit käyttää valmiiksi koulutettuja tekoälypalveluita, jotka voivat automatisoida tehtäviä puolestasi. Näin tiimisi voivat keskittyä arvokkaampaan työhön, joka erottaa yrityksesi, kun taas pilvipalveluntarjoaja hoitaa AI-mallien koulutuksen, käyttöönoton ja skaalauksen monimutkaisuuden.
• IaC-arkkitehtuurit – IDP-ratkaisua käytettäessä ratkaisu sisältää useita tekoälypalveluita, jotka suorittavat päästä päähän -työnkulun kronologisesti. Voit suunnitella ratkaisun työnkulkuputkistojen avulla AWS-vaihetoiminnot parantaa vikasietoisuutta, rinnakkaista käsittelyä, näkyvyyttä ja skaalautuvuutta. Näiden etujen avulla voit optimoida taustalla olevien tekoälypalvelujen käytön ja kustannukset.
• serverless arkkitehtuurit – IDP on usein tapahtumalähtöinen ratkaisu, jonka käynnistävät käyttäjien lataukset tai ajoitetut työt. Ratkaisua voidaan skaalata vaakatasossa nostamalla tekoälypalvelujen puhelun hintoja, AWS Lambdaja muut asiaan liittyvät palvelut. Palvelimeton lähestymistapa tarjoaa skaalautuvuuden ilman resurssien liiallista hallintaa, mikä estää tarpeettomat kulut. Palvelimeton suunnittelun takana oleva valvonta auttaa havaitsemaan suorituskykyongelmia.

Nämä kolme suunnitteluperiaatetta mielessään organisaatiot voivat luoda tehokkaan perustan tekoälyn/ML:n käyttöönotolle pilvialustoille. Delegoimalla monimutkaisuutta, ottamalla käyttöön joustavaa infrastruktuuria ja suunnittelemalla mittakaavaa organisaatiot voivat optimoida AI/ML-ratkaisunsa.

Seuraavissa osioissa keskustelemme, kuinka vastata yleisiin haasteisiin teknisten painopistealueiden osalta.

Kohdennusalueet

Suorituskykytehokkuutta arvioitaessa tarkastelemme ratkaisua viideltä painopistealueelta: arkkitehtuurin suunnittelu, tiedonhallinta, virheiden käsittely, järjestelmän valvonta ja mallien valvonta. Näiden painopistealueiden avulla voit suorittaa arkkitehtuuritarkistuksen eri näkökulmista parantaaksesi AI/ML-projektin, datan, mallin tai liiketoimintatavoitteen kolmen komponentin tehokkuutta, havaittavuutta ja skaalautuvuutta.

Arkkitehtuurisuunnittelu

Käymällä läpi tämän painopistealueen kysymykset, tarkistat nykyistä työnkulkua ja näet, noudattaako se parhaita käytäntöjä. Ehdotettu työnkulku tarjoaa yhteisen mallin, jota organisaatiot voivat seurata, ja estää kokeilu- ja erehdyskustannukset.

Perustuu ehdotettu arkkitehtuuri, työnkulku seuraa kuutta vaihetta: tietojen kerääminen, luokittelu, poimiminen, rikastaminen, tarkastelu ja validointi sekä kulutus. Aiemmin käsitellyissä yleisissä indikaattoreissa kaksi kolmesta tulee arkkitehtuurin suunnitteluongelmista. Tämä johtuu siitä, että kun aloitat projektin improvisoidulla lähestymistavalla, saatat kohdata projektin rajoituksia yrittäessäsi mukauttaa infrastruktuurisi ratkaisuusi. Arkkitehtuurisuunnittelun katsauksella improvisoitu suunnittelu voidaan irrottaa vaiheiksi, ja jokainen niistä voidaan arvioida ja järjestellä uudelleen.

Voit säästää aikaa, rahaa ja työtä toteuttamalla luokitukset työnkulussasi, ja asiakirjat menevät loppupään sovelluksiin ja API:ihin asiakirjatyypin perusteella. Tämä parantaa asiakirjaprosessin havaittavuutta ja tekee ratkaisusta yksinkertaisen ylläpidettävän uusia dokumenttityyppejä lisättäessä.

Tiedonhallinta

IDP-ratkaisun suorituskyky sisältää latenssin, suorituskyvyn ja päästä päähän -käyttökokemuksen. Asiakirjan ja sen poimittujen tietojen hallinta ratkaisussa on avain tietojen johdonmukaisuuteen, turvallisuuteen ja yksityisyyteen. Lisäksi ratkaisun tulee käsitellä suuria datamääriä alhaisella latenssilla ja suurella suorituskyvyllä.

Kun käyt läpi tämän painopistealueen kysymyksiä, tutustut asiakirjan työnkulkuun. Tämä sisältää tietojen käsittelyn, tietojen esikäsittelyn, asiakirjojen muuntamisen Amazon Textractin hyväksymiksi asiakirjatyypeiksi, saapuvien asiakirjavirtojen käsittelyn, asiakirjojen reitityksen tyypin mukaan sekä kulunvalvonta- ja säilytyskäytäntöjen toteuttamisen.

Esimerkiksi tallentamalla asiakirjan eri käsittelyvaiheisiin voit tarvittaessa kääntää käsittelyn edelliseen vaiheeseen. Tietojen elinkaari varmistaa luotettavuuden ja työmäärän noudattamisen. Käyttämällä Amazon Textract Service Kiintiöt Laskin (katso seuraava kuvakaappaus), asynkroniset ominaisuudet Amazon Textractissa, Lambdassa, Step Functionsissa, Amazonin yksinkertainen jonopalvelu (Amazon SQS) ja Amazonin yksinkertainen ilmoituspalvelu (Amazon SNS), organisaatiot voivat automatisoida ja skaalata asiakirjojen käsittelytehtäviä vastaamaan tiettyjä työkuormitustarpeita.

Virheiden käsittely

Tehokas virheiden käsittely on ratkaisevan tärkeää asiakirjaprosessin tilan seurannassa, ja se antaa käyttöryhmälle aikaa reagoida kaikkiin epänormaaliin toimiin, kuten odottamattomiin asiakirjavolyymiin, uusiin asiakirjatyyppeihin tai muihin kolmannen osapuolen palveluiden suunnittelemattomiin ongelmiin. Organisaation näkökulmasta oikea virheiden käsittely voi parantaa järjestelmän käytettävyyttä ja suorituskykyä.

Voit jakaa virheiden käsittelyn kahteen keskeiseen osaan:

• AWS-palvelun määritys – Voit ottaa käyttöön uudelleenyrityslogiikan eksponentiaalisella perääntymisellä käsitelläksesi ohimeneviä virheitä, kuten kuristusta. Kun aloitat käsittelyn kutsumalla asynkronisen Start*-toiminnon, kuten AloitaDocumentTextDetection, voit määrittää, että pyynnön valmistumistila julkaistaan ​​SNS-aiheessa Ilmoituskanava kokoonpano. Tämä auttaa sinua välttämään rajoituksia API-kutsuissa Get*-sovellusliittymien kyselyn vuoksi. Voit myös ottaa käyttöön hälytyksiä amazonin pilvikello ja laukaisee hälytyksen, kun esiintyy epätavallisia virhepiikkejä.
• Virheilmoituksen parannus – Tämä sisältää yksityiskohtaiset viestit, joissa on asianmukainen yksityiskohtaisuus virhetyypin mukaan, ja kuvaukset virheenkäsittelyvastauksista. Oikealla virheenkäsittelyasetuksella järjestelmät voivat olla joustavampia ottamalla käyttöön yleisiä malleja, kuten automaattisen uudelleenyritysten ajoittaisten virheiden käyttämisen, katkaisijoiden käyttämisen peräkkäisten vikojen käsittelyssä ja valvontapalveluita saadakseen käsityksen virheistä. Tämä mahdollistaa ratkaisun tasapainon uudelleenyritysrajojen välillä ja estää loputtomia piirisilmukoita.

Mallin seuranta

ML-mallien suorituskykyä seurataan ajan mittaan heikkenemisen varalta. Tietojen ja järjestelmän olosuhteiden muuttuessa mallin suorituskyky- ja tehokkuusmittareita seurataan sen varmistamiseksi, että uudelleenkoulutus suoritetaan tarvittaessa.

IDP-työnkulun ML-malli voi olla OCR-malli, kokonaisuuden tunnistusmalli tai luokitusmalli. Malli voi tulla AWS AI -palvelusta, avoimen lähdekoodin mallista Amazon Sage Maker, Amazonin kallioperä, tai muut kolmannen osapuolen palvelut. Sinun on ymmärrettävä kunkin palvelun rajoitukset ja käyttötapaukset, jotta voit tunnistaa tapoja parantaa mallia ihmisen palautteen avulla ja parantaa palvelun suorituskykyä ajan myötä.

Yleinen lähestymistapa on käyttää palvelulokeja eri tarkkuustasojen ymmärtämiseen. Nämä lokit voivat auttaa datatieteen tiimiä tunnistamaan ja ymmärtämään mallin uudelleenkoulutuksen tarpeen. Organisaatiosi voi valita uudelleenkoulutusmekanismin – se voi olla neljännesvuosittain, kuukausittain tai perustua tieteellisiin mittareihin, kuten silloin, kun tarkkuus putoaa tietyn kynnyksen alle.

Monitoroinnin tavoitteena ei ole vain havaita ongelmia, vaan sulkea silmukka mallien jatkuvaan tarkentamiseen ja IDP-ratkaisun pitämiseen toiminnassa ulkoisen ympäristön kehittyessä.

Järjestelmän valvonta

Kun olet ottanut IDP-ratkaisun käyttöön tuotannossa, on tärkeää seurata keskeisiä mittareita ja automaation suorituskykyä, jotta voidaan tunnistaa parannuskohteet. Mittareihin tulee sisältyä liiketoimintamittareita ja teknisiä mittareita. Näin yritys voi arvioida järjestelmän suorituskykyä, tunnistaa ongelmat ja tehdä parannuksia malleihin, sääntöihin ja työnkulkuihin ajan mittaan lisätäkseen automaationopeutta ja ymmärtääkseen toiminnan vaikutuksia.

Liiketoiminnan kannalta tärkeimmät mittarit, kuten tärkeiden kenttien poimintatarkkuus, yleinen automaatioaste, joka ilmaisee ilman ihmisen väliintuloa käsiteltyjen asiakirjojen prosenttiosuuden, ja keskimääräinen käsittelyaika asiakirjaa kohden ovat tärkeitä. Nämä liiketoimintamittarit auttavat mittaamaan loppukäyttäjien kokemuksia ja toiminnan tehokkuutta.

Tekniset mittarit, mukaan lukien virhe- ja poikkeusluvut koko työnkulun aikana, ovat välttämättömiä suunnittelun kannalta. Tekniset mittarit voivat myös seurata jokaista tasoa päästä päähän ja tarjota kattavan kuvan monimutkaisesta työmäärästä. Voit jakaa mittarit eri tasoille, kuten ratkaisutasolle, päästä päähän työnkulun tasolle, asiakirjatyyppitasolle, asiakirjatasolle, kokonaisuuden tunnistustasolle ja tekstintunnistustasolle.

Nyt kun olet käynyt läpi kaikki tämän pilarin kysymykset, voit arvioida muita pilareita ja kehittää parannussuunnitelman sisäisten pakolaisten työtaakkaasi varten.

Yhteenveto

Tässä viestissä keskustelimme yleisistä indikaattoreista, joita saatat joutua suorittamaan Performance Efficiency -pilarin hyvin rakennetun kehyksen tarkastelun IDP-työkuormasi osalta. Kävimme sitten läpi suunnittelun periaatteet tarjotaksemme korkean tason yleiskatsauksen ja keskustellaksemme ratkaisun tavoitteesta. Noudattamalla näitä ehdotuksia viitaten IDP:n hyvin suunniteltuun mukautettuun linssiin ja tarkastelemalla kysymyksiä painopistealueittain, sinulla pitäisi nyt olla projektin parannussuunnitelma.

---

Tietoja Tekijät

Mia Chang on ML Specialist Solutions -arkkitehti Amazon Web Servicesille. Hän työskentelee asiakkaiden kanssa EMEA-alueella ja jakaa parhaita käytäntöjä AI/ML-työkuormien suorittamiseen pilvessä taustansa soveltavan matematiikan, tietojenkäsittelytieteen ja AI/ML:n alalla. Hän keskittyy NLP-spesifisiin työkuormiin ja jakaa kokemuksiaan konferenssipuhujana ja kirjailijana. Vapaa-ajallaan hän harrastaa patikointia, lautapelejä ja kahvin keittämistä.

Brijesh Pati on yritysratkaisujen arkkitehti AWS:ssä. Hänen ensisijaisena tavoitteenaan on auttaa yritysasiakkaita ottamaan käyttöön pilviteknologioita työkuormitukseensa. Hänellä on tausta sovelluskehityksestä ja yritysarkkitehtuurista, ja hän on työskennellyt asiakkaiden kanssa eri toimialoilta, kuten urheilu-, rahoitus-, energia- ja asiantuntijapalvelut. Hänen kiinnostuksen kohteitaan ovat palvelimettomat arkkitehtuurit ja AI/ML.

Rui Cardoso on kumppaniratkaisuarkkitehti Amazon Web Servicesissä (AWS). Hän keskittyy AI/ML:hen ja IoT:hen. Hän työskentelee AWS Partnersin kanssa ja tukee heitä AWS:n ratkaisujen kehittämisessä. Kun hän ei ole töissä, hän nauttii pyöräilystä, patikoinnista ja uusien asioiden oppimisesta.

Tim Condello on vanhempi tekoälyn (AI) ja koneoppimisen (ML) asiantuntijaratkaisujen arkkitehti Amazon Web Servicesissä (AWS). Hän keskittyy luonnolliseen kielenkäsittelyyn ja tietokonenäköön. Tim nauttii asiakkaiden ideoiden ottamisesta ja muuttamisesta skaalautuviksi ratkaisuiksi.

Sherry Ding on vanhempi tekoälyn (AI) ja koneoppimisen (ML) asiantuntijaratkaisujen arkkitehti Amazon Web Servicesissä (AWS). Hänellä on laaja kokemus koneoppimisesta tietojenkäsittelytieteen tohtoriksi. Hän työskentelee pääasiassa julkisen sektorin asiakkaiden kanssa erilaisissa tekoälyyn/ML:ään liittyvissä liiketoimintahaasteissa, mikä auttaa heitä nopeuttamaan koneoppimismatkaansa AWS-pilvessä. Kun hän ei auta asiakkaita, hän nauttii ulkoilusta.

Suyin Wang on AI/ML Specialist Solutions -arkkitehti AWS:ssä. Hänellä on monitieteinen koulutustausta koneoppimisesta, taloustietopalvelusta ja taloustieteestä sekä vuosien kokemus datatieteen ja koneoppimisen sovellusten rakentamisesta, jotka ratkaisivat todellisia liiketoiminnan ongelmia. Hän nauttii auttaa asiakkaita löytämään oikeat liiketoimintakysymykset ja rakentamaan oikeita tekoäly/ML-ratkaisuja. Vapaa-ajallaan hän rakastaa laulamista ja ruoanlaittoa.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://aws.amazon.com/blogs/machine-learning/build-well-architected-idp-solutions-with-a-custom-lens-part-4-performance-efficiency/