Bachelor Informatica
Politieke zoekmachine voor
han-delingen van de Tweede
Ka-mer
Lennart Kerkvliet
20 januari 2020
Supervisor(s): dhr. dr. M.J. MarxInf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Samenvatting
Nieuwe technieken op het gebied van Natural Language Processing, maken het mogelijk om het doorzoeken van documenten makkelijker te maken voor gebruikers. Deze scriptie werkt voort op het werk van het Political Mashup project om een zoekmachine te bouwen voor het doorzoeken van handelingen van de Tweede Kamer. Hierbij maken we gebruik van taalanalyse, met het doel om het zoeken makkelijker en uitgebreider te maken voor de eindgebruiker. Hiervoor trainen we een model met het taalpakket SpaCy om de entiteiten in de handelingen correct te kunnen herkennen. Met deze herkende entiteiten kunnen we zoekresultaten uitbreiden door direct in de zoekresultaten de entiteiten te visualiseren, of met het weergeven van woordenwolken gebaseerd op een specifieke entiteitcategorie, zoals personen of organisaties.
Inhoudsopgave
1 Introductie 7
1.1 Onderzoeksvraag . . . 8
2 Theoretische achtergrond 9 2.1 Natural Language Processing . . . 9
2.1.1 Pipeline . . . 9 2.1.2 Training . . . 10 2.2 Scores . . . 11 3 Omgeving 13 3.1 Data . . . 13 3.2 Entiteiten . . . 14 3.2.1 Personen . . . 14 3.2.2 Monetaire eenheden . . . 15 3.2.3 Organisaties . . . 15 4 Methode 17 4.1 Architectuur . . . 17 4.1.1 Elasticsearch . . . 17 4.1.2 Backend . . . 17 4.1.3 Frontend . . . 18 4.2 Documenten . . . 18 4.3 Entiteiten herkennen . . . 18 4.3.1 Ons model . . . 20 4.4 Gebruikersinterface . . . 21 4.4.1 Design . . . 21 4.4.2 Informatie visualisatie . . . 22 4.4.3 Evaluatie . . . 23 4.5 Woordenwolken . . . 24 5 Resultaten 25 5.1 Experiment 1 . . . 25 5.2 Experiment 2 . . . 26 5.3 Experiment 3 . . . 28 5.4 Voorbeelden . . . 29 6 Conclusie 31 6.1 Onderzoeksvraag . . . 31
6.2 Named-entity recognition trainen . . . 31
6.3 Gebruikersinterface . . . 32
6.4 Onderzoeksvraag . . . 32
6.4.1 Vervolgonderzoek . . . 32
A Vragenlijst 39
A.1 Opstelling . . . 39
A.2 Vragen . . . 40
A.2.1 Algemeen . . . 40
HOOFDSTUK 1
Introductie
Voor onderzoek van bijvoorbeeld politicologen of journalisten is het van belang dat informatie uit overheidsinstanties volledig beschikbaar is en daarnaast makkelijk te vinden. Voor transparantie stellen instanties zoals de Tweede Kamer daarom al heel lang alle notulen beschikbaar. De notulen van de vergaderingen worden ook wel handelingen genoemd. Deze handelingen zijn volledig beschikbaar op de site van de Tweede Kamer 1 in de vorm van kamerstukken en op
de website Officiele Bekendmakingen 2, een site met alle offici¨ele publicaties van de overheid
inclusief historische parlementaire documenten.
Deze documenten zijn echter ongestructureerd en de inhoud is vaak niet ge¨ındexeerd, het is dus moeilijk om hier iets te vinden. Projecten zoals Political Mashup en OpenKamer hebben gepoogd om deze documenten toegankelijker te maken. In het Political Mashup project zijn de handelingen die beschikbaar zijn in verschillende formaten zoals PDF’s en Microsoft Word omgezet naar XML om deze te kunnen doorzoeken [8]. Dit is inclusief alle ingescande historische parlementaire documenten. Al deze documenten zijn beschikbaar op de site3 van het project.
Sinds dit project zijn er nieuwe ontwikkelingen. De Tweede Kamer heeft recentelijk een API vrijgegeven waarin naast de handelingen en ook informatie over kamerleden en partijen vanaf het jaar 2013 op te vragen zijn. Gecombineerd met nieuwe technieken in het gebied van tekstanalyse en zoekmachines kunnen we het doorzoeken van deze documenten niet alleen beter automatiseren, maar ook slimmer maken door gebruik te maken van semi supervised learning voor betere modellen aangepast op deze dataset [2].
De tool ontwikkeld in dit onderzoek heeft als doel om gebruikt te worden door een team aan de Radboud Universiteit Nijmegen geleid door dr. Harm Kaal voor een onderzoek naar de rol van de Tweede Kamer in de digitalisering van de overheid.
1Tweede Kamer: https://www.tweedekamer.nl/kamerstukken/ 2Officiele Bekendmakingen: https://www.officielebekendmakingen.nl 3Political Mashup: https://www.politicalmashup.nl
1.1
Onderzoeksvraag
Het doel van dit onderzoek is om een zoekmachine te ontwerpen die voortborduurt op vorig werk, waaronder het gebruik van de ingelezen documenten. Met nieuwe technieken kunnen we de betekenis van de tekst analyseren. Met de extra informatie verkregen uit de tekst zouden we dan het zoeken makkelijker kunnen maken voor een gebruiker. Daarom luidt de onderzoeksvraag:
In hoeverre kan het annoteren van entiteiten in de handelingen van de Tweede Kamer het zoeken vergemakkelijken?
Deze vraag is vervolgens onderverdeeld in twee deelvragen:
(a) Hoe kunnen we named-entity recognition trainen om beter te werken op personen, organi-saties en monetaire eenheden uit handelingen van de Tweede Kamer?
HOOFDSTUK 2
Theoretische achtergrond
2.1
Natural Language Processing
Natural Language Processing (ook wel NLP ) is een veld binnen de Informatica die zich bezig-houdt met de interacties binnen taal. NLP bestaat uit verschillende deelgebieden die ook weer van elkaar afhankelijk kunnen zijn. Samen noemen wij dit de pipeline.
2.1.1
Pipeline
Tokenization
Ook wel Lexicale analyse, is de eerste stap in NLP. Aan een zin op zichzelf staand heb je niet zo veel. Voordat we tags toe kunnen voegen aan een zin moeten we deze opdelen in stukken. Deze stukken noemen we tokens. Een werkwoord of een persoonlijk voornaamwoord is bijvoorbeeld zo’n token. Hoe dat er uit komt te zien kan heel erg verschillen per taal. In het Engels en Nederlands komen vaak compound tokens voor; een token waar twee woorden met verschillende betekenissen aan elkaar vast zitten [16]. Denk aan aren’t in het engels of aanspraakelijkheids-verzekering in het Nederlands. Wat een token precies inhoudt moet van tevoren duidelijk zijn voordat de zin opgedeeld wordt. Is het bijvoorbeeld van belang in de volgende stap dat een zelfstandig naamwoord ´e´en token is, of juist niet?
Het eerste stadium van de analyse wordt vaak gedaan door een simpele Finite State Machine, de Scanner. Leestekens zoals spaties en komma’s moeten bijvoorbeeld gescheiden worden van woorden, en zo kan er ook onderscheid worden gemaakt tussen zinnen. Een evaluator controleert vervolgens de token en geeft deze een waarde.
Part-of-speech
Part of Speech tagging (ook wel PoS-tagging) is het taggen van de grammaticale waarde van een token. Het gaat dus over woorden onderscheiden van op basis van hun plek in de zin. Woorden kunnen namelijk verschillende betekenissen hebben in een andere context. Denk aan Google. Als we het hebben over
“ik google het wel even”
dan is google hier een werkwoord. Google heeft alleen meerdere betekenissen. Als je zou zeggen:
“Google heeft recentelijk een winst gemaakt van 5 miljard”
dan hebben we het over Google als bedrijf, dus als zelfstandig naamwoord. Maar in een zin zoals
is Google geen bedrijf, maar juist weer deel van een productnaam. Google Maps is hier samen dan een zelfstandig naamwoord. Dit zou de tokenizer dus ook weer moeten zien als ´e´en token. Named-entity recognition
Named-entity recognition (ook wel NER) is het herkennen van de entiteit van een token. De entiteiten worden gecategoriseerd. Google zou bijvoorbeeld ingedeeld kunnen worden als organi-satie. Niet alle tokens zijn entiteiten, werkwoorden bijvoorbeeld niet. Entiteiten zijn bijvoorbeeld locaties, tijdstippen, organisaties of personen.
Zoals eerder aangegeven kan een woord verschillende betekenissen hebben op basis van de plaats in de zin. De NER maakt daarom op zinsniveau gebruik van bijvoorbeeld Part-of-speech tagging [12]. Samen met features op woordniveau zoals hoofdletters of het gebruik van cijfers kan bepaald worden of en met welke entiteit we te maken hebben.
2.1.2
Training
Een algoritme die zo’n onderdeel van de NLP pipeline kan uitvoeren kan op meerdere manieren worden gedaan, zoals met rule-based systemen of door middel van een training. Je kunt bij een training een model als het ware “leren” om een taak van de pipeline uit te voeren. Je kunt er dan voor kiezen om gebruik te maken van een bestaand model, of om er zelf een te genereren. Supervised learning
Algoritmes zoals Logistic Regression, Support Vector Machines (SVM) of Neurale Netwerken leren onder toezicht (Engels supervised ). Dit houdt in dat alle data die gevoed wordt aan het algoritme wordt gelabeld door een persoon. Deze data noemen we de training set. Met gradient decent kan een model worden geoptimaliseerd, door de loss functie te minimaliseren [10]. Dit proces wordt ook wel backpropagation genoemd.
Semi-supervised learning
Het probleem bij bestaande modellen is dat deze vaak ontwikkeld zijn met een bron die niet aansluit bij het onderzoek. Er wordt bijvoorbeeld gebruik gemaakt van nieuwsartikelen, vaak omdat deze makkelijk in grote getallen te vinden zijn op het internet. Wil je dan zelf een model genereren dan moet je voldoende data hebben. Zeker als je dit supervised wilt hebben gaat daar enorm veel werk in zitten. Google is daarom begonnen aan het onderzoekproject BERT, wat staat voor Bidirectional Encoder Representations from Transformers [5].
Figuur 2.1: BERT architectuur
In dit framework maak je gebruik van pre-training, oftewel een bestaand model die al getraind is op een grote dataset voor een specifieke taal. Dit gebeurt unsupervised. Dit model kan ver-volgens supervised doorgetraind worden door een eindgebruiker om gebruikt te worden voor een
specifiek doel, zoals het ophalen van entiteiten uit e-mail of bijvoorbeeld productomschrijvingen. Dit noemen we Fine-tuning
In de pre-training fase wordt het model unsupervised op specifieke taal getraind met een enorme dataset. Dit met als doel het model een algemeen “taalbegrip” aan te leren. Het model zou in deze stap al moeten leren dat een werkwoord bijvoorbeeld geen entiteit is, maar de verdere accuraatheid is relatief laag omdat de training set zo breed is.
Het is daarna aan de eindgebruiker om de parameters/features uit het unsupervised model aan te passen naar zijn specifieke doel. Dit kan de resultaten op kleinere datasets verbeteren, omdat het model een duidelijk concept heeft van de taal. Hierbij moet dan een dataset gebruikt worden die representatief is voor het gebruik. Een model getraind op Wikipedia waar er weinig tot geen gebruik gemaakt wordt van de eerste persoon zal waarschijnlijk niet goed werken op Twitter.
2.2
Scores
Om te kijken hoe goed een model is moet er een score opgebouwd worden. Natural Language Processing gebruikt hier over het algemeen de F-score voor [4], ook wel de F-measure of F1-score. Zo’n score kunnen we ook aan een model voor named-entity recognition geven. Elk woord kun je indelen in ´e´en van de 4 categorie¨en [6]: een correct herkend label op een token (T P , true-positive), een token die correct geen label heeft (T N , true-negative), een token die incorrect herkend is (F P , false-positive) en een token die incorrect geen label heeft (F N , false-negative). In het geval van NER zou het woord “Microsoft” waarschijnlijk het label organisatie moeten krijgen. Heeft deze het correcte label dan is dat een true-positive. Heeft het het geen label, dan is het een false-negative. Andersom geldt voor een woord zonder label, zoals een voorzetsel. Heeft dit een label dan is het een false-positive, heeft het geen label is het een true-negative. Precisie
De precisie (in het Engels Precision) is de verhouding tussen alle correcte gelabelde entiteiten (T P ) en incorrect herkende entiteiten, dus de false-positives (F P ).
P = |T P |
|T P + F P | (2.1)
Een entiteit kan echter bestaan uit meerdere tokens. We rekenen een entiteit dan pas aan als “correct” als er sprake is van een exacte match met ons antwoord. Een label die bijvoorbeeld afwijkt op slechts ´e´en token is dus ook al een volledige fout. Uit de resultaten kunnen we dus niet onderscheiden of een fout bijna goed was, of niet eens in de buurt.
Vangst
De vangst (in het Engels Recall ) is de verhouding tussen het aantal correcte gelabelde entiteiten (F P ) en het niet herkende entiteiten (F N ). De vangst laat in tegenstelling tot de precisie juist de false-negatives zien.
R = |T P |
|T P + F N | (2.2)
F-score
Zoals aangegeven kunnen we de F-score gebruiken om prestaties van een model te meten. Deze score is het harmonische gemiddelde van de precisie en de vangst van een model. Met deze score kan de algemene accuraatheid van een test worden bepaald. Een nadeel hiervan is is dat het de precisie en vangst evenveel betekenen in de score, terwijl in sommige use cases de een meer van belang zou kunnen zijn.
F1=
2 · (P · R)
HOOFDSTUK 3
Omgeving
3.1
Data
Voor het opvragen van alle politieke partijen, Tweede Kamer commissies en betrokken personen maken we gebruik van de OData API van de Tweede Kamer1.
Uit de OData API krijgen we niet alleen alle plenaire- en commissieverslagen (handelingen) in XML-formaat, maar ook de namen van alle personen, partijen en commissies in JSON of XML formaat (naar keuze).
Figuur 3.1: Datamodel OData API
Met deze data kunnen we precies zien wie op wat moment in welke fractie zat, in welke commissie en welke functie deze persoon bekleedde. Dit is van belang, want naast dat politici nog wel eens van functie en commissie wisselen, hebben ze ook nog wel eens de behoefte om zich af te splitsen en een nieuwe partij te beginnen of zich bij een andere partij te voegen.
3.2
Entiteiten
In ons onderzoek gebruiken we de teksten uit handelingen van de Tweede Kamer. In het algemeen zijn dit aparte soorten tekst, met unieke eigenschappen zoals
• bevatten vrijwel geen spelfouten (de gecorrigeerde documenten) • taalgebruik is consistent en netjes
• rijk aan locaties, organisaties en personen
Ons onderzoek legt vooral nadruk op het laatste van de drie, namelijk het herkennen van entiteiten in context. In de volgende secties wordt uitgelegd hoe deze entiteiten zijn gestructu-reerd, zodat we de juiste benadering kunnen kiezen en later beter kunnen verklaren waarom onze benadering wel of niet juist is geweest.
3.2.1
Personen
De Tweede Kamer bestaat al eeuwen en heeft daarom veel regels. Deze regels heten het Reglement van Orde. Een van de meest opvallende verschillen met normale conversaties is dat politici in de Kamer niet rechtstreeks met elkaar spreken, maar via de voorzitter. Het idee hierachter is dat een debat hier minder persoonlijk mee wordt en daardoor een meer gematigde toon aanneemt. Dit gebruik is overigens niet vastgelegd, maar een ongeschreven regel.
Dit zorgt er wel voor dat handelingen heel anders gestructureerd zijn dan normale Nederlandse teksten. Mensen spreken elkaar dus alleen aan in de tweede persoon. Dit doen ze over het algemeen in een vaste structuur, namelijk met achternaam, voorafgaand aan aanhef:
• de heer Baudet • meneer Baudet • de vrouw Dijkstra • mevrouw Dijkstra • collega Klaver
Waarin vrouwen in sommige gevallen achternaam + meisjesnaam bevat [11]. In oudere do-cumenten wordt er ook nog wel eens mijnheer gebruikt. Personen in belangrijke functies worden daarnaast vaak aangesproken met hun titels:
• de Voorzitter • de Premier
• de Minister (van Buitenlandse Zaken) • minister-president Rutte
• minister Grapperhaus
Vaak wordt dit ook nog eens geschreven met hoofdletters. De context is hier belangrijk, de Premier of de Minister van Buitenlandse Zaken is afhankelijk van de datum waarin het gesprek plaatsvindt. De voorzitter is ook weer verschillend per commissie, maar dit wordt dan ook weer aangegeven in het verslag.
3.2.2
Monetaire eenheden
SpaCy, het taalpakket dat we gebruiken, heeft uit zichzelf al een ingebouwde entiteit voor geld (Monetary Unit ). Dit gaat echter vaker fout dan goed. Om dit bruikbaar te maken moeten we ons model aanpassen om deze monetaire eenheden met enige redelijkheid te kunnen herkennen. Gelukkig voor ons is er binnen notulen van de Tweede Kamer enige consistentie in het be-schrijven van dit soort eenheden. Er zijn over het algemeen twee manieren om een bedrag te omschrijven. Het kan gaan over het euroteken gevolgd door een nummer, of over een getal gevolgd door euro, waar het getal ook uitgeschreven kan zijn.
• e1,72
• 90 (miljoen) euro(cent)
We hebben in de data vooral te maken met miljoen, miljard en soms (honderd)duizend, en over het algemeen eigenlijk alleen euro en soms de dollar. Moeilijker is het om een bedrag te herkennen zodra het eerste getal in een stuk met een euro(symbool) wordt benoemd maar de tweede keer zonder.
Deze structuur is makkelijk te herkennen. Het is echter moeilijker zodra er slechts “10 mil-joen” staat. Het zal vaak gaan over geld, maar soms ook over bijvoorbeeld mensen. De context bepaald dan of het gaat over een geldbedrag of over een kwantiteit. We zouden dus verwachten dat een getraind model vaker een bedrag op zou pakken dan we geautomatiseerd zouden kunnen herkennen, maar ook vaker een kwantiteit aan ziet voor een geldbedrag.
3.2.3
Organisaties
In een vergadering wordt er veel verwezen naar instituten en rapporteren. Denk hierbij aan de rekenkamer, NAVO, Europese Unie, etc. Maar ook zijn er veel ministeries en commissies.
De tweede kamer heeft dus te maken met veel instituten. Huidige modellen zijn hier niet op ingesteld.
In de structuur van notulen wordt vaak in het begin een instituut volledig uitgeschreven, waarna het snel over gaat naar het gebruik van slechts een afkorting. SpaCy herkent veel insti-tuten, maar ook veel niet.
Ministeries en commissies kunnen we uit de data van de Tweede Kamer halen en daarom direct toevoegen, de instanties die niet direct gerelateerd zijn wordt al moeilijker.
Waar een kamer normaal gezien zou worden als een locatie, wordt het hier gezien als een organisatie/orgaan. Hetzelfde geldt voor het rijk
• de Kamer • het Rijk
• de Belastingdienst
• het ministerie van Financi¨een • Nederlandse Staat
Waarbij het laatste ingewikkeld kan zijn omdat Nederlandse zonder Staat een nationaliteit is, bijvoorbeeld als er gesproken wordt over Nederlandse burgers. Maar de kamer spreekt vooral vaak in afkortingen voor organisaties
• NPO (Nederlandse Publieke Omroep) • BuZa (Buitenlandse Zaken)
• RIVM (Rijksinlichtingen- en veiligheidsdienst)
HOOFDSTUK 4
Methode
Search Engine Result Page (SERP) is de pagina waar de resultaten van een zoekopdracht worden weergegeven. In zo’n SERP kan een gebruiker verschillende eisen stellen om zo’n query op te bouwen. Vervolgens geven wij aan de eindgebruiker een lijst met documenten weer.
Aan zo’n query kunnen ook filters toegevoegd worden. Deze filters kijken naar de inhoud van de metadata om bepaalde documenten uit de resultaten te halen, om een gebruiker beter te laten focussen. Maar dit werkt ook andersom; de metadata van de gevonden documenten kan gebruikt worden om grafieken en woordenwolken van de resultaten te maken.
Zoals eerder genoemd slaan we ook de geanalyseerde entiteiten van de tekst op in de met-adata van het document. Dit maakt het mogelijk om slimmere woordenwolken te maken die entiteiten gebruiken. Gecombineerd met de NER kunnen we ook woordenwolken genereren per entiteitcategorie, dus bijvoorbeeld met alleen personen of organisaties.
4.1
Architectuur
Om verkregen data zoekbaar te maken moeten we een systeem ontwerpen die het mogelijk maakt om op basis van een query de juiste resultaten te presenteren aan de eindgebruiker. Een query kan een woord of meerdere woorden bevatten, en kan ook filters hebben. Bijvoorbeeld: “ik wil alle teksten met de term digitalisering in het jaar 2018.”
4.1.1
Elasticsearch
Elasticsearch (vaak ook alleen Elastic) maakt het mogelijk om snel en effici¨ent door grote hoe-veelheden data te zoeken met veel extra mogelijkheden en valt precies af te stellen. Elasticsearch is geen dataopslag. Het is bedoeld om gebruikt te worden naast databases of andere vormen van meer persistente opslag en niet om het te vervangen. De XML met handelingen is vaak diep genest en bevat veel referenties naar andere documenten. Het is dus ideaal de XML van een vergadering door te zoeken met Elastic, omdat we slechts een representatie hoeven te geven van de data. We slaan als het ware de rijk gevulde XML met diverse relaties plat, om alleen de relevante zoekbare data over te houden. De communicatie tussen de ElasticSearch server en een losse webserver gaat dan via JSON, wat weer wordt omgezet naar een resultaat voor de eindgebruiker.
We indexeren alle personen, partijen, commissies zoals aangegeven in de OData API zodat we deze kunnen gebruiken als filters. Uit de XML bestanden van een vergadering indexeren we alleen tekst van sprekers, dus bijvoorbeeld niet de moties. Door middel van JSON kunnen deze zoekresultaten opgevraagd worden.
4.1.2
Backend
Een gebruiker moet op een intu¨ıtieve manier kunnen communiceren met de achterliggende zoek-machine (Elastic). Hiervoor hebben we gebruik gemaakt van Django, een webframework voor
Python.
De Django instantie maakt gebruik van een PostgreSQL database met een kopie van de gegevens uit de OData API. Hierin staan dus bijvoorbeeld alle partijen, commissies en personen. De XML met gesproken tekst wordt via Django naar Elastic gestuurd om te indexeren.
4.1.3
Frontend
Voor de frontend maken we gebruik van Vue.js in combinatie met Bootstrap voor CSS styles. Vue.js is een Javascript framework. Hiermee kunnen we het weergeven van woordenwolken en het highlighten van entiteiten interactief maken.
4.2
Documenten
Een stuk tekst met toegevoegde informatie (metadata) noemen we een Document. Om een document daadwerkelijk nuttig te maken voor Elastic moeten we metadata toevoegen. Het belangrijkste is natuurlijk de uitspraak/tekst zelf. Om deze makkelijker vindbaar te maken voegen we de metadata van spreker en van de vergadering toe. Dat ziet er dan zo uit:
• Tekst • Spreker 1. Naam 2. Partij (optioneel) • Vergadering 1. Titel 2. Datum 3. Aanwezigen 4. Commissie (optioneel)
We maken voor de tekst specifiek gebruik van een ingebouwde plugin die het mogelijk maakt om entiteiten toe te voegen aan een stuk tekst (annotated text). Dit gebeurt met een Markdown-achtig protocol
De (VVD)[ORG] is op dit moment de grootste partij van (Nederland)[GPE]
In dit protocol wordt tussen de vierkante haken de entiteit categorie van de tekst tussen de haakjes beschreven, zoals ORG voor Organisatie en GPE voor Geo-political Entity. Dit kunnen ook meerdere zijn, gescheiden door een ampersand. Dit wordt bijvoorbeeld gebruikt om onze naam van de query te kunnen highlighten. Dit kunnen we vervolgens visualiseren in onze frontend zoals weergegeven in figuur 4.1.
4.3
Entiteiten herkennen
We kunnen in Elasticsearch entiteiten weergeven in de tekst. Om entiteiten te herkennen maken we gebruik van NER. We moeten dan tijdens het indexeren van een stuk tekst de entiteiten toevoegen door middel van tekstanalyse.
Voor het analyseren van deze teksten zijn er verschillende bibliotheken beschikbaar, met meer bekende zoals TensorFlow, OpenNLP en SpaCy. Er is hier geen duidelijk beter presterende bibliotheek; verschillende onderdelen van de pipelines doen het beter op uiteenlopende datasets [1].
Zoals al aangegeven maken we voor dit onderzoek gebruik van SpaCy1. SpaCy is een
open-source bibliotheek voor geavanceerde Natural Language Processing, specifiek gericht op gebruik 1SpaCy: https://www.spacy.io/
Figuur 4.1: Visualisatie van een document
in productie-applicaties. SpaCy heeft ingebouwde ondersteuning van de Nederlandse taal. Dit model is op basis van nieuwsartikelen van het internet.
Binnen de taalanalyse worden entiteiten opgedeeld in verschillende categorie¨en. SpaCy maakt specifiek onderscheid tussen de volgende entiteiten [14]:
Figuur 4.2: Omschrijving van alle SpaCy entiteitcategorie¨en
Type Omschrijving
PERSON Mensen, inclusief fictioneel
NORP Nationaliteiten, religieuze of politieke groepen FAC Gebouwen, vliegvelden, snelwegen, bruggen, etc. ORG Bedrijven, agencies, instanties, etc.
GPE Landen, steden, provincies.
LOC Non-GPE locaties, gebergtes, waterlichamen PRODUCT Objecten, voertuigen, voedsel, etc.
EVENT Orkanen, verslagen, oorlogen, sport evenementen, etc. WORK OF ART Boeken, liederen, etc.
LAW Wetten
LANGUAGE Talen
DATE Absolute of relatieve dagen, of periodes TIME Periodes korter dan dagen
PERCENT Percentages, inclusief % MONEY Monetaire eenheden.
QUANTITY Afmetingen (gewicht of afstand). ORDINAL Eerste, Tweede, enz.
CARDINAL Numerieke eenheden die niet vallen onder eerder genoemde categorieen
Sommige van deze entiteiten zullen standaard niet goed herkend worden omdat de NER niet is aangepast op onze dataset. Het interne statistische model voor NER kan BERT-style worden bijgetraind met een eigen datasets. Dit maakt het dus mogelijk om een eigen model te cre¨eren die we aanpassen op basis van de informatie verkregen van de Tweede Kamer.
Om op te lossen dat entiteiten niet goed worden herkend kunnen we gebruik van training. We kunnen zo een model de nuances leren van de entiteiten. Hiervoor hebben we een dataset van geannoteerde data nodig.
SpaCy traint op basis van de Gold standard. Dit houdt in dat in een zin de entiteiten worden gedefinieerd als een tuple van (entity type, start, einde) waar start en einde de index is van een karakter.
4.3.1
Ons model
Om een Spacy model bij te trainen hebben we een dataset nodig. Om deze dataset op te bouwen hebben we eefn een tool geschreven om snel handmatig zinnen te annoteren. Deze tool maakt ge-bruik van het ingebouwde model voor Nederlands uit SpaCy, namelijk het nl core web sm model, vanaf nu te noemen model A. De tool kiest willekeurige zinnen geselecteerd uit de handelingen op basis van een seed, zodat zinnen niet herhaald worden. Deze zinnen worden eerst geannoteerd met model A, zodat de gebruiker niet alle entiteiten in hoeft te voeren maar slechts hoeft te corrigeren waar nodig.
Zoals eerder beschreven is de structuur van namen die wordt gehanteerd in de notulen vrij ongebruikelijk. Om het makkelijker te maken voor de persoon die aan het annoteren is worden automatisch alle personen uit de Tweede Kamer ingeladen in een zogenaamde mat-cher. De matcher maakt dan gebruik van een lijst van alle achternamen en matcht ook de heer/vrouw/minister/mevrouw/meneer/mijnheer mee als dit er voor staat, en voegt hier de en-titeit PERSON aan toe.
De interface laat nu de zin met annotaties zien in gold standard en geeft deze weer aan de gebruiker:
["Geert Wilders is partijleider van de PVV", [[0, 13, "PERSON"], [37, 40, "ORG"]] De gebruiker kan nu kijken of deze zin correct is geanotteerd. Is dit niet het geval, dan kan de gebruiker het corrigeren. Om de zoveel zinnen worden de resultaten opgeslagen in een JSON bestand, zodat we deze kunnen gebruiken voor de training.
De matcher kan ook fouten maken doordat sommige achternamen misschien ook normale woorden zijn (denk aan mevrouw Kant ). Het model kan natuurlijk ook entiteiten verkeerd herkennen. In het geval van zo’n false-positive of false-negative moet de gebruiker een correctie maken, het proces is dus niet geautomatiseerd.
Met de opgeslagen JSON bestanden kunnen we het standaard model van SpaCy bijtrainen. Dit nieuwe model noemen we model B. We slaan voor dit model de entiteiten PRODUCT, WORK OF ART, LANGUAGE, QUANTITY, TIME en LOC over omdat deze bijna niet voorkomen in de handelin-gen. De dataset die we gemaakt hebben met de tool heeft 5.536 geclassificeerde zinnen in Gold Standard. In totaal bevat deze dataset 86.206 woorden, met 3.578 geannoteerde entiteiten. Dit betekend dus dat er gemiddeld minder dan ´e´en entiteit per zin wordt herkend. Ongeveer 4.2% van de woorden in deze dataset bevat een entiteit.
Figuur 4.3: Aantal classificaties per entiteitcategorie in de dataset
Type Aantal PERSON 1163 NORP 149 FAC 11 ORG 954 GPE 395 EVENT 31 LAW 76 DATE 261 PERCENT 59 MONEY 75 ORDINAL 142 CARDINAL 262 Totaal 3579
Tijdens het maken van de dataset kan er gekozen worden om alvast een model bij te trainen, om dit nieuwere model vervolgens te gebruiken in de tool. Dit model zou dan beter moeten functioneren en de geannoteerde zinnen zouden minder correcties van de gebruiker nodig moeten hebben. Zo kan het annoteren met de tool steeds sneller worden.
4.4
Gebruikersinterface
We maken hier gebruik van de principes uit het boek Search User Interfaces [9]. We gaan hier verder niet in op de functionaliteit die standaard in Elasticsearch zit, maar slechts over de visualisatie. We gaan het ook niet hebben over personalisatie en mobiele interfaces, omdat dit niet van toepassing is op dit project.
4.4.1
Design
De meeste zoekresultaten worden weergegeven in een verticale lijst, met elk informatie over het document en waarom het is gekozen. Door de termen uit de query te highlighten geef je die visuele feedback die nodig is om weer te geven waarom dit document wordt weergegeven aan de gebruiker. Zo kan de gebruiker zo snel mogelijk de beslissing maken of het document daadwerkelijk relevant is. Google maakt bijvoorbeeld de termen uit de query dikgedrukt om deze te highlighten. Wij gebruiken een geel tekstvlak om de woorden. Dit staat als metafoor aan een gele tekstmarker.
Zo’n highlighted woord wordt dan weergegeven in bijvoorbeeld een alinea. Oudere zoekma-chines lieten vaak ´e´en zin of soms zelfs slechts een gedeelte van een zin zien bij een document. Dit is echter vaak te weinig om goed de context te bepalen, en wordt daarom in moderne zoek-machines niet meer gedaan. In onze implementatie geeft Elasticsearch de alinea in kwestie weer, maar kort deze in als deze voorbij de 350 karakters gaat.
Figuur 4.4: Gebruikersinterface voor zoekopdracht “Amerika”
Het “blenden” van resultaten uit verschillende bronnen zoals het weergeven van afbeeldingen kan het herkennen van de context versnellen. In ons ontwerp geven we de logo’s van partijen en gezichten van personen weer bij de grafieken en documenten, zodat er sneller herkend kan worden over wie en wat iets gaat.
Een andere effectieve manier van visuele feedback bij zoekresultaten is het toestaan van sorteren op diverse rangschikkingen. Gebruikers kunnen dan interactief resultaten vergelijken, omdat de resultaten direct beschikbaar zijn.
4.4.2
Informatie visualisatie
Om een zoekmachine verder te verbeteren kunnen we visuele informatie opnemen met technieken uit het veld van informatie visualisatie. De perceptie van mensen is sterk afgestemd op het verwerken van visuele informatie in tegenstelling tot tekst. De essentie van een grafiek wordt veel sneller waargenomen dan van een tabel.
Een belangrijke waarneembare eigenschap is preattentiveness. Deze term wijst naar een eigen-schap die een persoon kan waarnemen binnen 250 milliseconden, dus zonder de ogen te bewegen [15]. Mensen kunnen bijvoorbeeld heel snel aangeven of er een rode cirkel binnen een aantal blauwe cirkels te vinden is. Hoeveel rode cirkels er zijn kan dan weer niet zonder de hele omge-ving te “scannen”.
Preattentiveness verklaard hiermee waarom het zo effectief is om een kleur als highlight te gebruiken op een witte achtergrond. Wij gebruiken deze techniek dan ook om herkende entiteiten een kleur te geven. Elke entiteitcategorie heeft een andere kleur. Als een gebruiker bijvoorbeeld aan het zoeken is naar welke organisaties betrokken zijn bij een onderwerp, kan dit al in ´e´en oogopslag.
Figuur 4.5: Grafiek met aantal resultaten per jaar voor de zoekopdracht “stikstof”
Een andere vorm van informatie visualisatie zijn grafieken. Als een zoekopdracht kwanti-tatieve informatie geeft kan dit deze geplot worden. Dit is het meest krachtig als je meerder visuele eigenschappen combineerd. In figuur 4.6 is bijvoorbeeld zichtbaar hoe de sprekers zijn uitgezet tegenover het aantal resultaten per jaar. Hier worden tien personen weergegeven, met de bijbehorende kleur. De gebruiker kan vervolgens door middel van een interactie de exacte cijfers zijn.
Figuur 4.6: Grafiek voor aantal resultaten per spreker
4.4.3
Evaluatie
Om de bruikbaarheid van een gebruikersinterface te evalueren is wat moeilijker. Er zijn drie onderdelen die hier belangrijk zijn om te meten:
• Effectiviteit: de accuraatheid en compleetheid van de resultaten
• Effici¨entie: hoe accuraat en compleet zijn de middelen waarmee de gebruiker zijn doel moet bereiken.
• Tevredenheid: hoe positief is de gebruiker
Om dit te meten zijn er verschillende methodes. Je kunt een controlled experiment opzetten waarbij alles wordt gemeten, of informele usability tests waarbij enkele gebruikers elke stap in het ontwikkelproces feedback geven.
Controlled experiments
Ook wel formele usability studies. Hier wordt bijvoorbeeld gebruik gemaakt van opnames (audio, video, scherm, oog volgen) om een technische analyse op uit te voeren. Hier kan worden gekeken waar de muis het meest is en waar de gebruiker op welk moment naar kijkt, om zo bepaalde hot spots te bepalen.
Een andere optie is om een analyse te doen op logs van de zoekmachine. Dit is echter geen goede optie als er niet genoeg gebruik gemaakt wordt van de zoekmachine. Er zijn dan niet genoeg resultaten om conclusies uit te trekken.
Complete controlled experiments zijn op zichzelf al een heel onderzoek, waar veel participan-ten voor nodig zijn en is daarom niet geschikt voor kleiner onderzoek.
Informele usability testing
Bij informele usability tests wordt er gebruik gemaakt van een paar representatieve gebruikers. Er wordt gedurende het proces telkens feedback gevraagd, waarna de feedback wordt verwerkt. Dit iteratieve proces zorgt ervoor dat ontwikkelaars minder makkelijk gehecht raken aan een specifiek ontwerp, omdat ontwerpfouten eerder in het proces er al uit gehaald kunnen worden.
Het is bij dit soort experimenten vooral belangrijk om vooroordelen van participanten te vermijden. Het is belangrijk dat de participant ook in de vraagstelling niet op kan maken wat de voorkeur van de ontwikkelaar is, maar echt een eigen mening kan vormen.
Informeel testen kan heel effectief zijn. Bij iteratief ontwerp kan bij het gebruik van slechts vijf deelnemers al gemiddeld 85% van de usability problemen gevonden worden [13]. Dit is daarom ook de makkelijkste manier om binnen een korte periode een goed ontwerp te cre¨eren.
4.5
Woordenwolken
Woordenwolken zijn een andere manier om data te visualiseren om zo een gebruiker een beter beeld te geven van een dataset [7]. Als we een woordenwolk met informatie uit een vergadering of een query willen visualiseren, willen we graag de meeste relevante woorden in de vergadering laten zien. Hoe groter het woord, des te relevanter [3]. Laten zien welke woorden het meeste voorkomen ligt hier misschien op het eerste gezicht het meest voor de hand. Het probleem hier mee is, is dat we dan voornamelijk dezelfde woorden gaan zien. Sommige woorden worden nou eenmaal vaker gebruikt dan anderen ongeacht de context. De wolken worden daarom opgesteld op basis van significant terms. Dit houdt in dat we niet kijken naar hoe vaak een woord gebruikt wordt, maar hoe vaak een woord gebruikt wordt ten opzichte van het gemiddelde. Twitter doet dit bijvoorbeeld ook voor hashtags, om te kijken wat er op dat moment Trending is.
Nog steeds kunnen we niet voorkomen dat irrelevante woorden zoals lidwoorden aan worden geduid als significant term. Om dit helemaal te voorkomen, en om het genereren van de woor-denwolk sneller te maken slaan we op elk document een aparte Array op met alleen werkwoorden, zelfstandig naamwoord en bijvoegelijk naamwoord (NOUN
PROPN, ADJ, VERB) op basis van de Part-of-Speech tagging van SpaCy. Hiermee filteren we als het ware de irrelevante woorden.
We gebruiken diezelfde techniek om een woordenwolk van ´e´en specifieke entiteit weer te geven door een aparte Array toe te voegen. Zo kun je in ´e´en oogopslag zien welke personen en organisaties in een vergadering besproken worden.
Figuur 4.7: Woordenwolk voor de zoekterm “Trump”
Om de (relatieve) grootte van een woord te bepalen maken we gebruik van de frequentie van een woord in de zoekopdracht. Er is hier gekozen voor een macht van twee-vijfde, dus niet een lineaire verhouding (tot de macht 1).
S = N25 (4.1)
Er is voor deze verhouding gekozen zodat alle woorden, groot of klein, goed leesbaar blijven. Twee-vijfde is visueel bijna hetzelfde als de wortel trekken (tot de macht 12). Het is voor woord-frequenties goed mogelijk dat het ene woord 2000 keer voorkomt en het andere 50 keer. Beide zouden dan in de wolk staan maar het ene woord is dan 40 keer zo groot. Door gebruik te maken van een verhouding van twee-vijfde staat het relatieve verschil bovenaan in plaats van het directe verschil. Een verschil tussen 30 en 45 is namelijk een stuk interessanter dan het verschil tussen 2500 en 2515.
HOOFDSTUK 5
Resultaten
SpaCy heeft verschillende modellen voor enkele talen. In het Nederlands is op het moment van schrijven alleen de nl core web sm beschikbaar We maken in de experimenten gebruik van dit model A en B zoals beschreven in Sectie 4.3.
Voor de resultaten van het trainen van model B maken we gebruik van Cross Validation door middel van de train/test split techniek. Dit houdt in dat we een random split maken van onze dataset. De test data wordt slechts gebruikt voor het valideren van het model en dus niet bij het trainen.
We doen 8 verschillende trainingen op telkens een andere split. De resultaten geven het gemiddelde weer van 8 modellen waarbij 20% van de dataset wordt gebruikt voor de evaluatie (80:20).
5.1
Experiment 1
Dit experiment is om te bepalen hoeveel iteraties we willen doen voor ons tweede experiment. We plotten in figuur 5.1 de evaluatie, hier zetten we de F-score van het model op de evaluatie data uit tegenover het aantal iteraties aan trainingen van SpaCy. Er wordt hier ook de lichtere kleur de interval weergegeven met de minimum en maximum score van de trainingen.
Figuur 5.1: Evaluatie van model training
0 10 20 30 40 50 60 70 80 90 100 50 60 70 80 90 100 Iteraties F-score
van een log loss, ook wel cross-entropy loss. Log loss geeft een grotere “straf” aan een foute classificatie waar de confidence van het model hoog is [10].
− log p(y|x) = −[y log ˆy + (1 − y) log(1 − ˆy)] (5.1) Figuur 5.2: Gradient descent met log loss van het model
0 20 40 60 80 100 120 140 0 1,000 2,000 3,000 4,000 Iteraties Losses
5.2
Experiment 2
We meten hier de verbeteringen tussen het getrainde en een ongetrainde model door middel van een score. De score wordt hier berekend door de SpaCy Scorer klasse1. Deze bouwt een score
tussen 0.0 en 100.0 in plaats van 0.0 en 1.0 zoals we zouden verwachten. De F-score in figuur 5.5 is berekend in verhouding tot de entiteiten die voorkomen in het model. De entiteit PERSON komt veel vaker voor dan bijvoorbeeld LAW, en telt daarom meer mee in de totale score.
Het aantal iteraties staat vast op 100 op basis van experiment 1.
Figuur 5.3: Tabel met scores voor precisie (P ), vangst (R) en F-score (F1)
(a) Model A (ongetraind)
Type P R F1 PERSON 16.06 6.27 9.00 ORG 58.75 37.12 45.46 MONEY 17.92 4.79 7.46 LAW 50.00 4.27 7.76 GPE 60.40 87.51 71.37 NORP 50.21 89.65 64.12 DATE 80.32 86.54 83.24 PERCENT 97.30 96.46 96.82 FAC 0.63 12.5 1.19 EVENT 0.00 0.00 0.00 ORDINAL 91.52 95.90 93.60 (b) Model B (getraind) Type P R F1 PERSON 93.80 91.97 92.86 ORG 82.99 85.30 84.10 MONEY 95.09 93.03 93.90 LAW 81.73 76.57 78.64 GPE 92.53 90.56 91.47 NORP 85.03 85.75 85.27 DATE 89.31 90.99 90.11 PERCENT 97.60 96.47 97.01 FAC 50.0 56.25 52.08 EVENT 62.5 43.68 51.01 ORDINAL 96.94 95.49 96.17
Figuur 5.4: Staafdiagram met F-Scores per entiteit voor model A en B
PERSON ORG MONEY LAW NORP GPE DATE PERCENT FAC EVENT ORDINAL 0 20 40 60 80 100 F-score Model A Model B
Figuur 5.5: Staafdiagram met totale F-score van model A en B
Model A Model B 0 20 40 60 80 100 F-score
5.3
Experiment 3
Gevraagd is aan enkele personen die gebruik gaan maken van de zoekmachine om een vragenlijst in te vullen over de gebruikersinterface. De participanten worden gevraagd om vier onderzoeks-vragen te beantwoorden met behulp van de zoekmachine. Hierna wordt ook gevraagd om te beoordelen hoe nuttig bepaalde functies waren bij het gebruik op een schaal van 1 tot 10.
Figuur 5.6: Cijfers uit vragenlijst op basis van drie respondenten Hoeveel helpt het “highlighten” van relevante onderwerpen in de tekst met het sneller begrijpen van de resultaten van een query?
8 8 7
Hoeveel helpt een woordenwolk met het sneller begrijpen van een query?
7 4 8
Hoeveel helpen woordenwolken op basis van categorie (bijv. gevon-den personen of instanties) met het sneller begrijpen van een query?
7 8 8
Hoeveel helpt een grafiek die toont hoeveel resultaten er per jaar zijn met het sneller begrijpen van een query?
9 7 8
5.4
Voorbeelden
Hieronder zichtbaar zijn een paar voorbeelden van resultaten van SpaCy in het Elasticsearch annotated text formaat. Het eerste voorbeeld is telkens het ongetrainde nl core web sm model (Model A), het tweede is het model bijgetraind op onze dataset (Model B).
Voorbeeld 1
(A) Ik vind het een volstrekt onnodige en overbodige vraag, want elke [euro](PERSON)
die we op een onterechte manier uitgeven, is er een te veel, of dat nou €[1](CARDINAL), €[10](CARDINAL), [1](CARDINAL) [miljoen euro](EVENT) of [14 miljoen](DATE) euro
is. Aan elke [euro](MONEY) | het is gewoon belastinggeld | die we uitgeven die we niet hadden hoeven uitgeven aan mensen die niets [anders doen dan op een oneerlijke manier geld proberen](ORG) te vangen, moeten we iets doen.
(B) Ik vind het een volstrekt onnodige en overbodige vraag, want elke euro die we op een onterechte manier uitgeven, is er een te veel, of dat nou [€1](MONEY), [€10](MONEY), [1 miljoen euro](MONEY) of [14 miljoen euro](MONEY) is. Aan elke euro | het is gewoon belastinggeld | die we uitgeven die we niet hadden hoeven uitgeven aan mensen die niets anders doen dan op een oneerlijke manier geld proberen te vangen, moeten we iets doen.
In model A worden er duidelijke fouten gemaakt. Euro wordt aangeduid als PERSON en hete teken wordt los gezien van het cijfer. Alleen “euro” zelf wordt gezien als geld, wat overigens ook nog eens verkeerd is. 14 miljoen wordt gezien als datum. In model B wordt alles correct getagd. Voorbeeld 2
(A) Voorzitter. Als ik eerlijk zou zijn over de Wet werk en zekerheid, dan hebben we een kabinetscrisis, zei de minister-president vorige [week](DATE) hier voor de deur. Dat lijkt mij een debat waard met de minister van Sociale Zaken en Werkgelegenheid en de minister-president. Dan kan de minister-president hier zijn eerlijke verhaal vertellen.
(B) [Voorzitter](PERSON). Als ik eerlijk zou zijn over de Wet werk en zekerheid, dan hebben we een kabinetscrisis, zei [de minister-president](PERSON) [vorige week](DATE) hier voor de deur. Dat lijkt mij een debat waard met [de minister van Sociale Zaken en Werkgelegenheid](PERSON) en [de minister-president](PERSON). Dan kan [de minister-president](PERSON) hier zijn eerlijke verhaal vertellen. De voorzitter, de minister-president en de minister van Sociale Zaken en Werkgelegenheid wordt hier correct aangeduid als personen. Ook is er een kleine verbetering in de herkenning van DATE. In het eerste voorbeeld wordt bij “vorige week” alleen “week” herkend. In het tweede voorbeeld is het wel correct. De Wet werk en zekerheid (LAW) wordt helemaal niet herkend. Voorbeeld 3
(A) Aan de orde is het [VAO](ORG) Raad Buitenlandse Zaken. Ik heet de minister van Buitenlandse Zaken van harte welkom en geef de heer [Sjoerdsma](PERSON) namens [D66](GPE) het woord.
(B) Aan de orde is het [VAO Raad Buitenlandse Zaken](ORG). Ik heet [de minister
van Buitenlandse Zaken](PERSON) van harte welkom en geef [de heer Sjoerdsma](PERSON) namens [D66](ORG) het woord.
De minister wordt hier opnieuw goed herkend in model B. Hetzelfde voor de heer Sjoerdsma. D66 werd op het orginele model geannoteerd als Geopolitical Entity (GPE). In model B wordt deze correct geannoteerd als organisatie. De VAO Raad Buitenlandse Zaken wordt wel correct herkend, maar verkeerd geannoteerd. Een VAO is een Verslag Algemeen Overleg, en zou dus een EVENT moeten zijn.
Voorbeeld 4
(A) Opnieuw geen antwoord op mijn vraag. Het gaat er niet om wat ik wel of niet
gezegd heb of wat de heer Van Bommel heeft gezegd. Er hebben [4](CARDINAL) miljoen mensen gestemd.
(B) Opnieuw geen antwoord op mijn vraag. Het gaat er niet om wat ik wel of niet
gezegd heb of wat [de heer Van Bommel](PERSON) heeft gezegd. Er hebben [4 miljoen](MONEY) mensen gestemd.
Hier is een voorbeeld waar het model een keuze maakt die fout is, maar logisch uit te leggen. Als er wordt gesproken over miljoenen over miljarden is dat bijna altijd een geldbedrag. In de dataset zijn weinig tot geen voorbeelden waar dit niet het geval is, en daarom wordt een getal gevolgd door miljoen of miljard bijna automatisch geclassificeerd als MONEY.
Voorbeeld 5
(A) Ik wens hier eigenlijk geen interruptie aan te besteden. Zo vat ik dit ook niet
op. Ik hoop u ook niet, voorzitter. Ik heb op die avond | de heer [Ten Broeke](PERSON) heeft het niet goed gehoord | niet gezegd dat ik met dit handelsverdrag kon
leven, maar wel dat ik met een handelsverdrag kan leven. Dat is een groot verschil. [Jawel](NORP).
(B) Ik wens hier eigenlijk geen interruptie aan te besteden. Zo vat ik dit ook niet op. Ik hoop u ook niet, [voorzitter](PERSON). Ik heb op die avond | [de heer Ten Broeke](PERSON) heeft het niet goed gehoord | niet gezegd dat ik met dit handelsverdrag kon leven, maar wel dat ik met een handelsverdrag kan leven. Dat is een groot verschil. [Jawel](ORG).
Er wordt hier een fout gemaakt bij het laatste woord. In zowel model A als model B wordt “Jawel” geannoteerd. Dit valt moeilijk te verklaren. Het enige wat we hier uit kunnen halen is dat omdat SpaCy dit al (verkeerd) zag als een entiteit, de training niet voldoende was om dit af leren.
HOOFDSTUK 6
Conclusie
6.1
Onderzoeksvraag
De onderzoeksvraag “In hoeverre kan het annoteren van entiteiten in de handelingen van de Tweede Kamer het zoeken vergemakkelijken?” is in de inleiding uiteengezet in twee deelvragen: • Hoe kunnen we named-entity recognition trainen om beter te werken op personen,
organi-saties en monetaire eenheden uit handelingen van de Tweede Kamer?
• Hoe kunnen we resultaten van tekstanalyse integreren binnen de gebruikersinterface? Om de onderzoeksvraag te beantwoorden, bespreken we eerst de twee losse deelvragen, om vervolgens de hoofdvraag te beantwoorden.
6.2
Named-entity recognition trainen
De named-entity recognition was zonder trainen uitstekend in staat om cijfers (ORDINAL), datums en percentages te herkennen. Logischerwijs is hier daarom ook het minste resultaat geboekt.
Voor NORP en GPE zijn aantoonbare verbeteringen te zien. In Experiment 2 is goed zichtbaar dat de F-score voor deze entiteiten omhoog is gegaan. Dit is echter grotendeels te danken aan de precisie (P) en nauwelijks aan de vangst (R). Dit komt er op neer dat vooral het aantal false-positives omlaag is gegaan maar het aantal herkende entiteiten niet veel. Er aantal fouten wat werd gemaakt is dus vooral geminimaliseerd.
PERSON en ORG zijn enorm vooruit gegaan op zowel precisie als vangst. Vooral personen worden in het originele model nauwelijks herkend. Dit is te danken aan de structuur van personen zoals beschreven in Sectie 3.2.1. Het model heeft herkend dat als er bijvoorbeeld “de heer” staat dat dit waarschijnlijk gevolgd gaat worden door een achternaam en dus een persoon is. In dat getrainde model weet SpaCy deze structuur dan dus te herkennen en weet ook tussenvoegsels mee te nemen. Hetzelfde geldt voor organisaties: bedrijven zoals Shell werden al wel herkend maar politieke instanties zoals ”het ministerie van Buitenlandse Zaken”niet. Deze structuur moest worden aangeleerd. Bij zowel personen als organisaties zijn er ook nieuwe termen geleerd. Met name bij organisaties zijn er veel nieuwe instellingen die nu wel herkend worden. De grote winst onder personen valt vooral toe te schrijven aan de herkenning van de structuren.
MONEY werd van alle entiteiten als een van de slechte herkend, dat is nu andersom. Dat is waarschijnlijk te danken aan de relatief simpele structuur van geldbedragen.
FAC, EVENT en LAW zijn flink vooruit gegaan maar LAW heeft nog een lage vangst (veel false-negatives) en FAC en EVENT komen eigenlijk te weinig voor in de dataset om er echt iets over te kunnen zeggen. Vandaar ook de grote standaardafwijkingen zichtbaar in de grafiek van Experi-ment 2.
Er komt uit de experimenten duidelijk naar voren dat er grote stappen vooruit zijn gemaakt om entiteiten te herkennen in de handelingen van de Tweede Kamer. De grootste vooruitgang
is geboekt op personen, organisaties en geldbedragen. Deze entiteiten komen veel voor in de vergaderingen. Voorbeelden van de verbeteringen in het model met commentaar zijn de vinden in Sectie 5.4.
6.3
Gebruikersinterface
Met de antwoorden op de vragenlijst kunnen we een aantal interessante dingen opmaken. De assumptie dat de websites van de overheid onvoldoende zijn voor onderzoek zijn wordt hier bevestigd.
De zoekvragen die worden gesteld worden door de gebruikers allemaal op ongeveer dezelfde manier opgelost en maken hier gebruik van de functies die hier voor bedoelt zijn. Hier kunnen we dus uit opmaken dat het gebruik van de functies duidelijk is. Met name het highlighten van de relevante personen (vraag A) werd over het algemeen aangegeven als nuttig. Een respondent geeft aan dat het “helpt bij het in-context interpreteren van de zoekresultaten”.
De consensus bij “normale” woordenwolken (vraag B) is dat ze handig kunnen zijn, maar de gebruiker eerst moet scannen op irrelevante woorden. Met onze methode worden al zoveel mogelijk woorden die niet relevant zijn verwijderd, maar dit is dus kennelijk nog niet voldoende. De woordenwolk zonder specifieke entiteiten wordt van alle functies ook het laagst beoordeeld, met als laagste cijfer een 4. Dit terwijl de woordenwolken voor een specifieke categorie entiteit (vraag C) wel van alle respondenten een ruime voldoende krijgt. Het lijkt er dus op dat de toevoeging van named-entity recognition van aantoonbare extra waarde is.
De grafiek met resultaten per jaar (vraag D) krijgt gemiddeld het hoogste cijfer. Zo’n grafiek “geeft mooi inzicht in de opkomst van een term in het politieke debat en geeft aanleiding tot verder onderzoek rond bepaalde kernjaren” volgens een respondent. Dit is handig voor kwantitatieve analyse van een zoekvraag.
De respondenten geven wel aan dat er nog een aantal dingen verbeterd/toegevoegd moet worden, maar dit zijn slechts kleine functies die niet veel met de taalanalyse te maken hebben. De exacte antwoorden op de vragen zijn ook te vinden in Appendix A.
6.4
Onderzoeksvraag
Allereerst was het trainen van de named-entity recognition succesvol. Het is gelukt om het model nieuwe woorden te laten herkennen, maar vooral ook om voorheen onbekende structuren van geldbedragen, organisaties en personen te identificeren.
Sommige functionaliteit in de gebruikersinterface is afhankelijk van het getrainde NER mo-del. Respondenten geven in de vragenlijst aan dat de functies die gebruik maken van de NER nuttig zijn om de onderzoeksvragen te beantwoorden. Uit de evaluatie blijkt dat de toegevoegde functionaliteiten in de ogen van de gebruikers daadwerkelijk toegevoegde waarde heeft gehad.
6.4.1
Vervolgonderzoek
Er valt nog veel te winnen op bij de NER op sommige entiteiten zoals EVENT, FAC, of LAW. Deze komen relatief weinig voor in de dataset vergeleken met bijvoorbeeld PERSON of ORG en zijn daarom minder goed geoptimaliseerd.
Het model waarmee we getraind hebben is daarnaast minder uitgebreid dan sommige modellen die beschikbaar zijn in Engels, Duits of Frans. SpaCy heeft small, medium en large modellen voor talen, maar voor Nederlands alleen small. Dit model is wel snel, maar niet state-of-the-art. Nieuw onderzoek zou kunnen kijken naar modellen die met dezelfde dataset meer winst zou kunnen behalen.
In de woordenwolken wordt bijvoorbeeld “de premier” en “premier Rutte” als twee aparte entiteiten gezien. Met behulp van Entity Linking zouden personen (en eventueel ook andere entiteiten) gekoppeld kunnen worden aan een entry in de database. Hierdoor koppelen we niet alleen verschillende strings met dezelfde betekenis, maar kunnen we ook kijken als er over iemand gesproken wordt of dit over een persoon gaat die deel neemt aan het gesprek of niet. Met deze informatie zouden we een meer accurate visualisatie kunnen opstellen.
Entity linking is ook mogelijk voor ministeries en partijen. Hiervoor moet echter wel een aparte entiteit gecre¨eert worden. Hiervoor zou de dataset dan ook aangepast op moeten worden om onderscheid te maken tussen deze twee, in plaats van dat alles gezien wordt onder de categorie organisaties. De entiteiten zouden dan vanaf nul getraind moeten worden. Dit zou ook op andere vlakken een grotere precisie in het zoeken kunnen hebben.
Voor de gebruikersinterface hebben we respondenten korte vragen laten beantwoorden waarin ze aangeven hoe nuttig bepaalde functies zijn. Hier kunnen we uit opmaken of het zoeken met deze functies wordt gezien als handig en of de perceptie is dat het zoeken sneller gaat. We kunnen hiermee alleen niet aantonen of het zoeken daadwerkelijk sneller is. Met een formele usability study, dus een onderzoek van grotere schaal zouden we een betere onderbouwing kunnen geven.
Bibliografie
[1] F. N. A. Al Omran en C. Treude.
”Choosing an NLP Library for Analyzing Software Documentation: A Systematic Literature Review and a Series of Experiments”. In: 2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR). Mei 2017, p. 187–197. doi: 10.1109/MSR.2017.42.
[2] Claire Cardie en John Wilkerson.
”Text Annotation for Political Science Research”. In:
Journal of Information Technology & Politics 5.1 (2008), p. 1–6. doi: 10.1080/19331680802149590. eprint: https://doi.org/10.1080/19331680802149590. url: https://doi.org/10.
1080/19331680802149590. [3] Julie Cidell.
”Content clouds as exploratory qualitative data analysis”. In: Area 42.4 (2010), p. 514–523. doi: 10.1111/ j.1475- 4762. 2010.00952.x. eprint: https:// rgs- ibg. onlinelibrary . wiley . com / doi / pdf / 10 . 1111 / j . 1475 - 4762 . 2010 . 00952 . x. url: https://rgs-ibg.onlinelibrary.wiley.com/doi/abs/10.1111/j.1475-4762.2010. 00952.x.
[4] Leon Derczynski.
”Complementarity, F-score, and NLP Evaluation”. In: Proceedings of the Tenth International Conference on Language Resources and Evaluation (LREC’16). Portoroˇz, Slovenia: European Language Resources Association (ELRA), mei 2016, p. 261– 266. url: https://www.aclweb.org/anthology/L16-1040.
[5] Jacob Devlin e.a. BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. 2018. arXiv: 1810.04805 [cs.CL].
[6] Tom Fawcett.
”ROC Graphs: Notes and Practical Considerations for Researchers”. In: Machine Learning 31 (jan 2004), p. 1–38.
[7] Thomas Gottron.
”Document word clouds: Visualising web documents as tag clouds to aid users in relevance decisions”. In: International Conference on Theory and Practice of Digital Libraries. Springer. 2009, p. 94–105.
[8] Steven Grijzenhout, Maarten Marx en Valentin Jijkoun.
”Sentiment analysis in parliamen-tary proceedings”. In: From Text to Political Positions: Text analysis across disciplines 55 (2014), p. 117–134.
[9] Marti A. Hearst. Search User Interfaces. 1st. USA: Cambridge University Press, 2009. isbn: 0521113792.
[10] Daniel Jurafsky en James H. Martin. Speech and Language Processing (3rd ed. draft). 2019. url: https://web.stanford.edu/~jurafsky/slp3/.
[11] Maarten Marx e.a.
”Calculating the women-friendliness of parliament”. In: Driven by data (2010), p. 41.
[12] David Nadeau en Satoshi Sekine.
”A Survey of Named Entity Recognition and Classifica-tion”. In: Lingvisticae Investigationes 30 (jan 2007). doi: 10.1075/li.30.1.03nad. [13] Jakob Nielsen. Why You Only Need to Test with 5 Users. 2000. url: https : / / www .
nngroup.com/articles/why-you-only-need-to-test-with-5-users/.
[14] Bhargav Srinivasa-Desikan. Natural Language Processing and Computational Linguistics: A practical guide to text analysis with Python, Gensim, spaCy, and Keras. Packt Publishing Ltd, 2018.
[15] Anne Treisman.
”Preattentive processing in vision”. In: Computer Vision, Graphics, and Image Processing 31.2 (1985), p. 156–177. issn: 0734-189X. doi: https : / / doi . org / 10.1016/S0734- 189X(85)80004- 9. url: http://www.sciencedirect.com/science/ article/pii/S0734189X85800049.
[16] Jonathan J. Webster en Chunyu Kit.
”Tokenization as the Initial Phase in NLP”. In: Proceedings of the 14th Conference on Computational Linguistics - Volume 4. COLING ’92. Nantes, France: Association for Computational Linguistics, 1992, p. 1106–1110. doi: 10.3115/992424.992434. url: https://doi.org/10.3115/992424.992434.
BIJLAGE A
Vragenlijst
A.1
Opstelling
Hieronder staan 3 zoekvragen. Noteer welke zoektermen je gebruikt. • Welke autoriteit is verantwoordelijk voor het handhaven van de AVG?
Trefwoord(en): autoriteit AND AVG Trefwoord(en): “handhaven” “AVG” Trefwoord(en): handhaving avg autoriteit
• Hoe vaak heeft Theirry Baudet het woord “integratie” genoemd in het jaar 2018? En hoe vaak Mark Rutte?
Persoon: Baudet/Rutte
Periode: 1 januari 2018 - 31 december 2018 Trefwoord(en): integratie
Persoon: Baudet/Rutte Trefwoord(en): integratie zoekresultaten beperken tot 2018
Baudet: ik vind slechts 4 resultaten door te zoeken op “integratie” onder de persoon Baudet, met als periode 1-1-2018 - 1-1-2019
Rutte: 9 resultaten door te zoeken op “integratie” onder de persoon Rutte met dezelfde tijds-periode
• Welke 5 personen worden in het jaar 2019 het meest besproken tijdens plenaire debatten over stikstof?
Soort: Plenair
Periode: 1 januari 2019 - 31 december 2019 Trefwoord(en): stikstof
Trefwoord(en): stikstof Soort: Plenair
Periode: 1 januari 2019 - 31 december 2019 Trefwoord(en): stikstof
Afgaande op de woordenwolk (want ik zie niet zo snel een overzicht per persoon): de minister president (Rutte dus), de heer Geurts, mevrouw Lodders, de heer Heerma, de heer Madlener
A.2
Vragen
A.2.1
Algemeen
• Wat ontbreekt er op dit moment op de website(s) van de overheid in het onderzoeken van handelingen van de Tweede Kamer?
Nu ontbreekt een portal waar alle gegevens verzameld zijn, vanaf de oorsprong van de parle-mentaire democratie tot nu, met de mogelijkheid om onderscheid te maken tussen verschillende soorten Kamerstukken, en met tools als word clouds, graphs etc.
De website(s) van de overheid waarop je in de Handelingen kunt zoeken zijn niet gebruiksvrien-delijk. Ik begrijp dat er ontzettend veel documentatie doorzoekbaar is, maar wat zou helpen is een ordening op onderwerp / verantwoordelijk ministerie / Kamercommissie bijvoorbeeld. het clusteren van onderzoeksresultaten in partijen
het zoeken op bijdragen van individuele Kamerleden
het onderscheiden van individuele Kamerleden in de onderzoeksresultaten duidingsinstrumenten zoals grafieken e.d.
• Waar lette je op als je wilt weten waar een vergadering over gaat?
Dan let ik op het begin van het debat waar aangegeven wordt waarop het debat betrekking heeft Titel vergaderstuk, indien hierin iets specifieks stond. Zo niet, dan klikte ik door naar het PDF-bestand.
bij websites van de overheid: vooral titel van het debat bij Political Mashup: lastiger, dan moet je doorklikken en doorscrollen naar wat de voorzitter zegt
• Wat mis je nog in de zoekmachine/wat zou er nog verbeterd kunnen worden?
Zoeken met truncatie, chronologisch ordenen van de resultaten, toevoegen stukken Eerste Ka-mer, hits per party/speaker
Het zou fijn zijn als – net als bij policital mashup – een deel van de tekst zichtbaar is, waarop de zoekmachine de resultaten heeft gebaseerd.
ook de titel van het debat aangeven, niet alleen hoeveelste vergadering het is
als je bij woordwolken of grafieken naar de volgende pagina wilt gaan, kom je weer uit bij je eerste zoekresultaten en niet bij (bijv.) extra grafieken; dat lijkt me een foutje
het vergelijken van bijdragen van verschillende Kamerleden en/of partijen, zoals dat geloof ik in de oude versie wel kon
zoeken op verschillende soorten parlementaire documenten, zoals moties en Kamervragen (dus meer differenti¨eren)
in het verlengde daarvan, en misschien wel het belangrijkste kritiekpunt: je krijgt nu het aantal treffers, maar niet de hoeveelheid debatten als zoekresultaat
A.2.2
Beoordelingen
Graag te beoordelen met een cijfer tussen 1 en 10 en een onderbouwing waarom.
• Hoeveel helpt het “highlighten” van relevante onderwerpen in de tekst met het sneller be-grijpen van de resultaten van een query?
8 helpt bij het keyword-in-context interpreteren van de zoekresultaten 8 Zo kun je eenvoudig zien of de ‘hit’ in de gewenste context is geuit.
7 dat helpt, maar aangezien de Mashup enkel de treffers weergeeft en niet de debatten, is het soms lastig in te schatten hoeveel er nu daadwerkelijk over een bepaald onderwerp is gesproken. Je kunt bijvoorbeeld best 40 treffers hebben in slechts ´e´en debat. Andersom: je kunt ook 20 debatten hebben waarin gemiddeld twee keer de treffer voorkomt. Dat moet je dan weer zelf beoordelen; dat is lastig
• Hoeveel helpt een woordenwolk met het sneller begrijpen van een query?
7 woordenwolk kan helpen, geeft indicatie van met welke andere termen de zoekterm samen-hangt, maar vaak moet je eerst minder relevant termen eruit filteren om een word cloud echt zeggingskracht te geven
4 tenzij je eenvoudig woorden kunt uitsluiten.
8 kan erg helpen. Hele mooie functie, al krijg je er nu natuurlijk ook vaak weinig zeggende zoekresultaten uit, zoals “voorzitter”, “minister” en “premier”. Voor de betrokken perso-nen, organisaties en thema’s is het wel echt een fijne functie
• Hoeveel helpen woordenwolken op basis van categorie (bijv. gevonden personen of instan-ties) met het sneller begrijpen van een query?
7 kan iets van het politieke krachtenveld rond een vraagstuk blootleggen, welke organisaties zijn erbij betrokken
8 zo krijg je snel zicht op de betrokken autoriteiten en personen in een debat. 8 zie vorig antwoord; erg handig
• Hoeveel helpt een grafiek die toont hoeveel resultaten er per jaar zijn met het sneller be-grijpen van een query?
9 grafiek geeft mooi inzicht in de opkomst van een term in het politieke debat en geeft aan-leiding tot verder onderzoek rond bepaalde kernjaren (bijv. op het moment dat gebruik van de term sterk toeneemt
7 deze cijfers zijn handig om de kwantitatieve ontwikkeling van een debat te verkennen, maar uiteindelijk gaat het mij toch om de kwalitatieve analyse van de tekst. Dan hoeven cijfers niet zo heel veel te zeggen.
