Evaluering af store sprogmodeller: En teknisk vejledning

Store sprogmodeller (LLM’er) som GPT-4, Claude og LLaMA er eksploderet i popularitet. Takket være deres evne til at generere imponerende menneske-lignende tekst, bruges disse AI-systemer nu til alt fra indholdsskabelse til kundeservice-chattbots.

Men hvordan ved vi, om disse modeller er godt nok? Med nye LLM’er, der annonceres konstant, og som alle hævder at være større og bedre, hvordan kan vi evaluere og sammenligne deres ydeevne?

I denne omfattende vejledning vil vi udforske de bedste teknikker for at evaluere store sprogmodeller. Vi vil se på fordelene og ulemperne ved hver tilgang, når de er bedst anvendt, og hvordan du kan udnytte dem i din egen LLM-test.

Opdateringsspecifikke metrikker

En af de mest direkte måder at evaluere en LLM på er at teste den på etablerede NLP-opgaver med standardiserede metrikker. For eksempel:

Sammenfatning

Til sammenfatningsopgaver bruges metrikker som ROUGE (Recall-Oriented Understudy for Gisting Evaluation) ofte. ROUGE sammenligner den model-genererede sammenfatning med en menneskeskrevet “reference”-sammenfatning og tæller overlap af ord eller fraser.

Der er flere varianter af ROUGE, hver med deres egne fordele og ulemper:

• ROUGE-N: Sammenligner overlap af n-grammer (sekvenser af N ord). ROUGE-1 bruger unigrammer (enkelte ord), ROUGE-2 bruger bigrammer osv. Fordelen er, at det fanger ordorden, men det kan være for strengt.
• ROUGE-L: Baseret på længste fælles undersekvens (LCS). Mere fleksibelt i ordorden, men fokuserer på hovedpunkter.
• ROUGE-W: Væger LCS-matches efter deres betydning. Forsøger at forbedre ROUGE-L.

Generelt er ROUGE-metrikker hurtige, automatiske og fungerer godt til at rangere system-sammenfattninger. Men de måler ikke sammenhæng eller mening. En sammenfatning kan få en høj ROUGE-score og stadig være meningsløs.

Formlen for ROUGE-N er:

ROUGE-N=∑∈{Reference Sammenfattninger}∑∑�∈{Reference Sammenfattninger}∑ROUGE-N=∑s∈{Reference Sammenfattninger}​∑gramn​∈s​Count(gramn​)∑s∈{Reference Sammenfattninger}​∑gramn​∈s​Countmatch​(gramn​)​

Hvor:

• Count_{match}(gram_n) er antallet af n-grammer i både den genererede og reference-sammenfatning.
• Count(gram_n) er antallet af n-grammer i reference-sammenfatningen.

For eksempel, for ROUGE-1 (unigrammer):

• Genereret sammenfatning: “Katten sad.”
• Reference-sammenfatning: “Katten sad på matten.”
• Overlappende unigrammer: “Katten”, “sad”
• ROUGE-1-score = 2/4 = 0,5

ROUGE-L bruger den længste fælles undersekvens (LCS). Det er mere fleksibelt i ordorden. Formlen er:

ROUGE-L=���(genereret,reference)max(length(genereret), length(reference))ROUGE-L=max(length(genereret), length(reference))LCS(genereret,reference)​

Hvor LCS er længden af den længste fælles undersekvens.

ROUGE-W væger LCS-matches. Det tager hensyn til betydningen af hver match i LCS.

Øversættelse

Til maskinøversættelse-opgaver er BLEU (Bilingual Evaluation Understudy) en populær metrik. BLEU måler ligheden mellem modellens output-øversættelse og professionelle menneskeskrevne øversættelser, ved hjælp af n-gram præcision og en kortfattethedsstraf.

Nøgleaspekter af, hvordan BLEU fungerer:

• Sammenligner overlap af n-grammer for n op til 4 (unigrammer, bigrammer, trigrammer, 4-grammer).
• Beregner en geometrisk gennemsnit af n-gram præcisioner.
• Anvender en kortfattethedsstraf, hvis oversættelsen er meget kortere end referencen.
• Generelt varierer det fra 0 til 1, hvor 1 er en perfekt match til referencen.

BLEU korrelerer rimeligt godt med menneskelige vurderinger af oversættelseskvalitet. Men det har stadig begrænsninger:

• Måler kun præcision i forhold til referencer, ikke genkaldelse eller F1.
• Kæmper med kreative oversættelser, der bruger forskellige ord.
• Er følsom over for “gaming” med oversættelsestricks.

Andre oversættelsesmetrikker som METEOR og TER forsøger at forbedre BLEU’s svagheder. Men generelt fanger automatiske metrikker ikke fuldt ud oversættelseskvalitet.

Andre opgaver

Ud over sammenfatning og oversættelse kan metrikker som F1, nøjagtighed, MSE og mere bruges til at evaluere LLM-ydeevne på opgaver som:

• Tekstklassificering
• Informationsextraktion
• Spørgsmålssvar
• Sentimentanalyse
• Grammatisk fejlfinding

Fordelen ved opgave-specifikke metrikker er, at evaluering kan være fuldstændig automatiseret ved hjælp af standardiserede datasæt som SQuAD til QA og GLUE-benchmark til en række opgaver. Resultater kan let spores over tid, mens modellerne forbedres.

Men disse metrikker er snævert fokuserede og kan ikke måle den overordnede sprogkvalitet. LLM’er, der klarer sig godt på metrikker for en enkelt opgave, kan fejle i at generere sammenhængende, logisk, nyttig tekst generelt.

Forskningsbenchmarks

En populær måde at evaluere LLM’er på er at teste dem mod omfattende forskningsbenchmarks, der dækker diverse emner og færdigheder. Disse benchmarks tillader, at modeller kan testes hurtigt i stor skala.

Nogle velkendte benchmarks inkluderer:

• SuperGLUE – En udfordrende samling af 11 forskellige sprogopgaver.
• GLUE – En samling af 9 sætningforståelsesopgaver. Simpelt i forhold til SuperGLUE.
• MMLU – 57 forskellige STEM-, samfundsvidenskabelige og humanistiske opgaver. Tester viden og resonemsevne.
• Winograd Schema Challenge – Pronominalt resolutionsproblemer, der kræver fælles fornuft.
• ARC – Udfordrende naturlig sprogforståelsesopgaver.
• Hellaswag – Fælles fornuft om situationer.
• PIQA – Fysikspørgsmål, der kræver diagrammer.

Ved at evaluere på benchmarks som disse kan forskere hurtigt teste modeller på deres evne til at udføre matematik, logik, resonemse, kodning, fælles fornuft og meget mere. Procentdelen af korrekt besvarede spørgsmål bliver en benchmark-metrik til at sammenligne modeller.

Men et større problem med benchmarks er træningsdata-forurening. Mange benchmarks indeholder eksempler, der allerede er set af modeller under fortræning. Dette giver modellerne mulighed for at “huske” svar på bestemte spørgsmål og klare sig bedre end deres virkelige evner.

Forsøg er gjort for at “rense” benchmarks ved at fjerne overlappende eksempler. Men det er vanskeligt at gøre dette omfattende, især når modeller kan have set omskrevne eller oversatte versioner af spørgsmål.

Så selvom benchmarks kan teste en bred vifte af færdigheder effektivt, kan de ikke pålideligt måle sand resonemse-evner eller undgå score-inflation på grund af forurening. Komplementære evalueringmetoder er nødvendige.

LLM-selv-evaluering

En interessant tilgang er at lade en LLM evaluere en anden LLM’s output. Idéen er at udnytte den “lettere” opgave-koncept:

• At producere en højkvalitets-output kan være svært for en LLM.
• Men at bestemme, om en given output er af høj kvalitet, kan være en lettere opgave.

For eksempel, mens en LLM kan have svært ved at generere en faktuel, sammenhængende paragraf fra scratch, kan den lettere bedømme, om en given paragraf er logisk og passer til konteksten.

Så processen er:

1. Send input-prompt til første LLM for at generere output.
2. Send input-prompt + genereret output til anden “evaluerer”-LLM.
3. Spørg evaluerer-LLM en spørgsmål for at bedømme output-kvalitet. f.eks. “Gør ovenstående respons logisk mening?”

Denne tilgang er hurtig at implementere og automatiserer LLM-evaluering. Men der er nogle udfordringer:

• Ydeevne afhænger stærkt af valg af evaluerer-LLM og prompt-formulering.
• Begrænset af sværhedsgraden af den oprindelige opgave. At evaluere kompleks resonemse er stadig svært for LLM’er.
• Kan være beregningsmæssigt dyrt, hvis man bruger API-baserede LLM’er.

Selv-evaluering er særligt lovende til at bedømme hentet information i RAG (retrieval-augmented generation)-systemer. Yderligere LLM-forespørgsler kan validere, om hentet kontekst bruges korrekt.

Samlet set viser selv-evaluering potentiale, men kræver omhu i implementeringen. Det supplerer, snarere end erstatter, menneskelig evaluering.

Menneskelig evaluering

Givet begrænsningerne i automatiserede metrikker og benchmarks er menneskelig evaluering stadig guldstandarden for at evaluere LLM-kvalitet omhyggeligt.

Eksperter kan give detaljerede kvalitative vurderinger af:

• Nøjagtighed og faktuel korrekthed
• Logik, resonemse og fælles fornuft
• Sammenhæng, konsistens og læselighed
• Tone-, stil- og stemme-egnethed
• Grammatisk korrekthed og flydende
• Kreativitet og nuance

For at evaluere en model gives mennesker en række input-prompts og LLM-genererede svar. De bedømmer kvaliteten af svarene, ofte ved hjælp af vurderingsskalaer og rubrikker.

Ulemperne er, at manuel menneskelig evaluering er dyrt, langsomt og vanskeligt at skalaere. Det kræver også udvikling af standardiserede kriterier og træning af vurderere for at anvende dem konsekvent.

Nogle forskere har udforsket kreative måder at crowdfunde menneskelig LLM-evaluering ved hjælp af turnerings-stil-systemer, hvor mennesker vædder på og bedømmer kampe mellem modeller. Men dækningen er stadig begrænset i forhold til fuld manuel evaluering.

Til forretningsanvendelser, hvor kvalitet betyder mere end rå skala, forbliver ekspert-menneskelig testning guldstandarden, trods omkostningerne. Dette er særligt sandt for risikofyldte anvendelser af LLM’er.

Konklusion

At evaluere store sprogmodeller omhyggeligt kræver brug af en divers værktøjskasse af komplementære metoder, snarere end at afhænge af en enkelt teknik.

Ved at kombinere automatiserede tilgange for hastighed med omhyggelig menneskelig oversigt for nøjagtighed kan vi udvikle pålidelige testmetoder for store sprogmodeller. Med robust evaluering kan vi låse op for det enorme potentiale i LLM’er, samtidig med at vi håndterer deres risici ansvarligt.