BLEU: A Misunderstood Metric from Another Age

Men fortsatt brukt i dag i AI-forskning

GPT-3, Hviske, PALM, NLLB, FLAN, og mange andre modeller har alle blitt evaluert med den metriske BLEU for å hevde sin overlegenhet i noen oppgaver.

Men hva er egentlig BLEU? Hvordan virker det?

I denne artikkelen vil vi gå tilbake for 20 år siden for å avsløre hovedårsakene som førte til BLEU og gjorde det til en svært vellykket beregning. Vi skal se på hvordan BLEU fungerer med noen eksempler. Jeg vil også fremheve hovedgrensene for beregningen og gi anbefalinger om hvordan du bruker den.

Denne artikkelen er tenkt som en introduksjon til BLEU, men kan også være en god påminnelse for erfarne NLP/AI-utøvere som bruker BLEU etter vaner i stedet for behov.

BLEU ble først beskrevet i en IBM-forskningsrapport medforfatter av Kishore Papineni, Salim Roukos, Todd Ward og Wei-Jing Zhu, i 2001. De publiserte en vitenskapelig artikkel som beskriver det ett år senere på ACL 2002 som er mye mer sitert og lett å finne.

BLEU ble opprinnelig foreslått som en automatisk beregning for å evaluere maskinoversettelse (MT).

I 2001 ble maskinoversettelsessystemer fortsatt hovedsakelig evaluert manuelt, eller ved bruk av eldre automatiske beregninger som WER (ordfeilrate). WER er en metrikk inspirert fra Levenshtein-avstanden og brukes fortsatt i dag for evaluering av talegjenkjenningssystemer. For maskinoversettelsesevaluering kan WER sees på som en stamfar til BLEU. Forfatterne av BLEU uttrykker det som følger:

Vi lager nærhetsberegningen vår etter den svært vellykkede beregningen for ordfeilfrekvens som brukes av talegjenkjenningsfellesskapet

I likhet med WER er BLEU en beregning som måler hvor nær en tekst er referansetekster produsert av mennesker, f.eks. referanseoversettelser.

Oversettelse er en oppgave med flere riktige løsninger, og forfatterne av BLEU designet sin metrikk slik at den kan håndtere flere referanseoversettelser. Dette var ikke nytt på den tiden siden WER allerede ble omdannet til en "mWER" for også å håndtere flere referanser. Så vidt jeg vet har den først blitt foreslått av Alshawi et al. (1998) fra AT&T Labs.

Det er viktig å merke seg at i hele artikkelen som presenterer BLEU, antar forfatterne alltid bruken av flere referanseoversettelser for deres metriske. De diskuterer kort bruken av en enkelt referanseoversettelse for å være korrekt bare under noen omstendigheter:

vi kan bruke et stort testkorpus med en enkelt referanseoversettelse, forutsatt at oversettelsene ikke alle er fra samme oversetter.

I motsetning, i dag, bruker de fleste forskningsartikler BLEU med en enkelt referanse, ofte fra en ukjent opprinnelse, Og for ulike oppgaver, dvs. ikke bare oversettelse.

Siden 2001 har BLEU mildt sagt vært en svært vellykket beregning. Dette var delvis på grunn av dens billig beregningskostnad og reproduserbarhet av BLEU-poeng, i motsetning til menneskelig evaluering hvor resultatene kan variere mye avhengig av evaluatorene og evalueringsrammeverket.

BLEU er nå brukt i nesten 100 % av forskningsarbeidene for maskinoversettelse og har i stor grad spredt seg til andre naturspråkgenereringsoppgaver.

Mer presist evaluerer BLEU hvor godt n-grammene til en oversettelse er samsvarer med n-grammene fra et sett med referanseoversettelser, mens straffe maskinoversettelsen hvis den er kortere eller lengre enn referanseoversettelsene.

Noen definisjoner:

An n-gram er en sekvens av tokens. La oss også definere her at a token er en sekvens av tegn vilkårlig avgrenset med mellomrom. For eksempel setningen "et symbol er ikke et ord." vil ofte bli symbolisert som "et symbol er ikke et ord .". Vi vil diskutere mer om den ekstremt viktige rollen til tokenisering senere i denne artikkelen.

For å se BLEU i aksjon, lånte jeg et eksempel fra BLEU-artikkelen på en setning på kinesisk (ikke levert av forfatterne) oversatt til engelsk. Vi har følgende 2 oversettelser generert av maskinoversettelse:

Og følgende 3 referanseoversettelser levert av mennesker:

Spørsmålet vi ønsker å svare på med BLEU er:

Hvilken oversettelse er nærmest de gitte referanseoversettelsene?

Jeg fremhevet alle n-grammene som dekkes av referanseoversettelsene i begge kandidatoversettelsene.

Kandidat 1 dekker mange flere n-gram fra referanseoversettelsene, og siden lengden (antall tokens) også rimelig samsvarer med lengden på referanseoversettelsene, vil den få en høyere BLEU-score enn kandidat 2. Her er BLEU riktig siden kandidat 1 er faktisk bedre enn kandidat 2.

Med dette eksemplet kan vi se noen åpenbare grenser for BLEU. Betydningen av den evaluerte oversettelsen vurderes ikke. BLEU søkte bare etter eksakte treff med symbolene til referanseoversettelsene.

For eksempel, "sikre" i kandidat 2 er ikke i referanseoversettelsene, men "sikrer" er. Siden "sikre" er ikke akkurat det samme som "sikrer”, BLEU belønner det ikke til tross for at det har en nær betydning.

Det kan bli enda verre når vi ser nøye på skilletegn. For eksempel slutter kandidat 2 med en "." men denne perioden er knyttet til "umiddelbart." for å danne et enkelt token. "umiddelbart.” er ikke et tegn på referanseoversettelsene. Kandidat 2 blir ikke belønnet for å inneholde denne perioden korrekt.

Dette er grunnen til at BLEU vanligvis beregnes på oversettelser som er tokenisert til delte tokens som inneholder skilletegn. Vi vil diskutere det videre i neste avsnitt.

For å holde det enkelt, vil jeg ikke diskutere ligningene bak BLEU. Hvis du er interessert i å beregne BLEU selv, inviterer jeg deg til å lese BLEU-oppgaven der alle ligningene er godt motiverte og forklart.

Vi så at BLEU er veldig streng siden en token skal være identisk med en token i referanseoversettelsene for å telle som en match. Det er her tokenisering spiller et veldig viktig men ofte misforstått rolle.

Tokeniseringen gir noe fleksibilitet til BLEU.

La oss for eksempel se på kandidat 2 igjen:

Det er for å sikre at troppene alltid hører aktivitetsguiden som partiet leder.

Men denne gangen bruker vi enkle tokeniseringsregler for å skille skilletegn fra ord. Vi oppnår:

Det er for å sikre at troppene alltid hører aktivitetsguiden som partiet leder.

Noter det "." har blitt skilt fra "direkte” ved et mellomrom. Dette er den eneste forskjellen. Kandidat 2 matcher nå en annen token fra referanseoversettelsene. Dette tokenet er ".". Det virker ikke viktig siden dette bare er ett token til, men dette er veldig hyppig. Denne tokeniseringen vil ha innvirkning på nesten alle setninger og fører dermed til betydelig bedre BLEU-score.

Det er en uendelig mengde mulige tokeniseringer. For eksempel er følgende franske setninger oversettelser fra engelsk som jeg bruker 5 forskjellige tokenizere på. Merk: Jeg brukte Moses (åpen kildekode, LGPL-lisens) og SacreBLEU (åpen kildekode, Apache License 2.0).

Dette er de samme setningene, men siden de er tokenisert forskjellig, vil de matche forskjellige tokens fra referanseoversettelsene. Alle disse tokeniseringene vil gi forskjellige BLEU-poengsummer mens oversettelsene forblir de samme.

Dette er grunnen til at to BLEU-score beregnet på oversettelser der tokeniseringen er forskjellig eller ukjent, ikke kan sammenlignes.

Dette er ofte oversett i vitenskapelige artikler i dag.

Du kan se tokeniseringen som en parameter for BLEU. Hvis du endrer parameterne, endrer du beregningen. Poeng fra to forskjellige beregninger kan ikke sammenlignes.

Da BLEU ble foreslått i 2001, var kvaliteten på maskinoversettelse svært forskjellig.

For å gi deg en idé om denne forskjellen, prøvde jeg å gjenskape et fransk-til-engelsk maskinoversettelsessystem fra 2000-tallet. For dette formålet trente jeg opp et ordbasert statistisk maskinoversettelsessystem. jeg gjorde det med Moses. Jeg vil betegne dette systemet "statistisk MT (2001)."

Deretter trente jeg et nevralt maskinoversettelsessystem ved å bruke en vaniljetransformatormodell. jeg gjorde det med Marian (åpen kildekode, MIT-lisens). Jeg vil betegne dette systemet "neural MT (2022)."

Oversettelsene de genererer er som følger. Merk: Jeg fremhevet n-grammene som samsvarer med referanseoversettelsen.

Som forventet gir ikke oversettelsen generert av statistisk MT mye mening, spesielt mot slutten av setningen. Den dekker mindre n-gram fra referanseoversettelsen enn neural MT. På den annen side ser oversettelsen generert av neural MT perfekt ut (uten kontekst), men den er ikke akkurat det samme som referanseoversettelsen, så den vil bli straffet av BLEU.

I 2001 genererte maskinoversettelsessystemer oversettelser som ofte var meningsløse og med åpenbare syntaktiske feil. De ble rettmessig straffet for ikke å matche bestemte referanseoversettelser. I dag genererer nevral maskinoversettelse ofte svært flytende oversettelser, spesielt for "enkle" språkpar som fransk-engelsk. De vil ofte finne den riktige oversettelsen, men siden det er mange mulige korrekte oversettelser, kan det bare skje ved en tilfeldighet å finne den nøyaktige oversettelsen som brukes som referanse.

Det er her vi treffer grensene for BLEU som kun vil belønne eksakte treff selv når oversettelsen er korrekt.

BLEU har ledet fremgangen innen maskinoversettelsesforskning i mange år. På NAACL 2018 mottok forfatterne av BLEU en prøvepris.

BLEU brukes fortsatt i mange områder av AI, men bare av vaner. Det er nå i stor grad utkonkurrert av mange andre evalueringsmålinger for generering av naturlige språk, inkludert maskinoversettelse, som f.eks. chrF, BLEURTeller KOMET.

Ikke desto mindre forblir BLEU en veldig godt verktøy for diagnostiske formål.

Siden BLEU har en velkjent oppførsel, dvs. vi vet hvilket nivå av BLEU vi kan forvente for bestemte oversettelsesoppgaver, kan den brukes til å raskt oppdage feil og andre problemer i opplæringspipelinen til et maskinoversettelsessystem eller i dets databehandling.

I alle fall BLEU bør ikke brukes på korte tekster. I praksis kjører maskinoversetter alltid BLEU på tekster som inneholder mer enn 1,000 setninger. BLEU er ment å evaluere dokumentoversettelse. Det bør ikke brukes til å evaluere setningsoversettelse.

Når det gjelder implementeringene av BLEU, er mange offentlig tilgjengelige. Hugging Face har sin egen implementering i Vurdere biblioteket. NLTK implementerer også BLEU. Det er også multi-bleu.perl manus i Moses-prosjektet. Merk at alle disse implementeringene av BLEU er forskjellige og vil ikke gi sammenlignbare resultater. Min personlige anbefaling er å bruke den opprinnelige implementeringen av SacreBLEU siden dette verktøyet var ment å garantere reproduserbarheten og sammenlignbarheten til BLEU-score.

Og hvis du planlegger å bruke BLEU i ditt neste arbeid, ikke overse behovet for å teste den statistiske signifikansen til resultatene dine.

Den beste måten å støtte arbeidet mitt på er å bli et medium medlem ved å bruke lenken min:

Hvis du allerede er medlem og ønsker å støtte dette arbeidet, bare følg meg på Medium.