BLEU: A Misunderstood Metric from Another Age

Men bruges stadig i dag i AI-forskning

GPT-3, Hviske, Håndflade, NLLB, FLAN, og mange andre modeller er alle blevet evalueret med den metriske BLEU for at hævde deres overlegenhed i nogle opgaver.

Men hvad er BLEU helt præcist? Hvordan virker det?

I denne artikel vil vi gå tilbage for 20 år siden for at afsløre de vigtigste årsager, der bragte BLEU til eksistens og gjorde det til et meget vellykket mål. Vi vil se på, hvordan BLEU fungerer med nogle eksempler. Jeg vil også fremhæve de vigtigste begrænsninger for metrikken og give anbefalinger til, hvordan man bruger den.

Denne artikel er tænkt som en introduktion til BLEU, men kan også være en god påmindelse for erfarne NLP/AI-udøvere, der bruger BLEU efter vaner frem for behov.

BLEU blev første gang beskrevet i en IBM-forskningsrapport, medforfattet af Kishore Papineni, Salim Roukos, Todd Ward og Wei-Jing Zhu, i 2001. De udgav en videnskabelig artikel, der beskriver det et år senere på ACL 2002, som er meget mere citeret og let at finde.

BLEU blev oprindeligt foreslået som en automatisk metrik til at evaluere maskinoversættelse (MT).

I 2001 blev maskinoversættelsessystemer stadig primært evalueret manuelt eller ved hjælp af ældre automatiske metrikker såsom WER (ordfejlhastighed). WER er en metrik inspireret af Levenshtein-distancen og bruges stadig i dag til evaluering af talegenkendelsessystemer. Til maskinoversættelsesevaluering kan WER ses som en forfader til BLEU. Forfatterne af BLEU udtrykker det som følger:

Vi danner vores nærhedsmetrik efter den meget succesrige metrik for ordfejlfrekvens, der bruges af talegenkendelsesfællesskabet

Ligesom WER er BLEU et mål, der måler hvor tæt en tekst er på referencetekster produceret af menneskerf.eks. referenceoversættelser.

Da oversættelse er en opgave med flere korrekte løsninger, har forfatterne af BLEU designet deres metrik, så den kan håndtere flere referenceoversættelser. Dette var ikke nyt på det tidspunkt, da WER allerede var ved at blive omdannet til en "mWER" for også at håndtere flere referencer. Så vidt jeg ved, er det først blevet foreslået af Alshawi et al. (1998) fra AT&T Labs.

Det er vigtigt at bemærke, at i hele papiret, der præsenterer BLEU, antager forfatterne altid brugen af ​​flere referenceoversættelser til deres metrik. De diskuterer kort brugen af ​​en enkelt referenceoversættelse for kun at være korrekt under nogle omstændigheder:

vi kan bruge et stort testkorpus med en enkelt referenceoversættelse, forudsat at oversættelserne ikke alle er fra den samme oversætter.

I modsætning hertil bruger de fleste forskningsartikler i dag BLEU med en enkelt reference, ofte fra en ukendt oprindelse, Og forskellige opgaver, dvs. ikke kun oversættelse.

Siden 2001 har BLEU mildest talt været en meget succesfuld målestok. Dette skyldtes til dels dens billige beregningsomkostninger og reproducerbarhed af BLEU-score, i modsætning til menneskelig evaluering, hvor resultaterne kan variere meget afhængigt af evaluatorerne og evalueringsrammerne.

BLEU er nu brugt i næsten 100 % af forskningsartiklerne om maskinoversættelse og har stort set spredt sig til andre naturlige sproggenereringsopgaver.

Mere præcist vurderer BLEU, hvor godt n-grammene af en oversættelse er matcher n-grammene fra et sæt referenceoversættelser, mens straffe maskinoversættelsen, hvis den er kortere eller længere end referenceoversættelserne.

Nogle definitioner:

An n-gram er en sekvens af tokens. Lad os også her definere, at en token er en sekvens af tegn vilkårligt afgrænset af mellemrum. For eksempel sætningen "en token er ikke et ord." vil ofte blive tokeniseret som "et token er ikke et ord". Vi vil diskutere mere om tokeniseringens ekstremt vigtige rolle senere i denne artikel.

For at se BLEU i aktion lånte jeg et eksempel fra BLEU-papiret på en sætning på kinesisk (ikke leveret af forfatterne) oversat til engelsk. Vi har følgende 2 oversættelser genereret ved maskinoversættelse:

Og følgende 3 referenceoversættelser leveret af mennesker:

Spørgsmålet vi ønsker at besvare med BLEU er:

Hvilken oversættelse er tættest på de givne referenceoversættelser?

Jeg fremhævede alle de n-grammer, der er dækket af referenceoversættelserne i begge kandidatoversættelser.

Kandidat 1 dækker mange flere n-gram fra referenceoversættelserne, og da dens længde (antal tokens) også rimeligt matcher længden af ​​referenceoversættelserne, vil den få en højere BLEU-score end kandidat 2. Her er BLEU korrekt, da kandidat 1 er faktisk bedre end kandidat 2.

Med dette eksempel kan vi se nogle åbenlyse grænser for BLEU. Betydningen af ​​den evaluerede oversættelse tages ikke i betragtning. BLEU søgte kun efter nøjagtige matches med tokens fra referenceoversættelserne.

For eksempel, "sikre" i kandidat 2 er ikke i referenceoversættelserne, men "sikrer” er. Siden "sikre" er ikke helt det samme som "sikrer”, BLEU belønner det ikke på trods af at det har en nær betydning.

Det kan være endnu værre, når vi nøje ser på tegnsætningstegn. For eksempel slutter kandidat 2 med et "." men denne periode er knyttet til "med det samme.” for at danne et enkelt token. “med det samme.” er ikke et tegn på referenceoversættelserne. Kandidat 2 bliver ikke belønnet for korrekt at indeholde denne periode.

Dette er grunden til, at BLEU normalt beregnes på oversættelser, der er tokeniseret til opdelte tokens, der indeholder tegnsætningstegn. Vi vil diskutere det yderligere i næste afsnit.

For at holde det enkelt vil jeg ikke diskutere ligningerne bag BLEU. Hvis du er interesseret i selv at beregne BLEU, inviterer jeg dig til at læse BLEU-papiret, hvor alle ligningerne er velmotiverede og forklaret.

Vi så, at BLEU er meget streng, da et token skal være identisk med et token i referenceoversættelserne for at tælle som et match. Det er her tokenisering spiller et meget vigtigt men ofte misforstået rolle.

Tokeniseringen giver nogle fleksibilitet til BLEU.

Lad os for eksempel se igen på kandidat 2:

Det er for at sikre, at tropperne for evigt hører aktivitetsvejledningen, som partiet leder.

Men denne gang anvender vi simple tokeniseringsregler for at adskille tegnsætningstegn fra ord. Vi får:

Det er for at sikre, at tropperne for evigt hører aktivitetsvejledningen, som partiet leder.

Noter det "." er blevet adskilt fra "direkte” ved et mellemrum. Dette er den eneste forskel. Kandidat 2 matcher nu endnu et token fra referenceoversættelserne. Dette token er ".”. Det virker ikke vigtigt, da dette kun er et token mere, men dette er meget hyppigt. Denne tokenisering vil have en indvirkning på næsten alle sætninger og fører dermed til markant bedre BLEU-score.

Der er en uendelig mængde af mulige tokeniseringer. For eksempel er de følgende franske sætninger oversættelser fra engelsk, som jeg anvender 5 forskellige tokenizere på. Bemærk: Jeg brugte Moses (open source, LGPL-licens) og SacreBLEU (open source, Apache License 2.0).

Dette er de samme sætninger, men da de er tokeniseret forskelligt, vil de matche forskellige tokens fra referenceoversættelserne. Alle disse tokeniseringer vil give forskellige BLEU-score, mens oversættelserne forbliver de samme.

Dette er grunden til, at to BLEU-score beregnet på oversættelser, for hvilke tokeniseringen er anderledes eller ukendt, ikke kan sammenlignes.

Dette er ofte overset i videnskabelige artikler i dag.

Du kan se tokeniseringen som en parameter for BLEU. Hvis du ændrer parametrene, ændrer du metrikken. Resultater fra to forskellige metrics kan ikke sammenlignes.

Da BLEU blev foreslået i 2001, var kvaliteten af ​​maskinoversættelse meget anderledes.

For at give dig en idé om denne forskel, forsøgte jeg at genskabe et fransk-til-engelsk maskinoversættelsessystem fra 2000'erne. Til dette formål trænede jeg et ordbaseret statistisk maskinoversættelsessystem. jeg gjorde det med Moses. Jeg vil betegne dette system "statistisk MT (2001)."

Derefter trænede jeg et neuralt maskinoversættelsessystem ved hjælp af en vanilje Transformer-model. jeg gjorde det med Marian (open source, MIT-licens). Jeg vil betegne dette system "neural MT (2022)."

De oversættelser, de genererer, er som følger. Bemærk: Jeg fremhævede de n-grammer, der matcher referenceoversættelsen.

Som forventet giver oversættelsen genereret af statistisk MT ikke meget mening, især mod slutningen af ​​sætningen. Den dækker mindre n-gram fra referenceoversættelsen end neural MT. På den anden side ser oversættelsen genereret af neural MT perfekt ud (uden kontekst), men den er ikke helt den samme som referenceoversættelsen, så den vil blive straffet af BLEU.

I 2001 genererede maskinoversættelsessystemer oversættelser, der ofte var meningsløse og med åbenlyse syntaktiske fejl. De blev med rette straffet for ikke at matche bestemte referenceoversættelser. Nu om dage genererer neural maskinoversættelse ofte meget flydende oversættelser, især for "lette" sprogpar såsom fransk-engelsk. De vil ofte finde den rigtige oversættelse, men da der er mange mulige korrekte oversættelser, kan det kun ske tilfældigt at finde den nøjagtige oversættelse, der bruges som reference.

Det er her, vi rammer grænserne for BLEU, der kun belønner eksakte matches, selv når oversættelsen er korrekt.

BLEU har ledet fremskridtene inden for maskinoversættelsesforskning i mange år. Ved NAACL 2018 modtog forfatterne af BLEU en prøvepræmie.

BLEU bruges stadig i mange områder af kunstig intelligens, men kun af vaner. Det er nu stort set udkonkurreret af mange andre evalueringsmetrikker for opgaver, der genererer naturligt sprog, herunder maskinoversættelse, som f.eks. chrF, BLEURT eller KOMET.

Ikke desto mindre forbliver BLEU en meget godt værktøj til diagnostiske formål.

Da BLEU har en velkendt adfærd, dvs. vi ved, hvilket niveau af BLEU vi kan forvente til bestemte oversættelsesopgaver, kan det bruges til hurtigt at opdage fejl og andre problemer i træningspipelinen af ​​et maskinoversættelsessystem eller i dets databehandling.

I hvert fald BLEU bør ikke bruges på korte tekster. I praksis kører maskinoversættelser altid BLEU på tekster, der indeholder mere end 1,000 sætninger. BLEU er beregnet til at evaluere dokumentoversættelse. Det bør ikke bruges til at evaluere sætningsoversættelse.

Hvad angår implementeringerne af BLEU, er mange offentligt tilgængelige. Hugging Face har sin egen implementering i Evaluer biblioteket. NLTK implementerer også BLEU. Der er også multi-bleu.perl manuskript i Moses-projektet. Bemærk, at alle disse implementeringer af BLEU er forskellige og ikke vil give sammenlignelige resultater. Min personlige anbefaling er at bruge den originale implementering af SacreBLEU da dette værktøj var beregnet til at garantere reproducerbarheden og sammenligneligheden af ​​BLEU-score.

Og hvis du planlægger at bruge BLEU i dit næste arbejde, skal du ikke overse behovet for at teste den statistiske signifikans af dine resultater.

Den bedste måde at støtte mit arbejde på er at blive et medium medlem ved at bruge mit link:

Hvis du allerede er medlem og ønsker at støtte dette arbejde, så bare følg mig på Medium.