Teknikker og tilnærminger for overvåking av store språkmodeller på AWS | Amazon Web Services

Store språkmodeller (LLM) har revolusjonert feltet for naturlig språkbehandling (NLP), og forbedret oppgaver som språkoversettelse, tekstoppsummering og sentimentanalyse. Men ettersom disse modellene fortsetter å vokse i størrelse og kompleksitet, har det blitt stadig mer utfordrende å overvåke ytelsen og oppførselen deres.

Å overvåke ytelsen og oppførselen til LLM-er er en kritisk oppgave for å sikre deres sikkerhet og effektivitet. Vår foreslåtte arkitektur gir en skalerbar og tilpassbar løsning for online LLM-overvåking, som gjør det mulig for team å skreddersy overvåkingsløsningen til dine spesifikke brukstilfeller og krav. Ved å bruke AWS-tjenester gir arkitekturen vår sanntidssynlighet til LLM-atferd og gjør det mulig for team å raskt identifisere og løse eventuelle problemer eller uregelmessigheter.

I dette innlegget demonstrerer vi noen få beregninger for online LLM-overvåking og deres respektive arkitektur for skalering ved bruk av AWS-tjenester som f.eks. Amazon CloudWatch og AWS Lambda. Dette gir en tilpassbar løsning utover det som er mulig med modellevaluering jobber med Amazonas grunnfjell.

Oversikt over løsning

Det første du må vurdere er at forskjellige beregninger krever forskjellige beregningshensyn. En modulær arkitektur, der hver modul kan ta inn modellslutningsdata og produsere sine egne beregninger, er nødvendig.

Vi foreslår at hver modul tar innkommende slutningsforespørsler til LLM, og sender forespørsel og fullføring (svar)-par til metriske beregningsmoduler. Hver modul er ansvarlig for å beregne sine egne beregninger med hensyn til inndatamelding og fullføring (svar). Disse beregningene sendes til CloudWatch, som kan samle dem og arbeide med CloudWatch-alarmer for å sende varsler om spesifikke forhold. Følgende diagram illustrerer denne arkitekturen.

Arbeidsflyten inkluderer følgende trinn:

1. En bruker sender en forespørsel til Amazon Bedrock som en del av en applikasjon eller et brukergrensesnitt.
2. Amazon Bedrock lagrer forespørselen og fullføringen (svaret) i Amazon enkel lagringstjeneste (Amazon S3) som per konfigurasjon av påkallingslogging.
3. Filen som er lagret på Amazon S3 oppretter en hendelse som utløser en Lambda-funksjon. Funksjonen påkaller modulene.
4. Modulene legger ut sine respektive beregninger til CloudWatch-beregninger.
5. alarmer kan varsle utviklingsteamet om uventede metriske verdier.

Den andre tingen du bør vurdere når du implementerer LLM-overvåking, er å velge riktige beregninger å spore. Selv om det er mange potensielle beregninger du kan bruke for å overvåke LLM-ytelse, forklarer vi noen av de bredeste i dette innlegget.

I de følgende delene fremhever vi noen av de relevante modulberegningene og deres respektive metriske beregningsmodularkitektur.

Semantisk likhet mellom spørsmål og fullføring (svar)

Når du kjører LLM-er, kan du avskjære forespørselen og fullføringen (svaret) for hver forespørsel og transformere dem til innebygginger ved hjelp av en innebyggingsmodell. Embeddings er høydimensjonale vektorer som representerer den semantiske betydningen av teksten. Amazon Titan tilbyr slike modeller gjennom Titan Embeddings. Ved å ta en avstand som cosinus mellom disse to vektorene, kan du kvantifisere hvor semantisk like forespørselen og fullføringen (responsen) er. Du kan bruke SciPy or scikit lære å beregne cosinusavstanden mellom vektorer. Følgende diagram illustrerer arkitekturen til denne metriske beregningsmodulen.

Denne arbeidsflyten inkluderer følgende nøkkeltrinn:

1. En Lambda-funksjon mottar en streamet melding via Amazon Kinesis som inneholder et spørsmål og et kompletteringspar (svar).
2. Funksjonen får en innebygging for både ledeteksten og fullføringen (responsen), og beregner cosinusavstanden mellom de to vektorene.
3. Funksjonen sender denne informasjonen til CloudWatch-målinger.

Sentiment og toksisitet

Overvåking av sentiment lar deg måle den generelle tonen og følelsesmessige virkningen av responsene, mens toksisitetsanalyse gir et viktig mål på tilstedeværelsen av støtende, respektløst eller skadelig språk i LLM-utdata. Eventuelle endringer i sentiment eller toksisitet bør overvåkes nøye for å sikre at modellen oppfører seg som forventet. Følgende diagram illustrerer den metriske beregningsmodulen.

Arbeidsflyten inkluderer følgende trinn:

1. En Lambda-funksjon mottar et spørsmål og et kompletteringspar (respons) gjennom Amazon Kinesis.
2. Gjennom AWS Step Functions orkestrering kaller funksjonen Amazon Comprehend å oppdage sentiment og toksisitet.
3. Funksjonen lagrer informasjonen til CloudWatch-målinger.

For mer informasjon om å oppdage sentiment og toksisitet med Amazon Comprehend, se Bygg en robust tekstbasert toksisitetsprediktor og Rapporter skadelig innhold ved å bruke Amazon Comprehend-toksisitetsdeteksjon.

Forhold mellom avslag

En økning i avslag, for eksempel når en LLM nekter fullføring på grunn av mangel på informasjon, kan bety at enten ondsinnede brukere prøver å bruke LLM på måter som er ment å jailbreak det, eller at brukernes forventninger ikke blir oppfylt og de får svar av lav verdi. En måte å måle hvor ofte dette skjer er ved å sammenligne standardavslag fra LLM-modellen som brukes med de faktiske svarene fra LLM. Følgende er for eksempel noen av Anthropics Claude v2 LLM vanlige 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å et fast sett med meldinger kan en økning i disse avslagene være et signal om at modellen har blitt for forsiktig eller følsom. Det omvendte tilfellet bør også vurderes. Det kan være et signal om at modellen nå er mer utsatt for å delta i giftige eller skadelige samtaler.

For å hjelpe modellintegritet og modellvegringsforhold, kan vi sammenligne svaret med et sett med kjente avslagsfraser fra LLM. Dette kan være en faktisk klassifikator som kan forklare hvorfor modellen avslo forespørselen. Du kan ta cosinusavstanden mellom responsen og kjente avslagssvar fra modellen som overvåkes. Følgende diagram illustrerer denne metriske beregningsmodulen.

Arbeidsflyten består av følgende trinn:

1. En Lambda-funksjon mottar en melding og fullføring (svar) og får en innebygging fra svaret ved hjelp av Amazon Titan.
2. Funksjonen beregner cosinus eller euklidisk avstand mellom responsen og eksisterende avslagsmeldinger som er bufret i minnet.
3. Funksjonen sender det gjennomsnittet til CloudWatch-beregninger.

Et annet alternativ er å bruke uklar matchning for en enkel, men mindre kraftig tilnærming til å sammenligne de kjente avslagene med LLM-utgang. Referere til Python-dokumentasjon for et eksempel.

Oppsummering

LLM observerbarhet er en kritisk praksis for å sikre pålitelig og pålitelig bruk av LLM. Overvåking, forståelse og sikring av nøyaktigheten og påliteligheten til LLM-er kan hjelpe deg med å redusere risikoen forbundet med disse AI-modellene. Ved å overvåke hallusinasjoner, dårlige fullføringer (svar) og forespørsler, kan du sørge for at din LLM holder seg på sporet og leverer verdien du og brukerne dine ser etter. I dette innlegget diskuterte vi noen få beregninger for å vise frem eksempler.

For mer informasjon om evaluering av fundamentmodeller, se Bruk SageMaker Clarify til å evaluere fundamentmodeller, og bla gjennom flere eksempel notatbøker tilgjengelig i vårt GitHub-lager. Du kan også utforske måter å operasjonalisere LLM-evalueringer i skala inn Operasjonaliser LLM-evaluering i stor skala ved å bruke Amazon SageMaker Clarify og MLOps-tjenester. Til slutt anbefaler vi å henvise til Vurdere store språkmodeller for kvalitet og ansvar for å lære mer om evaluering av LLM-er.

---

Om forfatterne

Bruno Klein er en senior maskinlæringsingeniør med AWS Professional Services Analytics Practice. Han hjelper kunder med å implementere big data og analyseløsninger. Utenom jobben liker han å tilbringe tid med familien, reise og prøve ny mat.

Rushabh Lokhande er en senior data- og ML-ingeniør med AWS Professional Services Analytics Practice. Han hjelper kunder med å implementere big data, maskinlæring og analyseløsninger. Utenom jobben liker han å tilbringe tid med familien, lese, løpe og spille golf.

• 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/techniques-and-approaches-for-monitoring-large-language-models-on-aws/