Tekniker och tillvägagångssätt för att övervaka stora språkmodeller på AWS | Amazon webbtjänster

Stora språkmodeller (LLM) har revolutionerat området för naturlig språkbehandling (NLP), och förbättrat uppgifter som språköversättning, textsammanfattning och sentimentanalys. Men eftersom dessa modeller fortsätter att växa i storlek och komplexitet, har det blivit alltmer utmanande att övervaka deras prestanda och beteende.

Att övervaka prestanda och beteende hos LLM:er är en kritisk uppgift för att säkerställa deras säkerhet och effektivitet. Vår föreslagna arkitektur ger en skalbar och anpassningsbar lösning för online LLM-övervakning, vilket gör det möjligt för team att skräddarsy din övervakningslösning för dina specifika användningsfall och krav. Genom att använda AWS-tjänster ger vår arkitektur realtidssynlighet i LLM-beteende och gör det möjligt för team att snabbt identifiera och åtgärda eventuella problem eller anomalier.

I det här inlägget visar vi några mätvärden för online LLM-övervakning och deras respektive arkitektur för skalning med hjälp av AWS-tjänster som t.ex. amazoncloudwatch och AWS Lambda. Detta erbjuder en anpassningsbar lösning utöver vad som är möjligt med modellutvärdering jobb med Amazonas berggrund.

Översikt över lösningen

Det första att tänka på är att olika mätvärden kräver olika beräkningsöverväganden. En modulär arkitektur, där varje modul kan ta in modellinferensdata och producera sina egna mätvärden, är nödvändig.

Vi föreslår att varje modul tar inkommande slutledningsförfrågningar till LLM, och skickar prompt och komplettering (svar) par till metriska beräkningsmoduler. Varje modul är ansvarig för att beräkna sina egna mätvärden med avseende på ingångsuppmaningen och slutförandet (svaret). Dessa mätvärden skickas till CloudWatch, som kan aggregera dem och arbeta med CloudWatch-larm för att skicka meddelanden om specifika förhållanden. Följande diagram illustrerar denna arkitektur.

Arbetsflödet innehåller följande steg:

1. En användare gör en förfrågan till Amazon Bedrock som en del av en applikation eller ett användargränssnitt.
2. Amazon Bedrock sparar begäran och kompletteringen (svaret) i Amazon enkel lagringstjänst (Amazon S3) som per konfiguration av anropsloggning.
3. Filen som sparats på Amazon S3 skapar en händelse som triggar en lambdafunktion. Funktionen anropar modulerna.
4. Modulerna publicerar sina respektive mätvärden till CloudWatch-statistik.
5. Larm kan meddela utvecklingsteamet om oväntade metriska värden.

Den andra saken att tänka på när du implementerar LLM-övervakning är att välja rätt mätvärden att spåra. Även om det finns många potentiella mätvärden som du kan använda för att övervaka LLM-prestanda, förklarar vi några av de bredaste i det här inlägget.

I följande avsnitt lyfter vi fram några av de relevanta modulmåtten och deras respektive metriska beräkningsmodularkitektur.

Semantisk likhet mellan prompt och komplettering (svar)

När du kör LLM:er kan du fånga upp meddelandet och slutförandet (svaret) för varje begäran och omvandla dem till inbäddningar med hjälp av en inbäddningsmodell. Inbäddningar är högdimensionella vektorer som representerar textens semantiska betydelse. Amazon Titan tillhandahåller sådana modeller genom Titan Embeddings. Genom att ta ett avstånd som cosinus mellan dessa två vektorer kan du kvantifiera hur semantiskt lika prompten och kompletteringen (svaret) är. Du kan använda SciPy or scikit lära för att beräkna cosinusavståndet mellan vektorer. Följande diagram illustrerar arkitekturen för denna metriska beräkningsmodul.

Detta arbetsflöde inkluderar följande nyckelsteg:

1. En Lambdafunktion tar emot ett streamat meddelande via Amazon Kinesis som innehåller ett uppmaning och ett kompletteringspar (svar).
2. Funktionen får en inbäddning för både prompten och kompletteringen (svaret), och beräknar cosinusavståndet mellan de två vektorerna.
3. Funktionen skickar den informationen till CloudWatch-mätvärden.

Sentiment och toxicitet

Övervakning av sentiment låter dig mäta den övergripande tonen och den känslomässiga effekten av svaren, medan toxicitetsanalys ger ett viktigt mått på förekomsten av stötande, respektlöst eller skadligt språk i LLM-utdata. Alla förändringar i sentiment eller toxicitet bör övervakas noga för att säkerställa att modellen beter sig som förväntat. Följande diagram illustrerar den metriska beräkningsmodulen.

Arbetsflödet innehåller följande steg:

1. En Lambda-funktion får en prompt och ett kompletteringspar (svar) via Amazon Kinesis.
2. Genom AWS Step Functions orkestrering anropar funktionen Amazon Comprehend för att upptäcka känsla och giftighet.
3. Funktionen sparar informationen till CloudWatch-mätvärden.

För mer information om att upptäcka sentiment och toxicitet med Amazon Comprehend, se Bygg en robust textbaserad toxicitetsprediktor och Flagga skadligt innehåll med Amazon Comprehend toxicitetsdetektering.

Förhållande av avslag

En ökning av antalet avslag, som när en LLM nekar slutförande på grund av brist på information, kan innebära att antingen illvilliga användare försöker använda LLM på ett sätt som är avsett att jailbreaka det, eller att användarnas förväntningar inte uppfylls och de får lågvärdiga svar. Ett sätt att mäta hur ofta detta händer är att jämföra standardavslag från LLM-modellen som används med de faktiska svaren från LLM. Till exempel, följande är några av Anthropics Claude v2 LLM vanliga avslagsfraser:

“Unfortunately, I do not have enough context to provide a substantive response. However, I am an AI assistant created by Anthropic to be helpful, harmless, and honest.”

“I apologize, but I cannot recommend ways to…”

“I'm an AI assistant created by Anthropic to be helpful, harmless, and honest.”

På en fast uppsättning uppmaningar kan en ökning av dessa avslag vara en signal om att modellen har blivit alltför försiktig eller känslig. Det omvända fallet bör också utvärderas. Det kan vara en signal om att modellen nu är mer benägen att delta i giftiga eller skadliga samtal.

För att hjälpa modellens integritet och modellvägringsförhållande kan vi jämföra svaret med en uppsättning kända avslagsfraser från LLM. Detta kan vara en faktisk klassificerare som kan förklara varför modellen avvisade begäran. Du kan ta cosinusavståndet mellan svaret och kända avslagssvar från modellen som övervakas. Följande diagram illustrerar denna metriska beräkningsmodul.

Arbetsflödet består av följande steg:

1. En Lambda-funktion får en prompt och komplettering (svar) och får en inbäddning från svaret med Amazon Titan.
2. Funktionen beräknar cosinus eller euklidiskt avstånd mellan svaret och befintliga vägransprompter som cachelagrats i minnet.
3. Funktionen skickar det genomsnittet till CloudWatch-mätvärden.

Ett annat alternativ är att använda suddig matchning för ett enkelt men mindre kraftfullt tillvägagångssätt för att jämföra de kända avslagen med LLM-utdata. Referera till Python-dokumentation till exempel.

Sammanfattning

LLM observerbarhet är en kritisk praxis för att säkerställa tillförlitlig och pålitlig användning av LLM:er. Att övervaka, förstå och säkerställa noggrannheten och tillförlitligheten hos LLM:er kan hjälpa dig att minska riskerna förknippade med dessa AI-modeller. Genom att övervaka hallucinationer, dåliga slutföranden (svar) och uppmaningar kan du se till att din LLM håller sig på rätt spår och levererar det värde du och dina användare letar efter. I det här inlägget diskuterade vi några mätvärden för att visa upp exempel.

För mer information om att utvärdera grundmodeller, se Använd SageMaker Clarify för att utvärdera grundmodeller, och bläddra ytterligare exempel anteckningsböcker tillgängligt i vårt GitHub-förråd. Du kan också utforska sätt att operationalisera LLM-utvärderingar i skala in Operationalisera LLM-utvärdering i skala med hjälp av Amazon SageMaker Clarify- och MLOps-tjänster. Slutligen rekommenderar vi att du hänvisar till Utvärdera stora språkmodeller för kvalitet och ansvar för att lära dig mer om att utvärdera LLM.

---

Om författarna

Bruno Klein är en Senior Machine Learning Engineer med AWS Professional Services Analytics Practice. Han hjälper kunder att implementera big data och analyslösningar. Utanför jobbet tycker han om att umgås med familjen, att resa och prova ny mat.

Rushabh Lokhande är en Senior Data & ML Engineer med AWS Professional Services Analytics Practice. Han hjälper kunder att implementera big data, maskininlärning och analyslösningar. Utanför jobbet tycker han om att umgås med familjen, läsa, springa och spela golf.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/techniques-and-approaches-for-monitoring-large-language-models-on-aws/