Hur CCC Intelligent Solutions skapade ett anpassat tillvägagångssätt för att vara värd för komplexa AI-modeller med Amazon SageMaker

Det här inlägget är skrivet av Christopher Diaz, Sam Kinard, Jaime Hidalgo och Daniel Suarez från CCC Intelligent Solutions.

I det här inlägget diskuterar vi hur CCC intelligenta lösningar (CCC) kombinerat Amazon SageMaker med andra AWS-tjänster för att skapa en skräddarsydd lösning som kan vara värd för de typer av komplexa artificiell intelligens (AI)-modeller som man tänkt sig. CCC är en ledande SaaS-plattform (Software-as-a-service) för fastighets- och skadeförsäkringsekonomin på flera biljoner dollar som driver verksamheten för försäkringsbolag, reparatörer, biltillverkare, delleverantörer, långivare och mer. CCC molnteknik kopplar samman mer än 30,000 XNUMX företag som digitaliserar affärskritiska arbetsflöden, handel och kundupplevelser. En pålitlig ledare inom AI, Internet of Things (IoT), kundupplevelse och nätverks- och arbetsflödeshantering, CCC levererar innovationer som håller människors liv framåt när det betyder mest.

Utmaningen

CCC behandlar mer än 1 biljon USD skadetransaktioner årligen. När företaget fortsätter att utvecklas för att integrera AI i sin befintliga och nya produktkatalog, kräver detta sofistikerade metoder för att träna och distribuera ensemblemodeller för multimodal maskininlärning (ML) för att lösa komplexa affärsbehov. Dessa är en klass av modeller som kapslar in proprietära algoritmer och ämnesdomänexpertis som CCC har finslipat genom åren. Dessa modeller bör kunna inta nya lager av nyanserad data och kundregler för att skapa enstaka förutsägelseresultat. I det här blogginlägget kommer vi att lära oss hur CCC utnyttjade Amazon SageMaker-hosting och andra AWS-tjänster för att distribuera eller vara värd för flera multimodala modeller i en ensemble-inferenspipeline.

Som visas i följande diagram är en ensemble en samling av två eller flera modeller som är orkestrerade för att köras på ett linjärt eller olinjärt sätt för att producera en enda förutsägelse. När de staplas linjärt kan de individuella modellerna av en ensemble direkt anropas för förutsägelser och senare konsolideras för enande. Ibland kan ensemblemodeller också implementeras som en seriell slutledningspipeline.

För vårt användningsfall är ensemblens pipeline strikt olinjär, som visas i följande diagram. Icke-linjära ensemblepipelines är teoretiskt direkt acykliska grafer (DAG). För vårt användningsfall hade denna DAG-pipeline både oberoende modeller som körs parallellt (Tjänster B, C) och andra modeller som använder förutsägelser från tidigare steg (Tjänst D).

En praxis som kommer ur den forskningsdrivna kulturen på CCC är den kontinuerliga översynen av teknologier som kan utnyttjas för att ge kunderna mer värde. När CCC stod inför denna ensembleutmaning, lanserade ledarskapet ett proof-of-concept (POC)-initiativ för att grundligt utvärdera erbjudandena från AWS för att specifikt upptäcka om Amazon SageMaker och andra AWS-verktyg kunde hantera värdskapet för individuella AI-modeller i komplexa, olinjära ensembler.

Ensemble förklarade: I detta sammanhang är en ensemble en grupp av 2 eller flera AI-modeller som arbetar tillsammans för att producera 1 övergripande förutsägelse.

Frågor som driver forskningen

Kan Amazon SageMaker användas för att vara värd för komplexa ensembler av AI-modeller som arbetar tillsammans för att ge en övergripande förutsägelse? Om så är fallet, kan SageMaker erbjuda andra fördelar direkt, såsom ökad automatisering, tillförlitlighet, övervakning, automatisk skalning och kostnadsbesparande åtgärder?

Att hitta alternativa sätt att distribuera CCC:s AI-modeller med hjälp av de tekniska framstegen från molnleverantörer kommer att göra det möjligt för CCC att ta ut AI-lösningar på marknaden snabbare än konkurrenterna. Att ha mer än en implementeringsarkitektur ger dessutom flexibilitet när man ska hitta balansen mellan kostnad och prestanda baserat på affärsprioriteringar.

Baserat på våra krav har vi slutfört följande lista med funktioner som en checklista för en implementeringsarkitektur i produktionsklass:

• Stöd för komplexa ensembler
• Garanterad drifttid för alla komponenter
• Anpassningsbar automatisk skalning för distribuerade AI-modeller
• Bevarande av AI-modellens input och output
• Användningsstatistik och loggar för alla komponenter
• Kostnadsbesparande mekanismer

Med en majoritet av CCC:s AI-lösningar som förlitar sig på datorseende modeller krävdes en ny arkitektur för att stödja bild- och videofiler som fortsätter att öka i upplösning. Det fanns ett stort behov av att designa och implementera denna arkitektur som en asynkron modell.

Efter cykler av forskning och inledande benchmarking ansträngningar, bestämde CCC SageMaker var en perfekt passform för att möta en majoritet av deras produktionskrav, särskilt den garanterade drifttiden SageMaker ger för de flesta av dess slutledningskomponenter. Standardfunktionen i Amazon SageMaker Asynchronous Inference endpoints som sparar in/utdata i Amazon S3 förenklar uppgiften att bevara data som genereras från komplexa ensembler. Dessutom, när varje AI-modell är värd för sin egen slutpunkt, blir det lättare att hantera automatiska skalningspolicyer på modell- eller slutpunktsnivå. Genom att förenkla hanteringen är en potentiell kostnadsbesparande fördel med detta att utvecklingsteam kan avsätta mer tid för att finjustera skalningspolicyer för att minimera överprovisionering av beräkningsresurser.

Efter att ha beslutat att fortsätta använda SageMaker som den centrala komponenten i arkitekturen, insåg vi också att SageMaker kan vara en del av en ännu större arkitektur, kompletterad med många andra serverlösa AWS-hanterade tjänster. Detta val behövdes för att underlätta de högre ordningens orkestrerings- och observerbarhetsbehov för denna komplexa arkitektur.

För det första, för att ta bort begränsningar av nyttolaststorlek och avsevärt minska risken för timeout under scenarier med hög trafik, implementerade CCC en arkitektur som kör förutsägelser asynkront med SageMaker Asynchronous Inference endpoints i kombination med andra AWS-hanterade tjänster som de viktigaste byggstenarna. Dessutom följer användargränssnittet för systemet eld-och-glöm designmönstret. Med andra ord, när en användare har laddat upp sin input till systemet behöver inget mer göras. De kommer att meddelas när förutsägelsen är tillgänglig. Figuren nedan illustrerar en översikt på hög nivå av vår asynkrona händelsedrivna arkitektur. Låt oss i det kommande avsnittet göra en djupdykning i utförandeflödet av den designade arkitekturen.

Steg-för-steg lösning

steg 1

En kund gör en begäran till AWS API-gateway slutpunkt. Innehållet i begäran innehåller namnet på AI-tjänsten från vilken de behöver en förutsägelse och den önskade metoden för meddelande.

Denna begäran skickas till a Lambda funktion kallas Ny förutsägelse, vars huvudsakliga uppgifter är att:

• Kontrollera om den efterfrågade tjänsten av kunden är tillgänglig.
• Tilldela begäran ett unikt prediktions-ID. Detta förutsägelse-ID kan användas av användaren för att kontrollera statusen för förutsägelsen under hela processen.
• Generera en Amazon S3 försignerad URL som användaren måste använda i nästa steg för att ladda upp inmatningsinnehållet i förutsägelseförfrågan.
• Skapa en post i Amazon DynamoDB med informationen om den mottagna begäran.

Lambdafunktionen kommer sedan att returnera ett svar via API Gateway-slutpunkten med ett meddelande som inkluderar det förutsägelse-ID som tilldelats förfrågan och Amazon S3 försignerade URL.

steg 2

Klienten laddar säkert upp innehållet i förutsägelseinmatningen till en S3-bucket med hjälp av den försignerade URL som genererades i föregående steg. Inmatat innehåll beror på AI-tjänsten och kan bestå av bilder, tabelldata eller en kombination av båda.

steg 3

S3-skopan är konfigurerad att utlösa en händelse när användaren laddar upp inmatat innehåll. Detta meddelande skickas till en Amazon SQS-kö och hanteras av en Lambda-funktion som kallas Processingång. De Processingång Lambda kommer att få informationen relaterad till det förutsägelse-ID:t från DynamoDB för att få namnet på tjänsten som begäran ska göras till.

Denna tjänst kan antingen vara en enda AI-modell, i vilket fall Processingång Lambda kommer att göra en begäran till SageMaker-slutpunkten som är värd för den modellen (steg 3-A), eller så kan det vara en ensemble-AI-tjänst i vilket fall Processingång Lambda kommer att göra en begäran till tillståndsmaskinen för stegfunktionerna som är värd för ensemblelogiken (steg 3-B).

I båda alternativen (enkel AI-modell eller ensemble AI-tjänst), när den slutliga förutsägelsen är klar, kommer den att lagras i lämplig S3-hink, och den som ringer kommer att meddelas via metoden som specificeras i steg 1 (mer information om aviseringar i steg 4).

Steg 3-A

Om förutsägelse-ID:t är kopplat till en enda AI-modell, Processingång Lambda kommer att göra en förfrågan till SageMaker-slutpunkten som betjänar modellen. I detta system stöds två typer av SageMaker-slutpunkter:

• Asynchronous: Den Processingång Lambda skickar begäran till SageMaker asynkrona slutpunkt. Det omedelbara svaret inkluderar S3-platsen där SageMaker kommer att spara förutsägelseutgången. Denna begäran är asynkron, följer eld-och-glöm-mönstret och blockerar inte exekveringsflödet för Lambda-funktionen.
• Synkron: Den Processingång Lambda skickar begäran till SageMakers synkrona slutpunkt. Eftersom det är en synkron begäran, väntar Process Input på svaret och när det väl erhålls lagras det i S3 på ett analogt sätt som SageMaker asynkrona slutpunkter skulle göra.

I båda fallen (synkrona eller asynkrona ändpunkter), bearbetas förutsägelsen på ett likvärdigt sätt, och utdata lagras i en S3-hink. När den asynkrona SageMaker-slutpunkten slutför en förutsägelse utlöses en Amazon SNS-händelse. Detta beteende replikeras också för synkrona slutpunkter med ytterligare logik i Lambda-funktionen.

Steg 3-B

Om prediktions-ID:t är associerat med en AI-ensemble, Processingång Lambda kommer att göra begäran till stegfunktionen som är kopplad till den AI-ensemblen. Som nämnts ovan är en AI Ensemble en arkitektur baserad på en grupp AI-modeller som arbetar tillsammans för att generera en enda övergripande förutsägelse. Orkestreringen av en AI-ensemble görs genom en stegfunktion.

Stegfunktionen har ett steg per AI-tjänst som omfattar ensemblen. Varje steg kommer att anropa en Lambda-funktion som förbereder dess motsvarande AI-tjänsts indata med hjälp av olika kombinationer av utmatningsinnehållet från tidigare AI-tjänstanrop från tidigare steg. Den ringer sedan till varje AI-tjänst som i det här sammanhanget kan vissna vara en enskild AI-modell eller en annan AI-ensemble.

Samma Lambda-funktion, kallad GetTransformCall som används för att hantera mellanförutsägelserna för en AI-ensemble används genom hela stegfunktionen, men med olika ingångsparametrar för varje steg. Denna ingång inkluderar namnet på AI-tjänsten som ska anropas. Den inkluderar också mappningsdefinitionen för att konstruera indata för den angivna AI-tjänsten. Detta görs med hjälp av en anpassad syntax som Lambdan kan avkoda, vilket sammanfattningsvis är en JSON-ordbok där värdena ska ersättas med innehållet från de tidigare AI-förutsägelserna. Lambda kommer att ladda ner dessa tidigare förutsägelser från Amazon S3.

I varje steg GetTransformCall Lambda läser från Amazon S3 de tidigare utgångar som behövs för att bygga ingången för den specificerade AI-tjänsten. Den kommer då att anropa Ny förutsägelse Lambdakod som tidigare användes i steg 1 och tillhandahåller tjänstens namn, återuppringningsmetod ("stegfunktion") och token som behövs för återuppringningen i förfrågans nyttolast, som sedan sparas i DynamoDB som en ny förutsägelsepost. Lambdan lagrar också den skapade inmatningen från det steget i en S3-hink. Beroende på om det steget är en enskild AI-modell eller en AI-ensemble, gör Lambdan en begäran till en SageMaker-slutpunkt eller en annan stegfunktion som hanterar en AI-ensemble som är ett beroende av moderensemblen.

När begäran är gjord går stegfunktionen in i ett väntande tillstånd tills den tar emot återuppringningstoken som indikerar att den kan gå till nästa steg. Åtgärden att skicka en callback-token utförs av en Lambda-funktion som anropas anmälningar (mer information i steg 4) när den mellanliggande prognosen är klar. Denna process upprepas för varje steg som definieras i stegfunktionen tills den slutliga förutsägelsen är klar.

steg 4

När en förutsägelse är klar och lagrad i S3-bucket utlöses en SNS-avisering. Denna händelse kan utlösas på olika sätt beroende på flödet:

1. Automatiskt när en SageMaker asynkron slutpunkt slutför en förutsägelse.
2. Som det allra sista steget i stegfunktionen.
3. By Processingång or GetTransformCall Lambda när en synkron SageMaker-slutpunkt har returnerat en förutsägelse.

För B och C skapar vi ett SNS-meddelande som liknar det A automatiskt skickar.

En lambdafunktion som kallas aviseringar prenumererar på detta SNS-ämne. Aviseringarna Lambda kommer att få informationen relaterad till förutsägelse-ID från DynamoDB, uppdatera posten med statusvärde till "avslutad" eller "fel" och utföra den nödvändiga åtgärden beroende på återuppringningsläget som sparats i databasposten.

Om denna förutsägelse är en mellanförutsägelse av en AI-ensemble, enligt beskrivningen i steg 3-B, kommer återuppringningsläget som är kopplat till denna förutsägelse att vara "stegfunktion", och databasposten kommer att ha en återuppringningstoken kopplad till det specifika steget i stegfunktion. Meddelandena kommer Lambda att ringa till AWS Step Functions API med metoden "SendTaskSuccess" eller "SendTaskFailure." Detta gör att stegfunktionen kan fortsätta till nästa steg eller avsluta.

Om förutsägelsen är den slutliga utmatningen av stegfunktionen och återuppringningsläget är "Webhook" [eller e-post, meddelandeförmedlare (Kafka), etc.], kommer aviseringarna Lambda att meddela klienten på det angivna sättet. När som helst kan användaren begära status för sin förutsägelse. Begäran måste innehålla det förutsägelse-ID som tilldelades i steg 1 och peka på rätt URL i API Gateway för att dirigera begäran till Lambda-funktionen som kallas resultat.

Resultaten Lambda kommer att göra en begäran till DynamoDB, erhålla status för begäran och returnera informationen till användaren. Om statusen för förutsägelsen är fel, kommer relevant information om felet att inkluderas i svaret. Om förutsägelsestatusen är framgång, kommer en S3 försignerad URL att returneras så att användaren kan ladda ner förutsägelseinnehållet.

Utkomster

Preliminära resultat från prestandatestning är lovande och stöder CCC för att utöka implementeringen av denna nya implementeringsarkitektur.

Anmärkningsvärda observationer:

• Tester visar styrka i att bearbeta batch- eller samtidiga förfrågningar med hög genomströmning och en felfrekvens på 0 procent under scenarier med hög trafik.
• Meddelandeköer ger stabilitet i systemet under plötsliga inflöden av förfrågningar tills skalningsutlösare kan tillhandahålla ytterligare beräkningsresurser. När trafiken ökade med tre gånger ökade den genomsnittliga fördröjningstiden för begäran endast med 3 procent.
• Priset på stabilitet är ökad latens på grund av kommunikationsoverhead mellan de olika systemkomponenterna. När användartrafiken ligger över baslinjetröskeln kan den extra fördröjningen delvis minskas genom att tillhandahålla fler beräkningsresurser om prestanda har högre prioritet framför kostnad.
• SageMakers asynkrona slutpunktsslutpunkter tillåter instansräkningen att skalas till noll samtidigt som slutpunkten hålls aktiv för att ta emot förfrågningar. Den här funktionen gör det möjligt för driftsättningar att fortsätta köras utan att ådra sig beräkningskostnader och skala upp från noll vid behov i två scenarier: tjänstedistributioner som används i lägre testmiljöer och de som har minimal trafik utan att kräva omedelbar bearbetning.

Slutsats

Som observerats under POC-processen ger den innovativa designen gemensamt skapad av CCC och AWS en solid grund för att använda Amazon SageMaker med andra AWS-hanterade tjänster för att vara värd för komplexa multimodala AI-ensembler och orkestrera slutledningspipelines effektivt och sömlöst. Genom att utnyttja Amazon SageMakers out-of-the-box-funktioner som Asynchronous Inference har CCC fler möjligheter att fokusera på specialiserade affärskritiska uppgifter. I andan av CCC:s forskningsdrivna kultur kommer denna nya arkitektur att fortsätta att utvecklas när CCC leder vägen framåt, tillsammans med AWS, i att släppa lös kraftfulla nya AI-lösningar för kunder.

För detaljerade steg om hur man skapar, anropar och övervakar asynkrona slutpunkter, se dokumentation, som också innehåller en prov anteckningsbok för att hjälpa dig komma igång. För prisinformation, besök Amazon SageMaker Prissättning.

För exempel på användning av asynkron slutledning med ostrukturerad data som datorseende och naturlig språkbehandling (NLP), se Kör datorseende inferens på stora videor med Amazon SageMaker asynkrona slutpunkter och Förbättra forskning med högt värde med Hugging Face och Amazon SageMaker asynkrona slutpunkter, Respektive.

---

Om författarna

Christopher Diaz är en ledande R&D-ingenjör på CCC Intelligent Solutions. Som medlem i FoU-teamet har han arbetat med en mängd olika projekt, allt från ETL-verktyg, webbutveckling för backend, samarbeta med forskare för att träna AI-modeller på distribuerade system och underlätta leveransen av nya AI-tjänster mellan forsknings- och driftsteam. Hans fokus på senare tid har varit att undersöka molnverktygslösningar för att förbättra olika aspekter av företagets livscykel för AI-modellutveckling. På fritiden tycker han om att prova nya restauranger i sin hemstad Chicago och samla på så många LEGO-set som hans hem får plats. Christopher tog sin kandidatexamen i datavetenskap från Northeastern Illinois University.

Emmy Award-vinnare Sam Kinard är Senior Manager of Software Engineering på CCC Intelligent Solutions. Baserad i Austin, Texas, bråkar han med AI Runtime Team, som ansvarar för att betjäna CCC:s AI-produkter med hög tillgänglighet och stor skala. På fritiden tycker Sam om att vara sömnlös på grund av sina två underbara barn. Sam har en kandidatexamen i datavetenskap och en kandidatexamen i matematik från University of Texas i Austin.

Jaime Hidalgo är senior systemingenjör på CCC Intelligent Solutions. Innan han gick med i AI-forskargruppen ledde han företagets globala migrering till Microservices Architecture, designade, byggde och automatiserade infrastrukturen i AWS för att stödja distributionen av molnprodukter och -tjänster. För närvarande bygger och stödjer han ett lokalt datacenterkluster byggt för AI-träning och designar och bygger även molnlösningar för företagets framtid av AI-forskning och implementering.

Daniel Suarez är datavetenskapsingenjör på CCC Intelligent Solutions. Som medlem av AI Engineering-teamet arbetar han med automatisering och förberedelse av AI-modeller i produktion, utvärdering och övervakning av mätvärden och andra aspekter av ML-operationer. Daniel tog en magisterexamen i datavetenskap från Illinois Institute of Technology och en magister- och kandidatexamen i telekommunikationsteknik från Universidad Politecnica de Madrid.

Arunprasath Shankar är en Senior AI/ML Specialist Solutions Architect med AWS, som hjälper globala kunder att skala sina AI-lösningar effektivt och effektivt i molnet. På fritiden tycker Arun om att titta på sci-fi-filmer och lyssna på klassisk musik.

Justin McWhirter är Solutions Architect Manager på AWS. Han arbetar med ett team av fantastiska Solutions Architects som hjälper kunder att få en positiv upplevelse när de använder AWS-plattformen. När han inte är på jobbet tycker Justin om att spela tv-spel med sina två pojkar, ishockey och åka terräng i sin jeep.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/how-ccc-intelligent-solutions-created-a-custom-approach-for-hosting-complex-ai-models-using-amazon-sagemaker/