• Facetten van Natural Language Processing: deel 1 & deel 2
• NLP & Modèles de langue (FR)
• Named Entity Recognition: une application pratique du NLP (FR)
• API’s voor computervertaling & in de praktijk

NLP is een belangrijke component in toepassingen zoals chatbots en voicebots. Het kan ook ingezet worden om data te annoteren en bv. een knowledge graph te verrijken, wat dan weer beter kennisbeheer en -ontsluiting mogelijk maakt.

Het is niet zo moeilijk voor iemand met wat programmeervaardigheden om met NLP te experimenteren. Veel code is open source, en er zijn talloze goede tutorials te vinden, compleet met educatieve notebooks in Jupyter of Google Colab en duidelijke instructievideo’s. Maar deze beperken zich veelal tot het Engels, of heel af en toe een andere grote wereldtaal.

We lezen dan wel met de regelmaat van de klok over spectaculaire vooruitgang met NLP in het Engels – herinner u GPT-3 – maar over minder courant gesproken talen horen we weinig. Iemand die NLP probeert toe te passen op het Nederlands, komt dan ook plots een paar obstakels tegen. Ook De Standaard merkte dit recent op, en wist daarbij te vertellen dat de trainingsdata van GPT-3 voor 92% uit Engelse tekst bestaat en voor 0,35% uit Nederlandse – toch een stevige grootteorde verschil.

(Noot: de evoluties in het domein van NLP en de beschikbare tools gaan snel; dit artikel is dus accuraat op het moment van schrijven maar de situatie kan volgend jaar al helemaal anders zijn.)

SpaCy is een bekende open-source Python library voor NLP. Ze is gebruiksvriendelijk en abstraheert veel van de onderliggende complexiteit van NLP of de achterliggende Machine Learning frameworks zoals PyTorch of Tensorflow weg. Sinds versie 3.0 ondersteunen ze ook de transformer deep learning architecturen, die aan de basis liggen van de meest succesvolle recente taalmodellen. We gebruiken deze versie van SpaCy voor al wat volgt. Alternatieven voor SpaCy zijn o.a. Stanza en Flair.

Entiteiten herkennen

Een ingebouwde functionaliteit van hun taalmodellen is Named Entity Recognition (NER), het herkennen van entiteiten in een tekst. In de documentatie bij elk taalmodel zien we in het label scheme o.a. alle categorieën die het model kan herkennen: DATE, TIME, PERCENT etc., maar ook PERSON (eigennamen), PRODUCT of WORK_OF_ART. Het is gemakkelijk dit zelf uit te proberen op een klein stukje tekst, geïnspireerd op hun tutorial:

import spacy
from spacy import displacy
nlp = spacy.load("en_core_web_sm")
doc = nlp("Apple buys a French company for $1 billion.")
displacy.render(doc, style="ent")

We merken dat Apple wordt herkend als ORG (organisatie), French als NORP (nationaliteit of religieuze/politieke groep) en $1 billion als een geldhoeveelheid. Proberen we echter hetzelfde in het Nederlands:

import spacy
from spacy import displacy
nlp = spacy.load("nl_core_news_sm")
doc = nlp("Apple koopt een Frans bedrijf voor $1 miljard.")
displacy.render(doc, style="ent")

In het Nederlands wordt Apple plots aanzien als persoon en wordt 1 aangeduid als simpel telwoord! Eerlijkheid gebiedt ons te zeggen dat de grote versie van het taalmodel dit wel correct annoteert, op het dollarteken na. De kleine taalmodellen die we hier hebben gebruikt illustreren echter wel een belangrijk punt: er is geen garantie dat wat werkt in de ene taal, daarom ook even goed zou werken in een andere taal, ook al lijkt het dat de taalmodellen slechts verschillen qua taalcode. Het repliceren van Engelstalige NLP-succesverhalen in een andere taal, is dus geen kwestie van even snel copy-pasten.

Waarom dat verschil?

Een blik op de onderliggende automatische grammaticale analyse maakt een en ander duidelijk:

displacy.render(list(doc.sents), style="dep")

De betekenis van alle afkortingen voor woordsoorten en -functies kan je terugvinden op de website van Universal Dependencies. Wat blijkt:

• billion wordt aanzien als telwoord, miljard als zelfstandig naamwoord.
• $ wordt in het Engels als symbool, in het Nederlands als naamwoord geannoteerd.
• In het Engels is “for $1 billion” afhankelijk van het werkwoord (een bijwoordelijke bepaling), in het Nederlands wordt “voor $1 miljard” als afhankelijk van het naamwoord bedrijf beschouwd.
• Apple wordt in beide talen correct aangeduid als eigennaam en onderwerp, dus de grammaticale analyse alleen is niet genoeg om het onderscheid te verklaren.

SpaCy‘s taalmodel voor het Nederlands ziet de zaken dus anders dan dat voor het Engels. De documentatie ervan laat zien dat de componenten tagger en parser, die de zinsontleding voor hun rekening nemen, ook heel anders georganiseerd zijn in het Nederlands en veel complexer (of fijnmaziger?) lijken dan die voor het Engels. Ook lezen we elders dat de dataset waarop de grammaticale analyse is getraind, anders is: OntoNotes 5 voor het Engels, en LassySmall 2.5 en Alpino uit Universal Dependencies voor het Nederlands.

Lassy, Alpino en OntoNotes

Lassy heeft haar oorsprong in de academische wereld van de computationeel taalkundigen. Er bestaat een kleine versie en een grote versie: LassyKlein met ongeveer 1 miljoen woorden, is manueel geverifieerd; LassyGroot met ongeveer 700 miljoen woorden, is automatisch geannoteerd met het programma Alpino . Ze gebruikten een eigen XML-annotatieformaat geïnspireerd op het eerdere project Corpus Gesproken Nederlands. Dit formaat verschilt nogal van het CoNLL formaat dat vaak gebruikt wordt voor opslag van dit soort gegevens, en dat de standaard is voor de Universal Dependencies datasets. Na omzetting met een convertor kon wel een subset van LassyKlein daarin opgenomen worden als UD_Dutch-LassySmall. Men is daarbij wel heel selectief geweest: enkel een subset uit Wikipedia is bewaard, met daarin 7388 zinnen van in totaal 98163 woorden.

Een andere dataset gebaseerd op voornamelijk nieuwsartikels is ook beschikbaar: UD_Dutch-Alpino, met daarin 13578 zinnen met 208601 woorden. Wie enkele van de zinnen leest, merkt dat ze vooral verzameld zijn in de vroege jaren 2000. Onderwerpen die ter sprake komen zijn bijvoorbeeld Brussel-Halle-Vilvoorde, Justine Henin-Hardenne en Wim Kok als premier van Nederland.

OntoNotes 5.0 is het Engelstalige bronmateriaal voor SpaCy’s grammaticale analyse. Het bevat naar schatting 2 miljoen woorden in +/- 300000 zinnen uit gevarieerde bronnen: het merendeel uit nieuwsartikels waarvan een deel ook uit vertaalde internationale bronnen, en dan nog een klein deel uit blogs en stukken uit de Bijbel. De dataset kan gezien worden als een opvolger van de Penn Treebank , een van de eerste grote datasets voor automatische syntactische analyse. Ook OntoNotes is niet in het CoNLL formaat en vereist dus een omzetting.

Om een model te kunnen trainen, moet SpaCy de CoNLL-data nog converteren in haar eigen interne formaat.

Nederlandstalige datasets: werk aan de winkel

Het valt op dat er zowat 10 keer minder trainingsdata beschikbaar is voor het Nederlands dan voor het Engels. Daarbij komt ook het uitgebreidere label schema in de woordsoort-tagger, dus minder voorbeelden per label, en een beperkte variatie in het bronmateriaal – enkel oude nieuws- en Wikipedia-artikelen. Dan is het geen verrassing dat zelfs het beste (ingebouwde) Nederlandse taalmodel in SpaCy qua accuraatheid in detectie van woordsoort (part-of-speech tags, 95%), zinsstructuur (labeled dependencies, 82%) en entiteiten (F-score 77%) achterblijft op hun slechtste Engelse taalmodel (resp. 97%, 90%, 84%) – laat staan dat het in de buurt komt van het beste Engelse taalmodel (resp. 98%, 94%, 90%). Dat laatste is weliswaar een gloednieuw transformer-model, en het valt te verwachten dat we dit type binnenkort ook voor het Nederlands zullen mogen verwachten in SpaCy, gezien er al enkele beschikbaar zijn in de transformers model hub.

Wil men de achterstand echt structureel inhalen, dan zal men op een bepaald moment toch werk moeten maken van grotere Nederlandstalige datasets voor het trainen van taalmodellen. Dat vergt veel middelen en tijd, maar misschien kan een gedeeltelijke automatisering met behulp van wat vandaag al bestaat qua automatische annotatie, aangevuld met crowdsourcing voor bv. de validatie, de zaken wat versnellen. In de zijlijn: voor het trainen van word embeddings / vectors hoeft de tekst niet geannoteerd te zijn. Daarvoor bestaan dus, ook in het Nederlands, wel erg grote datasets, o.a. Wikipedia dumps of Common Crawl. Ook gebeurt er onderzoek naar few-shot learning, waarvoor slechts enkele geannoteerde voorbeelden voldoende zouden zijn, maar er is nog volop debat over wanneer en onder welke voorwaarden dat wel of niet kan werken.

Ondertussen zijn de bestaande taalmodellen zeker niet nutteloos: we kunnen ze gemakkelijk tweaken voor onze eigen toepassingen.

Een taalmodel verbeteren

Wat kunnen we vandaag al doen om fouten te reduceren? Gelukkig is SpaCy als library modulair opgezet en iedere component van de tekstverwerkingspijplijn is naar believen aan te passen. We zagen dat het Engelse billion wel als getal werd gezien, maar het Nederlandse miljard niet.

Laat ons eerst kijken naar de taalspecifieke uitzonderingen die SpaCy definieert. Daarin zien we dat in de lexicale attributen het woord miljard wel degelijk als getal wordt aangemerkt, net zoals in het Engels. Alleen samengestelde getallen (“drieëntwintig”) worden op moment van schrijven nog niet zo geannoteerd in het Nederlands – hiermee hebben we al direct een eerste plek gevonden waar ruimte voor verbetering is qua analyse van het Nederlands in SpaCy!

De woordsoorten worden toegekend door een Morphologizer in de pijplijn, dit is een component die getraind is en waarvan de uitkomst dus afhangt van de trainingsdata. En inderdaad , als we de inhoud van UD_Dutch-LassySmall en UD_Dutch-Alpino erop nalezen, zijn woorden zoals miljoen en miljard er enkele keren in terug te vinden, consistent geannoteerd als NOUN.

Je kan desgewenst een eigen versie van de trainingsdata maken waarin dat anders is en proberen een geheel nieuwe Morphologizer component te trainen. Voor een kleine aanpassing zoals dit is een elegant alternatief ook om een op maat gemaakte component toe te voegen aan de pijplijn, die de automatische annotatie door zo’n standaard taalmodel aanpast of aanvult waar nodig of gewenst. In dit geval kunnen we een zelfgeschreven AttributeRuler invoegen achter de Morphologizer, die de woordsoort aanpast van NOUN naar NUM voor NOUNs waarbij “token.like_num == True“:

ruler = nlp.add_pipe("attribute_ruler", name="fix_num", after="morphologizer")
detect = [[{"POS": "NOUN", "LIKE_NUM": True}]]  
assign = {"POS": "NUM"}  
ruler.add(patterns=detect, attrs=assign)

NER updaten

De Named Entity Recognition component, die het nodig vond om Apple een persoon te noemen, is ook een aparte component in de pijplijn die we kunnen aan- of uitschakelen, bijtrainen of desgewenst in zijn geheel vervangen. Het is niet mogelijk om een lijstje van patronen te maken waarmee alle mogelijke bedrijfsnamen herkend zouden kunnen worden, dus trainen op voorbeelden is hier onvermijdelijk. De NER-component kan hier blijkbaar enkele voorbeeldzinnen over bedrijfsacquisities gebruiken, om te leren dat niet enkel personen iets kunnen kopen.

SpaCy heeft sinds kort een hele projectarchitectuur uitgebracht die het beheer en het uitvoeren van trainingsprojecten voor taalmodellen sterk vereenvoudigt. We hoeven maar een van de templateprojecten te klonen en aan te passen aan onze noden:

python -m spacy project clone pipelines/ner_demo_update

Dit commando downloadt een kant-en-klaar project dat out-of-the-box werkt. In het bestand project.yml maken we de nodige aanpassingen aan de configuratie: de taal en het basismodel wijzigen naar het Nederlands, eventueel kan ook de GPU ingeschakeld worden, etc. Het project.yml bestand werkt zoals een Makefile: het definieert verschillende commando’s voor de voorbereiding van het data, het samenstellen van de trainingsconfiguratie, het uitvoeren van de training, het exporteren en packagen van het resulterende model en het schoonmaken van de bestandsstructuur. Je kan daar zelf naar believen onderdelen aan toevoegen. Er zijn ook mogelijkheden om het resultaat te visualiseren of via een API te publiceren, middels integraties met libraries zoals streamlit, FastAPI, weights&biases en ray.

Dan moeten we enkel nog trainingsdata in de map assets zetten. Er zijn allerlei tools beschikbaar om tekst of andere data te annoteren: die van UD zelf, LabelBox, Doccano, … maar buiten SpaCy’s eigen Prodigy bieden weinigen directe ondersteuning voor SpaCy. Het kan nog nodig zijn om een eigen script te maken om data te converteren naar een ondersteund formaat, en dat is met een extra lijntje code in project.yml snel ingevoegd. Gelukkig is het formaat gebruikt in het demoproject relatief eenvoudig en kunnen we snel manueel een JSON-file schrijven. We nemen bijvoorbeeld enkele titels van recente artikels op Tweakers.net:

[
["OnePlus 9 Pro met nieuwe Sony-sensor verschijnt eind maart voor 899 euro.", {"entities":[[0,7,"ORG"],[25,29,"ORG"],[64,72,"MONEY"]]}],
["Gerucht: Discord voert gesprekken met Microsoft over mogelijke overname.",{"entities":[[9,16,"ORG"],[38,47,"ORG"]]}],
...
]

Om te illustreren dat de context bepalend is om een woord als een bepaalde entiteit te markeren, vermeldt geen enkele van de voorbeeldzinnen die we gebruikten Apple. Eens alle onderdelen van het project zijn gedefinieerd, is de trainingsupdate met één commando uit te voeren en het resultaat al even snel te visualiseren:

spacy project run all
spacy project run visualize-model

Dit geeft dus een gemengd beeld. Het goede nieuws is dat Apple nu wel wordt herkend als een bedrijf. Het systeem lijkt ook extra aandacht te hebben voor cijfers gevolgd door woorden, die in commerciële context wel eens een geldbedrag zouden kunnen zijn. Maar plots worden ook mensen en nationaliteiten aanzien als organisaties – en dat was vroeger niet zo. Wat is hier gebeurd?

Het fenomeen staat bekend als Catastrophic Forgetting: in de ijver om de herkenning van een bepaalde categorie van entiteiten te verfijnen, zijn de andere entiteiten in het model bij het bijtrainen veel te ver naar de achtergrond gedrukt. De standaard oplossing hiervoor is om er voor te zorgen dat genoeg voorbeelden zijn toegevoegd in de trainingsdata die ook nog over al die andere entiteiten gaan, zodat je bijtraint met een gezonde mix aan voorbeelden die alle gevraagde entiteiten bevat. Het blijft dus belangrijk dat trainingsdata, ook als het enkel om een update gaat, goed gebalanceerd blijft.

Custom NER

Naast het updaten van een NER component kan je hem ook integraal vervangen door een andere die je zelf traint. Misschien vindt je de 17 entiteiten aangeboden in de huidige trainingsdata overkill, en heb je genoeg aan wat bijvoorbeeld het Duitse taalmodel biedt: Person, Organisation, Location en Miscellaneous, zoals gedefinieerd in de WikiNER dataset, en die ook beschikbaar is voor het Nederlands en het Frans.

Dan doe je exact hetzelfde als voordien, maar, je haalt de mosterd bij het kant-en-klare SpaCy WikiNER project dat je ook eenvoudig kan klonen:

python -m spacy project clone pipelines/ner_wikiner 

Dan is het een kwestie van de trainingsdata van WikiNER te downloaden en te converteren naar het juiste inputformaat. Die datavoorbereiding is waarschijnlijk nog het meeste werk. Eens het model getraind en bewaard is, kan je de NER component ervan eenvoudig inpluggen in een andere analysepijplijn, op dezelfde manier als we al eerder een stukje hadden toegevoegd aan de Morphologizer.

Het wordt vooral interessant als we zelf nieuwe categorieën van entiteiten gaan definiëren. Er is immers geen reden om ons te beperken tot dat wat voorzien is in een of andere dataset. Voor e-health toepassingen kan het zeer nuttig zijn om ziektes, behandelingen en medicijnen in een tekst als dusdanig te markeren. In biomedische tekst kan het gaan over namen van genen of proteïnen. En in juridische tekst is de herkenning van wetsartikelen ongetwijfeld ook nuttig.

Zolang je er trainingsdata voor kan aanmaken, en je zorgt dat er een goede balans is tussen alle entiteiten die je wil herkennen, is het allemaal mogelijk. Met wetsartikelen hadden we dat bij Smals Research al eens uitgeprobeerd, met het oog op entity linking – in dit geval, linken naar de eigenlijke wettekst via de ELI:

Het aanhouden van de projectstructuur van SpaCy, met een workflow definitie in project.yml en een trainingsconfiguratie in config.cfg , maakt dit alles veel gemakkelijker te beheren. We staan bij Smals Research dan ook graag open om verdere experimenten te doen met Named Entity Recognition. We kunnen snel een proof-of-concept aanleveren aan iedereen die een geannoteerde trainingsdataset heeft liggen.

Conclusie

Er is vandaag nog wat achterstand wat betreft Nederlandstalige NLP, maar het veld verandert zeer snel. Het ontbreken van grote trainingsdatasets zet een rem op de performantie. Maar met de opkomst van transfomer modellen, ook in het Nederlands, kunnen we in de nabije toekomst zeker verbetering verwachten.

Ondertussen zijn de bestaande taalmodellen misschien niet perfect, maar zeker niet slecht. Ze zijn bovendien erg gemakkelijk om te tweaken en te optimaliseren voor eigen toepassingen. Wie vandaag al begint met computationele analyse van taal, zal dus gemakkelijk kunnen meesurfen met de opeenvolgende verbeteringen die we de komende maanden en jaren zeker zullen zien.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Classificatie is hét typevoorbeeld van machine learning, en bij uitbreiding artificiële intelligentie. Het algemene probleem is als volgt: gegeven een bepaalde input (onze gegevens), welke output (een label) hoort daarbij? Die output geeft dan weer of de input tot een of meerdere categorieën behoort: bvb. de bloedtypes “A”, “B”, “AB”, “O”, of nog simpeler: “ja”, “nee”. Een classifier (*) is een algoritme dat we kunnen trainen om deze vraag te beantwoorden. Die training vereist dat we het algoritme voeden met hopen voorbeelden: een dataset van input-output-paren die we al ter beschikking hebben.

Bij NLP bestaat onze input uit tekst. Tekst bestaat uit zinnen, zinnen uit woorden, woorden uit letters, en op elk van die niveau’s kunnen we classifiers trainen en toepassen. Omwille van de grote woordenschat en variabiliteit in vele talen (denk aan alle vervoegingen en verbuigingen) moet een trainingsdataset voor NLP-classifiers vaak enorm groot zijn. Bovendien kan je een classifier getraind op één taal niet zomaar toepassen op een andere: daarvoor moet de classifier meestal volledig opnieuw getraind worden met een dataset uit die andere taal.

Een courante tekstclassifier die we allemaal dagelijks gebruiken is de spamfilter: gegeven een email, beslist die of het spam is, ja of nee. In dit artikel wil ik echter focussen op een fijnmaziger niveau: de classificatie van een woord, of een kleine woordgroep, binnen eenzelfde zin.

(*) Er bestaat een brede waaier aan algoritmes voor classificatie, waaronder decision trees, support vector machines, probabilistische modellen, graaf-gebaseerde modellen en neurale netwerken in allerlei geuren en kleuren. Ze zijn in principe allemaal inzetbaar voor de NLP-problemen beschreven in dit artikel; “classifier” mag in deze tekst dus breed geïnterpreteerd worden.

Grammatica

In de context van parsing (zinsontleding) willen we bijvoorbeeld achterhalen tot welke woordsoort een woord behoort. Dit probleem staat bekend als Part-of-Speech (POS) tagging. Naamwoorden worden in veel talen verbogen, en werkwoorden vervoegd. Ter vereenvoudiging wordt daarom vaak eerst een vorm van stemming of lemmatisering toegepast, waarbij men ieder woord eerst terug brengt tot zijn stam.

Dan nog is er ambiguïteit mogelijk. Neem het woord “werken” in de volgende voorbeelden:

• De 12 werken van Hercules
• Er zijn ook onderzoekers die werken bij Smals

Dit illustreert de noodzaak om met context rekening te houden. Net daar komt machine learning van pas: we hebben een systeem nodig dat bepaalt dat het in de eerste zin het gaat om een zelfstandig naamwoord, en in de tweede zin om een werkwoord.

Een classifier die dat moet bepalen zal je daarom trainen met voorbeelden waarin ook enkele woorden rondom worden meegenomen (zogenoemde n-grams). Neem bijvoorbeeld 2 woorden voordien en 1 woord nadien als context:

• “De 12 werken van” → werken = zelfst. nw.
• “onderzoekers die werken bij” → werken = werkwoord

Een geschikte classifier die zo voldoende wordt getraind, zal ook van onbekende woorden de meest waarschijnlijke woordsoort kunnen afleiden. Dit is handig omdat we dan in zekere mate kunnen omgaan met neologismen of nieuwe woordenschat:

• “Hij schreef 7 ghjkl in zijn leven” → ghjkl = zelfstandig naamwoord

Disambiguatie

Ook binnen eenzelfde woordsoort kan een woord verschillende betekenissen hebben, dit zijn de homoniemen. Voor ons is het evident dat als een “muis” knoppen heeft om op te drukken, je waarschijnlijk spreekt over de computermuis en niet over de veldmuis. Een computer moet eerst getraind worden om de juiste betekenis te selecteren. Dit vraagt om een classifier die je traint op een hoop zinnen waarin het woord “muis” voorkomt, in de hoop dat de classifier aanleert in welke context “muis” verwijst naar de computermuis en in welke context niet.

In de computationele linguïstiek heet dit Word Sense Disambiguation, een klassiek probleem waarvoor dan ook grote datasets bestaan voor training en evaluatie van algoritmes. Een basisdataset is het Engelstalige WordNet. Het Europees project BabelNet breidt dat uit tot een honderdtal andere talen via Wikipedia-crosslinks, terwijl Open MultiLingual Wordnet een lijst bevat van andere datasets gelinkt aan WordNet.

Data genoeg, zo lijkt het, maar dat maakt het niet noodzakelijk gemakkelijk om goede resultaten te krijgen. Zelfs de beste algoritmes halen momenteel een F1-score (een maat voor accuraatheid) die maar weinig hoger ligt dan die van de eenvoudigste strategie: “kies altijd de meest voorkomende betekenis”. Volgens de laatste resultaten presteren neurale netwerken en traditionelere classifiers daarbij op ongeveer hetzelfde niveau, en doen deze classificatiegebaseerde systemen het net iets beter dan rule-based systemen.

Het spreekt vanzelf dat grammaticale en semantische disambiguatie allebei erg nuttig zijn voor automatische vertaling, waar ik in een vorige blogpost al kort over schreef.

Named Entity Recognition

In een tekst vind je al snel referenties terug naar mensen, bedrijven, plaatsnamen, bedragen, tijdstippen, kunstwerken, etc. Vaak gaat het om eigennamen of jargon: woorden die je niet zomaar in het woordenboek terugvindt. Dit noemen we entiteiten, en een vaak voorkomende vraag is: kunnen we deze automatisch herkennen en markeren in een tekst?

Het probleem staat bekend als Named Entity Recognition (NER), en je kan dat aanpakken op verschillende manieren:

• Als je je kan beperken tot een overzichtelijke eindige lijst: gewoon kijken of een woord in dat lijstje voorkomt. Handig voor o.a. plaatsnamen of de namen van de maanden.
• Als de term een gestructureerde vorm heeft, kan je werken met een reguliere expressie. Nuttig voor datums in een vaste vorm, identificatienummers, telefoonnummers, emailadressen of URLs.
• Als een entiteit beschreven kan worden op teveel manieren om op te sommen, kan je die met een getrainde classifier proberen te herkennen. Deze aanpak wordt vaak gehanteerd voor het herkennen van persoonsnamen en organisaties, of wanneer een tekst veel spelfouten kan bevatten.

Ter illustratie, het volgende experiment: in een gescand juridisch document (een vonnis, een arrest, een brief van een advocaat), waaruit de tekst werd geëxtraheerd met behulp van Optical Character Recognition (OCR), willen we alle verwijzingen naar wetteksten markeren. Dit is nuttig om bijvoorbeeld de binnenkomende post onmiddellijk intern te kunnen doorsturen naar de jurist die gespecialiseerd is de wet waarvan sprake, of om de tekst te verrijken met links naar andere informatiebronnen over die wet (Entity Linking), wat een hoop manueel opzoekwerk kan besparen.

Een referentie naar een wettekst kan op veel manieren verwoord worden:

• Wet ter bescherming van persoonsgegevens,
• Wet ter bescherming van de persoonlijke levenssfeer ten opzichte van de verwerking van persoonsgegevens,
• Wet van 8 december 1992,
• Belgische Privacywet,
• … 

Al deze referenties zouden we op een of andere manier willen herkennen. We doen dat door trainingsvoorbeelden te geven aan een classifier die antwoord geeft op de vraag: is dit woord onderdeel van een wetsverwijzing, ja of nee? De trainingsdata neemt de vorm aan van individuele zinnen waarin een wetsverwijzing voorkomt, en de beginpositie en eindpositie van die wetsverwijzing. In de volgende frase markeerden we een verwijzing naar een wetsartikel van letter 26 tot letter 65:

• terwijl overeenkomstig de artikelen 87 tot 94 Wet Strafuitvoering een gevangenisstraf kan worden omgezet in een werkstraf

Zonder hier dieper in te gaan op de details, zal een NER-classifier proberen om in een nieuwe tekst de beginposities en eindposities van alle entiteiten terug te vinden. Een geschikte classifier zal daarbij rekening moeten kunnen houden met de context, of misschien gebruik maken van systemen zoals attention, die kunnen zorgen voor een consistentere output.

In onderstaand voorbeeld proberen we ook met machine learning te detecteren welke woorden plaatsnamen en organisaties zijn. Dit omdat de input afkomstig is van een beeldscanner met OCR, waarvan het resultaat inherent spelfouten bevat. Na een minimale training is een eerste resultaat:

Hieruit blijkt alvast:

• De spelfouten en splitsingstekens in de input maken het moeilijker voor NER. In plaats van “Ar-beidsrechtbank” als organisatie te markeren, wordt “Ar-” als apart woord aanzien, dat de computer blijkbaar eerder doet denken aan een wetsverwijzing – vermoedelijk omdat het begint met dezelfde letters als “artikel”.
• Dat “Mechelen” soms als organisatie wordt aangeduid, is vermoedelijk omdat in de trainingsdata soms een plaatsnaam voorkomt in de naam van een organisatie. Dat zal iedere classifier in de war brengen. (Hetzelfde probleem doet zich voor bij het onderscheid tussen persoonsnamen en bedrijfsnamen: nogal wat bedrijfsnamen bevatten een persoonsnaam.)

Met extra trainingsvoorbeelden kan dat uiteindelijk geremedieerd worden, maar duiken er elders misschien nieuwe problemen op. Helaas vergt het samenstellen van een trainingsdataset voor gespecialiseerde toepassingen zoals deze, nog altijd veel manueel werk. Crowdsourcing kan daarvoor eventueel een oplossing bieden. En dan nog is het onbegonnen werk om alle mogelijke variaties en nuances te vatten, zodus zal er altijd met een zekere foutenmarge rekening gehouden moeten worden.

Met de entiteiten die wél goed gedetecteerd worden, kunnen we alvast aan de slag. Een link naar een andere toepassing met nuttige info over die wettekst is snel gelegd: bijvoorbeeld naar de integrale gepubliceerde wetteksten, die in Europa sinds kort online beschikbaar worden gesteld via een gestandaardiseerd systeem, de European Legislation Identifier (ELI).

Dit werd als proof-of-concept uitgewerkt op de NLP4Gov Hackathon georganiseerd door Informatie Vlaanderen in 2018. Daar ging een team van startup TheMatchbox aan de slag met een dataset die Smals Research voorstelde samen met RSZ-ONSS en IGO-IFJ, op basis van de gepubliceerde arresten van het Hof van Cassatie. Om af te sluiten, hun filmpje dat het eindresultaat presenteert:

Taal is echter meer dan spraak alleen. Ook geschreven tekst valt onder de noemer “Natural Language”: krantenartikels, boeken en tijdschriften, blogs en Wikipedia-pagina’s, … Er worden bergen onderzoek verzet naar het extraheren van nuttige informatie uit al deze bronnen, of het automatisch proberen begrijpen van de inhoud ervan. Voortgestuwd door de recente vooruitgang in artificiële intelligentie, zien we ook veel beweging in deze tekstuele subdomeinen van NLP. In deze eerste blogpost over NLP houden we de vinger aan de pols van enkele belangrijke facetten ervan: parsing en automatische vertaling.

Parsing

Parsing is zinsontleding voor computers. Daarbij wordt geprobeerd aan ieder woord of zinsdeel een label toe te kennen (is het een bijwoord, naamwoord, werkwoord, bijzin, …), en zo mogelijk ook de grammaticale structuur af te leiden.

In de meest eenvoudige vorm worden woorden individueel gelabeld (“Part of Speech tagging“). Op relatief “schone” tekst, zoals uit kranten, worden ondertussen accuraatheden van bijna 98% gehaald op de belangrijkste Engelstalige en bijna 97% op de belangrijkste meertalige datasets. Op een hoger niveau kan men ook zinsdelen proberen herkennen – wat men “shallow parsing” of “chunking” noemt.

Aan de basis van automatisch vertalen (Google/Bing Translate, …) liggen meestal constituency grammars, waarmee gemakkelijker overkoepelende grammaticale structuren voorgesteld worden. Met traditionele methodes zijn er echter nog talloze kleine regeltjes nodig om correct met woordvolgorde of de nodige tussenvoegsels om te gaan. Door de boomstructuur voor te stellen als een rij van karakters en er zogenaamde sequence-to-sequence methodes op los te laten, bleek men ook die speciale regeltjes automatisch te kunnen aanleren. Met zulke deep learning methodes wordt nog regelmatig vooruitgang geboekt op het vlak van parsing.

Correct parsen is een voorwaarde om daaropvolgende analyses, zoals een vertaling of een automatische annotatie, ook correct te kunnen uitvoeren. Er komen echter nogal wat moeilijkheden kijken bij natuurlijke taal, waaronder:

• Verschillende verbuigingen of vervoegingen van hetzelfde woord moeten herkend worden als variaties van datzelfde woord (door stemming of lemmatization).
• Vaste uitdrukkingen en idiomen worden misschien best niet letterlijk geïnterpreteerd.
• Interpunctie maakt een wereld van verschil.

Dat alles is bovendien verschillend voor iedere taal. Alleen al aan die problemen zijn hele subdomeinen van NLP gewijd. Bovendien kan natuurlijke taal ook erg ambigu of dubbelzinnig zijn. Zonder nu dieper in te gaan op al deze moeilijkheden (dat doe ik misschien in een volgend artikel), enkele voorbeeldjes van dat laatste:

• Op grammaticaal vlak is de functie van een woord niet altijd eenduidig. Voorbeeld uit de laatste link: “De man slaat de hond met de stok” – wie heeft hier de stok vast? Ook in “De jongen die Marc geslagen heeft” is niet duidelijk wat nu het onderwerp of het lijdend voorwerp is.
• Op semantisch vlak kan een woord meerdere betekenissen hebben. In dat geval is er meestal context nodig om te weten over welke betekenis het gaat. Is die context er niet of onvoldoende, dan slaan ook de beste automatische vertaalmachines de bal mis.

Automatisch (v|h)ertalen

Het gebruik van deep learning in vertaling wordt vaak Neural Machine Translation genoemd. Omdat daarmee correctere woordkeuzes en woordvolgordes bekomen worden, en omdat zo enigszins (maar zeker niet perfect) ook met context rekening wordt gehouden, is Google eind 2016 begonnen met de uitrol ervan in Translate, en ook de meeste andere online vertaaldiensten zijn ondertussen hierop gebaseerd.

Het evalueren van automatisch vertalen blijft echter moeilijk. De meest gebruikte metriek voor automatisch vertalen, BLEU, probeert te meten hoe een professional de vertaling zou beoordelen. Er is echter van bekend dat de manier van meten toch enkele tendensen vertoont (bvb het bevoordelen van kortere vertalingen).  Qua datasets om zulke systemen te trainen en testen zijn er o.a. erg veel meertalige gegevens van het Europees Parlement, die echter logischerwijs enkel westerse talen bevatten. Er is dus nog zeker werk aan de winkel wat betreft inclusie van niet-westerse en zeldzamere talen. Ondertussen leiden die lacunes soms tot bevreemdende effecten in online vertaaltools.

Vertaling hoeft niet alleen van een gesproken taal naar een andere gesproken taal te gaan. We kunnen even goed “hertalen”: de vraag in natuurlijke taal omzetten naar een query die op een database uitgevoerd kan worden, of naar een andere formele structuur zoals computercode. Deze vorm van NLP, Semantic Parsing, wordt o.a. gebruikt door Google Assistant of Amazon Alexa om vragen in natuurlijke taal te beantwoorden (genre “Wie is de president van de VS?”). Om dat op grote schaal te trainen en testen bestaan verschillende datasets die beschrijvingen van een query in natuurlijke taal linken aan de query zelf. (WikiSQL, ATIS vliegverkeer, etc). Voor specifieke toepassingen of niet-courante talen heb je vaak geen andere keuze dan het zelf opbouwen van een eigen database, die sowieso erg groot moet zijn. Crowdsourcing kan voor dat laatste eventueel een oplossing bieden.

Van daar is de stap snel gezet naar het beantwoorden van (algemene) vragen. Hiermee gooide IBM hoge ogen toen hun Watson systeem het spel Jeopardy won. Het probleem lijkt een beetje op een “examen begrijpend lezen”: gegeven een document of stukje tekst, wordt een bepaalde vraag gesteld waarvan het antwoord teruggevonden moet worden (al dan niet letterlijk) in de tekst. Daarvoor wordt de computer voorzien van de inhoud van, bijvoorbeeld, Wikipedia. Op basis van een training met vragen en de correcte antwoorden daarop, tracht men de computer zelf te doen afleiden hoe het het antwoord van een vraag moet opzoeken in de beschikbare dataset. Ook voor de training hiervan bestaan grote datasets, met bvb vragen over nieuwsartikels, crowdsourced op basis van Wikipedia, of van eindexamens Engels in China.

De data definieert het systeem

Eens we op dit niveau van NLP aankomen, zijn we erg afhankelijk van de datasets waarop het systeem wordt getraind. Kunnen we een systeem dat is getraind op tekst uit Wikipedia, inzetten om documenten met een heel andere inhoud te verwerken – van straattaal tot juridisch jargon (i.e. domein-adaptatie)? Deze uitdaging van de generaliseerbaarheid van systemen die getraind zijn op gelimiteerde of biased datasets, vinden we terug in zo goed als elke AI-applicatie. We willen vermijden dat een AI-systeem bepaalde biases (“vooroordelen”) aanleert of bestendigt. Daar zijn veel voorbeelden van bekend, en dat dat voor problemen zorgt, lichtte ik al toe in een vorige blogpost. Ook recent nog verschenen berichten over een CV-screening systeem dat de mist in ging op dat vlak. Dit blijft dus om permanente waakzaamheid vragen.