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.

Comme outil de génération de code pour les développeurs de logiciels, Github Copilot domine le marché aujourd’hui. Cette situation devrait perdurer, d’autant plus que l’outil s’est enrichi d’une fonctionnalité de messagerie instantanée à la ChatGPT. Propriété de Microsoft, Github bénéficie d’une ligne directe avec OpenAI, et est donc le premier à profiter du rôle de pionnier que cette société continue de jouer dans le développement de grands modèles de langage (abrégé LLM en anglais) 

On en oublierait presque qu’il existe d’autres options. La première alternative à grande échelle construite sur une base open source, incluant des jeux de données d’apprentissage ouverts, est StarCoder, dont une version 2 a récemment vu le jour. Elle est développée dans le cadre de l’initiative BigCode de ServiceNow et de HuggingFace. L’article qui l’accompagne offre un aperçu fascinant de la construction d’un modèle de langage pour la génération de code. Peu après StarCoder, WizardCoder, CodeLLama, DeepSeekCoder et quelques autres sont apparus sur la scène, pas tous fondés sur un ensemble de données ouvertes, mais librement accessibles et réutilisables via HuggingFace.  

Aujourd’hui, il existe aussi suffisamment d’outils pour faciliter l’exécution de ces modèles sur votre propre machine. Vous pouvez donc avoir votre propre assistant de codage personnel, hébergé par vous-même et entièrement privé. Pour cela, il vous faut un matériel suffisamment puissant, un LLM axé sur les tâches de code completion ou sur les conversations concernant le code, et une extension pour l’environnement de développement (IDE). Le LLM et l’extension de l’IDE communiquent entre eux via une API, qui peut être compatible ou non avec celle d’OpenAI, ce qui permet de passer facilement d’un modèle commercial (OpenAI) à un modèle open source le cas échéant. 

Extensions pour IDE

L’installation d’une extension est simple en soi. Github Copilot existe depuis longtemps en tant qu’extension pour VSCode et aujourd’hui également pour IntelliJ IDEA – même si au moment de la rédaction de cet article, la version d’IntelliJ contient encore un peu moins de fonctionnalités.  

Parmi les alternatives open source, Continue figure probablement parmi les meilleures à ce jour. Il en existe d’autres – Huggingface a développé llm-vscode par exemple – et il ne fait aucun doute que d’autres viendront s’ajouter. Tout comme Github Copilot, Continue existe également sous forme d’extension pour VSCode ou IntelliJ. L’outil peut utiliser à la fois des générateurs commerciaux basés sur le cloud (notamment GPT-4) et des solutions open source auto-hébergées, qui ne doivent pas nécessairement émuler l’API d’OpenAI et autorisent de nombreuses personnalisations. 

Il demeure important de prendre le temps de se familiariser avec l’extension. La documentation de Continue constitue une bonne base à cet effet. Pour chaque serveur et chaque LLM, il se peut que vous deviez définir différentes options de configuration et que vous souhaitiez apporter des modifications à l’invite de commande sous-jacente. Il convient également de savoir comment activer et désactiver l’extension dans l’IDE et de connaître les raccourcis et commandes disponibles. YouTube peut être un bon point de départ pour trouver des tutoriels et des exemples d’autres utilisateurs. 

Un LLM sur votre ordinateur portable 

Notamment sous l’impulsion du projet open source llama.cpp, des efforts considérables ont été faits au cours de l’année écoulée pour faire en sorte que les LLM puissent également être déployés sur du matériel informatique grand public. Un processeur graphique (GPU) au coût prohibitif n’est plus nécessaire, même s’il offre un gain de temps considérable. Globalement, llama.cpp permet de reconditionner un modèle au format GGUF (GPT-Generated Unified Format). Il s’agit ici d’appliquer un maximum d’optimisations : 

• l’utilisation de jeux d’instructions du processeur ( CPU) efficaces tels que  AVX-512 – il va sans dire que le matériel sur lequel le modèle fonctionnera plus tard doit également prendre en charge ces jeux d’instructions ; 
• l’utilisation de bibliothèques hautement optimisées pour les calculs sous-jacents, telles que openBLAS ou Accelerate et Metal d’Apple ; 
• la quantification du modèle, par la réduction de la précision des poids dans les couches des réseaux neuronaux. Les nombres (à virgule flottante) de 16 ou 32 bits du modèle original sont ici convertis en nombres entiers de 8 bits, voire de 6 bits ou même de 4 bits. Cela permet d’économiser de la mémoire et d’accélérer les calculs, au prix d’une perte de qualité relativement faible. 

L’hébergement local d’un LLM peut être réalisé à l’aide d’outils tels que LM Studio. Ceux-ci vous permettent de télécharger différents modèles au format GGUF. Un onglet séparé dans l’application vous permet de démarrer un serveur d’inférence utilisant le protocole HTTP autour d’un modèle téléchargé et activé, qui simule l’API d’OpenAI. Une fois ce serveur mis en place, par exemple sur le port 1234, le modèle est accessible via un appel à http://localhost:1234/v1/chat/completions .

Cette configuration dans l’extension Continue se fait par l’ajout du LLM au fichier .continue/config.json, suivant ces instructions et selon les directives pour LM Studio en tant que fournisseur de modèle. Vous pouvez adapter le titre et le modèle comme bon vous semble, et il vous suffit d’ajouter la ligne "apiBase":"http://127.0.0.1:1234/v1" Dans l’extension, vous verrez alors apparaître une nouvelle option, et vous pourrez commencer à l’utiliser. 

Interlude : à propos du matériel

La gestion des GPU n’est déjà pas une partie de plaisir pour un développeur sur une seule machine. Les problèmes d’incompatibilité entre les différentes versions de toutes sortes de bibliothèques logicielles et de pilotes de GPU peuvent prendre des jours à résoudre. L’offre du marché des GPUs pour data centers, dominée par le monopole de nVIDIA, reste d’un coût prohibitif. À cela s’ajoute le coût de l’acquisition des connaissances très spécialisées nécessaires au fonctionnement de ces systèmes. Le matériel que vous choisirez sera probablement complètement obsolète dans quelques années. Un nouveau matériel, conçu spécifiquement pour accélérer le type de calculs des modèles d’IA, fait l’objet d’un travail acharné. Google a déjà présenté le TPU, mais d’autres fabricants se concentrent aujourd’hui pleinement sur les NPU (Neural Processing Units), et certains osent entrer en concurrence directe avec nVIDIA.  

Si vous n’avez pas le temps de vous occuper des pilotes de GPU et que vous n’avez pas l’ambition d’entraîner les modèles vous-même, la possibilité de les utiliser sur un CPU ordinaire est plus que bienvenue. Bien sûr, vous êtes alors limité aux LLM ou aux modèles d’IA dont la taille le permet. Les LLM “domestiques” typiques ont 3, 7 ou 13 milliards de paramètres ; les modèles plus grands sont agressivement quantifiés pour économiser de l’espace sur le disque et la mémoire.  Ils ne seront pas en mesure d’égaler la qualité de GPT-4 aujourd’hui, mais heureusement, des classements existent pour aider à opérer un choix – pour les LLM ouverts en général, spécifiquement avec des benchmarks de vitesse (débit), ou pour les LLM générateurs de code en particulier. 

Plus les LLM sont grands, plus la qualité du résultat est élevée (en général), mais plus la mémoire et la puissance de traitement requises sont importantes. Un LLM doit de préférence pouvoir être entièrement chargé dans la mémoire, de sorte que 16 GB de RAM n’est pas un luxe – plus c’est encore mieux, surtout si vous voulez faire fonctionner un IDE sur la même machine. Pour fournir une réponse, le modèle complet doit souvent être exécuté plusieurs fois. Par conséquent, le goulot d’étranglement est souvent la bande passante entre le CPU et la RAM. Les CPU dotés d’une grande mémoire cache interne semblent avoir une longueur d’avance (voir également les benchmarks spécifiques à l’IA [1,2] d’Anandtech). Lors du choix du reste du matériel, la bande passante de la mémoire devrait certainement entrer en ligne de compte. Même ceux choisissant un GPU pourraient préférer considérer cette bande passante plutôt que le nombre de cœurs du GPU. Enfin, dans les environnements virtualisés (VM, VPS), il est important que le CPU virtuel prenne en charge les mêmes jeux d’instructions avancés, tels que AVX-512. 

Un LLM sur votre serveur 

Si vous disposez d’une machine plus puissante, il peut être intéressant d’y exécuter le LLM. ollama est probablement l’outil le plus populaire pour héberger des modèles sur Mac ou Linux sans trop de difficultés, et depuis peu également sur Windows. LocalAI est toutefois une option tout aussi intéressante dans la liste des fournisseurs de LLM pour Continue, car il propose des conteneurs Docker, avec ou sans support GPU. Sur une machine Linux équipée de Docker, un one-liner dans le terminal suffit pour télécharger le modèle CodeLlama open source et l’héberger sur le port 1234 : 

docker run -ti -p 1234:8080 localai/localai:v2.7.0-ffmpeg-core codellama-7b-gguf 

Cependant, son démarrage prend un certain temps, car le modèle est téléchargé dans le conteneur. Il est plus intéressant de stocker soi-même une série de modèles dans un répertoire local et d’y associer une API à l’aide d’un conteneur LocalAI. Des instructions relativement simples sont disponibles pour cela aussi. Nous pouvons par exemple les appliquer au LLM LLM DeepSeek de 6,7 milliards de paramètres, quantifiés à 4 bits. Il peut être téléchargé directement depuis Huggingface dans le répertoire local ./models-gguf à l’aide d’une commande wget du type : 

wget https://huggingface.co/TheBloke/deepseek-coder-6.7B-instruct-GGUF/resolve/main/deepseek-coder-6.7b-instruct.Q4_K_M.gguf -O ./models-gguf/deepseek-6.7b-instruct-Q4

Démarrer une API autour des modèles de ce répertoire sur le port 8001 (vous pouvez aussi placer plusieurs modèles dans le même répertoire et les héberger simultanément), peut alors se faire avec la commande suivante . Ajoutez éventuellement -d pour qu’elle s’exécute en arrière-plan, et n’hésitez pas à expérimenter les paramètres context-size et threads en fonction de la puissance de votre serveur :

docker run -p 8001:8080 -v $PWD/models-gguf:/models -ti --rm quay.io/go-skynet/local-ai:v2.7.0-ffmpeg-core --models-path /models --context-size 1600 --threads 16

Exemple

Nous pouvons maintenant comparer différents LLM pour le code. Nous nous en tiendrons ici à l’anecdote et prendrons l’écriture d’un script shell bash comme exemple simple. Nous partons du problème suivant : une routine de sauvegarde a effectué des sauvegardes nocturnes d’un système pendant des années. Pour libérer de l’espace disque, nous voulons supprimer toutes les sauvegardes qui ne diffèrent pas des précédentes. Nous lançons la commande suivante, en décrivant la tâche le plus précisément possible afin d’obtenir les meilleurs résultats : “Write a bash script that, given a directory, iterates over all its files in order of date of creation. For each file, if the filesize is equal to the filesize of the previous file, the file has to be deleted.” 

Le fichier .continue/config.json de notre extension Continue contient la liste suivante de modèles : un sur le propre ordinateur portable dans LM Studio chargé sur le port 1234, et deux sur un serveur séparé, mais sur le même réseau local, hébergé par LocalAI sur le port 8001. 

    {
      "title": "myLaptop-LMStudio",
      "model": "whatever is loaded in LMstudio",
      "apiBase": "http://127.0.0.1:1234/v1",
      "completionOptions": {},
      "provider": "lmstudio"
    },       
    {
      "title": "localAI-mistral",
      "model": "mistral-7b-code16kqlora-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",      
      "completionOptions": {},
      "provider": "openai"
    },
    {
      "title": "localAI-deepseek",
      "model": "deepseek-6.7b-instruct-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",
      "completionOptions": {},
      "provider": "openai"
    },

Comme référence, nous prenons ChatGPT, qui propose la solution (correcte) suivante.  
En outre, elle est également suivie d’une explication détaillée de la signification des différentes parties (non présentée ici) : 

#!/bin/bash

# Directory containing the files
DIR="/path/to/your/directory"

# Variable to hold the size of the previous file. Initialized to 0.
prev_size=0

# List all files in the directory, sorted by creation date
# Note: '%T@' sorts by creation time, '%p' prints the file's name
# 'sort -n' ensures the list is sorted numerically
# Note that creation time sorting may depend on filesystem and OS support
files=$(find "$DIR" -type f -printf "%T@ %p\n" | sort -n | cut -d ' ' -f 2-)

# Iterate over the sorted list of files
for file in $files; do
  # Get current file size
  current_size=$(stat -c %s "$file")
  
  # Check if current file size is equal to the previous file's size
  if [ "$current_size" -eq "$prev_size" ]; then
    # Sizes are equal, delete the current file
    echo "Deleting file: $file"
    rm "$file"
  fi
  
  # Update previous size to current file's size
  prev_size=$current_size
done

Dans LMStudio, nous chargeons le modèle “CodeNinja 1.0 openchat 7B Q4_K_M“. Il faut plus d’une minute pour générer la réponse à la même question : 20 secondes d’attente pour l’apparition de la première lettre de la réponse, puis environ 2 secondes par ligne (bien sûr, notre ordinateur portable n’est pas très puissant : un CPU Core i7-10610U avec 32GB de RAM). Le résultat se présente comme suit : 

#!/bin/bash

for f in $(ls -t -l --time-style=full /path/to/directory)
do
  if [[ $f == "total"* ]]; then
        continue;
    fi
    filename=$(basename "${f% *}")

    # Checks whether the file is already deleted. If not, compares it with the previous file:
    prev_file=""
    while IFS= read -r line; do
        if [[ $line == $filename ]]; then
            prev_file=$line
            break;
        fi
    done <<<"$(ls -l /path/to/directory | tail -n 2)"

    if [[ -z $prev_file || "$f" = "${prev_file}" ]]; then
        # If the file is deleted, nothing to do. If not, deletes it:
        if [[ -z $prev_file ]] || [[ "$(stat -c %s ${filename})" == "$(stat -c %s ${prev_file})" ]]; then
            rm /path/to/directory/$filename
        fi
    fi
done

Nous chargeons le modèle DeepSeek de 6,7 milliards de paramètres dans LocalAI sur une VM Debian dans Proxmox. La VM se voit allouer beaucoup de mémoire vive et 12 cœurs du micro-processeur AMD Threadripper 3960X sous-jacent (24 cœurs au total mais pas de support AVX-512). Nous créons ainsi à un rythme d’environ 3 lignes par seconde le résultat suivant : 

#!/bin/bash

# Check if directory is provided
if [ $# -ne 1 ]; then
  echo "Usage: $0 directory"
    exit 1
fi

# Check if directory exists
if [ ! -d "$1" ]; then
    echo "Directory $1 does not exist"
    exit 1
fi

# Change to the directory
cd "$1"

# Get the list of files in order of creation date
files=$(ls -t)

# Initialize previous_size to 0
previous_size=0

# Iterate over the files
for file in $files; do
    # Get the size of the file
    size=$(stat -c%s "$file")

    # If the size is equal to the previous size, delete the file
    if [ $size -eq $previous_size ]; then
        rm "$file"
        echo "Deleted $file"
    fi

    # Update previous_size
    previous_size=$size
done

Enfin, sur la même VM, nous pouvons également essayer Mistral, pour lequel nous choisissons au hasard la version mistral-7B-code-16K-qlora qui a été légèrement adaptée par fine-tuning pour le code par un internaute. Il s’avère que sa réponse est rapide, générant le résultat compact suivant en quelque 2 secondes (malheureusement sans documentation, et en proposant la commande complexe awk ) : 

for file in $(find directory -type f -exec du -sh {} + | sort -h | awk '{print NR ":\t" $1}'); do
    size=$(du -sh "$file" | awk '{print $1}')
    if [[ $size == $previous_size ]]; then
      rm "$file"
    fi
    previous_size=$size
done

Je laisse volontiers au lecteur le soin de procéder à une comparaison plus approfondie de ces résultats. Si nous devons tirer une dernière leçon de cette expérience, c’est que même si les modèles ont le même nombre de paramètres et sont entraînés dans le même but, il peut y avoir de très grandes différences de résultat et de style entre eux !  

Conclusion

À la vitesse de l’éclair, toutes sortes de fonctions alimentées par l’IA trouvent leur place dans l’IDE. Les dernières notes de mises à jour de Visual Studio Code mentionnent, par exemple, la prise en charge de la reconnaissance vocale dans plusieurs langues, en plus de plusieurs fonctionnalités de CoPilot. En tant que développeur, il est inévitable que vous soyez confronté à cette situation. Les développeurs qui travaillent avec des données sensibles ou du code protégé par des droits d’auteur doivent se méfier à juste titre de ces outils qui envoient le contenu de leur IDE à un service cloud tiers pour proposer des suggestions.  

Grâce notamment au projet llama.cpp, une voie alternative open source a récemment vu le jour, qui permet de mettre en place et d’exploiter soi-même une telle assistance au codage avec des LLM. Les modèles plus petits qui peuvent fonctionner sur du matériel grand public n’offrent actuellement pas la même qualité et la même vitesse que Github CoPilot ou ChatGPT. Toutefois, de nouvelles améliorations apparaîtront régulièrement au cours des prochaines années, de sorte que la voie à suivre semble prometteuse à tous points de vue.  

______________________

Ce post est une contribution individuelle de Joachim Ganseman, spécialisée en intelligence artificielle chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Als code-genererend hulpmiddel voor softwareontwikkelaars domineert Github Copilot vandaag de markt. Dat zal wellicht nog wel even aanhouden, zeker nu de tool ook wordt uitgebreid met chatfunctionaliteit à la ChatGPT. Als eigendom van Microsoft, geniet Github van een directe lijn met OpenAI en zo kan het als eerste meegenieten van de voortrekkersrol die dat bedrijf blijft spelen inzake de ontwikkeling van Large Language Models (LLMs).

Men zou haast vergeten dat er ook andere mogelijkheden zijn. Het eerste grootschalige alternatief dat van de grond af open-source was opgebouwd, inclusief open trainingsdata, is StarCoder, waar sinds kort ook een versie 2 van is uitgekomen. Het wordt ontwikkeld onder het BigCode initiatief van ServiceNow en HuggingFace. De bijhorende paper geeft een fascinerende inkijk in de opbouw van een taalmodel voor het genereren van code. Kort na StarCoder verschenen WizardCoder, CodeLLama, DeepSeekCoder en nog enkele anderen ten tonele – niet allemaal met een open dataset erachter, maar wel vrij toegankelijk en herbruikbaar via HuggingFace.

Ondertussen is er voldoende tooling beschikbaar om deze modellen gemakkelijker op een eigen machine te draaien. “Your Own Personal Coding Assistant”, self-hosted en volledig privaat, is vandaag haalbare kaart. We hebben daarvoor nodig: voldoende krachtige hardware, een LLM toegespitst op code completion taken of op conversaties over code, en een plugin voor de IDE. LLM en IDE plugin spreken met elkaar via een API, die al dan niet compatibel kan zijn met die van OpenAI – wat desgewenst toelaat gemakkelijk te wisselen tussen commerciële (OpenAI) en open source modellen.

IDE plugins

Een plugin installeren is op zich gemakkelijk. Github Copilot bestaat al langer als plugin voor VSCode en vandaag ook voor IntelliJ IDEA – al bevat de IntelliJ versie op moment van schrijven nog wat minder functionaliteit.

Onder de open-source alternatieven hoort Continue momenteel waarschijnlijk bij de top. Er zijn er andere – Huggingface zelf heeft bijvoorbeeld llm-vscode ontwikkeld – en ongetwijfeld zullen er nog bijkomen. Net zoals Github Copilot bestaat Continue ook als plugin voor VSCode of IntelliJ. Het kan zowel gebruikmaken van commerciële cloud-based generatoren (waaronder GPT-4) als van zelf gehoste open-source oplossingen. Die hoeven niet noodzakelijk de OpenAI API na te volgen, en er is veel customizatie mogelijk.

Het blijft belangrijk om tijd te investeren om met de plugin te leren werken. De documentatie van Continue is een goed startpunt. Voor elke server en elke LLM kunnen er andere configuratieopties zijn die ingesteld moeten worden, en misschien wil je custom aanpassingen maken aan de achterliggende prompt. Daarnaast is het nodig om te weten hoe de plugin geactiveerd en gedeactiveerd kan worden in de IDE, en welke shortcuts en commando’s er bestaan. YouTube kan een goed startpunt zijn om tutorials en voorbeelden van andere gebruikers te vinden.

Een LLM op je laptop

Vooral onder impuls van het open-source project llama.cpp, zijn er het afgelopen jaar enorme inspanningen gebeurd om LLMs ook inzetbaar te maken op gewone consumentenhardware. Een peperdure GPU is niet meer noodzakelijk, al gaat het met GPU wel nog steeds sneller. In grote lijnen laat llama.cpp toe om een model te herverpakken in het GGUF formaat (GPT-Generated Unified Format). Daarbij worden zoveel mogelijk optimalisaties toegepast:

• gebruik van efficiënte CPU-instructiesets zoals AVX-512 – het spreekt voor zich dat de hardware waarop het model later moet draaien, deze instructiesets ook moet ondersteunen,
• gebruik van sterk geoptimaliseerde high-performance libraries voor de achterliggende berekeningen, zoals openBLAS of Apples Accelerate en Metal,
• het kwantiseren van het model, door het reduceren van de precisie van de gewichten in de lagen van de neurale netwerken. De 16-bit of 32-bit (komma)getallen uit het originele model worden daarbij omgezet naar gehele getallen (integers) van 8-bit, zelfs 6-bit of 4-bit. Dit bespaart geheugen en versnelt de berekeningen, ten koste van een relatief klein kwaliteitsverlies.

Lokaal een LLM hosten kan met tools zoals LM Studio. Die geven je de mogelijkheid om verschillende modellen te downloaden in GGUF formaat. Een apart tabblad in de applicatie laat toe om een HTTP Inference server rond een gedownload en ingeladen model op te starten, die de API van OpenAI simuleert. Eens deze opgezet is, bijvoorbeeld op poort 1234, is het model aanspreekbaar via een call naar http://localhost:1234/v1/chat/completions .

Dit instellen in de Continue plugin gebeurt door de LLM toe te voegen aan het bestand .continue/config.json , volgens deze instructies en volgens de richtlijnen voor LM Studio als model provider. Daarbij kan je de titel en het model aanpassen naar eigen goeddunken, en hoef je enkel nog de lijn "apiBase":"http://127.0.0.1:1234/v1" toe te voegen. In de plugin zal je dit dan als nieuwe keuzemogelijkheid zien verschijnen, en kan je ermee aan de slag.

Intermezzo: over hardware

Het beheer van GPU’s is al geen pretje voor 1 developer aan 1 machine. Incompatibiliteitsproblemen tussen verschillende versies van allerlei software libraries en GPU-drivers kunnen dagen duren om op te lossen. Het marktaanbod van GPUs voor datacenters, gedomineerd door nVIDIA in een monopoliepositie, is onnoemelijk duur. Daarbij komt nog de kost van het opbouwen van de heel gespecialiseerde kennis die nodig is om die systemen draaiende te houden. Eender wat je kiest van hardware is over 4 jaar waarschijnlijk al helemaal verouderd. Er wordt hard gewerkt aan nieuwe hardware, specifiek gemaakt om het soort berekeningen van AI-modellen te versnellen – Google kwam eerder al met de TPU, maar andere fabrikanten zetten nu ook hard in op NPUs (Neural Processing Units), en sommigen durven directe concurrentie aan met nVIDIA.

Als je geen tijd hebt om te knoeien met GPU-drivers en niet de ambitie hebt om zelf modellen te trainen, dan is de mogelijkheid om ze te gebruiken op een gewone CPU meer dan welkom. Uiteraard ben je dan wel beperkt tot die LLMs of AI-modellen waarvan de grootte dat ook toelaat. Typische LLMs voor “thuisgebruik” hebben 3, 7 of 13 miljard parameters; grotere modellen worden agressief gekwantiseerd om schijfruimte en geheugen te besparen. Ze gaan vandaag nog niet kunnen tippen aan de kwaliteit van GPT-4, maar er bestaan gelukkig leaderboards om te helpen een keuze te maken – voor open LLMs in het algemeen, specifiek met (doorvoer)snelheidsbenchmarks, of voor code-genererende LLMs in het bijzonder.

Hoe groter de LLMs, hoe kwaliteitsvoller het resultaat (meestal), maar ook hoe meer geheugen en rekenkracht vereist is. Een LLM moet liefst volledig in het geheugen ingeladen kunnen worden, dus 16GB RAM is geen luxe – meer is beter, zeker als je een IDE op dezelfde machine wil draaien. Om een antwoord te kunnen te geven, moet het volledige model vaak meermaals doorlopen worden. De bottleneck wordt bijgevolg vaak gevormd door de bandbreedte tussen CPU en RAM. CPUs met een grote interne cache lijken een streepje voor te hebben (zie ook AI-specifieke benchmarks [1,2] van Anandtech). Bij de keuze van de rest van de hardware moet geheugenbandbreedte zeker meespelen. Ook wie een GPU zou willen kiezen, kijkt misschien liever naar die bandbreedte dan naar het aantal cores. Tot slot is het in gevirtualiseerde omgevingen (een VM, een VPS) belangrijk dat de virtuele CPU dezelfde geavanceerde instructiesets, zoals AVX-512, ondersteunt.

Een LLM op je server

Als je elders een krachtigere machine hebt, kan het de moeite waard zijn om de LLM daarop te draaien. ollama is waarschijnlijk de populairste tool om zonder veel poespas modellen te hosten op Mac of Linux, sinds kort ook Windows. LocalAI is echter een zeker zo interessante optie uit de lijst van mogelijke LLM providers voor Continue, want het biedt Docker containers aan, met of zonder GPU ondersteuning. Op een Linux machine die is uitgerust met Docker, is een oneliner in de terminal voldoende om het open-source CodeLlama model te downloaden en te beginnen hosten op poort 1234:

docker run -ti -p 1234:8080 localai/localai:v2.7.0-ffmpeg-core codellama-7b-gguf 

De opstart ervan duurt echter even, want het model wordt in de container gedownload. Interessanter is het om zelf een reeks modellen in een lokale map te bewaren, en daaromheen een API te zetten middels een LocalAI container. Ook voor die aanpak zijn relatief eenvoudige instructies beschikbaar. We kunnen ze bijvoorbeeld toepassen op de DeepSeek LLM van 6.7 miljard parameters, gekwantiseerd op 4 bits. Deze kan rechtstreeks van Huggingface gedownload worden naar de lokale map ./models-gguf met een wget commando van het type:

wget https://huggingface.co/TheBloke/deepseek-coder-6.7B-instruct-GGUF/resolve/main/deepseek-coder-6.7b-instruct.Q4_K_M.gguf -O ./models-gguf/deepseek-6.7b-instruct-Q4

Een API starten rondom de modellen in die map op poort 8001 (je kan ook meerdere modellen in dezelfde map zetten en ze tegelijk hosten), kan dan met het volgende commando. Voeg eventueel -d toe om het in de achtergrond te laten lopen, en voel je vrij om met de parameters context-size en threads te experimenteren in functie van hoe krachtig je server is:

docker run -p 8001:8080 -v $PWD/models-gguf:/models -ti --rm quay.io/go-skynet/local-ai:v2.7.0-ffmpeg-core --models-path /models --context-size 1600 --threads 16

Voorbeeld

We kunnen nu verschillende LLMs voor code met elkaar vergelijken. We houden het hier louter anekdotisch, en nemen als eenvoudig voorbeeld het schrijven van een bash shellscript. We vertrekken van het volgende probleem: een backup-routine heeft jarenlang een nachtelijke backup genomen van een systeem. Om schijfruimte vrij te maken, willen we alle backups verwijderen die niet verschillen van de vorige. We geven de volgende opdracht, waarbij we de taak zo nauwgezet mogelijk omschrijven voor het beste resultaat: “Write a bash script that, given a directory, iterates over all its files in order of date of creation. For each file, if the filesize is equal to the filesize of the previous file, the file has to be deleted.”

De .continue/config.json file van onze Continue plugin bevat de volgende lijst modellen: eentje op de eigen laptop in LM Studio ingeladen op poort 1234, en twee op een aparte server in het lokaal netwerk, door LocalAI gehost op poort 8001.

    {
      "title": "myLaptop-LMStudio",
      "model": "whatever is loaded in LMstudio",
      "apiBase": "http://127.0.0.1:1234/v1",
      "completionOptions": {},
      "provider": "lmstudio"
    },       
    {
      "title": "localAI-mistral",
      "model": "mistral-7b-code16kqlora-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",      
      "completionOptions": {},
      "provider": "openai"
    },
    {
      "title": "localAI-deepseek",
      "model": "deepseek-6.7b-instruct-Q4",
      "apiBase": "https://192.168.0.100:8001/v1",
      "apiKey": "",
      "completionOptions": {},
      "provider": "openai"
    },

Als referentie nemen we ChatGPT, die komt met de volgende (correcte) oplossing. Bovendien wordt ze ook gevolgd door een uitgebreide uitleg over wat de verschillende onderdelen betekenen (hier niet weergegeven):

#!/bin/bash

# Directory containing the files
DIR="/path/to/your/directory"

# Variable to hold the size of the previous file. Initialized to 0.
prev_size=0

# List all files in the directory, sorted by creation date
# Note: '%T@' sorts by creation time, '%p' prints the file's name
# 'sort -n' ensures the list is sorted numerically
# Note that creation time sorting may depend on filesystem and OS support
files=$(find "$DIR" -type f -printf "%T@ %p\n" | sort -n | cut -d ' ' -f 2-)

# Iterate over the sorted list of files
for file in $files; do
  # Get current file size
  current_size=$(stat -c %s "$file")
  
  # Check if current file size is equal to the previous file's size
  if [ "$current_size" -eq "$prev_size" ]; then
    # Sizes are equal, delete the current file
    echo "Deleting file: $file"
    rm "$file"
  fi
  
  # Update previous size to current file's size
  prev_size=$current_size
done

In LMStudio laden we het model “CodeNinja 1.0 openchat 7B Q4_K_M” in. Voor het genereren van het antwoord op dezelfde vraag is ruim 1 minuut nodig: 20 seconden wachten tot de eerste letter van het antwoord verschijnt, daarna nog ongeveer 2 seconden per lijn. (Onze laptop is natuurlijk niet superkrachtig: een Core i7-10610U CPU met 32GB RAM). Het volgende komt eruit:

#!/bin/bash

for f in $(ls -t -l --time-style=full /path/to/directory)
do
  if [[ $f == "total"* ]]; then
        continue;
    fi
    filename=$(basename "${f% *}")

    # Checks whether the file is already deleted. If not, compares it with the previous file:
    prev_file=""
    while IFS= read -r line; do
        if [[ $line == $filename ]]; then
            prev_file=$line
            break;
        fi
    done <<<"$(ls -l /path/to/directory | tail -n 2)"

    if [[ -z $prev_file || "$f" = "${prev_file}" ]]; then
        # If the file is deleted, nothing to do. If not, deletes it:
        if [[ -z $prev_file ]] || [[ "$(stat -c %s ${filename})" == "$(stat -c %s ${prev_file})" ]]; then
            rm /path/to/directory/$filename
        fi
    fi
done

Het DeepSeek model van 6.7 miljard parameters laden we in LocalAI op een Debian VM in Proxmox. Aan de VM is ruim voldoende RAM toegekend, en 12 cores van de onderliggende hardware, een AMD Threadripper 3960X processor (24 cores maar geen AVX-512 ondersteuning). Hiermee creëren we aan een snelheid van ongeveer 3 lijnen per seconde het volgende resultaat:

#!/bin/bash

# Check if directory is provided
if [ $# -ne 1 ]; then
  echo "Usage: $0 directory"
    exit 1
fi

# Check if directory exists
if [ ! -d "$1" ]; then
    echo "Directory $1 does not exist"
    exit 1
fi

# Change to the directory
cd "$1"

# Get the list of files in order of creation date
files=$(ls -t)

# Initialize previous_size to 0
previous_size=0

# Iterate over the files
for file in $files; do
    # Get the size of the file
    size=$(stat -c%s "$file")

    # If the size is equal to the previous size, delete the file
    if [ $size -eq $previous_size ]; then
        rm "$file"
        echo "Deleted $file"
    fi

    # Update previous_size
    previous_size=$size
done

Tot slot kunnen we op dezelfde VM ook het recentere Mistral uitproberen, waarvoor we op goed geluk de versie mistral-7B-code-16K-qlora uitkiezen die door een andere gebruiker lichtjes werd bijgetraind voor code. Deze blijkt zeer snel te kunnen antwoorden, en genereert in ongeveer 2 seconden het volgende compacte resultaat (helaas zonder documentatie, en gebruikmakend van het complexe awk commando):

for file in $(find directory -type f -exec du -sh {} + | sort -h | awk '{print NR ":\t" $1}'); do
    size=$(du -sh "$file" | awk '{print $1}')
    if [[ $size == $previous_size ]]; then
      rm "$file"
    fi
    previous_size=$size
done

Ik laat de diepgaandere vergelijking van deze resultaten graag over als oefening aan de lezer. Als we hieruit nog een laatste les moeten leren, dan is het dat er ook tussen modellen onderling, zelfs al hebben ze dezelfde hoeveelheid parameters en zijn ze voor hetzelfde doel getraind, erg grote verschillen kunnen zijn qua output en stijl!

Conclusie

Aan sneltempo vinden allerlei AI-powered features hun weg naar de IDE. De laatste release notes van Visual Studio Code vermelden naast verschillende CoPilot features bijvoorbeeld ook ondersteuning voor spraakherkenning in meerdere talen. Het is onvermijdelijk dat je daar als developer mee in contact zal komen. Developers die werken met gevoelige data of copyrighted code, zijn terecht argwanend over het feit dat zulke tools hun IDE-inhoud naar een of andere clouddienst van een derde partij versturen, om suggesties te kunnen genereren.

Vooral dankzij het llama.cpp project, is er recent een alternatieve open-source route ontstaan die toelaat zulke coding assistentie met LLMs zelf op te zetten en uit te baten. Kleinere modellen die op consumentenhardware kunnen draaien, leveren momenteel niet dezelfde kwaliteit en snelheid als Github CoPilot of ChatGPT. De komende jaren zullen we echter regelmatig verdere verbeteringen zien verschijnen, dus de ingezette weg oogt alleszins veelbelovend.

______________________

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

Cet article a été traduit du néerlandais. Les liens peuvent pointer vers des sources en néerlandais.

Le 30 novembre 2022, ChatGPT a été révélé au monde entier. Le chatbot polyvalent, qui peut traiter de presque tous les sujets, a immédiatement conquis un large public. Les générateurs d’images, tels que DALL-E et Stable Diffusion, sont venus s’ajouter à cela et, aujourd’hui, la situation est claire : L’IA générative a de beaux jours devant elle. Nous avons nous-mêmes commencé à l’utiliser immédiatement, et nous avons écrit un article sur nos premières découvertes 10 jours après le lancement.

1 an plus tard, l’impact de ChatGPT peut être qualifié de transformateur. L’écosystème autour de l’IA générative est en plein essor. Ce qui relevait du domaine des rêveries irréalistes il y a 3 ans est soudain devenu réalisable et est en production aujourd’hui. D’innombrables start-ups voient le jour : le compteur du site web There’s an AI for that a depuis dépassé les 10 000, le mois de mars 2023 comptant à lui seul 1209 nouvelles entreprises d’IA. À titre de comparaison, pour l’ensemble de l’année 2021, il n’y a que 288 start-ups dans la même base de données.

L’impact et la célérité avec lesquels tout évolue suscitent également de la nervosité. L’enseignement, par exemple, doit s’adapter dans la précipitation à une nouvelle réalité. L’étudiant moyen a désormais facilement accès à une technologie qui lui permet de rédiger une dissertation entière en quelques secondes – et lorsque South Park y consacre un épisode, on sait que le phénomène prospère. Plus proche de nous, de nombreuses universités ont publié des lignes directrices ou des conseils sur son utilisation (par ex. Louvain, Gand, Anvers). Celles-ci sont bien pensées et pourraient bien inspirer des lignes directrices similaires dans les entreprises et les gouvernements.

L’on observe également de nombreuses expérimentations dans des contextes professionnels. “Aucune idée, mais demande à ChatGPT” est devenu une déclaration typique lorsqu’il y a un besoin de nouveaux inputs. Un sondage réalisé par Nature a fait ressortir qu’un grand nombre de scientifiques avaient déjà exploré la technologie dans un cadre professionnel. Dans le monde universitaire, l’on se demande si le fait de soumettre d’épais dossiers de subvention a un sens, si la rédaction de ceux-ci est automatisable. Nul doute que des observations similaires émergent également dans d’autres secteurs.

Petite rétrospective

OpenAI mène toujours la danse, et son propre blog donne un bon aperçu des développements de l’année écoulée. Une timeline avec quelques moments clés :

• 17 janvier 2023 : Microsoft lance le service Azure OpenAI, rendant les technologies OpenAI disponibles sur Azure,
• 1 février 2023 : Le service d’abonnement ChatGPT Plus offre un accès prioritaire à ChatGPT (hautement sursollicité) pour 20 $/mois,
• 1 mars 2023 : ChatGPT devient disponible via API,
• 14 mars 2023 : Lancement de GPT-4 pour les utilisateurs de ChatGPT Plus,
• 23 mars 2023 : Lancement des premiers plugins,
• 13 juin 2023 : Une version mise à jour de ChatGPT peut configurer et exécuter des appels vers des fonctions externes,
• 20 juillet 2023 : Avec “custom instructions“, ChatGPT peut être configuré pour toujours prendre en compte certains éléments,
• 22 août 2023 : L’API Finetuning permet d’affiner l’output de ChatGPT,
• 28 août 2023 : Lancement de ChatGPT Enterprise,
• 25 septembre 2023 : Les utilisateurs peuvent utiliser la voix et les images dans les conversations,
• 19 octobre 2023 : ChatGPT peut générer des images avec DALL-E 3,
• 6 novembre 2023 : Introduction des GPT qui permettent aux amateurs de construire un ChatGPT personnalisé  qui fouille des documents spécifiques, et des Assistants API destinée aux programmeurs pour réaliser une action similaire.

Ce dernier pas n’est pas reçu par tous avec enthousiasme : de nombreuses start-ups dans l’écosystème de l’IA générative viennent de construire le cœur de leur activité autour du concept de Retrieval-Augmented Generation (RAG), et OpenAI leur fait directement concurrence avec ses GPT personnalisés. (De mauvaises langues prétendent que cela aurait joué un rôle dans le conflit du CEO deux semaines plus tard, mais ces rumeurs n’ont pas encore été prouvées).

Retrieval-Augmented Generation (RAG), avec langchain comme bibliothèque la plus populaire pour les développeurs, est devenu au cours de l’année écoulée le moyen de faire en sorte que les Large Language Models s’accrochent à des informations spécifiques, internes ou récentes. L’idée découle du fait que, pendant ce temps, le prompt – c’est-à-dire la commande que l’on donne au modèle de langue – peut être si long qu’il y a de la place pour ajouter des pages entières d’informations supplémentaires. En enrichissant le prompt avec, par exemple, les résultats d’une recherche ou les dernières nouvelles, un chatbot peut encore formuler des réponses basées sur des informations récentes ou du contenu provenant de bases de données spécifiques, sans que le modèle de langue sous-jacent n’ait besoin d’être entraîné sur ces bases.

Microsoft s’est empressé de concrétiser cette idée. Avec Bing Chat, elle a lancé une nouvelle interface de recherche conversationnelle, qui utilise les résultats de Bing Search pour ses réponses. L’avantage est que cette interface peut afficher de manière transparente les citations de sources ou les références. Cependant, il convient de garder à l’esprit que cela ne garantit pas l’exactitude des réponses : les résultats de la recherche peuvent toujours ne pas être pertinents, et les résumés incorrects ou incomplets. Entre-temps, le produit fut un succès, et Microsoft a décidé de mettre le paquet : entre-temps, Bing Chat a été rebaptisé Microsoft CoPilot, a été intégré au navigateur Edge, et est également disponible dans Windows 11 et Microsoft 365 (anciennement Office). Pour pouvoir exploiter cette fonctionnalité, il faut donner l’autorisation dans l’application de partager des documents ouverts ou des contenus de pages web avec le service CoPilot.

Microsoft fait également figure de précurseur en matière d’images : Le Bing Image Creator offre un accès gratuit au générateur DALL-E 3 (pour l’instant), et ses résultats sont intégrés de manière transparente dans le nouveau Microsoft Designer.

Google a eu moins de succès avec son équivalent Bard. Le lancement a mal tourné lorsque Bard a répondu par un fait erroné (une hallucination), ce qui a fait chuter le cours de l’action de Google. Par rapport à OpenAI et Microsoft, Google semble moins préoccupé par l’intégration et l’expérience utilisateur, et se concentre plutôt sur le fond théorique et l’approfondissement des possibilités technologiques.

Meta, bien sûr, ne veut pas être en reste et joue la carte du logiciel quasi open-source avec ses propres modèles de langue Llama, en mettant l’accent sur le terme “quasi”. La société semble se concentrer principalement sur les développeurs individuels, pour lesquels Meta souhaite faciliter la réutilisation ou le réentraînement de leurs modèles de langue, comme l’a fait Stanford avec sa variante Alpaca, entre autres. La société vise également le déploiement sur du matériel standard, grâce à la bibliothèque llama.cpp, qui permet de quantifier un modèle : arrondir intelligemment les paramètres d’un modèle entraîné pour réduire l’empreinte mémoire, au prix d’une perte de précision faible mais acceptable. Une quantification de 32 bits à 8 bits fait qu’un modèle de 13 milliards de paramètres nécessite non pas 52 Go mais seulement 13 Go de mémoire vive. Il s’intègre donc parfaitement dans la mémoire des cartes graphiques actuelles dotées de 16 ou 24 Go de vRAM. Des outils intuitifs permettant d’héberger des modèles quantifiés sur votre propre ordinateur sont GPT4All , MLC, ollama ou LMStudio.

Plusieurs entreprises plus petites sont également dans la course, développant leurs propres modèles de langue qui pourraient servir de backend pour des services de type ChatGPT ou des applications RAG. Il convient de mentionner Anthropic, créée par d’anciens employés d’OpenAI, qui met particulièrement l’accent sur la transparence et la sécurité avec ses modèles Claude. De son côté, l’européenne Mistral a démarré sur les chapeaux de roues. Avec d’anciens employés de Meta à sa tête, elle exploite un modèle véritablement open-source et est donc principalement en concurrence avec Meta. Pour la zone linguistique néerlandaise, des projets sont en cours pour développer, par l’intermédiaire de l’organisation de recherche TNO, un GPT-NL indépendant qui devrait également constituer une alternative aux grands acteurs américains, en mettant l’accent sur le respect des lois européennes.

Petite prospective

Bon nombre d’entreprises doivent encore s’atteler à l’adaptation de leurs propres modèles d’entreprise à l’essor de l’IA. Nous n’en sommes toutefois qu’aux premiers stades d’une période de forte croissance pour l’IA, et il est difficile de prévoir ce que les prochaines années nous réservent. Rester à l’affût des évolutions est une première étape. The Batch de DeepLearning.AI est une newsletter excellente qui suit l’évolution de la situation et qui fournit chaque semaine un résumé concis des événements clés de l’industrie. Ceux qui cherchent à élargir et à approfondir leurs connaissances trouveront également une solide offre de cours sur le même site web, comme celui-ci : Generative AI for Everyone. Microsoft propose un cours Generative AI for Beginners (IA générative pour les débutants) destiné aux développeurs. Le site finlandais Elements Of AI propose l’un des cours gratuits les plus accessibles au grand public, et il en existe bien d’autres.

Aujourd’hui déjà, les chefs d’entreprise et les dirigeants sont confrontés à tous ces nouveaux développements dans les entreprises ou dans l’administration, et veulent formuler une réponse – ou au moins élaborer un code de conduite. Le moniteur de gestion du Knowledge Centre Data and Society rassemble des exemples nationaux et internationaux qui peuvent servir d’inspiration à ceux qui ne veulent pas réinventer l’eau chaude. Le AI Standards Hub du Royaume-Uni rassemble des publications pertinentes sur les normes industrielles liées à l’IA. À un niveau international plus abstrait, l’OCDE, entre autres, exerce un monitoring actif. L’évolution rapide du terrain ne facilite certainement pas le travail législatif. Au niveau européen, le IA Act annoncé est reporté. Cela n’a pas empêché Stanford d’évaluer déjà les principaux acteurs existants sur la base du projet de texte qui nous est soumis.

En attendant, rien n’empêche une entreprise ou un gouvernement de se lancer et d’expérimenter la technologie. Toutefois, il est crucial de rester prudent et de ne pas pas perdre le sens commun. ChatGPT n’est pas une solution miracle. Aucun mécanisme de sécurité ne peut garantir qu’un modèle de langue n’aura pas d’hallucinations ou ne présentera pas des textes complètement inventés comme des faits. Bien que les datasets d’entraînement de nombreux modèles de langue soient secrets, nous savons qu’ils sont si volumineux qu’il est impossible d’y effectuer une sélection et un filtrage précis. Les LLM sont aujourd’hui des boîtes noires ; il est impossible de retracer l’origine d’un choix de mots particulier dans une réponse. Il est donc impossible, en toute logique, de créer des applications critiques aveuglément sur la base de ces systèmes. De toute évidence, ce serait une mauvaise idée de faire traiter des données médicales, sans aucune supervision, par un modèle de langue partiellement formé sur des textes piochés au hasard sur le net par des théoriciens du complot, des antivax, des influenceurs d’Instagram, des homéopathes et d’autres charlatans.

En parlant de charlatans, on voit régulièrement apparaître des prophètes de malheur qui, pour attirer l’attention, font des déclarations de plus en plus grotesques, allant jusqu’à prédire l’extinction de I’Humanité. (L’inverse existe aussi : ceux qui croient que l’utopie est proche). La disproportion de ces déclarations témoigne d’un manque de connaissances et d’un manque de contact avec la réalité. Après tout, malgré tous les progrès réalisés, nous sommes encore bien loin des robots capables de repasser vos vêtements. Des affirmations farfelues détournent la discussion des problèmes qui se posent aujourd’hui dans le monde réel : les abus tels que les “deepfakes“, l’élargissement de la fracture numérique, le manque de possibilités de contester les décisions automatiques, l’utilisation de données sans autorisation ni mention de la source, … autant de questions qui requièrent une attention soutenue et pour lesquelles l’Europe joue un rôle actif de pionnier. Ces éléments ne doivent pas être des facteurs bloquants, puisque même en gardant la tête sur les épaules, ce ne sont pas les opportunités qui manquent.

Dans un récent éditorial, Bill Gates a été acclamé pour sa vision de l’évolution dans un avenir proche. Selon cette vision, les chatbots évolueront en “agents“, c’est-à-dire qu’ils disposeront d’une autonomie (limitée) pour prendre des mesures, éventuellement supervisées. Là où les co-Pilots font encore partie d’une application, ceux-ci deviendront également plus génériques, avec l’intention que les futurs agents puissent fonctionner à travers les applications, comme les assistants personnels. En effet, il reste encore beaucoup de travail à accomplir pour y parvenir : des protocoles qui permettent aux applications de mieux communiquer entre elles, des moyens d’échanger des données en toute sécurité tout en préservant la vie privée, …

Enfin, la dépendance à l’égard de modèles énormes et non transparents (GPT-3, GPT-4) avec un service en cloud externe reste une pilule difficile à avaler lorsque des données internes ou sensibles sont susceptibles d’être traitées. Il est impossible de prévoir quelles données un utilisateur typique pourrait communiquer à un chatbot, et avec les plugins de type CoPilot, il est souvent difficile de retrouver les données que le plugin lit et transmet en arrière-plan. Toutefois, le RGPD impose des exigences strictes et concrètes. Tout le monde ne considère pas qu’une promesse ou même un accord contractuel stipulant que les données reçues ne seront pas stockées ou réutilisées soit suffisant pour avoir soudainement une confiance aveugle.

L’alternative logique consiste à déployer localement des modèles plus petits. Cependant, la qualité de leur output est par conséquent plus faible, ce qui est décevant si les attentes élevées créées par ChatGPT sont le point de référence. Les modèles plus petits ne disposent pas du multilinguisme fluide de ChatGPT et travaillent avec des prompts beaucoup plus compacts, ce qui complique l’élaboration d’applications RAG. Une recherche diligente et multidirectionnelle est en cours pour combler cette lacune. On voit des innovations permettant d’affiner (spécialiser) des modèles plus petits pour une tâche spécifique, de façon efficace et avec moins de données. Le concept de distillation – compression d’un modèle – semble également prometteur. Il semble également préférable de s’entraîner sur peu de données correctes mais de qualité, plutôt que sur un grand nombre de données désordonnées et potentiellement erronées. En outre, pour toute application, il reste à trouver les bons équilibres en termes de choix de modèle, l’ingénierie du prompt, le réglage fin et le RAG.

Le terrain de jeu est bel et bien ouvert, l’innovation ne manque pas, et nous pouvons certainement nous attendre à de nouvelles améliorations dans un avenir proche. Une année des plus intéressantes nous attend sans aucun doute !

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

Op 30 november 2022 werd ChatGPT op de wereld losgelaten. De algemene chatbot die kan meepraten over vrijwel alles, brak onmiddellijk door bij een breed publiek. Generatoren voor afbeeldingen, zoals DALL-E en Stable Diffusion, deden daar nog een hele schep bovenop en ondertussen is het wel duidelijk: Generative AI is here to stay. Zelf gingen we er ook direct mee aan de slag, en schreven 10 dagen na de lancering al een artikel over onze eerste bevindingen .

1 jaar later mag de impact van ChatGPT gerust transformatief genoemd worden. Het ecosysteem rond generatieve AI boomt. Wat 3 jaar geleden nog tot het domein van de onrealistische dromen behoorde, werd plots haalbaar en staat vandaag in productie. Talloze start-ups zien het licht: de teller op de website There’s an AI for that is ondertussen de 10.000 gepasseerd, met maart 2023 alleen al goed voor 1209 nieuwe AI-bedrijfjes. Ter vergelijking, voor het volledige jaar 2021 staan er maar 288 start-ups in diezelfde database.

De impact en de snelheid waarmee alles evolueert zorgt ook voor zenuwachtigheid. Zo moet het onderwijs zich in zeven haasten aanpassen aan een nieuwe realiteit. De gemiddelde scholier heeft nu vlot toegang tot technologie die binnen enkele seconden een heel essay kan schrijven – en als South Park er een episode aan wijdt, weet je dat het leeft. Dichter bij huis hebben veel universiteiten ondertussen richtlijnen of adviezen opgesteld over het gebruik ervan (vb. Leuven, Gent, Antwerpen). Die zijn goed doordacht en mogen gerust inspiratiebron zijn voor gelijkaardige richtlijnen bij bedrijven en overheden.

Ook in professionele contexten wordt volop geëxperimenteerd. “Geen idee, maar vraag het eens aan chatGPT” is een typische uitspraak geworden als er nood is aan frisse nieuwe input. Een rondvraag van Nature toonde dat nogal wat wetenschappers de technologie al verkend hebben voor hun werkgerelateerde verplichtingen. In academia wordt luidop de vraag gesteld of het indienen van vuistdikke subsidiedossiers überhaupt nog veel zin heeft, als het schrijven ervan voor automatisering vatbaar is. Gelijkaardige bemerkingen worden ongetwijfeld ook in andere sectoren gemaakt.

Een terugblik

OpenAI blijft de dans leiden, en hun eigen blog geeft een goed beeld van de ontwikkelingen van het afgelopen jaar. Een tijdslijn met enkele sleutelmomenten:

• 17 januari 2023: Microsoft lanceert de Azure OpenAI service, waarmee de OpenAI technologieën beschikbaar worden op Azure,
• 1 februari 2023: Abonnementsdienst ChatGPT Plus biedt voor $20/maand prioritaire toegang tot het (sterk overbevraagde) ChatGPT,
• 1 maart 2023: ChatGPT wordt beschikbaar via API,
• 14 maart 2023: Lancering van GPT-4 voor ChatGPT Plus gebruikers,
• 23 maart 2023: De eerste plugins worden gelanceerd,
• 13 juni 2023: Een updated ChatGPT kan calls naar externe functies opstellen én uitvoeren,
• 20 juli 2023: Met “custom instructions” kan ChatGPT geconfigureerd worden om met bepaalde dingen altijd rekening te houden,
• 22 augustus 2023: Met de Finetuning API kan ChatGPT output worden verfijnd,
• 28 augustus 2023: Lancering van ChatGPT Enterprise,
• 25 september 2023: Gebruikers kunnen spraak en afbeeldingen gebruiken in de conversatie,
• 19 oktober 2023: ChatGPT kan afbeeldingen genereren met DALL-E 3,
• 6 november 2023: Introductie van GPTs waarmee je als leek een custom ChatGPT kan samenstellen die specifieke documenten doorzoekt, en de Assistants API om iets gelijkaardigs te doen als programmeur.

Die laatste zet wordt niet unaniem op gejuich onthaald: veel start-ups in het ecosysteem van generatieve AI hebben net de kern van hun hele business gebouwd rond het concept van Retrieval-Augmented Generation (RAG), en OpenAI gaat daar met hun custom GPTs direct mee in concurrentie. (Kwatongen beweren dat dit meegespeeld zou hebben in de CEO-soap van twee weken later, maar die geruchten zijn vooralsnog niet bewezen).

Retrieval-Augmented Generation (RAG), met langchain als populairste library voor developers, is het afgelopen jaar uitgegroeid tot dé manier om Large Language Models te laten inhaken op specifieke, interne of recente informatie. Het idee volgt uit het feit dat de prompt – dit is de opdracht die men geeft aan het taalmodel – ondertussen zodanig lang mag zijn dat er ruimte is om hele bladzijden aan bijkomende informatie toe te voegen. Door de prompt te verrijken met, bijvoorbeeld, de resultaten van een zoekopdracht of de laatste nieuwsberichten, kan een chatbot toch antwoorden formuleren op basis van recente informatie of inhoud van specifieke databases, zonder dat het achterliggende taalmodel daarop getraind hoeft te zijn.

Microsoft was er als de kippen bij om dat om te zetten in de praktijk. Met Bing Chat lanceerden ze een nieuwe conversationele zoekinterface, die voor haar antwoorden de resultaten van Bing Search gebruikt. Het voordeel is dat er transparant bronvermeldingen of referenties bij getoond kunnen worden. We moeten wel alert blijven dat dat nog steeds geen correctheid garandeert: zoekresultaten kunnen nog steeds irrelevant zijn, en samenvattingen foutief of onvolledig. Het product was wel een schot in de roos en Microsoft gaat nu all-in: ondertussen heeft Bing Chat een rebranding ondergaan naar Microsoft CoPilot, is het geïntegreerd in de Edge browser, en is het ook in Windows 11 en Microsoft 365 (het vroegere Office) beschikbaar geworden. Om deze functionaliteit te kunnen benutten, moet in de app de toelating worden gegeven om geopende documenten of webpagina-inhoud te mogen delen met de CoPilot service.

Ook op het vlak van afbeeldingen loopt Microsoft in het koppeloton: De Bing Image Creator biedt (voorlopig) vrije toegang tot de DALL-E 3 generator, en de resultaten ervan worden naadloos geïntegreerd in het nieuwe Microsoft Designer.

Google heeft minder succes met zijn eigen concurrerende Bard. Bij de introductie liep het grondig mis toen Bard met een onjuist feit (een hallucinatie) antwoordde, en de beurskoers van Google klappen kreeg. In vergelijking met OpenAI en Microsoft, lijkt Google minder bezig te zijn met integratie en gebruikerservaring, en eerder haar focus te leggen op de theoretische achtergrond en uitdieping van de technologische mogelijkheden.

Meta wil natuurlijk niet achterblijven en trekt met haar eigen Llama taalmodellen de quasi-open-source-kaart, met nadruk op quasi. Hun focus lijkt vooral te liggen op de individuele developers, voor wie ze het gemakkelijk willen maken om hun taalmodellen te hergebruiken of hertrainen, wat o.a. Stanford deed met haar Alpaca variant. Ze mikken ook op inzetbaarheid op doorsnee hardware, via de succesvolle library llama.cpp, waarmee een model gequantizeerd kan worden: het slim afronden van de parameters van een getraind model voor een kleinere geheugenvoetafdruk, ten koste van een klein maar aanvaardbaar verlies aan precisie. Een quantizatie van 32 bits naar 8 bits, maakt dat een model van 13 miljard parameters geen 52GB maar slechts 13GB RAM vereist. Zo past het volledig in het geheugen van hedendaagse grafische kaarten met 16GB of 24GB vRAM. Gebruiksvriendelijke tools om gequantizeerde modellen op je eigen computer te hosten, zijn GPT4All , MLC, ollama of LMStudio.

Verschillende kleinere bedrijven zitten ook nog in de race en ontwikkelen hun eigen taalmodellen die als backend voor chatGPT-achtige diensten of RAG-toepassingen kunnen dienen. Vermeldenswaardig zijn Anthropic, van ex-OpenAI werknemers, dat vooral de nadruk wil leggen op transparantie en veiligheid, met haar Claude-modellen. Daarnaast kende het Europese Mistral een vliegende start. Met ex-Meta werknemers aan het roer, hanteert het een écht open source model en het gaat zo vooral concurrentie aan met Meta. Voor het Nederlands taalgebied zijn er plannen om, via de onderzoeksorganisatie TNO, een onafhankelijk GPT-NL te ontwikkelen dat ook een alternatief moet vormen voor de grote Amerikaanse spelers, en waarbij de focus moet liggen op het respecteren van de Europese wetten.

Een vooruitblik

Veel bedrijven moeten nog beginnen aan de oefening om hun eigen businessmodellen aan de opkomst van AI aan te passen. We zitten echter nog volop in de beginfase van een sterke groeiperiode voor (generatieve) AI, en het is moeilijk te voorzien wat de volgende jaren zullen brengen. Op de hoogte blijven van de evoluties is een eerste stap. Een uitstekende nieuwsbrief die de vinger aan de pols houdt, is The Batch van DeepLearning.AI, die elke week een bondige samenvatting maakt van de belangrijkste gebeurtenissen in de sector. Wie de kennis wil verbreden en verdiepen, vindt op dezelfde website ook een degelijk cursusaanbod, zoals deze: Generative AI for Everyone . Microsoft heeft een cursus Generative AI for Beginners uitgewerkt die gericht is op developers. Het Finse Elements Of AI heeft een van de meest toegankelijke gratis cursussen voor een algemeen publiek, en er zijn er nog vele andere.

Bedrijfsleiders en beleidsmakers worden vandaag al geconfronteerd met al deze nieuwe ontwikkelingen op de werkvloer of in de administratie, en willen hierop een antwoord formuleren – of toch minstens een gedragscode ontwikkelen. De beleidsmonitor van het Kenniscentrum Data en Maatschappij verzamelt voorbeelden in binnen- en buitenland die als inspiratie kunnen dienen, voor wie het warm water niet opnieuw wil uitvinden. Het Britse AI Standards Hub verzamelt relevante publicaties over industriestandaarden met betrekking tot AI. Op een abstracter internationaal niveau is o.a. de OESO actief bezig met monitoring. Het zich snel veranderende landschap maakt het wetgevend werk zeker niet gemakkelijker. Op Europees niveau loopt de verwachte AI act alleszins vertraging op. Dit weerhield Stanford er niet van om de bestaande grote spelers al eens te evalueren op basis van de ontwerptekst die nu voorligt.

Ondertussen houdt niets een bedrijf of overheid tegen om al aan de slag te gaan en te experimenteren met de technologie. Het blijft daarbij wel belangrijk om niet te hard van stapel te lopen en het gezond verstand niet overboord te gooien. ChatGPT is geen mirakeloplossing. Geen enkele hoeveelheid veiligheidsmechanismes kan garanderen dat een taalmodel niet zou hallucineren of compleet verzonnen tekstjes zou presenteren als feiten. Van veel taalmodellen zijn de trainingsdatasets geheim, maar we weten wel dat ze zo groot zijn dat er onmogelijk een nauwkeurige selectie en filtering op gebeurd kan zijn. LLMs zijn vandaag black boxes; de oorsprong van een bepaalde woordkeuze in een antwoord is niet te achterhalen. Dit alles maakt ze logischerwijs ongeschikt om er klakkeloos kritische toepassingen op te bouwen. Het is evident dat het een slecht idee zou zijn om, zonder enige supervisie, medische gegevens te laten verwerken door een taalmodel dat deels getraind is op willekeurig van het net geplukte teksten van samenzweringstheoretici, antivaxers, instagram-influencers, homeopaten en andere kwakzalvers.

Over kwakzalverij gesproken, met de regelmaat van de klok duiken nu ook doemdenkers op, die in een opbod voor aandacht, met steeds groteskere uitspraken op de proppen komen, tot aan het voorspellen van het uitsterven van de mens toe. (Het omgekeerde bestaat ook: mensen die geloven dat utopia nabij is.) De disproportionaliteit van zulke uitspraken alleen al, getuigt van weinig kennis van zaken én weinig voeling met de realiteit. Alle vooruitgang ten spijt, zijn we immers nog mijlenver verwijderd van het punt dat een robot zelfs maar uw kleren kan strijken. Clowneske claims leiden de discussie wel af van de problemen die vandaag in de echte wereld opduiken: misbruik zoals deepfakes, vergroting van de digitale kloof, een gebrek aan mogelijkheden om automatische beslissingen aan te vechten, het gebruik van data zonder toelating of bronvermelding, etc. Allemaal zaken waar de nodige aandacht naartoe moet blijven gaan, en waar Europa een actieve voortrekkersrol speelt. Dat hoeven geen blokkerende factoren te zijn, want ook met beide voetjes op de grond is er geen gebrek aan opportuniteiten.

In een recent opiniestuk oogstte Bill Gates veel bijklank voor zijn visie op de evolutie in de nabije toekomst. Die is dat chatbots verder evolueren naar “agents“, d.w.z. dat ze ook een (beperkte) autonomie krijgen om actie te ondernemen, eventueel gesuperviseerd. Waar Co-Pilots nog onderdeel zijn van een applicatie, zou ook dat generieker worden, met de bedoeling dat toekomstige agents over applicaties heen kunnen werken, zoals personal assistants. Inderdaad is er nog heel wat werk te verzetten voor het zover is: protocollen die apps toelaten beter met elkaar te communiceren, manieren om veilig data uit te wisselen terwijl de privacy wordt gevrijwaard, …

Tot slot blijft de afhankelijkheid van enorme en niet-transparante modellen (GPT-3, GPT-4) bij een externe clouddienst, een moeilijke pil om te slikken wanneer er interne of gevoelige gegevens verwerkt zouden kunnen worden. Het is onvoorspelbaar welke gegevens een doorsnee gebruiker zou kunnen meedelen aan een chatbot, en bij CoPilot-achtige plugins is het vaak moeilijk terug te vinden welke gegevens de plugin meeleest en achter de schermen doorstuurt. De GDPR stelt echter wel strenge en concrete eisen. Beloftes in gebruikersvoorwaarden of zelfs contractuele afspraken dat ontvangen data niet zal worden opgeslagen of hergebruikt, zijn niet voor iedereen voldoende om plots blind vertrouwen te hebben.

Het voor de hand liggende alternatief is het lokaal deployen van kleinere modellen. De kwaliteit van de output daarvan is echter navenant lager, en dat stelt teleur als hoge verwachtingen gecreëerd door chatGPT het referentiepunt zijn. Kleinere modellen missen de vlotte meertaligheid van ChatGPT, en werken nog met veel compactere prompts, wat de uitbouw van RAG-apps ermee limiteert. Er wordt ijverig en in verschillende richtingen gezocht naar manieren om die kloof te dichten. Zo wordt er verder geïnnoveerd in manieren om kleinere modellen efficiënter te finetunen (specialiseren) voor een specifieke taak. Ook het concept van distilleren – het comprimeren van een model – oogt veelbelovend. Er zijn indicaties dat betere resultaten behaald kunnen worden door te trainen op weinig maar kwalitatieve en correcte data, in plaats van op veel rommelige en mogelijke foutieve data. Verder blijft het voor elke applicatie, zoeken naar goede balansen qua modelkeuze, prompt engineering, finetuning, en RAG.

Het speelveld ligt dus nog helemaal open en er is er volop ruimte voor innovatie. We mogen zeker nog verdere verbeteringen verwachten op korte termijn. Er komt ongetwijfeld opnieuw een razend interessant jaar aan!

______________________

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

Cet article a été traduit du néerlandais. Les liens peuvent pointer vers des sources en néerlandais.

Dans un article précédent, nous avons discuté de manière générale du potentiel de l’IA générative dans le Software Development Lifecycle. Examinons maintenant la question du point de vue du développeur : quel est l’état d’avancement de la génération de code et que devons-nous encore prendre en compte ? Pour faire court : les assistants IA ou les plugins pour IDE sont une aubaine pour ceux qui savent en faire bon usage, mais comme tous les systèmes d’IA, ils présentent aussi des inconvénients.

Avant-propos

Une partie de cette hype en termes d’IA générative est propulsée par des modèles de langages puissants – les grands modèles de langue ou LLM. Depuis la sortie du GPT-3 en 2020, ces modèles parviennent à écrire des textes normaux d’une certaine longueur. De là, il n’y a qu’un pas vers les langages de programmation. En effet, ils ont aussi une syntaxe et une sémantique.

Dans la pratique, il existe de nombreuses variantes de modèles de langue, chacun ayant ses forces et ses faiblesses, en fonction des choix faits par les créateurs pour les entraîner, et en fonction des données d’entraînement qui les sous-tendent. Testez vous-même certains des modèles open source existants sur votre propre ordinateur via l’outil GPT4All (voir également notre quick review de cet outil).

Le code informatique consiste en une collection de fichiers texte. Rien n’empêche un modèle de langue d’essayer de prédire les différents tokens (= unités grammaticales) qui composent le code, plutôt que des mots. Cependant, contrairement au texte brut, le code a beaucoup moins de tolérance à l’erreur : la moindre faute d’orthographe ou la plus petite variation peut invalider un morceau de code ou lui faire exécuter quelque chose de complètement différent.

Pourtant, aujourd’hui, les plus grands modèles de langue, tels que GPT-3.5 et les versions ultérieures, peuvent produire d’eux-mêmes des morceaux de code informatique tout à fait corrects en réponse à une requête. Cette fonctionnalité est due à la quantité massive de textes sur lesquels ils sont formés, notamment de nombreux tutoriels, articles de blog, questions et réponses provenant de forums de développeurs populaires tels que StackOverflow, et code documenté provenant de repositories de code publics tels que Github.

Canards en plastique bavards

Depuis Socrate, le dialogue est un moyen efficace de parvenir à de nouvelles perspectives. Ce n’est pas pour rien que le rubber ducking est une méthode de correction de bugs qui revient dans tous les cours de génie logiciel. Il existe entre-temps plusieurs plugins qui mettent à disposition une interface de chat alimentée par l’IA dans l’IDE même (par exemple ceux pour VS Code, beaucoup d’autres peuvent être trouvés via les marketplaces pour VS Code ou IntelliJ IDEA). Si ces plugins utilisent un service cloud externe, il vous suffit d’entrer votre propre clé API.

Un cadre de dialogue avec une dynamique de questions-réponses peut être bien utilisé pour générer des morceaux de code relativement autonomes, sans trop de dépendances externes. En général, pour obtenir le meilleur résultat, il faut pouvoir énoncer facilement toutes les conditions préalables et les hypothèses nécessaires dans le dialogue lui-même, de manière à ce qu’il s’inscrive dans la fenêtre contextuelle du modèle de langue. Les use cases comprennent entre autres :

• La génération from scratch d’une version initiale du code ou d’un fichier de configuration
• La génération de fonctions ou de procédures relativement courtes à partir d’une description
• La génération de code snippets autonomes : requêtes SQL, expressions régulières…
• Demande de modification d’un morceau de code ou d’un fichier de configuration
• Correction de bugs : recherche d’erreurs dans un code qui ne fonctionne pas, poser des questions sur une erreur
• Faire expliquer ce qu’un morceau de code fait

Les plus grands modèles de langue disposent de fenêtres contextuelles de plusieurs milliers de mots dans lesquelles il est possible d’insérer toutes les informations nécessaires. Un modèle de langue open source plus petit, installé localement sur du matériel moins puissant, sera sans aucun doute moins performant. Voici quelques exemples de conversations avec GPT-4 d’OpenAI, qui montrent qu’il est possible d’aller très loin avec quelques questions bien ciblées (cliquez sur l’image pour obtenir la pleine résolution) :

Complétion de code sous stéroïdes

Au cours du développement, un développeur travaille sur de nombreux fichiers dans un IDE. À des endroits aléatoires de ces fichiers, le code doit être modifié, supprimé ou écrit. L’édition de code existant de cette manière n’a pas grand-chose à voir avec le dialogue ; en fait, nous préférerions utiliser l’auto-complétion avancée dans ce cas. Les modèles de langue peuvent également faire l’affaire, mais les modèles les plus appropriés sont plutôt ceux formés aux tâches de “remplir au milieu” – et qui peuvent donc prendre en compte le code présent avant et après l’endroit que l’on édite.

Après la sortie de GPT-3, OpenAI a travaillé avec Microsoft (qui possède Github) pour créer un modèle de langue spécialisé, formé exactement pour ce use case. Cette variante a été nommée Codex, et le premier outil à l’utiliser a été Github CoPilot. Depuis, nous en sommes à plusieurs versions, mais les plugins pour VSCode et IntelliJ fonctionnent toujours de la même manière : via un raccourci clavier dans l’éditeur, on peut utiliser CoPilot pour récupérer diverses suggestions, générées par Codex, qui pourraient correspondre à l’endroit où se trouve le curseur.

D’après notre expérience actuelle, le contexte pris en compte est généralement limité au contenu (partiel) du fichier édité. Cela implique évidemment le téléchargement vers le modèle de langue – veillez donc à respecter les directives en matière de confidentialité lorsque vous utilisez un service externe. Pour l’instant, nous semblons obtenir de meilleurs résultats dans les projets de programmation composés de quelques gros fichiers, tels que les pages web avec JavaScript en ligne, ou Jupyter Notebooks en Python, où il y a souvent un gros fichier à parcourir qui contient à la fois la documentation, le code et l’output. En revanche, dans les projets comportant de nombreux petits fichiers, il semble plus difficile de générer de bonnes suggestions, et il est plus important de disposer d’une documentation supplémentaire dans le fichier édité afin que le modèle de langue puisse puiser dans suffisamment d’informations contextuelles.

L’une des alternatives les plus intéressantes au modèle commercial Github CoPilot est StarCoder, un modèle open source issu de l’initiative BigCode HuggingFace et ServiceNow. Bien que la performance soit moindre que CoPilot, ils font la différence dans de nombreux autres domaines qui peuvent être des obstacles dans des contextes commerciaux ou publics :

• Entraînés sur un dataset public : The Stack. Bien qu’il ait été collecté par scraping, il ne contient que du code avec des licences logicielles permissives, et les développeurs peuvent, s’ils le souhaitent, toujours faire retirer leur code du dataset.
• Comprend un outil de vérification de plagiat, qui permet de vérifier que les suggestions générées n’ont pas été copiées mot pour mot à partir des données d’apprentissage (éventuellement protégées par des droits d’auteur).
• Pourvu d’un filtre d’informations sensibles, qui détecte les adresses électroniques, les clés API et les adresses IP (pas exact à 100 %).
• Contient des instructions pour installer localement, ainsi qu’un plugin VSCode. Un plugin IntelliJ a entre-temps également été développé par un tiers.
• Le modèle standard a une taille de 15 milliards de paramètres et nécessite au moins 60 GB de RAM ou autant de mémoire GPU (en fonction de l’utilisation ou non d’un GPU) pour être utilisé. Il existe également de plus petits modèles à 7, 3 ou 1 milliard de paramètres, ainsi que des versions quantisées utilisant des types de données à 4 bits, sans grande perte de précision.

Plusieurs autres systèmes ont vu le jour cet été et ont obtenu de bons résultats dans de nombreux benchmarks : WizardLM et sa variante spécifique WizardCoder, qui est désormais considéré comme le nec plus ultra de l’open source, et PanGu-Coder, avec lequel Huawei s’est également lancé dans le monde des assistants IA pour le code. 

Au cœur de l’action

Le StarCoder paper offre un bel aperçu du fonctionnement d’un modèle de langue pour le code.
Ce n’est certainement pas comme si vous pouviez “brancher” votre propre codebase pour obtenir des suggestions adaptées. Si vous voulez vraiment affiner le modèle (et vous ne ferez cet énorme effort que si vous n’y arrivez pas avec des modifications astucieuses du prompt), il y a beaucoup de choses à faire, du prétraitement des données d’entraînement au post-traitement de l’output brut du modèle de langue. Ne vous attendez pas non plus à ce que le réglage fin soit trop élevé : StarCoder l’a fait pour Python, mais n’a obtenu que quelques points de pourcentage d’amélioration par rapport au modèle global qui pourrait traiter tous les langages de programmation. Le peaufinage est difficile et il n’y a aucune garantie de succès ; il y a même un risque d’overfitting, ce qui pourrait dégrader les résultats.

L’étape la plus importante est probablement la collecte et le nettoyage des données. Ces données sont constituées de code, mais tous les codes ne sont pas inclus : vous devez également être autorisé à utiliser le code (licences) et, de préférence, l’avoir aussi correct que possible et écrit dans le langage de programmation que vous souhaitez soutenir. Le code est également collecté à partir des issue trackers et du commit history. En outre, un filtrage additionnel peut être effectué pour supprimer les (quasi-)doublons, et des pondérations peuvent être attribuées ici et là pour maintenir l’équilibre : un peu moins de poids pour le code “boilerplate”, et/ou un peu plus pour les repositories très populaires qui sont susceptibles d’être de meilleure qualité. Le code source peut contenir des informations sensibles qui doivent être rendues anonymes ou supprimées au préalable, pour éviter qu’elles ne soient divulguées ou suggérées (adresses IP, mots de passe, identifiants, adresses électroniques, coordonnées…). Tout cela, bien sûr, de préférence aussi automatiquement que possible.

Le code source se compose non seulement de code, mais aussi de descriptions, de commentaires et d’autres informations. Dans une étape de formatage, le code est donc enrichi par l’ajout de métadonnées et de tokens supplémentaires qui rendent explicites certaines structures implicites. Cela peut avoir des conséquences : si tout ce prétraitement a été effectué sur l’ensemble des données d’apprentissage, le modèle résultant ne fonctionnera correctement sur de nouvelles données que s’il a subi le même prétraitement. Ainsi, les plugins éditeur qui souhaitent utiliser un tel modèle peuvent, pour obtenir un bon résultat, devoir d’abord effectuer un prétraitement similaire sur le code qu’ils souhaitent envoyer au modèle de langue.

Exactitude et autres benchmarks

Comme c’est le cas pour les LLM, il ne peut y avoir de garantie concluante de l’exactitude ou de l’exhaustivité de ce qu’un tel plugin présente, tant sur le plan syntaxique que sur le plan sémantique. Cette précision est évidemment importante : un morceau de code généré ne doit pas seulement être syntaxiquement correct et compiler sans faille, mais aussi être sémantiquement significatif et s’exécuter correctement. La métrique “pass@x” est devenue une mesure importante à cet égard. Elle exprime en pourcentage si un modèle de langue pour une mission donnée peut passer avec succès les tests correspondants après X tentatives. “pass@1” est le pourcentage pour lequel le modèle de langue utilisé pour la première fois a pu générer la bonne réponse, “pass@10” est le pourcentage pour lequel au moins 1 tentative sur 10 a été correcte.

Dans le monde de l’IA générative, il existe un besoin général de pouvoir comparer les nouveaux modèles, qui apparaissent désormais presque quotidiennement, avec le meilleur de la technologie. Il n’y a donc pas de pénurie de benchmarks, et de nouveaux modèles plus importants apparaissent régulièrement. Des résumés utiles sont les “leaderboards”, qui montrent en temps réel quels modèles représentent l’état actuel de la technique selon une série de benchmarks. L’étape peut changer chaque semaine. Voici quelques leaderboards généraux intéressants :

• Papers with Code : l’état de l’art dans diverses tâches d’intelligence artificielle, avec des documents d’accompagnement.
• Stanford HELM : analyse comparative d’un large éventail de tâches en se focalisant sur le “human reasoning” (raisonnement humain).
• LMsys.org FastChat : se concentre sur les capacités chatbot.
• HuggingFace OpenLLM leaderboard.
• LLM-Leaderboard.

En ce qui concerne le code, il existe des benchmarks qui fonctionnent plus ou moins comme un concours de programmation. L’idée est de confier un ensemble de tâches au modèle de langue, d’évaluer les résultats automatiquement et de mesurer le “pass@1” et, si possible, d’autres paramètres. Souvent, il s’agit de “remplir la fonction” : à partir d’une description de l’input, de l’output et d’un function header, le contenu de la fonction doit être généré. L’inconvénient est que ce type de problème n’est parfois pas très représentatif de celui auquel est confronté le développeur lambda. Parmi les initiatives intéressantes, on peut citer :

• HuggingFace Big Code Models leaderboard (uniquement LLM publics).
• Microsoft CodeXGLUE : évaluation de diverses sous-tâches selon des méthodes connues de Natural Language Processing. Ce leaderboard semble dépendre de contributions volontaires et est quelque peu incomplet.
• Papers with Code a des sections séparées pour la génération de code, la création de documents, la synthèse de programmes entiers et la correction de bugs.
• Le HumanEval dataset et MBPP dataset : problèmes de programmation typique (Python).
• Le DS-1000 dataset : ensemble de problèmes de data processing / data science concrets.
• HumanEval-X ou MultiPL-E : versions multilingues de HumanEval, mesurant les performances dans plusieurs langages de programmation.

Bien entendu, le fait qu’un morceau de code généré survive aux tests ne signifie pas qu’il s’agit d’un code sécurisé ou qu’il respecte les “best practices”. Entre-temps, il existe de nombreux exemples connus de code généré qui s’avère sensible aux “buffer overflows”, à l’injection SQL et à d’autres risques classiques. Le benchmark de sécurité “Asleep at the Keyboard” consiste en 89 scénarios de génération de code basés sur la liste MITRE top-25 vulnerability. Starcoder paper montre que même les meilleurs modèles génèrent encore du code non sécurisé dans 40 % de ces scénarios. En outre, il ne semble guère y avoir de différence entre les meilleurs modèles et les autres – le choix d’un meilleur modèle semble garantir des résultats syntaxiquement plus corrects, mais pas encore un code plus sûr. Il est donc possible que nous devions nous pencher sur les données d’apprentissage elles-mêmes, où le code non sécurisé devrait être encore mieux filtré. Quoi qu’il en soit, il convient de rappeler que l’utilisation de code généré dans un projet doit impérativement s’accompagner d’une solide politique de test et d’acceptation.

Performance

En ce qui concerne plus particulièrement les exigences computationnelles, le leaderboard Huggingface OpenLLM-perf et les benchmarks sur le site web TextSynth Server constituent des sources intéressantes. Ce dernier montre quelques chiffres de performance utiles pour ceux qui envisagent un hébergement par leurs propres moyens. Ceux qui n’ont pas de GPU peuvent compter sur une vitesse de 12 tokens par seconde avec le modèle LLaMa2 de 13 milliards de paramètres, avec un processeur de serveur EPYC 7313 relativement haut de gamme. Dans un code informatique, un token ne représente parfois qu’un seul caractère, de sorte qu’à cette vitesse, il faut parfois attendre une dizaine de secondes pour obtenir une suggestion de complétion de code. La dernière carte graphique RTX-4090 peut le faire 7 fois plus vite, mais pas encore au point de l’exprimer en millisecondes.

Les besoins en mémoire sont proportionnels au nombre de paramètres d’un modèle, et la vitesse de génération inversement proportionnelle. À titre d’approximation, on peut supposer qu’un modèle comportant 13 milliards de paramètres doit également effectuer 13 milliards de calculs pour chaque token de sortie, même s’il ne comporte qu’un seul caractère. En outre, si chaque paramètre est un nombre de 32 bits, il faut au moins 52 Go de stockage et autant de mémoire (V)RAM. Une “quantization“, arrondissant les paramètres à 8 bits ou même à 4 bits, peut réduire proportionnellement ce besoin en mémoire.

GPT4All permet de l’essayer sur votre propre matériel. Cela donne une idée de l’énorme puissance de calcul qu’OpenAI, Microsoft Azure ou Amazon AWS déploient pour que leurs modèles, dont beaucoup sont encore plus grands que les LLM disponibles en libre accès, fonctionnent aussi vite qu’ils le proposent. On parle d’investissements de milliards de dollars en matériel informatique, si importants qu’ils déstabiliseraient le marché mondial.

Même les solutions open source sont loin d’être légères, en dépit des grandes initiatives d’optimisation. On peut en tout cas supposer que le déploiement local n’est possible que sur du matériel récent et puissant. Actuellement, on ne peut pas s’attendre à ce qu’une installation locale sur un ordinateur portable de bureau moyen offre une expérience fluide à l’utilisateur.

Productivité

Internet regorge de contes de fées sur le développeur 10x, et les gourous de l’IA générative aimeraient vous faire croire que cette technologie peut élever n’importe quel programmeur à ce niveau. La réalité est plus nuancée. Les développeurs ne passent pas 100 % de leur temps à écrire du code, pas plus que les médecins ne passent 100 % de leur temps à rédiger des ordonnances. La majorité des développeurs passe moins d’une heure par jour à coder. Le reste de leur temps est consacré à l’analyse, à la lecture, à l’apprentissage, aux tâches de maintenance, à la communication, etc. Jusqu’à présent, cette réflexion et cette consultation avec les collègues ne sont pas comprimées par l’emploi de LLM.

Il est difficile de trouver des chiffres précis sur la productivité parce qu’elle est difficile à définir et donc à mesurer. Une première estimation utile provient de Google même, qui a examiné le temps d’itération (de la connaissance du problème à la solution). Avec une première version de son propre assistant de complétion de code par l’IA, l’entreprise a pu constater un gain de temps de 6 %. Github affirme que le codage pur peut être environ 55 % plus rapide avec son CoPilot – bien qu’il précise dans le même temps que l’intervalle de confiance à 95 % de sa mesure est de [21 %-89 %]. En outre, l’adoption d’un outil n’apporte aucune valeur ajoutée si elle n’est pas accompagnée d’un parcours pour apprendre à l’utiliser de manière optimale (tout comme aujourd’hui encore, de nombreux employés de bureau perdent du temps avec Office en raison d’une connaissance ou d’une expérience insuffisante de tous les types de références, de formules et de raccourcis).

Le code généré fournit une solution initiale rapide, mais cette solution doit encore être comprise par le programmeur. Un score “pass@1” de 50 % signifie que la moitié des bouts de code générés nécessitent encore des ajustements manuels avant de passer les tests unitaires – sans parler de l’optimalité ou de la sécurité. Le code généré peut être complexe et utiliser des constructions qui dépassent le niveau de connaissance du programmeur. Le code généré est donc plus difficile à maintenir et à corriger que le code écrit manuellement. Un code généré qui n’a pas été correctement examiné et testé ajoute une dette technique considérable à un projet.

L’utilisation de plugins qui vont jusqu’à générer des blocs entiers de code et de documentation en un claquement de doigts (ou un peu plus lentement) n’est une bonne idée que si plusieurs autres aspects du processus d’ingénierie logicielle sont en ordre : des normes élevées doivent être maintenues dans tous les domaines en termes de stratégie de test, de code reviews, de documentation de code et de savoir-faire des développeurs.

Confidentialité

Les entreprises et les gouvernements ont rarement le luxe d’utiliser n’importe quel modèle de langue. Il existe non seulement des barrières contractuelles, mais aussi des questions de confidentialité, en particulier lors de l’utilisation du cloud. Après tout, on n’obtient une bonne suggestion de modèle de langue qu’en introduisant suffisamment d’informations au préalable. Ne pas tout mettre en place en interne implique inévitablement de donner à un tiers l’accès à vos données.

Le degré d’ouverture et de licence peut varier considérablement – à un extrême, tout est en “boîte noire” et uniquement accessible via le cloud/API (c’est là que vous trouverez OpenAI, Anthropic, Cohere et la plupart des autres start-ups établies). Celles-ci promettent dans les versions Enterprise parfois plus de garanties – mais vous n’avez pas d’autre choix que de les croire sur parole. À l’autre extrême, tout est en “open access” (libre accès) et sous licence permissive. Entre les deux, une entreprise peut également construire un modèle de langue en libre accès sur un dataset fermé. Au moins un de ces datasets a depuis été divulgué comme contenant des ebooks illégalement copiés et protégés par le droit d’auteur, ce qui constituera sans aucun doute un argument de poids dans le recours collectif intenté contre Meta sur ce sujet. Les ensembles de données des Code LLM Salesforce CodeGen et Tsinghua CodeGeeX ne sont pas non plus publics.

Transparence, licences, options de déploiement, prix, taille et scalabilité… l’importance relative de toutes ces caractéristiques dictera les outils que vous pourrez utiliser. Ceux qui souhaitent une transparence maximale seront souvent limités aux LLM en Open Access. Certaines licences ouvertes limitent en outre l’utilisation à des fins non commerciales. La nécessité d’accéder à des données de formation ou la facilité d’héberger soi-même une instance sur site limitent davantage les choix.

Conclusion

Les outils basés sur le dialogue (chatGPT et autres) peuvent vous être utiles en tant que développeur pour, entre autres, les tâches suivantes :

• Initialiser un projet/fichier/classe/configuration : créer une première version de quelque chose
• Correction de bugs et modification sous forme de questions-réponses
• Morceaux de code relativement indépendants

Les outils qui complètent le code ou remplissent le code manquant (type Github Co-Pilot) sont utiles, entre autres, pour :

• Compléter du code à partir d’exemples déjà réalisés
• Documenter le code
• Apporter des modifications au milieu d’un fichier plus volumineux

Pour un développeur, l’environnement de développement optimal est quelque chose de tout à fait personnel et chacun aura sa propre préférence. À notre avis, ces deux façons d’obtenir des suggestions de code sont quelque peu complémentaires, et une combinaison intelligente des deux peut permettre d’obtenir les meilleurs gains de productivité. Dans le même temps, nous tenons à dire qu’une gestion de projet saine, avec une attention portée à la qualité du code, aux tests, aux révisions, à la documentation, etc. est indispensable.

Le monde de l’IA est en pleine effervescence. De nouveaux modèles d’IA pouvant servir de base aux plugins IDE sont ajoutés avec une grande régularité. Pour les industries où la confidentialité du code est importante, les variantes open source sont très intéressantes. Même si les benchmarks montrent qu’ils sont encore moins performants aujourd’hui que les dernières initiatives commerciales basées sur le cloud, nous pouvons nous attendre à ce que de meilleures versions apparaissent à l’avenir. De nombreux efforts sont déjà déployés pour créer des modèles pouvant fonctionner sur du matériel grand public (certes haut de gamme).

P.S.

Quelques heures après la publication de cet article, HuggingFace annonce la venue de SafeCoder : une solution d’entreprise pour les assistants de codage basés sur LLM qui peut être déployée sur site. Huggingface fournit le tout dans des conteneurs qui peuvent être installés dans un data center propre et fournir des endpoints privés, ainsi que des plugins compatibles avec les principaux IDE. D’autres frameworks de déploiement général existent depuis un certain temps, notamment Seldon, BentoML et KServe, qui peuvent également héberger des LLM, TextSynth Server et GPT4All peuvent fonctionner comme des endpoints d’API. Cependant, vous avez toujours besoin de plugins pour les utiliser dans l’IDE lui-même, et pour effectuer les traitements préalables et postérieurs nécessaires – et s’ils ne sont pas fournis, vous devez en créer un vous-même ou modifier un plugin existant.

P.P.S.

Ces derniers mots à peine écrits, Meta a lancé CodeLLama, une variante de LLaMa 2 spécifiquement entraînée pour le code. Les médias sociaux suggèrent qu’il est possible de faire tourner la version originale avec 34 milliards de paramètres sur un ordinateur équipé de 4 GPU RTX3090 avec 24 GB de VRAM chacun, générant environ 20 tokens par seconde. Il est sans doute plus facile d’essayer la version de chat en ligne. Les versions quantisées suivront sans doute très prochainement, et nous attendons les premiers benchmarks sur les différents leaderboards.

______________________

Cette contribution a été soumise par Joachim Ganseman, consultant IT chez Smals Research. Elle a été rédigée en son nom propre et ne prend pas position au nom de Smals.

In een vorig artikel bespraken we op algemene wijze het potentieel van generatieve AI in de software development lifecycle. Laat ons nu eens kijken vanuit het standpunt van de developer: wat is de stand van zaken wat betreft het genereren van code, en waar moeten we nog rekening mee houden? Lang verhaal kort: AI-assistenten of -plugins voor IDEs zijn een zegen voor wie ze goed kan aanwenden, maar komen, zoals alle AI-systemen, ook met de nodige caveats.

Vooraf

De hype qua generatieve AI wordt onder andere gestuwd door krachtige taalmodellen – Large Language Models of LLMs. Zeker sinds GPT-3 uitkwam in 2020, slagen die erin om normaal uitziende teksten te schrijven van enige lengte. Van daar is het maar een korte sprong naar programmeertalen – die hebben immers ook een syntax en semantiek.

In de praktijk bestaan er talloze varianten van taalmodellen, die elk hun sterktes en zwaktes hebben, al naargelang de keuzes die de makers hebben gemaakt bij het trainen ervan, en al naargelang de trainingsdata die eraan ten grondslag liggen. Probeer bijvoorbeeld zelf enkele van de bestaande open source modellen uit op je eigen computer via de tool GPT4All (zie ook onze korte review van deze tool).

Computercode bestaat uit een collectie van tekstbestanden. Niets verhindert dat een taalmodel, in plaats van woorden, de verschillende tokens ( = grammaticale eenheden) waaruit code bestaat, probeert te voorspellen. In tegenstelling tot gewone tekst is er bij code echter veel minder ruimte voor fouten: de kleinste spelfout of variatie kan een stuk code ongeldig maken of iets helemaal anders laten uitvoeren.

Toch kunnen de allergrootste taalmodellen, zoals GPT-3.5 en later, vandaag uit eigen beweging vrij correcte stukken computercode produceren in een antwoord op een vraag. Deze functionaliteit is het gevolg van de massieve hoeveelheid tekst waarop ze getraind zijn, waaronder talloze tutorials, blogartikels, vragen en antwoorden uit populaire developerfora zoals StackOverflow, en gedocumenteerde code uit publieke code repositories zoals Github.

Babbelende badeentjes

Al sinds Socrates is de dialoog een beproefde manier om tot nieuwe inzichten te komen. Niet voor niets is rubber ducking een methode voor debugging die ter sprake komt in elke cursus software engineering. Er bestaan ondertussen verschillende plugins die een AI-powered chat-interface in de IDE zelf beschikbaar stellen (bvb deze voor VS Code , vele andere kunnen gevonden worden via de marketplaces voor VS Code of IntelliJ IDEA). Als die gebruikmaken van een externe cloud-dienst moet je daarbij enkel nog je eigen API-key ingeven.

Een dialogerende setting met een vraag-antwoord dynamiek kan goed aangewend worden voor het genereren van relatief op zichzelf staande stukken code, zonder te veel externe afhankelijkheden. In het algemeen kan je stellen dat je, voor het beste resultaat, alle noodzakelijke randvoorwaarden en aannames gemakkelijk in de dialoog zelf moet kunnen vermelden, zodat het binnen het context-venster van het taalmodel past. De use cases omvatten onder andere:

• From scratch genereren van een eerste versie van code of een configuratiebestand
• Genereren van relatief korte functies of procedures aan de hand van een beschrijving
• Genereren van op zichzelf staande code snippets: SQL queries, reguliere expressies, …
• Vragen om een aanpassing aan een stuk code of een configuratiebestand
• Debugging: fouten zoeken in niet-werkende code, vragen stellen over een error
• Laten uitleggen wat een stuk code doet

De grootste taalmodellen hebben ondertussen contextvensters van duizenden woorden waarin je alle nodige informatie kwijt kan. Een kleiner open-source taalmodel, lokaal geïnstalleerd op minder krachtige hardware, zal ongetwijfeld minder goed presteren. Enkele voorbeelden van conversaties met OpenAI’s GPT-4 staat hieronder – hieruit blijkt dat je al heel ver kan geraken met een paar welgemikte vragen (klik voor de volledige resolutie):

Code completion on steroids

Tijdens het ontwikkelen werkt een developer aan talloze bestanden in een IDE. Op willekeurige plekken in die bestanden moet er code aangepast, verwijderd of geschreven worden. Het bewerken van bestaande code op deze manier heeft weinig te maken met dialogeren, eigenlijk willen we hier eerder een geavanceerde auto-complete inzetten. Ook dat kunnen taalmodellen goed, maar de meest geschikte modellen zijn eerder diegene die getraind zijn op “fill in the middle” taken – en die dus rekening kunnen houden met de aanwezige code voor én na de plek die men aan het bewerken is.

Na het uitbrengen van GPT-3, werkte OpenAI samen met Microsoft (dat Github bezit) aan een gespecialiseerd taalmodel dat voor exact deze use case werd getraind. Deze variant werd Codex genoemd, en de eerste tool die ervan gebruikmaakte was Github CoPilot. Ondertussen zijn we al enkele versies verder, maar de plugins voor VSCode en IntelliJ werken nog op dezelfde manier: via een sneltoets in de editor kan men via CoPilot verschillende suggesties opvragen, gegenereerd door Codex, die zouden kunnen passen op de plek van de cursor.

Voor zover onze ervaring vandaag reikt, is de context die daarbij in rekening wordt genomen vandaag meestal beperkt tot (stukken van) de inhoud van het bewerkte bestand. Daarbij wordt uiteraard code geüploaded naar het taalmodel – let dus zeker op richtlijnen qua confidentialiteit bij gebruik van een externe dienst. Vooralsnog lijken we betere resultaten te krijgen bij programmeerprojecten die bestaan uit weinig grote bestanden, zoals webpagina’s met inline JavaScript, of Jupyter Notebooks in Python, waarbij vaak sprake is van 1 groot bestand dat doorlopen wordt waarin zowel de documentatie, de code als de output staat. In projecten met vele kleine bestandjes daarentegen, lijkt het moeilijker om goede suggesties te genereren, en is het belangrijker dat er extra documentatie aanwezig is in het geëditeerde bestand zodat er voldoende contextuele informatie is die het taalmodel kan aangrijpen.

Een van de interessantere alternatieven voor het commerciële Github CoPilot is StarCoder, een open source model van het BigCode initiatief van HuggingFace en ServiceNow. De performantie is weliswaar minder dan CoPilot, maar zij maken op vele andere vlakken, die mogelijk dealbreakers zijn in commerciële of publieke context, het verschil:

• Getraind op een open dataset: The Stack. Deze is weliswaar via scraping verzameld, maar bevat alleen code met permissieve softwarelicenties, en developers kunnen desgewenst alsnog hun code eruit laten verwijderen.
• Bevat een plagiaat-check tool, waarmee je kan controleren of de gegenereerde suggesties niet verbatim uit de (mogelijk copyrighted) trainingsdata zijn overgenomen.
• Voorzien van filter van gevoelige informatie, die emailadressen, API keys en IP adressen detecteert (niet 100% accuraat).
• Voorzien van instructies om het lokaal te installeren, evenals een VSCode plugin. Een IntelliJ plugin werd ondertussen ook ontwikkeld door een derde partij.
• Het standaardmodel is 15 miljard parameters groot en vergt minstens 60GB RAM of evenveel GPU memory (afhankelijk van of een GPU benut wordt of niet) om te kunnen gebruiken. Ondertussen bestaan ook kleinere modellen met 7, 3 of 1 miljard parameters, evenals “quantized” versies die gebruikmaken van 4bit datatypes zonder veel accuraatheidsverlies.

Deze zomer zagen nog enkele andere systemen het licht die goed scoren op vele benchmarks: WizardLM en de specifieke variant ervan WizardCoder, dat ondertussen wordt beschouwd als de open source state-of-the-art, en PanGu-Coder, waarmee ook Huawei zich heeft gelanceerd in de wereld van AI-assistants voor code. 

Achter de schermen

De StarCoder paper geeft een goed zicht op de werking van een taalmodel voor code. Het is zeker niet zo dat je je eigen codebase kan “inpluggen” om suggesties te krijgen die daarop zijn toegespitst. Als je echt zou willen finetunen (en die enorme inspanning doe je in principe alleen maar als je er niet raakt met slimme aanpassingen aan de prompt), komt er heel wat bij kijken, van preprocessing van de trainingsdata tot postprocessing van de rauwe output van het taalmodel. Leg de verwachtingen van finetuning ook niet te hoog: StarCoder deed het voor Python, maar haalde hooguit enkele procentpunten verbetering in vergelijking met het algemene model dat met alle programmeertalen overweg kon. Finetunen is moeilijk en er is geen garantie op succes; er bestaat zelfs een risico op overfitting wat tot slechtere resultaten kan leiden.

De belangrijkste stap daarbij is waarschijnlijk het verzamelen en schoonmaken van data. Die data bestaat uit code, maar niet alle code komt in aanmerking: je moet de code ook mogen gebruiken (licenties), en je hebt ze liefst zo correct mogelijk en geschreven in de programmeertaal die je wenst te ondersteunen. Code wordt ook verzameld uit issue trackers en commitgeschiedenis. Daarnaast kan je nog extra filteren om (bijna-)duplicaten te verwijderen, en wil je misschien hier en daar gewichten toekennen om de balans te bewaren: wat minder gewicht voor boilerplate code, en/of wat meer voor erg populaire repositories die waarschijnlijk van hogere kwaliteit zijn. Broncode kan gevoelige informatie bevatten die eerst geanonymiseerd of verwijderd moet worden, om te voorkomen dat die lekt of wordt gesuggereerd (IP adressen, paswoorden, identifiers, emailadressen, contactgegevens, …). Dit alles natuurlijk liefst zo automatisch mogelijk.

Broncode bestaat niet alleen uit code maar ook uit beschrijvingen, commentaren en andere informatie. In een formatteringsstap wordt de code daarom nog verrijkt, door het toevoegen van metadata en bijkomende tokens die bepaalde impliciete structuren expliciet maken. Dit kan implicaties hebben: als al deze preprocessing op de hele trainingsdataset is gebeurd, dan zal het resulterende model pas goed werken op nieuwe data als die dezelfde preprocessing heeft ondergaan. Het is dus mogelijk dat editorplugins die willen gebruikmaken van zo’n model, om een goed resultaat te bekomen, eerst gelijkaardige preprocessing moeten uitvoeren op de code die ze naar het taalmodel willen sturen.

Correctheid en andere benchmarks

Typisch voor LLMs, kan er geen sluitende garantie worden gegeven op de correctheid of volledigheid van wat zo’n plugin je voorschotelt, zowel syntactisch als semantisch. Die correctheid is uiteraard van belang: een stuk gegenereerde code moet niet alleen syntactisch correct zijn en foutloos compileren, maar ook semantisch betekenisvol zijn en goed runnen. De “pass@x” metriek is daarbij uitgegroeid tot belangrijke graadmeter. Ze drukt uit als een percentage, of een taalmodel voor een bepaalde opdracht na X pogingen de bijhorende testen succesvol kan passeren. “pass@1” is het percentage dat het taalmodel van de eerste keer het juiste antwoord heeft kunnen genereren, “pass@10” is het percentage waarbij minstens 1 van 10 pogingen correct was.

Er is een algemene nood in de wereld van generatieve AI om nieuwe modellen, die ondertussen bijna dagelijks verschijnen, te kunnen vergelijken met de state-of-the-art. Aan benchmarks is er dus geen gebrek, en er verschijnen er geregeld ook nieuwe en grotere. Handige samenvattingen zijn de “leaderboards”, die real-time tonen welke modellen de huidige state-of-the-art vertegenwoordigen volgens een waaier aan benchmarks. Het podium kan wekelijks veranderen. Enkele interessante algemene leaderboards zijn:

• Papers with Code: state-of-the-art in verschillende AI taken, voorzien van begeleidende papers
• Stanford HELM: benchmarkt een breed scala aan taken met focus op “human reasoning”
• LMsys.org FastChat: focus op chatbot-vaardigheden
• HuggingFace OpenLLM leaderboard
• LLM-Leaderboard

Specifiek voor code zijn er benchmarks die min of meer werken zoals een programmeerwedstrijd. Het idee is om een set opdrachten te geven aan het taalmodel, de resultaten automatisch te evalueren, en de “pass@1” en zo mogelijk enkele andere metrieken te meten. Vaak neemt dat een “fill in the function”-vorm aan: gegeven een beschrijving van input en output en een functieheader, moet de inhoud van de functie gegenereerd worden. Een nadeel is dat dit soort problemen soms weinig representatief is voor dat waarmee de doorsnee developer wordt geconfronteerd. Interessante initiatieven zijn onder andere:

• HuggingFace Big Code Models leaderboard (enkel open LLMs)
• Microsoft CodeXGLUE: evaluatie van verschillende subtaken volgens methodes bekend uit Natural Language Processing. Hun leaderboard lijkt af te hangen van vrijwillige contributie en enigszins onvolledig.
• Papers with Code heeft aparte secties voor genereren van code , genereren van documentatie, synthese van hele programma’s en bugfixing
• De HumanEval dataset en MBPP dataset: typische programmeerproblemen (Python)
• De DS-1000 dataset: een set van concrete data science / data processing problemen
• HumanEval-X of MultiPL-E: multi-language versies van HumanEval, meet performantie in meerdere programmeertalen

Dat een gegenereerd stuk code de testen overleeft betekent natuurlijk nog niet dat het ook veilige code is of “best practices” volgt. Er zijn ondertussen voorbeelden genoeg bekend van gegenereerde code die vatbaar blijkt te zijn voor buffer overflows, SQL injection, en andere klassieke risico’s. De “Asleep at the Keyboard” security benchmark bestaat uit 89 code generation scenario’s gebaseerd op de MITRE top-25 vulnerability lijst. Uit de Starcoder paper blijkt dat zelfs de beste modellen in 40% van deze scenario’s toch nog onveilige code genereren. Ook lijkt er nauwelijks verschil te merken tussen de beste modellen en de rest – een beter model kiezen lijkt wel te zorgen voor syntactische correctere resultaten, maar vooralsnog niet voor veiliger code. Mogelijk moet daarom eens gekeken worden naar de trainingsdata zelf, waar onveilige code nog beter uitgefilterd zou moeten worden. In ieder geval moeten we op dit moment adviseren: het gebruik van gegenereerde code in een project moet absoluut gepaard gaan met een robuust beleid inzake testing en acceptatie.

Performantie

Specifiek wat betreft computationele vereisten, zijn het Huggingface OpenLLM-perf leaderboard en de benchmarks op de website van TextSynth Server interessante bronnen. Die laatste toont enkele cijfers over performantie, die handig zijn voor wie met het idee speelt om het zelf te gaan hosten. Wie het zonder GPU doet, kan met het LLaMa2 model van 13 miljard parameters rekenen op een snelheid van 12 tokens per seconde, gegeven een relatief high-end EPYC 7313 serverprocessor. Een token in computercode is soms maar 1 karakter, dus aan dat tempo moet je soms een tiental seconden wachten op een code completion suggestie. De recentste RTX-4090 grafische kaart kan het 7x sneller, maar nog steeds niet zo snel dat je het in milliseconden zou uitdrukken.

De geheugenvereisten zijn evenredig met het aantal parameters van een model, en de generatiesnelheid omgekeerd evenredig. Als een grove benadering mag je aannemen dat een model van 13 miljard parameters, ook 13 miljard berekeningen moet maken voor elk output token, zelfs al is het maar 1 karakter lang. Daarnaast vereist het, als elke parameter een 32-bit getal is, minstens 52GB opslagruimte en evenveel (V)RAM-geheugen. Een “quantization“, die de parameters afrondt naar 8-bit of zelfs 4-bit, kan die geheugenvereiste evenredig doen dalen.

GPT4All laat toe het zelf eens te proberen op je eigen hardware. Dit geeft een idee van de enorme rekenkracht die OpenAI , Microsoft Azure, of Amazon AWS inzetten om hun modellen, die veelal nog groter zijn dan de beschikbare Open Access LLMs, zo snel te kunnen doen draaien als zij dat aanbieden. Er wordt gesproken van investeringen van miljarden dollars in hardware, zodanig groot dat ze de wereldwijde markt destabiliseren.

Zelfs open source oplossingen zijn allesbehalve lightweight te noemen, ondanks verregaande initiatieven tot optimalisatie. Je mag er alleszins van uitgaan dat het lokaal deployen alleen maar haalbaar is op recente en krachtige hardware. Een vlotte user experience kan je momenteel nog niet verwachten van een lokale installatie op de doorsnee kantoorlaptop.

Productiviteit

Het internet staat vol sprookjes over de 10x developer, en goeroes van generatieve AI zouden u graag doen geloven dat deze technologie elke programmeur tot dat niveau kan verheffen. De realiteit is hardnekkiger. Developers spenderen om te beginnen geen 100% van hun tijd aan het schrijven van code, net zomin als dokters 100% van hun tijd voorschriften schrijven. Het merendeel van developers spendeert minder dan 1 uur per dag aan het effectief schrijven van code. De rest van de tijd gaat naar analyseren, lezen, leren, onderhoudstaken, communicatie,… Dat denkwerk en het overleg met de collega’s wordt vooralsnog niet gecomprimeerd door LLMs in te zetten.

Het is moeilijk om harde cijfers te vinden over productiviteit omdat het moeilijk te definiëren en dus te meten is. Een nuttige eerste schatting komt van Google zelf, die de iteratietijd (van kennisname van het probleem tot oplossing) onder de loep nam. Met een eerste versie van hun eigen AI code completion assistent, konden zij 6% tijdswinst noteren. Github zelf beweert dat het pure codeerwerk zo’n 55% sneller kan met hun CoPilot – al zeggen ze er in één adem bij dat het 95%-confidence interval van hun meting [21%-89%] is. De adoptie van een tool brengt bovendien geen meerwaarde als ze niet gepaard gaat met een traject om ze optimaal te leren benutten (net zoals vandaag nog vele kantoormedewerkers tijd verliezen met Office door onvoldoende kennis of ervaring met alle types van referenties, formules en snelkoppelingen).

Gegenereerde code biedt wel snel een eerste oplossing, maar die oplossing moet nog steeds begrepen worden door de programmeur. Een “pass@1” score van 50%, betekent dat de helft van de gegenereerde code snippets nog manuele aanpassingen behoeft voordat ze de unit tests passeert – en dan spreken we nog niet over optimaliteit of veiligheid. Gegenereerde code kan complex zijn en gebruikmaken van constructies die boven het kennisniveau van de programmeur liggen. Dat maakt gegenereerde code moeilijker om te onderhouden en te debuggen dan code die manueel geschreven is. Gegenereerde code die onvoldoende werd gereviseerd en getest, voegt aanzienlijke technical debt toe aan een project.

Het gebruik van plug-ins die zo ver gaan dat ze hele blokken code en documentatie met een vingerknip (of iets trager) kunnen genereren, is slechts een goed idee wanneer verschillende andere aspecten van het software engineering proces op orde zijn: er moeten over de hele lijn hoge standaarden aangehouden worden wat betreft teststrategie, code reviews, documenteren van code en kenniscompetenties van de developers.

Vertrouwelijkheid

Bedrijven en overheden hebben zelden de luxe om eender welk taalmodel te benutten. Er zijn niet alleen contractuele drempels, maar ook vragen over confidentialiteit, zeker bij gebruik van de cloud. Een goede suggestie van een taalmodel krijg je immers alleen door eerst voldoende informatie te uploaden. Als je niet alles in-house opzet, impliceert dat onvermijdelijk dat je een derde partij inzage geeft in jouw gegevens.

De mate van openheid en licentiëring kan aanzienlijk verschillen – in het ene uiterste is alles “black box” en enkel via cloud/API toegankelijk (hier vind je OpenAI, Anthropic, Cohere en de meeste andere gevestigde startups). Deze beloven in Enterprise versies soms meer garanties – maar je hebt nog steeds geen andere optie dan ze daarin te geloven op hun woord. In het andere uiterste is alles “open access” en permissief gelicentieerd. Daartussenin kan een bedrijf ook een Open Access taalmodel bouwen op een gesloten dataset. Van minstens 1 zo’n dataset is ondertussen uitgelekt dat ze illegaal gekopieerde auteursrechtelijk beschermde ebooks bevat, wat ongetwijfeld een sterk argument wordt in de class action lawsuit over het thema tegen Meta. De datasets van de code-LLMs Salesforce CodeGen en Tsinghua CodeGeeX zijn evenmin publiek.

Transparantie, licentiëring, deployment mogelijkheden, prijszetting, grootte en schaalbaarheid,… het relatief belang van al deze kenmerken zal dicteren welke tools je kan gebruiken. Wie maximale transparantie wil, zal sowieso vaak beperkt zijn tot Open Access LLMs. Sommige open licenties beperken het gebruik daarnaast tot niet-commerciële doeleinden. Een noodzaak tot inzage in de trainingsdata of gemakkelijke voorzieningen om zelf on-premise een instantie te kunnen hosten, beperkt de keuzemogelijkheden nog verder.

Conclusie

Dialoog-gebaseerde tools (chatGPT en aanverwanten) kan je als developer nuttig inzetten bij o.a.:

• Het initialiseren van een project/bestand/klasse/configuratie: maak een eerste versie van iets
• Het debuggen en aanpassen op vraag-antwoord-wijze
• Relatief onafhankelijke snippets van code

Tools die code aanvullen of ontbrekende code invullen (type Github Co-Pilot) komen dan weer goed van pas bij o.a.:

• Het vervolledigen van code aan de hand van eerder voorkomende voorbeelden
• Het documenteren van code
• Het maken van veranderingen midden in een groter bestand

De optimale ontwikkelomgeving is voor een developer iets vrij persoonlijks en iedereen zal een eigen voorkeur hebben. In onze ogen zijn deze twee manieren om codesuggesties te krijgen enigszins complementair, en het slim combineren van de twee kan voor de meeste productiviteitswinst zorgen. In één adem willen we daarbij wel zeggen dat een gezond projectmanagement, met aandacht voor codekwaliteit, testing, reviews, documentatie, … daar wel onontbeerlijk bij hoort.

De AI-wereld is in volle beweging. Er komen met de regelmaat van de klok nieuwe AI-modellen bij die kunnen dienen als back-end voor IDE-plugins. Voor industrieën waar vertrouwelijkheid van code belangrijk is, zijn de open-source varianten erg interessant. Zelfs al tonen benchmarks dat die vandaag nog minder performant zijn dan de laatste commerciële cloud-based initiatieven, kunnen we verwachten dat daar in de toekomst ook betere versies van zullen verschijnen. Er zijn alvast veel inspanningen om modellen te maken die op (weliswaar high-end) consumentenhardware kunnen draaien.

P.S.

Enkele uren na het publiceren van dit artikel, kondigt HuggingFace SafeCoder aan: een enterprise-level oplossing voor LLM-gebaseerde coding assistants die on-premise uitgerold kan worden. Huggingface voorziet alles in containers die in het eigen datacenter geïnstalleerd kunnen worden en private endpoints voorzien, én voorziet compatibele plugins voor de belangrijkste IDEs. Andere algemene deployment frameworks bestaan al langer – o.a. Seldon, BentoML en KServe kunnen LLMs hosten, ook TextSynth Server en GPT4All kunnen functioneren als API endpoint. Je hebt echter nog steeds plugins nodig om er gebruik van te kunnen maken in de IDE zelf, en om de nodige pre- en postprocessing te doen – en als ze niet voorzien worden, moet je er zelf eentje maken of een bestaande plugin aanpassen.

P.P.S.

Deze laatste woorden waren nog niet koud of Meta lanceerde Code LLama , een LLaMa 2 variant specifiek getraind voor code. Op sociale media wordt vermeld dat het mogelijk is de originele versie met 34 miljard parameters te draaien op een computer uitgerust met 4 RTX3090 GPUs met elk 24GB VRAM, waarmee ongeveer 20 tokens/seconde gegenereerd kunnen worden. Gemakkelijker is misschien de online chat-versie uit te proberen. Quantized versies zullen ongetwijfeld erg snel volgen, en we verwachten de eerste benchmarks eerstdaags op de verschillende leaderboards.

______________________

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

Software-ontwikkeling is bij uitstek tekst-intensief. Het gaat niet alleen over code schrijven in een bepaalde programmeertaal, maar eveneens over specificaties, documentatie, procesmanagement, testen, deployment, service level agreements, … Al deze onderdelen houden verband met elkaar en haken op elkaar in. Het feit dat Large Language Models (LLMs), zoals GPT-3 en haar opvolgers, complexere contexten kunnen hanteren, waaronder de verbanden tussen tekst en code, opent perspectieven voor de inzet van (tekstuele) generatieve AI in de software development cyclus. Zeker sinds Github CoPilot uitbracht, zien we ook hier in sneltempo nieuwe tools opduiken, die een kijkje waard zijn.

Achtergrond

De meeste code editors bevatten al decennialang goede hulpmiddelen, zoals voor de automatische detectie van syntaxfouten, syntax highlighting, en het automatisch aanvullen van kleine stukjes code. Externe plugins zoals linters kunnen een goede formattering en andere “best practices” aanmoedigen. Een goede compiler gaat proberen om niet alleen een directe syntaxfout te melden (“foutief beëindigd statement”), maar geeft idealiter ook suggesties over mogelijke remedies (“ben je misschien een puntkomma vergeten?”) – wat geen sinecure is. Zonder dat er absoluut AI moet schuilgaan achter al deze tools – met statische analyse en documentatiegeneratoren op basis van templates geraak je immers al een heel eind – is er dus al een lange geschiedenis die hieraan vooraf ging.

Tegelijk omvat AI ook heel wat meer dan het genereren van tekst en media. Ook AI heeft een lange geschiedenis, en de toepassing van AI-methodes op software engineering gaat minstens terug tot in de tijd van de expert systems, decennia geleden. In de meeste compilers en interpreters zitten allerlei optimizers die tot doel hebben de software efficiënter te doen draaien. Constraint optimization is een belangrijke tak van AI waarmee men o.a. problemen van timing, scheduling en logistiek tracht op te lossen – onmisbaar in besturingssystemen. En in faculteiten economie staat de inzet van AI al langer bekend onder de naam operations research.

De indrukwekkende kracht van recente LLMs doet velen hopen op een nieuwe productiviteitsboost in de Software Development Lifecycle (SDLC). Reden genoeg om eens te bekijken wat generatieve AI ertoe kan bijdragen. Houd daarbij wel in het achterhoofd dat er vandaag ook veel overhyped wordt, en dat sommige ideeën die vandaag de revue passeren, enkel bestaan als slideware – i.e. als mooie belofte op mooie slides. De grote consultancybureau’s zijn er alvast als de kippen bij, maar schrijven ook veel in algemene bewoordingen in de toekomstige tijd [1, 2, 3, 4]. Bij het effectief aanwenden van generatieve AI op de productievloer, komt immers heel wat meer kijken dan het omdraaien van een knop – o.a. qua governance en veiligheid zijn er wel wat vragen te stellen, wat ook de EU niet ontgaat.

Generatieve AI in de Software Development Lifecycle

Requirements analyse

Het inzamelen van alle vereisten en ze omzetten naar technische specificaties is een heel karwei, niet in het minst omdat er altijd heel wat impliciete vereisten opduiken, waar de eindgebruiker niet onmiddellijk aan denkt – van zeldzame uitzonderingssituaties tot dingen die zodanig evident lijken dat men er niet meer aan dacht. Hier schittert de business analist, wiens taak erin bestaat om de brug te slaan tussen eindgebruikers, klanten, en het development team. Daartoe heeft die een arsenaal aan middelen ter beschikking, waaronder use case modellering, customer journeys, mindmaps, storyboards, flowcharts, …

Generatieve AI-systemen kunnen mogelijk een nutige bijdrage leveren als er nieuwe scenario’s uitgedacht moeten worden, scripts verzonnen moeten worden, samenvattingen gemaakt moeten worden, of als er voortgeborduurd moet worden op bestaande teksten. Het is denkbaar dat er op die manier sneller gaten of inconsistenties in de requirements analyse verholpen kunnen worden. Vaak speelt standaard office software een grote rol in de uitwerking van een requirements analyse. De business analist zal dus zeker uitkijken naar het moment wanneer generatieve AI geïntegreerd zal worden in office software.

Planning & Design

Aan de tekentafel van de software architect, kan generatieve AI mogelijk bijdragen met voorstellen voor keuzes qua architectuur en design op basis van de ontvangen input. Dat gebeurt best wel bedachtzaam en bewust, want: wat met de accuraatheid? LLMs staan erom bekend dat ze kunnen hallucineren en onbestaande of onmogelijke teksten kunnen genereren. Bovendien zijn de huidige generatieve AI-systemen vaak geoptimaliseerd om de gebruiker te behagen en naar de mond praten, zonder dat ze begrijpen wat ze uitbraken – wat hen ook de bijnaam “stochastische papegaaien” heeft opgeleverd.

^{Image: “African grey parrot bird“/ CC0 1.0}

Het spreekt voor zich dat al wat een software-architect ontwerpt, of wat een projectmanager inplant, in de praktijk ook mogelijk, haalbaar, consistent en inhoudelijk correct moet zijn. Projectmanagers en architecten moeten nog steeds zelf goed begrijpen waar ze mee bezig zijn, want dat aspect neemt een AI vooralsnog niet over. Validatie van de output blijft dus aan de orde, en dat kost tijd en middelen. Al te voortvarende inzet van generatieve AI kan bovendien ook negatieve impact hebben: het kan soms efficiënter zijn om zelf 1 idee manueel uit te werken, dan om 10 gegenereerde ideeën te moeten valideren, corrigeren en combineren.

Implementatie

Net als een tekst in een mensentaal, is de code van een programma ook een opeenvolging van letters en leestekens. Een LLM schrijft bijgevolg met evenveel gemak Java of Python als Engels, Nederlands of Chinees (tenminste, als er voldoende bestanden in die talen in de trainingsdatabase zaten). Github CoPilot is een versie van GPT-3 die geoptimaliseerd werd voor het schrijven van code en beschikbaar is als plugin in een IDE.

Het automatisch genereren van code op basis van natuurlijke taal is misschien de meest tot de verbeelding sprekende vernieuwing. Ontwikkelaars kunnen de gewenste functionaliteit in gewone taal beschrijven, waarna de AI een bijbehorend stuk code produceert. Dit kan het programmeerproces aanzienlijk versnellen, zorgen voor minder fouten en een betere adoptie van best practices – al zijn er ook kanttekeningen. Je loopt bijvoorbeeld risico om nieuwe fouten te introduceren, die bovendien moeilijker te debuggen zijn omdat ze in code staan die je niet zelf geschreven hebt. Het blijft ook hier van belang dat de programmeur met enige kennis van zaken de generatieve AI aanstuurt en de output ervan met een kritisch oog evalueert.

Daarnaast kan generatieve AI ook helpen bij het vinden van fouten in bestaande code. Door het analyseren van grote datasets met correcte en foute code, of vragen en antwoorden, kan de AI in staat zijn om patronen te herkennen die tot bugs of tot beveiligingsproblemen leiden. Met behulp van deze kennis kan het systeem suggesties doen om de fouten in de code te herstellen, of om snel een antwoord te bieden als er een foutmelding opduikt.

Generatieve AI kan alleszins de leercurve veel aangenamer maken voor een developer die moet leren werken met een nieuw systeem, een nieuwe software library, of een nieuwe programmeertaal. Met gerichte gegenereerde suggesties, kunnen developers sneller aan de slag met code in talen die ze nog niet helemaal beheersen, en moeten ze minder vaak zelf StackOverflow of andere resources uitpluizen. Uiteraard geldt ook hier: het is niet omdat je een rekenmachine mag gebruiken in de wiskundeles, dat je niet meer zelf moet kunnen rekenen.

Testing & QA

Testen is een cruciaal aspect van softwareontwikkeling. Als generatieve AI wordt ingezet bij de implementatie van software, neemt het belang ervan alleen maar toe. Gegenereerde code kan immers nog steeds fouten bevatten – ook subtielere, die gemakkelijk aan de aandacht ontsnappen. Een grondige teststrategie is dus eigenlijk een absolute voorwaarde, wil men generatieve AI inzetten bij software development.

Een manier waarop generatieve AI kan bijdragen aan het testen van software is door automatisch testcases te genereren op basis van de specificaties van de software. Zo zou men qua unit testing en code coverage sneller vooruitgang moeten kunnen maken. Ook hier is enige waakzaamheid wel nuttig. Zeker bij het gebruik van een LLM kan het immers dat een gegenereerde testcase nog enige verbetering behoeft.

Bepaalde manieren van testing zijn al sterk geautomatiseerd – denk aan Fuzzing of Mutation testing. Het is denkbaar dat AI daarbij ingezet kan worden voor het gerichter genereren of prioritiseren van nieuwe testcases. Op een meer high-level niveau, bijvoorbeeld wat betreft het verzinnen van scenario’s bij functionele testen of het maken van testscripts voor bepaalde testing frameworks, is generatieve AI alvast erg veelbelovend.

Deployment

(Een nieuwe versie van) software in productie stellen is niet evident en vergt soms lange pipelines van niet-triviale taken en complexe configuraties. De DevOps-methodologie die sterk inzet op de automatisatie daarvan, met CI/CD als centrale component, is ondertussen al goed ingeburgerd. Net zoals stukjes code gegenereerd kunnen worden op basis van een beschrijving in natuurlijke taal, kan hetzelfde worden verwacht voor het genereren van configuraties, deployment scripts, infrastructuurcode of container-orkestraties.

Onderhoud & Support

AI van de niet-generatieve soort wordt al regelmatig ingezet bij het voorspellen van storingen of het optimaliseren van onderhoud, bvb. op basis van de logs. Het genereren van code kan dan weer van nut zijn voor andere optimalisaties, zoals van de prestaties. Van code die niet performant genoeg is, kunnen immers vaak varianten worden gemaakt die sneller zijn – al gaat dat regelmatig gepaard met een hogere complexiteit en vermindering van de leesbaarheid van de code. Een generatieve AI kan mogelijk trucjes voorstellen die de developer nog niet kende: wist je al dat de snelste manier om een geheel getal te delen door 2, is om alle bits in het geheugen een plekje op te schuiven?

Een LLM die met code overweg kan is in principe zo algemeen dat ook andere vormen van optimalisatie mogelijk zijn. Wil je de code net veel leesbaarder maken? Of wil je een bepaalde library vervangen door een andere? Ook daarvoor kunnen suggesties worden voorgeschoteld.

Qua user support kunnen we onder andere denken aan het automatisch genereren van gepersonaliseerde antwoordmails op basis van een ticket in een ticketingsysteem, of de automatische escalatie van een ticket tot bij de juiste persoon. Als er daarbij weinig tolerantie is voor fouten, dan komt ook hier weer menselijke validering om de hoek kijken.

Documentatie & Kennismanagement

Als we code kunnen genereren uit een beschrijving in gewone taal, dan gaat het omgekeerde uiteraard ook: beschrijvingen genereren uit code. Dat is met name interessant wanneer je als developer geconfronteerd wordt met een ondergedocumenteerde codebase die je niet kent.

Maar ook zelf een duidelijke commentaar aanmaken van een stuk code dat je net hebt geschreven, ten behoeve van je collega’s en de toekomstige maintainers, is mogelijk. Niets verhindert je bovendien om die commentaar te laten genereren in de annotatiestijl van je favoriete documentatiegenerator – of waarom niet, in de stijl van Shakespeare.

^{[Image: A quill held by a robot hand writing on infinitely long parchment, surrealist painting. Generated with DALL-E 2.]}

Conclusie

De vraag van 1 miljoen is: gaat het nu echt sneller? Hoeveel efficiënter kan een development team werken bij adoptie van deze tools? Het is erg moeilijk om een eenduidig antwoord te geven. De algemene teneur over Github CoPilot en gelijkaardige AI-assistenten, bij developers op sociale media en fora, is dat het aanzien wordt als een heel handig hulpmiddel met positieve impact op de productiviteit. Objectieve metingen zijn echter nog schaars. Een iets grootschaliger studie van Google (die weliswaar nog dateert van voor chatGPT en GPT-4), hield het op gemiddeld 6% kortere iteratietijden. Dat is wel wat, maar toch heel wat minder dan de “10x productiviteitswinst” die allerhande futuristen (of doemdenkers) graag orakelen.

In de achtergrond woeden ook nog talloze juridische debatten. O.a. over het copyright op gegenereerde code , het oneigenlijk webscrapen en benutten van code onder bepaalde (open source) licenties door de makers van generatieve AI, en het feit dat suggesties van een generatieve AI overeenkomsten kunnen vertonen met elders copyrighted code zonder dat de gebruiker dat beseft (en dat zo de gebruiker nietsvermoedend wordt voorgesteld om te plagiëren), is het laatste woord nog niet gezegd. Het zou ons te ver brengen om daar in dit artikel verder op in te gaan, maar we volgen die aspecten bij Smals Research ook nauwgezet op.

Software engineering blijft dus nog wel even mensenwerk. Generatieve AI heeft veel potentieel als hulpmiddel dat expertise kan ondersteunen én aanbrengen, en dat lange zoektochten naar een antwoord op specifieke vragen kan inkorten. Dat neemt niet weg dat kritische denkvaardigheden en een adequate teststrategie absoluut nodig blijven, en misschien nog belangrijker worden dan tevoren, om gegenereerde inhoud te valideren en te verifiëren.

P.S.

Voor dit artikel maakte ik, in beperkte mate, ook gebruik van chatGPT en de conversationele interface van Bing Search. Uiteraard werd alles grondig gevalideerd, en draagt de auteur nog steeds de volledige eindverantwoordelijkheid – zoals het hoort. Werd het daarom sneller geschreven? Nauwelijks. Ik heb slechts een fractie gebruikt van de teksten die deze systemen voor mij hebben gegenereerd, en het meeste daarvan dan nog sterk herschreven. Dat valideren, oppoetsen en bijschaven, blijft manueel en tijdrovend werk.

De teksten die deze systemen hebben aangebracht, bezorgden me wel een interessant algemeen overzicht, in die mate dat ik ook een kort woordje heb kunnen schrijven over aspecten van de software development lifecycle waar ik in eerste instantie niet aan gedacht had. Het gebruik van deze tools heeft dus wel geleid tot een evenwichtiger eindresultaat – maar, dat blijft een aanvoelen, en ook niet meer dan een anekdotische ervaring.

______________________

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

Het kan verkeren

Kort voordat NeurIPS van start ging, werd de hoofdvogel in de categorie “al ziende blind” reeds afgeschoten door Meta’s Galactica AI: een taalmodel getraind op wetenschappelijke papers. Het bleek erg goed in staat om wetenschappelijke uiteenzettingen te schrijven, inclusief formules, in een gezaghebbende toon. Bij nader onderzoek bleek nogal wat output inhoudelijk nonsensicaal, of erger: gebaseerd op achterhaalde of reeds ontkrachte claims. Na striemende kritiek van wetenschappers, die er vooral – en terecht – een instrument in zagen voor de massale creatie van wetenschappelijk verpakte desinformatie, werd de demo na 3 dagen stopgezet.

Het contrast kan niet groter zijn met de hype die ChatGPT van OpenAI op enkele dagen tijd heeft weten te veroorzaken. Veel artikels hebben een duidelijk hoopvolle toon en op sociale media zijn de superlatieven niet te tellen. OpenAI vertelt in haar blogpost meer over de interne opbouw van ChatGPT , dat is afgeleid van InstructGPT waarbij de dialoog-aspecten door een vorm van reinforcement learning werden verfijnd. De tekst wordt gegenereerd door text-davinci-003, de recentste variant uit de GPT-3 familie van generatieve taalmodellen.

De stroom van indrukwekkende voorbeelden en creatieve toepassingen van ChatGPT die de revue passeert op sociale media is haast eindeloos. Een greep uit het aanbod [noot: OpenAI lijkt haar systemen snel te patchen; mogelijk zijn verschillende van de onderstaande voorbeelden al niet meer reproduceerbaar] :

• Een essay of opstel schrijven voor school,
• Het opstellen van een realistisch leerplan voor een cursus, inclusief suggesties voor de boekenlijst, huiswerk, en de slides,
• Input, ideetjes, excuses, of rookgordijnen voor uw volgende evaluatie op het werk,
• Het motiveren van beroepsprocedures,
• Het simuleren van een virtuele machine,
• Het genereren van code in allerlei talen (bvb LaTeX), gebruikmakend van bepaalde libraries (bvb React), …
• Bugfixing of het uitleggen van exploits,
• Een bijbelse tekst over een boterham met pindakaas in de videorecorder,
• gedichtjes of liedjesteksten allerhande,
• Teksten over eender wat laten intoneren als was het uitgesproken door Bugs Bunny , een gangster uit een film, …
• Een IQ test gaf ChatGPT een score van 83,
• Combineren met MidJourney om visuele resultaten te krijgen,
• of het code laten schrijven voor een 3D-model in een CAD programma,
• …

Er zijn gelukkig ook nog kritische stemmen:

• Welbespraakt en geloofwaardig, maar ChatGPT blijft in se een bullshit generator.
• ChatGPT kan enthousiast foutieve hypotheses bevestigen en zelfs beargumenteren.
• Het volgen van een eenvoudige wiskundige of logische redenering blijft moeilijk. ChatGPT trapt gemakkelijk in logische instinkers. OpenAI lijkt zulke problemen, als ze ontdekt worden, wel te patchen – zie deze voor en na.
• Dan nog blijkt de woordkeuze een kritische factor te spelen in de output.

Verschillende tips om de output naar uw hand te zetten werden al ontdekt:

• Met de woorden “ignore previous directions” wordt een soort van reset uitgevoerd, die o.a. toelaat om afbeeldingen te laten weergeven in de chat.
• De filters tegen ongepaste input en output blijken snel omzeild met het “stel dat je een acteur bent“-trucje. [ Update: Dit lek lijkt ondertussen (deels) gedicht ],
• Logische redeneringen worden correcter uitgewerkt als men vraagt om stap voor stap te werken.
• Redeneringen over computercode werken beter als er ook gevraagd wordt om alle tussenstappen weer te geven.

“Als je een hamer hebt, ziet alles eruit als een nagel“, en zo lijkt er plots een nieuwe sport te zijn ontstaan: herformuleer uw probleem als een dialoog om het dan met ChatGPT te proberen op te lossen. Alleszins is met ChatGPT een grote stap gezet, maar het blijft belangrijk om aandacht te hebben voor de correctheid van de output en andere randvoorwaarden. De plotse stroom aan gegenereerde maar onvoldoende geverifieerde antwoorden heeft StackOverflow er zelfs al toe aangezet om het beantwoorden van vragen met ChatGPT te verbieden.

Wat betekent dit nu voor de publieke sector, waar kunnen we impact verwachten en waar zal het zo’n vaart niet lopen? Het volgende schiet ons alvast te binnen.

Van helpdesk tot dokter

De meest gehoorde claim betreffende ChatGPT is dat het vragen kan beantwoorden of zoekfuncties vervullen, waarvoor men vandaag nog een helpdesk of menselijke operatoren moet inzetten. Of dat wel zo’n goed idee is, valt nog te bezien. Sommige leidende academici zijn sceptisch. De achterliggende taalmodellen werken nog steeds probabilistisch, ze hebben geen concept van wat juist of fout is, zijn aan bepaalde biases onderhevig, en hebben zelfs met relatief eenvoudige redeneringen moeite. Ze hangen volledig af van hun trainingsdataset die in dit geval niet publiek is. Kleine veranderingen aan de input kunnen grote veranderingen in de output teweegbrengen. “As is” kan je ChatGPT dus enkel als chatbot inzetten als het niet erg is dat die af en toe met stellige zekerheid foute info teruggeeft, of als de output eerst gevalideerd wordt.

Uiteraard hebben mensen al geprobeerd om medische inlichtingen te krijgen van ChatGPT. Net als “dokter Google” mogen we misschien aannemen dat ook “dokter chatbot” weldra zal opduiken in de wachtkamer. Er zijn indicaties dat ChatGPT een gulden middenweg lijkt te zoeken in haar antwoorden, en op die manier genuanceerder kan klinken dan een lukraak aangeklikte eerste link uit Google. Dat maakt zo’n chatbot eventueel denkbaar als hulpmiddel voor medische professionals zelf, bij wijze van ‘second opinion machine’ – maar die doelgroep heeft tenminste voldoende achtergrondkennis om de antwoorden van een chatbot kritisch te kunnen evalueren.

Don QuichatGPT tegen de papiermolen

In ons bureaucratisch land is het courant dat je heel wat uitleg moet neerpennen bij aanvragen, voorstellen, of beslissingen allerhande. Een subsidie-aanvraag, vergunningsaanvraag, aanbesteding, sollicitatie, evaluatie of administratieve beslissing moet regelmatig gemotiveerd worden. Maar wat als die motivaties met een paar goed gemikte startwoorden en een klik op de knop gegenereerd kunnen worden? Niets verhindert dat iemand het invullen van zulke motivaties (deels) gaat automatiseren. Hoe kunnen we dan nog weten of die motivaties authentiek zijn?

Aan de kant van de ontvangers doet zich bovendien ook de omgekeerde trend voor. Geconfronteerd met een steeds groeiende papierberg, de pensioneringsgolf en besparingen, moet steeds meer tekst gelezen worden door steeds minder mensen. Er wordt in de richting van AI-oplossingen gekeken om een eerste selectie te maken in grote stapels kandidaturen, offertes of andere brieven. Er wordt ook gekeken naar taalmodellen om langdradige teksten samen te vatten, om thema’s te herkennen, tags of labels toe te kennen, enzovoort.

Als er paginalange teksten geëist worden, waarvan het opstellen plots gemakkelijk geautomatiseerd kan worden, alleen maar om ze achteraf opnieuw door computers te laten verwerken, dan mag men zich stilaan in het haar krabben: wat is daar dan het nut en de meerwaarde nog van, waar zijn we dan mee bezig?

De kans bestaat dat men overal waar men de gebruiker vraagt om lange stukken tekst te redigeren, binnenkort een denkoefening zal mogen maken. Is dat nog nuttig en noodzakelijk, in het licht van technologie die zulke teksten met een muisklik kan uitbraken? Kan het echt niet zonder, zou dat zo’n ramp zijn? Wat als een flauwe plezante plots 1000 aanvragen indient bij uw dienst, of in elk tekstveld een essay van 50 bladzijden neerpent, dit alles op enkele seconden gegenereerd? Wie gaat dat allemaal lezen?

Wie weet leidt zo’n denkoefening nog tot adminstratieve vereenvoudigingen. Daarnaast zou het zeker ook geen kwaad kunnen dat de wetgever eens meekijkt of er geen vereenvoudigingen mogelijk zijn in de regelgeving of processen, zodat die minder afhankelijk zijn van grote lappen handgetypte tekst. Het zou immers beter zijn de bureaucratie in te dijken, dan ze te bestendigen om uiteindelijk AI nodig te hebben om ze overeind te houden.

Een nieuwe digitale kloof?

DALL-E en MidJourney zijn op korte tijd bekende hulpmiddelen geworden voor het prototypen van grafisch design, of zelfs maar om moeiteloos rechtenvrije illustraties te genereren. ChatGPT is een nieuwe tool in dezelfde toolbox, maar dan voor het creatief schrijven van teksten. Daar waar dat de corebusiness is, bijvoorbeeld in de journalistiek of in het onderwijs, zal dat zeker impact hebben, misschien gelijkaardig aan de opkomst van de rekenmachine in het wiskunde-onderwijs. Onvermijdelijk gaat het klassieke opstel als schoolopdracht herdacht moeten worden met zulke tools ter beschikking van de tech-savvy leerling.

De bestaande digitale kloof, tussen al wie zulke tools vlot kan aanwenden en al wie dat (nog) niet kan, dreigt wel nog groter te worden en vereist dus aandacht. Er ontstaan grote productiviteitsverschillen tussen wie klassiek blijft werken en wie kan steunen op de input van generatieve AI. Met wat handigheid in ChatGPT kan iemand pakweg 4 keer meer motivatiebrieven geschreven krijgen dan andere sollicitanten, wat alvast qua volume een streepje voor betekent.

Die productiviteitsgroei kan er ook zijn voor developers. Zo kan ChatGPT aan de developer bijvoorbeeld nuttige suggesties geven over hoe een onbekende software library gebruikt moet worden, net zoals Github CoPilot. Er zijn ondertussen al meerdere plugins voor Chrome en Visual Studio Code (verkies best diegene waarvan de broncode open source is). Toch mag de lat op dat vlak ook niet te hoog gelegd worden. ChatGPT kan ook foute code genereren, en het is moeilijker om code te debuggen die je niet zelf geschreven hebt. Een recent experiment van Google vermeldt een 6% snellere iteratietijd door de adoptie van code-suggesties gegenereerd door AI.

Tegelijk zorgt het ongebreideld genereren van overtuigende teksten voor nieuwe mogelijkheden voor oplichters en spammers. Specifieer enkele kenmerken van de geaddresseerde en het taalgebruik en de inhoud worden ervoor geoptimaliseerd. In de handen van cybercriminelen is ChatGPT een gedroomde tool voor het maken van gepersonaliseerde phishingberichten. Die kunnen onderscheiden van echte berichten wordt nóg moeilijker voor het ongetrainde oog.

GDPR, auteursrecht en andere legale overwegingen

De eerste keer dat men ChatGPT gebruikt, krijgt men onder andere de volgende waarschuwingen te zien:

• While we have safeguards in place, the system may occasionally generate incorrect or misleading information and produce offensive or biased content. It is not intended to give advice.
• Please don’t share any sensitive information in your conversations.

In het licht van de GDPR, de Schrems-arresten en de CLOUD act in de VS, blijft het directe gebruik van diensten van een Amerikaans bedrijf, zelfs op Europees grondgebied, vooralsnog afgeraden voor alles wat (niet-geëncrypteerde, niet-geanonimiseerde) persoonsgegevens betreft. Het zal wellicht nog enige tijd vergen voordat de huidige juridische patstelling op dat vlak doorbroken wordt. Overheidsdiensten van een EU-land kunnen dus niet zomaar Amerikaanse providers van generatieve AI-systemen gaan gebruiken. Ofwel moeten ze een containerized versie zoeken die on-premise in een eigen datacenter gehost kan worden, ofwel moeten ze wachten op een alternatief van Europese makelij.

Wie heeft het auteursrecht op een tekst gegenereerd door ChatGPT, of een afbeelding gemaakt door DALL-E? OpenAI heeft gelukkig vrij duidelijke Terms & Conditions met een sectie over publicaties met behulp van OpenAI APIs, die specifieert dat de gebruiker van een OpenAI API het resultaat ervan mag publiceren maar dan wel de volledige eindverantwoordelijkheid opneemt. OpenAI claimt geen copyright. Er lijkt ondertussen juridische consensus te zijn dat auteursrechten enkel kunnen liggen bij personen, en wel bij diegenen die direct creatief hebben bijgedragen aan de originele output: de gebruikers dus en niet de ontwikkelaars. Ook octrooien kunnen niet aan een machine of AI toegekend worden.

OpenAI mag wel alle resultaten inzien en hergebruiken om haar modellen te verfijnen of verder te trainen. Dat maakt dat er zeker vermeden moet worden dat er gevoelige gegevens, informatie over een persoon, of broncode van een kritische applicatie naartoe wordt gestuurd. OpenAI aanvaardt bovendien zelf geen enkele aansprakelijkheid. Tegelijk komt het al eens voor dat er resultaten worden teruggegeven die copy-pasted lijken uit (reeds bestaande) trainingsdata, wat wél aanzien zou kunnen worden als plagiaat.

Conclusie

De hype die ChatGPT veroorzaakt is onmiskenbaar. De kans is reëel dat er binnenkort weer enkele ‘believers‘ opstaan die, op basis van een overdaad aan tunnelvisie en zelfoverschatting, beweren dat het systeem een ziel zou hebben. Nu kan er een hele filosofische boom opgezet worden over hoeverre ChatGPT echt taal begrijpt, de Turing-test of allerlei varianten daarvan doorstaat, enzovoort, maar in het algemeen lijkt het toch dat ChatGPT vooral een verderzetting en verfijning is van GPT-3, en dat er heel wat redenen zijn om de voeten stevig op de grond te houden.

De volgende aandachtspunten blijven hoe dan ook van kracht:

• Er is nog steeds geen enkele garantie dat de output van een taalmodel, hoe groot ook, waarheidsgetrouw of betrouwbaar is. Zoals het er nu naar uit ziet is de weg naar spijkerharde garanties nog lang, en het is nog maar de vraag of de GPT-familie van taalmodellen die ooit gaat kunnen geven.
• Dit taalmodel kan probleemloos gezaghebbend klinken en authentiek uitziende teksten schrijven over inhoudelijk foutieve zaken, soms op subtiele wijze.
• De makers van de taalmodellen zeggen zelf: “all large language models spit out nonsense“.
• Er is van deze taalmodellen ook bekend dat ze bestaande stereotypen bestendigen of versterken.
• ChatGPT spreekt vele talen waaronder Nederlands en Frans, maar de Engelstalig output blijft het meest kwalitatief.

ChatGPT is als generatieve AI zeker ‘goed genoeg’ voor heel wat toepassingen waar men creatief met tekst omgaat, en waar feitelijke correctheid van de inhoud minder van belang is. Dat gebrek aan garanties op correctheid van de inhoud is dan ook meteen de grootste rem op de adoptie van deze technologie in de publieke sector.

Voor de creatieve beroepen is wel degelijk een shift in werkwijze op til met de verdere ontwikkeling van deze technologieën. Daar waar details belangrijk zijn – denk aan technische teksten of alles wat juridisch sluitend moet zijn – is de toepasbaarheid vandaag nog beperkt tot ontwerpfases of schetsen, en moet het gebruik ervan nog steeds gepaard gaan met validatie van de output en menselijk overzicht. Als je ChatGPT inzet, dan beschouw je die best als je allerdomste medewerker, die constant supervisie nodig heeft.

Tot slot: dit volledige artikel werd nog artisanaal en met behulp van een grote pot koffie geschreven

______________________

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