Haystack is een open-source Python library die toelaat om question answering en semantische systemen voor het ophalen van documenten te bouwen. Deze library is gebaseerd op taalmodellen van het type Transformer. De Haystack library integreert andere open-source projecten zoals Elasticsearch, FAISS en HuggingFace.

• La recherche sur les métadonnées (information structurée). Les documents sont associés à des métadonnées définis manuellement par un agent. Celles-ci peuvent être enrichies automatiquement grâce à des techniques telles que l’extraction d’entités (NER) ou le topic modeling qui consiste à extraire les principaux thèmes traités dans les documents.
• La recherche sur le contenu (information non-structurée). Typiquement, la recherche se fait à partir d’une requête introduite par un utilisateur sur des contenus indexés. Un cas particulier de la recherche sur le contenu est de retrouver des documents dont le contenu est similaire. Ceci permet de retrouver et de consulter les traitements de dossiers portant sur des sujets similaires.

C’est ce dernier scénario que nous allons aborder ci-dessous en présentant une expérience que nous avons réalisée sur le calcul de similarité entre deux textes.

Il y a deux façons d’aborder la similarité entre textes :

• La similarité lexicale. Les textes sont considérés comme un ensemble de mots, la similarité entre deux textes est caractérisée par le degré de recouvrement entre les ensembles de mots relatifs aux textes considérés. La similarité lexicale présente cependant quelques inconvénients : l’ordre des mots dans la phrase ainsi que les relations entre les mots ne sont pas pris en compte. Deux documents peuvent avoir peu de recouvrements entre leurs vocabulaires et parler de sujets similaires car le langage naturelle comprend de nombreuses façons d’exprimer une même idée.
• La similarité sémantique. Cette méthode est une extension de la précédente qui intègre la sémantique des mots notamment via la vectorisation de texte avec des techniques comme le word embeddings ou l’utilisation de transformers tels que BERT.

L’expérience s’est faite en trois étapes : le prétraitement du contenu, la représentation numérique de texte (vectorisation) et enfin le calcul de similarité. 

Le prétraitement des textes à comparer

Tout traitement automatique de textes (ou corpus) commence toujours par une étape de « nettoyage ». Cela implique la normalisation de texte pour enlever les caractères spéciaux, la division du texte en plus petites unités (typiquement des mots) , la conversion des mots en minuscule et/ou en lemme, la suppression de la ponctuation, des mots les plus fréquents, etc. Le traitement à appliquer sera déterminé par le problème que l’on veut résoudre et la qualité du corpus.

Représentation vectorielle des textes

La plupart des algorithmes utilisent des données numériques comme input et le texte dans sa forme brute ne peut être utilisé tel quel. Il faut donc passer par une étape de transformation de données textuelles en données numériques représentées sous forme de vecteurs sur lesquelles on peut appliquer des opérations vectorielles. Ces vecteurs doivent être tels que les propriétés linguistiques du texte soient conservées.

Nous allons aborder ici les techniques les plus courantes de représentation vectorielle des textes, le choix de l’une ou de l’autre de ces techniques affecte le calcul de similarité comme nous le verrons dans l’expérience décrite ci-dessous.

Bag of Words (collection de mots)

Chaque document est représenté par un vecteur de taille fixe égal au nombre de mots du vocabulaire du corpus V (ensemble de mots présents dans le corpus) dont chaque élément représente le nombre d’occurrence d’un mot m_i  dans le document. Les mots sont considérés individuellement et l’ordre dans lesquelles ils apparaissent dans une phrase n’est pas pris en compte.

Term Frequency – Inverse Document Frequency (TF-IDF)

Le TF-IDF est une variation du BoW. Dans la méthode précédente les mots sont considérés de même importance dans chaque document. Cependant les mots récurrents dans un document d et rares dans le reste du corpus sont plus informatifs sur ce document que les mots apparaissants de façon équivalente dans tous les documents du corpus. La méthode TF-IDF permet donc d’ajuster le poids d’un mot dans un document en fonction de sa fréquence dans le document et dans le reste corpus.

La valeur de chaque élément (t) du vecteur représentant le document (d) est déterminée par la formule suivante :

Les représentations BoW et TF-IDF produisent des vecteurs larges et clairsemés (contenant beaucoup de 0) et capturent mal la sémantique des mots. Une des solutions possible à ce problème de vecteurs larges est la réduction de dimension avec des méthodes telles que l’analyse sémantique latente (LSA). Cet algorithme vise à réduire le texte à ses concepts principaux.

Word embeddings (Word2Vec, Glove,  fastText)

Les words embeddings tentent de corriger les inconvénients des méthodes décrites ci-dessous en produisant pour chaque mot un vecteur compact et dense tel que des mots ayant une signification similaire sont représentés par des vecteurs proches dans l’espace vectoriel. Chaque élément du vecteur représente un aspect de la signification du mot. Les modèles type « word vector » les plus populaires sont Word2Vec, Glove et fastText.

La représentation vectorielle du document tout entier peut-être calculée en prenant la moyenne des vecteurs de chaque terme présent dans le documents.

Transformers

Les transformers sont les modèles de représentation textuelle les plus avancés dans le domaine du NLP. Ils prennent en compte le fait qu’un mot, selon le contexte, aura un sens différent. Dans ce modèle, le mot est représenté par des vecteurs différents selon le contexte (voir plus de détails sur les transformes dans ce blog).

Mesure de similarité

Similarité Jaccard (similarité syntaxique)

C’est la forme la plus basique de calcul de similarité entre deux textes car elle ne nécessite pas d’avoir une représentation numérique des textes. L’indice de Jaccard est mesuré en divisant le nombre de mots partagés par les deux textes par le nombre total de mots. Cependant, plus les documents sont longs plus le nombre de mots partagés sera élevé sans pour autant que ces documents soient similaires.

Distance euclidienne

C’est la distance entre deux vecteurs représentants les documents. Cette mesure est utilisée spécifiquement par l’algorithme K-means.

Similarité cosinus

A la différence de la distance euclidienne, c’est l’angle entre les vecteurs et non la taille des vecteurs qui est pris en compte, ce qui a pour effet de réduire l’impact de la taille des documents sur le calcul de similarité. Cette méthode est la plus couramment utilisée car simple et efficace d’un point de vue computationnel.

Comparaison de plusieurs approches de calcul de similarité

Le but de l’exercice consiste à retrouver dans un corpus de 400 documents, les 5 documents les plus similaires à un document donné qui constitue notre requête. Des utilisateurs experts ont classé les documents de test en 8 catégories et 36 sous-catégories. On considère que des documents sont similaires s’ils appartiennent à la même catégorie et sous-catégorie que le document requête.

Nous avons essayé plusieurs combinaisons de représentation vectorielle et mesure de similarité cependant c’est l’étape de vectorisation de texte qui est déterminante pour l’efficacité de la recherche de documents similaires. Nous nous limitons donc à comparer les différentes représentations vectorielles en utilisant la similarité cosinus comme mesure de similarité avec l’algorithme kNN pour retrouver les 5 documents les plus proches du document requête.

Les différentes représentations vectorielles implémentées sont  les suivantes:

• TF-IDF
• TF-IDF + LSA
• Word embeddings – fastText (source: Word vectors for 157 languages · fastText)
• Word embeddings – fastText amélioré (fine-tuned) en intégrant des données du domaine
• Word embeddings – Word2vec entrainé sur des données du domaine uniquement

Première évaluation des différents word embeddings

Pour nos premiers tests, nous utilisons des word embeddings libre d’accès et entrainés sur des millions de documents. Néanmoins, les textes utilisés pour entrainer ces modèles sont éloignés de notre domaine et les représentations produites pour des textes contenant un vocabulaire propre à la sécurité sociale sont moins précises.

En recherchant les mots les plus similaires (proches dans l’espace vectorielle) aux mots « cotisation » et « Dmfa » on obtient les résultats suivants :

Ces résultats illustrent les spécificités de chacun des modèles Word2Vec et fastText : le modèle fastText capture les différentes formes morphologiques des mots tandis que le modèle Word2Vec capture les relations entre les mots apparaissant dans un même contexte. Autre point d’attention, pour le mot « cotisation » les mots similaires donnés par le modèle Word2Vec tels que rafp et csg-crds sont parfaitement logiques dans un contexte français mais ne sont pas d’utilité dans le contexte de la sécurité sociale belge.

Avec la librairie python Gensim, il est possible d’entrainer ou d’affiner des modèles de word embeddings et nous disposons pour cela d’un corpus très limité de 3500 documents. Nous utilisons ce corpus pour affiner le modèle fastText précédemment décrit et pour entrainer « from scratch » un modèle word2vec ce qui donne les résultats suivants.

Le modèle fastText s’est amélioré, le terme « dmfa » a une représentation vectorielle cependant les termes similaires à ce terme se réfèrent pour la plupart à des institutions de sécurité sociale étrangères. Quant au modèle Word2Vec, bien qu’ayant été entrainé avec très peu de textes, on constate qu’il donne déjà des résultats satisfaisants.

Évaluation des différentes représentations de textes sur les documents de test

Les différentes représentations vectorielles implémentées sont les suivantes:

• TF-IDF
• TF-IDF + LSA
• Word embeddings – fastText (source: Word vectors for 157 languages · fastText)
• Word embeddings – fastText amélioré (fine-tuned) en intégrant des données propres à notre domaine
• Word embeddings – Word2Vec entrainé avec des données du domaine uniquement

Pour chacune d’elles, on recherche les 5 documents les plus similaires d’un document requête et on calcule la proportion de documents similaires qui appartiennent à la même catégorie et la même sous-catégorie que ce document requête.

Les modèles TF-IDF et Word2Vec sont ceux qui donnent les meilleurs résultats. Les documents retrouvés par les deux modèles appartiennent tous à la bonne catégorie et sous-catégorie cependant seuls 2 documents sur 5 sont communs aux deux sets de résultats (TF-IDF et Word2Vec). En analysant de près les résultats, on constate que le modèle Word2Vec a privilégié des documents se référant à des entreprises de restauration. Le document requête concerne lui aussi une entreprise de restauration.

Conclusion

Nous avons vu comment déterminer si deux textes sont similaires. On constate que le choix du type de représentation vectorielle est important pour cette tâche. Sans surprise les modèles qui intègrent la sémantique d’un mot donnent, dans notre use case, des résultats plus pertinents. Ils existent des représentations type word embedding prêtes à l’emploi (Word2Vec, fastText, GloVe). Cependant si on traite des textes qui relèvent d’un domaine ayant un vocabulaire spécifique, il est préférable d’entrainer son propre word embedding « from scratch ».

SDV (Synthetic Data Vault) est une bibliothèque open source populaire permettant de générer un nouvel ensemble de données synthétiques modélisé sur un ensemble de données spécifié. Il s’intègre facilement dans un flux de traitement de données basé sur Python. La bibliothèque est toujours en version alpha et en développement actif. Elle est gratuite et librement disponible sous licence MIT.

Natural Language Generation (NLG) gaat over het automatisch creëren van correcte en inhoudelijk betekenisvolle tekst. Dit kan vandaag ook met behulp van Artificiële Intelligentie, net zoals men realistische foto’s en zelfs video’s kan namaken. Wat is de stand van zaken van deze technologie, wat zijn de opportuniteiten en de gevaren? Artificiële Intelligentie is echter niet zaligmakend, en we bekijken in dit webinar ook alternatieven voor het automatisch genereren van tekst die eenvoudiger of robuuster kunnen zijn.

We stofferen alles met voldoende voorbeelden en ervaringen geput uit experimenten die Smals Research het voorbije jaar heeft uitgevoerd. Tot slot peilen we naar toepassingen binnen een overheidscontext. We hopen u met dit webinar te inspireren om de mogelijkheden van NLG binnen uw organisatie te ontdekken.

Presentation

Natural Language Generation (NLG) gaat over het automatisch creëren van correcte en inhoudelijk betekenisvolle tekst. Dit kan vandaag ook met behulp van Artificiële Intelligentie, net zoals men realistische foto’s en zelfs video’s kan namaken. Wat is de stand van zaken van deze technologie, wat zijn de opportuniteiten en de gevaren? Artificiële Intelligentie is echter niet zaligmakend, en we bekijken in dit webinar ook alternatieven voor het automatisch genereren van tekst die eenvoudiger of robuuster kunnen zijn.

Le Natural Language Generation (NLG) ou, en français, la Génération Automatique de Textes (GAT), consiste en la création automatique de textes corrects et significatifs. Aujourd’hui, cela peut également se faire au moyen de l’intelligence artificielle, tout comme il est possible de recréer des photos et même des vidéos réalistes. Où en est cette technologie, quels sont ses dangers et opportunités ? L’intelligence artificielle n’est toutefois pas la panacée. Lors de ce webinaire, nous examinons également les alternatives à la génération automatique de textes qui peuvent être plus simples ou plus robustes.

Presentation

Leximancer est un outil commercial qui dans une grande quantité de texte, identifie les sujets les plus importants, les regroupe en concepts connexes, et visualise les relations entre eux. L’utilisateur peut affiner les résultats à chaque étape intermédiaire. Parmi les domaines d’application possibles se trouvent la criminalistique ou l’inspection numérique, l’analyse des questionnaires à grande échelle ou encore les revues de presse/littérature.

RosaeNLG est un moteur de génération de langage naturel, construit sur le moteur de modèles Pug pour node.js. Dans RosaeNLG, vous pouvez définir des modèles pour convertir les objets JSON en une description en langage naturel. RosaeNLG utilise des dictionnaires pour appliquer les règles grammaticales correctes pour les articles, les conjugaisons, les inflexions et les cas. Actuellement, 5 langues sont supportées : anglais, français, allemand, espagnol et italien.

Bovenstaand paragraafje werd geschreven door een GPT-2 taalmodel dat in het Nederlands werd getraind door de Gentse startup ML6. Volgens hun taalmodel is dit een plausibele aanvulling op de titel van dit stuk. En het mag gezegd: qua stijl, woordkeuze en coherentie tussen opeenvolgende zinnen is dit zeker niet slecht. Of het ook inhoudelijk consistent en betekenisvol is, is nog iets anders: de aandachtige lezer besluipt toch nog een gevoel van “woordenbrij”, al is het maar omdat een echt correcte tekst zou verwijzen naar de verhalen als “Het eerste” en “Het tweede”.

Dit geeft wel een idee van waar we vandaag staan qua Natural Language Generation (NLG) in het Nederlands. De agile manier waarop ML6 dit heeft uitgewerkt is trouwens een uitstekende illustratie van wat we in een eerdere blogpost al concludeerden: het tweaken van bestaande NLP systemen met je eigen datasets en voor je eigen doeleinden is het afgelopen jaar veel gemakkelijker geworden – al blijft beschikbaarheid van voldoende grote datasets wel een voorwaarde voor degelijke resultaten, en dat is moeilijker voor minder courante talen.

De geschiedenis van tekstgeneratoren gaat een heel eind terug. De Turing Test vereist al dat een computer een realistisch klinkend antwoord op een gestelde vraag moet kunnen samenstellen. De eerste chatbots waren, ondanks hun eenvoud, opvallend goed in staat om een conversatie te simuleren. Recenter zagen verschillende generatoren voor langere teksten gaande van academische papers tot new-age bullshit het licht. Op basis van de laatste evoluties in deep learning voor Natural Language Processing, is het aansturen van je eigen adventure game slechts een van de vele creatieve toepassingen. Met wat goede wil is ook automatische vertaling een vorm van NLG – we genereren immers een equivalent van de oorspronkelijke tekst, maar dan in een andere taal. En als we code ook als tekst beschouwen, valt het generatieve luik van Low Code Application Platforms er ook onder.

Hier kijken we naar twee categorieën van NLG systemen die fundamenteel verschillen van elkaar en op een heel andere manier tot resultaten komen. De eerste categorie moet het hebben van templates en grammaticale regels, en produceert een strikt deterministische output. De tweede categorie is gebaseerd op machine learning met een scheut randomness, en benadert zo meer wat we “creatief schrijven” zouden kunnen noemen. We beperken ons hier louter tot het genereren van tekst, waarbij je al weet wat je zou willen zeggen of welke richting je uit wil. Het begrijpen van vragen of het opzoeken van informatie, zoals bij chatbots en question answering systemen, kan aan het genereren van een tekst voorafgaan, maar zijn afzonderlijke concepten die buiten de scope van dit artikel vallen.

Grammaticale template engines

De “klassieke” manier om teksten te genereren is met templates. De meesten onder ons gebruiken die wel eens in Word en Powerpoint, en wie evenementen organiseert heeft misschien ervaring met MailChimp. Een template is zoals een formulier: een deel is vooraf geschreven en ligt vast, de rest moet je nog aanvullen met eigen gegevens of inhoud. Die inhoud kan je zelf schrijven, of halen uit een database. Maar zo’n rechtstreekse copy-paste uit een database heeft beperkingen: dat wat je invoegt moet immers ook grammaticaal passen in de omliggende vaste tekst. Dat wordt moeilijker als we in detail willen gaan of enigszins willen variëren.

Retailers of grote online handelaars bieden soms duizenden producten aan op hun website, elke dag verschijnen en verdwijnen er dingen uit het assortiment. Voor elk product moet een wervend tekstje op de website komen zodra het aan de database wordt toegevoegd. Om niet telkens dezelfde tekst te doen verschijnen, wil je “met onze blauwe suède schoenen” al eens afwisselen met “Deze schoen is blauw en gemaakt van suède,” en hetzelfde moet ook werken voor “rode lederen laarzen” of “grote Amerikaanse koelkasten“.

Het doel van zulke data-to-text NLG is om op basis van een database met mogelijk gevarieerde inhoud, toch correcte teksten te kunnen genereren. Daarvoor moeten voornaamwoorden, meervouden, verbuigingen en vervoegingen flexibel aangepast kunnen worden al naargelang het beschreven object en haar eigenschappen. In het Frans moet het accord de l’adjectif correct zijn, in het Duits de naamvallen, in het Nederlands de lidwoorden. Idealiter wordt er ook elegant met ontbrekende gegevens omgegaan, kunnen we de zinsvolgorde al eens veranderen, en tegelijk zorgen dat we ook niets onnodig herhalen.

Echte NLG template engines maken gebruik van een woordenboek en een grammaticale rule engine om dat allemaal correct te kunnen genereren. Verschillende bedrijven zijn actief in deze markt, vaak voorzien zij grafische interfaces en integraties die het gebruiksgemak heel wat kunnen verhogen. Er zijn ook open-source oplossingen waaronder SimpleNLG, RiTa en RosaeNLG. Een NLG template in die laatste ziet eruit als volgt:

| #[+subjectVerbAdj('enquête', {verb: 'être', tense: 'PASSE_COMPOSE', aux: 'AVOIR'}, 'ouvert', {det:'INDEFINITE'})]
| concernant
| #[+value('réclamation', {det:'POSSESSIVE', adj: 'contesté', adjPos: 'AFTER', number:'P' })]

Dit genereert: “Une enquête a été ouverte concernant ses réclamations contestées“. De meeste parameters in dit voorbeeld, zoals de woorden ‘enquête‘, ‘ouvert‘, ‘réclamation‘, ‘contesté‘, kunnen vlot vervangen worden door andere woorden (van dezelfde woordsoort) en dan zal deze template een even correcte zin produceren. Parameters zoals werkwoordstijd en type voornaamwoord zijn eveneens gemakkelijk aanpasbaar.

Het gebruik van NLG op basis van grammaticale template engines heeft een paar duidelijke voordelen:

• De hoge parametriseerbaarheid maakt dat je met 1 goed ontwikkelde NLG template teksten kan genereren over relatief heterogene collecties van gegevens.
• Je hebt volledige controle over de output, alle output is gegarandeerd conform het template.
• Slim gebruik van synoniemen, alternatieve beschrijvingen, wisselende zinsvolgorde, gelinkte voornaamwoorden etc. kunnen veel variatie van de output opleveren.

Het belangrijkste nadeel is dat zulke grammaticale templates erg snel erg complex worden. Als ook variatie en synoniemen ingebouwd moeten worden, is zo’n template al snel vele malen langer dan de tekst die ze genereert. NLG templates ontwikkelen die goed geparametriseerd en breed inzetbaar zijn, is tijdrovend secuur werk en vereist bovendien een uitstekende kennis van grammatica. Als een klassieke substitutie-oplossing waarin je slechts hoeft te copy-pasten al tot een voldoende kwalitatief resultaat leidt, dan bieden NLG templating engines weinig meerwaarde.

Creatief schrijven met neurale netwerken

Een volledig andere manier om teksten te genereren werd mogelijk dankzij machine learning en met name deep learning, waarmee op basis van enorme hoeveelheden bestaande tekst (denk ter grootte van een paar keer de volledige wikipedia) een taalmodel getraind kan worden dat “weet” welke woorden in welke context het meest geschikt zijn. Zulke taalmodellen “voorspellen” het meest plausibele volgende, of ontbrekende, woord. Doe dat vele keren na elkaar en je genereert uiteindelijk ook een tekst.

Kleine taalmodelletjes zitten al een tijdje in onze smartphone, waar toetsenbord-apps suggesties geven voor het volgende woord in een tekstbericht. De taalmodellen van vandaag zijn vele malen groter en kunnen veel beter rekening houden met context, zeker sinds de opkomst van de zogenaamde transformer architectuur. Die zit achter verschillende taalmodellen die furore hebben gemaakt in de laatste paar jaren, zoals BERT, T5 en GPT. GPT-3 is dusdanig groot dat eenzelfde model inzetbaar is voor verschillende taken. De geselecteerde derde partijen die van OpenAI aan de slag mochten met het model maakten al indrukwekkende applicaties.

Het kost heel wat geld, hardware en tijd om zelf zulke taalmodellen te trainen. Wie niet zulke financiële resources heeft, moet vertrekken van een bestaand model dat ter beschikking wordt gesteld door de grote spelers, en trachten dat te verfijnen. Daarmee ben je wel afhankelijk van de dataset die gebruikt werd om het originele model te trainen. Met die trainingsdata, die niet altijd openlijk beschikbaar is, zijn verschillende problemen. Ze zijn deels gescraped van allerlei internetfora, wat maakt dat er nogal wat persoonlijke gegevens in terechtkomen die kunnen uitlekken. Het overgenomen discours van minder appetijtelijke fora leidt dan weer tot sterke bias in de gegenereerde teksten.

Mede daarom wordt de toegang tot GPT-3 angstvallig bewaakt door OpenAI. Voorganger GPT-2 is wel vrij beschikbaar en de oefening om dat ook eens te trainen in het Nederlands werd al gedaan door onder andere de Universiteit van Groningen [code] en de Gentse AI-startup ML6 [code en demo]. Beiden maken andere keuzes voor de manier waarop ze trainen, en gebruiken bovendien verschillende datasets: het Groningse GroNLP model is getraind op voornamelijk wikipedia, e-books en nieuwswebsites, terwijl ML6 zich baseert op OSCAR, een subset van de CommonCrawl webscraping dataset. Beide hebben hun eigen voor- en nadelen: tekst gegenereerd door het GroNLP model gaat al snel lijken op een stationsromannetje, terwijl de OSCAR dataset heel wat bankrekeningnummers, bestaande adresgegevens en zelfs erotiek bevat.

GPT taalmodellen werken als volgt: men geeft een aanzet (een prompt) en laat dan het model vrij aanvullen. Dat aanvullen kan je verder vrij weinig sturing geven, je draait bij wijze van spreken gewoon de woordenkraan open. Eventueel kan je een gebruiker laten kiezen uit verschillende mogelijkheden, of de output alsnog filteren (als je bepaald taalgebruik wil weren), maar dat moet je zelf toevoegen.

Een fictieve biografie van ondergetekende uit een parallel universum, gegenereerd door GroNLP, klinkt als volgt (tekst in vet gegeven als aanzet):

Joachim Ganseman is informaticus en heeft gestudeerd aan de Universiteit van Antwerpen. Levensloop. Hij begon zijn opleiding in het Koninklijk Belgisch Staatsinstituut voor Landbouw (KOCO) te Brussel, waar hij ook een landbouwdiploma kreeg. Hij werkte daar onder andere als assistent-accountant bij Yves Van den Bucket uit 1988 tot 1997. In 1996 was hij adjunct-adjunct-directrice met wie hij contact zocht tussen verschillende Europese landen over hun beleid inzake voedselveiligheid.

Dezelfde aanzet bij ML6 genereert de volgende biografie – ik heb duidelijk een carrière in de agro-sector gemist:

Joachim Ganseman is informaticus en heeft gestudeerd aan de Universiteit van Antwerpen.  Als onderzoeker werkte hij veel in het bedrijf van de jonge kunstenaar en producent van het meest uiteenlopende werk: de tuin, het terras, de terras- en het terrasrestaurant. Tijdens zijn werkzaamheden werd hij de expert en de eerste specialist in het werk van Ganseman. Hij specialiseerde zich in de tuinontwerp. Zijn onderzoek naar tuinontwerp is gebaseerd op de vele verschillende tuinontwerpen en is te vinden op diverse sites zoals: websites, mobiele applicaties, apps en sites van partijen.

De repetitiviteit blijft moeilijk te controleren. Je wil dat de output bij hetzelfde thema blijft maar dat geeft een risico op in herhaling vallen, terwijl veel vrijheid dan weer riskeert dat de tekst plots een heel andere richting uitgaat. Deze Nederlandstalige GPT-2 modellen zijn ook nog relatief klein, de context van de aanzet is vaak na een drietal zinnen al vergeten en dan zie je soms rare sprongen in de thematiek gebeuren.

Uit de aanzet die je geeft zal het model bepaalde aannames afleiden over de stijl, taalgebruik en inhoud van wat moet volgen. Zo genereer je met hetzelfde model zowel deze serieus klinkende (inhoudelijk absurde) quasi-wettekst, als het daaropvolgende (oneetbare) quasi-recept:

• Artikel 478, eerste lid, Gerechtelijk wetboek bepaalt dat degene die bij of krachtens deze wet wordt vervolgd wegens een strafbaar feit in de eerste aanleg bij de aanvang van de terechtzitting is verschenen, onverwijld zal worden vervangen door een gewezen rechter-commissaris.
• 2 eieren , 500g boter , 500g suiker , 100g bloem , 1 stokje vanille. Recept: Voeg de kaneel, kaneel en vanille toe aan de mix, voeg nog een beetje vanille, voeg 1 theelepel vanille toe. Meng met een lepel de suiker en klop door tot hij zacht genoeg is om dit een eierdooistokje te maken. Voeg vervolgens de melk, kaneel en vanille toe en voeg dit nog een beetje bij het product. Klop alles goed door elkaar en bestrooi de mix erover.

Via een goed doordachte prompt kunnen we het model dus heel verschillende output laten produceren. Voor echt gespecialiseerde taken zoals het genereren van een machinevertaling of programmeercode, zal het finetunen van het model op een speciaal daarvoor gemaakte dataset misschien wel nog robuustere resultaten geven, zoals bij deze omzetting van Engelse tekst naar SQL queries.

Conclusie

Het gebruik van NLG templating engines is aangewezen wanneer er een duidelijke meerwaarde is ten opzichte van de klassieke substitutie-templates (copy-paste), en wanneer de gegenereerde teksten bedoeld zijn voor de buitenwereld. Toepassingen zijn onder andere:

• Het maken van regelmatige tekstuele rapporten of notificaties over constant binnenstromende gegevens, zoals weerberichten, de financiële markten, de sportuitslagen, maar ook statusrapporten van IT systemen, sensorgegevens van IoT devices, etc.
• Het aanmaken van sterk gepersonaliseerde teksten, over bvb. de inhoud van een winkelmandje, of van een persoonlijk dossier, hetgeen per gebruiker erg kan verschillen.
• Het maken van gevarieerde teksten voor omvangrijke productdatabases bij grote retailers, deelplatformen etc.

Het gebruik van deep learning taalmodellen voor het genereren van tekst is veel riskanter. Zeker als de training van die modellen niet volledig onder eigen controle is gebeurd, is een manuele validatie en correctie van de output altijd aangewezen. Je accepteert immers ook niet blind de suggesties van je smartphonetoetsenbord. Deze aanpak vindt dus vooral intern zijn nut, binnen de organisatie, op plaatsen waar creatief schrijven vandaag veel tijd opeist. We denken onder andere aan:

• Assistentie bij het schrijven of als tool tegen writer’s block, door het suggereren van plausibele aanvullingen.
• Het aanmaken van realistisch ogend maar toch fictief opleidingsmateriaal. Dit is nuttig wanneer het niet wenselijk zou zijn dat personen in opleiding echte dossiers inkijken, bvb. omwille van privacyredenen.
• Het maken van examenvragen.
• Het maken van (tekstuele) synthetische datasets – mits kwaliteitscontrole, filtering en validatie van de output.
• In UX analyse, voor het verzinnen van willekeurige persona’s, fictieve biografieën en gebruiksscenario’s.

De kwaliteit van de vandaag beschikbare Nederlandstalige generatieve modellen, blijft nog wel wat achter bij dat wat de media haalt in het Engels – wat ook De Standaard opmerkte toen zij aan het testen gingen. Om dat ten gronde te verbeteren zal ook werk gemaakt moeten worden van zorgvuldiger samengestelde Nederlandstalige trainingsdatasets.

Voor specifieke toepassingen zoals codegeneratie, verwachten we dat gespecialiseerde modellen relatief snel hun weg zouden kunnen vinden in de bestaande professionele IDEs. Microsoft heeft recent aangekondigd een deel van de functionaliteit van GPT-3 in te bouwen in hun Power Apps low-code platform, en Github lanceert met CoPilot een “AI Pair Programmer” als plugin voor de Visual Studio Code editor. Ongetwijfeld zullen anderen volgen, en zo vinden we suggesties van krachtiger tekstgeneratoren misschien binnenkort al terug als plugin in de gangbare developer tools.

______________________

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.

Natural Language processing technologieën gebruiken we ondertussen dagelijks, in de vorm van chatbots en virtuele assistenten – denk Siri of Google Assistant – of in tools gaande van autocomplete tot automatische vertaling. In het Engels werkt dat vrij goed; Nederlands blijft moeilijker maar er is toch ook snelle vooruitgang. Hoe kan je nu zelf een systeem maken voor herkenning van entiteiten in Nederlandstalige documenten? Met een focus op tekst (spraak is voor een andere keer), werken we een praktisch voorbeeld uit waarvoor we gebruik maken van openlijk beschikbare documenten en open source componenten.

Les technologies de traitement du langage naturel sont désormais utilisées quotidiennement, sous la forme de chatbots et d’assistants virtuels – pensez à Siri ou Google Assistant – ou dans des outils allant de l’autocomplétion à la traduction automatique. En anglais, cela fonctionne assez bien; le néerlandais reste plus difficile mais les progrès sont rapides. Alors comment faire un système de reconnaissance des entités dans les documents néerlandais ? En nous concentrant sur le texte (la parole est pour une autre fois), nous élaborons un exemple pratique en utilisant des documents librement disponibles et des composants open source.

Presentation

• 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.