Kunstig intelligens
Evaluering av store sprÄkmodeller: En teknisk guide

Store språkmodeller (LLM) som GPT-4, Claude og LLaMA har eksplodert i popularitet. Takket være deres evne til å generere imponerende menneske-lignende tekst, brukes disse AI-systemene nå til alt fra innholdsskapning til kundeservice-chatbots.
Men hvordan vet vi om disse modellene faktisk er noen gode? Med nye LLM som annonseres konstant, alle hevder å være større og bedre, hvordan vurderer og sammenligner vi deres ytelse?
I denne omfattende guiden vil vi utforske de beste teknikkene for å evaluere store språkmodeller. Vi vil se på fordelene og ulemper ved hver tilnærming, når de er best anvendt, og hvordan du kan utnytte dem i din egen LLM-testing.
Oppgave-spesifikke metrikker
En av de mest rettframma måtene å evaluere en LLM på er å teste den på etablerte NLP-oppdrag med standardiserte metrikker. For eksempel:
Sammendrag
For sammendragsoppgaver er metrikker som ROUGE (Recall-Oriented Understudy for Gisting Evaluation) vanlig brukt. ROUGE sammenligner modell-generert sammendrag med et menneske-skrevet “referanse” sammendrag, og teller overlapet av ord eller fraser.
Det finnes flere varianter av ROUGE, hver med sine egne fordeler og ulemper:
- ROUGE-N: Sammenligner overlap av n-grammer (sekvenser av N ord). ROUGE-1 bruker unigrammer (enkelte ord), ROUGE-2 bruker bigrammer, osv. Fordelen er at det fanger ordrekkefølge, men det kan være for strengt.
- ROUGE-L: Basert på lengste felles subsekvens (LCS). Mer fleksibelt på ordrekkefølge, men fokuserer på hovedpoengene.
- ROUGE-W: Vekter LCS-matcher med deres betydning. Forsøker å forbedre ROUGE-L.
Generelt er ROUGE-metrikker rask, automatisk og fungerer godt for å rangere system-sammendrag. Men de måler ikke sammenheng eller mening. Et sammendrag kan få høy ROUGE-poeng og likevel være meningsløst.
Formelen for ROUGE-N er:
ROUGE-N=∑∈{Reference Summaries}∑∑�∈{Reference Summaries}∑
Hvor:
Count_{match}(gram_n)er tallet på n-grammer i både generert og referanse-sammendrag.Count(gram_n)er tallet på n-grammer i referanse-sammendrag.
For eksempel, for ROUGE-1 (unigrammer):
- Generert sammendrag: “Katten satt.”
- Referanse-sammendrag: “Katten satt på matta.”
- Overlappende unigrammer: “Katten”, “satt”
- ROUGE-1-poeng = 2/4 = 0,5
ROUGE-L bruker den lengste felles subsekvensen (LCS). Den er mer fleksibel på ordrekkefølge. Formelen er:
ROUGE-L=���(generated,reference)max(length(generated), length(reference))
Hvor LCS er lengden på den lengste felles subsekvensen.
ROUGE-W vekter LCS-matcher. Den tar hensyn til betydningen av hver match i LCS.
Øversettelse
For maskin-øversettelse-oppgaver er BLEU (Bilingual Evaluation Understudy) en populær metrikk. BLEU måler likheten mellom modellens utgangs-øversettelse og profesjonelle menneske-øversettelser, ved å bruke n-gram presisjon og en korthetsstraff.
Nøkkelaspekter ved hvordan BLEU fungerer:
- Sammenligner overlap av n-grammer for n opptil 4 (unigrammer, bigrammer, trigrammer, 4-grammer).
- Beregner en geometrisk gjennomsnitt av n-gram presisjonene.
- Anvender en korthetsstraff hvis oversettelsen er mye kortere enn referansen.
- Vanligvis varierer fra 0 til 1, med 1 som en perfekt match til referansen.
BLEU korrelerer rimelig godt med menneskelige vurderinger av oversettelses kvalitet. Men den har likevel begrensninger:
- Måler bare presisjon mot referanser, ikke rekall eller F1.
- Har vanskelig for å håndtere kreative oversettelser som bruker forskjellige ord.
- Er utsatt for “gaming” med oversettelse-triks.
Andre oversettelse-metrikker som METEOR og TER forsøker å forbedre BLEU-svakheter. Men generelt sett fanger ikke automatiske metrikker fullstendig oversettelses kvalitet.
Andre oppgaver
I tillegg til sammendrag og oversettelse, kan metrikker som F1, nøyaktighet, MSE og mer brukes til å evaluere LLM-ytelse på oppgaver som:
- Tekst-klassifisering
- Informasjons-utvinning
- Spørsmål-svar
- Sentiment-analyse
- Grammatisk feil-detteksjon
Fordelen med oppgave-spesifikke metrikker er at evaluering kan være fullstendig automatisert ved å bruke standardiserte datamengder som SQuAD for QA og GLUE-benchmark for en rekke oppgaver. Resultatene kan lett spores over tid når modellene forbedres.
Men disse metrikkene er smalt fokusert og kan ikke måle helhetlig språkkvalitet. LLM-er som utfører godt på metrikker for en enkelt oppgave kan feile i å generere sammenhengende, logisk, nyttig tekst generelt.
Forsknings-benchmark
En populær måte å evaluere LLM-er på er å teste dem mot omfattende forsknings-benchmark som dekker diverse emner og ferdigheter. Disse benchmarkene tillater modellene å bli raskt testet i stor skala.
Noen kjente benchmark inkluderer:
- SuperGLUE – En utfordrende samling av 11 forskjellige språk-oppgaver.
- GLUE – En samling av 9 setninger-forståelse-oppgaver. Enklere enn SuperGLUE.
- MMLU – 57 forskjellige STEM-, samfunns- og humanistiske oppgaver. Tester kunnskap og resonnerings-evne.
- Winograd Schema Challenge – Pronomen-løsning-problemer som krever sunn fornuft.
- ARC – Utfordrende naturlig språk-resonnerings-oppgaver.
- Hellaswag – Sunn fornuft-resonnering om situasjoner.
- PIQA – Fysikk-spørsmål som krever diagrammer.
Ved å evaluere på benchmark som disse, kan forskerne raskt teste modellene på deres evne til å utføre matematikk, logikk, resonnering, kode, sunn fornuft og mye mer. Prosenten av spørsmål som blir svart korrekt blir en benchmark-metrikk for å sammenligne modellene.
Men et større problem med benchmark er trening-data-forurensning. Mange benchmark inneholder eksempler som allerede er sett av modellene under fortrening. Dette gjør det mulig for modellene å “huske” svarene på bestemte spørsmål og utføre bedre enn deres egentlige evner.
Forsøk gjøres for å “rense” benchmarkene ved å fjerne overlappende eksempler. Men dette er vanskelig å gjøre omfattende, særlig når modellene kan ha sett omformulerte eller oversatte versjoner av spørsmål.
Så mens benchmark kan teste en bred rekke ferdigheter effektivt, kan de ikke pålitelig måle sanne resonnerings-evner eller unngå poeng-inflasjon på grunn av forurensning. Komplementære evaluering-metoder er nødvendige.
LLM-selv-evaluering
En interessant tilnærming er å la en LLM evaluere en annen LLMs utgang. Ideen er å utnytte den “enklere” oppgave-konseptet:
- Å produsere en høykvalitets-utgang kan være vanskelig for en LLM.
- Men å bestemme om en gitt utgang er av høy kvalitet kan være en enklere oppgave.
For eksempel, mens en LLM kan streve med å generere en faktisk, sammenhengende paragraf fra scratch, kan den lettere vurdere om en gitt paragraf har logisk mening og passer konteksten.
Så prosessen er:
- Send innputt-prompt til første LLM for å generere utgang.
- Send innputt-prompt + generert utgang til andre “evaluerer” LLM.
- Spør evaluerer LLM en spørsmål for å vurdere utgangskvalitet. f.eks. “Har ovennevnte svar logisk mening?”
Dette tilnærmingen er rask å implementere og automatiserer LLM-evaluering. Men det finnes noen utfordringer:
- Ytelse avhenger sterkt av valg av evaluerer LLM og prompt-ordlyd.
- Begrenset av vanskelighetsgraden av oppgaven. Å evaluere kompleks resonnering er fortsatt vanskelig for LLM-er.
- Kan være datamaskinelt dyrt hvis man bruker API-basert LLM-er.
Selv-evaluering er spesielt lovende for å vurdere hentet informasjon i RAG (retrieval-augmented generation)-systemer. Ekstra LLM-spørsmål kan validere om hentet kontekst brukes riktig.
Samlet sett viser selv-evaluering potensial, men krever omsorg i implementeringen. Den komplementerer, i stedet for erstatter, menneskelig evaluering.
Menneskelig evaluering
Gitt begrensningene av automatiske metrikker og benchmark, er menneskelig evaluering fortsatt gullstandarden for å strengt vurdere LLM-kvalitet.
Eksperter kan gi detaljerte kvalitative vurderinger av:
- Nøyaktighet og faktisk korrekthet
- Logikk, resonnering og sunn fornuft
- Sammenheng, konsistens og lesbarhet
- Passende tone, stil og stemme
- Grammatikk og flyt
- Kreativitet og nuanser
For å evaluere en modell, får mennesker en samling av innputt-prompter og LLM-genererte svar. De vurderer kvaliteten av svarene, ofte ved å bruke vurderingsskalaer og rubrikker.
Ulemper er at manuell menneskelig evaluering er dyrt, tregt og vanskelig å skalerer. Den krever også utvikling av standardiserte kriterier og trening av vurderere for å anvende dem konsekvent.
Noen forskere har utforsket kreative måter å crowdfunde menneskelig LLM-evaluering ved å bruke turnerings-stil systemer hvor mennesker tipper og vurderer sammenligninger mellom modeller. Men dekningen er fortsatt begrenset sammenlignet med full manuell evaluering.
For bedrifts-brukstilfeller hvor kvalitet betyr mer enn rå skala, er ekspert-menneskelig testing fortsatt gullstandarden, til tross for kostnadene. Dette er spesielt sant for risikofylte anvendelser av LLM-er.
Konklusjon
Å evaluere store språkmodeller grundig krever å bruke en divers verktøykasse av komplementære metoder, i stedet for å stole på en enkelt teknikk.
Ved å kombinere automatiske tilnærminger for hastighet med strenge menneskelige vurderinger for nøyaktighet, kan vi utvikle pålitelige testmetoder for store språkmodeller. Med robust evaluering kan vi låse opp det enorme potensialet i LLM-er samtidig som vi håndterer deres risiko ansvarlig.












