BLEU: een verkeerd begrepen metriek uit een ander tijdperk

Maar het wordt nog steeds gebruikt in AI-onderzoek

GPT-3, Fluisteren, Palm, NLLB, VLAAI, en vele andere modellen zijn allemaal geëvalueerd met de statistiek BLEU om hun superioriteit bij sommige taken te claimen.

Maar wat is BLEU precies? Hoe werkt het?

In dit artikel gaan we twintig jaar geleden terug om de belangrijkste redenen bloot te leggen die BLEU tot stand hebben gebracht en er een zeer succesvolle metriek van hebben gemaakt. We zullen met enkele voorbeelden bekijken hoe BLEU werkt. Ik zal ook de belangrijkste beperkingen van de metriek belichten en aanbevelingen doen over hoe deze te gebruiken.

Dit artikel is bedoeld als een introductie tot BLEU, maar kan ook een geweldige herinnering zijn voor doorgewinterde NLP/AI-beoefenaars die BLEU gebruiken uit gewoonte in plaats van uit noodzaak.

BLEU werd voor het eerst beschreven in een IBM-onderzoeksrapport, mede geschreven door Kishore Papineni, Salim Roukos, Todd Ward en Wei-Jing Zhu, in 2001. Zij publiceerden een wetenschappelijk artikel dat dit beschrijft een jaar later op ACL 2002, dat veel meer geciteerd en gemakkelijk te vinden is.

BLEU werd oorspronkelijk voorgesteld als een automatische metriek om machinevertaling (MT) te evalueren.

In 2001 werden machinevertaalsystemen nog voornamelijk handmatig geëvalueerd of met behulp van oudere automatische metrieken zoals WER (woordfoutenpercentage). WER is een metriek geïnspireerd op de Levenshtein-afstand en wordt nog steeds gebruikt voor de evaluatie van spraakherkenningssystemen. Voor de evaluatie van machinevertalingen kan WER worden gezien als een voorloper van BLEU. De auteurs van BLEU verwoorden het als volgt:

We modelleren onze nabijheidsmetriek naar de zeer succesvolle maatstaf voor het aantal woordfouten die wordt gebruikt door de spraakherkenningsgemeenschap

Net als WER is BLEU een metriek die meet hoe dicht een tekst ligt bij referentieteksten die door mensen zijn geproduceerd, bijvoorbeeld referentievertalingen.

Omdat vertaling een taak is met meerdere correcte oplossingen, hebben de auteurs van BLEU hun metriek zo ontworpen dat deze meerdere referentievertalingen aankan. Dit was destijds niet nieuw aangezien WER al werd omgevormd tot een “mWER” om ook meerdere referenties te kunnen verwerken. Voor zover ik weet, is het voor het eerst voorgesteld door Alshawi et al. (1998) van AT&T Labs.

Het is belangrijk op te merken dat de auteurs in het hele artikel waarin BLEU wordt gepresenteerd, altijd uitgaan van het gebruik van meerdere referentievertalingen voor hun metriek. Ze bespreken kort het gebruik van een enkele referentievertaling om alleen onder bepaalde omstandigheden correct te zijn:

we kunnen een groot testcorpus gebruiken met één enkele referentievertaling, op voorwaarde dat de vertalingen niet allemaal van dezelfde vertaler zijn.

Tegenwoordig gebruiken de meeste onderzoeksartikelen daarentegen BLEU met a enkele referentie, vaak van een onbekende oorsprongEn voor verschillende taken, dat wil zeggen, niet alleen vertaling.

Sinds 2001 is BLEU op zijn zachtst gezegd een zeer succesvolle maatstaf geweest. Dit kwam mede door zijn goedkope rekenkosten en reproduceerbaarheid van BLEU-scores, in tegenstelling tot menselijke evaluatie waarbij de resultaten sterk kunnen variëren afhankelijk van de beoordelaars en het evaluatiekader.

BLEU is nu gebruikt in bijna 100% van de onderzoekspapers over machinevertaling en heeft zich grotendeels verspreid naar andere taken voor het genereren van natuurlijke taal.

Meer precies evalueert BLEU hoe goed de n-grammen van een vertaling zijn overeenkomend met de n-grammen uit een reeks referentievertalingen, terwijl het bestraffen van de machinevertaling als deze korter of langer is dan de referentievertalingen.

Enkele definities:

An n-gram is een reeks tokens. Laten we hier ook definiëren dat a teken is een reeks tekens die willekeurig worden begrensd door spaties. De zin 'een teken is geen woord' bijvoorbeeld. wordt vaak tokenized als “een token is geen woord.”. We zullen later in dit artikel meer bespreken over de uiterst belangrijke rol van tokenisatie.

Om BLEU in actie te zien, heb ik een voorbeeld geleend uit het BLEU-artikel van een zin in het Chinees (niet verstrekt door de auteurs) vertaald in het Engels. We hebben deze volgende 2 vertalingen gegenereerd door automatische vertaling:

En de volgende 3 referentievertalingen geleverd door mensen:

De vraag die wij met BLEU willen beantwoorden is:

Welke vertaling komt het dichtst in de buurt van de gegeven referentievertalingen?

Ik heb alle n-grammen gemarkeerd die onder de referentievertalingen vallen in beide kandidaatvertalingen.

Kandidaat 1 bestrijkt veel meer n-grammen uit de referentievertalingen, en aangezien de lengte (aantal tokens) ook redelijk overeenkomt met de lengte van de referentievertalingen, krijgt hij een hogere BLEU-score dan Kandidaat 2. Hier heeft BLEU gelijk aangezien Kandidaat 1 is inderdaad beter dan kandidaat 2.

Met dit voorbeeld kunnen we enkele duidelijke grenzen van BLEU zien. Er wordt geen rekening gehouden met de betekenis van de geëvalueerde vertaling. BLEU zocht alleen naar exacte overeenkomsten met de tokens van de referentievertalingen.

Bijvoorbeeld, "verzekeren” in Kandidaat 2 staat niet in de referentievertalingen, maar “waarborgt" is. Sinds "verzekeren'is niet precies hetzelfde als'waarborgt”, BLEU beloont het niet ondanks dat het een nauwe betekenis heeft.

Het kan zelfs nog erger zijn als we goed naar leestekens kijken. Kandidaat 2 eindigt bijvoorbeeld met een “.” maar deze periode is verbonden aan “direct.” om één token te vormen. “direct.” is geen teken van de referentievertalingen. Kandidaat 2 wordt niet beloond voor het correct invullen van deze periode.

Dit is de reden waarom BLEU meestal wordt berekend op basis van vertalingen die zijn getokeniseerd tot gesplitste tokens die leestekens bevatten. We zullen het in de volgende sectie verder bespreken.

Om het simpel te houden, zal ik de vergelijkingen achter BLEU niet bespreken. Als u geïnteresseerd bent om BLEU zelf te berekenen, nodig ik u uit om het BLEU-artikel te lezen waarin alle vergelijkingen goed gemotiveerd en uitgelegd zijn.

We hebben gezien dat BLEU erg streng is, omdat een token identiek moet zijn aan een token in de referentievertalingen om als match te tellen. Dit is waar tokenisatie een zeer belangrijke maar speelt vaak verkeerd begrepen rol.

De tokenisatie levert wat op flexibiliteit naar BLEU.

Laten we bijvoorbeeld nog eens naar kandidaat 2 kijken:

Het is bedoeld om ervoor te zorgen dat de troepen voor altijd de activiteitengids van die partij kunnen horen.

Maar deze keer passen we eenvoudige tokenisatieregels toe om leestekens van woorden te scheiden. We verkrijgen:

Het is bedoeld om ervoor te zorgen dat de troepen voor altijd de activiteitengids van die partij te horen krijgen.

Let daar op ".' is gescheiden van 'directe' door een spatie. Dit is het enige verschil. Kandidaat 2 komt nu overeen met nog een token uit de referentievertalingen. Dit teken is “.”. Het lijkt niet belangrijk omdat dit nog maar één teken is, maar dit komt zeer vaak voor. Deze tokenisatie zal impact hebben op vrijwel alle zinnen en leidt dus tot aanzienlijk betere BLEU-scores.

Er is een oneindig aantal mogelijke tokenisaties. De volgende Franse zinnen zijn bijvoorbeeld vertalingen uit het Engels, waarop ik 5 verschillende tokenizers toepas. Let op: ik heb gebruikt Mozes (open source, LGPL-licentie) en SacreBLEU (open source, Apache-licentie 2.0).

Dit zijn dezelfde zinnen, maar omdat ze anders zijn getokeniseerd, komen ze overeen met andere tokens uit de referentievertalingen. Al deze tokenisaties zullen verschillende BLEU-scores opleveren terwijl de vertalingen hetzelfde blijven.

Dit is de reden waarom twee BLEU-scores die zijn berekend op vertalingen waarvan de tokenisatie verschillend of onbekend is, niet kunnen worden vergeleken.

Dit is vaak vergeten in wetenschappelijke artikelen tegenwoordig.

Je kunt de tokenisatie zien als een parameter van BLEU. Als u de parameters wijzigt, wijzigt u de metriek. Scores uit twee verschillende statistieken kunnen niet worden vergeleken.

Toen BLEU in 2001 werd voorgesteld, was de kwaliteit van automatische vertaling heel anders.

Om u een idee te geven van dit verschil, heb ik geprobeerd een automatisch vertaalsysteem van Frans naar Engels uit de jaren 2000 na te bootsen. Voor dit doel heb ik een op woorden gebaseerd statistisch machinevertaalsysteem getraind. Ik deed het met Mozes. Ik zal dit systeem aanduiden als ‘statistisch MT (2001)’.

Vervolgens heb ik een neuraal machinevertaalsysteem getraind met behulp van een standaard Transformer-model. Ik deed het met Marian (open source, MIT-licentie). Ik zal dit systeem aanduiden als ‘neurale MT (2022)’.

De vertalingen die ze genereren zijn als volgt. Opmerking: ik heb de n-grammen gemarkeerd die overeenkomen met de referentievertaling.

Zoals verwacht heeft de door statistische MT gegenereerde vertaling niet veel zin, vooral niet aan het einde van de zin. Het bestrijkt minder n-grammen van de referentievertaling dan neurale MT. Aan de andere kant ziet de door neurale MT gegenereerde vertaling er perfect uit (zonder context), maar is deze niet precies hetzelfde als de referentievertaling, dus wordt deze bestraft door BLEU.

In 2001 genereerden automatische vertaalsystemen vertalingen die vaak betekenisloos waren en duidelijke syntactische fouten bevatten. Ze werden terecht gestraft omdat ze niet overeenkwamen met bepaalde referentievertalingen. Tegenwoordig genereert neurale machinevertaling vaak zeer vloeiende vertalingen, vooral voor ‘gemakkelijke’ talencombinaties zoals Frans-Engels. Ze zullen vaak de juiste vertaling vinden, maar aangezien er veel mogelijke correcte vertalingen zijn, kan het vinden van de exacte vertaling die als referentie wordt gebruikt slechts bij toeval gebeuren.

Dit is waar we de grenzen van BLEU bereiken, die alleen exacte overeenkomsten beloont, zelfs als de vertaling correct is.

BLEU begeleidt al jaren de vooruitgang in het onderzoek naar machinevertalingen. Op NAACL 2018 ontvingen de auteurs van BLEU een prijs voor de tand des tijds.

BLEU wordt nog steeds op veel gebieden van AI gebruikt, maar alleen door gewoonten. Het wordt nu grotendeels overtroffen door veel andere evaluatiestatistieken voor taken voor het genereren van natuurlijke taal, waaronder automatische vertalingen, zoals chF, BLEURTof KOMEET.

Niettemin blijft BLEU een zeer goed hulpmiddel voor diagnostische doeleinden.

Omdat BLEU een bekend gedrag vertoont, dwz we weten welk BLEU-niveau we kunnen verwachten voor bepaalde vertaaltaken, kan het worden gebruikt om snel bugs en andere problemen op te sporen in de trainingspijplijn van een automatisch vertaalsysteem of in de gegevensverwerking ervan.

BLAUW in ieder geval mag niet worden gebruikt op korte teksten. In de praktijk voeren beoefenaars van machinevertalingen BLEU altijd uit op teksten die meer dan 1,000 zinnen bevatten. BLEU is bedoeld om de vertaling van documenten te evalueren. Het mag niet worden gebruikt om de vertaling van zinnen te evalueren.

Wat de implementaties van BLEU betreft, vele zijn openbaar beschikbaar. Hugging Face heeft een eigen implementatie in de Evalueer bibliotheek. NLTK implementeert ook BLEU. Er is ook de multi-blauw.perl script in het Moses-project. Merk op dat al deze implementaties van BLEU verschillend zijn en geen vergelijkbare resultaten zullen opleveren. Mijn persoonlijke aanbeveling is om de originele implementatie van te gebruiken SacreBLEU aangezien deze tool bedoeld was om de reproduceerbaarheid en vergelijkbaarheid van BLEU-scores te garanderen.

En als u van plan bent BLEU in uw volgende werk te gebruiken, vergeet dan niet de noodzaak om de statistische significantie van uw resultaten te testen.

De beste manier om mijn werk te ondersteunen is door Medium-lid te worden via mijn link:

Als u al lid bent en dit werk wilt steunen, gewoon volg mij op Medium.