(NL) Neosemantics is een Java plug-in voor Neo4J, ontworpen om RDF-semantische tools toegankelijk te maken voor direct gebruik binnen Neo4J.

Graphs, en meer bepaald knowledge graphs, maken het mogelijk om informatie op een gestructureerde manier weer te geven. Zo krijgt een persoon een visuele samenvatting van de inhoud van een of meerdere documenten en kan een machine deze structuur gebruiken om bijvoorbeeld de inhoud ervan te analyseren (met behulp van graphalgoritmen) en/of redeneringen te maken op basis van de graph (bijvoorbeeld in het kader van een graphRAG-toepassing of om impliciete informatie te ontdekken (af te leiden)).

Dit artikel gaat in op de manieren waarop een graph kan worden verkregen op basis van tekstuele data, de verschillende soorten graphs die kunnen worden geëxtraheerd en de tools die vaak worden gebruikt, afhankelijk van het type extractie dat men wil uitvoeren.

Aangezien grote taalmodellen (LLM’s) bijzonder geschikt zijn voor tekstverwerking, zal dit artikel zich voornamelijk richten op de presentatie van LLM-gebaseerde benaderingen en vervolgens kort ingaan op verschillende alternatieve benaderingen.

Knowledge graphs: een kort overzicht

Een graph is een structuur die bestaat uit een reeks nodes en bogen (die paren van nodes met elkaar verbinden). Een knowledge graph voegt een extra semantische laag toe aan een klassieke graph, waarbij elke node een concept vertegenwoordigt (entiteit, persoon, enz.) en elke boog een relatie tussen twee concepten vertegenwoordigt (“werkt voor”, “is bevriend met”, enz.). Het is dus een weergave van kennis in de vorm van een reeks onderling verbonden entiteiten. Meer details over de verschillende soorten graphs en de bijbehorende tools vindt u hier.

Voorbereiding van het documentcorpus

Voor de eenvoud gaan we ervan uit dat de tekstdocumenten die worden gebruikt om de graph op te bouwen, correct zijn opgeschoond. Dit artikel is namelijk niet bedoeld om de voorbewerking van tekstdocumenten (scrapen van webpagina’s, extraheren van tekst uit pdf-bestanden, enz.) te bespreken, aangezien deze voorbewerking op zich al een uitgebreid onderwerp is dat ongetwijfeld een apart artikel verdient.

Fragmentatie van de tekst in “chunks”

Een belangrijke stap in de voorbereiding van tekstdata voordat entiteiten en relaties worden geëxtraheerd, is het opsplitsen van de tekst in fragmenten (meestal ‘chunks’ genoemd). We hebben het concept van chunking al meerdere keren besproken in vorige blogposts. Wanneer een document te lang is (meer dan enkele paragrafen), is het raadzaam om het op te splitsen in chunks (tekstfragmenten van redelijke omvang) die één voor één door de LLM worden verwerkt. Deze procedure maakt het mogelijk om de hoeveelheid informatie in elke chunk te beperken, zodat deze niet te veel entiteiten en relaties bevat die moeten worden geëxtraheerd. Deze opsplitsing in chunks kan op verschillende manieren gebeuren, hetzij op basis van het aantal woorden in de chunk, hetzij op basis van een vooraf gedefinieerd scheidingsteken (bijvoorbeeld een regeleinde dat het einde van de paragraaf aangeeft).

De informatie weergeven of de structuur weergeven

Laten we beginnen met de twee belangrijkste soorten graphs die kunnen worden geconstrueerd op basis van een reeks tekstdocumenten.

De eerste is een graph die de structuur van het document weergeeft (document structure graph), en niet de informatie die in de tekst staat. Bijvoorbeeld door de chunks te koppelen aan het document waaruit ze zijn gehaald en de volgorde waarin ze in het document voorkomen:

Dit type graph kan ook worden verrijkt door relaties toe te voegen tussen semantisch vergelijkbare chunks of, indien van toepassing, door de hiërarchische organisatie van het document weer te geven in secties, subsecties, enz. Dit gebeurt via nodes die de secties/subsecties vertegenwoordigen en relaties van het type “HAS_SECTION”, “HAS_SUBSECTION”, evenals relaties die de volgorde van de secties/subsecties aangeven. Zodra de graph is opgebouwd, kan deze bijvoorbeeld worden gebruikt in RAG-toepassingen voor indexeringsdoeleinden om context te bieden aan de gebruikte chunks (zie onze blogpost over graphRAG).

Het tweede type graph bestaat uit het opnemen van de informatie in de documenten in de vorm van nodes en relaties:

In het kader van deze blogpost zullen we ons concentreren op dit tweede type graph. Merk op dat beide benaderingen elkaar niet uitsluiten. Als men voor het tweede type graph kiest, is het trouwens vaak nuttig om ook de documentstructuur weer te geven. Zo kan men indien nodig teruggaan naar de bron van de informatie in de graph.

Opbouw van een knowledge graph met behulp van een LLM

Eerst zullen we de algemene procedure voor het aanmaken van een knowledge graph op basis van tekstdocumenten via LLM voorstellen, alvorens te bekijken hoe deze aan de eigen behoeften kan worden aangepast.

LLM’s ontvangen standaard tekst als input (prompt) en sturen tekst terug als output in reactie op de prompt. Afhankelijk van de instructies bieden LLM’s echter de mogelijkheid om gestructureerde outputs te genereren, zoals JSON-bestanden. Vaak wordt deze functionaliteit gebruikt als basis voor het extraheren van kennis naar een graph, omdat deze gestructureerde output systematisch kan worden verwerkt.

Een script (bv. Python) haalt de chunks op en stuurt ze een voor een naar de LLM door een gestructureerd antwoord op te leggen (bv. LangChain met de methode llm.with_structured_output()), met instructies over de taak, het type informatie dat in de tekst moet worden gedetecteerd en de structuur van het verwachte antwoord in de output. De gestructureerde output (meestal in JSON) wordt vervolgens eenvoudigweg ontleed in Python om de door de LLM gedetecteerde informatie (nodes/relaties) op te halen, die vervolgens rechtstreeks aan de graph kan worden toegevoegd (via een databasedriver).

Interessant is dat LLM’s een grote verscheidenheid aan antwoorden kunnen geven en dat het gebruik van gestructureerde output niet altijd nodig is. In sommige gevallen is het nog steeds het eenvoudigst om de LLM te vragen zijn extracties te leveren in de vorm van queries (bijvoorbeeld queries die de gedetecteerde nodes/relaties direct toevoegen), die als zodanig kunnen worden uitgevoerd, of in de vorm van RDF triples.

Na de algemene procedure, kijken we nu meer in detail naar de verschillende manieren om de informatie in de chunks binnen een graph te extraheren en weer te geven, te beginnen met de eenvoudigste benadering (thema-extractie) tot de meest complete (extractie van entiteiten en relaties).

Thematische extractie

In deze eerste benadering richten we ons op het opsporen en extraheren van de thema’s die in het document aan bod komen. We bouwen dus een thematische weergave van de verschillende documenten in het corpus om een structuur te verkrijgen van het type:

De graph heeft dus een lichte structuur en wordt gebruikt voor referentiedoeleinden, om gemakkelijk en snel documenten te identificeren die betrekking hebben op een (of meerdere) bepaald(e) onderwerp(en) van belang. Met dit type graph kunnen ook gelijkenissen tussen documenten (of tussen chunks) worden vastgesteld op basis van de gemeenschappelijke onderwerpen, of kan eenvoudigweg een schematische weergave worden gegeven van hun corpus van documenten en de thema’s die daarin aan bod komen.

Dit kan op een niet-gestuurde manier (de LLM vrij laten bepalen welke thema’s in de chunk aan bod komen) of op een gestuurde manier gebeuren (de LLM kiest een of meer thema’s uit een vooraf gedefinieerde lijst met thema’s die in de instructies van de prompt wordt gegeven).

Extractie van named entities

De extractie (of herkenning) van named entities (named-entity recognition, vaak afgekort tot NER) is een bekend domein van natuurlijke taalverwerking (natural language processing (NLP)) dat bestaat uit het detecteren en categoriseren van entiteiten (personen, organisaties, plaatsen, enz.) die in een tekst worden genoemd. Het doel is dus vergelijkbaar met dat van thematische extractie: een graph maken door tekstfragmenten te koppelen aan de entiteiten die erin worden genoemd. We krijgen dus een graph met het volgende standaard schema:

Met dit type graph kunnen ook gelijkenissen tussen documenten (of tussen chunks) worden vastgesteld op basis van de entiteiten die ze gemeenschappelijk hebben. Het is interessant om op te merken dat deze extractie vergelijkbaar is met een volledige extractie (inclusief entiteiten en relaties, zie onderstaande paragraaf), behalve dat hier alleen de entiteiten worden geëxtraheerd en niet de relaties die ze met elkaar verbinden. Dit is een lichtere en gemakkelijker te implementeren oplossing wanneer een volledige extractie niet nodig is.

Dit soort extractie kan gemakkelijk worden uitgevoerd met behulp van een LLM met gestructureerde outputs. Met het pydantic-pakket kunnen op maat gemaakte templates worden gemaakt voor de verwachte outputstructuur. Bijvoorbeeld:

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

In dit eenvoudige voorbeeld wordt de LLM gevraagd om een gestructureerde output van het type “Extraction” terug te geven, met als attribuut “entityList”, een lijst van “Entity”-objecten “ die net daarvoor zijn gedefinieerd.

Het is interessant om op te merken dat dit type template kan worden uitgebreid wanneer we extra informatie willen extraheren of het type gedetecteerde entiteiten willen beperken. Als we bijvoorbeeld alleen entiteiten van het type “persoon” en “onderneming” willen detecteren, kan de template worden aangepast door de klassen “ Persoon” en “Onderneming” aan te maken, waarin de attributen worden opgesomd die voor elke instantie van deze entiteiten moeten worden geëxtraheerd, en door het veld ”entityList“ te vervangen door twee velden “personList” en ”enterpriseList” in het uiteindelijke object dat moet worden teruggegeven.

Het voordeel van het gebruik van de methode with_structured_output is dat LangChain automatisch controleert of de output van de LLM overeenkomt met de template.

Extractie van entiteiten en relaties

Het doel hier is het bouwen van een graph die de kennis in het document of de documenten weergeeft in de vorm van onderling verbonden entiteiten (nodes) en relaties. Dit is de meest uitgebreide (en meest ingewikkelde) taak die we in detail zullen bekijken.

Laten we het volgende stukje tekst nemen om te illustreren wat voor soort extractie we hier willen uitvoeren:

“The San Fransisco-based 9th U.S. Circuit Court of Appeals rejected the legal challenge by the Federal Trade Commission to Microsoft’s $69 billion acquisition of Activision Blizzard, the developer of “Call of Duty.” A three‑judge panel unanimously upheld a lower court’s decision denying a preliminary injunction, finding that the FTC had not demonstrated a likelihood of success in proving the merger would harm competition. The acquisition, completed in late 2023 following UK regulatory approval, is the largest ever in the video gaming industry.”
(Source: adapted from Reuters, 2025).

Zodra de informatie is geëxtraheerd, is dit een voorbeeld van een graph die op basis van deze tekst kan worden gemaakt:

Dit type extractie kan op veel verschillende manieren worden uitgevoerd. Het volgende deel is speciaal gewijd aan de verschillende benaderingen om een volledige extractie uit te voeren, en aan de voor- en nadelen daarvan.

Welke benaderingen zijn er voor het extraheren van entiteiten en relaties?

Handmatige extractie versus speciale tools

Een dergelijke graph kan manueel worden opgebouwd volgens de techniek die in het vorige deel werd voorgesteld (een prompt met instructies en de chunk naar de LLM sturen, de gestructureerde output ophalen en ontleden, en vervolgens de graph bijwerken via queries), ofwel biedt LangChain een tool aan om deze verschillende taken te automatiseren via de LLM Graph Transformer.

Deze tool vereenvoudigt de procedure door de instructies aan de LLM, het opstellen van de template en de verwerking van de gestructureerde output voor zijn rekening te nemen. De tool biedt verschillende instelmogelijkheden, zoals de mogelijkheid om de soorten nodes die gedetecteerd moeten worden te beperken (bv. alleen nodes van het type “Person”, “Company” en “Location”), de soorten relaties te beperken of de instructieprompt aan te passen.

Bovendien geeft een LLMGraphTransformer-instantie een lijst terug met objecten van het type GraphDocument, die de gedetecteerde nodes en relaties bevat en die direct kan worden gebruikt door verschillende LangChain-drivers naar graph-gerichte databases (zoals Memgraph, TigerGraph, Neo4j, enz.), om de geëxtraheerde entiteiten en relaties direct in de graph te importeren.

Hieronder volgt een voorbeeld van het extraheren van data uit een lijst met chunks met behulp van de LLMGraphTransformer-tool, gevolgd door het importeren van de entiteiten en relaties naar Neo4j:

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

Er bestaat ook een gratis alternatief voor Neo4j, waarvoor geen programmering nodig is: de Neo4j LLM Knowledge Graph Builder. Deze online tool neemt alle stappen voor zijn rekening, van de voorbewerking van documenten (pdf, webpagina) tot de opbouw van de resulterende knowledge graphs, en biedt tal van personaliseringsopties (het beperken van de te detecteren entiteit- en/of relatietypes, enz.). Zie hier voor meer details.

Vrije extractie versus begeleide extractie

Merk op dat als er met deze tools geen beperkingen (op de soorten entiteiten en relaties die moeten worden geëxtraheerd) worden gedefinieerd, ze in alle vrijheid alle informatie zullen extraheren die ze kunnen vinden. Dit soort “blinde” extractie kan eventueel worden gebruikt voor kleine documenten, of in gevallen waarin men van tevoren niet weet wat voor soort structuur men kan extraheren, maar het is over het algemeen beter om van tevoren de gewenste ontologie voor de graph vast te leggen.

Vrije extractie is namelijk vaak een probleem om verschillende redenen:

Explosie van entiteitstypen en relaties 

Naarmate de omvang of het aantal documenten toeneemt, bestaat het risico dat er al snel een zeer groot aantal verschillende soorten entiteiten en relaties in de graph terechtkomen, waardoor deze moeilijk te gebruiken kan worden (bijvoorbeeld voor RAG-toepassingen).

Inconsistentie van types

Bij gebrek aan een ontologie die een duidelijke nomenclatuur biedt, bestaat het risico van inconsistentie in de gedetecteerde types (een bedrijf kan bijvoorbeeld worden gelabeld als “Enterprise”, een ander als “Company” en een derde als “Organization”). In de praktijk kunnen dit soort problemen achteraf worden opgelost door alle soorten nodes op te sommen en semantisch verwante soorten te groeperen.

Problemen met reïficatie

Per definitie verbindt een relatie in een graph een node met een ander node. Er kan een probleem ontstaan wanneer een entiteit moet worden gekoppeld aan informatie die in de vorm van een relatie is gemodelleerd. Om het probleem te illustreren, nemen we als voorbeeld de overname van Activision Blizzard door Microsoft. Stel dat een eerste stuk tekst alleen deze overname vermeldt zonder verdere details, dan wordt deze hoogstwaarschijnlijk opgeslagen in de vorm:

(Microsoft)-[ACQUIRES]->(Activision Blizzard)

Stel dat de volgende chunk de informatie “The FTC challenged the acquisition…” vermeldt, dan hebben we een probleem omdat het niet meer mogelijk is om

(FTC)-[CHALLENGES]->(Acquisition)

te modelleren, aangezien de overname eerder werd gemodelleerd in de vorm van een relatie en niet als een node waarnaar door een relatie kan worden verwezen.

In dit geval kan de relatie bijvoorbeeld worden verwijderd en vervolgens worden vervangen door een node, zodat ernaar kan worden verwezen:

(Microsoft)-[INITIATES]->(Acquisition)-[TARGETS]->(Activision Blizzard)

Dit proces, dat reïficatie wordt genoemd, verloopt niet automatisch en vereist een extra verrijkingsstap om mogelijke verwijzingen naar informatie die in de vorm van relaties is gemodelleerd, op te sporen en indien nodig te reïficeren.

Enkele alternatieven voor LLM’s

Nu we een reeks benaderingen hebben bekeken die specifiek op LLM’s zijn gebaseerd, worden in dit gedeelte enkele alternatieve tools voorgesteld die zijn gebaseerd op klassieke NLP-methoden.

Voor wie alleen named entities wil extraheren, is hier een blogpost over dit onderwerp te vinden, evenals een voorbeeld van de toepassing van NER bij PII-filtering.  Er zijn tal van vooraf getrainde NER-modellen beschikbaar op platforms zoals Hugging Face.

Het extraheren van entiteiten en relaties kan doorgaans op twee verschillende manieren gebeuren:

• Extractie in twee afzonderlijke stappen: eerst wordt een NER gebruikt voor het detecteren en categoriseren van entiteiten, gevolgd door een extractie van relaties op basis van de tekst en de gedetecteerde entiteiten, om de relaties tussen deze entiteiten te bepalen. Enkele voorbeelden van tools voor het extraheren van relaties zijn openNRE, spacy-relation-extraction en GliREL.
• End-to-end-extractie: tools die entiteiten en relaties in één stap extraheren, zoals OpenIE, Relik, REBEL of Diffbot (commerciële oplossing).

Nagaan of de gedetecteerde gegevens conform zijn

De grote kracht van LLM’s voor dit soort extractietaken is hun begrip van natuurlijke taal, waardoor de extractie kan worden gepersonaliseerd door de instructieprompt aan te passen. Als er bijvoorbeeld geen outputtemplate bestaat voor het gestructureerde antwoord (waar de LLM moeite mee kan hebben als de template te ingewikkeld wordt), is het mogelijk om ontologieconforme nodes en relaties te verkrijgen door de ontologie rechtstreeks in de instructieprompt te beschrijven, maar het is belangrijk om alert te blijven voor extracties. Er is namelijk geen garantie dat de LLM geen fouten maakt en geen niet-conforme relatie/entiteit als output teruggeeft.

In het algemeen geldt dat wanneer een LLM (of een andere tool) wordt gebruikt om automatisch informatie uit een tekst te extraheren naar een knowledge graph, het nuttig is om te controleren of datgene dat is geëxtraheerd wel degelijk in overeenstemming is met de ontologie en trouw is aan de informatie in de bron.

1. Controleren of de extractie voldoet aan de ontologie

In een vorige blogpost hebben we al vermeld dat het mogelijk is om de structuur en inhoud van een knowledge graph te valideren met behulp van de SHACL-standaard. Dit is een taal die de verschillende beperkingen bevat die van toepassing zijn op een knowledge graph. Het is mogelijk om ofwel een definitieve validatie van de graph uit te voeren, om te controleren of de inhoud daadwerkelijk voldoet aan de in SHACL geformuleerde beperkingen (en de data die deze beperkingen overtreden op te sommen), ofwel deze validaties transactioneel uit te voeren bij elke nieuwe toevoeging van informatie, om elke nieuwe onrechtmatige toevoeging te weigeren. Hoewel SHACL oorspronkelijk bedoeld was voor graphs in RDF, kunnen sommige databases toch SHACL-beperkingen interpreteren en de graph valideren, zoals Neo4j met het neosemantics package (n10s).

2. Nagaan of de extractie correct is

Het risico van automatische extractie is dat informatie die in de graph wordt ingevoerd feitelijk onjuist is ten opzichte van de oorspronkelijke tekst, wat in het bijzonder problematisch kan zijn als deze graph wordt gebruikt als potentiële informatiebron (bijvoorbeeld voor een graphRAG-toepassing). Er kunnen verschillende benaderingen worden gevolgd. De eenvoudigste is een menselijke controle van de geëxtraheerde informatie, maar dit kan moeilijk of zelfs onhaalbaar worden wanneer de documenten te lang/talrijk worden. De andere aanpak bestaat erin een tweede LLM te gebruiken om te controleren wat uit elk fragment is geëxtraheerd. Zoals we in de post over de evaluatie van LLM’s hebben vermeld, is het voor LLM’s gemakkelijker om achteraf fouten op te sporen dan ze te vermijden.

Conclusie

Deze technologieën zijn weliswaar krachtig, maar nooit perfect. Behalve vrije (blinde) extractie, die kan resulteren in een moeilijk bruikbare graph, vormt het opstellen van een knowledge graph op basis van tekst een taak die veel werk vereist. En dit zowel vooraf (voorbewerking van teksten, opstellen van een ontologie voor de graph op basis van de inhoud van de tekst), als achteraf (validatie van de structuur van de graph ten opzichte van de ontologie en controle van de juistheid en betrouwbaarheid van de inhoud).

Dit is een ingezonden bijdrage van Pierre Leleux, data scientist et network data analyst bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Les graphes, et plus particulièrement les graphes de connaissances, permettent de représenter l’information de manière structurée. Cela permet, pour un humain, d’avoir une représentation (synthèse visuelle) du contenu d’un ou de plusieurs documents et, pour une machine, d’exploiter cette structure afin, par exemple, d’en analyser le contenu (via l’utilisation d’algorithmes de graphe) et/ou de raisonner sur le graphe (par exemple dans le cadre d’une application de graphRAG ou pour découvrir (inférer) de l’information implicite).

Cet article s’intéresse aux façons dont une représentation graphe peut être obtenue à partir de données textuelles, les différents types de graphe qui peuvent être extraits, et les outils fréquemment utilisés suivant le type d’extraction que l’on souhaite effectuer.

Il est à noter que, puisque les grands modèles de langage (LLM) sont particulièrement adaptés pour le traitement de texte, cet article se concentrera principalement sur la présentation d’approches basées sur les LLM et discutera rapidement, dans un second temps, de différentes approches alternatives.

Les graphes de connaissances : un rappel rapide

Un graphe est une structure composée d’un ensemble de nœuds et d’arcs (qui lient des paires de nœuds). Un graphe de connaissances ajoute une couche sémantique supplémentaire à un graphe classique, où chaque nœud représente un concept (entité, personne, etc.) et chaque arc représente une relation entre deux concepts (« travaille pour », « est ami avec », etc.). Il s’agit donc d’une représentation de la connaissance sous forme d’un ensemble d’entités interconnectées. Plus de détails sur les différentes formes de graphes et les outils associés peuvent être trouvés ici.

Préparation du corpus de documents

Il est à noter que, pour des raisons de simplicité, nous faisons l’hypothèse que les documents de texte utilisés pour construire le graphe ont été correctement nettoyés. En effet, cet article n’a pas pour but de discuter de l’aspect relatif au prétraitement des documents de texte (scrapping de pages web, extraction de texte à partir de fichiers pdf, etc.), car ce prétraitement est déjà, en tant que tel, un vaste sujet méritant sans doute un article dédié.

Fragmentation du texte en « chunks »

Une étape importante de la préparation des données de texte avant d’en extraire les entités et relations est la division du texte en fragments (généralement appelés « chunks »). Nous avons déjà mentionné le concept de chunking à plusieurs reprises dans de précédents articles. Si un document est trop long (plus de quelques paragraphes…) il convient de le séparer en chunks (fragments de texte de taille raisonnable) qui seront traités un à un par le LLM. Cette procédure permet de limiter la quantité d’information présente dans chaque chunk, pour éviter que celui-ci ne contienne une quantité trop importante d’entités et de relations à extraire. Cette séparation en chunks peut se faire de différentes manières, soit sur la base du nombre de mots dans le chunk, soit sur la base d’un séparateur prédéfini (par exemple : un passage à la ligne qui indiquerait la fin du paragraphe).

Représenter l’information ou représenter la structure

Commençons par regarder les deux principaux types de graphe qui peuvent être construits à partir d’un ensemble de documents textuels.

Le premier est un graphe qui va présenter la structure du document (document structure graph), et non pas l’information qui est contenue dans le texte. Par exemple, en reliant les chunks au document d’où ils sont tirés ainsi que l’ordre d’apparition de ceux-ci dans le document :

Ce type de graphe peut aussi être enrichi en ajoutant des relations entre chunks sémantiquement similaires ou, le cas échéant, en représentant l’organisation hiérarchique du document en sections, sous-sections, etc. Cela se fait via des nœuds représentant les sections/sous-sections et des relations de type « HAS_SECTION », « HAS_SUBSECTION », ainsi que des relations indiquant l’ordre des sections/sous-sections. Une fois le graphe construit, il peut par exemple être utilisé dans des applications de RAG à des fins d’indexation pour fournir du contexte aux chunks utilisés (voir notre article sur le graphRAG).

Le second type de graphe consiste à capturer l’information contenue dans les documents sous la forme de nœuds et de relations :

Dans le cadre de cet article, nous nous concentrerons sur ce second type de graphe. Il est à noter que les deux approches ne sont pas mutuellement exclusives. D’ailleurs, il est souvent utile, si l’on souhaite opter pour le deuxième type de graphe, de représenter également la structure des documents. Cela permet, si nécessaire, de pouvoir remonter à la source des informations présentes dans le graphe.

Construction d’un graphe de connaissances à l’aide d’un LLM

Dans un premier temps, nous allons présenter la procédure générale à suivre pour la création d’un graphe de connaissances à partir de documents textuels via LLM, avant de voir comment l’adapter suivant ses besoins.

Les LLMs, par défaut, reçoivent en entrée du texte (prompt) et renvoient en sortie du texte généré en réponse au prompt. Cependant, suivant les instructions, les LLM offrent la possibilité de générer des outputs structurés tels que des fichiers JSON. C’est souvent sur la base de cette fonctionnalité que se base l’extraction de connaissances vers un graphe, car cet output structuré pourra être traité de façon systématique.

Un script (par ex. python) va récupérer les chunks et les envoyer un à un au LLM en imposant une réponse structurée (par ex. langchain avec la méthode llm.with_structured_output()), avec des instructions concernant la tâche, le genre d’information à détecter dans le texte, et la structure de la réponse attendue en sortie. L’output structuré (typiquement en JSON) est ensuite simplement décomposé en python afin de récupérer les informations (nœuds/relations) détectées par le LLM, qui peuvent ensuite être directement ajoutées au graphe (via un database driver).

Il est intéressant de noter que les LLM peuvent fournir une grande diversité de réponses, et l’utilisation d’une sortie structurée n’est pas forcément toujours nécessaire. Dans certains cas, le plus simple est encore de demander au LLM de fournir ses extractions sous la forme de requêtes (par exemple, de requêtes qui ajoutent directement les nœuds/relations détectées), qui peuvent être exécutées telles quelles, ou sous forme de triplets RDF.

Maintenant que nous avons vu la procédure générale, nous allons regarder plus en détail les différentes façons d’extraire et de représenter l’information contenue dans les chunks au sein d’un graphe, en commençant par l’approche la plus simple (extraction de thèmes) jusqu’à la plus complète (extraction d’entités et de relations).

Extraction thématique

Dans cette première approche, on va s’intéresser à la détection et l’extraction des thèmes abordés dans le document. On y construit donc une représentation thématique des différents documents du corpus de sorte à obtenir une structure de type :

Le graphe a donc une structure légère et est utilisé à des fins de référencement, afin d’identifier facilement et rapidement les documents traitant d’un (ou plusieurs) sujet(s) d’intérêt donné(s). Ce type de graphe permet aussi d’établir des similarités entre documents (ou entre chunks) sur la base des sujets qu’ils ont en commun, ou simplement d’avoir une représentation schématique du corpus de documents et des thèmes qui y sont abordés.

Cela peut se faire soit de façon non-dirigée (laisser le LLM déterminer librement de la liste des thèmes abordés dans le chunk), soit dirigée (le LLM choisit un ou plusieurs thèmes parmi une liste prédéfinie de thèmes fournie dans les instructions du prompt).

Extraction d’entités nommées

L’extraction (ou reconnaissance) d’entités nommées (named-entity recognition, souvent abrégé en NER) est un domaine bien connu du traitement du langage naturel (natural language processing (NLP)) qui consiste à détecter et catégoriser les entités (personne, organisation, lieu, etc.) qui sont nommées dans un texte. L’objectif va donc être similaire à celui de l’extraction thématique : créer un graphe en liant les chunks de texte aux entités qui y sont mentionnées. Nous obtenons donc un graphe avec le schéma-type suivant :

Ce type de graphe permet aussi d’établir des similarités entre documents (ou entre chunks) sur la base des entités qu’ils ont en commun. Il est intéressant de noter que cette extraction est similaire à une extraction complète (incluant entités et relations, voir section ci-dessous), si ce n’est qu’ici seules les entités sont extraites, et pas les relations qui les interconnectent. Il s’agit d’une solution plus légère et facile à mettre en place, lorsqu’une extraction complète n’est pas nécessaire.

Ce genre d’extraction peut se faire facilement par l’utilisation de LLM avec outputs structurés. Le package pydantic permet de créer des templates sur mesure pour la structure attendue en sortie. Par exemple :

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

from pydantic import BaseModel, Field
from typing import List
class Entity(BaseModel):
    category: str = Field(description="The category of the entity.")
    name: str = Field(description="The name of the entity.")
class Extraction(BaseModel):
    entityList: List[Entity] = Field(description="The list of extracted entities.")
structured_llm = llm.with_structured_output(Extraction)
extracted=structured_llm.invoke(myPrompt)

Dans cet exemple simple, on demande au LLM de retourner une sortie structurée de type « Extraction », avec comme attribut « entityList » qui est une liste d’objets « Entity » définis juste avant.

Il est intéressant de noter que ce type de template peut être enrichi si l’on souhaite extraire des informations supplémentaires ou contraindre le type d’entités détectées. Par exemple, si l’on souhaite uniquement détecter des entités de type « personne » et « entreprise », le template peut être modifié en créant des classes « Personne » et « Entreprise », dans lesquelles on listera les attributs que l’on souhaite extraire pour chaque instance de ces entités, et en remplaçant le champs « entityList » par deux champs « personList » et « enterpriseList » dans l’objet final à retourner.

L’avantage d’utiliser la méthode with_structured_output est que langchain vérifiera automatiquement que la sortie du LLM est bien conforme au template.

Extraction d’entités et de relations

L’objectif ici est la construction d’un graphe qui va représenter la connaissance contenue au sein du ou des documents sous la forme d’entités (nœuds) interconnectées (relations). Il s’agit de la tâche la plus complète (et la plus compliquée), sur laquelle nous allons nous pencher le plus en détail.

Prenons le chunk de texte suivant, afin d’illustrer le genre d’extraction que nous souhaitons réaliser ici :

“The San Fransisco-based 9th U.S. Circuit Court of Appeals rejected the legal challenge by the Federal Trade Commission to Microsoft’s $69 billion acquisition of Activision Blizzard, the developer of “Call of Duty.” A three‑judge panel unanimously upheld a lower court’s decision denying a preliminary injunction, finding that the FTC had not demonstrated a likelihood of success in proving the merger would harm competition. The acquisition, completed in late 2023 following UK regulatory approval, is the largest ever in the video gaming industry.”
(Source: adapted from Reuters, 2025).

Une fois l’information extraite, voici un exemple de graphe qu’il est possible de construire depuis ce texte :

Ce type d’extraction peut se faire de nombreuses façons différentes. La prochaine section sera spécialement dédiée aux différentes approches qui peuvent être adoptées pour réaliser une extraction complète, leurs avantages et inconvénients.

Quelles approches pour réaliser une extraction d’entités et de relations ?

Extraction manuelle VS outils dédiés

La construction d’un graphe de ce type peut se faire de manière manuelle en suivant la technique présentée dans la section précédente (envoyer un prompt incluant les instructions et le chunk au LLM, récupérer et décomposer l’output structuré renvoyé en sortie, puis mettre à jour le graphe via requêtes), ou alors langchain propose un outil permettant d’automatiser ces différentes tâches via le LLM Graph Transformer.

Cet outil permet de simplifier la procédure, en prenant en charge les instructions au LLM, la construction du template et le traitement de la sortie structurée. Il offre plusieurs possibilités de personnalisation, comme la possibilité de restreindre les types de nœud que l’on souhaite détecter (par ex. uniquement des nœuds de type « Person », « Company » et « Location »), de restreindre les types de relation, ou encore de personnaliser le prompt d’instructions.

De plus, une instance LLMGraphTransformer renvoie en sortie liste d’objets de type GraphDocument, contenant les nœuds et relations détectés, qui est exploitable directement par plusieurs drivers langchain vers des bases de données orientées graphe (telles que Memgraph, TigerGraph, Neo4j, etc.), afin de réaliser directement l’importation des entités et relations extraites vers le graphe.

Ci-dessous, un exemple illustratif de l’extraction des données depuis une liste de chunks via l’outil LLMGraphTransformer, suivie de l’importation des entités et relations vers Neo4j :

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

doc_transformer=LLMGraphTransformer(llm=llm)
graph_docs=doc_transformer.convert_to_graph_documents(listOfChunks)

from langchain_neo4j import Neo4jGraph
graph=Neo4jGraph(
    url='XXXXX',
    username='YYYYY',
    password='ZZZZZ'
)
graph.add_graph_documents(graph_docs)

Il existe aussi une alternative gratuite pour Neo4j, qui ne requiert aucune programmation, le Neo4j LLM Knowledge Graph Builder. Cet outil en ligne prend toutes les étapes en charge, en allant du prétraitement des documents (pdf, page web) jusqu’à la construction du graphe de connaissances résultant, et offre de multiples options de personnalisation (contraindre les types d’entité et/ou de relation à détecter, etc.). Voir ici pour plus de détails.

Extraction libre VS extraction supervisée

Il est à noter que si aucune contrainte (sur les types d’entité et de relation à extraire) n’est définie avec ces outils, ils vont librement extraire toutes les informations qu’ils peuvent trouver. Ce genre d’extraction « à l’aveugle » peut éventuellement être utilisée pour des petits documents, ou dans des cas où l’on ne sait pas à l’avance le genre de structure que l’on peut extraire, mais il est généralement préférable d’établir à l’avance l’ontologie que l’on souhaite adopter pour le graphe.

Une extraction libre est en effet souvent problématique pour plusieurs raisons :

Explosion des types d’entité et de relation 

Lorsque la taille ou le nombre de documents augmente, l’on risque rapidement de se retrouver avec un très grand nombre de types différents d’entités et de relations au sein du graphe, ce qui peut le rendre difficile à exploiter (par ex. pour des applications de RAG).

Incohérence de types

En l’absence d’une ontologie fournissant une nomenclature claire, il y a des risques d’incohérence dans les types détectés (par exemple, une entreprise pourra être labelisée comme « Enterprise », une autre comme « Company », et une troisième comme « Organization »). En pratique, ce genre de soucis peut potentiellement être réglé a posteriori en listant tous les types de nœud et en rassemblant les types sémantiquement proches.

Soucis de réification

Par définition, une relation dans un graphe relie un nœud à un autre nœud. Un souci peut émerger lorsqu’une entité doit se connecter à une information qui a été modélisée sous la forme d’une relation. Pour illustrer le problème, reprenons en guise d’exemple l’acquisition d’Activision Blizzard par Microsoft. Supposons qu’un premier chunk de texte mentionne simplement cette acquisition sans plus de détails, elle sera fort potentiellement enregistrée sous la forme :

(Microsoft)-[ACQUIRES]->(Activision Blizzard)

Si maintenant le chunk suivant mentionne l’information « The FTC challenged the acquisition… », nous avons un problème car il n’est plus possible de modéliser

(FTC)-[CHALLENGES]->(Acquisition)

puisque l’acquisition a été précédemment modélisée sous la forme d’une relation, et non d’un nœud pouvant être référencé par une relation.

Dans ce cas, la relation peut par exemple être supprimée puis remplacée par un nœud, afin de la rendre référençable :

(Microsoft)-[INITIATES]->(Acquisition)-[TARGETS]->(Activision Blizzard)

Ce processus, appelé réification, n’est pas automatique et demande l’ajout d’une étape d’enrichissement pour détecter de potentielles références à des informations modélisées sous forme de relations, et les réifier si nécessaire.

Quelques alternatives aux LLM

Maintenant que nous avons vu une série d’approches basées spécifiquement sur les LLM, cette section propose quelques outils alternatifs basés sur des méthodes de NLP classique.

Si l’objectif est uniquement de faire l’extraction d’entités nommées, vous pouvez trouver ici un article de blog dédié à ce sujet, ainsi qu’un exemple d’application de NER en PII filtering. Il existe de nombreux modèles de NER préentrainés disponibles sur des plateformes telles que Hugging Face.

Concernant l’extraction d’entités et de relations, elle peut se faire typiquement de 2 façons distinctes :

• L’extraction en 2 étapes séparées : l’on commence par l’utilisation d’un NER pour la détection et la catégorisation des entités, suivie d’une extraction de relations sur la base du texte et des entités détectées, afin de déterminer les relations entre ces dernières. Quelques exemples d’outils pour l’extraction de relations incluent openNRE, spacy-relation-extraction ou encore GliREL.
• L’extraction conjointe (end-to-end)  : il s’agit d’outils qui réalisent l’extraction d’entités et de relations en une seule étape, tels que OpenIE, Relik, REBEL ou Diffbot (solution commerciale).

Vérifier la conformité de ce qui a été détecté

La grande force des LLM pour ce genre de tâche d’extraction est leur compréhension du langage naturel, ce qui permet de personnaliser l’extraction en adaptant le prompt d’instructions. Par exemple, en l’absence de template de sortie pour la réponse structurée (que le LLM peut peiner à respecter si le template devient trop compliqué), il est possible d’obtenir des nœuds et relations conformes à l’ontologie en décrivant l’ontologie directement dans le prompt d’instructions, mais il est important de rester vigilant aux extractions. En effet, il n’y a aucune garantie que le LLM ne fasse pas d’erreur, et ne renvoie pas en sortie une relation/entité non-conforme.

De manière générale, lorsqu’un LLM (ou tout autre outil) est utilisé pour extraire de l’information de façon automatique depuis un texte vers un graphe de connaissances, il est utile de vérifier que ce qui a été extrait est bien conforme à l’ontologie et fidèle à l’information qui se trouve dans la source.

1. Vérifier que l’extraction respecte l’ontologie

Comme nous l’avons déjà mentionné dans un précédent article de blog, il est possible de valider la structure et le contenu d’un graphe de connaissances à l’aide du standard SHACL. Il s’agit d’un langage qui va contenir les différentes contraintes qui s’appliquent sur un graphe de connaissances. Il est possible soit d’effectuer une validation finale du graphe, pour vérifier que le contenu respecte effectivement les contraintes énoncées en SHACL (et de lister les données qui violent ces contraintes), soit d’effectuer ces validations de façon transactionnelle à chaque nouvelle information qui est ajoutée, afin de refuser tout nouvel ajout illégal. Bien qu’initialement prévu pour des graphes en RDF, certaines bases de données peuvent tout de même interpréter des contraintes en SHACL et valider le graphe, comme neo4j avec le package neosemantics (n10s).

2. Vérifier que l’extraction est correcte

Le risque d’une extraction automatique est qu’une information introduite dans le graphe soit factuellement incorrecte vis-à-vis du texte d’origine, ce qui peut être particulièrement problématique si ce graphe est utilisé comme potentielle source d’information (par exemple pour une application de graphRAG). Plusieurs approches peuvent être suivies. La plus simple est une vérification humaine des informations extraites, mais cela peut devenir difficile, voire infaisable, lorsque les documents deviennent trop longs/nombreux. L’autre approche consiste à utiliser un second LLM afin de vérifier ce qui a été extrait de chaque chunk. Comme nous l’avons mentionné dans l’article d’évaluation de LLM, il est plus facile, pour les LLM, de détecter les erreurs a posteriori que de les éviter.

Conclusion

Ces technologies, bien que performantes, ne sont jamais parfaites. Sauf extraction libre (à l’aveugle), mais qui risque d’aboutir à la création d’un graphe difficilement exploitable, la construction d’un graphe de connaissances à partir de texte est une tâche qui demande du travail, tant en amont (prétraitement des textes, établissement d’une ontologie pour le graphe sur la base du contenu du texte) qu’en aval (validation de la structure du graphe vis-à-vis de l’ontologie et vérification de la véracité et la fiabilité de son contenu).

Ce post est une contribution individuelle de Pierre Leleux, data scientist et network data analyst chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Artificiële intelligentie en machine learning spelen een steeds grotere rol in de menselijke samenleving ter ondersteuning van besluitvormingsprocessen. De aandacht naar hun eerlijkheid (fairness) is de afgelopen jaren dan ook steeds belangrijker geworden. Predictieve modellen kunnen namelijk problematisch worden wanneer ze biases (vooringenomenheden) die ze tijdens hun trainingsfase uit historische gegevens hebben geleerd, beginnen te reproduceren of versterken. Deze bias leidt vaak tot discriminatie van een of meer groepen individuen. Dit is vooral problematisch in het kader van gevoelige beslissingen, zoals het verwerken van sollicitaties, het toekennen van leningen of justitie. Dit artikel gaat in op de manier waarop deze algoritmische bias kan worden gemeten en op de verschillende manieren om deze te corrigeren om eerlijke voorspellingen te genereren.

Zoals we al in een eerdere blogpost hebben besproken, kan een bias verschillende oorzaken hebben. Het kan bijvoorbeeld gaan om een designfout in het algoritme zelf, een ondervertegenwoordiging van een groep in de trainingsdata, of om historische data die bevooroordeeld is door racisme/seksisme in de samenleving [1]. In dit artikel richten we ons op het geval waarin het probleem bij de gegevens ligt en niet bij het model zelf, namelijk wanneer het model leert op basis van bevooroordeelde gegevens en deze vooringenomenheid vervolgens reproduceert in zijn voorspellingen.

Een van de bekendste voorbeelden is de COMPAS-case. Het COMPAS-algoritme werd gebruikt in de Verenigde Staten om het risico op recidive van gedetineerden in het kader van een mogelijke vervroegde vrijlating in te schatten. In 2016 stelde een studie van ProPublica dat Afro-Amerikanen door het algoritme werden gediscrimineerd omdat ze meer kans hadden om als “high-risk” te worden geclassificeerd. De studie stelde meer bepaald dat een persoon met een donkere huidskleur meer kans had om ten onrechte als “high-risk” te worden geclassificeerd en dat een blanke daarentegen meer kans had om ten onrechte als “low-risk” te worden geclassificeerd. Deze zaak leidde tot een groot debat en de publicatie van honderden artikelen over dit onderwerp.

In het geval van COMPAS, lag het probleem niet bij het algoritme zelf, maar eerder bij de gegevens waarop het was getraind. Het model was namelijk getraind op historische strafrechtelijke gegevens die een systematische racistische vooringenomenheid weerspiegelen, zoals discriminerende politiepraktijken. Deze bevooroordeelde gegevens leidden er dus toe dat het model eveneens vooroordelen vertoonde in zijn voorspellingen.

Hoe meet je de oneerlijkheid van een model?

Problemen met fairness veronderstellen het bestaan van een zogenaamde gevoelige variabele. Dit is de variabele waarvoor men geen discriminatie wenst. Het kan bijvoorbeeld gaan om het geslacht of de etnische afkomst van een persoon. De gevoelige variabele is vaak categorisch, maar kan, afhankelijk van het geval, ook continu zijn (bijvoorbeeld de leeftijd van een persoon). Voor het gemak gaan we ervan uit dat er slechts een gevoelige variabele is, maar in sommige problemen kunnen er meerdere zijn.

Op basis van deze gevoelige variabele worden doorgaans twee groepen gedefinieerd. De groep die door het model negatief wordt gediscrimineerd, wordt de “beschermde groep” genoemd.

Stel dat we een predictief model hebben dat voorspellingen moet doen over het toekennen van een lening. Dit algoritme wordt als “eerlijk” beschouwd als de kans dat een persoon voor de lening wordt geselecteerd (positieve beslissing van het model) gelijk is, ongeacht de groep waartoe de persoon behoort. Wiskundig gezien willen we dus het volgende opleggen:

P(Y_d = 1 | Z = 1) = P(Y_d = 1 | Z = 0)

waarbij Y_d de beslissing van het model is en Z een binaire variabele die aangeeft of een persoon al dan niet behoort tot de beschermde groep. Deze kansen worden berekend op groepsniveau, niet op individueel niveau.

Een bekende maatstaf voor algoritmische oneerlijkheid is dus gewoon het verschil tussen deze twee termen. Indien er een verschil is, betekent het dat het model een van de twee groepen bevoordeelt. Deze maatstaf voor het verschil tussen voorspellingen binnen de twee groepen wordt “demographic parity” of “statistical parity” genoemd.

Hoewel deze maatstaf relatief eenvoudig is, is dit een van de bekendste op het gebied van algoritmische rechtvaardigheid, die algemeen wordt erkend en gebruikt. Het is echter duidelijk niet de enige maatstaf die bestaat (voor enkele alternatieven, zie bijvoorbeeld [2, 3]). Opgemerkt moet worden dat, aangezien demographic parity wordt gemeten op groepsniveau, het een maatstaf is voor groepsrechtvaardigheid (group fairness). Er bestaan ook alternatieve maatstaven op individueel niveau (individual fairness).

Waarom wordt de gevoelige variabele niet gewoon uit het model verwijderd?

Op het eerste gezicht lijkt het probleem eenvoudig op te lossen. Een voorspellend machine learning-model neemt gegevens X als input en voorspelt een variabele Y als output op basis van de gegevens in X. Het zou dus in principe voldoende zijn om de variabele Z niet op te nemen in de gegevens X, zodat de voorspellingen van het model niet meer worden beïnvloed door Z.

Helaas zijn de variabelen waaruit X bestaat in de praktijk zelden onafhankelijk van elkaar. De database X kan dus variabelen bevatten die gecorreleerd zijn met de gevoelige variabele, het model kan deze variabelen gebruiken als proxy van de gevoelige variabele en vertekende voorspellingen geven, ook al maakt Z niet expliciet deel uit van de gebruikte inputgegevens. Zo kan in een steekproef het inkomen van een persoon worden gebruikt als proxy voor zijn leeftijd, omdat het inkomen van personen doorgaans stijgt naarmate ze ouder worden.

In het geval van COMPAS werd de etnische afkomst van de gedetineerde bijvoorbeeld niet expliciet gebruikt in het model als variabele, maar door de aanwezigheid van gecorreleerde proxyvariabelen (bijv. postcode, sociaaleconomische indicatoren) werd de raciale vertekening altijd weerspiegeld in de voorspellingen van het model.

Hoe een algoritmische bias in de praktijk corrigeren?

Er onderscheiden zich drie grote families van correcties: voorbewerking (“pre-processing”: het verwijderen van de bias uit de trainingsdata), verwerking (“in-processing”: het verwijderen van de bias tijdens het trainen van het model) en nabewerking (“post-processing”: het verwijderen van de bias uit een getraind model). Deze benaderingen hebben elk hun voor- en nadelen en zijn uitgebreid beschreven in tal van publicaties. De geïnteresseerde lezer kan de volgende survey raadplegen [4], waarin de verschillende publicaties op het gebied van fairness zijn verzameld en geordend per aanpak (pre-, in-, post-processing), per type algoritme (logistische regressie, random forest, neurale netwerken, enz.), per gebruikte fairness-maatstaf, enz. Dit biedt een goed gestructureerd overzicht van wat er op dit gebied wordt gedaan.

Pre-processingsmethoden

Het idee is eenvoudig: de trainingsgegevens ontdoen van vooringenomenheid om ze dichter bij de werkelijkheid te brengen, zodat de vooroordelen niet in het machine learning-model terechtkomen. Enkele voorbeelden van pre-processingsmethoden zijn:

• De steekproef (sampling) opnieuw in evenwicht brengen (door waarnemingen toe te voegen of te verwijderen);
• De inhoud van bepaalde variabelen van data X corrigeren of zelfs volledig vervangen door nieuwe variabelen (representational learning) die geen gevoelige informatie bevatten;
• Het label (variabele Y) van bepaalde waarnemingen wijzigen.

Pre-processing biedt het voordeel dat het niet afhankelijk is van het gebruikte model en dat het doorgaans eenvoudig uit te leggen en te begrijpen is. Het correct corrigeren van historische gegevens kan echter ingewikkeld zijn en het is moeilijk om de fairness van het resulterende model te garanderen. Ook moet het risico van verlies aan nauwkeurigheid worden vermeld, aangezien het wijzigen van data mogelijk relevante patterns uit de data verwijdert.

Figuur 2 toont hoe fairness wordt toegevoegd via een pre-processing-aanpak. Zoals uit het schema blijkt, is pre-processing niet altijd noodzakelijk voor nieuwe data. Sommige methoden (bijv. resampling, relabeling) vereisen enkel een wijziging van de trainingsdata om te voorkomen dat het algoritme de bias leert. Sommige algoritmen (bijv. representation learning) vereisen echter ook dat de nieuwe te voorspellen waarnemingen worden gewijzigd.

In-processing-methoden

Deze methoden bestaan uit het rechtstreeks wijzigen van het voorspellingsmodel zelf, zodat de voorspellingen fair zijn. Dit kan bijvoorbeeld worden gedaan door een regularisatieterm toe te voegen aan de doelfunctie van het algoritme, of door er fairness-beperkingen aan toe te voegen.

In-processing-methoden hebben het voordeel dat, zodra het model is getraind, fairness direct in het model wordt opgenomen en het model vrij kan worden gebruikt, zonder dat de invoergegevens of de voorspellingen van het model verder hoeven te worden aangepast. Bovendien biedt het rechtstreeks wijzigen van het model een grote flexibiliteit, omdat complexe fairness-beperkingen kunnen worden gecodeerd.

Deze grote flexibiliteit vereist echter voldoende theoretische en praktische kennis om het algoritme zelf te kunnen wijzigen. Bovendien kan het aanbrengen van wijzigingen in een model, zoals beperkingen, de trainingstijd aanzienlijk verlengen. Aangezien in-processing-methoden de training van een algoritme wijzigen, zijn de meeste gepubliceerde methoden doorgaans specifiek voor een bepaald model.

Post-processingsmethoden

Bij de laatste benadering worden het model en de historische data niet aangepast, maar worden de voorspellingen van het model aangepast om aan de fairness-beperkingen te voldoen. Een post-processing-algoritme wijzigt dus meestal ofwel de waarschijnlijkheid dat een waarneming tot de door het model voorspelde klassen behoort, ofwel rechtstreeks de beslissingen (definitieve classificaties) voor bepaalde waarnemingen.

Post-processingsalgoritmen zijn eenvoudig te implementeren: ze zijn onafhankelijk van het gebruikte voorspellingsmodel en kunnen dus worden gebruikt met ‘black-box’-modellen. Bovendien vereist post-processing geen wijzigingen aan de gegevens of het model en blijft de integriteit van het bestaande proces dus behouden.

Dit soort methoden leidt echter doorgaans tot een groter verlies aan modelprestaties dan het gebruik van in-processingsmethoden. Een model vrij trainen en vervolgens achteraf de voorspellingen aanpassen om aan bepaalde beperkingen te voldoen, is namelijk vaak minder effectief dan een model dat specifiek is geoptimaliseerd om voorspellingen te doen die aan de beperkingen voldoen.

Eerlijke voorspellingen evalueren

Vanaf het moment dat beperkingen aan de voorspellingen van een model worden toegevoegd of de toegang tot bepaalde informatie wordt beperkt, zal dit de classificatieprestaties van het model logischerwijs verminderen. Het integreren van fairness in een classificatieprobleem houdt dus in dat er een juiste balans moet worden gevonden tussen de nauwkeurigheid van het model en de fairness ervan.

Bovendien is het raadzaam om, zelfs wanneer een evenwicht tussen nauwkeurigheid en eerlijkheid is gevonden, altijd te controleren welke wijzigingen het toevoegen van fairness-beperkingen met zich meebrengt.

Een voorbeeld ter illustratie: stel dat een algoritme voorspellingen doet die bevooroordeeld zijn en relatief meer gunstige beslissingen neigt te nemen voor leden van groep A dan voor leden van groep B. Het risico bestaat dat het algoritme bij de invoering van een fairness-beperking reageert door simpelweg het aantal gunstige beslissingen voor groep A te verminderen om hetzelfde niveau als groep B te bereiken. Dit nieuwe model is dus in theorie eerlijker dan het vorige, maar het is duidelijk slechter omdat deze eerlijkheid alleen is bereikt door een van de groepen te benadelen.

Dit voorbeeld illustreert hoe belangrijk het is om bij het invoeren van eerlijkheid in een model niet alleen te kijken naar prestatiemaatstaven (accuracy, demographic parity, enz.), maar ook te onderzoeken hoe de beslissingen van het model in de praktijk worden beïnvloed.

Conclusie

In dit artikel hebben we gezien hoe de oneerlijkheid van een machine learning-model kan worden gemeten. Ook hebben we een overzicht gegeven van de verschillende benaderingen die worden gebruikt om te voorkomen dat het model een in de historische gegevens aangeleerde bias reproduceert of versterkt.

Belangrijk is dat de verschillende benaderingen elkaar niet uitsluiten en vaak kunnen worden gecombineerd (bijvoorbeeld voorbewerking van de trainingsdata, gevolgd door een in-processing-methode op het model). Sommige publicaties op dit gebied stellen methoden voor die op verschillende niveaus van het classificatieproces werken.

Referenties

[1] Mehrabi, N., Morstatter, F., Saxena, N., Lerman, K., & Galstyan, A. (2021). A survey on bias and fairness in machine learning. ACM computing surveys (CSUR), 54(6), 1-35.

[2] Castelnovo, A., Crupi, R., Greco, G., Regoli, D., Penco, I. G., & Cosentini, A. C. (2022). A clarification of the nuances in the fairness metrics landscape. Scientific Reports, 12(1), 4209.

[3] Corbett-Davies, S., Gaebler, J. D., Nilforoshan, H., Shroff, R., & Goel, S. (2023). The measure and mismeasure of fairness. Journal of Machine Learning Research, 24(312), 1-117.

[4] Hort, M., Chen, Z., Zhang, J. M., Harman, M., & Sarro, F. (2024). Bias mitigation for machine learning classifiers: A comprehensive survey. ACM Journal on Responsible Computing, 1(2), 1-52.

Voor een soortgelijk onderwerp, zie de blogpost IA : L’éthique en pratique.

Dit is een ingezonden bijdrage van Pierre Leleux, data scientist et network data analyst bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Tandis que l’intelligence artificielle et le machine learning jouent un rôle croissant dans la société humaine pour soutenir les processus de prise de décision, les préoccupations concernant leur équité (fairness) ont attiré l’attention au cours des dernières années. Les modèles prédictifs peuvent en effet devenir problématiques lorsqu’ils commencent à reproduire ou renforcer des biais qu’ils ont appris dans les données historiques utilisées durant leur phase d’entrainement. Ce biais crée souvent une discrimination injuste à l’encontre d’un ou plusieurs groupe(s) d’individus, ce qui est particulièrement problématique dans le cadre de décisions sensibles, telles que le traitement de candidatures d’emploi, l’accord de prêts ou la justice, entre autres. Cet article s’intéresse à la manière dont ces biais algorithmiques peuvent être mesurés et les différentes façons de les corriger pour générer des prédictions équitables.

Comme nous en avions déjà discuté dans un précédent article de blog, un biais peut avoir plusieurs sources. Il peut par exemple s’agir d’un problème de design de l’algorithme en lui-même, d’un souci de sous-représentation d’un groupe dans les données d’entrainement, ou de données historiques biaisées par du racisme/sexisme présent dans la société [1]. Dans le cadre de cet article, nous nous concentrerons sur le cas où le problème vient des données et non pas du modèle en lui-même, à savoir lorsque le modèle apprend sur des données biaisées et reproduit ensuite ce biais dans ses prédictions.

L’un des exemples les plus connus est le cas COMPAS. L’algorithme COMPAS était utilisé aux États-Unis pour estimer le risque de récidive de détenus dans le cadre d’une potentielle libération anticipée. En 2016, une étude de ProPublica affirmait que les Afro-Américains étaient discriminés par l’algorithme car ils avaient plus de chance d’être classifiés comme « high-risk ». Plus précisément, l’étude mentionnait qu’une personne noire avait plus de chance d’être erronément classifiée comme « high-risk » et, qu’à l’inverse, une personne blanche avait plus de chance d’être erronément classifiée comme « low-risk ». Cette affaire entraina un grand débat et la publication de centaines d’articles sur le sujet.

Dans le cas de COMPAS, le problème n’était pas l’algorithme en lui-même, mais les données sur lesquelles il a été entrainé. Le modèle a en effet été entrainé sur des données historiques de la justice pénale qui reflètent un biais raciste systémique, telles que des pratiques policières discriminatoires. Ces données biaisées ont donc entrainé un modèle produisant des prédictions elles aussi biaisées.

Comment mesurer l’iniquité d’un modèle ?

Les problèmes de fairness supposent l’existence d’une variable appelée variable sensible. Il s’agit de la variable vis-à-vis de laquelle on souhaite qu’il n’y ait pas de discrimination. Il peut par exemple s’agir du genre de la personne, ou de son origine ethnique. La variable sensible est souvent catégorielle, mais suivant le cas de figure, elle peut aussi être continue (e.g. l’âge d’une personne). Pour des raisons de simplicité, nous faisons l’hypothèse qu’il n’y a qu’une seule variable sensible, mais dans certains problèmes il peut y en avoir plusieurs.

Sur base de cette variable sensible, on définit généralement deux groupes. Le groupe qui est discriminé négativement par le modèle est appelé « groupe protégé ».

Supposons un modèle prédictif ayant pour objectif de fournir des prédictions concernant l’accord d’un prêt. Cet algorithme sera considéré comme « équitable » si la probabilité pour un individu d’être sélectionné pour le prêt (décision positive du modèle) est la même peu importe le groupe dont est issu l’individu. Mathématiquement, on cherche donc à imposer :

P(Y_d = 1 | Z = 1) = P(Y_d = 1 | Z = 0)

Où Y_d est la décision du modèle et Z est une variable binaire indiquant l’appartenance ou non au groupe protégé. Ces probabilités sont calculées à l’échelle du groupe, et non pas de façon individuelle.

Une mesure bien connue de l’iniquité algorithmique consiste donc simplement à calculer la différence entre ces deux termes. S’il y a une différence, cela implique que le modèle favorise l’un des deux groupes. Cette mesure de la différence entre les prédictions au sein des deux groupes est appelée la « demographic parity » ou « statistical parity ».

Bien que relativement simple, il s’agit de l’une des mesures les plus connues dans le domaine de l’équité algorithmique, largement reconnue et utilisée. Cependant, ce n’est évidemment pas la seule mesure qui existe (pour quelques alternatives, voir e.g., [2, 3]). Il est à noter que, puisqu’elle se mesure à l’échelle des groupes, la demographic parity est donc une mesure d’équité de groupe (group fairness), il existe aussi des mesures alternatives au niveau des individus (individual fairness).

Pourquoi ne pas simplement enlever la variable sensible du modèle ?

Le problème semble, à première vue, simple à régler. Un modèle prédictif de machine learning prend en entrée des données X et prédit une variable Y en sortie sur base des données contenues dans X. Il suffirait donc, a priori, simplement d’enlever la variable Z de la base de données X pour que les prédictions du modèle ne soient plus impactées par Z.

Malheureusement, dans la pratique, les variables qui composent X sont rarement indépendantes les unes des autres. La base de données X peut donc contenir des variables corrélées avec la variable sensible, et le modèle pourra se servir de ces variables comme d’un proxy de la variable sensible et fournir des prédictions biaisées, bien que Z ne fasse pas explicitement partie des données utilisées en entrée. Par exemple, dans un échantillon, le revenu d’une personne peut être utilisée comme proxy de son âge, car les revenus des individus ont tendance à augmenter avec l’âge.

Dans le cas COMPAS par exemple, l’origine ethnique du détenu n’était pas explicitement utilisée en tant que variable du modèle, mais à cause de la présence de variables proxy corrélées (e.g., le code postal, des indicateurs socio-économiques), le biais racial se reflétait toujours dans les prédictions du modèle.

Comment corriger un biais algorithmique en pratique ?

Il existe 3 grandes familles de corrections : le prétraitement (« pre-processing » : enlever le biais des données d’entrainement), le traitement en cours (« in-processing » : enlever le biais durant l’entrainement du modèle) et le post-traitement (« post-processing » : enlever le biais d’un modèle entrainé). Chacune de ces approches a ses avantages et ses inconvénients et a fait l’objet de nombreuses publications. Le lecteur intéressé pourra se référer au survey suivant [4], qui rassemble et organise les différentes publications dans le domaine de la fairness par approche (pre-, in-, post-processing), type d’algorithme utilisé (régression logistique, random forest, réseaux de neurones, etc.), mesure de fairness utilisée, etc., offrant une vue d’ensemble bien structurée de ce qui se fait dans le domaine.

Les méthodes « pre-processing »

L’idée est simple : il s’agit simplement de débiaiser les données d’entrainement pour les rendre plus proches de la réalité, de sorte que le biais ne parvienne pas jusqu’au modèle de machine learning. Quelques exemples de méthodes de pre-processing incluent par exemple :

• Rééquilibrer l’échantillonnage (en ajoutant ou supprimant des observations) ;
• Corriger le contenu de certaines variables des données X, voire complètement remplacer les variables par des nouvelles (representation learning) qui ne contiennent pas d’information sensible ;
• Changer le label (variable Y) de certaines observations.

Le pre-processing offre l’avantage de ne pas dépendre du modèle utilisé et d’être (généralement) facile à expliquer et à comprendre. Cependant, corriger adéquatement les données historiques peut être compliqué à réaliser, et il est difficile de garantir l’équité du modèle résultant. Il faut aussi mentionner le risque de perte de précision, car altérer les données peut potentiellement enlever des patterns pertinents des données.

La figure 2 montre l’ajout d’équité via une approche pre-processing. Comme visible sur le schéma, le pre-processing ne s’applique pas toujours nécessairement aux nouvelles données. Certaines méthodes (e.g. rééchantillonnage, relabeliser) ne demandent que de modifier les données d’entrainement, pour éviter que l’algorithme n’apprenne le biais. Par contre, certains algorithmes (e.g. representation learning) nécessitent aussi de modifier les nouvelles observations à prédire.

Les méthodes « in-processing »

Ces méthodes consistent à modifier directement le modèle prédictif en lui-même, de sorte que ses prédictions soient équitables. Cela peut par exemple se faire en ajoutant un terme de régularisation sur la fonction objectif de l’algorithme, ou en lui ajoutant des contraintes de fairness.

Les méthodes in-processing ont l’avantage qu’une fois le modèle entrainé, la fairness est directement inclue dans le modèle et celui-ci peut être utilisé librement, sans nécessiter de modification supplémentaire des données entrées ou des prédictions du modèle. De plus, modifier directement le modèle offre une grande flexibilité, car on peut y encoder des contraintes de fairness complexes.

Cette grande flexibilité requiert, en contrepartie, des connaissances théoriques et pratiques suffisamment approfondies pour pouvoir modifier l’algorithme en lui-même. En outre, introduire des modifications dans un modèle, telles que des contraintes, peut significativement augmenter son temps d’entrainement. Enfin, puisque les méthodes d’in-processing modifient l’entrainement d’un algorithme, la plupart des méthodes publiées sont généralement spécifiques à un modèle précis.

Les méthodes « post-processing »

Pour la dernière approche, on ne touche pas au modèle ou aux données historiques, on va simplement appliquer un ajustement aux prédictions fournies par le modèle de sorte à satisfaire les contraintes de fairness. Un algorithme de post-processing va donc généralement soit modifier les probabilités d’appartenance aux classes prédites par le modèle, soit directement modifier les décisions (classifications finales) pour certaines observations.

Les algorithmes de post-processing sont des solutions simples à mettre en place : ils sont indépendants du modèle prédictif utilisé, et peuvent donc s’utiliser avec des modèles « black-box ». De plus, le post-processing ne demande aucune modification ni des données, ni du modèle, et préserve donc l’intégrité du processus existant.

Ce genre de méthodes tend cependant généralement à dégrader plus fortement les performances du modèle que l’utilisation de méthodes d’in-processing. En effet, entrainer un modèle librement et ensuite altérer ses prédictions a posteriori pour que ces dernières remplissent des contraintes sera souvent moins efficace que d’avoir un modèle ayant été spécifiquement optimisé pour fournir des prédictions remplissant les contraintes.

Evaluer les prédictions équitables

Par définition, à partir du moment où on ajoute des contraintes sur les prédictions d’un modèle, ou si on limite l’accès à certaines informations, cela va logiquement réduire les performances de classification du modèle. Par conséquent, incorporer de l’équité dans un problème de classification implique de trouver la juste balance entre la précision du modèle et sa fairness.

De plus, même une fois qu’un équilibre entre précision et équité a été trouvé, il convient toujours de vérifier les modifications qui résultent de l’ajout des contraintes de fairness.

Prenons un exemple illustratif : supposons un algorithme fournissant des prédictions biaisées, qui a tendance à donner relativement plus de décisions favorables aux membres du groupe A comparé au groupe B. Il y a un risque qu’à l’introduction d’une contrainte de fairness, l’algorithme réponde en réduisant simplement le nombre de décisions favorables pour le groupe A pour atteindre le même niveau que le groupe B. Ce nouveau modèle est donc théoriquement plus équitable que le précédent, mais il est manifestement pire puisque cette équité a été réalisée uniquement en pénalisant l’un des groupes.

Cet exemple illustre l’importance, lors de l’introduction d’équité dans un modèle, de ne pas regarder uniquement les mesures de performance (accuracy, demographic parity, etc.), mais aussi d’investiguer la façon dont les décisions du modèle sont impactées en pratique.

Conclusion

Dans cet article, nous avons vu comment mesurer l’iniquité d’un modèle de machine learning, et présenté un aperçu des différentes approches utilisées pour éviter que le modèle ne reproduise ou ne renforce un biais appris dans les données historiques.

Il est important de signaler que les différentes approches ne sont pas mutuellement exclusives, et peuvent souvent être combinées (e.g. un pre-processing des données d’entrainement, suivi d’une méthode in-processing sur le modèle). Certaines publications dans le domaine proposent d’ailleurs des méthodes qui agissent à plusieurs niveaux du processus de classification.

Références

[1] Mehrabi, N., Morstatter, F., Saxena, N., Lerman, K., & Galstyan, A. (2021). A survey on bias and fairness in machine learning. ACM computing surveys (CSUR), 54(6), 1-35.

[2] Castelnovo, A., Crupi, R., Greco, G., Regoli, D., Penco, I. G., & Cosentini, A. C. (2022). A clarification of the nuances in the fairness metrics landscape. Scientific Reports, 12(1), 4209.

[3] Corbett-Davies, S., Gaebler, J. D., Nilforoshan, H., Shroff, R., & Goel, S. (2023). The measure and mismeasure of fairness. Journal of Machine Learning Research, 24(312), 1-117.

[4] Hort, M., Chen, Z., Zhang, J. M., Harman, M., & Sarro, F. (2024). Bias mitigation for machine learning classifiers: A comprehensive survey. ACM Journal on Responsible Computing, 1(2), 1-52.

Sur un sujet similaire, voir le post IA: L’éthique en pratique.

Ce post est une contribution individuelle de Pierre Leleux, data scientist et network data analyst chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Deze blogpost volgt op deel 1, die de grondbeginselen van graphtechnologieën, hun algoritmes en toepassingen toelicht. Dit tweede deel is gewijd aan graph databases en aan knowledge graphs, hun verschillen en tools.

Graph databases

Zoals bij een relationele database is ook bij een graph database het doel om gegevens op een persistente manier op te slaan en te beheren en om complexe query’s uit te voeren. Het verschil is dat de gegevens worden opgeslagen in de vorm van een graph, d.w.z. een verzameling nodes die onderling verbonden zijn door bogen.

Graph databases hebben een aantal voordelen ten opzichte van traditionele relationele databases, omdat het graph model eenvoudige, geoptimaliseerde doorloop van gegevens via bogen mogelijk maakt, terwijl het verkennen van relaties in een relationele database een groot aantal joints kan vereisen. Meer details over de voordelen van graph databases en de situaties waarin ze gebruikt kunnen worden, zijn te vinden in de blogposts [1] en [2].

De drie componenten van een graph database zijn nodes, bogen en properties. Deze eigenschappen kunnen ofwel op de nodes, ofwel op de bogen, ofwel op beide worden geplaatst. Laten we eens kijken naar het voorbeeld in Figuur 1, de node “Paul” kan bijvoorbeeld gelinkt worden met eigenschappen zoals zijn geboortedatum en adres, voor de nodes die films voorstellen kunnen we eigenschappen associëren zoals het jaar van uitgave, het budget en de IMDb identifier, en op de “RATED” relaties tussen een gebruiker en een film kunnen we eigenschappen associëren zoals de kijkdatum en de waardering (op 5) die de gebruiker aan de film geeft.

Merk op dat de graph algoritmes die we in deel 1 hebben gepresenteerd vaak niet zijn geïmplementeerd in graph database software, met een paar uitzonderingen (Neo4j en TigerGraph hebben een “Graph Data Science (GDS)” library die verschillende algoritmes bevat). Over het algemeen is het daarom nodig om de graph (of een deel ervan) te exporteren naar een analysetool.

Tools voor graph databases

Laten we eens snel kijken naar enkele van de bekendste tools. Merk op dat alle hieronder genoemde tools compatibel zijn met ACID-eigenschappen. Er bestaan een groot aantal tools voor het beheren van graph databases, en deze post noemt er maar een paar. Bekijk hier gerust een uitgebreidere lijst.

1. Neo4j

Neo4j biedt het voordeel van een native graphformaat, wat het doorlopen van de graph zeer efficiënt maakt (en dus ook de query’s) De query’s gebeuren via Cypher, een taal die gemakkelijk te leren is, Neo4J is bovendien goed gedocumenteerd en beschikt over een grote community. Neo4J is in zijn “community”-versie gratis, maar een betalende versie bestaat ook (Neo4J Enterprise), de gratis versie kan een aantal schaalbaarheidsproblemen opleveren bij zeer grote hoeveelheden data.

2. ArangoDB

ArangoDB biedt een flexibel datamodel (multimodel), met een graphmodel, een documentmodel (gebaseerd op JSON-objecten) en een key-value model. Het heeft zijn eigen querytaal, AQL (Arango Query Language), die ingewikkelder kan zijn om te leren dan Cypher vanwege het multimodel dat aan de grondslag ligt van ArangoDB. Het programma is betalend, hoewel er ook een opensourceversie bestaat (community edition), maar die is (uiteraard) beperkter dan de betalende versie.

3. TigerGraph

TigerGraph is een betalende tool, die geoptimaliseerd is voor gebruik op zeer grote databases. De query’s gebeuren via de taal GSQL, die het mogelijk maakt om verschillende taken uit te voeren, maar die ingewikkelder is dan Cypher. TigerGraph beschikt over verschillende algoritmes die geïmplementeerd zijn via de GDS library.

4. Memgraph

Memgraph is een speciale tool in die zin dat hij gegevens direct in het geheugen bewaart (in RAM). Dit levert zeer hoge prestaties op voor query’s, maar maakt het aan de andere kant moeilijk te gebruiken, of op zijn minst kostbaar in termen van infrastructuur, als de graph groot is, omdat je genoeg RAM moet hebben om de gegevens op te slaan. Memgraph wordt daarom over het algemeen gebruikt als prestaties de hoogste prioriteit hebben. Query’s worden gedaan in Cypher.

5. GraphDB

GraphDB gebruikt een zeer specifiek graphmodel dat het Resource Description Framework (RDF) wordt genoemd. Dit framework, dat meer in detail zal worden besproken in de sectie Knowledge graphs, heeft zijn eigen querytaal die SPARQL heet. Er bestaat een gratis opensourceversie (graphDB Free) en een betalende enterpriseversie (graphDB Enterprise).

6. Apache TinkerPop en de implementaties ervan

Het gaat om een opensource framework voor het definiëren van een graph database en een querytaal die “Gremlin” heet. Het wordt gebruikt in veel graph database management software, zoals JanusGraph (opensource software), Amazon Neptune dat andere modellen biedt dan die van TinkerPop zoals RDF, of nog andere tools voor databasebeheer die niet gespecialiseerd zijn in graphs, zoals Azure Cosmos DB.

Knowledge graphs

Laten we, voordat we naar werkwijzen en tools kijken, eerst definiëren wat een knowledge graph is en hoe deze verschilt van een graph database. Het is een graph die zich richt op semantiek en inferentie. Elke node vertegenwoordigt een concept en elke boog een relatie. Zoals we al hebben gezien in de blogposts [3, 4], wordt een knowledge graph gedefinieerd als een graph die aan drie voorwaarden voldoet [5]:

1. De integratie van informatie uit verschillende heterogene bronnen.

Een knowledge graph verzamelt en combineert gegevens uit verschillende (on)gestructureerde bronnen op een coherente manier.

1. Het gebruik van een ontologie.

Een ontologie beschrijft formeel de concepten en relaties die aanwezig zijn in de graph, evenals eventuele beperkingen en regels. Het is dus een gestructureerd model dat de semantische basis biedt voor logische bewerkingen en coherentietesten. Een ontologieschema (zie Figuur 2), ook bekend als een ‘ontology graph’, biedt bijvoorbeeld een representatie van de entiteittypes en relaties van een knowledge graph, en biedt zo een conceptuele structuur zonder specifieke gegevens te bevatten.

1. Inferentie van impliciete informatie op basis van expliciete informatie.

Het is mogelijk om informatie te vinden die niet aanwezig was in de oorspronkelijke gegevens op basis van inferentieregels (zie Figuur 3).

Een overzicht van het RDF-model (Resource Description Framework)

Het RDF-model, oorspronkelijk ontworpen voor de formele beschrijving van web resources en de metadata ervan, wordt vaak gebruikt bij knowledge graphs omdat het robuust semantisch rederneren en een zeer hoge interoperabiliteit biedt.

Een RDF-document heeft de vorm van een set RDF-triples waarbij elk triple een associatie is: subject (te beschrijven bron), predicaat (eigenschap van de bron), object (gegevens of andere bron).

Bijvoorbeeld:

:Alice :knows :Bob .
:Alice :livesIn :Paris .
:Alice :age 30 .

Deze semantic triples vertegenwoordigen dus zowel relaties tussen nodes (bijvoorbeeld de relatie tussen Alice en Bob) als eigenschappen (de leeftijd van Alice).

Kenmerkend voor RDF is dat elk element van een triple (met uitzondering van het object als het een simpele waarde is, zoals de waarde 30 voor de leeftijd van Alice) door een URI (Uniform Resource Identifier) of IRI (Internationalized Resource Identifier) moet worden geïdentificeerd. Dit zorgt voor een hoge mate van interoperabiliteit, omdat het voorkomt dat er duplicaten ontstaan wanneer verschillende informatiebronnen worden gecombineerd. Als we teruggaan naar de eerder gebruikte triples, krijgen we het volgende fragment (in Turtle-taal):

<http://example.org/Alice> <http://example.org/knows> <http://example.org/Bob> .
<http://example.org/Alice> <http://example.org/livesIn> <http://example.org/Paris> .
<http://example.org/Alice> <http://example.org/age> "30"^^<http://www.w3.org/2001/XMLSchema#integer> .

Het gebruik van RDF impliceert daarom een URI om alle concepten (subjecten, predikaten en objecten) in de graph te kunnen identificeren op dezelfde manier als een primaire sleutel in relationele databases.

Bovendien bestaan er twee hulpmiddelen om semantische betekenis toe te voegen aan RDF-gegevens door relaties te beschrijven om redeneren mogelijk te maken, namelijk RDFS (RDF Schema) en OWL (Web Ontology Language). Zoals we al hebben gezien, vereist RDF dat elk concept wordt geïdentificeerd door een URI. RDFS en OWL bieden een voorgedefinieerde set URI’s voor veelgebruikte concepten waarnaar verwezen kan worden in RDF. Dit maakt het mogelijk om een gestandaardiseerd gemeenschappelijk vocabularium te hebben, wat de integratie met andere databanken vergemakkelijkt, en om inferentieregels op te stellen. Aangezien OWL en RDFS gestandaardiseerde concepten aanbieden, kunnen OWL-gebaseerde ‘reasoners’ (zoals FaCT++ of HermiT) op een systematische manier impliciete relaties afleiden of tegenstrijdigheden detecteren op basis van de ontologie.

Query’s op een RDF database worden gedaan via SPARQL.

Alternatieven voor RDF en tools voor het werken met een knowledge graph

Natuurlijk is het voor een knowledge graph niet noodzakelijk om het RDF-model te gebruiken. Een graph wordt als een knowledge graph beschouwd als voldaan is aan de 3 voorwaarden die beschreven zijn aan het begin van het hoofdstuk over knowledge graphs. Het is dus perfect mogelijk om een knowledge graph te creëren in een klassieke graph databasemanagementtool, zolang de implementatie data uit verschillende bronnen combineert, voldoet aan een ontologie en gebruikt kan worden voor semantische inferentie.

De voornaamste kracht van het RDF-model is zijn hoge standaardisatieniveau. Enerzijds laat het een hoge mate van interoperabiliteit toe dankzij de URI-identificatievereiste en de gestandaardiseerde woordenschat en querytaal. Anderzijds bieden de RDFS- en OWL-uitbreidingen een schat aan semantische informatie voor automatisch redeneren. Omgekeerd beperkt de complexiteit het gebruik in zakelijke toepassingen waar deze semantische nauwkeurigheid niet noodzakelijk is en waar het gebruik van een eenvoudiger graphmodel (zoals Neo4j of TigerGraph) volstaat. Het gebruik van eenvoudigere modellen heeft het voordeel dat ze eenvoudiger en sneller op te zetten zijn en optimale query prestaties bieden, maar ten koste van het verlies van de semantische rijkdom die RDF biedt.

In deze sectie worden (niet-exhaustieve) tools met betrekking tot RDF voorgesteld, maar zoals vermeld blijven de tools die eerder werden vermeld voor graph databases geldig voor het creëren van een knowledge graphs zolang aan de voorwaarden wordt voldaan.

Hier is een lijst van enkele tools gerelateerd aan knowledge graphs in RDF:

• Ontwerp van ontologieën: de opensourcetool Protégé wordt vaak gebruikt om ontologieën te creëren. De website Schema.org biedt een groot aantal standaard schema’s en vocabulaires voor verschillende domeinen, maar wordt over het algemeen gebruikt voor knowledge graphs met betrekking tot webgegevens.
• Gegevens omzetten naar RDF: de tool R2RML kan gebruikt worden om relationele gegevens om te zetten in RDF. Ook het vermelden waard is D2RQ, dat toegang biedt tot een relationele database via een virtuele RDF knowledge graph.
• Dataopslag: naast de hierboven genoemde oplossingen (GraphDB en Amazon Neptune), kunnen we ook BlazeGraph en Apache Jena (opensource) vermelden, alsook Stardog en AllegroGraph (businessoplossingen).
• OWL reasoners: er bestaan veel OWL reasoners. Ze worden echter niet allemaal actief onderhouden of zijn niet altijd bruikbaar. De meest recente OWL reasoners lijst die we konden vinden dateert uit 2023 en is hier beschikbaar [6].

Tot slot willen we nog het RDF4J framework (Java framework) en rdflib (python library) vermelden voor interactie met RDF data.

Conclusie

Laten we afsluiten met een korte samenvatting van de belangrijkste concepten die een wiskundige graph onderscheiden van een graph database en een knowledge graph.

Een wiskundige graph is een verzameling van nodes en bogen die gemakkelijk kan worden voorgesteld in matrixvorm zodat er algoritmes op kunnen worden toegepast. Het is de onderliggende structuur van elke graph database of knowledge graph.

Een graph database bestaat uit een set van nodes, bogen en properties. De nadruk ligt op het opslaan van grote hoeveelheden gegevens binnen een graph structuur en het optimaliseren van query’s.

Een knowledge graph heeft als doel om kennis binnen een graph weer te geven met de nadruk op:

• Semantiek: de graph volgt een ontologie en relaties hebben betekenis.
• Integratie: verschillende databronnen zijn gekoppeld in een uniforme graph.
• Inferentie: het vermogen om kennis af te leiden door redeneren.

Daarom is het gericht op de integratie en de semantische verrijking van data.

Het spreekt voor zich dat deze post slechts een tipje van de sluier oplicht van de uitgebreide literatuur over graphs en de verschillende toepassingen ervan. Vele punten moeten nog verder uitgewerkt worden en zullen ongetwijfeld het onderwerp zijn van toekomstige blogposts.

Referenties

[1] Graph DB vs RDBMS

[2] Sept (bonnes) raisons d’utiliser une Graph Database

[3] Les graphes de connaissance, incontournable pour l’intelligence artificielle

[4] Smals KG Checklist: déterminer si un graphe de connaissances peut résoudre un problème concret

[5] Ehrlinger, L., & Wöß, W. (2016). Towards a definition of knowledge graphs. SEMANTiCS 2016, 48(1-4), 2.

[6] Abitch, K., (2023). “OWL Reasoners still useable in 2023”

Dit is een ingezonden bijdrage van Pierre Leleux, data scientist et network data analyst bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Dankzij hun vermogen om complexe relaties tussen gegevens te begrijpen en te benutten, worden graphtechnologieën steeds populairder op veel gebieden van kunstmatige intelligentie en gegevensbeheer. Deze blog heeft al meerdere artikels gepubliceerd over verschillende graphtechnologieën, waaronder graph databases [1, 2, 3] en knowledge graphs [4, 5, 6].

Maar wat betekent de term ‘graph’ eigenlijk? Tussen de wiskundige modellen die als basis dienen, graph databases en knowledge graphs, kan het moeilijk zijn om je weg te vinden en de tools te identificeren die het best passen bij je behoeften. Hierbij komt nog het feit dat werken met graph data op het eerste gezicht complex kan lijken en dat het gebruik van graphalgoritmes niet tot de kernvaardigheden van de meeste data engineers en data scientists behoort. Dit alles kan het creëren en exploiteren van graph data en modellen tot een ontmoedigend vooruitzicht maken.

Dit artikel geeft daarom een overzicht van graphtechnologieën, waarbij de drie bovengenoemde aspecten worden verkend:

• Graphs vanuit een theoretisch oogpunt, hun eigenschappen en hun belangrijkste toepassingen;
• Graph databases, gespecialiseerd in de opslag en exploitatie van gekoppelde gegevens;
• Knowledge graphs, die kennis semantisch structureren.

Daarom is het de bedoeling om deze concepten en de – soms vage – grenzen ertussen te presenteren, en hun toepassingen en de bijbehorende tools en software te belichten.

Dit artikel is opgesplitst in twee delen. Het eerste deel richt zich op graphs in hun fundamentele wiskundige vorm, hoe ze kunnen worden gecodeerd en geëxploiteerd, en de belangrijkste algoritmes en de toepassingen ervan. Het tweede deel richt zich op graph databases en knowledge graphs, en de bijbehorende tools.

Back to basics: graphs als wiskundige structuur

Laten we eerst definiëren wat een graph is. Deze theoretische basis is cruciaal aangezien de concepten van graph databases en knowledge graphs op deze basis zijn gebouwd. Deze meer geavanceerde concepten kunnen op elk moment worden teruggebracht tot hun onderliggende wiskundige vorm en bij uitbreiding zijn alle modellen en algoritmes die hieronder worden gepresenteerd toepasbaar op graph databases en knowledge graphs.

In zijn meest basale vorm is een graph een wiskundige structuur die bestaat uit een verzameling nodes en arcs die de nodes paarsgewijs verbinden. Nodes stellen meestal objecten of mensen voor en bogen stellen links tussen deze objecten of mensen voor. In het geval van een sociaal netwerk kan een boog bijvoorbeeld een vriendschapsband tussen twee gebruikers voorstellen.

De graph kan zowel gericht als ongericht zijn. In het geval van een ongerichte graph zijn de relaties tussen nodes altijd wederkerig (bijvoorbeeld een vriendschapslink op Facebook), terwijl in een gerichte graph een boog die van node i naar node j gaat, niet noodzakelijk een boog in de tegenovergestelde richting impliceert (bijvoorbeeld een website A die een link heeft naar een website B).

Afhankelijk van de situatie of toepassing kan een graph al dan niet gewogen zijn. Een graph is als gewogen omschreven als er aan elke boog een gewicht wordt toegekend dat varieert van boog tot boog en dat het mogelijk maakt om bepaalde bogen een grotere “kracht” te geven. De interpretatie van deze gewichten hangt af van de context; ze kunnen bijvoorbeeld een mate van verwantschap, gelijkenis, afhankelijkheid, enz. weergeven.

Een graph wordt over het algemeen voorgesteld door een vierkante matrix van dimensie (n × n), waarbij n het aantal nodes in de graph voorstelt, genaamd een adjacency matrix (aangeduid als A). Het element op positie (i, j) in de matrix is het gewicht van de boog van node i naar node j als deze bestaat, en anders 0 (zie figuur 1). De adjacency matrix is gewoon een binaire matrix als de graph ongewogen is.

Hier gaat een boog van gewicht 3 van node 1 naar node 3 en een boog van gewicht 5 in de tegenovergestelde richting. De matrix A bevat daarom de waarde 3 op positie (1,3) en de waarde 5 op positie (3,1).

Merk op dat adjacency matrices vaak grotendeels nullen bevatten en daarom over het algemeen worden gecodeerd met behulp van sparse matrices om het geheugen te optimaliseren.

Deze voorstelling van een graph in matrixvorm maakt het veel eenvoudiger om algoritmes op de graph te gebruiken, aangezien veel graphalgoritmes, die soms complex zijn in de vorm van vergelijkingen, vaak gereduceerd kunnen worden tot een reeks elementaire matrixbewerkingen. Dit maakt hun uitvoering zeer efficiënt in wetenschappelijke programmeertalen die geoptimaliseerd zijn voor matrixberekeningen, zoals R, MATLAB, Julia of Python (numpy, scipy).

Gebruiken van graphalgoritmes en praktische toepassingen

Om het nut van een graph beter te begrijpen, kijken we eerst naar de hoofdcategorieën van graphalgoritmes, met voor elke categorie een paar voorbeelden van het praktische gebruik ervan.

• Het optimale pad bepalen om een paar nodes te verbinden.

Hierbij kan het gaan om het minimaliseren van het aantal overgangen dat nodig is om van de ene node naar de andere te gaan of, als er kosten zijn verbonden aan elke boog, het vinden van het pad met de laagste kosten. De kosten kunnen gedefinieerd worden als het gewicht van een boog, of gecodeerd worden in een tweede matrix (kostenmatrix, onafhankelijk van de adjacency matrix). De manier waarop de kosten van een boog worden bepaald hangt af van de toepassing, afhankelijk van wat je wilt minimaliseren. Dit kan bijvoorbeeld een maat voor de lengte van de boog zijn (de lengte van een weg), een maat voor de tijd (de tijd die nodig is om de boog over te steken) of financiële kosten. Dit type algoritme kan worden gebruikt in de logistiek om transport te optimaliseren. De bekendste algoritmes zijn de algoritmes Dijkstra, A* en Bellman-Ford.

• Maatstaven bepalen voor gelijkenis of afstand tussen nodes in een graph.

Afhankelijk van de context kan het nuttig zijn om een similariteitsmaat te bepalen tussen twee nodes in een graph om te bepalen hoe dicht ze bij elkaar liggen. Similariteitsmaten worden vaak gebruikt in aanbevelingstoepassingen. Door een consumptiegraph te ontwerpen die gebruikers koppelt aan de producten die ze hebben geconsumeerd, maakt het meten van de similariteit tussen nodes het voor een bepaalde gebruiker mogelijk om gebruikers met een gelijkaardig consumptieprofiel te identificeren, gebaseerd op hun connecties met de producten. Een product wordt meestal aanbevolen aan een gebruiker omdat het door veel vergelijkbare gebruikers is geconsumeerd (user-based recommendation) of omdat het product vergelijkbaar is met producten die de gebruiker al heeft geconsumeerd (item-based recommendation). De bekendste similariteitsmaten zijn over het algemeen gebaseerd op common-neighbour maten (het aantal buren dat twee nodes gemeen hebben), zoals de Jaccard-index of cosinus-similariteit, maar andere methoden houden ook rekening met indirecte buren, zoals de Katz-kernel [12] (ook bekend als de “von Neumann kernel”). Zie [13] voor enkele klassieke similariteitsmaten en het gebruik ervan in aanbevelingen.

Het tegenovergestelde van een similariteitsmaat is een dissimilariteitsmaat, die toeneemt naarmate twee nodes verder van elkaar verwijderd zijn. Een afstandsmaat is per definitie een dissimilariteit, omdat deze toeneemt naarmate twee nodes verder van elkaar verwijderd zijn. De bekendste en meest intuïtieve maat voor dissimilariteit tussen twee nodes is de lengte van het kortste pad tussen hen.

• De centraliteit meten.

Een maat voor de centraliteit van een node of boog, soms ook een prestige measure genoemd, wordt gebruikt om te kwantificeren hoe belangrijk een node of boog is binnen een graph. De bekendste maat voor centraliteit is de score die wordt berekend door het algoritme PageRank [14]. PageRank werd oorspronkelijk ontwikkeld en gebruikt door de zoekmachine Google om webpagina’s te rangschikken. Het is gebaseerd op een willekeurige beweging in een graph waarin elke node een webpagina voorstelt en elke gerichte boog een hyperlink tussen twee pagina’s voorstelt. Het PageRank-algoritme kent naast het rangschikken van webpagina’s heel wat andere toepassingen:

“Google’s PageRank method was developed to evaluate the importance of web-pages via their link structure. The mathematics of PageRank, however, are entirely general and apply to any graph or network in any domain. Thus, PageRank is now regularly used in bibliometrics, social and information network analysis, and for link prediction and recommendation. It’s even used for systems analysis of road networks, as well as biology, chemistry, neuroscience, and physics.” – Gleich (2014) [15]

Een ander bekend algoritme dat lijkt op PageRank is het HITS-algoritme (Hyperlink-Induced Topic Search) [16].

Als we het over centraliteit hebben, is PageRank vaak het algoritme dat wordt voorgesteld, maar centraliteit kan op verschillende manieren worden begrepen. Het kan bijvoorbeeld verwijzen naar een node of boog die een kritieke intermediair is voor communicatie en informatieoverdracht binnen het netwerk. Centrale nodes identificeren kan het bijvoorbeeld mogelijk maken om informatie optimaal te verspreiden in een netwerk of om nodes of bogen op te sporen die van vitaal belang zijn voor de graph (waarvan de verdwijning de informatieoverdracht in de graph ernstig zou belemmeren). Veel voorkomende maatstaven voor node- of boog-centraliteit op basis van dit principe gebruiken over het algemeen tussen-maatstaven (betweenness centrality).

Centraliteit kan ook worden beschouwd als een maat voor de representativiteit van een node binnen een gemeenschap (in termen van nabijheid tot de andere nodes in de graph), in dit geval gemeten door middel van een maat van nabijheid (closeness centrality). Merk op dat we het gebruik van verschillende centraliteitsalgoritmes in een fraudedetectiecontext al hebben vermeld in eerdere blogposts, met name PageRank (in de vorm van een verspreidingsalgoritme) [7] en betweenness centrality [8].

• De graph partitioneren.

Beter bekend als “clustering”, bestaat graph partitioning uit het groeperen van nodes in communities (clusters) zodat nodes binnen een community “similair” zijn en twee nodes die tot verschillende communities behoren “dissimilair” zijn. Dit partitioneren kan op verschillende manieren gebeuren. Door bijvoorbeeld een maat voor similariteit of dissimilariteit tussen de nodes in de graph te gebruiken en vervolgens een clusteralgoritme zoals k-medoids uit te voeren op basis van deze (dis)similariteiten.

Een andere manier is om direct op de graph te werken en te proberen dichte gebieden binnen de graph te detecteren. Dit kan worden gedaan met behulp van labelpropagatie [17], of door het optimaliseren van een objectieve functie die de kwaliteit van de partitionering meet, zoals modulariteit. Het bekendste algoritme voor modulariteitsoptimalisatie is de Louvain-methode [18].

We hebben het gebruik van ‘graph partitioning’-methodes al genoemd in verschillende blogposts [9, 10]. Deze algoritmes worden met name gebruikt in communicatie en marketing om gerichte advertenties te produceren.

• Kenmerken of representaties extraheren.

De traditionele modellen voor machine learning hebben als limiet dat ze alleen rekening houden met de gegevens (continue en categorische variabelen) die betrekking hebben op de waarnemingen, en de informatie negeren die kan worden afgeleid uit de relaties tussen de waarnemingen. Indien er relaties bestaan tussen deze gegevens, kan er een graph worden geconstrueerd en kunnen de machine learning modellen worden verrijkt door nieuwe variabelen uit de graph toe te voegen (er is ook een blogpost over dit onderwerp [11]). Deze nieuwe variabelen kunnen bijvoorbeeld een maat voor centraliteit zijn (continue variabele) of het resultaat van partitionering (categorische variabele), of ze kunnen worden verkregen met behulp van ‘graph embedding’-methoden (continue variabelen). Graph embedding moet leiden tot een representatie van de nodes in een multidimensionale ruimte. Deze ruimte wordt zo berekend dat als twee nodes dicht bij elkaar liggen in de graph, ze ook dicht bij elkaar liggen in deze ruimte. Zo’n ruimte kan worden verkregen met methoden die direct op de graph werken (node2vec [19], fastRP [20]) of door te werken op basis van bijvoorbeeld similariteiten (kernelPCA [21]) of afstanden (t-SNE [22]). Zie figuur 3 voor een voorbeeld van een tweedimensionale weergave van een eenvoudige gewogen graph.

• Links voorspellen.

Het concept van linkvoorspelling is relatief eenvoudig: het gaat om het inschatten van de waarschijnlijkheid dat er een link bestaat tussen twee nodes. Dit maakt het mogelijk om potentieel ontbrekende bogen (incomplete graph) te detecteren, of om het verschijnen van nieuwe bogen te voorspellen. Aanbevelingsalgoritmes zijn een veelvoorkomend voorbeeld van het voorspellen van links tussen gebruikers en producten, maar deze algoritmes kunnen ook worden gebruikt om potentiële, nog onbekende interacties binnen biologische netwerken te detecteren. Dit type voorspelling wordt vaak verricht met behulp van methoden gebaseerd op overeenkomsten tussen nodes, matrixfactorisatie, probabilistische modellen of kunstmatige neurale netwerken [23].

Welke hulpmiddelen?

Zoals hierboven vermeld betekent de weergave van graphs in matrixvorm dat ze efficiënt gebruikt kunnen worden in wetenschappelijke programmeertalen. Er bestaan echter ook library’s of softwares die gebruikt kunnen worden om graphs te creëren en te exploiteren.

Enkele voorbeelden van library’s voor het werken met graphs. Deze library’s kunnen worden gebruikt om een graph object te maken dat op verschillende manieren kan worden opgebouwd. Het kan leeg worden opgebouwd, voordat handmatig nodes en bogen worden toegevoegd, of vanuit een adjacency matrix of een lijst van bogen, of rechtstreeks vanuit bestanden die een beschrijving van de graph bevatten in de vorm van een lijst van nodes en bogen. Voorbeelden van graph-georiënteerde library’s zijn igraph, NetworkX, graph-tool of NetworKit voor Python, igraph voor R en Graphs voor Julia.

Voor gebruikers die al een van deze talen kennen, hebben deze library’s het voordeel dat ze intuïtief en gemakkelijk te leren zijn en veel voorgeïmplementeerde graph algoritmes bevatten.

Conclusie

In het eerste deel van deze blogpost hebben we ons toegespitst op de verschillende graph tools, we hebben de graphtheorie kort ingeleid, alsook de voornaamste toepassingen en algoritmes voor graphs. Het tweede deel richt zich op graph databases en knowledge graphs, het verschil tussen deze concepten en de bijbehorende tools.

Referenties

Enkele blogposts van Smals Research over graphs:

[1] Graph DB vs RDBMS

[2] Sept (bonnes) raisons d’utiliser une Graph Database

[3] Een graph database verkennen

[4] Les graphes de connaissance, incontournable pour l’intelligence artificielle

[5] Les graphes de connaissance : quelques applications

[6] Smals KG Checklist: déterminer si un graphe de connaissances peut résoudre un problème concret

[7] Un fraudeur ne fraude jamais seul

[8] Un fraudeur ne fraude jamais seul, partie 2

[9] Ce qu’un réseau social peut nous apprendre

[10] Facebook : peut-on vraiment cacher sa liste d’amis ?

[11] Améliorer le Machine Learning avec des données graphes

Wetenschappelijke bronnen:

[12] Katz, L. (1953). A new status index derived from sociometric analysis. Psychometrika, 18(1), 39-43.

[13] Fouss, F., Pirotte, A., Renders, J. M., & Saerens, M. (2007). Random-walk computation of similarities between nodes of a graph with application to collaborative recommendation. IEEE Transactions on knowledge and data engineering, 19(3), 355-369.

[14] Page, L., Brin, S., Motwani, R., & Winograd, T. (1998). The pagerank citation ranking: Bringing order to the web. Technical report, Stanford Digital Libraries.

[15] Gleich, D. F. (2015). PageRank beyond the web. siam REVIEW, 57(3), 321-363.

[16] Kleinberg, J. M. (1999). Authoritative sources in a hyperlinked environment. Journal of the ACM (JACM), 46(5), 604-632.

[17] Raghavan, U. N., Albert, R., & Kumara, S. (2007). Near linear time algorithm to detect community structures in large-scale networks. Physical Review E—Statistical, Nonlinear, and Soft Matter Physics, 76(3), 036106.

[18] Blondel, V. D., Guillaume, J. L., Lambiotte, R., & Lefebvre, E. (2008). Fast unfolding of communities in large networks. Journal of statistical mechanics: theory and experiment, 2008(10), P10008.

[19] Grover, A., & Leskovec, J. (2016). node2vec: Scalable feature learning for networks. In Proceedings of the 22nd ACM SIGKDD international conference on Knowledge discovery and data mining (pp. 855-864).

[20] Chen, H., Sultan, S. F., Tian, Y., Chen, M., & Skiena, S. (2019, November). Fast and accurate network embeddings via very sparse random projection. In Proceedings of the 28th ACM international conference on information and knowledge management (pp. 399-408).

[21] Schölkopf, B., & Smola, A. J. (2002). Learning with kernels: support vector machines, regularization, optimization, and beyond.

[22] Van der Maaten, L., & Hinton, G. (2008). Visualizing data using t-SNE. Journal of machine learning research, 9(11).

[23] Lü, L., & Zhou, T. (2011). Link prediction in complex networks: A survey. Physica A: statistical mechanics and its applications, 390(6), 1150-1170.

Dit is een ingezonden bijdrage van Pierre Leleux, data scientist et network data analyst bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Cet article fait suite à la Partie 1, qui présente les fondamentaux des technologies graphes, algorithmes et applications. Cette seconde partie est consacrée aux bases de données orientées graphe et aux graphes de connaissances, leurs différences et leurs outils.

Les bases de données orientées graphe

A l’instar d’une base de données relationnelle, l’objectif d’une base de données orientée graphe est de pouvoir stocker et gérer des données de manière persistante et d’effectuer des requêtes complexes. La différence étant que les données sont stockées sous la forme d’un graphe, à savoir un ensemble de nœuds interconnectés par le biais d’arcs.

Les bases de données orientées graphe ont plusieurs avantages par rapport aux bases de données relationnelles classiques, car le modèle de graphe permet une traversée simple et optimisée des données via les arcs, là où l’exploration de relations dans une base de données relationnelle peut demander un nombre important de jointures. Plus de détails sur les avantages des bases de données orientées graphe, ainsi que les cas de figure où les utiliser, se trouvent dans les articles de blog [1] et [2].

Les trois composants de toute base de données orientée graphe sont : nœuds, arcs et propriétés. Ces propriétés peuvent être placées soit sur les nœuds, soit sur les arcs, ou sur les deux. Si nous considérons le petit exemple illustratif dans la Figure 1, le nœud « Paul » peut par exemple être associé à des propriétés telles que sa date de naissance et son adresse, pour les nœuds représentant des films on peut y associer les propriétés telles que l’année de sortie, le budget et son identifiant IMDb, et sur les relations « A_VU » entre un utilisateur et un film, on pourrait associer des propriétés telles que la date de visionnage et la note (sur 5) que l’utilisateur donne au film.

Il est à noter que les algorithmes de graphe que nous avons présentés dans la Partie 1 ne sont souvent que peu ou pas implémentés dans les logiciels de bases de données orientées graphe, à quelques exceptions près (Neo4j et TigerGraph disposent d’une libraire « Graph Data Science (GDS) » contenant plusieurs algorithmes). Il est donc généralement nécessaire d’exporter le graphe (ou une partie de celui-ci) vers un outil d’analyse.

Les outils pour bases de données orientées graphe

Passons rapidement en revue quelques-uns des outils les plus connus. Notez que tous les outils listés ci-après sont compatibles avec les propriétés ACID. Il existe un grand nombre d’outils pour la gestion de base de données graphe, cet article n’en mentionne qu’une partie. N’hésitez pas à aller jeter un coup d’œil à une liste plus détaillée trouvable ici.

1. Neo4j

Neo4j offre l’avantage d’avoir un format de graphe natif, ce qui rend très efficace la traversée du graphe (et donc, les requêtes). Les requêtes se font en Cypher, un langage facile à prendre en main, et Neo4J est bien documenté et dispose d’une grande communauté. Neo4J dans sa version « community » est gratuit, mais une version payante existe (Neo4j Enterprise), et la version gratuite peut poser quelques soucis de scalabilité face à de très grandes quantités de données.

2. ArangoDB

ArangoDB propose un modèle de données flexible (multi-modèle), intégrant un modèle graphe, un modèle document (basé sur des objets JSON) et un modèle clé-valeur. Il dispose de son propre langage de requêtes AQL (Arango Query Language) qui peut être plus compliqué à prendre en main que Cypher en raison du multi-modèle sous-jacent à ArangoDB. C’est un logiciel payant, bien qu’une version open source existe (community edition), mais est (évidement) plus limitée que la version payante.

3. TigerGraph

TigerGraph est un outil payant, optimisé pour pouvoir être utilisés sur de très grandes bases de données. Les requêtes se font via le langage GSQL, qui est un langage permettant d’effectuer de nombreuses tâches, mais plus compliqué à prendre en main que Cypher. TigerGraph dispose de nombreux algorithmes implémentés via la librairie GDS.

4. Memgraph

Memgraph est un outil particulier en ce sens qu’il stocke les données directement en mémoire (dans la RAM). Cela lui permet d’avoir des très hautes performances pour le requêtage, mais en contrepartie cela rend son utilisation difficile, ou du moins coûteuse en termes d’infrastructure, lorsque le graphe est de grande taille, puisqu’il faut avoir suffisamment de RAM que pour stocker les données. Memgraph s’utilise donc généralement lorsque les performances sont la première priorité. Les requêtes se font en Cypher.

5. GraphDB

GraphDB utilise un modèle de graphe bien spécifique appelé Resource Description Framework (RDF). Ce framework, qui sera discuté un peu plus en détails dans la section relative aux graphes de connaissances, a son langage de requête propre nommé SPARQL. Il existe en version gratuite open-source (graphDB Free) et en version entreprise payante (graphDB Enterprise).

6. Apache TinkerPop et ses implémentations

Il s’agit d’un framework open-source qui vise à définir un modèle de base de données graphes, ainsi qu’un langage de requête nommé « Gremlin ». Il est utilisé dans de nombreux logiciels de gestion de base de données orientées graphe, tels que JanusGraph (un logiciel open-source), Amazon Neptune qui propose d’autres modèles que celui de TinkerPop tels que RDF, ou encore des outils de gestion de base de données non spécialisés en graphe, tels qu’Azure Cosmos DB.

Les graphes de connaissances

Avant de s’intéresser aux pratiques et outils, commençons dans un premier temps par définir ce qu’est un graphe de connaissances et ce qui le distingue d’une base de données orientée graphe. Il s’agit d’un graphe qui met l’accent sur la sémantique et sur l’inférence. Chaque nœud représente un concept et chaque arc une relation. Comme nous l’avons déjà vu dans les articles de blog [3, 4], un graphe de connaissances se définit comme un graphe remplissant trois conditions [5] :

1. L’intégration d’informations en provenance de différentes sources hétérogènes.

Un graphe de connaissances rassemble et combine des données issues de diverses sources (structurées ou non) de manière cohérente.

2. L’utilisation d’une ontologie.

Une ontologie décrit de façon formelle les concepts et les relations présentes dans le graphe, ainsi que les éventuelles contraintes et règles. Il s’agit donc d’un modèle structuré qui fournit les fondations sémantiques afin de permettre des opérations de raisonnement et des tests de cohérence. Par exemple, un schéma d’ontologie (voir Figure 2), également appelé graphe ontologique, fournit une représentation des types d’entités et des relations d’un graphe de connaissances, fournissant ainsi une structure conceptuelle sans contenir de données spécifiques.

3. L’inférence d’informations implicites sur base d’informations explicites.

Il est possible de trouver des informations qui n’étaient pas présentes dans les données initiales sur base de règles d’inférence (Voir Figure 3).

Un aperçu du modèle RDF (Resource Description Framework)

Initialement conçu pour la description formelle de ressources web et leurs métadonnées, le modèle RDF est fréquemment utilisé pour les graphes de connaissances car il permet un raisonnement sémantique robuste et une très grande interopérabilité.

Un document en RDF prend la forme d’un ensemble de triplets RDF, chaque triplet est une association : sujet (ressource à décrire), prédicat (propriété de la ressource), objet (donnée ou autre ressource).

Par exemple :

:Alice :knows :Bob .
:Alice :livesIn :Paris .
:Alice :age 30 .

Ces triplets représentent donc aussi bien des relations entre nœuds (par exemple : la relation entre Alice et Bob) que des propriétés (l’âge d’Alice).

Une spécificité de RDF est qu’il nécessite que chaque élément d’un triplet (à l’exception de l’objet s’il s’agit d’une valeur simple, tel que la valeur 30 pour l’âge d’Alice) soit identifié par un URI (Uniform Resource Identifier) ou IRI (Internationalized Resource Identifier). Cela permet une grande interopérabilité car cela évite la création de doublons lorsque plusieurs sources d’information sont combinées. Si nous reprenons les triplets utilisés précédemment, nous obtenons le fragment suivant (en langage turtle) :

<http://example.org/Alice> <http://example.org/knows> <http://example.org/Bob> .
<http://example.org/Alice> <http://example.org/livesIn> <http://example.org/Paris> .
<http://example.org/Alice> <http://example.org/age> "30"^^<http://www.w3.org/2001/XMLSchema#integer> .

L’utilisation de RDF implique donc d’avoir un URI afin de pouvoir identifier tous les concepts (sujets, prédicats et objets) du graphe à l’instar d’une clé primaire dans les bases de données relationnelles.

De plus, il existe deux outils permettant d’ajouter de la signification sémantique aux données RDF, en décrivant les relations afin de permettre le raisonnement, à savoir RDFS (RDF Schema) et OWL (Web Ontology Language). Comme nous l’avons vu, RDF impose que chaque concept soit identifié par un URI. RDFS et OWL fournissent un ensemble prédéfini d’URI pour des concepts fréquemment utilisés, auxquels on peut faire référence dans RDF. Ceci permet d’une part d’avoir un vocabulaire commun standardisé, ce qui facilite l’intégration d’autres bases de données, et d’autre part d’établir des règles d’inférence. En effet, puisque OWL et RDFS proposent des concepts standardisés, cela permet à des « raisonneurs » basés sur OWL (tels que FaCT++ ou HermiT) d’inférer les relations implicites de façon systématique ou de détecter des contradictions, sur base de l’ontologie.

Les requêtes sur une base de données RDF se font via SPARQL.

Les alternatives à RDF, et les outils pour travailler avec un graphe de connaissances

Bien évidemment, un graphe de connaissances ne nécessite pas forcément l’utilisation du modèle RDF. Un graphe sera considéré comme graphe de connaissances tant que les 3 conditions décrites en début de section sur les graphes de connaissances sont remplies. Il est donc parfaitement possible de créer un graphe de connaissances dans un outil classique de gestion de base de données orientée graphe, tant que l’implémentation combine des données de plusieurs sources, qu’elle est conforme à une ontologie et qu’elle peut être utilisée pour de l’inférence sémantique.

La principale force du modèle RDF est son niveau de standardisation élevé. D’une part, via son exigence d’identification par URI, ainsi que son vocabulaire et son langage de requête standardisés, elle permet une haute interopérabilité. D’autre part, les extension RDFS et OWL permettent d’offrir une richesse sémantique rendant possible un raisonnement automatique. En contrepartie, sa complexité limite son adoption dans des applications business où cette rigueur sémantique n’est pas forcément nécessaire et où l’utilisation d’un modèle de graphe plus simple (tel que Neo4j ou TigerGraph) suffit. L’utilisation de modèles plus simples offre l’avantage d’être plus facile et rapide à mettre en place et d’offrir des performances de requêtage optimisées, mais au prix de la perte de la richesse sémantique offerte par RDF.

Cette section présente des outils (de façon non exhaustive) relatifs à RDF mais, comme mentionné, les outils précédemment cités pour les bases de données orientées graphe restent valides pour créer un graphe de connaissances tant que les conditions sont remplies.

Voici une liste de quelques outils liés aux graphes de connaissances en RDF :

• La conception d’ontologies : l’outil open-source Protégé est fréquemment utilisé pour créer des ontologies. Le site schema.org fournit un grand nombre de schéma et vocabulaires standards pour différents domaines, mais est généralement plutôt utilisé pour des graphes de connaissances relatifs aux données web.
• La transformation de données vers RDF : l’outil R2RML permet de transformer des données relationnelles vers RDF. Nous pouvons aussi mentionner D2RQ, qui donne accès à une base de données relationnelle via un graphe de connaissances RDF virtuel.
• Le stockage de données : en plus des solutions mentionnées précédemment (GraphDB et Amazon Neptune), nous pouvons aussi mentionner BlazeGraph et Apache Jena (open-source) ou encore Stardog et AllegroGraph (solutions commerciales).
• Les raisonneurs OWL : il existe de nombreux raisonneurs OWL. Tous ne sont cependant pas forcément activement maintenus ou toujours utilisables. La liste de raisonneurs OWL la plus récente que nous ayons pu trouver date de 2023 et est accessible ici [6].

Terminons par mentionner le framework RDF4J (framework Java) et rdflib (libraire python) permettant d’interagir avec des données RDF.

Conclusion

Terminons par une rapide synthèse des concepts clés qui séparent un graphe mathématique d’une base de données orientée graphe et d’un graphe de connaissances.

Un graphe mathématique est un ensemble de nœuds et d’arcs facilement représentable sous forme matricielle afin d’y appliquer des algorithmes. C’est la structure sous-jacente de toute base de données orientée graphe ou graphe de connaissances.

Une base de données graphe comporte un ensemble de nœuds, d’arcs et de propriétés. L’accent est mis sur le stockage de grandes quantités de données au sein d’une structure graphe et sur l’optimisation du requêtage.

Un graphe de connaissances a pour but de représenter le savoir au sein d’un graphe mettant l’accent sur :

• La sémantique : Le graphe suit une ontologie et les relations ont une signification.
• L’intégration : Diverses sources de données sont liées dans un graphe unifié.
• L’inférence : La capacité à dériver des connaissances via un raisonnement.

Il est donc concentré sur l’intégration et l’enrichissement sémantique des données.

Il va sans dire que cet article ne fait qu’effleurer la surface de la vaste littérature des graphes et leurs applications diverses, et que nombreux points mériteraient un développement plus poussé et feront d’ailleurs sans doute l’objet de futurs articles.

Références

[1] Graph DB vs RDBMS

[2] Sept (bonnes) raisons d’utiliser une Graph Database

[3] Les graphes de connaissance, incontournable pour l’intelligence artificielle

[4] Smals KG Checklist: déterminer si un graphe de connaissances peut résoudre un problème concret

[5] Ehrlinger, L., & Wöß, W. (2016). Towards a definition of knowledge graphs. SEMANTiCS 2016, 48(1-4), 2.

[6] Abitch, K., (2023). “OWL Reasoners still useable in 2023”

Ce post est une contribution individuelle de Pierre Leleux, data scientist et network data analyst chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Grâce à leur capacité à comprendre et exploiter les relations complexes entre les données, les technologies relatives aux graphes ont actuellement le vent en poupe, gagnant en popularité dans de nombreux domaines de l’intelligence artificielle et la gestion de données. Plusieurs articles ont d’ailleurs déjà été postés sur ce blog concernant différentes technologies de graphes, notamment sur les bases de données orientées graphe (graph database) [1, 2, 3] et les graphes de connaissances (knowledge graph) [4, 5, 6].

Mais que recouvre réellement le terme « graphe » ? Entre les modèles mathématiques qui servent de fondation, les bases de données orientées graphe et les graphes de connaissances, il peut être difficile de s’y retrouver et d’identifier les outils adaptés à ses besoins. Ajoutez à cela le fait que travailler sur des données organisées en réseau peut sembler complexe à première vue et que l’utilisation d’algorithmes de graphe ne fait pas partie des compétences de base de la plupart des data engineers et data scientists, et tout cela peut rendre décourageant la création et l’exploitation de données et de modèles de graphes.

Cet article a donc pour objectif de faire le point sur les technologies graphes, en explorant les 3 aspects mentionnés ci-dessus :

• Les graphes d’un point de vue théorique, leurs propriétés, leurs applications principales ;
• Les bases de données orientées graphe, spécialisées dans le stockage et l’exploitation de données connectées ;
• Les graphes de connaissances qui structurent le savoir de manière sémantique.

Le but est donc de présenter ces concepts, les frontières – parfois floues – qui les séparent, ainsi que de mettre en lumière leurs utilisations et les outils et logiciels qui y sont associés.

Cet article est divisé en deux parties. Cette première partie est consacrée aux graphes dans leur forme mathématique fondamentale, comment les encoder et les exploiter, ainsi qu’aux principaux algorithmes et leurs applications. La seconde partie portera sur les bases de données orientées graphe et graphes de connaissances et les outils qui y sont associés.

Retour aux fondamentaux : les graphes en tant que structure mathématique

Avant toute chose, commençons par définir ce qu’est un graphe. Cette base théorique est cruciale car c’est dessus que se construisent les concepts de base de données orientée graphe et de graphe de connaissances. À tout moment, ces concepts plus avancés peuvent être ramenés à leur forme mathématique sous-jacente et, par extension, tous les modèles et algorithmes présentés ci-dessous sont applicables à des bases de données orientées graphe et graphes de connaissances.

Dans sa forme la plus fondamentale, un graphe est une structure mathématique constituée d’un ensemble de nœuds et d’arcs qui joignent des nœuds deux à deux. Les nœuds représentent typiquement des objets ou des personnes, et les arcs représentent des liens entre ces objets ou personnes. Par exemple, dans le cas d’un réseau social, un arc peut représenter un lien d’amitié entre deux utilisateurs.
Le graphe peut être soit dirigé soit non-dirigé. Dans le cas d’un graphe non-dirigé, les relations entre les nœuds sont toujours réciproques (par exemple, un lien d’amitié sur Facebook) alors que dans un graphe dirigé, un arc allant d’un nœud i à un nœud j n’implique pas forcément d’arc de sens opposé (par exemple, un site internet A ayant un hyperlien qui pointe vers un site B).

Suivant la situation ou l’application, un graphe peut aussi être pondéré ou non. Un graphe est dit pondéré lorsqu’un poids est associé à chaque arc, qui varie d’un arc à l’autre, et qui permet de donner plus de « force » à certains arcs. L’interprétation de ces poids dépend du contexte, ces poids peuvent par exemple représenter un degré d’affinité, de similarité, de dépendance, etc.

Un graphe est généralement représenté par une matrice carrée de dimension (n × n), où n est le nombre de nœuds du graphe, appelée matrice d’adjacence (notée A). L’élément en position (i, j) dans la matrice vaut le poids de l’arc allant du nœud i au nœud j s’il existe, et 0 sinon (voir Figure 1). La matrice d’adjacence est simplement une matrice binaire lorsque le graphe n’est pas pondéré.

Dans l’exemple illustratif, il y a un arc de poids 3 allant du nœud 1 au nœud 3, et un arc de poids 5 allant dans le sens inverse. La matrice A contient donc la valeur 3 en position (1,3) et la valeur 5 en position (3,1).

Il est à noter que les matrices d’adjacence contiennent souvent une très large majorité de zéros, et sont donc généralement encodées via des matrices creuses (sparse matrix) afin d’optimiser la mémoire.

Cette représentation d’un graphe sous forme d’une matrice facilite fortement l’utilisation d’algorithmes sur le graphe, car nombre d’algorithmes de graphe, parfois complexes sous forme d’équations, peuvent souvent être résumés à une série d’opérations matricielles élémentaires. Ceci rend leur exécution très efficace dans des langages de programmation scientifiques optimisés pour les calculs matriciels, tels que R, MATLAB, Julia ou Python (numpy, scipy).

Utilisations d’algorithmes de graphe et applications pratiques

Pour mieux comprendre l’intérêt d’un graphe, commençons dans un premier temps par regarder les grandes catégories d’algorithmes de graphe, avec, pour chaque catégorie, quelques exemples d’utilisation pratique de ceux-ci.

• Déterminer le chemin optimal permettant de joindre une paire de nœuds.

Il peut simplement s’agir de minimiser le nombre de transitions nécessaires pour passer d’un nœud à l’autre, ou alors, si un coût est associé à chaque arc, de trouver le chemin associé au coût le plus faible. Le coût peut-être défini en tant que poids d’un arc, ou encodé dans une seconde matrice (matrice de coût, indépendante de la matrice d’adjacence). La façon dont le coût d’un arc est déterminé dépend de l’application, en fonction de ce que l’on souhaite minimiser. Il peut s’agir, par exemple, d’une mesure de longueur de l’arc (telle que la longueur d’une route), une mesure de temps (le temps nécessaire pour franchir l’arc) ou un coût financier. Ce genre d’algorithme peut être utilisé en logistique pour optimiser le transport. Les algorithmes les plus connus en la matière étant les algorithmes de Dijkstra, A*, ou encore l’algorithme de Bellman-Ford.

• Établir des mesures de similarité ou de distance entre des nœuds d’un graphe.

Suivant le contexte, il peut être intéressant d’établir une mesure de similarité entre deux nœuds d’un graphe afin de déterminer à quel point ils sont proches l’un de l’autre. L’utilisation de mesures de similarité est une approche souvent utilisée dans les applications de recommandation. En construisant un graphe de consommation qui lie les utilisateurs aux produits qu’ils ont consommés, mesurer la similarité entre les nœuds permet d’identifier, pour un utilisateur donné, des utilisateurs ayant un profil de consommation similaire, en se basant sur leurs liens avec les produits. Typiquement, un produit sera recommandé à un utilisateur soit parce qu’il a été consommé par de nombreux utilisateurs similaires (user-based recommendation) soit car le produit est similaire à ceux déjà consommés par l’utilisateur (item-based recommendation). Les mesures de similarité les plus connues se basent généralement sur des mesures de voisinage commun (le nombre de voisins en commun que possèdent deux nœuds), telles que l’indice de Jaccard ou la similarité cosinus, mais d’autres méthodes permettent de prendre aussi en compte le voisinage indirect, telles que le kernel de Katz [12] (aussi connu sous le nom de « von Neumann kernel »). Pour voir quelques mesures de similarité classiques et leur utilisation en recommandation, voir [13].

L’opposé d’une mesure de similarité est une mesure de dissimilarité, qui augmente à mesure que les deux nœuds sont différents. Une mesure de distance est, par définition, une dissimilarité, puisqu’elle augmente lorsque deux nœuds sont éloignés. La mesure de dissimilarité la plus connue et la plus intuitive entre deux nœuds est la longueur du plus court chemin qui les sépare.

• Mesurer la centralité.

Une mesure de centralité d’un nœud ou d’un arc, parfois aussi appelée mesure de prestige, sert à quantifier à quel point un nœud ou un arc est important au sein d’un graphe. La mesure de centralité la plus connue est, de loin, le score calculé par l’algorithme PageRank [14]. Initialement développé et utilisé par le moteur de recherche Google pour hiérarchiser les pages web, PageRank se base sur une marche aléatoire sur un graphe où chaque nœud représente une page web et chaque arc dirigé représente un hyperlien entre deux pages. L’algorithme PageRank trouve de nombreuses applications au-delà de la hiérarchisation de pages web :

“Google’s PageRank method was developed to evaluate the importance of web-pages via their link structure. The mathematics of PageRank, however, are entirely general and apply to any graph or network in any domain. Thus, PageRank is now regularly used in bibliometrics, social and information network analysis, and for link prediction and recommendation. It’s even used for systems analysis of road networks, as well as biology, chemistry, neuroscience, and physics.” – Gleich (2014) [15]

Un autre algorithme très connu, similaire à PageRank, est l’algorithme HITS (Hyperlink-Induced Topic Search) [16].

Lorsque l’on parle de centralité, PageRank est souvent l’algorithme présenté, cependant, la centralité peut se comprendre de plusieurs manières. Il peut par exemple s’agir d’un nœud ou d’un arc constituant un intermédiaire critique pour la communication et la transmission d’information au sein du réseau. Repérer des nœuds centraux peut par exemple permettre d’optimiser la diffusion d’information dans un réseau ou de détecter des nœuds ou des arcs vitaux au graphe (dont la disparition nuirait fortement à la transmission d’information dans le graphe). Des mesures fréquentes de centralité de nœuds ou d’arcs se basant sur ce principe utilisent généralement des mesures « d’intermédiarité » (betweenness centrality).

La centralité peut aussi se comprendre comme la mesure de la représentativité d’un nœud au sein d’une communauté (en termes de proximité vis-à-vis des autres nœuds du graphe), se mesurant ici plutôt avec une mesure de proximité (closeness centrality). Il est à noter que nous avons déjà mentionné l’utilisation de différents algorithmes de centralité dans un cadre de détection de fraude dans des articles de blog précédents, notamment PageRank (sous forme d’un algorithme de diffusion) [7] et la betweenness centrality [8].

• Partitionner le graphe.

Plus connu sous le nom de « clustering », le partitionnement de graphe consiste à regrouper des nœuds en communautés (clusters) tels que les nœuds au sein d’une communauté sont « similaires » et deux nœuds appartenant à des communautés différentes sont dissimilaires. Ce partitionnement peut se faire de plusieurs manières. Par exemple en utilisant une mesure de similarité ou de dissimilarité entre les nœuds du graphe, puis en exécutant un algorithme de clustering tel que le k-médoïdes sur base de ces (dis-)similarités.

Ou alors, en travaillant directement sur le graphe en cherchant à détecter des zones denses dans celui-ci. Cela peut se faire via de la propagation de label [17], ou via l’optimisation d’une fonction objectif mesurant la qualité du partitionnement, telle que la modularité. L’algorithme d’optimisation de la modularité le plus célèbre est la méthode de Louvain [18].

Nous avions déjà mentionné l’utilisation des méthodes de partitionnement de graphes dans plusieurs articles de blog [9, 10], ces algorithmes sont utilisés notamment en communication et marketing afin de pouvoir réaliser des annonces ciblées.

• Extraire des caractéristiques ou des représentations.

Une des limites des modèles de machine learning classique est qu’ils considèrent uniquement les données (variables continues et catégorielles) relatives aux observations, et ignorent l’information qui pourrait être tirée des relations entre les observations. Si des relations existent entre ces données, un graphe peut être construit, et les modèles de machine learning peuvent être enrichis via l’ajout de nouvelles variables extraites du graphe (il y a aussi un article de blog à ce sujet [11]). Ces nouvelles variables peuvent par exemple être une mesure de centralité (variable continue) ou le résultat d’un partitionnement (variable catégorielle), ou encore être obtenues via des méthodes de graph embedding (variables continues). Le graph embedding vise à obtenir une représentation des nœuds dans un espace multidimensionnel. Cet espace est calculé de sorte que, si deux nœuds sont proches dans le graphe, ils le seront aussi dans cet espace. Cet espace peut par exemple s’obtenir via des méthodes travaillant directement sur le graphe (node2vec [19], fastRP [20]) ou en travaillant sur base de similarités (kernelPCA [21]) ou de distances (t-SNE [22]) par exemple. Voir Figure 3 pour un exemple de représentation en 2 dimensions d’un graphe pondéré simple.

• Prédire des liens.

Le concept de prédiction de lien est relativement explicite, il s’agit d’estimer la probabilité qu’un lien existe entre 2 nœuds. Cela permet de détecter des potentiels arcs manquants (graphe incomplet), ou de prédire l’apparition de nouveaux arcs. Les algorithmes de recommandations sont un exemple courant de prédiction de lien utilisateur-produit, mais ces algorithmes peuvent aussi servir à détecter des potentielles interactions encore inconnues à l’intérieur de réseaux biologiques. Ce genre de prédiction se fait souvent via des méthodes basées sur des similarités entre nœuds, de la factorisation matricielle, des modèles probabilistes ou des réseaux de neurones artificiels [23].

Quels outils ?

Comme mentionné précédemment, la représentation de graphes sous forme matricielle permet de les exploiter de façon efficace via des langages de programmation scientifiques. Cependant, il existe aussi des librairies ou logiciels permettant de créer et exploiter des données de graphe.

Voici quelques exemples de librairies dédiées au travail sur les graphes. Ces librairies permettent de créer un objet graphe, qui peut être construit de plusieurs manières. Il peut être construit à vide, avant d’y ajouter manuellement des nœuds et des arcs, ou alors à partir d’une matrice d’adjacence ou d’une liste d’arcs, ou bien encore directement depuis des fichiers contenant une description du graphe sous la forme d’une liste de nœuds et d’arcs. Quelques exemples de librairies orientées graphe incluent igraph, networkx, graph-tool ou networkit pour Python, igraph pour R et Graphs pour Julia.

Pour un utilisateur ayant déjà des connaissances dans l’un de ces langages, ces libraires ont l’avantage d’être intuitives et faciles à prendre en main, et contiennent de nombreux algorithmes de graphe pré-implémentés.

Il existe aussi de nombreux logiciels prévus pour l’analyse du contenu de bases de données orientées graphe, tels que Gephi ou Cytoscape (pour une liste plus détaillée, nous vous invitons à vous référer à l’un de nos précédents articles sur le sujet : [3]). Il s’agit bien de logiciels créés pour des analyses ponctuelles ou des explorations visuelles des relations dans des ensembles de données, mais qui ne sont pas conçus pour intégrer et gérer de grandes quantités de données de manière continue comme le ferait une base de données orientée graphe.

Conclusion

Dans la première partie de cet article dédié aux différentes technologies basées sur les graphes, nous avons fait une rapide présentation de la théorie des graphes, ainsi que des principaux algorithmes de graphe et leurs applications. La seconde partie se penchera sur les bases de données orientées graphe et les graphes de connaissances, les différences entre ces concepts ainsi que les outils qui y sont associés.

Références

Quelques articles de blog Smals Research concernant les graphes :

[1] Graph DB vs RDBMS

[2] Sept (bonnes) raisons d’utiliser une Graph Database

[3] Explorer une base de données orientée graphes

[4] Les graphes de connaissance, incontournable pour l’intelligence artificielle

[5] Les graphes de connaissance : quelques applications

[6] Smals KG Checklist: déterminer si un graphe de connaissances peut résoudre un problème concret

[7] Un fraudeur ne fraude jamais seul

[8] Un fraudeur ne fraude jamais seul, partie 2

[9] Ce qu’un réseau social peut nous apprendre

[10] Facebook : peut-on vraiment cacher sa liste d’amis ?

[11] Améliorer le Machine Learning avec des données graphes

Sources scientifiques :

[12] Katz, L. (1953). A new status index derived from sociometric analysis. Psychometrika, 18(1), 39-43.

[13] Fouss, F., Pirotte, A., Renders, J. M., & Saerens, M. (2007). Random-walk computation of similarities between nodes of a graph with application to collaborative recommendation. IEEE Transactions on knowledge and data engineering, 19(3), 355-369.

[14] Page, L., Brin, S., Motwani, R., & Winograd, T. (1998). The pagerank citation ranking: Bringing order to the web. Technical report, Stanford Digital Libraries.

[15] Gleich, D. F. (2015). PageRank beyond the web. siam REVIEW, 57(3), 321-363.

[16] Kleinberg, J. M. (1999). Authoritative sources in a hyperlinked environment. Journal of the ACM (JACM), 46(5), 604-632.

[17] Raghavan, U. N., Albert, R., & Kumara, S. (2007). Near linear time algorithm to detect community structures in large-scale networks. Physical Review E—Statistical, Nonlinear, and Soft Matter Physics, 76(3), 036106.

[18] Blondel, V. D., Guillaume, J. L., Lambiotte, R., & Lefebvre, E. (2008). Fast unfolding of communities in large networks. Journal of statistical mechanics: theory and experiment, 2008(10), P10008.

[19] Grover, A., & Leskovec, J. (2016). node2vec: Scalable feature learning for networks. In Proceedings of the 22nd ACM SIGKDD international conference on Knowledge discovery and data mining (pp. 855-864).

[20] Chen, H., Sultan, S. F., Tian, Y., Chen, M., & Skiena, S. (2019, November). Fast and accurate network embeddings via very sparse random projection. In Proceedings of the 28th ACM international conference on information and knowledge management (pp. 399-408).

[21] Schölkopf, B., & Smola, A. J. (2002). Learning with kernels: support vector machines, regularization, optimization, and beyond.

[22] Van der Maaten, L., & Hinton, G. (2008). Visualizing data using t-SNE. Journal of machine learning research, 9(11).

[23] Lü, L., & Zhou, T. (2011). Link prediction in complex networks: A survey. Physica A: statistical mechanics and its applications, 390(6), 1150-1170.

Ce post est une contribution individuelle de Pierre Leleux, data scientist et network data analyst chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.