Les agents IA ont le vent en poupe. Mais que sont-ils exactement ? Que peuvent-ils nous apporter et à quoi devons-nous faire attention ? Cet article de blog offre un aperçu des possibilités, des risques et des applications concrètes des agents IA.

Que sont les agents IA?

On peut décrire les agents IA comme des entités logicielles autonomes ou semi-autonomes qui utilisent l’IA pour percevoir, prendre des décisions, exécuter des actions et atteindre des objectifs. Tout comme une agence de voyage qui organise et réserve tout un voyage de manière indépendante en fonction de vos souhaits, les agents IA illustrent le concept d'”agency” : la capacité de prendre des décisions et d’agir de manière indépendante dans un contexte numérique.

Voici les caractéristiques typiques des agents IA :

• Autonomie : exécuter des tâches de manière indépendante, avec peu ou pas d’intervention humaine.
• Objectifs complexes : être capable de déterminer efficacement les étapes intermédiaires pour atteindre des objectifs complexes.
• Environnements complexes : la capacité à s’adapter à des circonstances changeantes et à des imprévus, tels que des objectifs modifiés, de nouvelles informations ou des outputs inattendus d’un système externe.

Les caractéristiques ci-dessus s’appliquent à des degrés divers aux agents IA, ce qui signifie que l'”agency” doit être considérée comme un spectre : plus ces caractéristiques sont présentes, plus un agent est capable d’effectuer des tâches complexes de manière autonome.

L’anatomie des agents IA

Les agents IA se composent généralement de plusieurs éléments qui, ensemble, rendent possible leur comportement intelligent :

• Le modèle d’IA pour le raisonnement : la capacité à planifier une série d’actions pour atteindre des objectifs et à prendre des décisions même avec des données incomplètes. On observe ici une tendance des “chat models” classiques vers des “reasoning models” qui sont mieux à même de découper les problèmes en étapes plus petites, de corriger les erreurs et d’essayer plusieurs stratégies.
• La base de connaissance : connaissances spécifiques à un domaine, souvent obtenues grâce à des techniques de Retrieval-Augmented Generation (RAG).
• La mémoire : capacité à mémoriser des informations sur les étapes ou interactions précédentes. Cela peut être à court terme (au cours d’une session) ou à plus long terme (sur plusieurs sessions). La mémoire permet aux agents IA de fournir des réponses cohérentes, de se souvenir des décisions précédentes et de rendre l’interaction plus fluide.
• Les outils : des outils tels que les moteurs de recherche, les bases de données ou les API peuvent être reliés à de grands modèles de langage (LLM). Sur la base d’une description des outils, le modèle peut alors déterminer quel outil doit être utilisé pour effectuer une tâche donnée, ainsi que les paramètres d’entrée.

Ces différents composants sont configurés et orchestrés avec des outils dédiés comme LangGraph, LlamaIndex, CrewAI, etc.

Les agents IA peuvent être activés de différentes manières. Souvent, c’est par le biais d’un input textuel ou vocal, comme dans une interface de chat. Mais un trigger peut également provenir automatiquement d’un processus : par exemple, la création d’un nouveau fichier, la réception d’un e-mail ou une modification dans une base de données. Cette flexibilité rend les agents IA utilisables dans des workflows très variés.

Une évolution intéressante est la “multi-agent collaboration” : plusieurs agents IA travaillent ensemble, chacun avec sa propre spécialisation ou tâche. Grâce à la communication mutuelle et à la répartition des tâches, ils peuvent traiter des problèmes complexes plus efficacement qu’un agent unique. Pensez par exemple à une équipe d’agents qui rédigent ensemble un rapport, où un agent collecte les données, un autre les analyse et un troisième rédige le rapport.

Bien que les agents IA deviennent toujours plus autonomes, la présence d’un “human in the loop” reste essentielle. En effet, une supervision humaine permet non seulement de détecter rapidement les erreurs ou les comportements indésirables, elle renforce également la confiance et la fiabilité du système, notamment dans les applications critiques où la précision et l’éthique jouent un rôle majeur.

Avantages et applications

Nous avons établi de quels éléments un agent IA est composé. Voyons maintenant quels avantages il peut offrir :

• Automatisation des tâches : les agents IA peuvent effectuer de manière autonome des tâches répétitives et chronophages, ce qui permet aux collaborateurs de se concentrer sur des tâches plus stratégiques.
• Assistance à la prise de décision : par l’analyse rapide de grandes quantités de données et la fourniture d’informations pertinentes, les agents IA peuvent aider à prendre des décisions plus éclairées et mieux fondées.
• Interaction intelligente avec les utilisateurs : les agents IA peuvent communiquer de manière naturelle et contextuelle par texte ou par voix, ce qui permet des interactions plus fluides et plus personnalisées avec les utilisateurs finaux.

Les domaines d’application suivants pourraient bénéficier d’une valeur ajoutée potentielle grâce aux agents IA :

• Environnements utilisateurs : dans les environnements orientés vers le client, les agents IA peuvent être utilisés pour des helpdesks automatisés, des chatbots ou des recommandations personnalisées.
• Traitement de l’information : les agents IA sont particulièrement adaptés à l’analyse et à la structuration de grandes quantités d’informations. Ils peuvent résumer des documents, détecter des tendances ou extraire des informations pertinentes à partir de sources de données complexes.
• Applications créatives : dans les secteurs créatifs, les agents IA peuvent aider à rédiger des rapports, générer des textes pour les réseaux sociaux ou même participer à la conception de nouvelles campagnes. Ils font alors office de sparring-partner créatif ou d’assistant productif.

Défis et risques

Bien que cette technologie dispose d’un potentiel considérable, il est essentiel de prendre en compte certains points importants :

• Imprévisibilité : les agents IA peuvent être imprévisibles en raison de leur nature non déterministe ; ils fournissent parfois des résultats inattendus ou incohérents, difficiles à reproduire et à comprendre.
• Problèmes liés aux LLM : les modèles de langage peuvent “halluciner”, faire des erreurs de planification ou de raisonnement, et faire de mauvais choix lors de la sélection d’outils ou de l’identification d’entités.
• Debugging complexe : en raison de la nature “black box” des modèles de langage, il est difficile de déterminer pourquoi un agent a pris une décision particulière. Plus l’agent IA est complexe, plus il est difficile d’identifier la cause exacte des erreurs. Des outils de traçage spécialisés ne sont donc pas un luxe.
• Coût et lenteur : particulièrement dans les situations où la planification et la replanification sont continues ou lorsque l’agent doit effectuer de nombreuses étapes, le résultat final peut se faire attendre et les coûts liés à l’utilisation de grands modèles de langage peuvent augmenter.
• Défis liés à la production : la création d’un premier prototype demande généralement peu d’efforts. Le véritable défi réside dans la mise en œuvre fiable et performante dans un environnement de production réel.

Etant donné que, dans de nombreux cas, nous ne pouvons pas nous fier aveuglément aux résultats des agents IA, une intervention humaine est encore souvent nécessaire pour garantir la fiabilité et la qualité.

Examples pratiques

Voici quelques exemples concrets d’agents IA illustrant les possibilités offertes :

1. Research agent : on voit émerger de plus en plus de systèmes destinés à effectuer des recherches, qui ne se limitent pas aux outils payants des grands fournisseurs (cf OpenAI Deep Research), mais comprennent également des alternatives ouvertes. L’objectif d’un tel agent de recherche est d’obtenir rapidement des informations sur un sujet donné. L’agent rédige des rapports de manière autonome, avec une contribution humaine pour la structure du rapport et la possibilité d’ajuster l’output. Un web search est utilisé comme outil pour collecter des informations sur le sujet donné et sur les thèmes spécifiques de chaque section. On utilise le reasoning pour planifier la structure du rapport, réfléchir aux sections générées et suggérer des questions de follow-up afin de poursuivre l’analyse à l’aide de l’outil de recherche web.
2. Agentic IDE: l’IA agentielle fait de plus en plus son apparition dans le développement de logiciels. Des outils tels que GitHub Copilot “agent mode” font appel à des techniques d’IA non seulement pour fournir des suggestions pendant la programmation, mais également pour accomplir des tâches complètes de manière autonome. Pensez par exemple à la génération de code, à la refactorisation de plusieurs fichiers, à la rédaction de scripts de test et même à la correction automatique d’erreurs dans le cadre d’une approche itérative par essais et erreurs. L’agent comprend l’objectif global de la tâche, exécute les actions par étapes et reformule son approche si nécessaire, tout comme le ferait un programmeur humain. Il agit ainsi comme un assistant de programmation intelligent qui permet aux développeurs de travailler plus rapidement et de manière plus cohérente.
3. Smart search : chez Smals, nous explorons les possibilités d’une fonction de recherche intelligente dans le contexte d’un environnement de travail. Dans la situation actuelle, les utilisateurs doivent naviguer parmi plus de 30 critères de recherche pour obtenir un résultat satisfaisant. L’objectif de cette expérience est de rendre la recherche beaucoup plus conviviale en permettant aux utilisateurs de formuler leur requête en langage naturel. L’agent peut désambiguïser la question (s’agit-il par exemple d’une entité ou d’une personne ?) et convertir ensuite la question désambiguïsée en une requête JSON structurée permettant d’appeler une API de recherche.

Quand (ne pas) l’utiliser?

Les agents IA peuvent être intéressants dans des situations où les solutions traditionnelles et déterministes ne suffisent pas. Pensez à des contextes impliquant de grandes quantités de données non structurées, en langage naturel ou avec des conditions changeantes où un comportement adaptatif est souhaitable. Les agents IA peuvent également apporter une valeur ajoutée dans le cadre de prises de décision complexes ou en tant qu’assistants dans des tâches comportant de nombreuses variables.

La checklist ci-dessous peut vous aider à déterminer si un agent IA est approprié :

Quand un agent IA est-il une bonne idée ?

La tâche est complexe et difficile à formaliser complètement

Le travail implique l’utilisation du langage naturel ou de données non structurées

La tâche est fréquente et prend actuellement beaucoup de temps

Le contexte change régulièrement ou est incertain

Il y a une valeur ajoutée évidente (gain de temps, meilleure qualité, évolutivité)

Quand vaut-il mieux s’abstenir ?

✘ La tâche exige une grande précision et une absence totale d’erreurs (par exemple, dans le domaine médical ou financier)

✘ Le domaine est strictement réglementé ou contient des données personnelles sensibles

✘ La tâche nécessite une intuition humaine, de l’empathie ou des considérations éthiques

✘ La tâche est simple et peut être facilement résolue à l’aide de systèmes classiques basés sur des règles

Attention : les agents IA ne sont pas toujours tenus de fonctionner de manière totalement autonome. Dans la plupart des cas, leur efficacité est maximale dans un rôle d’assistance, comme un copilote intelligent qui prépare des analyses, émet des suggestions ou effectue un travail préparatoire, tandis que la responsabilité finale reste entre les mains de l’homme.

Conclusion

Les agents IA ont clairement le vent en poupe. Ils promettent des gains d’efficacité considérables et de nouvelles possibilités dans des domaines aussi variés que le service à la clientèle, la recherche, le développement de logiciels et la gestion de l’information. Grâce à leur capacité de raisonnement, à leur accès aux connaissances et à l’utilisation d’outils, ils peuvent atteindre un haut niveau d’autonomie.

Il est toutefois important d’aborder cette technologie avec la prudence nécessaire. Les agents IA sont encore en cours de développement et sont confrontés à des défis fondamentaux en matière de fiabilité, de transparence et de performance. Dans de nombreux cas, l’intervention et la supervision humaines restent indispensables.

Quiconque expérimente aujourd’hui les agents IA acquiert des connaissances précieuses sur la manière dont ces systèmes peuvent être intégrés dans les processus et les organisations. Les années à venir seront déterminantes pour l’évolution de cette technologie. Peut-elle passer du statut de gadget à un rôle à part entière dans le fonctionnement quotidien des organisations ? Les agents IA ont le potentiel d’apporter une valeur ajoutée évidente, à condition qu’ils soient utilisés à bon escient.

Ce post est une contribution individuelle de Bert Vanhalst, IT consultant chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

AI agents zijn volop in opmars. Maar wat zijn het precies? Wat kunnen ze voor ons betekenen, en waar moeten we voor oppassen? Deze blogpost geeft een overzicht van de mogelijkheden, risico’s en concrete toepassingen van AI agents.

Wat zijn AI agents?

AI agents kunnen omschreven worden als autonome of semiautonome software-entiteiten die AI gebruiken om waar te nemen, beslissingen te nemen, acties uit te voeren en doelen te bereiken. Net als een reisbureau dat op basis van jouw wensen zelfstandig een hele reis samenstelt en boekt, illustreren AI agents het concept van “agency”: het vermogen om zelfstandig beslissingen te nemen en te handelen binnen een digitale context.

Dit zijn de typische kenmerken van AI agents:

• Autonomie: zelfstandig taken uitvoeren met weinig tot geen menselijke tussenkomst.
• Complexe doelen: tussenstappen efficiënt kunnen bepalen om complexe doelen te kunnen bereiken.
• Complexe omgevingen: het vermogen om zich aan te passen aan veranderende omstandigheden en onverwachte zaken, zoals bijgestuurde doelen, nieuwe informatie of onverwachte output van een extern systeem.

De bovenstaande kenmerken zijn in mindere of meerdere mate van toepassing op AI agents, wat maakt dat “agency” gezien moet worden als een spectrum: hoe sterker deze eigenschappen aanwezig zijn, hoe beter een agent in staat is om complexe taken autonoom uit te voeren.

De anatomie van AI agents

AI agents bestaan doorgaans uit meerdere bouwstenen die samen hun intelligent gedrag mogelijk maken:

• Reasoning model (redeneervermogen): het vermogen om een opeenvolging van acties te plannen om doelstellingen te bereiken, en beslissingen kunnen nemen zelfs met onvolledige gegevens. Hier zien we een trend van de klassieke “chat models” naar “reasoning models” die beter in staat zijn om problemen op te splitsen in kleinere stappen, fouten kunnen verbeteren en meerdere strategieën kunnen uitproberen.

• Knowledge base: domein-specifieke kennis die vaak opgehaald wordt via Retrieval-Augmented Generation (RAG) technieken.

• Geheugen: het vermogen om informatie over eerdere stappen of interacties te onthouden. Dit kan zowel op korte termijn zijn (binnen een sessie) als op langere termijn (over meerdere sessies heen). Geheugen stelt AI agents in staat om consequente antwoorden te geven, eerdere beslissingen te onthouden en de interactie vloeiender te maken.

• Tools: tools, zoals zoekmachines, databanken of API’s, kunnen gekoppeld worden aan grote taalmodellen (LLM’s). Op basis van een beschrijving van de tools kan het model dan bepalen welke tool er moet gebruikt worden om een bepaalde taak uit te voeren, tezamen met de input-parameters.

Deze verschillende componenten worden geconfigureerd en georchestreerd met behulp van specifieke tools zoals LangGraph, LlamaIndex, CrewAI, etc.

AI agents kunnen op verschillende manieren worden geactiveerd. Vaak gebeurt dit via tekst- of spraakinput, zoals in een chatinterface. Maar een trigger kan ook automatisch komen vanuit een proces: bijvoorbeeld de aanmaak van een nieuw bestand, het binnenkomen van een e-mail, of een wijziging in een database. Deze flexibiliteit maakt AI agents inzetbaar in uiteenlopende workflows.

Een interessante evolutie is “multi-agent collaboration”: hierbij werken meerdere AI agents samen, elk met een eigen specialisatie of taak. Door onderling te communiceren en taken te verdelen, kunnen ze complexe problemen efficiënter en effectiever aanpakken dan een enkelvoudige agent. Denk bijvoorbeeld aan een team van agents die samen een rapport opstellen, waarbij een agent data verzamelt, een andere analyseert en een derde het rapport schrijft.

Hoewel AI agents steeds autonomer worden, blijft een “human in the loop” essentieel. Menselijke supervisie helpt niet alleen om fouten of ongewenst gedrag tijdig te detecteren, maar verhoogt ook het vertrouwen en de betrouwbaarheid van het systeem – zeker in kritieke toepassingen waar nauwkeurigheid en ethiek een grote rol spelen.

Voordelen en toepassingen

Nu we weten uit welke bouwstenen AI agents zijn opgebouwd, kunnen we eens kijken welke voordelen ze kunnen bieden:

• Automatisering van taken: AI agents kunnen repetitieve en tijdrovende taken zelfstandig uitvoeren, waardoor medewerkers zich kunnen focussen op meer strategisch werk.

• Ondersteuning bij besluitvorming: door snel grote hoeveelheden data te analyseren en relevante inzichten aan te reiken, kunnen AI agents helpen bij het nemen van betere en beter onderbouwde beslissingen.

• Intelligente interactie met gebruikers: AI agents kunnen op een natuurlijke en contextbewuste manier communiceren via tekst of spraak, wat leidt tot vlottere en persoonlijkere interacties met eindgebruikers.

In de volgende toepassingsdomeinen kunnen AI agents potentieel een meerwaarde bieden:

• Gebruikersomgevingen: in klantgerichte omgevingen kunnen AI agents ingezet worden voor geautomatiseerde helpdesks, chatbots of gepersonaliseerde aanbevelingen.

• Informatieverwerking: AI agents zijn bijzonder geschikt voor het analyseren en structureren van grote hoeveelheden informatie. Ze kunnen documenten samenvatten, trends detecteren of relevante informatie extraheren uit complexe databronnen.

• Creatieve toepassingen: in creatieve sectoren kunnen AI agents ondersteuning bieden bij het opstellen van rapporten, het genereren van teksten voor sociale media of zelfs het meedenken over nieuwe campagnes. Ze functioneren hierbij als creatieve sparringpartner of productieve assistent.

Uitdagingen en Risico’s

Hoewel de technologie veel potentieel heeft, is het cruciaal om stil te staan bij enkele belangrijke aandachtspunten:

• Onvoorspelbaarheid: AI agents kunnen onvoorspelbaar zijn vanwege hun niet-deterministische aard; ze leveren soms onverwachte of inconsistente resultaten die moeilijk te reproduceren en te begrijpen zijn.

• Problemen met LLM’s: taalmodellen kunnen “hallucineren”, fouten maken bij het plannen of redeneren, en verkeerde keuzes maken bij de selectie van tools of het identificeren van entiteiten.

• Complexe debugging: vanwege de black-box-aard van taalmodellen is het moeilijk om te achterhalen waarom een agent een bepaalde beslissing gemaakt heeft. Hoe complexer de AI agent, hoe moeilijker het is om de exacte oorzaak van fouten te identificeren. Gespecialiseerde tracing tools zijn hierbij geen overbodige luxe.

• Kost en traagheid: vooral in situaties waarbij continu gepland en herpland wordt of de agent veel stappen doorloopt kan de finale output op zich laten wachten en kunnen de kosten voor het gebruik van grote taalmodellen oplopen.

• Productie-uitdagingen: een eerste prototype bouwen kost doorgaans relatief weinig moeite. De échte uitdaging ligt in het betrouwbaar en performant inzetten in een echte productie-omgeving.

Aangezien we in veel gevallen niet blindelings kunnen vertrouwen op de output van AI agents, is er momenteel nog vaak een menselijke tussenkomst nodig om betrouwbaarheid en kwaliteit te waarborgen.

Praktische voorbeelden

Om de mogelijkheden te illustreren volgen hieronder enkele concrete voorbeelden van AI agents:

1. Research agent: meer en meer zien we systemen opduiken om reseach uit te voeren, niet enkel betalende tools van de grote leveranciers (cf OpenAI Deep Research), maar ook open alternatieven. Het doel van zo’n research agent is om snel inzicht te krijgen in een bepaalde topic. De agent stelt zelfstandig rapporten op, met menselijke input voor de structuur van het rapport en de mogelijkheid om de output bij te sturen. Web search wordt ingezet als tool om informatie te verzamelen over de opgegeven topic en over de specifieke topics van elke sectie. Er wordt gebruik gemaakt van reasoning om de structuur van het rapport te plannen en om te reflecteren over de gegenereerde secties en follow-up vragen te suggereren om verdere analyse uit te voeren met behulp van de web search tool.

2. Agentic IDE: meer en meer zien we agentic AI opduiken bij softwareontwikkeling. Tools zoals GitHub Copilot “agent mode” schakelen AI-technieken in om niet enkel suggesties te geven tijdens het programmeren, maar ook om volledige taken autonoom af te ronden. Denk hierbij aan het genereren van code, uitvoeren van refactorings over meerdere bestanden, schrijven van testscripts en zelfs het automatisch verbeteren van fouten in een iteratieve trial-and-error aanpak. De agent begrijpt het bredere doel van de taak, voert stapsgewijs acties uit en herformuleert zijn aanpak indien nodig – net zoals een menselijke programmeur dat zou doen. Hierdoor fungeert hij als een intelligente programmeerassistent die ontwikkelaars sneller en consistenter laat werken.

3. Smart search: binnen Smals verkennen we de mogelijkheden van een slimme zoekfunctie in de context van een werkomgeving. In de huidige situatie moeten gebruikers hun weg vinden in meer dan 30 zoekcriteria om tot een goed resultaat te komen. Het doel van dit experiment is om het zoeken veel gebruiksvriendelijker te maken door gebruikers toe te laten hun zoekopdracht te formuleren in natuurlijke taal. De agent kan de vraag desambiguëren (gaat het bijvoorbeeld over een entiteit of een persoon?) en de gedesambigueerde vraag vervolgens omzetten naar een gestructureerde JSON-query waarmee een search-API kan aangeroepen worden.

Wanneer (niet) gebruiken?

AI agents kunnen interessant zijn in situaties waar traditionele, deterministische oplossingen tekortschieten. Denk aan contexten met grote hoeveelheden ongestructureerde data, natuurlijke taal, of veranderende omstandigheden waar adaptief gedrag wenselijk is. Ook voor complexe besluitvorming of als assistent in taken met veel variabelen kunnen AI agents meerwaarde bieden.

Om te beoordelen of een AI agent gepast is, kan onderstaande checklist helpen:

Wanneer is een AI agent een goed idee?

De taak is complex en moeilijk volledig te formaliseren

Er wordt gewerkt met natuurlijke taal of ongestructureerde data

De taak komt frequent voor en kost vandaag veel tijd

De context verandert regelmatig of is onzeker

Er is een duidelijke meerwaarde (tijdswinst, betere kwaliteit, schaalbaarheid)

Wanneer beter niet?

✘ De taak vereist hoge nauwkeurigheid en foutloosheid (bv. medisch, financieel)

✘ Het domein is strikt gereguleerd of bevat gevoelige persoonsgegevens

✘ De taak vraagt menselijke intuïtie, empathie of ethische afwegingen

✘ De taak is eenvoudig en goed oplosbaar via klassieke regelgebaseerde systemen

Let op: AI agents hoeven niet altijd volledig autonoom te opereren. In veel gevallen zijn ze het meest effectief in een assisterende rol – als slimme copiloot die analyses voorbereidt, suggesties doet of voorbereidend werk levert, terwijl de eindverantwoordelijkheid bij de mens blijft.

Conclusie

AI agents zitten duidelijk in de lift. Ze beloven enorme efficiëntiewinsten en nieuwe mogelijkheden in uiteenlopende domeinen, van klantendiensten en research tot softwareontwikkeling en informatiebeheer. Dankzij hun redenerend vermogen, toegang tot kennis en toolgebruik kunnen ze een hoog niveau van autonomie bereiken.

Toch is het belangrijk om deze technologie met de nodige voorzichtigheid te benaderen. AI agents zijn nog volop in ontwikkeling en kampen met fundamentele uitdagingen rond betrouwbaarheid, transparantie en performantie. In veel gevallen is menselijke tussenkomst en supervisie nog onmisbaar.

Wie vandaag experimenteert met AI agents, bouwt waardevolle kennis op over hoe deze systemen kunnen geïntegreerd worden in processen en organisaties. De komende jaren zullen bepalend zijn voor hoe deze technologie evolueert. Kan ze van hype evolueren naar een volwaardige, ingebedde rol in de dagelijkse werking van organisaties? AI agents hebben het potentieel om een duidelijke meerwaarde te leveren, mits we ze verstandig inzetten.

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

Dans le monde de l’IA, les bases de données vectorielles sont devenues un outil important.
Elles nous permettent de stocker et de fouiller efficacement de grandes quantités de données non structurées, fonction essentielle pour de nombreuses applications.

Embeddings vectoriels

Les bases de données vectorielles gèrent essentiellement des données vectorielles, c’est-à-dire des données représentées sous la forme d’une série de nombres, ou vecteurs, représentant un point dans un espace à haute dimension. La quantité de nombres dans un vecteur correspond à la quantité de dimensions.

La conversion des données en vecteurs s’opère sur la base d’un modèle d’embedding, où est captée leur signification (sémantique). On parle d’embeddings vectoriels. Par exemple, le vecteur du mot “chiot” sera proche du vecteur du mot “chien”, et plus éloigné du vecteur du mot “pomme”.

Ces vecteurs sont sauvegardés sous forme indexée dans une base de données vectorielle, de manière à ce que la recherche s’effectue le plus efficacement possible.

Recherche de similarité

Les bases de données vectorielles se distinguent par le fait qu’elles peuvent rechercher des données similaires par rapport à une requête d’entrée (query). On parle de recherche de similarité : au lieu de rechercher des correspondances exactes, les bases de données vectorielles peuvent rechercher les données les plus similaires à une requête donnée.

Cette “similarité” est calculée sur la base de la distance entre les vecteurs dans l’espace de recherche : plus la distance entre deux vecteurs est faible, plus ils sont similaires. Plusieurs fonctions permettent de calculer la distance entre deux vecteurs. Le choix peut dépendre de plusieurs facteurs : les données, le modèle d’embedding utilisé et le compromis entre précision et vitesse d’exécution.

La méthode la plus évidente pour chercher les vecteurs les plus proches d’un vecteur de requête consiste à comparer exhaustivement le vecteur de requête à tous les vecteurs présents dans la base de données (k-Nearest-Neighbors ou kNN). Nous avons ainsi la certitude de trouver les k vecteurs les plus proches. Dans ce cas, nous obtenons une précision parfaite. L’inconvénient de cette méthode est qu’elle nécessite beaucoup de calculs et qu’elle n’est pas extensible.

Pour effectuer des recherches plus performantes parmi de grandes quantités de données, il existe des méthodes approximatives où il n’y a pas de comparaison exhaustive entre la requête et les vecteurs de la base de données (Approximative Nearest Neighbors ou ANN). La méthode la plus utilisée est sans doute HNSW (Hierarchical Navigable Small World). Il s’agit d’une méthode basée sur un graphe hiérarchique où chaque nœud représente un vecteur et où les liens entre les nœuds indiquent la distance qui les sépare. Lors d’une recherche, l’algorithme navigue efficacement dans le graphe, en commençant par les niveaux supérieurs (où la densité des nœuds est moindre) et en descendant progressivement vers les niveaux inférieurs pour trouver les voisins les plus proches.

Recherche hybride

La recherche hybride est une technique de recherche avancée qui combine les atouts de la recherche vectorielle et ceux de la recherche classique par mot-clé. La recherche par mot-clé (recherche lexicale) utilise les correspondances exactes des mots-clés dans le texte. Elle est rapide et simple, mais manque parfois de nuances contextuelles. La recherche vectorielle (recherche sémantique) tient compte du sens. Dans la pratique, une combinaison des deux méthodes débouche sur de meilleurs résultats que chaque méthode individuelle.

Pour améliorer encore la pertinence des résultats de recherche, il est possible d’appliquer le classement sémantique, qui consiste à utiliser un modèle de machine learning avancé pour réorganiser les résultats de la recherche en fonction de leur pertinence par rapport à la requête. Il s’agit généralement d’une fonction payante ou d’une API facturée sur la base de son utilisation. À titre d’exemple d’un tel service, nous pouvons citer Cohere Rerank.

Domaines d’application

Les bases de données vectorielles peuvent être utilisées pour un grand nombre d’applications :

• Recherche sémantique – Il est clair à présent que les bases de données vectorielles peuvent grandement contribuer à l’amélioration des résultats d’une recherche sur la base de la signification sémantique plutôt que sur la seule base des correspondances exactes.
• Question answering & RAG– Depuis peu, les systèmes génératifs de questions-réponses font l’objet d’une grande attention. Dans un tel système, les bases de données vectorielles peuvent servir d’extracteur. On parle de Retrieval Augmented Generation (RAG). Dans cette approche, un modèle de langage formule des réponses basées sur les informations les plus pertinentes d’une base de connaissances.
• Recommandations – Les bases de données vectorielles peuvent également être utilisées pour recommander des informations ou des produits aux utilisateurs, en fonction ou non de leur historique ou de leurs préférences.

Recherche de similarité multimodale (Multimodal similarity search) – Certains modèles d’embedding sont capables de créer des vecteurs pour plusieurs types de données : non seulement du texte, mais aussi des images, de l’audio ou de la vidéo. Les bases de données vectorielles peuvent ainsi permettre la recherche de contenus similaires, qu’il s’agisse de textes, d’images, d’audio ou de vidéo.

Aperçu du marché

Les acteurs initiaux du marché des bases de données vectorielles comme Chroma, Milvus, Pinecone et Weaviate, proposaient essentiellement des solutions spécifiques.
Ce n’est que plus tard que les acteurs plus établis ont pris le train en marche. Ainsi, ElasticSearch et Postgresql (avec l’extension pgvector) prennent également en charge la recherche vectorielle. Bien évidemment, les grands acteurs sont également représentés dans le paysage : Microsoft propose Azure AI Search, Google Vector AI Vector Search et Amazon Kendra.

Presque toutes les solutions s’intègrent à des solutions d’orchestration LLM telles que LangChain et LlamaIndex. De plus en plus, les bases de données vectorielles fournissent également un support intégré pour RAG, où la création d’embeddings et l’invocation d’un modèle de langage n’ont plus besoin d’être orchestrées en dehors de la base de données vectorielle.

Il convient également de mentionner Neo4j, qui prend en charge la recherche vectorielle en plus de la recherche dans le graphe, ce qui le rend adapté aux cas de données structurées et non structurées.

Conclusion

Enfin, nous pouvons affirmer que les bases de données vectorielles peuvent fournir des résultats de recherche meilleurs et plus pertinents qu’une simple recherche par mot-clé.
Dans les applications génératives de réponse aux questions, les bases de données vectorielles peuvent aider un modèle de langage à formuler des réponses basées sur les informations les plus pertinentes d’une base de connaissances. S’il n’est pas évident de faire fonctionner de grands modèles de langage sur une infrastructure propriétaire, cela est bien possible avec une base de données vectorielle en guise de composant d’extraction, ce qui peut être un facteur favorable dans le contexte de la protection des données.

D’après notre propre expérience, la recherche hybride, à savoir une combinaison de recherche vectorielle et de recherche lexicale, peut être une solution rapide pour améliorer les résultats de la recherche. Le classement sémantique peut en outre renforcer la pertinence des résultats.

Ce post est une contribution individuelle de Bert Vanhalst, IT consultant chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

In de wereld van AI zijn vector databases een belangrijk hulpmiddel geworden. Ze stellen ons in staat om grote hoeveelheden ongestructureerde gegevens efficiënt op te slaan en te doorzoeken, wat cruciaal is voor veel toepassingen.

Vector embeddings

Vector databases beheren in essentie vectorgegevens. Dat zijn gegevens die worden weergegeven als een reeks getallen, of vectoren, die een punt in een hoog-dimensionale ruimte vertegenwoordigen. Het aantal getallen in een vector komt overeen met het aantal dimensies.

Het omzetten van gegevens naar vectoren gebeurt op basis van een embedding model, waarbij de betekenis (semantiek) ervan gecapteerd wordt. We spreken van vector embeddings. Zo zal de vector voor het woord “puppy” bijvoorbeeld dicht bij de vector voor “hond” liggen, en verder weg van “appel”.

Die vectoren worden geïndexeerd in een vector database opgeslagen, op zo een manier dat het opzoeken zo efficiënt mogelijk verloopt.

Similarity search

Het unieke aan vector databases is dat ze kunnen zoeken naar gelijkaardige gegevens ten opzichte van een inputvraag (query). We spreken van similarity search: in plaats van te zoeken naar exacte overeenkomsten kunnen vector databases zoeken naar gegevens die het meest vergelijkbaar zijn met een gegeven query.

Dat ‘vergelijkbaar zijn’ wordt berekend op basis van de afstand tussen vectoren in de zoekruimte: hoe kleiner de afstand tussen twee vectoren, hoe vergelijkbaarder ze zijn. Er bestaan verschillende functies om de afstand tussen twee vectoren te berekenen. De keuze kan afhangen van verschillende factoren: de gegevens, het gebruikte embedding model, en de afweging tussen accuraatheid en snelheid van uitvoering.

De meest voor de hand liggende manier om de dichtste vectoren te zoeken ten opzichte van een query vector is om de query vector exhaustief te vergelijken met alle vectoren in de databank (k-Nearest-Neighbors of kNN). Op die manier zijn we zeker dat we de k dichtste vectoren terugvinden. We krijgen  in dit geval perfecte accuraatheid. De keerzijde is echter dat het een rekenintensieve methode is die niet schaalt.

Om performanter te kunnen zoeken in grote hoeveelheden gegevens zijn er approximatieve methodes waarbij er geen exhaustieve vergelijking is tussen de query en de vectoren in de databank (Approximative Nearest Neighbors of ANN). De meest gebruikte methode hiervoor is wellicht HNSW (Hierarchical Navigable Small World). Dat is een methode op basis van een hiërarchische graaf waarbij elke node een vector vertegenwoordigt en de links tussen de nodes de afstand ertussen aangeeft. Tijdens een zoekopdracht navigeert het algoritme efficiënt door de graaf, beginnend op hogere niveaus (waar de dichtheid van nodes lager is) en geleidelijk afdalend naar lagere niveaus om de dichtste buren te vinden.

Hybrid search

Hybrid search is een geavanceerde zoektechniek die de sterktes van vector search combineert met die van een klassieke keyword search. Keyword search (lexicaal zoeken) maakt gebruik van exacte overeenkomsten van trefwoorden in de tekst. Het is snel en eenvoudig, maar mist soms de contextuele nuances. Bij vector search (semantisch zoeken) wordt de betekenis in rekening gebracht. In de praktijk blijkt dat een combinatie van beide methodes betere resultaten oplevert dan elke methode afzonderlijk.

Om de relevantie van de zoekresultaten nog te verbeteren kan er semantic ranking toegepast worden. Daarbij wordt een geavanceerd machine learning model gebruikt om de zoekresultaten te herschikken op basis van hun relevantie ten opzichte van de zoekopdracht. Dit is typisch een betalende feature of API waarbij je betaalt volgens verbruik. Een voorbeeld van zo’n dienst is Cohere Rerank.

Toepassingsgebieden

Vector databases kunnen voor een divers aantal toepassingen ingezet worden:

• Semantic search – Het mag ondertussen duidelijk zijn dat vector databases een belangrijke bijdrage kunnen leveren bij het verbeteren van de zoekresultaten op basis van semantische betekenis in plaats van enkel exacte matches.
• Question answering & RAG – Recent is er veel aandacht voor generatieve vraag-antwoordsystemen. Vector databases kunnen ingezet worden als retriever component in zo’n systeem. Men spreekt over Retrieval Augmented Generation (RAG). Dit is een aanpak waarbij een taalmodel antwoorden formuleert op basis van de meest relevante informatie uit een kennisbank.
• Aanbevelingen (recommender systemen) – Vector databases kunnen ook ingezet worden om informatie of producten aan te bevelen aan gebruikers, al dan niet op basis van hun historiek of voorkeuren.
• Multimodal similarity search – Bepaalde embedding modellen zijn in staat om vectoren aan te maken voor meerdere types van gegevens: niet enkel tekst, maar ook afbeeldingen, audio of video. Vector databases kunnen op die manier zoeken mogelijk maken naar gelijkaardige content, ongeacht of het gaat over tekst, afbeeldingen, audio of video.

Marktoverzicht

De initiële spelers op de markt voor vector databases, zoals Chroma, Milvus, Pinecone en Weaviate, boden voornamelijk purpose-built oplossingen aan. Pas later sprongen de meer gevestigde spelers op de kar. Zo bieden ElasticSearch en Postgresql (met de pgvector extensie) ook ondersteuning voor vector search. Uiteraard zijn ook de grote spelers vertegenwoordigd in het landschap: Microsoft biedt Azure AI Search, Google Vector AI Vector Search en Amazon Kendra.

Zo goed als alle oplossingen integreren met LLM orchestratie oplossingen zoals LangChain en LlamaIndex. Meer en meer bieden vector databases ook ingebouwde ondersteuning voor RAG, waarbij het aanmaken van embeddings en aanroepen van een taalmodel niet meer extern aan de vector database moet georchestreerd worden.

Ook vermeldenswaardig is Neo4j, dat naast graph search ook vector search ondersteunt en daarmee geschikt is voor cases met zowel gestructureerde als ongestructureerde gegevens.

Conclusie

Tot slot kunnen we stellen dat vector databases kunnen zorgen voor betere, relevantere zoekresultaten ten opzichte van een eenvoudige keyword search. Bij generative question answering toepassingen kunnen vector databases helpen een taalmodel antwoorden te laten formuleren op basis van de meest relevante informatie uit een kennisbank. Terwijl het niet evident is om grote taalmodellen op eigen infrastructuur te draaien, is dat bij vector database als retrieval component wel mogelijk, wat een gunstige factor kan zijn in het kader van gegevensbescherming.

Uit eigen ervaring merken we dat hybride search, een combinatie van vector search en lexical search, een quick win kan zijn om de zoekresultaten te verbeteren. Semantic ranking kan daarbovenop nog een extra boost geven aan de relevantie van de resultaten.

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

Modèles de langue

Ces derniers mois, nous avons tous pu découvrir la puissance de l’IA générative, avec ChatGPT occupant le devant de la scène. À la base, il y a les modèles de langue larges (large language models – LLM): des réseaux neuronaux à grande échelle avec de nombreux paramètres entraînés à partir de grandes quantités de texte. Voici quelques applications de ces LLM :

• Générer un texte : pensez ainsi à un brouillon pour un mail ;
• Résumer un texte ;
• Traduire ;
• Classifier du texte ; cela inclut le ‘sentiment analysis’, comme la classification de commentaires de clients comme positifs ou négatifs ;
• Répondre à des questions ;
• Reconnaître des entités, telles que des noms de personnes ;
• Aider à écrire du code : voir l’article de blog sur De AI-Augmented Developer

Une application populaire est celle des réponses aux questions. Suite au lancement de ChatGPT, une masse d’outils permettant de répondre à des questions concernant votre propre contenu voient le jour. Le principe est très simple : téléchargez vos documents (PDF, Word, etc.) et vous pouvez presque immédiatement poser des questions, généralement dans un environnement de type “chatbot”.

Dans cet article, nous décrivons le fonctionnement d’un tel système de réponse aux questions et nous apportons quelques précisions sur la qualité que l’on peut attendre des résultats.

Question answering basé sur des modèles de langue 

Le schéma ci-dessous présente les éléments qui composent un système de ‘question answering’ basé sur des modèles de langue. La partie supérieure (en bleu) représente toutes les étapes nécessaires à la préparation du contenu :

• Comme point de départ, nous avons une base de connaissance (knowledge base) composée d’un ou plusieurs documents. Il peut s’agir de différents formats comme PDF, Word ou des pages web. Dans cette première étape, le texte est extrait du document ;
• Le texte est ensuite divisé en de plus petits fragments (chunks) ;
• Ces fragments sont ensuite convertis en embeddings, une représentation numérique du texte qui permet de retrouver plus facilement des extraits de texte sémantiquement comparables ;
• Enfin, ces embeddings sont stockés dans une base de données vectorielles (vector store).

Après cette phase préparatoire, l’utilisateur final peut poser une question au système (voir la partie inférieure du schéma), celle-ci est ensuite traitée comme suit : la question de l’utilisateur (query) est convertie en embeddings, permettant de rechercher dans la base de données vectorielle (retrieval) les documents les plus proches sémantiquement de cette question. Ensuite, un prompt est envoyé au modèle de langue. Il contient toutes les informations nécessaires pour obtenir une réponse du modèle de langue: la question initiale de l’utilisateur, les documents pertinents trouvés et la mission spécifique (instruction) pour le modèle de langue. Enfin, nous obtenons une réponse générée, accompagnée d’une indication des sources (numéros de pages ou URL de sites web) si souhaité.

On peut se demander pourquoi ne pas immédiatement envoyer tous les documents de la base de connaissance au modèle de langue en tant que contexte. Il y a principalement deux raisons à cela. Premièrement, la taille du contexte que nous pouvons transmettre est limitée. Par exemple, le modèle populaire GPT-3.5-turbo est limité à 4000 tokens. Les tokens désignent la plus petite unité significative en laquelle un texte peut être divisé. Un token peut être un mot entier, mais aussi une partie de mot ou un signe de ponctuation, en fonction de la méthode de tokenization utilisée.

Une deuxième raison est le coût du recours à un modèle de langue large. En effet, il dépend du nombre de tokens en input et output. Ainsi, plus nous fournissons de contexte à l’input, plus le coût est élevé.

Frameworks

Les applications basées sur l’architecture ci-dessus peuvent être rapidement développées grâce à des frameworks comme Langchain. Ils offrent généralement des abstractions permettant d’exécuter en quelques lignes de code les tâches décrites dans le schéma ci-dessus (extraire le texte, le diviser, créer et sauvegarder les embeddings). Ils agissent également comme une sorte d’orchestrateur pour relier l’input de l’utilisateur à la base de données vectorielles et au modèle de langue.

En guise d’expérience, nous nous sommes lancé avec Langchain pour construire une application de question answering sur la base d’un PDF ou d’une page web. Avec la connaissance nécessaire du framework, la mise en place est très rapide.

Qualité du output

La principale question est bien sûr de savoir dans quelle mesure les réponses que nous recevons sont exactes. Nos expériences montrent que les réponses sont parfois impressionnantes : correctes, bien résumées et quelquefois accompagnées d’un raisonnement correct, par exemple pour interpréter si un montant de la question est supérieur ou inférieur à un montant limite.

Nous devons malheureusement aussi constater que les réponses sont souvent peu précises ou incomplètes, voire carrément fausses. Intuitivement, on pourrait penser que cela est intrinsèque à la nature générative des modèles linguistiques et au phénomène des hallucinations. Un facteur au moins aussi important est l’étape de retrieval : la recherche des fragments de texte les plus pertinents dans lesquels le modèle de langue doit trouver les informations pour composer une réponse. Si les informations utiles pour une réponse ne se trouvent pas dans les fragments de texte fournis, on ne peut pas s’attendre à ce que le modèle de langue renvoie une réponse exacte.

Indépendamment de ces failles, il existe un certain nombre de techniques permettant d’améliorer la qualité de l’output, notamment :

• Combiner le retrieval sémantique avec un retrieval lexical classique ;
• Inclure des sources pertinentes supplémentaires dans la base de connaissance ;
• Prompt engineering : adapter les instructions données au modèle de langue;
• L’ajustement de la taille des chunks et de la taille de du chevauchement entre les chunks. Nous notons ici que la limite du contexte des modèles de langue augmente. Ainsi, OpenAI fournit un modèle avec un contexte de 16 000 tokens. Cela permet d’inclure davantage de contexte. L’augmentation de la taille des chunks peut garantir que les informations sémantiquement liées restent plus longtemps dans un même chunk.
• Enfin, on peut également envisager d’affiner un modèle de langue, mais c’est beaucoup plus lourd.

Conclusion

Il serait bien de pouvoir mettre en place un système capable de répondre à des questions sur nos propres données avec un effort très limité. Cependant, la précision de la réponse reste un point d’attention important. Ce n’est pas pour rien que ces applications affichent invariablement un avertissement indiquant que les réponses peuvent être inexactes ou erronées et qu’il est toujours conseillé de vérifier le résultat.

Ce post est une contribution individuelle de Bert Vanhalst, IT consultant chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Taalmodellen

De laatste maanden heeft iedereen kunnen kennismaken met de kracht van generatieve AI, met ChatGPT als grote blikvanger. Aan de basis liggen grote taalmodellen (large language models – LLM’s): grootschalige neurale netwerken met heel veel parameters die getraind zijn op grote hoeveelheden tekst. Een aantal toepassingen van dergelijke LLM’s zijn:

• Genereren van tekst: denk bijvoorbeeld aan een draft voor een email;
• Samenvatten van tekst;
• Vertalingen uitvoeren;
• Classificeren van tekst: hieronder valt sentiment analyse, zoals het classificeren van klantenreviews als positief of negatief;
• Vragen beantwoorden;
• Entiteiten herkennen, zoals persoonsnamen;
• Assisteren bij het schrijven van code: zie de blogpost over De AI-Augmented Developer.

Een populaire toepassing is het beantwoorden van vragen. Naar aanleiding van de lancering van ChatGPT duiken er massaal tools op die toelaten om vragen te beantwoorden over je eigen content. Het wordt heel eenvoudig voorgesteld: upload je documenten (PDF, Word, etc.) en je kan quasi onmiddellijk vragen beginnen stellen, typisch in een chatbot-achtige omgeving.

In dit artikel geven we aan hoe zo’n question answering systeem in elkaar steekt en vertellen we wat meer over de kwaliteit die we kunnen verwachten van de output.

Question answering op basis van taalmodellen

Onderstaand schema geeft in grote lijnen weer welke componenten onderdeel uitmaken van een question answering systeem op basis van taalmodellen. Het bovenste gedeelte (blauw) zijn alle stappen die nodig zijn om de content klaar te zetten:

• Als startpunt hebben we een knowledge base met één of meerdere documenten. Het kan gaan om verschillende formaten, zoals PDF, Word of webpagina’s. In deze eerste stap wordt de tekst uit de documenten gehaald;
• Vervolgens wordt de tekst opgesplitst in kleinere stukken (chunks);
• Die stukken tekst worden dan omgezet naar embeddings, dat is een numerieke voorstelling van tekst die het gemakkelijker maakt om semantisch vergelijkbare stukken tekst terug te vinden;
• Uiteindelijk worden de embeddings bijgehouden in een databank (vector store).

Na deze voorbereidingsfase kunnen we als eindgebruiker een vraag stellen aan het systeem (zie onderste gedeelte in het schema). Dit gaat als volgt: de vraag van de gebruiker (query) wordt omgezet naar embeddings, wat toelaat om in de vector store de documenten op te zoeken (retrieval) die het meest semantisch verwant zijn met deze vraag. Vervolgens wordt een prompt naar het taalmodel gestuurd, dit is alle informatie die nodig is om een antwoord te bekomen van het taalmodel: de originele vraag van de gebruiker, de relevante gevonden documenten en de specifieke opdracht (instructie) voor het taalmodel. We krijgen tenslotte een gegenereerd antwoord terug, indien gewenst samen met vermelding van de bronnen (paginanummers of website URL’s).

We kunnen ons afvragen waarom we niet meteen alle documenten uit de knowledge base als context meegeven aan het taalmodel. Daar zijn hoofdzakelijk twee redenen voor. Eerst en vooral is er een beperking op de grootte van de context die we kunnen meegeven. Het populaire GPT-3.5-turbo model heeft bijvoorbeeld een limiet van 4000 tokens. Met tokens wordt de kleinste betekenisvolle eenheid bedoeld waarin tekst kan worden opgesplitst. Een token kan een volledig woord zijn, maar het kan ook een deel van een woord zijn of een leesteken, afhankelijk van de gebruikte methode voor tokenization.

Een tweede reden is de kost voor het aanroepen van een taalmodel. Die is namelijk afhankelijk van het aantal tokens in de input en de output. Hoe meer context we meegeven met de input, hoe hoger dus de kost.

Frameworks

Toepassingen op basis van de bovenstaande architectuur kunnen snel ontwikkeld worden dankzij frameworks zoals Langchain. Ze bieden typisch abstracties aan om in enkele lijnen code de taken uit te voeren uit het schema hierboven (tekst extraheren, tekst opsplitsen, embeddings aanmaken en opslaan). En ze fungeren als een soort orchestrator om de gebruikersinput te verbinden met de vector store en het taalmodel.

Als experiment gingen we aan de slag met Langchain om een question answering toepassing te bouwen op basis van een PDF of webpagina’s. Met de nodige kennis van het framework is dit heel snel opgezet.

Kwaliteit van de output

De hamvraag is natuurlijk hoe accuraat de antwoorden zijn die we terugkrijgen. Uit onze experimenten blijkt dat de antwoorden soms indrukwekkend goed zijn: accuraat, mooi samengevat en soms met correcte redenering zoals het interpreteren of een bedrag uit de vraag boven of onder een bepaald grensbedrag ligt.

Maar we moeten helaas ook constateren dat de antwoorden dikwijls onnauwkeurig zijn of onvolledig, tot zelfs ronduit fout. Intuïtief kan men denken dat dit intrinsiek is aan het generatieve karakter van taalmodellen en het fenomeen van hallucinaties. Een minstens even belangrijke factor is echter de retrieval stap: het opzoeken van de meest relevante stukken tekst waarin het taalmodel de informatie moet vinden om een antwoord op te stellen. Indien de informatie die nuttig is voor een antwoord niet in die aangeleverde stukken tekst staat, kunnen we niet verwachten dat het taalmodel een accuraat antwoord teruggeeft.

Los van waar het fout gaat, zijn er een aantal technieken om de kwaliteit van de output te verhogen, waaronder:

• Semantische retrieval combineren met een klassieke lexicale retrieval;
• Bijkomende relevante bronnen opnemen in de knowledge base;
• Prompt engineering: de instructie aanpassen die gegeven wordt aan het taalmodel;
• Het aanpassen van de grootte van de chunks en de grootte van de overlap tussen de chunks. We merken hierbij op dat de limiet op de context van de taalmodellen groter wordt. Zo biedt OpenAI een model met een context van 16.000 tokens. Daardoor kan meer context meegegeven worden.  Het verhogen van de grootte van de chunks kan ervoor zorgen dat semantisch verwante informatie meer samenblijft in één chunk.
• Tenslotte kan er ook gedacht worden aan het finetunen van een taalmodel, maar dat is veel omslachtiger.

Conclusie

Het zou mooi zijn om met een heel beperkte inspanning een systeem te kunnen opzetten dat in staat is om vragen te beantwoorden over onze eigen data. De accuraatheid van het antwoord is echter nog een groot aandachtspunt. Er is een goede reden waarom er bij dergelijke toepassingen steevast een disclaimer te zien is die stelt dat de antwoorden onnauwkeurig of foutief kunnen zijn en dat het steeds aangeraden is om het resultaat te controleren.

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

Enorme taalmodellen moeten worden getraind met enorme datasets. Om die te verzamelen wordt op geen bron meer of minder gekeken: The Pile, zowat de grootste dataset van Engelstalige tekst die vandaag bestaat, tikt ongeveer 825 GB aan. De volledige Engelstalige Wikipedia maakt er deel van uit, voor 6.3 GB, oftewel 0.7% van de collectie. Andere databronnen zijn CommonCrawl , OpenWebText , maar er worden ook tekstfragmenten gebruikt afkomstig van Github, ArXiv, PubMed, StackExchange, OpenSubtitles, zelfs het Europees Parlement.

Veel van die datasets zijn met eenvoudige webscraping scripts verzameld. Of dat allemaal wel mag volgens copyright- en privacywetgevingen allerhande, is een ingewikkelde vraag met een nog ingewikkelder antwoord en dus maakt men daar voor het gemak in eerste instantie vaak abstractie van. Kwaliteitschecks en fijnmazige filters zijn tijdrovend als je ze accuraat wil maken, en in de wedloop om het grootste taalmodel sneuvelen die dus helaas ook maar al te vaak.

Gegeven de enorme verscheidenheid aan bronnen, websites, tekstformatteringen en dataverzamelingsmethodes, is het zo haast onvermijdelijk geworden dat in datasets van die grootteorde toch nog persoonsgegevens of auteursrechtelijk beschermde teksten terechtkomen – zelfs als men moeite doet om enigszins correct te handelen. Reden genoeg om zelf eens in zo’n dataset te duiken en te kijken wat we daarin terugvinden.

OSCAR

OSCAR is een meertalige dataset die regelmatig wordt gebruikt voor niet-Engelstalige taalmodellen. De Nederlandstalige subset ervan kan dienen als basis van een Nederlandstalige tekstgenerator. OSCAR is op zijn beurt afgeleid van CommonCrawl, een grootschalige dataset van scraped websites, waarvan de makers wel aangeven dat robots.txt en HTML no-follow specificaties gehonoreerd werden, maar waar verder weinig meer mee gebeurd is dan gegevensopslag. OSCAR groepeert die per taal, voegt wat extra preprocessing toe, en zet de tekstfragmenten in willekeurige volgorde, om zo copyrightproblemen te vermijden. We doen hier geen uitspraak over de vraag of dat wel voldoende is voor dat doel. Een bijkomend effect daarvan is wel dat de inhoudelijke relatie tussen opeenvolgende tekstfragmenten in deze dataset dus verloren is gegaan. (De laatste paper van de auteurs probeert daar alsnog een mouw aan te passen.)

We bekijken de Nederlandstalige gegevens uit de eerste versie van deze dataset uit 2019 (toegang tot versie 2021 of versie 2022 vereisen registratie of aanvraag). Deze is vrij beschikbaar in de dataset repository van Huggingface, dat ook een eerste preview van de inhoud voorziet. Bij Huggingface vermeldt men summier dat de dataset persoonlijke of gevoelige informatie kan bevatten, en dat de training van een AI-model op basis van deze dataset gevoelig kan zijn voor biases, zonder dieper in te gaan op deze problematiek. De verantwoordelijkheid hiervoor wordt bij de gebruiker van de dataset gelegd.

De Nederlandstalige subset van OSCAR bestaat uit 126.064.721 tekstfragmenten van één tot enkele zinnen lang, die we kunnen samengevoegen tot 1 tekstbestand met een grootte van ongeveer 40GB. In wat volgt doorzoeken we deze dataset naar gegevens die als persoonlijk of gevoelig beschouwd zouden kunnen worden. Het valt aan te nemen dat die gegevens grotendeels zijn gescrapet zonder medeweten van de originele auteurs of van de websites waarop ze oorspronkelijk gepubliceerd waren. We tonen telkens een selectie van wat we zoal terugvinden ter illustratie, maar om de mogelijke privacy- en copyrightproblemen niet erger te maken dan ze al zouden kunnen zijn, maskeren we in dit artikel de gevonden gevoelige gegevens alsnog en markeren we ze rood.

Gevoelige gegevens in OSCAR

Door gewoon reguliere expressies toe te passen, die je vaak kan copy-pasten van het internet, kunnen we al veel boven water halen. Om emailadressen te detecteren, gebruiken we een relatief eenvoudig patroon, waarmee we 685.968 potentiële matches terugvinden (let wel dat veel algemene emailadressen, bijvoorbeeld van helpdesks of infolijnen of grote organisaties, herhaaldelijk voorkomen):

grep -a -e "[a-zA-Z0-9._]\+@[a-zA-Z]\+.[a-zA-Z]\+" oscar_nl_full.txt

• Ik gooide enkele nieuwe data online! Wie zin heeft kan zich inschrijven door te mailen naar e*******s@gmail.com
• Ontdek hoe je een WordPress thema vindt dat echt bij jou past! www.speciaalgeselecteerd.nl jouw gids voor WordPress thema s Door: S******* v** N******** Datum: 1-1-2016 E-mail: s********@innonet.nl WordPress
• De hoofdleiding bestaat uit D***** V******, G***** G*******, M**** W****** en F***** V*** B*****, hen kan je contacteren via 0497****** (D*****), 0493****** (G*****), 0477****** (M****) en 0498****** (F*****). Een mailtje naar i***@c*********.be is ook altijd mogelijk. Zij zullen jullie graag helpen met vragen, opmerkingen of klachten.

Veel emailadressen lijken afkomstig van contactpagina’s op websites van bedrijven, organisaties, maar je herkent ook overduidelijk verenigingen, lokale initiatieven, jeugdbewegingen, en forumgebruikers die hun persoonlijke contactgegevens achterlaten, waaronder telefoonnummers. Het volgende patroon zoekt naar cijfercombinaties die eruit zien als een Belgisch telefoonnummer, in de meest voorkomende schrijfwijzen. (Het patroon is iets te algemeen opgesteld, met als nadeel dat we er ook onderdelen van niet-telefoonnummers mee vinden.) Dat leidt alleszins al tot 289.461 potentiële matches:

grep -a -P "(((\+|00)32[ ]?(?:\(0\)[ ]?)?)|0){1}(4(60|[789]\d)\/?(\s?\d{2}\.?){2}(\s?\d{2})|(\d\/?\s?\d{3}|\d{2}\/?\s?\d{2})(\.?\s?\d{2}){2})" oscar_nl_full.txt 

• Tijdens de openingstijden kan je via de Live Chat of via de telefoon 07******** vragen stellen aan één van onze medewerkers.
• […] Heeft u vragen over onze werkwijze, prijzen of materialen dan zijn we bereikbaar op de nummers 03/***.**.** en 03/***.**.**. Ook kunt u een e-mail sturen naar [email protected] of het contactformulier invullen.
• Op 22 september vertrekken we op speel-weekend naar Ronse. Wil je nog mee? Als de bliksem bellen naar R******* 0496/**.**.**
• Propere betonnen palen 8 stuks, geen beton/cement aan de onderkant van de paal- lengte 2.05m. Bieden vanaf €7/stuk. Tel 0478/******

Ook hier vinden we veel contactgegevens van bedrijven, maar een aanzienlijk deel zijn ook persoonlijke telefoonnummers afkomstig van berichten die mensen postten op online marktplaatsen of zoekertjeswebsites. Bankrekeningnummers, BTW-nummers e.d. duiken ook op tussen de gevonden data. Om te blijven focussen op persoonsgerelateerde data, gaan we nog op zoek naar Twitter of Instagram handles. Deze kunnen bijvoorbeeld afkomstig zijn van conversaties op Twitter en Instagram zelf, van internetfora waar mensen erover spreken, of van de footers van webpagina’s met links naar sociale media. Afgezien van enkele bedrijven wiens naam of product met een @ begint, gaan achter de meeste gevonden handles echte, actieve mensen of organisaties schuil. We vinden zo 131.364 potentiële matches:

grep -a -e " @[a-zA-Z0-9]\+" oscar_nl_full.txt

• Vandaag waren we op bezoek bij Leo Timmers, maker van Een huis voor Harry, het Prentenboek van het Jaar 2019! En we gingen Billy ontmoeten, de kat waar Harry op geïnspireerd is. Ik had dus de dag van m’n leven. @v*********** #cat #books #brussels #reading #catsofbrussels #eenhuisvoorharry 
• […] R***** twitterde dit naar mij en @p********, afgelopen zondagmiddag. We hadden het over de blogs die Ruud had willen schrijven die dag: drie stuks maar liefst. De blogs kwamen er inderdaad niet. Nooit meer. R***** overleed maandagavond [datum]. Ik heb een goede vriend verloren.
• Zeg @******** wat willen jullie nou in de omgangsvorm: ‘u’ of ‘je’? Maak een keuze! https://t.co/********
• @******** En niet alleen dat. Het kenteken *-***-** staat mooi op beeld. Kijk dus uit voor deze asociale weggebruiker, mede-weggebruikers. @ [datum]

Er duikt duidelijk een heel palet aan persoonsgebonden informatie in deze dataset op, zoals ook nummerplaten, berichten over ziekte of overlijden, politieke voorkeuren, informatie over wanneer personen waar geweest zijn, en nog heel wat meer. Met hetzelfde gemak vinden we ook beledigingen tegen personen terug, verwensingen allerhande, racistische fragmenten, … we kunnen alleszins heel lang bezig blijven als we hierop enige grip willen krijgen in zo’n dataset.

Een heel ander gevoelig onderwerp is erotische inhoud. Er zijn alvast 2.459.800 matches voor woorden die beginnen met “seks” of “sex” in dit eerste deeltje van de dataset. Voorbeelden daarvan geven we terwille van de goede smaak niet mee, maar u mag de auteur op zijn woord geloven dat de meeste gevonden tekstfragmenten niet van droog-wetenschappelijke papers of schoolse seksuele opvoeding afkomstig zijn. Op een totaal van 126 miljoen zinnen, kunnen we zo schatten dat zulke inhoud ongeveer 2% van het totaal uitmaakt in deze dataset. 

Kom ik er in voor?

Dat kunnen we gemakkelijk achterhalen:

grep -a -e "Joachim Ganseman" oscar_nl_full.txt  

• De 27e Internationale Olympiade Informatica vond plaats in Almaty, Kazachstan. De Belgische ploeg werd gevormd door Damien Galant (5e middelbaar), Robin Jadoul, Mattéo Couplet en Nico Ekkart (allen 6e middelbaar). Zij werden begeleid door Damien Leroy en Joachim Ganseman. […]
• […] De bouwstenen voor artificiële intelligentie (AI) liggen klaar, maar ze staan op los zand. Dhr. Joachim Ganseman van Smals Research bestudeerde de zwaktes van AI. In zijn artikel op de Research-blog bespreekt hij een aantal uitdagingen voor de toekomst.
• Joachim Ganseman wordt onderscheiden voor de ijver waarmee hij als jonge doctoraatsstudent de Belgische informatica-olympiade heeft gesticht, coördineert en communiceert in beide landshelften, met bijzondere inspanningen voor de toegankelijkheid voor alle leerlingen, ongeacht voorkennis.

In 7 tekstfragmenten komt mijn volledige naam voor, voornamelijk in verband met mijn engagement bij de Belgische Informatica-olympiade van 2011 tot 2018. Geen info die iets schandaligs of schaamtelijks bevat, integendeel, maar ik was niet op de hoogte. Als je ooit met naam en toenaam in de krant of op een website van een grotere organisatie hebt gestaan, lijkt de kans alleszins groot dat je naam in dat verband ook in de OSCAR dataset voorkomt. Het blijft dus erg belangrijk om in het achterhoofd te houden dat dat wat eenmaal op het internet staat, er erg moeilijk terug af gaat.

Misschien kan het een goed idee zijn om, naar analogie van Have I Been Pwned die je waarschuwt voor paswoordlekken, een gelijkaardige dienst te hebben bij dataset repositories waarmee gebruikers kunnen checken of hun persoonlijke informatie voorkomt in datasets? Tijd en middelen ontbreken om zoiets zelf verder uit te werken, maar we laten het hier staan als een interessante suggestie.

En dan?

We moeten nog vermelden dat de makers van de CommonCrawl en OSCAR datasets zelf niet Nederlandstalig zijn. Zij hebben dan ook niet onmiddellijk manieren ter beschikking om de verzamelde fragmenten in het Nederlands (en in de meeste van de andere 165 talen in OSCAR) op hun inhoudelijke merites te gaan beoordelen, en presenteren deze datasets “as is”.

Gegeven het feit dat persoonsgebonden gegevens gemakkelijk te vinden zijn op het internet voor wie een beetje zoekt – en zeker op sociale media of op marktplaatsen waar ze gretig uitgewisseld worden – is het niet verwonderlijk dat deze gegevens ook terechtkomen in datasets verzameld via webscraping, als er een breed net wordt uitgegooid en weinig wordt gefilterd.

Smals Research is een technisch team zonder juristen in haar rangen; we laten uitspraken over het wettelijke kader rond webscraping, auteursrechten, en de gebruiksvoorwaarden van websites, in een internationale context, dan ook liever over aan mensen die daar meer van kennen dan wij. Het is in onze sector wel algemeen bekend dat de persoonsgegevens van EU-ingezetenen beschermd worden door de GDPR. Dat houdt onder andere in dat zij de inzage en verwijdering van hun gegevens moeten kunnen vragen, en informatie moet kunnen krijgen over het gebruik ervan. Het wordt natuurlijk moeilijk om dat recht effectief uit te oefenen, als gegevens op elk moment in een externe database kunnen worden overgenomen, zonder medeweten van die persoon of zelfs van de website waarop ze gepubliceerd waren.

Wie van zulke datasets gebruik maakt om AI systemen te trainen, is technisch gesproken de daarin begrepen persoonsgegevens aan het verwerken, en lijkt zo alvast automatisch een verantwoordelijkheid te hebben ten aanzien van die betreffende personen. Het is daarnaast niet ondenkbaar dat een verkeerd of slecht getraind AI-systeem deze gegevens expliciet opneemt in het resulterend model, en ze aanwendt om bepaalde beslissingen te nemen, wat een risico op bias met zich meebrengt. Tot slot weet je nooit of er ergens een slecht beveiligde website gescrapet werd door de dataset-maker, waardoor er misschien login-gegevens of paswoorden voorkomen in de dataset.

Een alternatieve werkwijze

De onderzoeksgroep Computationele Linguïstiek van de Universiteit van Groningen bouwde een eigen variant van een Nederlandstalig GPT-2 model. Zij zijn natuurlijk wél Nederlandstalig, en waren ook selectiever in het kiezen van hun trainingsdata. In hun paper lezen we dat die bestaat uit de Nederlandstalige Wikipedia (2.0GB), een grote hoeveelheid E-books (6.5GB), een dataset van nieuwsartikels die weliswaar nog van 2007 dateert (2.9GB) aangevuld met artikels van andere nieuwswebsites (2.1GB). Na het wegfilteren van duplicaten is dat goed voor een trainingsdataset van 13GB aan Nederlandstalige tekst. Gegeven deze bronnen is het aannemelijk dat hun dataset alvast correcter geschreven Nederlands bevat van een inhoudelijk hogere standaard.

De eigenlijke dataset vonden we na een korte zoektocht niet onmiddellijk terug, dus het is moeilijk de inhoud verder te bekijken – wie weet waar ze ergens beschikbaar zou zijn, mag het steeds laten weten. Het valt alleszins te verwachten dat de inhoud van deze dataset minder problematisch zal zijn op het vlak van persoonlijke gegevens dan OSCAR. Langs de andere kant stelt zich, met een dataset afkomstig van krantenartikels en e-books, misschien wel nog een copyrightprobleem.

Kieskeurig zijn qua trainingsdata heeft weliswaar een keerzijde. Een generatief taalmodel getraind op een selecte dataset is gelimiteerder qua teksten die het kan produceren. Tekstfragmenten die lijken op sociale-media-posts zullen moeilijk gegenereerd kunnen worden door een model dat niet getraind werd op data afkomstig van sociale media, en een hoge aandeel e-books leidt ook tot prozaïscher teksten. Tot slot maakt het groot aandeel van oudere nieuwsartikels ook dat het getrainde model teksten “uit die tijd” zal produceren, en relatief minder woordenschat en zinswendingen kent over recente trends, technologische uitvindingen of politieke ontwikkelingen.

Conclusie

We hebben hier slechts één Nederlandstalige dataset onder de loep genomen, maar het spreekt voor zich dat dezelfde problemen zich stellen in gelijkaardige datasets voor andere talen.

Het valt op dat enkele eenvoudige filters, bijvoorbeeld om emailadressen, rekeningnummers, persoonlijke profielinformatie of andere persoonsgegevens te detecteren, al een heel deel van deze problematische inhoud zouden kunnen wegfilteren. Een sluitende garantie geven dat er niets fouts meer voorkomt is haast onmogelijk in datasets van deze grootteorde, maar hier hebben we toch kunnen illustreren dat er soms wel érg weinig moeite gedaan lijkt te zijn om de datasets een beetje op te schonen. 

Propere datasets maken, deze inhoudelijk onderzoeken en daarbij in de diepte graven, kost natuurlijk tijd en moeite – enkel om problematische stukjes weg te vijlen die in hun geheel maar een klein deeltje uitmaken van de hele dataset, wat dus waarschijnlijk ook maar een kleine impact zou hebben op het daaruit resulterende taalmodel. Het is moeilijk hard te maken dat zulk monnikenwerk zich economisch terugverdient, en garanties dat je effectief alles verwijdert zijn er evenmin.

Toch is het belangrijk dat er voldoende aandacht geschonken wordt aan de kwaliteit van de onderliggende datasets. Als dat niet werkbaar is vanwege hun grootte, moet je je minstens een idee vormen van de impact van mogelijke onregelmatigheden erin. Een data protection impact assessment is net daarvoor bedoeld, en is in sommige gevallen verplicht.

Het blind hergebruiken van een dataset die je zelf niet hebt samengesteld, is een slecht idee. Dat geldt bij uitbreiding eigenlijk ook voor het indirect gebruik ervan via een derde partij of een externe software-library. Dit is overigens een algemeen advies dat geldt voor elke toepassing van machine learning. Wie beter wil doen en ethiek wat hoger in het vaandel wil dragen, vindt goede startpunten in de paper Datasheets for Datasets en bij initiatieven zoals AI Now.

______________________

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.

Automatisering is een belangrijk wapen om het Mattheus-effect tegen te gaan. Het automatisch toekennen van bepaalde voordelen aan de hand van objectieve criteria zorgt idealiter voor een gelijke behandeling van alle burgers ongeacht stand en rang. Daarnaast zorgt automatisering ook voor tijdswinst, minder papier, en lagere kosten op lange termijn. Veel projecten waar Smals bij betrokken is, dragen daar aanzienlijk toe bij: ze besparen de overheid, burgers en bedrijven jaarlijks miljarden euro’s, om niet te zeggen tonnen papier, inkt en postzegels.

We schreven al uitvoerig over de talloze randvoorwaarden die opduiken als men Artificiële Intelligentie correct wil inzetten ([1], [2], [3], [4], [5], [6]), maar ook een gewone procesautomatisering, zelfs digitalisering, is niet zomaar vrijblijvend, en al zeker niet bij overheden. Automatisering is niet gelijk aan artificiële intelligentie, maar men geeft nog steeds een deel van de controle uit handen aan een machine. Naast winsten in snelheid en kostprijs, kan dat ook allerlei beperkingen introduceren. Door de schaalvergroting loopt het, als het fout loopt, ook ineens heel erg fout. Reden genoeg om reeds vanaf de planningsfase nauwgezet aandacht te besteden aan de bredere effecten van een automatiseringsproject.

Wil een geautomatiseerd proces goed werken, dan is het belangrijk dat het actief en “als een goede huisvader” wordt beheerd. Permanente monitoring is nodig zodat problemen snel gedetecteerd en opgelost kunnen worden. Manueel ingrijpen moet mogelijk blijven, het moet duidelijk zijn wie waarvoor verantwoordelijk is, en alles moet mee evolueren wanneer nodig. In het Engels wordt dat al eens aangeduid met (corporate) “governance“, vrij vertaald “deugdelijk bestuur”. Het is een vaag begrip, maar in dit artikel hoop ik het belang ervan te kunnen illustreren aan de hand van enkele spraakmakende voorbeelden uit het buitenland.

(afbeelding: “corporate governance”, (c) Asmi-corporatereporting.com, 2017, Licensed CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons)

Wat kan er zoal misgaan?

Frankrijk

De Franse Caisse des Allocations Familiale (CAF) nam in 2021 een nieuw systeem in gebruik voor de berekening van huisvestingstoelagen. Helaas was het systeem niet volledig compatibel met een ander systeem voor de registratie van sommige arbeidsprestaties, nodig om de hoogte van die uitkering te bepalen. Als gevolg kregen minstens 120.000 mensen een foutieve schuldvordering in de bus, automatisch aangemaakt, voor zogezegd teveel ontvangen uitkeringen. De toevloed aan reacties, en alle correcties die vaak manueel aangebracht moesten worden, zorgden voor veel extra werklast bij de dienst die al met veel vertragingen te kampen had, wat op zijn beurt aanleiding gaf tot stakingen. Negen maanden later wachtten nog steeds 32.000 mensen op de correctie van hun dossier.

Verenigd Koninkrijk

Het Verenigd Koninkrijk heeft geen rijksregister zoals België. Mensen moeten hun identiteit op een andere manier bewijzen: met een rijbewijs, bankrekening, telefooncontract of een internationaal paspoort. Dat zorgt al voor een eerste probleem, omdat net de meest kwetsbaren die het meeste belang hebben bij die diensten, door hun kleinere administratieve/digitale voetafdruk niet geauthenticeerd geraken. Daarnaast is identiteitsfraude een groot probleem.

Universal Credit is een geautomatiseerd sociaal vangnet voor de laagste inkomens, dat bestaat uit de fusie van 6 aparte uitkeringen. Hun doel om de zaken te vereenvoudigen hebben ze echter ook doorgetrokken in de berekeningswijze: die neemt enkel het inkomen van een vorige maand in rekening. Dat zorgt voor grote problemen bij mensen die onregelmatig betaald krijgen, of wanneer loon plots vervroegd uitbetaald wordt omwille van feestdagen: zij hebben in sommige maanden plots een hoger inkomen, in andere maanden geen, en krijgen daardoor heel erg fluctuerende uitkeringen. Het perverse effect daarvan is dat twee mensen met dezelfde job, gezinssamenstelling en jaarinkomen, toch verschillende uitkeringen kunnen krijgen, enkel en alleen omdat hun salaris op een ander moment wordt uitbetaald.

Een rechtszaak daarover werd door de Britse overheid verloren. Het maken van de opgedragen aanpassingen zal de kost van het geplaagde systeem, nu reeds lopend in de miljarden pond, alleen nog maar verder doen toenemen. Let wel dat het probleem hier niet zozeer bij de automatisering ligt, wel bij het ontwerp: de regering had expliciet besloten tot deze berekeningswijze, omdat ze gemakkelijker en efficiënter te implementeren was.

(afbeelding: Wordmark for Universal Credit, (c) UK Government, licensed under the Open Government Licence version 1.0 (OGL v1.0).

Australië

In Australië deed de RoboDebt affaire veel stof opwaaien. Frauduleus betaalde uitkeringen terugvorderen deden ze al langer, maar in 2015 maakten ze een cruciale verandering: het verifiëren van een “match” tussen de databanken sociale zekerheid (DHS) en financiën (ATO), werd geautomatiseerd. Dat nam effectief een stap van menselijke controle in de ketting weg. Het hoofddoel was om elke “match” op te volgen, daar waar ze vroeger slechts de meest flagrante inbreuken konden najagen omwille van het manuele werk. Dat leidde in het eerste jaar al tot een 40 keer hoger volume.

Helaas was niet elke “match” ook terecht. De uitkeringen werden immers in perioden van 14 dagen toegekend, terwijl de belastingdienst gegevens had per fiscaal jaar. Bij gebrek aan inkomstengegevens per 14 dagen werd een gemiddelde van het jaarinkomen toegepast, maar net zoals in het voorbeeld van UK, leidde dat tot ongewenste neveneffecten, en moesten burgers plots schulden gaan terugbetalen die ze nooit gemaakt hadden. In 2019 werd het systeem door de rechtbank onwettelijk verklaard, en in 2021 moest de overheid een schikking ter waarde van $1.8 miljard Australische dollar treffen met de bijna 500.000 gedupeerden. Ook hier lag de fout bij de wetgever, die niet voldoende had nagedacht over de aannames en mogelijke neveneffecten bij het opstellen van de berekeningswijze van het systeem.

USA

In de Verenigde Staten doken problemen op bij de automatisering van RAI. Dit Resident Assessment Instrument is een lange vragenlijst voor zwaar zorgbehoevenden. Aan de hand van het resultaat wordt o.a. berekend op hoeveel thuiszorg iemand een beroep mag doen. Ook in België wordt een variant ervan gebruikt die BelRAI heet. Het automatiseren daarvan moet heel omzichtig gebeuren. Als bijvoorbeeld de vraag of iemand voetproblemen heeft beantwoord wordt met “nee”, kan dat zijn omdat die gezond is, maar even goed omdat die geamputeerde voeten heeft – en die laatste behoeft uiteraard meer zorg.

In Arkansas liep het fout bij onderaannemers die een verkeerde versie van de vragenlijst hadden gebruikt, en daarnaast bepaalde ziektebeelden, zoals hersenverlamming, niet correct hadden verwerkt. Pas tijdens de rechtszaak werd duidelijk waar de fouten precies lagen, o.a. doordat de rechter verplichtte om de resultaten eens manueel na te rekenen. Het systeem bleek dermate complex, en de code werd zodanig afgeschermd, dat ook de bevoegde ambtenaren niet in staat waren geweest om de fout te ontdekken. Zo was het voor eindgebruikers nooit duidelijk waarom de evaluatie tot een bepaald resultaat leidde, wat het op zijn beurt erg moeilijk maakte een evaluatie aan te vechten of te overreden. Het gebruik van RAI op zich werd door de rechtbank wel als wettig beschouwd.

India

India heeft hetzelfde probleem als het Verenigd Koninkrijk, nl. dat het lange tijd geen eengemaakt burgerregister had en dat andere systemen (rijbewijzen, stembiljetten, geboorteaktes) onderling incompatibel zijn. Het bijhouden van gegevens op kaartjes en papieren is er ook geen sinecure voor de armeren en ongeletterden onder hun bevolking. In een ambitieus programma om iedere Indiër een sociaal identiteitsnummer te geven (zoals onze vroegere SIS-kaart), startte India het Aadhaar project, dat ook biometrische authenticatie op basis van de vingerafdruk omvat.

(afbeelding: “A sample of Aadhaar card”, by Pagelmp, licensed under the Creative Commons Attribution-Share Alike 4.0 International license. Source Wikimedia Commons.)

De praktijk blijkt echter weerbarstiger. Er zijn technologische vereisten om het te kunnen toepassen: een vingerafdruklezer en een stabiele internetverbinding. Bovendien zijn de vingerafdrukken niet altijd meer herkenbaar bij wie een leven lang handenarbeid heeft verricht. Ook fouten bij de manuele data-entry, wat tijd en geld kost om te laten corrigeren, zorgen voor problemen. Er duiken dan ook veel rapporten op van grote aantallen kwetsbaren die de toegang tot sociale diensten, onderwijs, vergunningen, kindergeld of voedselrantsoenen wordt ontzegd omdat ze door de mazen van het Aadhaar-systeem vallen.

Nederland

In Nederland viel de regering over de toeslagenaffaire. Vele duizenden gezinnen kwamen in grote problemen door onterechte beschuldigingen van subsidiefraude. De affaire is complex, maar aan de basis ligt de opsporingsdienst voor belastingfraude die zich danig heeft vergaloppeerd. Het probleem lag hier o.a. bij een gebrekkige training en validatie van een machine-learning model, dat een risicoclassificatie moest geven aan dossiers en daarbij zonder veel nadenken steunde op parameters zoals nationaliteit, die erg gevoelig zijn voor discriminatie. Daarnaast was de inhoud van verschillende onderliggende databanken, o.a. de Fraude Signalerings Voorziening, onoordeelkundig verzameld: een telefoontje naar de belastingdienst kon voldoende zijn om erin opgenomen te zijn als potentieel fraudeur. De opsporingsdienst vertrouwde echter quasi blindelings op de gegevens en risicoscores, en gebruikte ze als rechtvaardiging om drastisch te werk te gaan bij terugvorderingen, weigeringen van afbetalingsplannen, enz. Daarbij ontbrak het aan een richtinggevend kader van bovenaf, interne monitoring of audit, en mogelijkheden tot aantekenen van beroep. De databank werd op basis van inbreuken op de privacywetgeving stopgezet en de belastingdienst kreeg een stevige boete.

Conclusie

De bovenstaande verhalen hebben meestal 1 ding gemeen: alles gaat goed totdat op een bepaald moment ergens een bocht teveel wordt afgesneden zonder dat er tijdig wordt ingegrepen. Dat moet ons niet tegenhouden om te automatiseren, want er zijn ook duidelijke voordelen: voor de overheid qua schaalbaarheid, voor de burger o.a. door vermindering van administratie. Met dit artikel willen we vooral aandacht vestigen op de noodzaak om daarbij voldoende te investeren in planning en opvolging, om een goede grip te houden. Dat omvat ook een realistische blik, aandacht voor user experience en duidelijke adoptie van waarden en principes (transparantie, accountability, …).

Het grote verschil tussen een ambtenaar in persoon en een geautomatiseerd systeem, is dat een ambtenaar aanpassingen kan maken en verfijningen kan toebrengen nog voordat een beslissing genomen wordt, terwijl een algoritme enkel maar gecorrigeerd kan worden nadat het al een beslissing heeft gemaakt. Dat laatste veroorzaakt frustratie en een nood aan ingrijpen achteraf. Er is een risico dat bepaalde doelgroepen onevenredig het slachtoffer zijn van zulke fouten. Ook kan bij de gebruikers van geautomatiseerde systemen, een zekere verblinding, laksheid, of neiging tot het afschuiven van verantwoordelijkheid ontstaan: “de computer zegt het dus het zal wel zo zijn”. Er moeten dus toegankelijke procedures zijn om beroep aan te tekenen tegen een beslissing en correcties moeten eenvoudig doorgevoerd kunnen worden.

Daarnaast blijft het altijd mogelijk dat programmeurs de regels onvolledig of foutief inbrengen in een programma, of dat ze andere interpretaties en aannames hanteren dan de regelgevers. Er is dus nood aan een zekere waakzaamheid, transparantie en inspraak in het hele implementatieproces, zeg maar “project governance“. Ook de uitvoerende ambtenaren moeten blijven begrijpen wat er gebeurt en waarom. Daarbij hoort ook een goede methode om feedback te verwerken die vanop de werkvloer aangebracht wordt.

Er bestaat vooralsnog geen vaste manier om compliance of governance ontegensprekelijk te garanderen. Het zijn nog steeds vage begrippen, en ook nogal wat wetgeving blijft vaag: zo staat het woord “redelijk” maar liefst 38 keer in de GDPR, en het woord “passend” zelfs 125 keer, zonder verdere specificatie van wat we daar nu concreet onder moeten verstaan. In de VS worden basisregels voor bedrijfsbeheer opgelegd door de Sarbanes-Oxley Act. In België bestaan er de Code Lippens voor beursgenoteerde, en Code Buysse voor niet-beursgenoteerde ondernemingen. Ondertussen wordt in Europa verder gewerkt aan o.a. een Data Governance Act om een kader te scheppen voor verantwoord (her)gebruik van gegevens.

Deze en andere regulatorische raamwerken zijn misschien niet perfect sluitend. Ze adopteren, eventueel certifiëren, en regelmatig eraan toetsen, zorgt op korte termijn wel voor extra overhead en kosten, maar het legt de lat ook hoger en kan zo op lange termijn veel zorgen voorkomen. Het is ook meestal goede reclame. Uit alle aangehaalde voorbeelden blijkt natuurlijk ook dat daarvoor de nodige wil moet bestaan bij, en middelen ter beschikking gesteld moeten worden door, de bevoegde beleidsmakers.

______________________

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.

Cette contribution se situe dans une série d’articles sur les graphes de connaissances (les « knowledge graphs » en anglais). Nous vous présentons le Smals KG Checklist, un outil qui vous aide à déterminer si un graphe de connaissances serait utile, voire indispensable, pour résoudre un problème dans votre organisation. Le Smals KG Checklist a été présenté au sein du SEMANTiCS 2021, un congrès scientifique et industriel autour des graphes de connaissances.

La différence entre les graphes et les graphes de connaissances

Nous avons déjà traité les graphes de connaissances et les (bases de données) graphes. Mais quelle est la différence entre les deux? Dans les grandes lignes, les bases de données graphes nous permettent de stocker des données représentées en graphe et les graphes de connaissances sont un type de graphe spécifique qu’on stocke dans des bases de données graphes. Autrement dit, tous les graphes de connaissances sont des graphes mais l’inverse n’est pas vrai.

Quelles sont donc les caractéristiques qui séparent les graphes de connaissances des autres graphes? C’est une question qu’on se pose souvent dans l’industrie et la recherche. En 2020, Hogan et al. ont publié un rapport plutôt académique qui traite le sujet des graphes de connaissances. Ils présentent plusieurs définitions de ce concept, ce qui ajoute à la confusion.  Par contre, toutes ces définitions nous permettent de synthétiser les caractéristiques d’un graphe de connaissances. C’est un graphe qui représente des entités (sous forme de nœuds) et leurs relations (sous forme de d’arêtes), et qui adhère à trois conditions :

1. Le graphe intègre des informations de différentes sources hétérogènes : bases de données, documents, connaissances reprises dans les têtes des experts, …
2. Un schéma qui décrit les types et relations utilisés dans le graphe de connaissances. Ce schéma, également nommé ontologie, fait partie du graphe de connaissances.
3. Le graphe est utilisé pour déduire des informations implicites à travers les informations explicites. C’est-à-dire, d’utiliser le graphe de connaissances pour découvrir des nouvelles relations, types, etc. en utilisant des algorithmes ou des applications.

La première condition est évidente. La traduction d’une base de données relationnelle vers une base de données graphe peut être utile pour optimaliser les requêtes, mais le résultat n’est pas un graphe de connaissances ; le résultat non seulement ne combine pas d’autres informations, mais il manque aussi au résultat une description détaillée des concepts et relations et enfin, le résultat n’est utilisé que pour optimaliser un processus existant. Ce sont les deux autres conditions qui sont plus complexes et nuancées.

Le Schéma (ou ontologie) d’un graphe de connaissances

La définition d’un schéma (ontologie) d’un graphe de connaissances est : « une spécification formelle et explicite d’une conceptualisation partagée ». Cette définition semble compliquée, mais il suffit de comprendre chaque partie de cette définition.

Nous prenons par exemple l’ONSS et la Banque-Carrefour des Entreprises (BCE). L’ONSS et la BCE ont des informations sur des entreprises, mais de points de vue différents. Si l’ONSS et la BCE décident de partager des informations sur des entreprises, ils auront besoin d’une ontologie pour éviter des malentendus. La conceptualisation partagée inclut donc le concept « entreprise » et ses relations, définitions, règles, etc. Les représentants des deux parties se mettent d’accord sur cette conceptualisation partagée en discutant et en réutilisant des informations existantes (législations, glossaires, etc.). Cette conceptualisation partagée reste « dans la tête » des représentants, donc il faut mettre ces accords quelque part : on parle alors de la spécification. La spécification contient les descriptions et définitions de la conceptualisation. Mais la spécification doit être explicite, c’est-à-dire enregistrée quelque part (p. ex., un fichier) et cette spécification doit être formelle (logique ou mathématique) pour que des logiciels puissent l’utiliser.

Il existe des normes pour créer ces schémas ; RDFS et OWL sont deux exemples. RDFS nous permet de créer des hiérarchies de concepts et de relations. OWL est beaucoup plus expressif et nous permet de créer des règles pour valider un graphe de connaissances. Les use cases d’une organisation nous informent quelle langue est préférable. Ces langues nous permettent de décrire que :

• Chaque entreprise est un agent ;
• Chaque personne est un agent ;
• Une entité ne peut pas être à la fois une personne et une entreprise (possible avec OWL) ;
• Si une entité a un numéro BCE, cette entité est une entreprise ;
• …

En ajoutant des descriptions en langage naturel, ce schéma rend les données sémantiques pour les logiciels et les utilisateurs. En donnant la requête « donne-moi une liste des agents », un logiciel est capable d’interpréter le schéma et d’inclure les personnes et les entreprises.

Les bases de données graphes comme Neo4j ont souvent une notion de types de nœuds, mais ne soutiennent pas les relations entre ces types, par exemple. La réalisation d’un knowledge graph non seulement nécessite la construction du schéma, mais aussi l’utilisation de ce schéma en utilisant :

• une extension d’une base de données graphe ou d’une application sur cette base de données graphe capable d’interpréter un schéma. Un exemple est le RDF & Semantics Plugin de Neo4j ; ou
• des bases de données graphes conçues pour les graphes de connaissances comme Stardog et Apache Jena.

Le schéma est donc un graphe qu’on ajoute au graphe de données et qui est interprété d’une manière spécifique.

Déduire des informations implicites

La troisième condition est que le graphe de connaissances soit utilisé pour déduire des informations implicites ou « cachées » dans le graphe, en utilisant :

• L’intelligence artificielle symbolique (exploitant le schéma) ;
• L’intelligence artificielle statistique (machine ou deep learning) ;
• Des applications qui « comprennent » les graphes grâce au schéma.

Nous avons déjà évoqué l’IA symbolique dans la section précédente. En effet, le langage de schéma permet aux logiciels de déduire des informations. Si l’entité représentant Christophe est du type Personne, cet entité est aussi du type Agent. Ce genre d’IA utilise des logiques formelles pour arriver à ces déductions. L’usage de l’IA symbolique nécessite un schéma.

L’IA statistique, appliquée au graphes, nous permet de prédire des liens entre des entités ou même de prédire les catégories d’une nouvelle entité. L’usage d’un schéma nous permet de fournir des graphes plus riches, en déduisant un maximum d’informations, à ces algorithmes.

Et puis nous avons les applications « intelligentes » qui « comprennent » les graphes de connaissances. Ces applications exploitent le schéma et/ou le langage de schéma pour faciliter les tâches. Pour la recherche facettée, que nous connaissons tous des ventes en ligne, les types et les valeurs des relations sont interprétées pour créer des critères de recherche. Des outils comme Ontodia, traités dans un product review, nous permettent d’explorer et d’analyser les contenus d’un graphe de connaissances d’une manière visuelle. Ontodia non seulement interprète le schéma pour guider les fouilles, mais l’outil interprète aussi les contenus du graphe pour choisir les visualisations. Ces outils permettent donc aux usagers de découvrir eux-mêmes des nouvelles informations dans le graphe de connaissances.

Le Smals KG Checklist

Reconnaitre la différence entre les graphes et les graphes de connaissances n’est pas évident, non seulement pour des informaticiens non-spécialistes mais aussi, et surtout, pour les organisations. Au sein de Smals et ses membres, par exemple, l’usage et les possibilités des bases de données graphes sont reconnus ; pour faciliter, entre autres, les analyses de réseau. Mais quand est-ce qu’un projet nécessite un graphe de connaissances ? Pour répondre à cette question, Smals Research a développé le Smals KG Checklist. A partir d’une problématique concrète, le but du Smals KG Checklist est de déterminer si une solution à cette problématique requiert les trois conditions remplies et le développement d’un graphe de connaissances est une piste valable.

La checklist, disponible en PDF sous licence Creative Commons, se compose de deux parties.  Dans la première partie, nous allons d’abord : 1) décrire la problématique, 2) identifier les parties prenantes, et 3) identifier les concepts clefs (partagés par les parties prenantes). Les réponses à ces trois questions nous donnent un cadre pour les discussions suivantes.

La quatrième question se compose de trois blocs, une pour chaque condition, et chaque bloc à sa propre couleur. Ces trois blocs requièrent l’usage de la deuxième partie de la checklist et nous y retrouvons les mêmes couleurs.

Le violet correspond au schéma du graphe de connaissances. Nous retrouvons, dans la Section I, la connaissance des experts, la réutilisation des ontologies, la formalisation des législations, … et même la réutilisation des schémas existants. Les schémas des bases de données (relationnelles) contiennent souvent une représentation de nos concepts et relations que nous pouvons « réutiliser ». Si une des cases de la Section I est remplie (ou, voir plus tard, une des cases de la Section V), cette condition est remplie.

Le vert correspond à l’intégration des informations et données. Dès que plusieurs cases dans ces sections sont cochées, cette condition est remplie. Mais d’où viennent ces informations et ces données ?

• Section II se focalise sur l’intégration des données structurées (bases de données, fichiers Excel, …)
• Section IV se focalise sur l’intégration des données non-structurées (documents, Tweets, …)
• Section III, au milieu des sections II et IV, se focalise sur les métadonnées (d’où viennent les informations, leurs dates de créations, …)

Remarquez que la Section I a deux couleurs. La connaissance des experts peut contribuer au schéma et au graphe, par exemple. Dès que nous intégrons des bases de données existantes, nous allons (souvent) utiliser les schémas de ces bases de données pour le schéma du graphe de connaissances (surtout quand nous devons créer le schéma nous-même).

L’orange correspond à la découverte des informations implicites. Les Section V, VI, et VII correspondent respectivement avec l’IA symbolique, l’IA statistique, et les applications. Remarquez que la Section V nécessite un schéma et que la section VII est à moitié remplie en orange. Nous pouvons argumenter que la consultation des entités sous forme de page Web (comme, par exemple la page de Bruxelles de la graphe de connaissances DBpedia) est utile pour les utilisateurs, mais pas vraiment une application intelligente. Nous essayons de capter les applications intelligentes : c’est à dire celles qui interprètent le graphe de connaissances. Si une des cases dans les Section V et VI est remplie et/ou des applications intelligentes sont identifiées, la condition est remplie.

Une fois que les trois blocs de la première partie sont complétés, nous sommes capables de répondre à la cinquième question : est-ce que les trois conditions sont remplies ? Si oui, il est probable qu’un graphe de connaissances soit une solution (élégante) à cette problématique. La sixième question, en gris, nous permet d’enregistrer des pistes pour élargir le graphe de connaissances.

Une démonstration

En conclusion

Cet article de blog est une contribution individuelle de Christophe Debruyne, spécialisé en knowledge graph chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

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.