Benchmark til LLM’er

Forstå rolle og begrænsninger af benchmarks i LLM-ydelsesevaluering. Udforsk teknikker til udvikling af robuste LLM’er.

Large Language Models har fået enorm popularitet de seneste år. Jeg mener, du har set det. LLM’ers exceptionelle evne til at forstå menneskesprog har gjort dem til den perfekte integration for virksomheder, der understøtter kritiske arbejdsgange og automatiserer opgaver til maksimal effektivitet. Plus, ud over den gennemsnitlige brugers forståelse, kan LLM’er gøre meget mere. Og da vores afhængighed af dem vokser, må vi virkelig være mere opmærksomme på måder at sikre nødvendig nøjagtighed og pålidelighed. Dette er en global opgave, der vedrører hele institutioner, men i virksomhedsverdenen findes der nu flere benchmarks, der kan bruges til at evaluere LLM’ers ydelse på tværs af forskellige domæner. Disse kan teste modellens evner i forståelse, logisk tænkning, matematik og så videre, og resultaterne afgør, om en LLM er klar til virksomhedsudvikling.

I denne artikel har jeg samlet en omfattende liste over de mest populære benchmarks til LLM-evaluering. Vi vil diskutere hver benchmark i detaljer og se, hvordan forskellige LLM’er klarer sig i forhold til evalueringens kriterier. Men først lad os forstå LLM-evaluering i mere detaljer.

Hvad er LLM-evaluering?

Ligesom andre AI-modeller har LLM’er også brug for at blive evalueret i forhold til bestemte benchmarks, der vurderer forskellige aspekter af sprogmodellens ydelse: viden, nøjagtighed, pålidelighed og konsistens. Standarden indebærer normalt:

1. Forståelse af brugerforespørgsler: Vurdering af modellens evne til at forstå og fortolke en bred vifte af brugerinput.
2. Verificering af output: Verificering af AI-genererede svar mod en pålidelig videnbas for at sikre, at de er korrekte og relevante.
3. Robusthed: Måling af, hvor godt modellen klarer sig med tvetydige, ufuldstændige eller støjende input.

LLM-evaluering giver udviklere mulighed for at identificere og løse begrænsninger effektivt, så de kan forbedre den samlede brugeroplevelse. Hvis en LLM bliver grundigt evalueret, vil den være nøjagtig og robust nok til at håndtere forskellige virkelige anvendelser, selv dem med tvetydige eller uventede input.

Benchmarks

LLM’er er en af de mest komplekse teknologier til dato og kan aktivere selv de mest komplekse applikationer. Så evalueringen skal være lige så kompleks og teste tankeprocessen og teknisk nøjagtighed.

En benchmark bruger bestemte datasæt, metrikker og evalueringstasks til at teste LLM-ydelse og giver mulighed for at sammenligne forskellige LLM’er og måle deres nøjagtighed, hvilket driver fremgang i branchen ved forbedret ydelse.

Her er nogle af de mest typiske aspekter af LLM-ydelse:

• Viden: Modellens viden skal testes på tværs af forskellige domæner. Det er, hvad viden-benchmarken er til. Den vurderer, hvor effektivt modellen kan huske information fra forskellige fagområder som fysik, programmering, geografi osv.
• Logisk tænkning: Det indebærer at teste en modells evne til at “tænke” skridt for skridt og udlede en logisk konklusion, hvilket normalt indebærer scenarier, hvor modellen skal vælge den mest plausiblen fortsættelse eller forklaring baseret på hverdagskundskab og logisk tænkning.
• Læseforståelse: Modellerne skal være fremragende til at fortolke naturligt sprog og generere svar derefter. Testen ligner at besvare spørgsmål baseret på passager for at vurdere forståelse, slutning og detaljerede oplysninger. Ligesom en skolelæseprøve.
• Forståelse af kode: Dette er nødvendigt for at måle en modells dygtighed i at forstå, skrive og fejlfinde kode. Disse benchmarks giver modellen kodningsopgaver eller problemer, som modellen skal løse korrekt, ofte dækkende et bredt udvalg af programmeringssprog og paradigmer.
• Verdenskundskab: For at vurdere modellens greb om almindelig viden om verden. Disse datasæt har normalt spørgsmål, der kræver bred, encyklopædisk viden for at blive besvaret korrekt, hvilket gør dem forskellige fra mere specifik og specialiseret viden-benchmarks.

“Viden”-benchmarks

MMLU (Multimodal Language Understanding)

Denne benchmark er designet til at teste LLM’ens greb om faktuel viden på tværs af forskellige emner som humaniora, samfundsvidenskab, historie, datalogi og endda jura. 57 spørgsmål og 15.000 opgaver, alle rettet mod at sikre, at modellen har fremragende tænkningsevner. Dette gør MMLU til et godt værktøj til at vurdere en LLM’s faktuelle viden og tænkning i forhold til forskellige emner.

For nylig er det blevet en nøgle-benchmark for at evaluere LLM’er i ovennævnte områder. Udviklere ønsker altid at optimere deres modeller for at overgå andre i denne benchmark, hvilket gør det til en de facto-standard for at evaluere avanceret tænkning og viden i LLM’er. Store, virksomheds-klasse-modeller har vist imponerende resultater på denne benchmark, herunder GPT-4-omni på 88,7%, Claude 3 Opus på 86,8%, Gemini 1,5 Pro på 85,9% og Llama-3 70B på 82%. Små modeller klarer sig normalt ikke så godt på denne benchmark, hvor de sjældent overstiger 60-65%, men den seneste præstation af Phi-3-Small-7b på 75,3% er noget at tænke over.

Men MMLU er ikke uden ulemper: Den har kendte problemer som tvetydige spørgsmål, forkerte svar og manglende kontekst. Og mange mener, at nogle af dens opgaver er for lette til en ordentlig LLM-evaluering.

Jeg vil gerne gøre det klart, at benchmarks som MMLU ikke perfekt afspejler virkelige scenarier. Hvis en LLM opnår et stort score på denne, betyder det ikke altid, at den er blevet en fagekspert. Benchmarks er ret begrænsede i omfang og afhænger ofte af multiple-choice-spørgsmål, som aldrig fuldt ud kan fange kompleksiteten og konteksten af virkelige interaktioner. Sand forståelse kræver at kende fakta og anvende denne viden dynamisk, og det indebærer kritisk tænkning, problemløsning og kontekstforståelse. Derfor skal LLM’er konstant forbedres og opdateres, så modellen fastholder benchmarkets relevans og effektivitet.

GPQA (Graduate-Level Google-Proof Q&A Benchmark)

Denne benchmark vurderer LLM’er på logisk tænkning ved hjælp af en datasæt med kun 448 spørgsmål. Domæne-eksperter har udviklet det og dækker emner inden for biologi, fysik og kemi.

Hvert spørgsmål går igennem følgende valideringsproces:

1. En ekspert i samme emne besvarer spørgsmålet og giver detaljeret feedback.
2. Spørgsmålsforfatteren reviderer spørgsmålet baseret på denne feedback.
3. En anden ekspert besvarer det reviderede spørgsmål.

Denne proces kan faktisk sikre, at spørgsmålene er objektive, nøjagtige og udfordrende for en sprogmodel. Selv erfarne PhD-studerende opnår kun en nøjagtighed på 65% på disse spørgsmål, mens GPT-4-omni kun opnår 53,6%, hvilket understreger forskellen mellem menneskelig og maskin-intelligens.

På grund af de høje kvalifikationskrav er datasættet faktisk ret lille, hvilket begrænser dets statistiske kraft til at sammenligne nøjagtighed og kræver store effektstørrelser. Eksperterne, der skabte og validerede disse spørgsmål, kom fra Upwork, så de introducerede potentielt fordomme baseret på deres ekspertise og de dækkede emner.

Kode-benchmarks

HumanEval

164 programmeringsopgaver, en rigtig test for LLM’ers kodnings-evner. Det er HumanEval. Det er designet til at teste grundlæggende kodningsfærdigheder hos store sprogmodeller (LLM’er). Det bruger pass@k-metrikken til at vurdere den funktionelle nøjagtighed af den genererede kode, som udgangspunkt for sandsynligheden for, at mindst en af de top k LLM-genererede kodeeksempler passerer testtilfældene.

Selvom HumanEval-datasættet inkluderer funktions-signaturer, docstrings, kodekroppe og flere enhedstests, dækker det ikke det fulde udvalg af virkelige kodningsopgaver, hvilket ikke kan teste en modells evne til at generere korrekt kode for forskellige scenarier.

MBPP (Mostly Basic Python Programming)

Mbpp-benchmark består af 1.000 crowdsourced Python-programmeringsopgaver. Disse er indgangsniveau-opgaver og fokuserer på grundlæggende programmeringsfærdigheder. Det bruger few-shot og finjusteringstilgange til at evaluere modellens ydelse, hvor større modeller normalt klarer sig bedre på denne datasæt. Men da datasættet kun indeholder indgangsniveau-programmer, repræsenterer det ikke fuldt ud kompleksiteten og udfordringerne i virkelige applikationer.

Matematik-benchmarks

Selvom de fleste LLM’er er ret gode til at strukturere standard-svar, er matematisk tænkning et langt større problem for dem. Hvorfor? Fordi det kræver færdigheder relateret til spørgsmålsforståelse, en skridt-for-skridt logisk tilgang med matematisk tænkning og udledning af det korrekte svar.

“Chain of Thought” (CoT)-metoden er designet til at evaluere LLM’er på matematik-relaterede benchmarks, hvilket indebærer at prompte modeller til at forklare deres skridt-for-skridt tænkning under løsningen af et problem. Der er flere fordele ved dette. Det gør tænkningen mere gennemsigtig, hjælper med at identificere fejl i modellens logik og giver mulighed for en mere detaljeret vurdering af problemløsningsevner. Ved at bryde komplekse problemer ned i en række enklere skridt kan CoT forbedre modellens ydelse på matematik-benchmarks og give dybere indsigt i dens tænkningsevner.

GSM8K: En populær matematik-benchmark

En af de velkendte benchmarks til at evaluere matematiske evner i LLM’er er GSM8K-datasættet. GSM8K består af 8.500 mellem-skole-matematik-opgaver, som kræver flere skridt for at løse, og løsningerne indebærer primært udførelse af en række grundlæggende beregninger. Typisk klarer større modeller eller de, der er specifikt trænet til matematisk tænkning, sig bedre på denne benchmark, f.eks. GPT-4-modeller, der opnår en score på 96,5%, mens DeepSeekMATH-RL-7B ligger lidt efter på 88,2%.

Selvom GSM8K er nyttig til at vurdere en modells evne til at håndtere mellem-skole-niveau-matematik-opgaver, kan det måske ikke fuldt ud fange en modells evne til at løse mere avancerede eller diverse matematiske udfordringer, hvilket begrænser dets effektivitet som en omfattende måling af matematiske evner.

Matematik-datasættet: En omfattende alternativ

Matematik-datasættet løste manglerne i benchmarks som GSM8K. Dette datasæt er mere omfattende og dækker grundlæggende aritmetik til high school- og endda college-niveau-problemer. Det sammenlignes også med menneskers præstationer, hvor en PhD-student i datalogi, der ikke kan lide matematik, opnår en nøjagtighed på 40%, og en guldmedaljevinder opnår en nøjagtighed på 90%.

Det giver en mere omfattende vurdering af en LLM’s matematiske evner. Det sikrer, at modellen er dygtig i grundlæggende aritmetik og kompetent i komplekse områder som algebra, geometri og kalkulus. Men den øgede kompleksitet og diversitet af problemer kan gøre det udfordrende for modeller at opnå høj nøjagtighed, især for dem, der ikke er ekslicit trænet på et bredt udvalg af matematiske begreber. Desuden kan de varierede problemformater i Matematik-datasættet introducere inkonsistenser i modellens ydelse, hvilket gør det svært at træffe definitive konklusioner om en modells overordnede matematiske dygtighed.

At bruge “Chain of Thought”-metoden med Matematik-datasættet kan forbedre evalueringen, da det afslører LLM’ers skridt-for-skridt tænkningsevner på tværs af et bredt spektrum af matematiske udfordringer. En kombineret tilgang som denne sikrer en mere robust og detaljeret vurdering af en LLM’s sande matematiske evner.

Læseforståelses-benchmarks

En læseforståelses-vurdering evaluerer modellens evne til at forstå og bearbejde komplekst sprog, hvilket er særlig vigtigt for applikationer som kundesupport, indholdsgenerering og informationshenting. Der findes flere benchmarks designet til at evaluere denne færdighed, hver med unikke egenskaber, der bidrager til en omfattende vurdering af en modells evner.

RACE (Læseforståelses-datasæt fra eksaminationer)

RACE-benchmarks har næsten 28.000 passager og 100.000 spørgsmål samlet fra engelske eksaminationer for mellem- og high school-elever i Kina i alderen 12-18 år. Det begrænser ikke spørgsmål og svar til at blive trukket ud af de givne passager, hvilket gør opgaverne endnu mere udfordrende.

Det dækker et bredt udvalg af emner og spørgsmålstyper, hvilket giver en grundig vurdering og inkluderer spørgsmål på forskellige sværhedsgrader. Spørgsmål i RACE er specifikt designet til at teste menneskers læsefærdigheder og er skabt af domæne-eksperter.

Men benchmarken har også nogle ulemper. Da det er udviklet på kinesiske uddannelsesmaterialer, er det tilbøjeligt til at introducere kulturelle fordomme, der ikke afspejler en global kontekst. Desuden er det høje sværhedsniveau i nogle spørgsmål ikke nødvendigvis repræsentativt for typiske virkelige opgaver. Så ydelsesevalueringer kan være upræcise.

DROP (Discrete Reasoning Over Paragraphs)

En anden betydelig tilgang er DROP (Discrete Reasoning Over Paragraphs), som udfordrer modeller til at udføre diskret tænkning over passager. Det har 96.000 spørgsmål til at teste LLM’ers tænkningsevner og spørgsmålene er trukket fra Wikipedia og crowdsourced fra Amazon Mechanical Turk. DROP-spørgsmål kræver ofte, at modeller udfører matematiske operationer som addition, subtraktion og sammenligning baseret på information spredt over en passage.

Spørgsmålene er udfordrende. De kræver, at LLM’er lokaliserer flere tal i passagen og adderer eller subtraherer dem for at få det endelige svar. Store modeller som GPT-4 og Palm opnår 80% og 85%, mens mennesker opnår 96% på DROP-datasættet.

Fællessens-benchmarks

At teste fællessensforståelse i sprogmodeller er en interessant, men også afgørende opgave, da det vurderer en modells evne til at træffe domme og slutninger, der er i overensstemmelse med menneskelig tænkning. I modsætning til os, der udvikler en omfattende verdensmodel gennem praktiske erfaringer, trænes sprogmodeller på enorme datasæt uden at have en indbygget forståelse af konteksten. Dette betyder, at modellerne kæmper med opgaver, der kræver en intuitiv forståelse af hverdags-situationer, logisk tænkning og praktisk viden, hvilket er vigtigt for robuste og pålidelige AI-applikationer.

HellaSwag (Harder Endings, Longer contexts, and Low-shot Activities for Situations With Adversarial Generations)

Hellaswag er udviklet af Rowan Zellers og kolleger ved University of Washington og Allen Institute for Artificial Intelligence. Det er designet til at teste en modells evne til at forudsige den mest plausiblen fortsættelse af en given situation. Denne benchmark er konstrueret ved hjælp af Adversarial Filtering (AF), hvor en række diskrimineringstests iterativt vælger adversarielle maskin-genererede forkerte svar. Denne metode skaber en datasæt med trivielle eksempler for mennesker, men udfordrende for modeller, hvilket resulterer i en “Goldilocks”-zone af sværhedsgrad.

Selvom Hellaswag har været udfordrende for tidligere modeller, har state-of-the-art-modeller som GPT-4 opnået performancesniveauer tæt på menneskelig nøjagtighed, hvilket indikerer betydelig fremgang i feltet. Men disse resultater antyder behovet for kontinuerligt at udvikle benchmarks for at følge med i fremgangen i AI-kapaciteter.

Openbook

Openbook-datasættet består af 5.957 multiple-choice-spørgsmål på grundniveau inden for naturvidenskab. Spørgsmålene er samlet fra åbne bog-eksaminationer og udviklet til at vurdere menneskers forståelse af faget.

Openbook-benchmark kræver tænkningsevner ud over informationshenting. GPT-4 opnår den højeste nøjagtighed på 95,9% indtil videre.

OpenbookQA er modelleret efter åbne bog-eksaminationer og består af 5.957 multiple-choice-spørgsmål på grundniveau inden for naturvidenskab. Disse spørgsmål er designet til at teste forståelsen af 1.326 centrale naturvidenskabelige fakta og deres anvendelse i nye situationer.

Ligesom Hellaswag fandt tidligere modeller OpenbookQA udfordrende, men moderne modeller som GPT-4 har opnået næsten menneskelig performancesniveau. Denne fremgang understreger vigtigheden af at udvikle endnu mere komplekse og nuancerede benchmarks for at fortsætte med at udvide grænserne for AI-forståelse.

Er benchmarks nok til LLM-ydelsesevaluering?

Ja, selvom de giver en standardiseret tilgang til at evaluere LLM-ydelse, kan de også være misvisende. Large Model Systems Organisation siger, at en god LLM-benchmark skal være skalerbar, i stand til at evaluere nye modeller med et relativt lille antal forsøg, og give en unik rangordning for alle modeller. Men der er årsager til, at de måske ikke er nok. Her er nogle:

Benchmark-lækage

Dette er en almindelig forekomst, og det sker, når træningsdata overlapper med testdata, hvilket giver en misvisende evaluering. Hvis en model allerede har mødt nogle testspørgsmål under træning, kan resultaterne ikke nøjagtigt afspejle dens sande evner. Men en ideal benchmark skal minimere huskning og afspejle virkelige scenarier.

Evaluations-forudindtagelse

LLM-benchmark-leaderboards bruges til at sammenligne LLM’ers ydelse på forskellige opgaver. Men at afhænge af disse leaderboards til model-sammenligning kan være misvisende. Simple ændringer i benchmark-test, som at ændre spørgsmålsrækkefølge, kan skifte modellens rangordning med op til otte positioner. Desuden kan LLM’er opføre sig forskelligt afhængigt af vurderingsmetoder, hvilket understreger vigtigheden af at overveje evaluations-forudindtagelse.

Åbenhed

Virkelige LLM-interaktioner indebærer at designe prompts til at generere ønskede AI-outputs. LLM-outputs afhænger af promptens effektivitet, og benchmarks er designet til at teste kontekstbevidsthed hos LLM’er. Selvom benchmarks er designet til at teste en LLM’s kontekstbevidsthed, oversætter de ikke altid direkte til virkelige performances. F.eks. en model, der opnår en score på 100% på en benchmark-datasæt, som LSAT, garanterer ikke det samme niveau af nøjagtighed i praktiske anvendelser. Dette understreger vigtigheden af at overveje den åbne natur af virkelige opgaver i LLM-evaluering.

Effektiv evaluering for robuste LLM’er

Så, nu ved du, at benchmarks ikke altid er den bedste løsning, fordi de ikke kan generalisere over alle problemer. Men der er andre måder.

Brugerdefinerede benchmarks

Disse er perfekte til at teste bestemte adfærd og funktioner i specifikke scenarier. Lad os sige, hvis en LLM er designet til medicinske officerer, vil datasættet samlet fra medicinske indstillinger effektivt repræsentere virkelige scenarier. Disse brugerdefinerede benchmarks kan fokusere på domæne-specifik sprogforståelse, ydelse og unikke kontekstuelle krav. Ved at tilpasse benchmarks til mulige virkelige scenarier kan du sikre, at LLM’en klarer sig godt generelt og excellerer i de specifikke opgaver, den er designet til. Dette kan hjælpe med at identificere og løse huller eller svagheder i modellens evner tidligt.

Data-lækage-detektions-pipeline

Hvis du ønsker, at dine evalueringer skal “vise” integritet, er det vigtigt at have en data-lækage-fri benchmark-pipeline. Data-lækage sker, når benchmark-data er inkluderet i modellens pre-træningskorpus, hvilket resulterer i kunstigt høje performancescore. For at undgå dette skal benchmarks være krydskontrolleret mod pre-træningsdata. Plus, skridt til at undgå tidligere set information. Dette kan indebære at bruge proprietære eller nyligt kuraterede datasæt, der holdes adskilt fra modellens træningspipeline – dette vil sikre, at performances-målinger afspejler modellens evne til at generalisere godt.

Menneske-evaluering

Automatiserede metrikker alene kan ikke fange det fulde spektrum af en modells ydelse, især når det kommer til meget nuancerede og subjektive aspekter af sprogforståelse og generering. Her giver menneske-evaluering en langt bedre vurdering:

• Ansættelse af professionelle, der kan give detaljerede og pålidelige vurderinger, især for specialiserede domæner.
• Crowdsourcing! Platforme som Amazon Mechanical Turk giver mulighed for at samle diverse menneskelige vurderinger hurtigt og til lav omkostning.
• Fællesskabs-feedback: At bruge platforme som LMSYS-leaderboard-arena, hvor brugere kan stemme og sammenligne modeller, tilføjer et ekstra lag af indsigt. LMSYS Chatbot Arena Hard, for eksempel, er særlig effektiv til at fremhæve subtile forskelle mellem top-modeller gennem direkte bruger-interaktioner og stemmer.

Konklusion

Uden evaluering og benchmarking ville vi ikke have nogen måde at vide, om LLM’ens evne til at håndtere virkelige opgaver er så nøjagtig og anvendelig, som vi tror. Men som jeg sagde, benchmarks er ikke en fuldstændig sikker måde at kontrollere dette på, de kan føre til huller i LLM’ers ydelse. Dette kan også langsommere udviklingen af LLM’er, der er virkelig robuste til arbejde.

Dette er, hvordan det bør være i en ideal verden. LLM’er forstår brugerforespørgsler, identificerer fejl i prompts, fuldfører opgaver som instrueret, og genererer pålidelige outputs. Resultaterne er allerede store, men ikke ideelle. Dette er, hvor opgave-specifikke benchmarks er meget nyttige, ligesom menneske-evaluering og detektion af benchmark-lækage. Ved at bruge disse får vi chancen for at producere virkelig robuste LLM’er.