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.

Tijdens dit webinar delen we onze eigen ervaringen uit de praktijk. Aan de hand van concrete voorbeelden laten we zien wat werkt en waar de valkuilen liggen, welke aandachtspunten cruciaal zijn bij de ontwikkeling van een RAG-toepassing en hoe je beter kan inschatten wat je van deze technologie mag verwachten.

Of je nu zelf aan de slag wil met RAG of simpelweg beter wil begrijpen hoe deze technologie kan bijdragen aan waardevolle AI-toepassingen: dit webinar geeft je heldere inzichten en direct toepasbare lessen.

De sessie is tweetalig Frans – Nederlands, met Engelstalige slides.

La Génération Augmentée de Récupération (RAG) est le moyen idéal de créer des applications d’IA générative alimentées par vos propres données. Alors que les modèles de langage standard se limitent souvent à des réponses génériques, la RAG combine la puissance d’un modèle de langage avec vos propres données, de sorte que les réponses sont fiables et contextualisées.

Au cours de ce webinaire, nous partagerons nos propres expériences pratiques. À l’aide d’exemples concrets, nous vous montrerons ce qui fonctionne et où se trouvent les pièges, quels sont les points cruciaux à prendre en compte lors du développement d’une application RAG et comment mieux évaluer ce que vous pouvez attendre de cette technologie.

Que vous souhaitiez vous lancer avec la RAG ou simplement mieux comprendre comment cette technologie peut concourir à des applications d’IA utiles, ce webinaire vous apportera des informations claires et des enseignements directement applicables.

La session est bilingue français et en néerlandais, avec des slides en anglais.

Recording

Presentation

(FR) OpenEvals est un outil open source permettant d’évaluer la qualité des applications basées sur les LLM.

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.

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

Que sont les agents IA?

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

Voici les caractéristiques typiques des agents IA :

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

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

L’anatomie des agents IA

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

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

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

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

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

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

Avantages et applications

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

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

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

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

Défis et risques

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

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

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

Examples pratiques

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

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

Quand (ne pas) l’utiliser?

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

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

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

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

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

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

Le contexte change régulièrement ou est incertain

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

Quand vaut-il mieux s’abstenir ?

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

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

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

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

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

Conclusion

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

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

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

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

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

Wat zijn AI agents?

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

Dit zijn de typische kenmerken van AI agents:

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

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

De anatomie van AI agents

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

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

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

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

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

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

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

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

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

Voordelen en toepassingen

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

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

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

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

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

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

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

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

Uitdagingen en Risico’s

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

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

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

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

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

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

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

Praktische voorbeelden

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

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

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

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

Wanneer (niet) gebruiken?

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

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

Wanneer is een AI agent een goed idee?

De taak is complex en moeilijk volledig te formaliseren

Er wordt gewerkt met natuurlijke taal of ongestructureerde data

De taak komt frequent voor en kost vandaag veel tijd

De context verandert regelmatig of is onzeker

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

Wanneer beter niet?

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

✘ Het domein is strikt gereguleerd of bevat gevoelige persoonsgegevens

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

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

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

Conclusie

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

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

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

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

Cohere Rerank est un service permettant d’améliorer la pertinence des résultats de recherche.

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

Embeddings vectoriels

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

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

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

Recherche de similarité

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

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

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

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

Recherche hybride

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

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

Domaines d’application

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

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

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

Aperçu du marché

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

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

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

Conclusion

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

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

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