Hvordan CCC Intelligent Solutions skapte en tilpasset tilnærming for hosting av komplekse AI-modeller ved hjelp av Amazon SageMaker

Dette innlegget er skrevet av Christopher Diaz, Sam Kinard, Jaime Hidalgo og Daniel Suarez fra CCC Intelligent Solutions.

I dette innlegget diskuterer vi hvordan CCC intelligente løsninger (CCC) kombinert Amazon SageMaker med andre AWS-tjenester for å lage en tilpasset løsning som er i stand til å være vert for typene komplekse kunstige intelligens (AI)-modeller som er tenkt. CCC er en ledende programvare-som-en-tjeneste (SaaS)-plattform for eiendoms- og skadeforsikringsøkonomi på flere billioner dollar som driver operasjoner for forsikringsselskaper, reparatører, bilprodusenter, deleleverandører, långivere og mer. CCC-skyteknologi kobler sammen mer enn 30,000 XNUMX virksomheter som digitaliserer virksomhetskritiske arbeidsflyter, handel og kundeopplevelser. En pålitelig leder innen AI, Internet of Things (IoT), kundeopplevelse og nettverks- og arbeidsflytadministrasjon, leverer CCC innovasjoner som holder folks liv fremover når det betyr mest.

Utfordringen

CCC behandler mer enn $1 billioner kravtransaksjoner årlig. Ettersom selskapet fortsetter å utvikle seg for å integrere AI i sin eksisterende og nye produktkatalog, krever dette sofistikerte tilnærminger for å trene og distribuere ensemblemodeller for multimodal maskinlæring (ML) for å løse komplekse forretningsbehov. Dette er en klasse med modeller som innkapsler proprietære algoritmer og fagdomeneekspertise som CCC har finpusset opp gjennom årene. Disse modellene bør være i stand til å innta nye lag med nyanserte data og kunderegler for å skape enkelt prediksjonsresultater. I dette blogginnlegget vil vi lære hvordan CCC utnyttet Amazon SageMaker-hosting og andre AWS-tjenester til å distribuere eller være vert for flere multimodale modeller i en ensemble-inferenspipeline.

Som vist i følgende diagram, er et ensemble en samling av to eller flere modeller som er orkestrert til å kjøre på en lineær eller ikke-lineær måte for å produsere en enkelt prediksjon. Når de stables lineært, kan de individuelle modellene til et ensemble påkalles direkte for spådommer og senere konsolideres for forening. Noen ganger kan ensemblemodeller også implementeres som en seriell inferensrørledning.

For vårt bruk er ensemblerørledningen strengt tatt ikke-lineær, som vist i følgende diagram. Ikke-lineære ensemblerørledninger er teoretisk direkte asykliske grafer (DAG). For vårt brukstilfelle hadde denne DAG-rørledningen både uavhengige modeller som kjøres parallelt (tjenestene B, C) og andre modeller som bruker prediksjoner fra tidligere trinn (tjeneste D).

En praksis som kommer ut av den forskningsdrevne kulturen ved CCC er den kontinuerlige gjennomgangen av teknologier som kan utnyttes for å gi mer verdi til kundene. Da CCC møtte denne ensembleutfordringen, lanserte ledelsen et proof-of-concept (POC)-initiativ for å grundig vurdere tilbudene fra AWS for å finne ut, spesifikt, om Amazon SageMaker og andre AWS-verktøy kunne administrere hosting av individuelle AI-modeller i komplekse, ikke-lineære ensembler.

Ensemblet forklarte: I denne sammenhengen er et ensemble en gruppe på 2 eller flere AI-modeller som jobber sammen for å produsere 1 samlet prediksjon.

Spørsmål som driver forskningen

Kan Amazon SageMaker brukes til å være vert for komplekse ensembler av AI-modeller som jobber sammen for å gi én samlet prediksjon? I så fall, kan SageMaker tilby andre fordeler ut av boksen, som økt automatisering, pålitelighet, overvåking, automatisk skalering og kostnadsbesparende tiltak?

Å finne alternative måter å distribuere CCCs AI-modeller ved å bruke teknologiske fremskritt fra skyleverandører vil tillate CCC å bringe AI-løsninger til markedet raskere enn konkurrentene. I tillegg gir det å ha mer enn én distribusjonsarkitektur fleksibilitet når man skal finne balansen mellom kostnad og ytelse basert på forretningsprioriteringer.

Basert på kravene våre, fullførte vi følgende liste over funksjoner som en sjekkliste for en distribusjonsarkitektur i produksjonsgrad:

• Støtte for komplekse ensembler
• Garantert oppetid for alle komponenter
• Tilpassbar automatisk skalering for utplasserte AI-modeller
• Bevaring av AI-modellinngang og -utgang
• Bruksberegninger og logger for alle komponenter
• Kostnadsbesparende mekanismer

Med et flertall av CCCs AI-løsninger som er avhengige av datasynsmodeller, var det nødvendig med en ny arkitektur for å støtte bilde- og videofiler som fortsetter å øke i oppløsning. Det var et sterkt behov for å designe og implementere denne arkitekturen som en asynkron modell.

Etter sykluser med forskning og innledende benchmarking-innsats, fastslo CCC at SageMaker passet perfekt for å møte de fleste av deres produksjonskrav, spesielt den garanterte oppetiden SageMaker gir for de fleste av slutningskomponentene. Standardfunksjonen til Amazon SageMaker Asynchronous Inference-endepunkter som lagrer input/output i Amazon S3, forenkler oppgaven med å bevare data generert fra komplekse ensembler. I tillegg, med hver AI-modell som vert for sitt eget endepunkt, blir det enklere å administrere automatiske skaleringspolicyer på modell- eller endepunktnivå. Ved å forenkle administrasjonen er en potensiell kostnadsbesparende fordel ved dette at utviklingsteam kan bruke mer tid på å finjustere skaleringspolicyer for å minimere overforsyning av dataressurser.

Etter å ha bestemt oss for å fortsette med å bruke SageMaker som den sentrale komponenten i arkitekturen, innså vi også at SageMaker kan være en del av en enda større arkitektur, supplert med mange andre serverløse AWS-administrerte tjenester. Dette valget var nødvendig for å lette høyere ordens orkestrerings- og observerbarhetsbehov for denne komplekse arkitekturen.

For det første, for å fjerne begrensninger for nyttelaststørrelse og i stor grad redusere risikoen for tidsavbrudd under scenarier med høy trafikk, implementerte CCC en arkitektur som kjører spådommer asynkront ved å bruke SageMaker Asynchronous Inference-endepunkter kombinert med andre AWS-administrerte tjenester som kjernebyggesteinene. I tillegg følger brukergrensesnittet for systemet brann-og-glem designmønsteret. Med andre ord, når en bruker har lastet opp sine input til systemet, trenger ikke noe mer å gjøres. De vil bli varslet når spådommen er tilgjengelig. Figuren nedenfor illustrerer en oversikt på høyt nivå over vår asynkrone hendelsesdrevne arkitektur. I den kommende delen, la oss gjøre et dypdykk i utførelsesflyten til den utformede arkitekturen.

Steg-for-steg løsning

Trinn 1

En klient sender en forespørsel til AWS API-gateway endepunkt. Innholdet i forespørselen inneholder navnet på AI-tjenesten som de trenger en prediksjon fra og ønsket varslingsmetode.

Denne forespørselen sendes til a Lambda funksjon kalt Ny prediksjon, hvis hovedoppgaver er å:

• Sjekk om den forespurte tjenesten fra klienten er tilgjengelig.
• Tilordne en unik prediksjons-ID til forespørselen. Denne prediksjons-IDen kan brukes av brukeren til å sjekke statusen til prediksjonen gjennom hele prosessen.
• Generer en Amazon S3 forhåndssignert URL som brukeren må bruke i neste trinn for å laste opp inndatainnholdet i prediksjonsforespørselen.
• Lag en oppføring i Amazon DynamoDB med informasjonen om den mottatte forespørselen.

Lambda-funksjonen vil deretter returnere et svar gjennom API Gateway-endepunktet med en melding som inkluderer prediksjons-IDen tildelt forespørselen og Amazon S3 forhåndssignerte URL.

Trinn 2

Klienten laster sikkert opp prediksjonsinnholdet til en S3-bøtte ved å bruke den forhåndssignerte URL-en generert i forrige trinn. Inndata avhenger av AI-tjenesten og kan være sammensatt av bilder, tabelldata eller en kombinasjon av begge.

Trinn 3

S3-bøtten er konfigurert til å utløse en hendelse når brukeren laster opp inndatainnholdet. Dette varselet sendes til en Amazon SQS-kø og håndteres av en Lambda-funksjon kalt Prosessinngang. De Prosessinngang Lambda vil innhente informasjonen knyttet til den prediksjons-ID-en fra DynamoDB for å få navnet på tjenesten som forespørselen skal sendes til.

Denne tjenesten kan enten være en enkelt AI-modell, i så fall Prosessinngang Lambda vil sende en forespørsel til SageMaker-endepunktet som er vert for modellen (trinn 3-A), eller det kan være en ensemble AI-tjeneste, i så fall Prosessinngang Lambda vil sende en forespørsel til tilstandsmaskinen for trinnfunksjonene som er vert for ensemblelogikken (trinn 3-B).

I begge alternativene (enkelt AI-modell eller ensemble AI-tjeneste), når den endelige prediksjonen er klar, vil den bli lagret i den aktuelle S3-bøtten, og den som ringer vil bli varslet via metoden spesifisert i trinn 1 (mer detaljer om varsler i trinn 4).

Trinn 3-A

Hvis prediksjons-IDen er knyttet til en enkelt AI-modell, vil Prosessinngang Lambda vil sende en forespørsel til SageMaker-endepunktet som betjener modellen. I dette systemet støttes to typer SageMaker-endepunkter:

• asynkron: The Prosessinngang Lambda sender forespørselen til SageMaker asynkrone endepunkt. Den umiddelbare responsen inkluderer S3-plasseringen der SageMaker vil lagre prediksjonsutgangen. Denne forespørselen er asynkron, følger brann-og-glem-mønsteret, og blokkerer ikke utførelsen av Lambda-funksjonen.
• Synkron: The Prosessinngang Lambda sender forespørselen til SageMaker synkrone endepunkt. Siden det er en synkron forespørsel, venter Process Input på svaret, og når det er oppnådd, lagrer det det i S3 på en analog måte som SageMaker asynkrone endepunkter ville gjort.

I begge tilfeller (synkrone eller asynkrone endepunkter) behandles prediksjonen på en tilsvarende måte, og lagrer utdataene i en S3-bøtte. Når det asynkrone SageMaker-endepunktet fullfører en prediksjon, utløses en Amazon SNS-hendelse. Denne oppførselen er også replikert for synkrone endepunkter med ekstra logikk i Lambda-funksjonen.

Trinn 3-B

Hvis prediksjons-IDen er knyttet til et AI-ensemble, Prosessinngang Lambda vil sende forespørselen til trinnfunksjonen knyttet til det AI-ensemblet. Som nevnt ovenfor er et AI-ensemble en arkitektur basert på en gruppe AI-modeller som jobber sammen for å generere en enkelt samlet prediksjon. Orkestreringen av et AI-ensemble gjøres gjennom en trinnfunksjon.

Trinnfunksjonen har ett trinn per AI-tjeneste som omfatter ensemblet. Hvert trinn vil påkalle en Lambda-funksjon som vil forberede den tilsvarende AI-tjenestens inndata ved å bruke forskjellige kombinasjoner av utdatainnholdet fra tidligere AI-tjenestekall fra tidligere trinn. Den ringer deretter hver AI-tjeneste som i denne sammenhengen kan være en enkelt AI-modell eller et annet AI-ensemble.

Den samme Lambda-funksjonen, kalt GetTransformCall brukes til å håndtere de mellomliggende prediksjonene til et AI-ensemble, brukes gjennom trinnfunksjonen, men med forskjellige inngangsparametere for hvert trinn. Denne inngangen inkluderer navnet på AI-tjenesten som skal kalles. Den inkluderer også kartleggingsdefinisjonen for å konstruere input for den angitte AI-tjenesten. Dette gjøres ved å bruke en tilpasset syntaks som Lambdaen kan dekode, som oppsummert er en JSON-ordbok der verdiene skal erstattes med innholdet fra de tidligere AI-spådommene. Lambdaen vil laste ned disse tidligere spådommene fra Amazon S3.

I hvert trinn GetTransformCall Lambda leser fra Amazon S3 de tidligere utgangene som trengs for å bygge inndataene til den spesifiserte AI-tjenesten. Den vil da påkalle Ny prediksjon Lambdakode som tidligere ble brukt i trinn 1 og oppgi tjenestenavnet, tilbakeringingsmetoden ("trinnfunksjonen") og tokenet som er nødvendig for tilbakeringingen i forespørselsnyttelasten, som deretter lagres i DynamoDB som en ny prediksjonspost. Lambdaen lagrer også den opprettede inngangen til det trinnet i en S3-bøtte. Avhengig av om det stadiet er en enkelt AI-modell eller et AI-ensemble, sender Lambdaen en forespørsel til et SageMaker-endepunkt eller en annen trinnfunksjon som administrerer et AI-ensemble som er en avhengighet av overordnet ensemble.

Når forespørselen er gjort, går trinnfunksjonen inn i en ventende tilstand til den mottar tilbakeringingstokenet som indikerer at den kan gå til neste trinn. Handlingen med å sende et tilbakeringingstoken utføres av en Lambda-funksjon kalt varslinger (mer detaljer i trinn 4) når den mellomliggende prediksjonen er klar. Denne prosessen gjentas for hvert trinn definert i trinnfunksjonen til den endelige prediksjonen er klar.

Trinn 4

Når en prediksjon er klar og lagret i S3-bøtten, utløses en SNS-varsling. Denne hendelsen kan utløses på forskjellige måter avhengig av flyten:

1. Automatisk når et SageMaker asynkront endepunkt fullfører en prediksjon.
2. Som det aller siste trinnet i trinnfunksjonen.
3. By Prosessinngang or GetTransformCall Lambda når et synkront SageMaker-endepunkt har returnert en prediksjon.

For B og C lager vi en SNS-melding som ligner på det A sender automatisk.

En Lambda-funksjon kalt varsler abonnerer på dette SNS-emnet. Varslene Lambda vil få informasjonen relatert til prediksjons-IDen fra DynamoDB, oppdatere oppføringen med statusverdi til "fullført" eller "feil", og utføre den nødvendige handlingen avhengig av tilbakeringingsmodusen som er lagret i databaseposten.

Hvis denne prediksjonen er en mellomprediksjon for et AI-ensemble, som beskrevet i trinn 3-B, vil tilbakeringingsmodusen knyttet til denne prediksjonen være "trinnfunksjon", og databaseposten vil ha et tilbakeringingstoken knyttet til det spesifikke trinnet i trinnfunksjon. Varslene Lambda vil ringe til AWS Step Functions API ved å bruke metoden "SendTaskSuccess" eller "SendTaskFailure." Dette vil tillate trinnfunksjonen å fortsette til neste trinn eller avslutte.

Hvis prediksjonen er den endelige utgangen av trinnfunksjonen og tilbakeringingsmodusen er "Webhook" [eller e-post, meldingsmeglere (Kafka), etc.], vil Lambda-varslene varsle klienten på den angitte måten. Når som helst kan brukeren be om status for sin prediksjon. Forespørselen må inkludere prediksjons-ID-en som ble tildelt i trinn 1 og peke på riktig URL i API-gatewayen for å rute forespørselen til Lambda-funksjonen kalt resultater.

Resultatene Lambda vil sende en forespørsel til DynamoDB, innhente status for forespørselen og returnere informasjonen til brukeren. Hvis statusen til spådommen er feil, vil de relevante detaljene om feilen inkluderes i svaret. Hvis prediksjonsstatusen er suksess, vil en S3 forhåndssignert URL returneres slik at brukeren kan laste ned prediksjonsinnholdet.

Resultater

Foreløpige ytelsestestresultater er lovende og støtter CCC for å utvide implementeringen av denne nye distribusjonsarkitekturen.

Bemerkelsesverdige observasjoner:

• Tester avslører styrke i å behandle batch- eller samtidige forespørsler med høy gjennomstrømning og en feilfrekvens på 0 prosent under scenarier med høy trafikk.
• Meldingskøer gir stabilitet i systemet under plutselige tilstrømninger av forespørsler inntil skaleringstriggere kan levere ekstra dataressurser. Når trafikken økte med 3 ganger, økte gjennomsnittlig forespørselsforsinkelse bare med 5 prosent.
• Prisen på stabilitet er økt latens på grunn av kommunikasjonsoverhead mellom de ulike systemkomponentene. Når brukertrafikk er over grunnlinjeterskelen, kan den ekstra ventetiden delvis reduseres ved å tilby flere dataressurser hvis ytelse er høyere prioritet fremfor kostnad.
• SageMakers asynkrone slutningsendepunkter lar forekomsttellingen skaleres til null mens endepunktet holdes aktivt for å motta forespørsler. Denne funksjonaliteten gjør at distribusjoner kan fortsette å kjøre uten å pådra seg beregningskostnader og skalere opp fra null når det er nødvendig i to scenarier: tjenestedistribusjoner som brukes i lavere testmiljøer og de som har minimal trafikk uten å kreve umiddelbar behandling.

konklusjonen

Som observert under POC-prosessen, gir det innovative designet i fellesskap skapt av CCC og AWS et solid grunnlag for å bruke Amazon SageMaker med andre AWS-administrerte tjenester for å være vert for komplekse multimodale AI-ensembler og orkestrere inferensrørledninger effektivt og sømløst. Ved å utnytte Amazon SageMakers out-of-the-box funksjoner som Asynchronous Inference, har CCC flere muligheter til å fokusere på spesialiserte forretningskritiske oppgaver. I ånden til CCCs forskningsdrevne kultur, vil denne nye arkitekturen fortsette å utvikle seg ettersom CCC leder veien videre, sammen med AWS, i å slippe løs kraftige nye AI-løsninger for klienter.

For detaljerte trinn for hvordan du oppretter, påkaller og overvåker asynkrone inferensendepunkter, se dokumentasjon, som også inneholder en prøve notatbok for å hjelpe deg i gang. For prisinformasjon, besøk Amazon SageMaker-priser.

For eksempler på bruk av asynkron inferens med ustrukturerte data som datasyn og naturlig språkbehandling (NLP), se Kjør slutninger for datasyn på store videoer med Amazon SageMaker asynkrone endepunkter og Forbedre forskning med høy verdi med Hugging Face og Amazon SageMaker asynkrone inferensendepunkterHhv.

---

Om forfatterne

Christopher Diaz er en ledende R&D-ingeniør hos CCC Intelligent Solutions. Som medlem av R&D-teamet har han jobbet med en rekke prosjekter som strekker seg fra ETL-verktøy, backend-webutvikling, samarbeid med forskere for å trene AI-modeller på distribuerte systemer, og tilrettelegging for levering av nye AI-tjenester mellom forsknings- og driftsteam. Hans nylige fokus har vært på å forske på skyverktøyløsninger for å forbedre ulike aspekter av selskapets livssyklus for utvikling av AI-modeller. På fritiden liker han å prøve nye restauranter i hjembyen Chicago og samle så mange LEGO-sett som hjemmet hans får plass til. Christopher fikk sin Bachelor of Science in Computer Science fra Northeastern Illinois University.

Emmy Award-vinner Sam Kinard er Senior Manager of Software Engineering hos CCC Intelligent Solutions. Basert i Austin, Texas, krangler han AI Runtime Team, som er ansvarlig for å betjene CCCs AI-produkter med høy tilgjengelighet og stor skala. På fritiden liker Sam å være søvnmangel på grunn av sine to fantastiske barn. Sam har en Bachelor of Science in Computer Science og en Bachelor of Science in Mathematics fra University of Texas i Austin.

Jaime Hidalgo er senior systemingeniør hos CCC Intelligent Solutions. Før han begynte i AI-forskningsteamet, ledet han selskapets globale migrering til Microservices Architecture, design, bygging og automatisering av infrastrukturen i AWS for å støtte utrullingen av skyprodukter og -tjenester. For tiden bygger og støtter han en lokal datasenterklynge bygget for AI-opplæring, og designer og bygger også skyløsninger for selskapets fremtid for AI-forskning og -distribusjon.

Daniel Suarez er datavitenskapsingeniør ved CCC Intelligent Solutions. Som medlem av AI Engineering-teamet jobber han med automatisering og klargjøring av AI-modeller i produksjon, evaluering og overvåking av metrikk og andre aspekter ved ML-operasjoner. Daniel fikk en mastergrad i informatikk fra Illinois Institute of Technology og en master- og bachelorgrad i telekommunikasjonsteknikk fra Universidad Politecnica de Madrid.

Arunprasath Shankar er en senior AI/ML-spesialistløsningsarkitekt med AWS, og hjelper globale kunder med å skalere AI-løsningene sine effektivt og effektivt i skyen. På fritiden liker Arun å se sci-fi-filmer og høre på klassisk musikk.

Justin McWhirter er Solutions Architect Manager hos AWS. Han jobber med et team av fantastiske løsningsarkitekter som hjelper kunder med å få en positiv opplevelse mens de tar i bruk AWS-plattformen. Når han ikke er på jobb, liker Justin å spille videospill med de to guttene sine, ishockey og kjøre offroad i jeepen.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/how-ccc-intelligent-solutions-created-a-custom-approach-for-hosting-complex-ai-models-using-amazon-sagemaker/