Dit artikel is ook beschikbaar in het Nederlands.

Depuis l’essor de l’engouement pour les grands modèles de langage, la plupart des développeurs ont sans doute déjà pu constater le gain de productivité que ces outils peuvent offrir, à condition de les utiliser correctement. Dans cet article de blogue, nous explorons la possibilité d’aller plus loin : l’IA offre-t-elle une aide suffisante afin de maîtriser le legacy code ?

Le recours aux grands modèles de langage (Large Language Model – LLM) en programmation est en effet bien connu à présent : cela va de la formulation de questions à un chatbot (“comment écrire un algorithme en Java qui…”), à un code completion de plus en plus intelligent et étendu (saisie automatique de ce que vous souhaitez taper dans l’éditeur), jusqu’au vibe coding complet (dans l’IDE, ou même simplement dans un terminal) : des agents d’IA rédigent, à l’aide de prompts, des pans entiers de code sur votre machine – oui, même des applications fonctionnelles.

Nous avons donné une définition très large du code legacy dans un précédent article de blog. Commençons donc par préciser ce que nous entendons par “legacy” et par mieux illustrer le “degré de difficulté” des projets legacy.

“Ancien” code : une multitude de possibilités

Il n’existe pas vraiment de définition officielle du code legacy ; généralement, on parle de l’utilisation d’une technologie qui n’est plus prise en charge, difficile à maintenir, ou simplement de “code dont on hérite de quelqu’un d’autre”. Il s’agit évidemment toujours de code encore en service, et donc important. Ironiquement, les applications les plus critiques sont souvent celles qui existent depuis des années et auxquelles on “fait confiance” depuis longtemps, mais sans les entretenir correctement.

L’IA peut nous aider à entretenir n’importe quel code ; nous allons donc présenter un spectre allant du code legacy le plus ancien et le plus problématique au code de projets ne nécessitant qu’une petite mise à jour. À une extrémité du spectre, on trouve des programmes écrits dans des langages de programmation obsolètes, selon une architecture dépassée, utilisant des bases de données qui ne sont plus d’actualité et fonctionnant sur des serveurs équipés de systèmes d’exploitation qui ne sont plus pris en charge : avec ces géants, on doit souvent craindre une défaillance critique à la moindre modification erronée. À l’autre extrémité, on trouve des logiciels assez bien entretenus, mais qui utilisent une bibliothèque logicielle qui n’est plus la version la plus récente : il est généralement très facile de les remettre entièrement à jour. Enfin, quelque part entre les deux, on trouve des applications pour lesquelles la plupart des développeurs n’utiliseraient pas encore le terme legacy, mais qui nécessitent néanmoins des migrations complexes, avec par exemple un ou deux frameworks obsolètes à remplacer.

Que pouvons-nous en faire ? Les LLM offrent-ils d’autres possibilités en fonction de la position du projet sur ce spectre ? Jusqu’à présent, nos recherches se sont concentrées sur la partie gauche de ce spectre ; la suite de cet article portera donc davantage sur les possibilités d’aborder le “véritable” legacy. Plus tard dans l’année, nous approfondirons également ce que nous pouvons faire en matière de migrations et d’updates.

Utilisation des LLM sur des bases de code legacy

Il est clair qu’un simple prompt “réécris ce programme selon les normes modernes” ne fonctionnera pas (même si certains fournisseurs affirment que cela sera bientôt possible). Nous devrons poser des questions un peu plus concrètes et décomposer le travail en plusieurs étapes. Il y a en fait deux choses que nous pouvons faire avec notre code legacy : le réécrire et le documenter.

Réécriture du code legacy

Lorsque nous commençons à réécrire du code, nous devons souvent tenir compte du fait que la reconstruction complète d’un très grand projet est une tâche trop difficile. Il est possible d’obtenir des “quick wins” en réécrivant stratégiquement certaines parties d’un projet, qui seront ensuite réutilisées dans un contexte plus large, où une équipe humaine et l’IA reconstruiront l’application dans les règles de l’art. Nos expériences nous ont montré qu’il était trop ambitieux d’attendre de l’IA qu’elle utilise une architecture entièrement nouvelle tout en traduisant l’ancien code vers le nouveau. En revanche, il est possible de “vibe coder” une grande partie de la charpente typique d’un nouveau projet, puis d’y injecter de manière ciblée un certain nombre de morceaux de code qui sont des traductions de parties d’un projet legacy. En tant qu’êtres humains, notre tâche consiste à indiquer clairement quelle architecture nous attendons et quelles sont les règles de qualité du code nouveau.

L’un des principaux défis liés à la réécriture de code à l’aide de l’IA consiste à tester l’exactitude de la traduction : le code fait-il toujours ce qu’il faisait auparavant (indépendamment du fait que cela soit souhaitable, car même le business case peut parfois être trop obsolète dans le cas d’un projet legacy) ? Pour les projets relativement récents, il existe déjà de nombreux tests que nous pouvons effectuer pour vérifier l’exactitude, mais avec les anciens systèmes legacy, nous sommes souvent confrontés au problème que l’application est simplement testée en production, ou du moins avec des données de production : il n’y a pas de tests spécifiques ni même de données de test pouvant être utilisées en toute sécurité. Dans ce cas, il s’agit de créer un environnement dans lequel nous pouvons tester le nouveau code en toute sécurité, ce qui est généralement un travail ad hoc et demande une certaine créativité. Nous ne pouvons pas envoyer de données de production vers le cloud, nous devons donc nous assurer que le LLM ne puisse pas les lire. Ce serait plus simple si nous pouvions utiliser des LLM fonctionnant en local, mais pour l’instant, ceux-ci ne sont pas encore assez puissants (quand ils sont disponibles) pour effectuer des tâches aussi complexes avec du code legacy.

L’interface utilisateur constitue un autre défi : dans les projets plus anciens, celle-ci est souvent obsolète et il faut construire une nouvelle GUI à partir de zéro. Cela pose toutefois le problème de ne plus disposer d’une base de référence dans l’ancien projet : la nouvelle interface devra généralement être testée manuellement par des personnes. J’espère toutefois que nous verrons des progrès dans ce domaine dans un avenir proche, en ce qui concerne les possibilités de l’IA. En effet, nous voyons déjà apparaître des systèmes capables de contrôler l’intégralité de votre ordinateur (comme OpenClawd), et l’intégration avec des frameworks plus traditionnels pour le test d’une interface graphique fait également partie des possibilités.

Enfin, les petits projets legacy constituent également un domaine où nous pouvons obtenir des résultats rapides. Si nous utilisons un programme legacy petit à moyen, doté de fonctionnalités limitées et d’une GUI simple, ou présentant un input et un output clairs en cas de traitement par lots, et qu’il n’existe aucun business case justifiant son intégration dans une autre méthode de travail, nous pouvons alors tenter une approche directe pour construire une version moderne dans un nouveau langage de programmation à l’aide de l’IA. Dans ce cas, il faudra tout de même bien tester et adopter une approche structurée avec un accompagnement des développeurs humains, mais il est possible d’essayer cette méthode pour des applications non critiques. Une application à usage interne, par exemple, constitue généralement un bon premier candidat.

Documentation du code legacy

Parfois, la réécriture du code legacy avec l’IA est un peu trop ambitieuse, ou nous avons besoin de plus d’informations avant de nous y risquer. Il peut être intéressant de se tourner d’abord vers la documentation : l’IA peut également nous aider à faire en sorte que l’exploration d’une base de code legacy ressemble un peu moins à de l’archéologie de haut niveau.

Expliquer un morceau de code de petite à moyenne taille et en extraire la logique business, ou analyser un morceau plus important et en expliquer la structure et l’architecture, tout cela est tout à fait possible avec les grands modèles de langage actuels. Il est toutefois possible d’aller plus loin : il est possible de créer des outils d’IA pour l’aider à explorer la base de code et, par exemple, à générer des diagrammes illustrant les dépendances entre les segments de code. Ou bien on peut lui faire écrire des scripts afin de structurer soigneusement ses conclusions après chaque analyse dans un fichier texte pour elle-même et un PDF destiné à l’utilisateur humain.

Il est également possible d’adopter une approche hiérarchique : commencer par explorer la base de code, puis approfondir progressivement l’analyse des différents modules afin d’obtenir de plus en plus de détails et de compléter l’analyse. Il s’agit là de l’approche descendante, que nous pouvons toutefois compléter par une version ascendante : une fois que nous sommes allés en profondeur, nous pouvons à nouveau demander un résumé afin de construire une présentation mieux documentée de la situation dans son ensemble.

Il est toutefois important ici de savoir à l’avance ce que nous souhaitons exactement atteindre. Une analyse générale d’une base de code par l’IA peut s’avérer intéressante lorsque les utilisateurs humains ne connaissent pas du tout le système et souhaitent disposer de points de repère pour se familiariser avec celui-ci.

Cependant, lorsque l’objectif est de pouvoir assurer la maintenance de la base de code, il est préférable de mettre en place un système proposant un chatbot qui connaît le contexte spécifique et les particularités du projet legacy, et qui peut répondre à des questions très ciblées à ce sujet. Cela est possible, par exemple, dans CoPilot Studio. Si cela ne fonctionne pas correctement, il est possible d’envisager de construire manuellement une base de connaissances en utilisant l’IA qui pourra ensuite être utilisée par l’IA pour répondre aux questions.

Une autre option consiste à extraire des informations spécifiques de la base de code, telles que la logique business par module individuel, ou du pseudocode pouvant aider les développeurs humains à réimplémenter cette logique dans un autre projet. (Et bien sûr, une IA peut également être mise à contribution lors de cette deuxième étape).

Avec une touche de créativité, nous pouvons concevoir une meilleure approche pour la plupart des analyses ad hoc que celle consistant à “se contenter d’analyser à tout va”. Et la documentation d’un système legacy peut tout simplement constituer une première étape vers sa réécriture.

Conclusion : professionnels recherchés

Comme mentionné précédemment, les LLM nous offrent progressivement des possibilités très puissantes pour traiter nos bases de code legacy, surtout lorsque nous avons accès aux modèles volumineux et puissants disponibles aujourd’hui. Nous constatons toutefois qu’il s’agit en réalité d’une boîte à outils très bien fournie, comprenant plusieurs outils puissants, et que nous devons savoir ce que nous voulons en faire et comment les utiliser au mieux.

Tout n’est pas encore entièrement automatisé : nous aurons donc toujours besoin de bons professionnels pour tirer le meilleur parti de ces outils. Notre conseil aux développeurs est de ne surtout pas avoir peur de l’IA et de l’utiliser régulièrement lors de l’analyse et du développement de logiciels : l’expérience est la meilleure école pour former les bons professionnels dont nous avons besoin dans ce domaine.

Pour l’instant, la conclusion est donc la suivante : pour le code legacy, l’IA n’est pas une panacée, mais une boîte à outils pratique qu’il vaut mieux essayer dans le cadre d’une approche plus large. Comme indiqué, nous nous pencherons plus tard dans l’année sur le milieu et la partie droite du spectre du code legacy. Nous pensons qu’il existe ici davantage de possibilités d’automatisation de certains workflows, surtout si nous exploitons davantage les agents. Il est donc possible que, pour des projets un peu plus simples et répétitifs, nous puissions évoluer du “professionnel” vers “l’usine”.

Cet article est aussi disponible en français.

Sinds de hype van grote taalmodellen is losgebarsten, zullen de meeste ontwikkelaars ondertussen al wel geproefd hebben van de productiviteitswinst die deze tools, mits correct gebruik, kunnen bieden. In deze blog onderzoeken we of we verder kunnen gaan dan dat: biedt AI ook voldoende hulp bij het beheersen van Legacy Code?

Het inzetten van Large Language Models (LLM) bij het programmeren is inderdaad ondertussen stilaan goed gekend: het gaat van vragen stellen aan een chatbot (“hoe schrijf ik in Java een algoritme dat … “), overheen steeds slimmere en langer wordende code completion (automatisch aanvullen wat je wil typen in de editor), tot volledige vibe coding (in de IDE, of zelfs gewoon in een terminal): AI agenten, via prompts, hele stukken code – ja, zelfs werkende toepassingen – laten schrijven op je machine.

In een vorige post rond legacy code, gaven we een erg brede definitie. Laten we dus vooreerst iets duidelijker stellen wat we met Legacy bedoelen, en de “moeilijkheidsgraad” van Legacy projecten beter illustreren.

“Oude” code: een spectrum aan mogelijkheden

Er is niet echt een officiële definitie van legacy code; meestal spreekt men van het gebruik van niet langer ondersteunde technologie, moeilijk te onderhouden, of simpelweg “code die je van iemand anders erft”. Het gaat uiteraard altijd wel om code die nog in gebruik, en dus belangrijk is. Ironisch genoeg, zijn het vaak de meest kritische toepassingen, die al jaren meegaan en waar men al jaren “op vertrouwt”, maar dan zonder ze goed te onderhouden.

AI kan ons helpen bij het onderhoud van eender welke code, dus we zullen een spectrum demonstreren dat van de oudste, ergste legacy code gaat, tot code van projecten die slechts een kleine update nodig heeft. Aan de ene kant van het spectrum heb je programma’s, geschreven in ouderwetse programmeertalen, volgens een achterhaalde architectuur, gebruik makend van databases die niet meer van deze tijd zijn, en draaiende op servers met niet langer ondersteunde besturingssystemen: bij deze mastodonten moet men vaak bang zijn dat ze kritisch zullen falen bij de kleinste verkeerde wijziging. Helemaal aan de andere kant heb je vrij goed onderhouden software, waarin een softwarebibliotheek wordt gebruikt die niet meer de meest recente versie is: meestal een koud kunstje om ze weer helemaal up-to-date te krijgen. Ergens in het midden vind je, ten slotte, toepassingen terug waarbij de meeste developers nog niet meteen het woord Legacy in de mond zullen nemen, maar waar wel moeilijke migraties dienen te gebeuren, met b.v. een verouderd framework of twee dat zou moeten worden vervangen.

Wat kunnen we hier nu mee? Bieden LLMs ons andere mogelijkheden naargelang de plaats van het project op dit spectrum? Ons onderzoek heeft zich tot nu toe op de linkerkant van dit spectrum gefocust, dus het vervolg van deze blogpost zal veeleer over de mogelijkheden gaan om “échte” Legacy aan te pakken. Later dit jaar gaan we ook verder uitdiepen wat we met migraties en updates kunnen doen.

Gebruik van LLMs op Legacy Codebases

Het is duidelijk dat de eenvoudige prompt “herschrijf mij dit programma volgens moderne standaarden” niet zal werken (al beweren sommige vendors dat dit eraan zit te komen). We zullen iets concretere zaken gaan vragen, en het werk ook enigszins in stukjes moeten kappen. Verder zijn er eigenlijk twee zaken die we kunnen gaan doen met onze legacy code: ze herschrijven en ze documenteren.

Herschrijven van Legacy Code

Als we beginnen met code herschrijven, zullen we er vaak rekening mee moeten houden dat een heel groot project voldoende goed herbouwen een te moeilijke opgave is. We kunnen “quick wins” behalen door strategisch een aantal zaken te gaan herschrijven van een project, en die stukken dan te gebruiken in een ruimere context, waarbij een team van mensen en AI de toepassing opnieuw bouwen volgens de regels van de kunst. Bij onze experimenten stelden we vast dat het een brug te ver was om van het AI te verwachten een volledig nieuwe architectuur te gebruiken, tegelijk met het vertalen van oude code naar nieuwe. Wat wel mogelijk is, is om heel wat van de typische scaffolding (de standaardcode om tot iets werkend te komen) van een nieuw project te vibe coden, en daar dan gericht een aantal stukken code in te injecteren die vertalingen zijn van stukjes van een legacy project. Als mens is het onze taak om duidelijk aan te geven welke architectuur we verwachten, en wat de kwaliteitsregels zijn van de nieuw geschreven code.

Eén van de grotere uitdagingen bij het herschrijven van code met behulp van AI, is het testen van de correctheid van de vertaling: doet de code nog wat ze vroeger deed (los van het feit of dit wenselijk is, want zelfs de business case kan soms te verouderd zijn in geval van Legacy)? Bij redelijk nieuwe projecten zullen er reeds heel wat testen bestaan die we kunnen uitvoeren om de correctheid na te gaan, maar bij legacy hebben we vaak het probleem dat de toepassing eenvoudigweg wordt getest in productie, of op zijn minst met productiedata: er zijn geen specifieke tests of zelfs maar veilig bruikbare testdata. In dat geval komt het erop neer een omgeving te creëren waarin we de nieuwe code op een veilige manier kunnen testen, wat meestal ad hoc werk is en enige creativiteit vraagt. We mogen namelijk geen productiedata naar de Cloud sturen, dus we moeten ervoor zorgen dat het LLM deze niet kan lezen. Het zou eenvoudiger zijn als we lokaal draaiende LLMs zouden kunnen gebruiken, maar voorlopig zijn deze nog niet krachtig genoeg (als ze al beschikbaar zijn) om dergelijke complexe taken uit te voeren met legacy code.

Een andere uitdaging is de gebruikersinterface: bij oudere projecten is deze vaak achterhaald en moet er, vanaf de grond, een nieuwe GUI (Graphical User Interface) worden opgebouwd. Dat geeft echter het probleem dat je geen basis meer hebt in het oude project om mee te vergelijken: de nieuwe interface zal doorgaans manueel door mensen moeten worden getest. Ik verwacht echter dat we op dit vlak nog vorderingen zullen zien in de nabije toekomst, wat de mogelijkheden van het AI betreft. We zien namelijk al systemen opduiken die je volledige computer kunnen besturen (zoals OpenClaw of het “Computer Use” van Anthropic), en ook integratie met meer traditionele raamwerken voor het testen van een GUI behoort tot de mogelijkheden.

Waar we, ten slotte, ook quick wins mee kunnen halen, zijn kleinere Legacy projecten. Als we een klein tot matig groot legacy programma gebruiken, met beperkte functionaliteit en een eenvoudige GUI of een duidelijke input en output in geval van batch processing, en geen business case om deze te integreren in een andere manier van werken, dan kunnen we een rechttoe rechtaan aanpak proberen om een moderne versie in een nieuwe programmeertaal te bouwen met AI. We moeten dan nog altijd goed testen en een gestructureerde aanpak hebben met bijsturingen door menselijke developers, maar het wordt wel feasible om dit voor niet-kritische toepassingen te gaan uitproberen. Een intern gebruikte toepassing is bijvoorbeeld een typische goede eerste kandidaat.

Documenteren van Legacy Code

Soms is herschrijven van Legacy met AI net iets te ambitieus, óf we hebben meer informatie nodig voor we er ons aan wagen. In dat geval kan het interessant zijn om eerst richting documentatie te kijken: het AI kan ons ook helpen om het verkennen van een legacy codebase net iets minder op archeologie voor gevorderden te doen lijken.

Van een klein tot matig stuk code uitleggen en er de business logica uithalen, of een groter stuk analyseren en de opbouw en architectuur uitleggen: dat kan met de huidige grote taalmodellen zonder meer. We kunnen echter verder gaan: we kunnen het AI tools laten bouwen om zichzelf te helpen de codebase te verkennen, en b.v. diagrammen te voorzien van de afhankelijkheden tussen de stukken code. Of we kunnen het scripts laten maken om de bevindingen na elk stuk analyse netjes te structureren in een tekstbestand voor zichzelf en een pdf voor de menselijke gebruiker.

We kunnen ook hiërarchisch werken: eerst een verkenning van de codebase doen, en dan telkens dieper duiken in de verschillende modules, om meer en meer detail te verkrijgen en de analyse aan te vullen. Dat is de top-down aanpak, die we echter kunnen aanvullen met een bottom-up versie: eens we tot in de diepte zijn gegaan, kunnen we weer zaken laten samenvatten om van het grotere plaatje een beter geïnformeerde uiteenzetting op te bouwen.

Hier is het wel van belang dat we van tevoren weten wat we precies willen bereiken. Een algemene analyse van een codebase door het AI kan interessant zijn wanneer de menselijke gebruikers het systeem nog totaal niet kennen en aanknopingspunten willen hebben om zaken te leren, maar biedt meestal weinig extra aan mensen die de codebase reeds beheersen.

Maar wanneer het doel is om de codebase te kunnen onderhouden, kunnen we eventueel een systeem opbouwen waarbij we een chatbot aanbieden die de specifieke context en bijzonderheden van het legacy project kent, en daar heel gerichte vragen over kan beantwoorden. Dit kan b.v. in CoPilot Studio. Wanneer dat niet goed genoeg werkt, kunnen we nog overwegen om manueel een knowledge base op te bouwen, gebruik makend van het AI, die dan weer door het AI kan worden gebruikt om vragen te beantwoorden.

Nog een andere optie bestaat eruit dat we specifieke informatie uit de codebase willen extraheren, zoals de business logica per afzonderlijke module, of pseudocode die menselijke developers kan helpen om de logica in een ander project te herimplementeren. (En uiteraard kan bij die tweede stap ook weer een AI worden ingezet.)

Kortom, met een beetje creativiteit kunnen we voor de meeste ad hoc analyses een betere aanpak verzinnen dan “analyseer er maar gewoon op los”. En het documenteren van een legacy systeem kan ook gewoon een eerste opstap zijn naar het herschrijven.

Besluit: vakmannen gevraagd

Zoals we hebben aangekaart, bieden LLMs ons stilaan erg krachtige mogelijkheden om onze Legacy Codebases aan te pakken, zéker wanneer we toegang hebben tot de grote en krachtige modellen die vandaag beschikbaar zijn. We zien echter ook dat het eigenlijk een heel goed gevulde gereedschapskoffer is, met een aantal krachtige “power tools”, en dat we moeten weten wat we ermee willen bereiken en hoe we deze best kunnen gebruiken.

We zitten nog niet op het punt dat alles automatisch gaat: we zullen dus nog steeds goede vakmannen nodig hebben om optimaal van dit gereedschap gebruik te maken. Onze raad aan developers is om zeker niet bang te zijn van AI en er geregeld gebruik van te maken bij de analyse en ontwikkeling van software: ervaring is de beste leerschool om de goede vakmannen die we hiervoor nodig hebben, op te leiden.

Voorlopig is dus het besluit: voor legacy code is AI geen wondermiddel, maar een handige gereedschapskist die je best kan uitproberen als deel van een bredere aanpak. Zoals gezegd kijken we later dit jaar eerder naar het midden en de rechterkant van het spectrum van legacy. Wij vermoeden dat hier meer mogelijkheden zijn tot automatisering van een aantal workflows, zeker als we ook dieper gebruik gaan maken van agents. Mogelijks kunnen we, voor iets eenvoudigere en repetitievere projecten, dus toch van “vakman” naar “fabriek” evolueren.

We hebben waarschijnlijk het moment bereikt waarop de hype over AI op zijn grootst is: men is langs één kant laaiend enthousiast over AI, maar hier en daar raken mensen al gedesillusioneerd. Ook spreekt men meer en meer over een bubbel in de markt van de grote tech-spelers. Maar hoe nuttig zijn LLMs momenteel nu echt? Kunnen we nog veel verbetering verwachten? En hoe zit dat met die hallucinaties?

Waarschijnlijk heb je het zelf al meegemaakt: je praat met ChatGPT of een andere slimme chatbot, en deze vertelt je vol vertrouwen iets waarvan je weet dat het niet klopt. Of je bent een developer, en die coding assistant werkt best wel goed, tot je naar wat meer verlangt, maar die nieuw toegevoegde feature aan je programma hopeloos tekort schiet. En dat zijn nog maar je eigen, bescheiden, ervaringen: wat je hoort van anderen, of op het nieuws of via sociale media, is allicht nog veel extremer: vreugdekreten over hoe we, dankzij AI, een volgende industriële revolutie tegemoet gaan en doemberichten dat mensen hun job erdoor zullen verliezen, versus artikels die vertellen over hoe AI projecten maar blijven mislukken en verhalen over wat voor belachelijke of zelfs gevaarlijke hallucinaties uit de AI chatbots blijven komen. Dus wat moet je er nu van denken?

Om dit enigszins beter te begrijpen: een heel kort, niet te technisch, intermezzo over wat LLMs alweer zijn (mijn excuses dat ik daarbij opzettelijk vaag blijf: voor een betere uitleg raad ik de blogposts van mijn collega’s aan): AI taalmodellen doen voorspellingen over wat het volgende stukje tekst moet zijn, aan de hand van probabiliteiten. Ze zijn getraind op zó veel tekst, dat de in se willekeurige zinnen die eruit rollen, daardoor van een hoge kwaliteit zijn en perfect juist klinken (en het vaak genoeg ook zijn). Echt nadenken zoals een mens doen ze dus niet; het is heel erg “text based”. Het is meer het vinden en herhalen van patronen, dan écht begrip; de intelligentie erin ontstaat als emergent verschijnsel. De leukste naam die ik er al voor gehoord heb is “probabilistische papegaai“.

Volgens Gartner zitten we nu al voorbij de piek van opgeblazen verwachtingen en in de trog van desillusie. Ook andere verslaggevers spreken van een hype of bubbel. Er worden ettelijke miljarden geïnvesteerd in nieuwe datacenters om de AI-machine te voeden, soms zelfs met inbegrip van nieuwe energiecentrales, terwijl de winstgevendheid voorlopig nog ver te zoeken is. Is het effectief een bubbel? Dat hangt af van je definitie van bubbel… Het lijkt in elk geval een grote, soms geostrategische gok, op de volgende technologie die de wereld drastisch kan veranderen en verbeteren, of zelfs veroveren; misschien zelfs vernietigen… En op moment van schrijven deinzen sommigen er niet van terug om te zeggen dat de luchtbel weldra zal barsten, met als belangrijkste argumenten de circulaire investeringen van een aantal grote bedrijven in elkaars capaciteit, en het openstellen van ChatGPT voor erotische inhoud, een zet die meer op cashflow-druk dan op ruimdenkendheid lijkt te duiden.

Bijkomend probleem is dat momenteel ook de investeringen in LLM de wind wegnemen uit de zeilen van een aantal andere zeer nuttige AI-technologieën (maar wanneer de storm is gaan liggen kunnen de datacenters misschien wel van pas komen voor deze laatste). Stemmen gaan trouwens op dat we voor échte intelligentie nóg een andere AI technologie zullen moeten ontwikkelen (al zal het uiteindelijk wel iets zijn dat gebruik maakt van alle rekenkracht die we nu uitrollen), en dat LLMs stilaan op hun limieten botsen, met steeds kleiner wordende incrementele verbeteringen (en opgeklopte testresultaten). Ondanks de bittere les dat meer data en rekenkracht de grootste vooruitgang mogelijk hebben gemaakt, gaan er nu stemmen op dat men met LLMs geen Artificial General Intelligence (AGI) zal kunnen bouwen; men zal nieuwe research moeten aanboren. En ondertussen kan men ook aantonen dat de hallucinaties er gewoon bij horen en allicht nooit volledig weg te krijgen zullen zijn: onkruid vergaat niet.

Maar in een tuin waar onkruid groeit, kan men toch ook goede dingen laten groeien, met wat moeite. En in zo’n tuin hebben LLMs wel degelijk hun nut: daar waar een taak vooral gaat over tekst en taal, zijn ze bijvoorbeeld heel krachtig (denk aan samenvatten, vertalen, zaken verzinnen, zeer eenvoudige redeneringen opbouwen, …). En ook voor programmeren (wat een soort omgaan met een specifiek soort taal is), merken we enthousiasme van vele developers die hun productiviteit zagen stijgen (maar security blijft een aandachtspunt!). Als algemene slimme assistent kan het ook een rol spelen, zolang de gebruiker zelf voldoende onderlegd is in een onderwerp en kritisch is ingesteld. En misschien moeten ze gewoon nog verder evolueren tot de beste tool voor een bepaalde niche van taken.

Ook zelf heb ik een genuanceerd verhaal te vertellen: in mijn vorige blogpost had ik het over een aantal kleine successen met vibe coding, en de beperkingen van het AI, wanneer de taken groter of complexer worden. Hetzelfde zie ik in het werk dat ik sindsdien heb verricht: het analyseren en vertalen van legacy code met behulp van deze taalmodellen. Ook daar dus een gemengd succes: geen toverstokjes, nauwelijks of moeilijk te automatiseren, maar toch een zichtbare tijdswinst bij het begrijpen van middelmatig grote en het herschrijven van kleine stukken code van dit soort projecten (meer details daarover in een komende blogpost).

Conclusie

Een LLM is slechts één van de vele intelligente technologieën die we momenteel aan onze vingertippen hebben, al zij het wel de meest toegankelijke en zichtbare. Misschien vandaar zowel de hype als de controverse?

Zijn LLMs nuttig? Ik zou durven argumenteren van wel. Met de huidige stand van de technologie is het echter van groot belang dit te nuanceren: zet een LLM als powertool ter beschikking van een menselijke expert! De echte waarde ligt dus niet in vervanging, maar in augmentatie. Laten we het komende jaar kijken of alle agent-based systemen hier verandering in brengen…

Nous avons probablement atteint le point culminant du battage médiatique autour de l’IA : d’un côté, l’IA suscite l’enthousiasme, de l’autre, elle commence déjà à créer la désillusion. On parle aussi de plus en plus d’une bulle sur le marché des grands acteurs technologiques. Mais quelle est réellement l’utilité des LLM à l’heure actuelle ? Pouvons-nous encore espérer de nombreuses améliorations ? Et qu’en est-il des hallucinations ?

Vous avez probablement déjà vécu cette situation : vous discutez avec ChatGPT ou un autre robot conversationnel « intelligent » et celui-ci produit sans détour une affirmation que vous savez fausse. Ou vous êtes développeur et votre assistant de codage fonctionne plutôt bien, jusqu’à ce que vous en demandiez plus, mais la nouvelle fonctionnalité ajoutée à votre programme est loin d’être à la hauteur. Et ce ne sont là que vos propres expériences, modestes. En effet, les expériences relatées par les autres ou celles relayées dans la presse ou sur les réseaux sociaux sont sans doute bien plus extrêmes : d’un côté, des cris de joie à l’idée que l’IA amorce une nouvelle révolution industrielle et des messages alarmistes selon lesquels elle entraînera des pertes d’emploi, de l’autre, des articles qui disent que les projets d’IA ne cessent d’échouer et des récits sur les hallucinations ridicules, voire dangereuses que ne cessent de produire les robots conversationnels basés sur l’IA. Que faut-il dès lors en penser ?

Pour une meilleure compréhension, un bref intermède, pas trop technique, sur ce que sont les LLM (je vous prie de m’excuser de rester volontairement vague à ce sujet : pour une meilleure explication, je vous recommande les articles de blog de mes collègues) : les modèles de langage d’IA prédisent ce que doit être le prochain morceau de texte, en se basant sur des probabilités. Ils ont été entraînés sur une telle quantité de texte que les phrases aléatoires qu’ils produisent sont de grande qualité et semblent parfaitement cohérentes (et le sont souvent). Ils ne réfléchissent donc pas comme un être humain : leur fonctionnement est très “basé sur le texte”. Il s’agit davantage de trouver et de répéter des modèles que de faire preuve d’une véritable compréhension ; l’intelligence qui s’en dégage est un phénomène émergent. Le nom le plus cocasse que j’ai entendu jusqu’à présent est “perroquet stochastique“.

Selon Gartner, nous avons déjà dépassé le pic des attentes déraisonnables et nous sommes désormais dans la phase de désillusion. D’autres journalistes parlent d’un effet de mode ou d’une bulle.
Des milliards sont investis dans de nouveaux centres de données pour alimenter la machine IA, parfois même avec de nouvelles centrales électriques, alors que la rentabilité est encore loin d’être atteinte. S’agit-il réellement d’une bulle ? Tout dépend de votre définition d’une bulle… En tout cas, cela ressemble à un pari énorme, parfois géostratégique, sur la prochaine technologie qui pourrait changer et améliorer radicalement le monde, voire le conquérir, voire le détruire… Tandis que j’écris ces lignes, certains n’hésitent pas à affirmer que la bulle est sur le point d’éclater, avec comme principaux arguments les investissements circulaires d’un certain nombre de grandes entreprises dans leurs capacités respectives et l’ouverture de ChatGPT au contenu érotique, une décision qui semble davantage refléter une pression sur les flux de trésorerie qu’une ouverture d’esprit.

Un autre problème réside dans le fait qu’actuellement, les investissements dans les LLM freinent également le développement d’un certain nombre d’autres technologies d’IA très utiles (mais lorsque la tempête se sera calmée, les centres de données pourraient bien s’avérer utiles pour ces dernières). Certains pensent d’ailleurs que pour obtenir une véritable intelligence, nous devrons développer une autre technologie d’IA (même si, au final, celle-ci utilisera toute la puissance de calcul que nous déployons actuellement ), et que les LLM atteignent peu à peu leurs limites, avec des améliorations incrémentielles de plus en plus faibles (et des résultats de tests gonflés). Malgré la leçon amère que davantage de données et de puissance de calcul ont permis les plus grands progrès, des voix s’élèvent maintenant pour dire qu’on ne pourra pas construire une Intelligence Artificielle Générale (AGI) avec les LLM ; il faudra se tourner vers de nouvelles recherches. Et entre-temps, on peut aussi démontrer que les hallucinations en font tout simplement partie et qu’elles ne disparaîtront probablement jamais complètement : les mauvaises herbes ne disparaissent jamais.

Mais dans un jardin envahi par les mauvaises herbes, de belles plantations sont tout de même possibles, moyennant quelques efforts. Et dans un tel jardin, les LLM ont bel et bien leur utilité : lorsqu’une tâche concerne principalement le texte et le langage, ils sont par exemple très performants (pensez au résumé, à la traduction, à la création, à la construction de raisonnements très simples…). Et même pour la programmation (qui est une sorte de manipulation d’un langage spécifique), nous constatons l’enthousiasme de nombreux développeurs qui ont vu leur productivité augmenter (mais la sécurité demeure un point d’attention !). En tant qu’assistant intelligent général, les LLM peuvent également jouer un rôle, à condition que l’utilisateur soit suffisamment informé sur un sujet et ait l’esprit critique. Et peut-être doivent-ils simplement continuer à évoluer pour devenir le meilleur outil pour une certaine niche de tâches.

J’ai moi-même une histoire nuancée à raconter : dans mon précédent article de blog, j’ai évoqué quelques petits succès avec le vibe coding, ainsi que les limites de l’IA lorsque les tâches deviennent plus importantes ou plus complexes. Je constate la même chose dans le travail que j’ai effectué depuis : l’analyse et la traduction de code hérité à l’aide de ces modèles de langage. Là aussi, le succès est mitigé : pas de baguette magique, difficile voire impossible à automatiser, mais tout de même un gain de temps visible dans la compréhension des codes de taille moyenne et la réécriture des petits morceaux de code de ce type de projets (plus de détails à ce sujet dans un prochain article de blog).

Conclusion

Un LLM n’est qu’une des nombreuses technologies « intelligentes » disponibles actuellement, même s’il s’agit de la plus accessible et la plus visible. C’est peut-être ce qui explique à la fois l’engouement et la controverse qu’elle suscite.

Les LLM sont-ils utiles ? J’oserais dire que oui. Cependant, compte tenu de l’état actuel de la technologie, il est fondamental de nuancer cette affirmation : mettez un LLM à la disposition d’un expert humain en tant qu’outil puissant ! La véritable valeur ne réside donc pas dans le remplacement, mais dans l’augmentation. Nous verrons si tous les systèmes basés sur des agents changeront la donne au cours de l’année à venir.

Le monde de l’IA évolue à une vitesse vertigineuse et l’émergence du Retrieval-Augmented Generation (RAG) ouvre de nouvelles possibilités pour combiner intelligemment des données et des modèles de langage.

Les systèmes RAG combinent la capacité générative des LLM avec l’extraction d’informations pertinentes et actualisées dans des sources de données. Cela les rend plus puissants, mais aussi plus complexes, car ils dépendent de la qualité du modèle et des données utilisées, et sont susceptibles de diffuser des informations obsolètes, incorrectes ou inappropriées.

Dans un précédent article de blog, nous avons expliqué comment les évaluations automatiques peuvent aider à mesurer la qualité d’un système RAG et à l’améliorer de manière interactive. Mais la qualité seule ne suffit pas. Pour que les systèmes d’IA fonctionnent non seulement correctement, mais aussi de manière sûre et responsable, des garde-fous s’imposent. Par garde-fous, nous entendons les directives, les restrictions techniques et les cadres éthiques qui garantissent que les systèmes d’IA opèrent dans des limites acceptables. Ils empêchent un résultat indésirable ou préjudiciable et assurent la conformité des systèmes d’IA avec les valeurs humaines et les normes sociales.

Que sont exactement ces garde-fous et comment les utiliser efficacement ? C’est ce que nous allons explorer dans cet article.

La nécessité des garde-fous

Les applications basées sur des LLM comportent divers risques qui soulignent la nécessité de garde-fous solides. Sans protection adéquate, les instructions du système peuvent être dérobées. Celles-ci donnent un aperçu de la logique interne et des mécanismes de sécurité, que vous préférez ne pas voir divulgués. Il existe également un risque d’atteinte à la vie privée lorsque des données à caractère personnel parviennent à des fournisseurs de modèles externes. En outre, les modèles peuvent générer des réponses préjudiciables, allant de propos haineux à des conseils d’automutilation, ou des informations incorrectes en raison d’un résultat hallucinatoire. Les questions hors sujet peuvent entraîner une utilisation abusive de l’application et augmenter les coûts, tandis que des réponses inappropriées ou non conformes peuvent nuire à la réputation.

Pour toutes ces raisons, il est essentiel de mettre en place des mécanismes de sécurité solides, car ils constituent un rempart contre ces risques divers et contribuent à la sûreté et à la fiabilité des applications d’IA ainsi qu’à leur conformité avec les attentes des utilisateurs et des organisations.

Méthodes et techniques

Les garde-fous sont généralement déployés à deux niveaux : juste avant que les données d’entrée ne soient envoyées au modèle de langage (filtre à l’entrée) ou juste après la génération des résultats en sortie, mais avant qu’elle ne parvienne à l’utilisateur final (filtre à la sortie).

Garde-fous d’entrée et de sortie – source : https://github.com/guardrails-ai/guardrails

Il existe globalement quatre techniques pour concrètement mettre en œuvre les garde-fous.

• Les garde-fous natifs LLM sont des mécanismes de sécurité intégrés dans les services proposés par les fournisseurs des modèles eux-mêmes, celui inclut par exemple le filtrage des résultats préjudiciables ou l’exclusion de certaines instructions. Ils constituent une première ligne de défense, et doivent généralement être complétés par une ou plusieurs des techniques ci-dessous.
• Dans le cas des garde-fous basés sur le prompt, des instructions spécifiques sont ajoutées au prompt afin d’influencer le comportement du modèle. Un exemple typique consiste à obliger le modèle à répondre exclusivement sur la base des informations contextuelles fournies (via RAG) afin qu’il ne génère pas de résultats incontrôlés ou indésirables. Un autre exemple consiste à ajouter des instructions pour éviter que le système d’IA ne donne des conseils médicaux. L’exemple ci-dessous montre les instructions ajoutées au prompt pour éviter que l’application ne donne des conseils médicaux, avec un exemple de conversation dans laquelle l’application produit la réponse souhaitée.

• Les garde-fous basés sur des règles agissent de manière déterministe avec des filtres basés sur des mots exacts ou des expressions régulières. Ils permettent d’effectuer un screening sur certains mots ou sujets et de filtrer des formes simples d’informations confidentielles, telles que des identifiants, des numéros de téléphone ou des adresses e-mail.
• Les garde-fous basés sur le ML/LLM utilisent des modèles de machine learning ou des LLM-judges qui sont beaucoup plus aptes à gérer les nuances, l’intention et le contexte. Ils peuvent évaluer à la fois les entrées et les sorties et les classer, par exemple pour détecter les contenus préjudiciables ou les prompt injections (tentatives des utilisateurs de manipuler le comportement de l’application via le prompt). En outre, ils peuvent filtrer les informations sensibles et vérifier les faits en s’assurant que toutes les affirmations générées en sortie sont étayées par le contexte fourni, comme dans le cas de la RAG.

Chaque technique a son utilité, sa complexité et son coût. Aussi est-il recommandé d’évaluer d’abord les risques spécifiques à un cas d’utilisation particulier, puis de déterminer les garde-fous réellement nécessaires. Commencez par les méthodes les plus simples (basées sur un prompt et des règles) et ne passez à des techniques plus complexes (basées sur le ML/LLM) que lorsque cela est nécessaire. Ces dernières entraînent en effet une latence et des coûts supplémentaires.

Outils

Il existe de nombreux outils qui prennent en charge ces techniques et facilitent l’intégration de garde-fous dans une application. Les frameworks procurent un environnement complet pour définir, combiner et orchestrer des garde-fous. Ils vous permettent de configurer des règles, des workflows et des étapes de validation sans devoir tout construire vous-même. Exemples : Guardrails AI, LLM Guard et NVIDIA NeMo Guardrails.

Il existe également des API et des services qui offrent des fonctionnalités spécifiques, telles que la détection des contenus préjudiciables, le filtrage des données sensibles ou la détection des jailbreaks. Vous pouvez les appeler directement depuis votre application. Nous pouvons citer Azure AI Content Safety ou OpenAI Moderation API.

Sous le capot, ces outils utilisent une combinaison de modèles ML, de LLM-judges et de techniques basées sur des règles. Llama Guard et Prompt Guard sont des exemples de modèles ML.

Notre propre expérience montre que certains outils de protection sont nettement moins précis en néerlandais et en français qu’en anglais. Nous constatons parfois des faux positifs, par exemple lorsque la détection d’automutilation identifie à tort des phrases inoffensives comme risquées. Pour les applications simples présentant un faible profil de risque et utilisant exclusivement des données publiques, la valeur ajoutée des outils de protection supplémentaires semble limitée. Dans de tels cas, les mécanismes de sécurité intégrés au LLM, associés à un prompt RAG bien conçu, sont généralement suffisants.

Conclusion

En résumé, il est important de toujours utiliser les garde-fous de manière ciblée et stratifiée. Commencez par identifier les risques dans le cas d’utilisation spécifique, puis choisissez les techniques appropriées, en privilégiant les méthodes simples et en n’ajoutant des solutions plus complexes que lorsque cela est vraiment nécessaire. Bien qu’une combinaison de garde-fous natifs LLM, basés sur des prompts, basés sur des règles et basés sur le ML/LLM offre une protection plus robuste, il reste essentiel de comprendre qu’aucun système ne garantit une sécurité absolue. Les filtres à l’entrée et à la sortie peuvent produire à la fois des faux positifs et des faux négatifs. De plus, les garde-fous basés sur le ML/LLM occasionnent des coûts et une latence supplémentaires. Un monitoring continu de l’application d’IA est recommandé afin de détecter et de traiter rapidement les nouvelles vulnérabilités.

De wereld van AI evolueert razendsnel, en met de opkomst van Retrieval-Augmented Generation (RAG) openen zich nieuwe mogelijkheden om data en taalmodellen slim te combineren.

RAG-systemen combineren het generatieve vermogen van LLM’s met het ophalen van relevante, actuele informatie uit databronnen. Dit maakt ze krachtiger, maar ook complexer: ze zijn afhankelijk van de kwaliteit van zowel het model als de gebruikte data, en lopen risico op het verspreiden van verouderde, onjuiste of ongepaste informatie.

In een vorige blogpost bespraken we hoe automatische evaluaties kunnen helpen om de kwaliteit te meten van een RAG-systeem en het interatief te verbeteren. Maar kwaliteit alleen is niet genoeg. Om AI-systemen niet alleen goed te laten functioneren, maar ook veilig en verantwoord, zijn guardrails nodig. Onder guardrails verstaan we de richtlijnen, technische beperkingen en ethische kaders die ervoor zorgen dat AI-systemen binnen aanvaardbare grenzen opereren. Ze voorkomen ongewenste of schadelijke output en zorgen ervoor dat AI-systemen aansluiten bij menselijke waarden en maatschappelijke normen.

Wat zijn die guardrails precies en hoe zet je ze effectief in? Dat verkennen we in deze blogpost.

De nood aan guardrails

LLM-gebaseerde toepassingen brengen verschillende risico’s met zich mee die de nood aan sterke guardrails duidelijk maken. Zonder passende bescherming kunnen de systeeminstructies ontfutseld worden. Die geven inzicht in interne logica en beveiligingsmechanismen, en die zie je dus liever niet onthuld. Ook bestaat het risico op privacy­schendingen wanneer persoonlijke gegevens bij externe modelproviders terechtkomen. Daarnaast kunnen modellen schadelijke antwoorden genereren, variërend van haatspraak tot zelfbeschadigingsadviezen, of incorrecte informatie door hallucinerende output. Off-topic vragen kunnen leiden tot misbruik van de toepassing en de kosten doen oplopen, terwijl ongepaste of niet-conforme antwoorden reputatieschade kunnen veroorzaken.

Om al deze redenen zijn robuuste guardrails essentieel, omdat ze een buffer vormen tegen deze uiteenlopende risico’s en helpen garanderen dat AI-toepassingen veilig, betrouwbaar en conform de verwachtingen van gebruikers en organisaties functioneren.

Methodes en technieken

Guardrails worden doorgaans op twee niveaus ingezet: vlak vóór de input het taalmodel bereikt (inputfilter), of net na het genereren van de output maar vóór die bij de eindgebruiker terechtkomt (outputfilter).

Input & output guardrails – bron: https://github.com/guardrails-ai/guardrails

In grote lijnen bestaan er vier technieken om guardrails concreet te implementeren.

• LLM-native guardrails zijn ingebouwde veiligheidsmechanismen die modelproviders zelf voorzien, zoals het vermijden van schadelijke outputs of beperkingen bij het volgen van bepaalde instructies. Ze bieden een eerste verdedigingslinie, maar moeten doorgaans aangevuld worden met één of meerdere van de technieken hieronder.
• Bij prompt-gebaseerde guardrails worden specifieke instructies toegevoegd aan de prompt om het gedrag van het model te beïnvloeden. Een typisch voorbeeld is om het model te verplichten om uitsluitend te antwoorden op basis van aangeleverde contextinformatie (via RAG) zodat het geen ongecontroleerde of ongewenste output genereert. Een ander voorbeeld is het toevoegen van instructies om te vermijden dat het AI-systeem medisch advies geeft. In het voorbeeld hieronder zijn instructies te zien die toegevoegd worden aan de prompt om te vermijden dat de toepassing medisch advies geeft, samen met een voorbeeld van een conversatie waarbij de toepassing het gewenste antwoord geeft.
  

  

  
  
• Regelgebaseerde guardrails werken deterministisch met filters op basis van exacte woorden of reguliere expressies. Op die manier kan gescreend worden op bepaalde woorden of onderwerpen, en kunnen eenvoudige vormen van vertrouwelijke informatie gefilterd worden, zoals ID’s, telefoonnummers of e-mailadressen.
• LLM/ML-gebaseerde guardrails maken gebruik van machine learning modellen of zogenaamde LLM-judges die veel beter overweg kunnen met nuance, intentie en context. Ze kunnen zowel input als output beoordelen en kunnen deze classificeren, bijvoorbeeld om schadelijke inhoud of prompt injections te detecteren (dit zijn pogingen van gebruikers om het gedrag van de toepassing te manipuleren via de prompt). Daarnaast kunnen ze gevoelige informatie filteren en fact-checking uitvoeren door na te gaan of alle uitspraken in de output effectief worden ondersteund door de aangeleverde context, zoals bij RAG.

Elke techniek heeft een eigen nut, complexiteit en kost. Het is daarom aangeraden om eerst de specifieke risico’s voor een bepaalde usecase te evalueren en daarna te bepalen welke guardrails echt nodig zijn. Begin met de eenvoudigste methodes (prompt-gebaseerd en regelgebaseerd) en schakel pas over op complexere technieken (LLM/ML gebaseerd) wanneer dat noodzakelijk is. Deze laatste brengen namelijk extra latency en kosten met zich mee.

Guardrail tools

Er bestaan heel wat tools die deze technieken ondersteunen en het eenvoudiger maken om guardrails in een toepassing te integreren. Frameworks bieden een volledige omgeving om guardrails te definiëren, combineren en orkestreren. Ze laten je regels, workflows en validatiestappen configureren zonder alles zelf te moeten bouwen. Voorbeelden zijn Guardrails AI, LLM Guard en NVIDIA NeMo Guardrails.

Daarnaast zijn er API’s en services die specifieke functionaliteiten aanbieden, zoals het detecteren van schadelijke inhoud, het filteren van gevoelige gegevens of het opsporen van jailbreaks. Deze kun je rechtstreeks vanuit je toepassing aanroepen. Denk hierbij aan Azure AI Content Safety of OpenAI Moderation API.

Onder de motorkap maken deze tools gebruik van een mix van ML-modellen, LLM-judges en regelgebaseerde technieken. Voorbeelden van ML-modellen zijn Llama Guard en Prompt Guard.

Uit onze eigen ervaringen blijkt dat bepaalde guardrailtools merkbaar minder nauwkeurig presteren in het Nederlands en Frans ten opzichte van het Engels. We zien daarbij soms ook false positives, bijvoorbeeld wanneer selfharm-detectie onschadelijke zinnen foutief als risicovol markeert. Voor eenvoudige toepassingen met een laag risicoprofiel en uitsluitend publieke data lijkt de meerwaarde van extra guardrailtools beperkt. In zulke gevallen volstaan doorgaans de ingebouwde veiligheidsmechanismen van de LLM in combinatie met een goed ontworpen RAG-prompt.

Conclusie

Samengevat is het belangrijk om guardrails steeds risicogestuurd en gelaagd in te zetten. Begin met het identificeren van de risico’s binnen de specifieke usecase en kies vervolgens de passende technieken, waarbij eenvoudige methodes de voorkeur krijgen en complexere oplossingen pas worden toegevoegd wanneer dat echt nodig is. Hoewel een combinatie van LLM-native, prompt-gebaseerde, regelgebaseerde en ML/LLM-gebaseerde guardrails een robuustere bescherming biedt, blijft het essentieel om te beseffen dat geen enkel systeem volledige veiligheid garandeert. Input- en outputfilters kunnen zowel false positives als false negatives opleveren. ML/LLM-gebaseerde guardrails brengen bovendien extra kosten en latency met zich mee. Een continue monitoring van de AI-toepassing is aangeraden om nieuwe kwetsbaarheden tijdig op te sporen en aan te pakken.

De nombreuses organisations expérimentent actuellement l’IA générative. Dans ce cadre, elles utilisent souvent des applications qui fonctionnent sur des LLM (Large Language Models), soutenues par une architecture RAG (Retrieval-Augmented Generation). Cela signifie que le système extrait d’abord les informations pertinentes d’une source de connaissances pour les transmettre au modèle de langage en guise de contexte. Il en résulte un output solidement ancré dans le domaine de connaissances concerné. Dans le jargon, on parle de grounding. Cette approche est surtout populaire dans les applications de questions-réponses et les chatbots.

Malgré le grand potentiel de ces applications basées sur des LLM, l’output généré n’est pas toujours fiable dans la pratique. Des problèmes peuvent déjà survenir au niveau de l’extraction, si les informations pertinentes ne sont pas trouvées ou ne le sont que partiellement. Mais même si le bon contexte est fourni, un modèle de langage peut commettre des erreurs. Le modèle peut mal interpréter les informations, établir des liens incorrects ou générer des hallucinations, c’est-à-dire des réponses qui semblent convaincantes, mais qui sont en fait erronées. Cette incertitude quant à la qualité constitue l’un des principaux obstacles à la mise en production de telles applications, en particulier dans les domaines où la fiabilité est essentielle.

Dans cet article, nous nous pencherons sur les méthodes d’évaluation de la qualité des applications basées sur la RAG.

Évaluations manuelles et automatiques

Évaluer des applications d’IA générative est tout sauf simple. Cela s’explique principalement par le fait que l’output est souvent non structuré et non déterministe, à savoir qu’un même input peut chaque fois produire un output différent. De plus, il existe rarement une seule bonne réponse, de sorte qu’il est difficile d’évaluer objectivement la qualité de l’output généré. Beaucoup dépend de critères subjectifs comme la pertinence ou la précision, qui peuvent varier d’un évaluateur à l’autre. 

La manière la plus évidente de contrôler la qualité est manuelle. Elle consiste à exécuter manuellement un certain nombre de tests, à mesurer le résultat et éventuellement à ajouter un commentaire indiquant la cause d’une qualité moindre. Une personne disposant des connaissances nécessaires dans le domaine peut correctement effectuer une telle évaluation, mais celle-ci est chronophage et peu extensible.

Pour ces raisons, il peut être intéressant de se tourner vers des systèmes d’évaluation automatique, appelés “auto-evals“. Comme ces évaluations s’effectuent automatiquement, elles sont aisément extensibles. Des techniques telles que “exact-string matching” et “regular expressions” peuvent être mises en œuvre pour le matching exact d’un texte ou d’un schéma. Mais si l’output d’un LLM peut varier en termes de choix de mots, de séquence ou de longueur, par exemple lorsque plusieurs formulations sont correctes, ces méthodes échouent. Dans ces cas, une évaluation sémantique ou basée sur un modèle s’impose. Une technique qui suscite actuellement beaucoup d’intérêt s’appelle “LLM-as-judge“. Elle consiste à faire évaluer l’output par un (second) modèle de langage selon certains critères.

LLM-as-judge : un LLM évalué par un LLM

À première vue, l’intervention d’un modèle de langage pour évaluer l’output d’un autre modèle de langage peut sembler étrange. Cependant, il s’avère plus facile de critiquer un output que de générer l’output original : même pour les LLM, il est plus facile de détecter les erreurs a posteriori que de les éviter.

Un LLM désigné comme juge peut évaluer plusieurs aspects, tels que l’exactitude factuelle, l’exhaustivité, les hallucinations et la pertinence de l’output par rapport à la question. Cette évaluation peut se faire par rapport à une référence (basée sur une référence) ou non (sans référence). Ainsi, pendant la phase de développement, une batterie de tests peut être prévue avec des questions, complétées de réponses de référence : un expert du domaine peut fournir des réponses correctes à titre de référence. Dans un environnement de production, il est toutefois impossible de prévoir une réponse de référence pour chaque question possible. Dans la pratique, il faut dès lors se rabattre sur des évaluations sans référence.

Nous avons concrètement mis en œuvre quelques métriques LLM-as-judge issues de la boîte à outils OpenEvals de LangChain, appliquées à un système de questions-réponses basé sur des LLM. L’approche est la suivante :

• Élaboration d’une batterie de tests – Dans un premier temps, une batterie de tests est élaborée avec des questions représentatives de la base de connaissances concernée. Une réponse de référence est prévue pour chacune des questions.
• Génération des réponses – Ensuite, le système de questions-réponses génère une réponse pour chacune des questions de la batterie de tests.
• Évaluation manuelle – Afin de vérifier l’efficacité d’un LLM-as-judge automatique, on procède d’abord à une évaluation manuelle : chaque réponse générée se voit attribuer un score de 0 (réponse incorrecte), 1 (réponse partiellement correcte / incomplète) ou 2 (réponse correcte et complète).
• Exécution des évaluations – Au cours de cette étape, on produit un script qui évalue tous les cas de test au regard d’une certaine métrique. On utilise comme métrique l’évaluateur de correctness (“exactitude” en français) proposé par défaut dans la bibliothèque OpenEvals.
  Celui-ci mesure le degré d’exactitude d’une réponse générée par rapport à la réponse de référence. En output, on obtient pour chaque réponse générée un score binaire (true = correct ; false = incorrect) et une motivation textuelle du score, par exemple :

  Question : À partir de quel âge puis-je travailler comme étudiant?
  Réponse générée : Tu peux t’engager comme jobiste dès que tu as 15 ans et que tu as suivi le premier degré de l’enseignement secondaire, ou dès que tu as 16 ans.
  Réponse de référence : Vous pouvez travailler comme étudiant dès que vous avez 16 ans ou si vous avez 15 ans et avez suivi les deux premières années de l’enseignement secondaire.
  Score : true
  Motivation : The provided answer states that a student can work at 15 years old if they have completed the first cycle (“premier degré”) of secondary education, equivalent to the two first years of secondary education mentioned in the reference. It also notes that one can work at 16 years old. This information is factually accurate, complete, and addresses the question using precise terminology. Thus, the score should be: true.

Alignement des évaluations automatiques et manuelles

Si l’on compare les résultats de cet évaluateur d’exactitude avec les scores manuels, on constate dans notre test que le score LLM-as-judge est identique au score manuel dans 70 % des cas. Cela veut donc dire que les deux scores ne correspondent pas dans de nombreux cas. Cela s’explique par plusieurs raisons :

• Évaluations subjectives – Les évaluations manuelles sont subjectives. Ainsi, les réponses incomplètes sont évaluées de manière plus ou moins stricte selon l’évaluateur.
• Qualité des réponses de référence – La qualité des réponses de référence livrées par un expert du domaine joue un rôle important, car elle sert de référence. Elles doivent être complètes et clairement formulées.
• Méthode d’évaluation : l’évaluation manuelle repose sur trois scores (2 = correct, 1 = incomplet, 0 = incorrect). L’évaluateur d’exactitude testé utilise deux scores par défaut (true ou false). Il lui manque la nuance nécessaire pour attribuer, à une réponse correcte mais incomplète, un score qui soit tout de même positif dans une certaine mesure.
• Modèle de langage – Enfin, le modèle de langage utilisé par le LLM-as-judge joue également un rôle. Un reasoning model sera mieux à même de procéder à une bonne évaluation qu’un modèle de chat moins performant.

Dans le cas idéal, un évaluateur automatique juge de la même manière qu’un évaluateur humain, mais dans la pratique, il s’avère difficile d’aligner correctement les scores des évaluations automatiques sur ceux des évaluations manuelles.

Pour améliorer cet alignement, le LLM-as-judge peut être amélioré de manière itérative, par exemple par l’adaptation du prompt (instructions, méthode d’évaluation). En fait, le recours à un LLM en tant qu’évaluateur est en soi également un projet LLM dont la qualité doit être évaluée et peut être améliorée de manière itérative. Tout l’art consistera à commencer simplement et à améliorer progressivement la qualité de l’évaluateur. Dans tous les cas, la motivation textuelle de l’évaluateur d’exactitude peut être précieuse pour évaluer les réponses générées.

Quelles métriques utiliser ?

Dans la phase de développement, on dispose souvent de réponses de référence, ce qui nous permet de recourir à un évaluateur de correctness qui détermine simplement dans quelle mesure la réponse générée correspond à la réponse de référence. Des métriques complémentaires peuvent fournir des informations sur d’autres aspects de la RAG, comme la context precision, qui détermine quelle partie des chunks est pertinente, et le context recall, qui détermine combien de chunks pertinents ont été fournis. Dans l’illustration ci-dessous, ces métriques basées sur des références sont indiquées en jaune.

Lorsque de telles métriques sont nécessaires mais qu’aucune référence explicite n’est disponible, on peut recourir à des variantes approximatives (voir les métriques indiquées en bleu dans l’illustration ci-dessus) : par exemple, un LLM-as-judge qui compare la réponse générée au contexte extrait et restitue un score sémantique “close-enough”. Dans un environnement de production, les réponses de référence font presque toujours défaut ; l’accent est alors mis sur des métriques telles que l’hallucination detection ou la groundedness, qui déterminent si chaque affirmation dans l’output est réellement étayée par le contexte fourni. La qualité reste ainsi mesurable, même sans référence absolue. D’autres métriques approximatives sont la context relevance, qui évalue la correspondance sémantique des passages extraits à la question et peuvent donc servir de base à la génération, et l’answer relevance (helpfulness), qui évalue la correspondance de la réponse finale à la question.

Conclusion

L’IA générative est aujourd’hui en pleine effervescence, mais pour les organisations, la fiabilité de l’output figure parmi les critères majeurs pour pouvoir utiliser cette technologie en toute confiance. Dans un pipeline RAG, l’output généré est basé sur des connaissances du domaine, mais sans cadre d’évaluation robuste, sa qualité n’est pas suffisamment garantie. Il est donc important de miser sur la mesurabilité.

Commencez la phase de développement avec une batterie de tests compacte et représentative et des réponses de référence claires. Des métriques basées sur des références peuvent ensuite être appliquées, telles que la correctness, afin d’identifier rapidement les points sensibles. Une fois en production, vous pouvez passer à des métriques sans référence, telles que la groundedness et l’hallucination detection, afin de pouvoir également monitorer les questions inconnues.

Les évaluations automatiques basées sur le LLM‑as‑judge ne sont pas une solution miracle. Leur principal défi réside dans l’alignement : s’assurer que les scores automatiques correspondent autant que possible à l’avis des experts du domaine. Elles offrent néanmoins échelle et continuité : elles peuvent passer en revue de grands volumes d’output, signaler d’éventuels problèmes de qualité et procurer des points de référence objectifs pour ajuster de manière ciblée une application LLM ou RAG. La comparaison systématique de leur évaluation avec les évaluations manuelles et l’ajustement des prompts de l’évaluateur permettent d’améliorer continuellement l’application et l’évaluateur grâce à un processus itératif.

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

Heel wat organisaties zijn druk aan het experimenteren met generatieve AI. Vaak maken ze daarbij gebruik van toepassingen die draaien op LLM’s (Large Language Models), ondersteund door een RAG-architectuur (Retrieval-Augmented Generation). Dit betekent dat het systeem eerst relevante informatie uit een kennisbron ophaalt en die als context meegeeft aan het taalmodel. Zo ontstaat een output die stevig verankerd is in de juiste domeinkennis. In het jargon spreken we van grounding. Deze aanpak is vooral populair in vraag-en-antwoordtoepassingen en chatbots.

Hoewel het potentieel van dergelijke LLM-gebaseerde toepassingen groot is, blijkt de kwaliteit van de gegenereerde output in de praktijk niet altijd even betrouwbaar. Het kan al mislopen op niveau van de retrieval-stap, als de relevante informatie niet teruggevonden wordt of slechts gedeeltelijk. Maar zelfs als de juiste context wél wordt aangeleverd, kan een taalmodel alsnog fouten maken. Het model kan de informatie verkeerd interpreteren, onnauwkeurige verbanden leggen of hallucinaties genereren — antwoorden die overtuigend klinken, maar feitelijk onjuist zijn. Deze onzekerheid over de kwaliteit is één van de belangrijkste belemmeringen voor het in productie nemen van zulke toepassingen, zeker in domeinen waar betrouwbaarheid essentieel is.

In dit artikel gaan we dieper in op de methodes voor het evalueren van de kwaliteit van RAG-gebaseerde toepassingen.

Manuele & automatische evaluaties

Het evalueren van generatieve AI-toepassingen is allesbehalve eenvoudig. Dat komt vooral doordat de output vaak ongestructureerd is en niet-deterministisch: eenzelfde input kan telkens een andere output opleveren. Daarbovenop bestaat er zelden één juist antwoord, wat het moeilijk maakt om objectief te beoordelen of een gegenereerde output “goed” is. Veel hangt af van subjectieve criteria zoals relevantie of nauwkeurigheid, die per evaluator kunnen verschillen. 

De meest voor de hand liggende manier om de kwaliteit te controleren is manueel: handmatig een aantal testen uitvoeren, het resultaat inschalen en eventueel commentaar toevoegen met een indicatie van de oorzaak van minder goede kwaliteit. Iemand met de nodige domeinkennis kan zo’n evaluatie goed uitvoeren, maar het is tijdrovend en schaalt niet goed.

Om die redenen kan het interessant zijn om te kijken naar systemen voor automatische evaluaties, zogeheten “auto-evals”. Aangezien ze automatisch uitgevoerd worden, zijn ze goed te schalen. Technieken zoals exact-string matching en regular expressions kunnen gebruikt worden voor het exact matchen van tekst of het matchen van een patroon. Maar als de output van een LLM kan variëren in woordkeuze, volgorde of lengte, bijvoorbeeld in het geval van meerdere juiste formuleringen, lopen zo’n methodes vast. In die gevallen heb je semantische of model-gebaseerde evaluatie nodig. Een techniek die momenteel in de belangstelling staat is “LLM-as-judge”, waarbij een (tweede) taalmodel de gegenereerde output beoordeelt op bepaalde criteria.

LLM-as-judge: LLM beoordeelt LLM

Op het eerste zicht is het wat vreemd dat een taalmodel wordt ingeschakeld om de output van een taalmodel te beoordelen. Maar het blijkt eenvoudiger om kritiek te geven op een output dan om de originele output te genereren: zelfs voor LLM’s is het eenvoudiger om fouten achteraf te detecteren dan ze te voorkomen.

Er zijn een aantal aspecten die door een LLM-rechter kunnen beoordeeld worden, zoals feitelijke correctheid, volledigheid, hallucinaties en relevantie van de output ten opzichte van de vraag. Die beoordeling kan gebeuren ten opzichte van een referentie (referentie-gebaseerd) of niet (referentievrij). Zo kan in de ontwikkelfase een vaste testset voorzien worden van vragen, aangevuld met referentie-antwoorden: een domeinexpert kan correcte antwoorden aanleveren die gelden als een gouden standaard. Het is echter onmogelijk om in een productie-omgeving voor elke mogelijke vraag een referentie-antwoord te voorzien, waardoor je in de praktijk moet terugvallen op referentievrije evaluaties.

We gingen concreet aan de slag met enkele LLM-as-judge metrieken uit de OpenEvals toolbox van LangChain, toegepast op een LLM-gebaseerd vraag- en antwoordsysteem. Dit is de gevolgde aanpak:

• Opstellen testset – In een eerste stap wordt een testset opgesteld met vragen die representatief zijn voor de betrokken knowledge base. Voor elk van de vragen wordt een referentie-antwoord voorzien.
• Antwoordgeneratie – Vervolgens laten we voor elk van de vragen uit de testset een antwoord genereren door het vraag-antwoordsysteem.
• Manuele beoordeling – Om te kunnen nagaan hoe goed een automatische LLM-as-judge evaluator presteert, doen we eerst een manuele beoordeling: elk gegeneerd antwoord krijgt een score van 0 (fout antwoord), 1 (deels correct / onvolledig) of 2 (correct en volledig).
• Uitvoeren evaluaties – In deze stap voorzien we een script dat alle testcases beoordeelt op vlak van een bepaalde metriek. Als metriek gebruiken we de correctness evaluator die de OpenEvals library standaard aanbiedt. Deze meet hoe correct een gegenereerd antwoord is ten opzichte van het referentie-antwoord. Als output krijgen we voor elk gegenereerd antwoord een binaire score (true = correct; false = niet correct) en een tekstuele motivatie van de score, bijvoorbeeld:

  Vraag: A partir de quel âge puis-je travailler comme étudiant?
  Gegenereerd antwoord: Tu peux t’engager comme jobiste dès que tu as 15 ans et que tu as suivi le premier degré de l’enseignement secondaire, ou dès que tu as 16 ans.
  Referentie-antwoord: Vous pouvez travailler comme étudiant dès que vous avez 16 ans ou si vous avez 15 ans et avez suivi les deux premières années de l’enseignement secondaire.
  Score: true
  Motivatie: The provided answer states that a student can work at 15 years old if they have completed the first cycle (“premier degré”) of secondary education, equivalent to the two first years of secondary education mentioned in the reference. It also notes that one can work at 16 years old. This information is factually accurate, complete, and addresses the question using precise terminology. Thus, the score should be: true.

Alignering van automatische en manuele beoordeling

Als we de resultaten van deze correctness evaluator vergelijken met de manuele scores, dan zien we in onze test dat de LLM-as-judge score in 70% van de gevallen gelijk is aan de manuele score. Er zijn dus heel wat gevallen waar beide scores niet overeenkomen. Daar zijn diverse redenen voor:

• Subjectieve beoordelingen – Manuele beoordelingen zijn subjectief, zo worden onvolledige antwoorden al dan niet streng beoordeeld naargelang de persoon die de evaluatie uitvoert.
• Kwaliteit referentie-antwoorden – De kwaliteit van de referentie-antwoorden die opgesteld worden door een domein-expert spelen een belangrijke rol omdat dit de maatstaf is. Ze moeten compleet zijn en duidelijk geformuleerd.
• Beoordelingsmethode: Bij de manuele beoordeling wordt gebruik gemaakt van een driedelige score (2 = correct, 1 = onvolledig, 0 = fout).  De geteste correctness evaluator maakt standaard gebruikt van een tweedelige score (true of false). Deze mist de nodige nuance om een correct maar onvolledig antwoord toch enigszins positief te scoren.
• Taalmodel – Tenslotte speelt ook het taalmodel dat door de LLM-as-judge gebruikt wordt een rol.  Een reasoning model zal beter in staat zijn om een goede beoordeling te doen dan een minder performant chat model.

In het ideale geval oordeelt een automatische evaluator op dezelfde manier als een menselijke evaluator, maar in de praktijk blijkt het dus moeilijk om de scores van automatische evaluaties goed te aligneren met de manuele scores.

Om deze alignering te verbeteren kan de LLM-as-judge iteratief verbeterd worden door bijvoorbeeld de prompt aan te passen (instructies, beoordelingsmethode). In feite is het inschakelen van een LLM als evaluator op zich ook een LLM-project waarvan de kwaliteit moet geëvalueerd worden en iteratief verbeterd kan worden. De kunst zal erin bestaan om eenvoudig te starten en de kwaliteit van de evaluator geleidelijk aan te verbeteren. Sowieso kan de tekstuele motivatie van de correctness evaluator nuttige input leveren voor het beoordelen van gegenereerde antwoorden.

Welke metrieken gebruiken?

In de ontwikkelfase beschikken we vaak over referentie-antwoorden; daardoor kunnen we een correctness evaluator inzetten die simpelweg meet in hoeverre het gegenereerde antwoord overeenkomt met het referentie-antwoord. Aanvullende metrieken kunnen zicht bieden op andere RAG-aspecten, zoals context precision, die meet welk deel van de aangeleverde chunks relevant zijn, en context recall, die meet hoeveel van de relevante chunks werden aangeleverd. In de figuur hieronder zijn deze referentie-gebaseerde metrieken aangeduid in geel.

Wanneer zulke metrieken nodig zijn maar er geen expliciete referentie beschikbaar is, kan men teruggrijpen naar benaderende varianten (zie metrieken aangeduid in blauw in de figuur hierboven): bijvoorbeeld een LLM-as-judge die het gegenereerde antwoord vergelijkt met de opgehaalde context en een semantische “close-enough” score teruggeeft. In een productie-omgeving ontbreken referentie-antwoorden vrijwel altijd; daar verschuift de focus naar metrieken als hallucination detection of groundedness, die beoordelen of elke bewering in de output daadwerkelijk ondersteund wordt door de aangeleverde context. Zo blijft de kwaliteit toch meetbaar, ook zonder gouden standaard. Andere benaderende metrieken zijn context relevance, die meet hoe sterk de opgehaalde passages semantisch aansluiten bij de vraag en dus bruikbaar zijn als basis voor generatie, en answer relevance (helpfulness), die beoordeelt in welke mate het uiteindelijke antwoord daadwerkelijk de vraag beantwoordt.

Conclusie

Generatieve AI zit vandaag in een hypefase, maar voor organisaties is betrouwbare kwaliteit van de output één van de belangrijkste criteria om dergelijke technologie met vertrouwen te kunnen inzetten. Bij een RAG-pipeline is de gegenereerde output gebaseerd op domeinkennis, maar zonder een robuust evaluatiekader is er onvoldoende zicht op de kwaliteit. Daarom is het belangrijk om in te zetten op meetbaarheid.

Begin in de ontwikkelfase met een compacte, representatieve testset en duidelijke gouden standaard‑antwoorden. Daarop kunnen referentie‑gebaseerde metrieken toegepast worden zoals correctness om snel pijnpunten bloot te leggen. Eens je naar productie opschuift, kan je overschakelen op referentievrije metrieken zoals groundedness en hallucination detection, zodat je ook onbekende vragen kunt monitoren.

Automatische evaluaties op basis van LLM‑as‑judge zijn geen wondermiddel. Hun grootste uitdaging is alignering: ervoor zorgen dat de automatische scores zo dicht mogelijk aansluiten bij het oordeel van domeinexperts. Toch leveren ze schaal en continuïteit: ze kunnen grote volumes outputs screenen, kunnen potentiële kwaliteitsproblemen aanduiden en bieden objectieve meetpunten om een LLM- of RAG-toepassing gericht bij te sturen. Door hun oordeel systematisch te vergelijken met manuele beoordelingen en de prompts van de evaluator bij te sturen, worden zowel de toepassing als de evaluator steeds beter via een iteratief proces.

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

(FR) Entretien en Néerlandais (sous-titres disponibles) avec Bert Vanhalst de Smals Research sur les agents IA. Conversation intéressante sur la dernière évolution de l’intelligence artificielle, mais avec les deux pieds sur terre, loin du battage médiatique. Deuxième entretien d’une série de Research talks, avec la coopération de Smals Academy.

(EN) Interview in Dutch (subtitles available) with Bert Vanhalst from Smals Research about AI Agents. Interesting conversation about the latest evolution in artificial intelligence, but with both feet on the ground, away from the hype. Second conversation in a series of Research talks, with the cooperation of Smals Academy.