In een eerdere blogpost gaven we een overzicht van opportuniteiten voor het verbeteren van de klantenondersteuning. Contactcenters staan namelijk blijvend onder druk om vragen zo efficiënt mogelijk te beantwoorden. In deze blogpost gaan we dieper in op één van de mogelijke technieken, namelijk spraakroutering.

Wat is spraakroutering?

In een contactcenter is het belangrijk om een beller zo vlot mogelijk te verbinden met een medewerker die het meest geschikt is om de vraag te beantwoorden. Men spreek van skill-based routing. Traditioneel worden klanten daartoe vaak begroet door een IVR-systeem (Interactive Voice Response) die hen door een menu met opties leidt. IVR werkt met drukknoppen en vooraf opgenomen audiofragmenten: wanneer een klant belt, krijgt hij of zij een reeks opties te horen en moet hij of zij een bepaalde toets indrukken om de gewenste optie te selecteren. Dergelijke menu's kunnen al snel als complex ervaren worden, wat leidt tot frustratie bij de beller. Indien men niet zeker is kiest men vaak de optie "overige", wat een correcte routering in de weg staat.

Spraakroutering maakt gebruik van geavanceerde spraakherkenningstechnologie om de oproepen van klanten te routeren naar de juiste afdeling of persoon. In plaats van het kiezen van opties via drukknoppen, kunnen klanten simpelweg hun vraag stellen in hun eigen bewoordingen. Het systeem zal de ingesproken vraag omzetten naar tekst en de intentie (intent) ervan analyseren om de juiste actie te ondernemen. Dat kan een doorschakeling zijn naar de meest geschikte afdeling of persoon, of het doorsturen naar self-service mogelijkheden.

De meerwaarde van spraakroutering

De belangrijkste meerwaarde van spraakroutering is een snellere en efficiëntere afhandeling van inkomende oproepen, waardoor de wachttijd voor klanten verkort en de doorlooptijd van gesprekken wordt verbeterd. Er zijn minder doorschakelingen nodig omdat er correcter gerouteerd wordt naar de meest geschikte medewerker.

Een ander voordeel van spraakroutering is dat het een meer persoonlijke en menselijke ervaring biedt voor klanten. In plaats van het doorlopen van een standaardmenu met opties, kunnen klanten direct hun vraag stellen in hun eigen woorden.

Daarnaast kan spraakroutering de belasting op de contactcenter medewerkers verminderen. Als er een eenvoudige vraag gesteld wordt, kan het antwoord onmiddellijk teruggegeven worden of kan er doorgestuurd worden naar een self-service toepassing. In dat scenario komt er geen menselijke medewerker meer aan te pas. Er komt meer tijd vrij voor de contactcenter medewerkers om zich te concentreren op complexere vragen die menselijke interactie vereisen.

Een ander voordeel van spraakroutering is dat het kan helpen om de gegevens van klanten beter te begrijpen en te analyseren. Door het gebruik van geavanceerde spraakherkenningstechnologie kunnen bedrijven inzicht krijgen in de veelgestelde vragen van klanten en de belangrijkste pijnpunten in hun klantervaring. Die informatie kan vervolgens worden gebruikt om de dienstverlening verder te verbeteren.

Tenslotte kan het capteren van de precieze vraag ook toelaten om automatisch relevante knowledge artikels klaar te zetten ter ondersteuning van de contactcenter medewerker, die dat als basis kan gebruiken om een antwoord te formuleren. Of er kan zelfs al een kant-en-klare antwoordsuggestie voorgesteld worden.

Aandachtspunten bij de implementatie van spraakroutering

Cruciaal bij spraakroutering is de goede herkenning van de vraag. Hiervoor wordt in eerste instantie een beroep gedaan op spraakherkenningstechnologie voor het omzetten van de gesproken vraag naar tekstvorm. De spraakherkenning moet dan ook van zeer goede kwaliteit zijn en kunnen omgaan met diverse talen, accenten en dialecten, en een lage geluidskwaliteit of lawaaierige omgeving. Zo is een goede ondersteuning voor het Vlaams niet zo evident.

Het taalmodel moet ook rekening houden met de specifieke context van een organisatie. Woorden en afkortingen die specifiek zijn aan het eigen business domein moeten voldoende herkend worden. Daartoe moet het taalmodel bijgetraind kunnen worden zodat vragen goed herkend worden.

Om te kunnen spreken van een positieve business case voor spraakroutering moet er een zeker volume aan oproepen zijn om de investering te verantwoorden. Het is ook zo dat een situatie waarbij één centraal oproepnummer gebruikt wordt interessanter zal zijn dan een situatie waarbij er verschillende oproepnummers in gebruik zijn voor verschillende doelgroepen.

In ieder geval is het belangrijk om te zorgen voor een goede monitoring en rapportage van de prestaties van het spraakrouteringssysteem. Hierdoor kan de effectiviteit van de spraakroutering gemeten worden en de kwaliteit continu worden verbeterd.

Tenslotte moet ook aandacht uitgaan naar gegevensbescherming en privacy. De GDPR-regels moeten ook hier gevolgd worden, waaronder het bieden van de nodige transparantie aan bellers in verband met het gebruik van hun gegevens.

Conclusie

Spraakroutering kan ons in staat stellen om de efficiëntie van een contactcenter te verhogen en de klanttevredenheid te verbeteren door klanten snel en effectief te verbinden met de juiste agent. De beller kan zijn vraag in zijn eigen bewoordingen formuleren. De gemiddelde afhandeltijd en het aantal doorschakelingen kan verminderd worden. En het kan helpen om waardevolle inzichten te verkrijgen in de behoeften van klanten.

We moeten echter rekening houden met een aantal randvoorwaarden om spraakroutering succesvol te implementeren, zoals de kwaliteit van de spraakherkenning, de mogelijkheid om het taalmodel aan te passen aan de eigen context, en het respecteren van de regels rond gegevensbescherming en privacy.

Het is daarom aangeraden om voorafgaand aan de implementatie duidelijke doelen vast te stellen, en bij de implementatie de effectiviteit van de spraakroutering regelmatig te meten en deze continu te verbeteren.

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.

Taalmodellen

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

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

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

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

Question answering op basis van taalmodellen

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

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

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

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

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

Frameworks

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

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

Kwaliteit van de output

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

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

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

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

Conclusie

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

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

Nederlandstalige versie

Dans un article précédent, nous avons dressé la liste des opportunités d'améliorations de l'assistance à
la clientèle. Les centres de contact sont soumis à une pression constante de répondre aux questions le
plus efficacement possible. Dans cet article, nous examinons de plus près l'une des techniques
possibles : le routage vocal.

Qu'est-ce que le routage vocal ?

Dans un centre de contact, il est important de relier le plus facilement possible un appelant à
l’opérateur le plus apte à répondre à sa question. On parle alors de skill based routing.
Traditionnellement, à cette fin, les clients sont souvent accueillis par un système IVR (Interactive
Voice Response) qui les guide à travers un menu d'options. Le système IVR fonctionne sur la base de
commandes et fragments audio préenregistrés : lorsqu'un client appelle, on lui propose une série
d'options et il doit sélectionner l'option souhaitée en pressant une touche. De tels menus peuvent
rapidement être perçus comme complexes, entraînant la frustration de l'appelant. En cas d'incertitude,
les gens choisissent souvent l'option "autre", ce qui empêche un routage correct.

Le routage vocal utilise une technologie avancée de reconnaissance vocale pour router les appels des
clients vers le bon service ou la bonne personne. Au lieu de choisir des options à l'aide de boutons,
les clients peuvent simplement poser leur question dans leurs propres termes. Le système convertit la
question vocale en texte et analyse son intention (intent) pour prendre la mesure appropriée. Il peut
s'agir d'un transfert vers le service ou la personne la plus appropriée, ou d'une redirection vers des
options de self-service.

La valeur ajoutée du routage vocal

La principale valeur ajoutée du routage vocal est un traitement plus rapide et plus efficace des appels
entrants, ce qui réduit le temps d'attente des clients et améliore le débit des appels. Moins de
transferts d'appels sont nécessaires car les appels sont acheminés plus correctement vers l’opérateur
le plus approprié.

Un autre avantage du routage vocal est qu'il offre une expérience plus personnelle et plus humaine
aux clients. Au lieu de passer par un menu standard d'options, les clients peuvent directement poser
leur question dans leurs propres termes.

En outre, le routage vocal peut réduire la charge de travail du personnel du centre de contact. Si une
question simple est posée, la réponse peut être renvoyée immédiatement ou redirigée vers une
application en self-service. Dans ce scénario, il n'y a plus d'employé humain impliqué. Le personnel
du centre de contact dispose ainsi de plus de temps pour se concentrer sur les questions plus
complexes qui nécessitent une interaction humaine.

Un autre avantage du routage vocal est qu'il peut aider à mieux comprendre et analyser les données
relatives aux clients. En utilisant une technologie avancée de reconnaissance vocale, les entreprises
ont une idée des questions les plus fréquemment posées par les clients et des principaux obstacles
qu'ils rencontrent. Ces informations peuvent ensuite être utilisées pour améliorer les services.

Enfin, le fait de recueillir la question exacte permet de préparer automatiquement des articles de
référence pour aider l’opérateur du centre de contact, qui peut s'en servir comme base pour formuler
une réponse. Ou même une suggestion de réponse toute faite peut déjà être suggérée.

Points à considérer lors de l'implémentation du routage vocal

La reconnaissance correcte de la demande est cruciale pour le routage vocal. Pour ce faire, le routage
vocal s'appuie principalement sur la technologie de reconnaissance vocale pour convertir la requête
vocale en texte. La reconnaissance vocale doit donc être de très bonne qualité et être capable de gérer
des langues, accents et dialectes différents, ainsi qu'une mauvaise qualité sonore ou un
environnement bruyant. Par exemple, une bonne prise en charge du flamand n'est pas si évidente.

Le modèle linguistique doit également tenir compte du contexte spécifique d'une organisation.
Les mots et abréviations propres au domaine d'activité de l'entreprise doivent être suffisamment
reconnus. À cette fin, le modèle linguistique doit être entraîné afin que les questions soient
correctement reconnues.

Pour parler d'un business case positif du routage vocal, il faut qu'il y ait un certain volume d'appels
justifiant l'investissement. Il est vrai aussi qu'une situation dans laquelle un numéro d'appel central
est utilisé sera plus intéressante qu'une situation dans laquelle différents numéros d'appel sont utilisés
pour différents groupes cibles.

Dans tous les cas, il est important d'assurer un suivi et un reporting adéquats des performances du
système de routage vocal. Cela permet de mesurer l'efficacité du routage vocal et d'améliorer
continuellement la qualité.

Enfin, la protection des données et de la vie privée doit également être prise en compte. Il s’agit ici
également de respecter le RGPD, notamment en fournissant la transparence nécessaire aux appelants
en ce qui concerne l'utilisation de leurs données.

Conclusion

Le routage vocal peut nous permettre d'accroître l'efficacité des centres de contact et d'améliorer la
satisfaction des clients en les mettant en relation avec le bon agent rapidement et efficacement.
L'appelant peut formuler sa demande dans ses propres termes. Le temps moyen de traitement et le
nombre de transferts d'appels peuvent être réduits. Le routage vocal peut également permettre
d'obtenir des informations précieuses sur les besoins des clients.

Cependant, nous devons tenir compte d'un certain nombre de conditions préalables pour mettre en
oeuvre avec succès le routage vocal, telles que la qualité de la reconnaissance vocale, la capacité
d'adapter le modèle linguistique à son propre contexte, et le respect des règles de protection des
données et de la vie privée.

Il est donc recommandé de fixer des objectifs clairs avant la mise en oeuvre et, pendant celle-ci, de
mesurer régulièrement l'efficacité du routage vocal et de l'améliorer en permanence.

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.

Nederlandstalige versie

Pour répondre à la demande de leurs clients traitant des données sensibles ou attirer de nouveaux clients, les fournisseurs d’infrastructures informatiques publiques mettent d’importants moyens en œuvre afin d’améliorer leur sécurité et notamment de mieux protéger les données de leurs clients. Microsoft, par exemple, déclare investir environ un milliard de dollars chaque année dans la sécurité de ses infrastructures [1]. Depuis le milieu des années 2010, ces fournisseurs d’infrastructures investissent notamment dans une offre d’informatique confidentielle. Principalement basée sur des environnements d’exécution de confiance (« Trusted Execution Environments (TEE) »), celle-ci permet en principe de réduire la confiance accordée par le client au fournisseur d’infrastructure.

Dans un article précédent, nous avons présenté de manière générale ce qu’étaient ces TEE et leur utilité. Dans cet article nous regardons plus en détail le fonctionnement des principales mises en œuvre commerciales. Cependant, il convient de garder à l’esprit que les définitions d’informatique confidentielle et de TEE diffèrent et sont parfois incomplètes. Cela peut conduire à un faux sens de sécurité, à des incertitudes légales et à rendre les comparaisons difficiles [2]. Afin de répondre à ce manque de standardisation et d’interopérabilité entre les différentes approches d’informatique confidentielle, le « Confidential Computing Consortium » a été créé par des acteurs importants du secteur, dont AMD, Google, Intel, et Microsoft. Il est à noter qu’Amazon ne fait pas partie de ce regroupement et que son système Nitro (voir ici) est très différent des autres approches¹.

Une version plus approfondie de cet article, réservée aux clients de Smals, est disponible sur demande.

Fabricants de microprocesseurs

AMD et Intel sont les deux principaux fabricants de microprocesseurs offrant des fonctionnalités nécessaires à l’informatique confidentielle dans de larges centres informatiques². Alors que les technologies TDX d’Intel et SEV-SNP d’AMD ont pour but de protéger des machines virtuelles (VM) entières, la technologie SGX est très différente et sa surface d’exposition aux attaques plus faible. La Figure 1 montre les éléments faisant partie de la base informatique de confiance (« Trusted Computing Base (TCB) ») pour ces trois technologies que nous décrivons dans les paragraphes suivants.

Figure 1 – La technologie SGX d’Intel permet d’isoler un processus, tandis que les technologies TDX d’Intel et SEV-SNP d’AMD permettent l’isolation de machines virtuelles entières.

Technologie SEV-SNP d’AMD

En 2016, AMD a introduit la technologie de virtualisation sécurisée par chiffrement (« Secure Encrypted Virtualisation (SEV) ») afin d’isoler les VM de l’hyperviseur au niveau matériel [3], [4]. Chaque VM reçoit sa propre clé de chiffrement AES pour le chiffrement de la mémoire. L’état des registres du microprocesseur de chaque VM est également chiffré, empêchant l’hyperviseur de lire les données contenues dans la VM. Par la suite, AMD a ajouté une technologie de pagination imbriquée sécurisée (« Secure Nested Paging (SNP) ») offrant une protection de l’intégrité de la mémoire, et permettant d’empêcher les attaques d’un hyperviseur malicieux (par ex. attaques par rejeu, reconfiguration du mécanisme de traduction de mémoire virtuelle, corruption des données mémoires) [5]. Le principe fondamental de SEV-SNP est que si une VM est en mesure de lire une page mémoire lui étant réservée (et donc chiffrée), alors elle doit toujours lire la dernière valeur qu’elle a elle-même écrite. Par ailleurs dans le modèle de sécurité utilisé pour SNP, seule la VM du client et le microprocesseur AMD font partie de la base de confiance. N’en font donc pas partie l’hyperviseur, le BIOS, les autres VM, etc. (voir Figure 1). Enfin, une option de SEV-SNP permet aux VM de diviser, d’une manière similaire aux anneaux de protection dans l’architecture x86, leur mémoire virtuelle en quatre niveaux de privilèges (« Virtual Machine Privilege Levels (VMPL) »).

Le mécanisme d’attestation à distance d’AMD, permet de vérifier que la machine hôte est bien un processeur AMD qui prend en charge la technologie SEV-SNP et qu’une VM a bien été déployée avec la protection SEV-SNP. Chaque processeur AMD, contient un coprocesseur sécurisé qui permet de générer une paire de clés dédiées (« Platform Endorsement Key (PEK) »), elle-même signée par une clé unique dérivée de secrets enregistrés grâce à des fusibles dans la puce elle-même. Cette PEK est également indirectement utilisée pour établir un secret partagé entre la plate-forme SEV et le client [6]. Au moment du lancement de la VM sécurisée sur la plate-forme SEV par l’hyperviseur, le micrologiciel (« firmware ») SEV calcule la mesure (valeur du hachage cryptographique) de la mémoire de la VM. Cette mesure peut être communiquée de manière sécurisée au client afin qu’il vérifie que la VM déployée n’a pas été altérée.

La technologie SEV-SNP est disponible sur les processeurs AMD EPYC de 3^e génération (série 7003) et 4^e génération (série 9004). On peut trouver ces processeurs chez différents fournisseurs comme Dell (serveurs « PowerEdge »), Lenovo ou HP. Les prix varient de quelques milliers à plusieurs dizaines de milliers d’euros en fonction de la configuration.

Technologies SGX et TDX d’Intel

Introduit en 2015, le système « Software Guard eXtensions (SGX) » d’Intel permet à un logiciel de définir des zones de mémoire protégées pour des « enclaves » sécurisées isolées des autres processus fonctionnant sur la même machine (noyaux du système d’exploitation, hyperviseur, etc.) ainsi que des accès directs par des périphériques. Le processeur s’assure que chaque enclave a sa zone mémoire dédiée et chiffrée, enregistrant chaque allocation par le système d’exploitation [7]. Une enclave est générée en tant que bibliothèque partagée dynamiquement à l’aide d’outils de compilation standards. Lors de l’initialisation d’une enclave, le système d’exploitation demande au processeur de copier l’application dans des pages mémoire de la zone protégée chiffrée. Lors de ce chargement en mémoire, le processeur calcule une mesure de l’application. Cela permet par la suite de vérifier l’intégrité de l’application par un mécanisme d’attestation. Intel a introduit en 2020, la technologie « Trusted Domain Extensions (TDX), » qui est un module logiciel signé, exécuté dans un nouveau mode du processeur et qui permet de protéger et d’isoler cryptographiquement des machines virtuelles. Plus de détails sur le fonctionnement et l’architecture de TDX peuvent être trouvés dans [8].

Deux types d’attestation à distance sont disponibles avec SGX « Enhanced Privacy ID (EPID) » et « Data Centre Attestation Primitives (DCAP). » Le premier est un mode d’attestation dans lequel le serveur d’attestation d’Intel doit être contacté pour obtenir des informations sur l’enclave requérante. Le second ne nécessite pas de contacter le serveur d’attestation d’Intel. Durant le processus de construction d’une enclave, deux mesures sont faites. MRENCLAVE est la valeur de hachage cryptographique de la disposition de la mémoire virtuelle assignée à l’enclave au moment de son lancement. L’autre mesure, MRSIGNER, est la valeur de hachage cryptographique de la clé publique de l’auteur de l’application fonctionnant dans l’enclave [9].

Alors que la technologie SGX a été retirée de la 12^e génération des processeurs Core d’Intel, elle reste disponible sur la 3^e génération de processeurs Xeon [10]. Les processeurs Xeon de 4^e génération prennent en charge la technologie TDX et sont disponibles chez les partenaires et distributeurs agréés d’Intel.

Notons que l’utilisation de la technologie SGX demande une réécriture importante des applications existantes³. Il est en effet nécessaire de partitionner l’application en identifiant quelle partie du code doit pouvoir avoir accès aux données sensibles. Bien que cette étape essentielle soit complexe, elle permet en principe d’améliorer la sécurité de l’application étant donné qu’il est généralement accepté qu’une application de petite taille – en l’occurrence celle fonctionnant dans l’enclave – a moins de chances d’avoir des défauts tout en étant plus facilement vérifiable qu’une application de grande taille. La communication entre la partie sécurisée de l’application (dans l’enclave) et le reste de l’application (en dehors de l’enclave) se fait via des appels à des fonctions devant être déclarées avant le lancement de l’enclave. Enfin, les applications écrites pour la plate-forme SGX ne peuvent pas être utilisées sur d’autres plates-formes.

Fournisseurs d’infrastructures informatique

Plusieurs fournisseurs d’infrastructures informatiques publiques proposent aujourd’hui des solutions d’informatique confidentielle basées sur les TEE. Nous décrivons ici les trois principaux⁴.

AWS

Amazon définit l’informatique confidentielle comme l’utilisation de matériel spécialisé et de micrologiciels associés pour protéger le code et les données du client pendant le traitement contre tout accès extérieur. Amazon traduit cela selon deux dimensions :

• La protection vis-à-vis de de l’opérateur de l’infrastructure informatique sous-jacente, en l’occurrence AWS ;
• La capacité des clients à diviser leurs propres charges de travail en composants plus ou moins fiables, ou à concevoir des systèmes multi-agents.

L’accent est mis par Amazon sur l’architecture du système Nitro, plutôt que sur la disponibilité d’un microprocesseur particulier en charge de fournir un TEE. Cependant, depuis avril 2023, AWS offre aussi la possibilité de créer des instances EC2 avec la technologie SEV-SNP d’AMD (voir ici).

Dans sa conception, selon AWS, le système Nitro n’offre aucun mécanisme permettant à un système ou à une personne de se connecter aux serveurs EC2, de lire la mémoire des instances EC2 ou d’accéder aux données stockées. Les travaux de maintenance ne peuvent se faire qu’à travers des API limitées.

Le système AWS Nitro (Figure 2) s’inscrit dans une refonte de l’infrastructure de virtualisation du service EC2 d’Amazon, notamment réduire au maximum les parties de l’hyperviseur fonctionnant sur la carte mère. Le système AWS Nitro est une combinaison de serveurs, de processeurs, de composants de gestion et de micrologiciels spécialisés qui fournissent la plate-forme sous-jacente pour toutes les instances Amazon EC2. Il se compose de trois éléments principaux :

• Cartes Nitro spécifiques – Dispositifs matériels conçus par AWS qui assurent le contrôle global du système et la virtualisation des entrées/sorties indépendamment de la carte mère du système avec ses processeurs et sa mémoire ;
• La puce de sécurité Nitro – Celle-ci est intégrée à la carte mère du serveur et permet un démarrage sécurisé basé sur une racine de confiance matérielle, la capacité d’offrir des instances « bare metal » (permettant de se passer de l’hyperviseur d'AWS), ainsi qu’une protection du serveur contre les modifications non autorisées du micrologiciel du système ;
• L’hyperviseur Nitro – Un hyperviseur minimisé, semblable à un micrologiciel, conçu pour fournir une isolation des ressources et des performances.

Les considérations de sécurité de ce système sont détaillées dans [12].

Figure 2 – Architecture d’une machine AWS.

Les enclaves Nitro, quant à elles, sont des machines virtuelles isolées fonctionnant avec une instance EC2 classique, appelée instance « parent » (Figure 3).

Selon AWS, l’enclave Nitro n’offre pas de sécurité supplémentaire vis-à-vis d’une opératrice d’AWS [13], mais permet en revanche d’empêcher un administrateur du client d’accéder au contenu de l’enclave (code et données).

Figure 3 – Création d’une enclave Nitro à partir d’une instance EC2. Une enclave est créée en partitionnant le processeur et la mémoire d’une instance EC2, appelée instance parent. Il est possible de créer des enclaves avec des combinaisons variées de cœurs de processeur et de mémoire.

La contrainte principale imposée par les enclaves Nitro est que l’application fonctionnant dans l’enclave n’a pas de connexion au réseau. Elle peut seulement communiquer avec l’instance parent via une interface point à point appelée « vsock » qui est définie par un identifiant de contexte et un numéro de port⁵. Un simple « lift and shift » n’est donc pas possible.

Au moment de sa création, l’application fonctionnant dans l’enclave peut générer une paire de clés asymétriques et faire inclure la clé publique dans l’attestation. Par conséquent l’application client vérifiant l’attestation peut utiliser cette clé afin d’établir une communication sécurisée avec l’enclave.

Microsoft Azure

Microsoft Azure propose trois types d’informatique confidentielle basée sur les TEE :

• Les enclaves d’applications sont basées sur la technologie SGX d’Intel. Comme indiqué précédemment, il est nécessaire de modifier en profondeur les applications existantes afin de les adapter. Cela impose une réflexion importante sur le choix des parties de l’application à sécuriser et de leur interaction avec les autres parties, mais l’avantage de cette approche est de réduire la quantité de code auquel il faut faire confiance. L’inconvénient est bien évidemment la complexité de la mise en œuvre, requérant notamment une formation particulière des analystes, architectes et programmeurs ;
• Les machines virtuelles confidentielles utilisent la technologie SEV-SNP d’AMD (voir ici) et Microsoft a annoncé en avril 2023, la mise à disposition prochaine de la technologie TDX d’Intel (voir ici) [14]. Azure met également à disposition un module de plate-forme fiable (« trusted platform module (TPM) ») utilisé notamment pour l’attestation des machines virtuelles ;
• Les conteneurs confidentiels permettent au client d’avoir un niveau de contrôle plus fin que les machines virtuelles sur la TCB. Ce modèle d’empaquetage permet en principe d’exécuter des conteneurs existants dans une enclave SGX sans devoir modifier ou recompiler le logiciel (« lift-and-shift »).

L’option permettant l’existence de plusieurs fils d’exécution en parallèle (technologie « hyper-threading ») au sein du même processeur est désactivée sur toutes les instances SGX. Cela permet d’éviter des attaques conduisant à des fuites de données entre applications partageant le même processeur.

Google

Google propose différentes façons de mettre en œuvre l’informatique confidentielle sur son infrastructure :

• Les machines virtuelles confidentielles utilisent la technologie d’AMD ;
• Les nœuds Kubernetes confidentiels reposent également sur la technologie SEV d’AMD. Le moteur Kubernetes de Google peut imposer l’utilisation de machines virtuelles confidentielles pour tous les nœuds Kubernetes.

Alors que toutes les machines virtuelles confidentielles contiennent des TPM virtuels qui valident l’intégrité d’une machine virtuelle avec le démarrage mesuré, les machines virtuelles confidentielles avec la technologie SEV-SNP offrent également des rapports d’attestation signés cryptographiquement par le matériel. Cependant la technologie SEV-SNP n’est pas encore disponible de manière généralisée sur l’infrastructure de Google.

Limite pratique des attestations

Comme nous l’expliquions dans notre article précédent, un point essentiel de l’utilisation des TEE est d’obtenir la garantie que le logiciel fonctionnant sur l’infrastructure louée est réellement le logiciel auquel s’attend le client et que les données qu’il traite ne peuvent être lues par aucun autre logiciel. Cette garantie, appelée attestation et obtenue à travers un mécanisme fiable, devrait contenir des informations complètes, récentes et explicites sur le plan sémantique [15].

En supposant que l’on fasse confiance à la sécurité physique du microprocesseur ou de la puce spécialisée, que les attaques connues ont été atténuées et que le code de l’enclave n’est pas vulnérable aux attaques par canaux auxiliaires (« side-channel attacks »), comment peut-on être certain que la sortie d’une enclave est fiable?

Il faut s’assurer que :

• Le fichier binaire exécuté dans l’enclave a bien été construit avec le code attendu. Pour ce faire le client peut compiler son application sur une machine de confiance (par ex. lui appartenant), puis copier le binaire de manière sécurisée sur la plate-forme d’informatique confidentielle. Une autre méthode est d’utiliser un outil de compilation reproductible⁶ ;
• Le fichier binaire en cours d’exécution correspond bien au binaire attendu. Un système d’attestation utilise des clés cryptographiques dérivées de secrets figés dans le microprocesseur de confiance pour signer une preuve que le binaire est dans un état donné sur un véritable matériel (pas une simulation). La preuve contient une mesure (valeur de hachage cryptographique) du binaire ;
• L’état de l’application au moment de son démarrage est celui attendu " la mesure de la partie exécutable du binaire n’est pas suffisante pour prédire son comportement futur ;
• L’attestation est signée par une entité de confiance, en principe par le fabricant du microprocesseur ou de la puce sécurisée.

Pourtant dans les solutions étudiées, excepté les enclaves SGX, soit l’attestation est signée par le fournisseur de l’infrastructure (et non par le fabricant du matériel), soit il n’est pas possible de vérifier la mesure du logiciel sécurisé car il inclut des bibliothèques propriétaires. Le risque est donc que l’entité attestée mente sur son état.

Conclusion

Dix ans après les révélations d’Edward Snowden en juin 2013, concernant les méthodes de surveillance des États-Unis, nous devons partir du principe que des informations pourront être obtenues si elles sont suffisamment précieuses. L’impression de plus grande sécurité des infrastructures informatiques nationales peut alors être trompeuse⁷. Il existe en effet une tension entre une volonté d’indépendance des services informatiques étatiques et la capacité à égaler les niveaux de ressources (matérielles, humaines, R&D), de redondance et de sécurité qu’offrent les entreprises dominantes du secteur⁸. L’ajout de l’informatique confidentielle basée sur des TEE ajoute un nouvel argument en faveur des infrastructures informatiques publiques.

Lorsqu’ils sont mis en œuvre correctement, et toutes autres choses égales par elles-mêmes, les TEE fondés des composants physiques permettent d’augmenter significativement le niveau de protection des données au sein d’une infrastructure informatique, en particulier vis-à-vis de tiers, et notamment de cybercriminels⁹. En effet ils permettent d’éviter la plupart des attaques logiques affectant les systèmes habituels, et ce, grâce à une meilleure isolation des processus, un chiffrement de la mémoire par la couche matérielle, un démarrage sécurisé, des mécanismes de contrôle de mise à jour du micrologiciel, et, d’une manière générale à une réduction de la taille de la base informatique de confiance. En d’autres termes les mesures de sécurité mises en place dans les TEE rendent une attaque beaucoup plus complexe et coûteuse.

Les offres d’informatiques confidentielles basées sur des TEE varient entre les fournisseurs, notamment en fonction du type d’abstraction offert : librairie logiciel, conteneur, machine virtuelle. Le choix de ces options conduit à des différences dans la taille de code de la base de confiance (et donc de la surface exposée aux attaques), mais également dans l’effort d’adaptation nécessaire des applications existantes à ces nouveaux environnements.

Lors du choix d’une solution d’informatique confidentielle basée sur les TEE, il conviendra donc de vérifier les points suivants :

• La protection doit être ancrée dans la couche physique du système et chaque appareil doit avoir une identité unique ;
• Le mécanisme d’attestation doit permettre de pouvoir vérifier le contenu¹⁰ du TEE de manière indépendante du fournisseur d’infrastructure¹¹;
• L’attestation doit être signée au moins par le fabricant du composant physique et pas uniquement par le fournisseur d’infrastructure¹²;
• Le service permet au minimum d’importer ses propres clés cryptographiques dans une boîte noire transactionnelle (HSM) dédiée, et au mieux d’utiliser sa propre boîte ;
• Il devrait être possible de vérifier le code source des librairies critiques incluses par le fournisseur d’infrastructure dans la base de confiance pour le bon fonctionnement de l’application du client ;
• Un service permettant de traquer les différentes dépendances logicielles, d’environnement de compilation, et des binaires utilisés pour le TEE devrait être mis à disposition du client par le fournisseur d’infrastructure.

Finalement, la protection des données en cours d’utilisation permise par l’informatique confidentielle ne représente qu’un des multiples aspects techniques à considérer concernant la confidentialité des données sensibles (sans compter les aspects juridiques, économiques et politiques). Tout comme la meilleure serrure sur la porte d’entrée principale d’une maison ne résout pas le problème d’une porte secondaire grande ouverte, l’utilisation de l’informatique confidentielle suppose que les données sont effectivement protégées au repos et en mouvement, mais requiert également une formation spécifique des personnes en charge de l’adaptation (plus ou moins importantes en fonction du type d’informatique confidentielle choisie) et du transfert des applications existantes, notamment les analystes, architectes, et programmeurs.

Bibliographie

[1]        A. Linn, « Securing the cloud | Microsoft Story Labs », Securing the cloud | Microsoft Story Labs, 2017. http://news.microsoft.com/stories/cloud-security (consulté le 6 juin 2023).

[2]        M. U. Sardar et C. Fetzer, « Confidential computing and related technologies: a critical review », Cybersecurity, vol. 6, n^o 1, p. 10, mai 2023, doi: 10.1186/s42400-023-00144-1.

[3]        D. Kaplan, « AMD x86 Memory Encryption Technologies », août 2016. Consulté le: 11 mai 2023. [En ligne]. Disponible sur: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kaplan

[4]        D. Kaplan, J. Powell, et T. Woller, « AMD Memory Encryption », White Paper, oct. 2021. Consulté le: 1 mai 2023. [En ligne]. Disponible sur: https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf

[5]        « AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More », AMD, janv. 2020.

[6]        « Secure Encrypted Virtualisation API Version 0.24 », Specification, avr. 2020. [En ligne]. Disponible sur: https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf

[7]        Victor Costan et Srinivas Devadas, « Intel SGX Explained ». Cryptology ePrint Archive, 2016. [En ligne]. Disponible sur: https://eprint.iacr.org/2016/086

[8]        P.-C. Cheng et al., « Intel TDX Demystified: A Top-Down Approach ». arXiv, 27 mars 2023. Consulté le: 23 mai 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2303.15540

[9]        « Intel 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4 ». Intel Corporation, mars 2023. [En ligne]. Disponible sur: https://cdrdv2.intel.com/v1/dl/getContent/671200

[10]       A. Rao, « Rising to the Challenge — Data Security with Intel Confidential Computing », 20 janvier 2022. https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 (consulté le 17 mai 2023).

[11]       G. Steer, « Finance’s big tech problem », Financial Times, 6 juillet 2022. Consulté le: 10 juillet 2023. [En ligne]. Disponible sur: https://www.ft.com/content/41f400b6-f83f-4fa1-8dac-731acddcf8f2

[12]       « The Security Design of the AWS Nitro System - AWS Whitepaper ». AWS, 18 novembre 2022. [En ligne]. Disponible sur: https://docs.aws.amazon.com/fr_fr/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html

[13]       « Confidential computing: an AWS perspective | AWS Security Blog », 24 août 2021. https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/ (consulté le 18 avril 2023).

[14]       M. McReynolds, « Preview: Introducing DCesv5 and ECesv5-series Confidential VMs with Intel TDX », 24 avril 2023. https://techcommunity.microsoft.com/t5/azure-confidential-computing/preview-introducing-dcesv5-and-ecesv5-series-confidential-vms/ba-p/3800718 (consulté le 16 mai 2023).

[15]       G. Coker et al., « Principles of remote attestation », Int. J. Inf. Secur., vol. 10, n^o 2, p. 63‑81, juin 2011, doi: 10.1007/s10207-011-0124-7.

[16]       « Nix & NixOS | Reproducible builds and deployments ». https://nixos.org/ (consulté le 6 juin 2023).

[17]       R. Gallagher, « The Inside Story of How British Spies Hacked Belgium’s Largest Telco », The Intercept, 13 décembre 2014. https://theintercept.com/2014/12/13/belgacom-hack-gchq-inside-story/ (consulté le 8 juin 2023).

[18]       R. Gallagher, « How U.K. Spies Hacked a European Ally and Got Away With It », The Intercept, 17 février 2018. https://theintercept.com/2018/02/17/gchq-belgacom-investigation-europe-hack/ (consulté le 8 juin 2023).

[19]       C. Zhao, « SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA », Newsweek, 14 décembre 2020. Consulté le: 9 janvier 2023. [En ligne]. Disponible sur: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[20]       R. Koppel et C. Kuziemsky, « Healthcare Data Are Remarkably Vulnerable to Hacking: Connected Healthcare Delivery Increases the Risks », Stud. Health Technol. Inf., vol. 257, p. 218‑222, 2019.

Notes

¹   Par exemple le terme « enclave » n’a pas du tout le même sens chez Amazon et Intel. Alors que les « Nitro Enclaves » sont des machines virtuelles entières, les « SGX Enclaves » sont des bibliothèques exposant certaines API.

²   Notons que NVIDIA offre depuis peu un processeur graphique (A100 Tensor Core avec la technologie « Ampere Protected Memory (APM) ») qui introduit un mode d’exécution confidentielle dans le processeur graphique et permet ainsi d’utiliser des ensembles des données pour former et déployer des modèles d’apprentissage automatique (« machine learning ») de manière confidentielle, notamment sur une infrastructure informatique publique. Ces processeurs sont disponibles sur l’offre Azure de Microsoft.

³   Ce n’est pas le cas avec TDX qui permet de protéger une machine virtuelle entière.

⁴   Selon le Financial Times, les trois fournisseurs d’infrastructure informatique les plus importants en 2021 étaient Amazon, Microsoft et Google [11].

⁵   Cette « vsock » utilise la même API que les « sockets » POSIX.

⁶   Par exemple Nix [16].

⁷   Nous avons appris en 2014 que l’agence de surveillance britannique GCHQ avait piraté un système sensible de Belgacom [17], [18].

⁸   Les groupes cybercriminels n’hésitent plus à compromettre la sécurité de services informatiques en mettant en œuvre de nouveaux types d’attaques. L’exemple du piratage de SolarWind est symptomatique à cet égard [19]. Un service indépendant national mais insuffisamment sécurisé pourrait représenter un point de défaillance unique posant un risque crucial.

⁹   « Les données de santé sont attrayantes pour les cybercriminels car elles contiennent des données financières et personnelles, peuvent être utilisées pour le chantage et, surtout, sont idéales pour la facturation frauduleuse » [20].

¹⁰ Ce contenu, dans le cas de machines virtuelles confidentielles, inclut également le système d’exploitation que l’on préférera de taille minimale.

¹¹ Si le fournisseur d’infrastructure contrôle en partie le contenu de la machine virtuelle confidentielle ou du conteneur confidentiel et que le client n’a pas de mécanisme pour le vérifier, alors la confiance dans le fournisseur reste totale.

¹² Si le fournisseur d’infrastructure signe l’attestation, alors la confiance dans ce fournisseur reste totale.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n'impacte en rien le point de vue de Smals.

Version en français

Om te voldoen aan de eisen van hun klanten die met gevoelige gegevens omgaan, of om nieuwe klanten aan te trekken, verrichten leveranciers van publieke IT-infrastructuren inspanningen om hun beveiliging te verbeteren en met name om de gegevens van hun klanten beter te beschermen.  Microsoft, bijvoorbeeld, zegt elk jaar ongeveer een miljard dollar te investeren in de beveiliging van zijn infrastructuren [1]. Sinds halfweg 2010 investeren deze infrastructuurleveranciers in een aanbod van confidential computing. Voornamelijk gebaseerd op Trusted Execution Environments (TEE), vermindert dit in principe het vereiste vertrouwen van de klant in de infrastructuurleverancier.

In een vorig artikel (in het Frans) gaven we een algemeen overzicht van deze TEE’s en het nut ervan. In dit artikel gaan we dieper in op hoe de belangrijkste commerciële implementaties werken. Het is echter belangrijk om in gedachten te houden dat de definities van confidential computing en TEE verschillen en soms onvolledig zijn. Dit kan leiden tot een vals gevoel van veiligheid, juridische onzekerheden en maakt het vergelijken moeilijk [2]. Als reactie op dit gebrek aan standaardisatie en interoperabiliteit tussen de verschillende benaderingen van confidential computing is het Confidential Computing Consortium opgericht door grote spelers in de sector, waaronder AMD, Google, Intel en Microsoft. Daarbij moeten we opmerken dat Amazon geen deel uitmaakt van dit consortium en dat zijn Nitro-systeem (zie hier) sterk afwijkt van de andere benaderingen¹.

Een uitgebreidere versie van dit artikel, voorbehouden aan de klanten van Smals, is op aanvraag beschikbaar.

Fabrikanten van microprocessors

AMD en Intel zijn de twee voornaamste fabrikanten van microprocessors die noodzakelijke functionaliteiten bieden voor de confidential computing in grote data centers². Terwijl Intels TDX en AMD’s SEV-SNP-technologieën ontwikkeld zijn om complete virtual machines (VM’s) te beschermen, is de SGX-technologie erg verschillend en heeft deze een kleiner attack surface. Figuur 1 toont de elementen die de Trusted Computing Base (TCB) vormen voor deze drie technologieën die we in de volgende paragrafen beschrijven.

Figuur 1 – Intels SGX-technologie kan worden gebruikt om een proces te isoleren, terwijl Intels TDX- en AMD’s SEV-SNP-technologieën kunnen worden gebruikt om hele virtuele machines te isoleren.

AMD’s SEV-SNP-technologie

In 2016 introduceerde AMD de technologie Secure Encrypted Virtualisation (SEV) om VM’s op hardwareniveau te isoleren van de hypervisor [3], [4]. Elke VM ontvangt zijn eigen AES-coderingssleutel voor geheugenversleuteling. De status van de microprocessorregisters van elke VM wordt ook versleuteld, waardoor de hypervisor de gegevens in de VM niet kan lezen. Later voegde AMD de technologie Secure Nested Paging (SNP) toe om geheugenintegriteit te beschermen en aanvallen door een schadelijke hypervisor te voorkomen (bijv. replay-aanvallen, herconfiguratie van het virtuele geheugenvertaalmechanisme, corruptie van geheugengegevens) [5]. Het fundamentele principe van SEV-SNP is dat als een VM een geheugenpagina kan lezen die voor haar is gereserveerd (en daarom is versleuteld), ze altijd de laatste waarde moet lezen die ze zelf heeft geschreven. Verder vormen in het beveiligingsmodel dat voor SNP wordt gebruikt alleen de VM van de klant en de AMD-microprocessor onderdeel van de trusted base. Dit omvat niet de hypervisor, BIOS, andere VM’s, enzovoort (zie Figuur 1). Tot slot stelt een SEV-SNP-optie VM’s in staat om hun virtuele geheugen op te delen in vier Virtual Machine Privilege Levels (VMPL’s) op een vergelijkbare manier als de beschermingsringen in de x86-architectuur.

AMD’s attestatiemechanisme op afstand verifieert dat de hostmachine een AMD-processor is die de SEV-SNP-technologie ondersteunt en dat een VM is geïmplementeerd met SEV-SNP-bescherming. Elke AMD-processor bevat een beveiligde coprocessor die een paar dedicated sleutels genereert (“Platform Endorsement Key (PEK)”), zelf ondertekend door een unieke sleutel die is afgeleid van geheimen opgeslagen met behulp van eenmalig programmeerbare zekeringen in de chip zelf. Deze PEK wordt ook indirect gebruikt om een gedeeld geheim te creëren tussen het SEV-platform en de klant [6]. Wanneer de beveiligde VM door de hypervisor op het SEV-platform wordt gestart, berekent de SEV-firmware de meting (waarde van de cryptografische hash) van het geheugen van de VM. Deze meting kan veilig worden doorgegeven aan de klant, zodat deze kan controleren of de gedeployde VM niet is gewijzigd.

De SEV-SNP-technologie is beschikbaar op AMD EPYC-processors van 3^e (serie 7003) en 4^e generatie (serie 9004). Deze processors zijn verkrijgbaar bij verschillende leveranciers, waaronder Dell (‘PowerEdge‘-servers), Lenovo en HP. De prijzen variëren van enkele duizenden tot enkele tienduizenden euro’s, afhankelijk van de configuratie.

Intels SGX- en TDX-technologieën

Met Intels systeem Software Guard eXtensions (SGX), dat in 2015 werd geïntroduceerd, kan een software beschermde geheugengebieden definiëren voor beveiligde ‘enclaves’ die geïsoleerd zijn van andere processen die op dezelfde machine draaien (kernels van besturingssystemen, hypervisor, enz.) en waartoe randapparatuur ook rechtstreeks toegang heeft. De processor zorgt ervoor dat elke enclave zijn eigen speciale, versleutelde geheugengebied heeft en registreert elke allocatie door het besturingssysteem [7]. Een enclave wordt gegenereerd als een dynamisch gedeelde bibliotheek met behulp van standaard compilatietools. Wanneer een enclave wordt geïnitialiseerd, vraagt het besturingssysteem de processor om de toepassing te kopiëren naar geheugenpagina’s in de versleutelde beschermde ruimte. Wanneer dan de toepassing in het geheugen is geladen, berekent de processor een meting van de toepassing. Hiermee kan vervolgens de integriteit van de toepassing gecontroleerd worden met behulp van een attestatiemechanisme. In 2020 introduceerde Intel de technologie Trusted Domain Extensions (TDX), een ondertekende softwaremodule uitgevoerd in een nieuwe processormodus die kan worden gebruikt om virtuele machines te beschermen en cryptografisch te isoleren. Meer details over de werking en architectuur van TDX zijn te vinden in [8].

Er zijn twee soorten attestatie op afstand beschikbaar met SGX: Enhanced Privacy ID (EPID) en Data Centre Attestation Primitives (DCAP). De eerste is een attestatiemodus waarbij de Intel-attestatieserver moet worden gecontacteerd om informatie te verkrijgen over de aanvragende enclave. De tweede vereist geen contact met de Intel-attestatieserver. Tijdens het bouwen van een enclave worden er twee metingen gedaan. MRENCLAVE is de cryptografische hashwaarde van de virtuele geheugenlayout die aan de enclave wordt toegewezen wanneer deze wordt gestart. De andere meting, MRSIGNER, is de cryptografische hashwaarde van de publieke sleutel van de auteur van de toepassing die in de enclave draait [9].

Hoewel SGX-technologie is verwijderd uit Intels 12^e generatie Core-processors, blijft deze beschikbaar op 3^e generatie Xeon-processors [10]. Xeon-processors van de 4^e generatie ondersteunen TDX-technologie en zijn verkrijgbaar bij Intels erkende partners en verdelers.

We merken op dat het gebruik van SGX-technologie een grote herschrijving vereist van de bestaande toepassingen³. Het is noodzakelijk om de toepassing te partitioneren door te bepalen welk deel van de code toegang moet hebben tot gevoelige gegevens. Hoewel deze essentiële stap complex is, verbetert het in principe de veiligheid van de toepassing, omdat algemeen wordt aangenomen dat een kleine toepassing – in dit geval een toepassing die in de enclave draait – minder kans heeft op fouten en gemakkelijker te verifiëren is dan een grote. Communicatie tussen het beveiligde deel van de toepassing (binnen de enclave) en de rest van de toepassing (buiten de enclave) vindt plaats via aanroepen van functies die gedeclareerd moeten worden voordat de enclave wordt gelanceerd. Tenslotte kunnen toepassingen die geschreven zijn voor het SGX-platform niet gebruikt worden op andere platformen.

Leveranciers van IT-infrastructuren

Meerdere leveranciers van publieke IT-infrastructuren bieden vandaag oplossingen voor confidential computing gebaseerd op TEE’s. Hier beschrijven we de drie belangrijkste⁴.

AWS

Amazon definieert confidential computing als het gebruik van gespecialiseerde hardware en bijbehorende firmware om de code en gegevens van de klant tijdens de verwerking te beschermen tegen toegang van buitenaf. Amazon vertaalt dit in twee dimensies:

• Bescherming tegen de beheerder van de onderliggende IT-infrastructuur, in dit geval AWS;
• De mogelijkheid voor klanten om hun eigen workloads op te delen in meer of minder betrouwbare componenten, of om multi-agentsystemen te ontwerpen.

Amazon legt de nadruk op de architectuur van het Nitro-systeem, niet op de beschikbaarheid van een bepaalde microprocessor om een TEE te leveren. Sinds april 2023 biedt AWS echter ook de mogelijkheid om EC2-instanties te maken met AMD’s SEV-SNP-technologie (zie hier).

Het Nitro-systeem biedt volgens AWS geen enkel mechanisme waarmee systemen of personen verbinding kunnen maken met EC2-servers, het geheugen van EC2-instanties kunnen lezen of toegang kunnen krijgen tot opgeslagen gegevens. Onderhoudswerk kan alleen worden verricht via beperkte API’s.

Het AWS Nitro-systeem (Figuur 2) is onderdeel van een herziening van Amazons infrastructuur voor EC2-servicevirtualisatie, inclusief het minimaliseren van de onderdelen van de hypervisor die op het moederbord draait. Het AWS Nitro-systeem is een combinatie van servers, processors, beheercomponenten en gespecialiseerde firmware die het onderliggende platform vormt voor alle Amazon EC2-instanties. Het bestaat uit drie hoofdcomponenten:

• Specifieke Nitro Cards - Hardwareonderdelen ontworpen door AWS die zorgen voor algehele systeemcontrole en I/O-virtualisatie onafhankelijk van het moederbordvan het systeem met zijn processors en geheugen;
• Nitro-beveiligingschip - Deze is geïntegreerd in het moederbordvan de server en maakt veilig opstarten mogelijk op basis van een hardware root of trust, maakt het mogelijk om bare metal instances aan te bieden (waardoor de AWS-hypervisor overbodig wordt) en zorgt voor de bescherming van de server tegen ongeoorloofde wijzigingen in de firmware van het systeem;
• Nitro-hypervisor - Een geminimaliseerde, firmwareachtige hypervisor ontworpen om resource- en performance-isolatie te bieden.

Beveiligingsoverwegingen voor dit systeem staan gedetailleerd in [12].

Figuur 2 – Architectuur van een AWS-machine.

Nitro enclaves daarentegen zijn geïsoleerde virtuele machines die draaien op een klassieke EC2-instantie, een zogenaamde ‘parent instance’ (Figuur 3).

Volgens AWS biedt de Nitro enclave geen extra beveiliging ten aanzien van een AWS-operator [13], maar kan wel worden voorkomen dat een client-side administrator toegang krijgt tot de inhoud van de enclave (code en gegevens).

Figuur 3 – Een Nitro enclave maken van een EC2 instance. Een enclave wordt gemaakt door de CPU en het geheugen van een EC2 instance, de zogenaamde parent instance, te partitioneren. Enclaves kunnen worden gemaakt met verschillende combinaties van processorcores en geheugen.

De belangrijkste beperking van Nitro enclaves is dat de toepassing die in de enclave draait geen verbinding heeft met het netwerk. Ze kan alleen communiceren met de parent instance via een point-to-point interface genaamd ‘vsock’, die wordt gedefinieerd door een context identifier en een poortnummer⁵. Een eenvoudige ‘lift and shift’ is daarom niet mogelijk.

Wanneer het is aangemaakt, kan de toepassing die in de enclave draait een asymmetrisch sleutelpaar genereren en de publieke sleutel in het certificaat laten opnemen. Hierdoor kan de client-side applicatie die het attest verifieert deze sleutel gebruiken om beveiligde communicatie met de enclave tot stand te brengen.

Microsoft Azure

Microsoft Azure stelt drie types confidential computing voor gebaseerd op TEE’s:

• De toepassingsenclaves zijn gebaseerd op de SGX-technologie van Intel. Zoals eerder vermeld, is het noodzakelijk om de bestaande toepassingen grondig te wijzigen om ze aan te passen. Dit vereist veel denkwerk over welke delen van de toepassing beveiligd moeten worden en hun interactie met andere delen, maar het voordeel van deze aanpak is dat slechts een beknopte hoeveelheid code vertrouwd moet worden. Het nadeel is natuurlijk de complexiteit van de implementatie, die speciale training vereist voor analisten, architecten en programmeurs;
• De confidential virtual machines gebruiken AMD’s SEV-SNP-technologie (zie hier) en Microsoft kondigde in april 2023 aan dat ze binnenkort Intels TDX-technologie beschikbaar zou stellen (zie hier) [14]. Azure stelt tevens een ‘trusted platform module’ (TPM) voor, die met name wordt gebruikt voor het attesteren van virtual machines;
• De confidential containers geven de klant een preciezere mate van controle over de TCB dan virtuele machines. In principe maakt dit verpakkingsmodel het mogelijk om bestaande containers in een SGX enclave te draaien zonder dat de software aangepast of opnieuw gecompileerd hoeft te worden (“lift and shift”).

De optie om meerdere threads parallel te laten draaien (“hyper threading”-technologie) binnen dezelfde processor is uitgeschakeld op alle SGX instances. Dit voorkomt aanvallen die leiden tot datalekken tussen toepassingen die dezelfde processor delen.

Google

Google stelt verschillende manieren voor om confidential computing op zijn infrastructuur te implementeren:

• Confidential virtual machines maken gebruik van AMD’s technologie;
• Confidential Kubernetes nodes zijn ook gebaseerd op AMD’s SEV-technologie. De Kubernetes engine van Google kan het gebruik van confidential virtual machines voor alle Kubernetes nodes afdwingen.

Terwijl alle confidential virtual machines virtuele TPM’s bevatten die de integriteit van een virtuele machine valideren bij een gemeten opstart, bieden confidential virtual machines met SEV-SNP-technologie ook hardware cryptografisch ondertekende attestrapporten. SEV-SNP-technologie is echter nog niet algemeen beschikbaar op de infrastructuur van Google.

Praktische limiet van attesten

Zoals uitgelegd in ons vorige artikel, is een belangrijk punt bij het gebruik van TEE’s het verkrijgen van een garantie dat de software die draait op de gehuurde infrastructuur echt de software is die de klant verwacht en dat de gegevens die hij verwerkt niet kunnen worden gelezen door andere software. Deze garantie, een attest genoemd en verkregen via een betrouwbaar mechanisme, moet volledige, recente en semantisch expliciete informatie bevatten [15].

Ervan uitgaande dat we de fysieke veiligheid van de microprocessor of gespecialiseerde chip vertrouwen, dat bekende aanvallen zijn afgeweerd en dat de enclavecode niet kwetsbaar is voor side channel attacks, hoe kunnen we er dan zeker van zijn dat de output van een enclave betrouwbaar is?

Er moet voor gezorgd worden dat:

• De binary file die in de enclave wordt uitgevoerd, gebouwd is met de verwachte code. Hiervoor kan de klant zijn toepassing compileren op een vertrouwde machine (bijvoorbeeld een machine die hij bezit) en vervolgens de binary veilig kopiëren naar het confidential IT-platform. Een andere methode is om een reproducible build system⁶ te gebruiken;
• De binary file die wordt uitgevoerd overeenkomt met het verwachte binary. Een attestsysteem gebruikt cryptografische sleutels afgeleid van vaste geheimen in de vertrouwde microprocessor om een bewijs te ondertekenen dat de binary zich in een bepaalde toestand bevindt op echte hardware (geen simulatie). Het bewijs bevat een meting (cryptografische hashwaarde) van de binary;
• De staat van de toepassing bij het starten is de verwachte staat: het meten van het uitvoerbare deel van de binary is niet voldoende om het toekomstige gedrag te voorspellen;
• Het attest is ondertekend door een vertrouwde entiteit, in principe de fabrikant van de microprocessor of de beveiligde chip.

In de bestudeerde oplossingen, met uitzondering van SGX enclaves, wordt het attest echter ofwel ondertekend door de leverancier van de infrastructuur (en niet door de hardwarefabrikant), ofwel is het niet mogelijk om de meting van de beveiligde software te verifiëren omdat deze proprietary libraries bevat. Het risico bestaat dus dat de gecertificeerde entiteit liegt over haar status.

Conclusie

Tien jaar na de onthullingen van Edward Snowden in juni 2013, betreffende de Amerikaanse surveillancemethoden, moeten we ervan uitgaan dat informatie bemachtigd kan worden als deze voldoende waardevol is. De indruk dat nationale IT-infrastructuren veiliger zijn, kan daarom misleidend zijn⁷. Er bestaat namelijk een spanningsveld tussen het verlangen naar onafhankelijkheid van de IT-diensten van de Staat en het vermogen om het niveau van middelen (hardware, personeel, R&D), redundantie en beveiliging te evenaren dat aangeboden wordt door de dominante bedrijven in de sector⁸. Confidential computing gebaseerd op TEE’s brengt een nieuw argument ten voordele van publieke IT-infrastructuren.

Als ze correct worden geïmplementeerd, en alle andere zaken onveranderd blijven, kunnen TEE’s op basis van fysieke componenten het niveau van gegevensbescherming binnen een IT-infrastructuur aanzienlijk verhogen, met name ten opzichte van derden en in het bijzonder cybercriminelen⁹. Ze maken het in feite mogelijk om de meeste logische aanvallen te vermijden die conventionele systemen treffen, dankzij verbeterde procesisolatie, geheugenversleuteling via de hardwarelaag, veilig opstarten, controlemechanismen voor firmware-updates en, in het algemeen, een vermindering van de omvang van de trusted computing base. Met andere woorden, de veiligheidsmaatregelen opgenomen in de TEE’s maken een aanval aanzienlijk complexer en duurder.

Het aanbod van op TEE-gebaseerde confidential computing varieert tussen leveranciers, afhankelijk van het type abstractie dat wordt aangeboden: software library, container, virtuele machine. De keuze van deze opties leidt tot verschillen in de omvang van de trusted code base (en dus het oppervlak dat blootgesteld wordt aan aanvallen), maar ook in de inspanning die nodig is om bestaande toepassingen aan te passen aan deze nieuwe omgevingen.

Bij het kiezen van een op TEE-gebaseerde oplossing voor confidential computing moeten daarom de volgende punten worden gecontroleerd:

• Bescherming moet verankerd zijn in de fysieke laag van het systeem en elk apparaat moet een unieke identiteit hebben;
• Het attestmechanisme moet het mogelijk maken om de inhoud¹⁰ te verifiëren van de TEE op onafhankelijke wijze van de infrastructuurleverancier¹¹;
• Het attest moet ten minste ondertekend worden door de fabrikant van de fysieke component en niet alleen door de infrastructuurleverancier¹²;
• De dienst stelt ten minste in staat om eigen crypotografische sleutels te importeren in een toegewijde hardware-beveiligingsmodule (HSM), en in het beste geval om een eigen HSM te gebruiken;
• Het moet mogelijk zijn om de source code van de critical libraries die in de trust base zijn opgenomen door de infrastructuurleverancier te controleren op de goede werking van de klanttoepassing;
• De infrastructuurleverancier moet de klant een dienst ter beschikking stellen waarmee de verschillende software dependencies, compilatieomgevingen en binaries die voor de TEE worden gebruikt, kunnen worden getraceerd.

Tot slot is de gegevensbescherming aangeboden door confidential computing tijdens gebruik slechts één van de vele technische aspecten die in overweging moeten worden genomen met betrekking tot de vertrouwelijkheid van gevoelige gegevens (om nog maar te zwijgen van de juridische, economische en politieke aspecten). Net zoals het beste slot op de voordeur van een huis het probleem van een wijd openstaande achterdeur niet oplost, gaat het gebruik van confidential computing ervan uit dat gegevens in rust en in transit effectief worden beschermd, maar vereist het ook specifieke training voor de mensen die verantwoordelijk zijn voor het aanpassen (in meer of mindere mate afhankelijk van het gekozen type confidential computing) en migreren van bestaande toepassingen, in het bijzonder analisten, architecten en programmeurs.

Bibliografie

[1]        A. Linn, ‘Securing the cloud | Microsoft Story Labs’, Securing the cloud | Microsoft Story Labs, 2017. http://news.microsoft.com/stories/cloud-security (geraadpleegd 6 juni 2023).

[2]        M. U. Sardar en C. Fetzer, ‘Confidential computing and related technologies: a critical review’, Cybersecurity, vol. 6, nr. 1, p. 10, mei 2023, doi: 10.1186/s42400-023-00144-1.

[3]        D. Kaplan, ‘AMD x86 Memory Encryption Technologies’, augustus 2016. Geraadpleegd: 11 mei 2023. [Online]. Beschikbaar op: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kaplan

[4]        D. Kaplan, J. Powell, en T. Woller, ‘AMD Memory Encryption’, White Paper, okt. 2021. Geraadpleegd: 1 mei 2023. [Online]. Beschikbaar op: https://www.amd.com/system/files/TechDocs/memory-encryption-white-paper.pdf

[5]        ‘AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More’, AMD, jan. 2020.

[6]        ‘Secure Encrypted Virtualisation API Version 0.24’, Specification, apr. 2020. [Online]. Beschikbaar op: https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf

[7]        Victor Costan en Srinivas Devadas, ‘Intel SGX Explained’. Cryptology ePrint Archive, 2016. [Online]. Beschikbaar op: https://eprint.iacr.org/2016/086

[8]        P.-C. Cheng e.a., ‘Intel TDX Demystified: A Top-Down Approach’. arXiv, 27 maart 2023. Geraadpleegd: 23 mei 2023. [Online]. Beschikbaar op: http://arxiv.org/abs/2303.15540

[9]        ‘Intel 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4’. Intel Corporation, maart 2023. [Online]. Beschikbaar op: https://cdrdv2.intel.com/v1/dl/getContent/671200

[10]       A. Rao, ‘Rising to the Challenge — Data Security with Intel Confidential Computing’, 20 januari 2022. https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/1353141 (geraadpleegd 17 mei 2023).

[11]       G. Steer, ‘Finance’s big tech problem’, Financial Times, 6 juli 2022. Geraadpleegd: 10 juli 2023. [Online]. Beschikbaar op: https://www.ft.com/content/41f400b6-f83f-4fa1-8dac-731acddcf8f2

[12]       ‘The Security Design of the AWS Nitro System - AWS Whitepaper’. AWS, 18 november 2022. [Online]. Beschikbaar op: https://docs.aws.amazon.com/fr_fr/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html

[13]       ‘Confidential computing: an AWS perspective | AWS Security Blog’, 24 augustus 2021. https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/ (geraadpleegd 18 april 2023).

[14]       M. McReynolds, ‘Preview: Introducing DCesv5 and ECesv5-series Confidential VMs with Intel TDX’, 24 april 2023. https://techcommunity.microsoft.com/t5/azure-confidential-computing/preview-introducing-dcesv5-and-ecesv5-series-confidential-vms/ba-p/3800718 (geraadpleegd 16 mei 2023).

[15]       G. Coker e.a., ‘Principles of remote attestation’, Int. J. Inf. Secur., vol. 10, nr. 2, pp. 63-81, jun. 2011, doi: 10.1007/s10207-011-0124-7.

[16]       ‘Nix & NixOS | Reproducible builds and deployments’. https://nixos.org/ (geraadpleegd 6 juni 2023).

[17]       R. Gallagher, ‘The Inside Story of How British Spies Hacked Belgium’s Largest Telco’, The Intercept, 13 december 2014. https://theintercept.com/2014/12/13/belgacom-hack-gchq-inside-story/ (geraadpleegd 8 juni 2023).

[18]       R. Gallagher, ‘How U.K. Spies Hacked a European Ally and Got Away With It’, The Intercept, 17 februari 2018. https://theintercept.com/2018/02/17/gchq-belgacom-investigation-europe-hack/ (geraadpleegd 8 juni 2023).

[19]       C. Zhao, ‘SolarWinds, Probably Hacked by Russia, Serves White House, Pentagon, NASA’, Newsweek, 14 december 2020. Geraadpleegd: 9 januari 2023. [Online]. Beschikbaar op: https://www.newsweek.com/solar-winds-probably-hacked-russia-serves-white-house-pentagon-nasa-1554447

[20]       R. Koppel en C. Kuziemsky, ‘Healthcare Data Are Remarkably Vulnerable to Hacking: Connected Healthcare Delivery Increases the Risks’, Stud. Health Technol. Inf., vol. 257, pp. 218-222, 2019.

Noten

¹   Bijvoorbeeld: de term “enclave” heeft een compleet andere betekenis bij Amazon en Intel. Waar “Nitro Enclaves” volledig virtuele machines zijn, zijn de “SGX Enclaves” bibliotheken die bepaalde API’s beschikbaar stellen.

²   We moeten opmerken dat NVIDIA onlangs een grafische processor heeft aangeboden (A100 Tensor Core met de technologie Ampere Protected Memory (APM)) die een vertrouwelijke uitvoeringsmodus introduceert in de grafische processor. Deze maakt het mogelijk om datasets te gebruiken en zo modellen voor machine learning op een vertrouwelijke manier te trainen en in te zetten, met name op een publieke IT-infrastructuur. Deze processors zijn beschikbaar op de Azure-cataloog van Microsoft.

³   Dit is niet het geval met TDX, die een hele virtuele machine kan beschermen.

⁴   Volgens de Financial Times waren de drie belangrijkste leveranciers van IT-infrastructuur in 2021 Amazon, Microsoft en Google [11].

⁵   Deze ‘vsock’ gebruikt dezelfde API als POSIX ‘sockets’.

⁶   Bijvoorbeeld Nix [16].

⁷   In 2014 kwamen we te weten dat GCHQ, de Britse surveillanceagentschap, een gevoelig systeem van Belgacom had gehackt [17], [18].

⁸   Cybercriminele groepen aarzelen niet langer om de veiligheid van IT-services te ondermijnen door nieuwe soorten aanvallen uit te zetten. Het voorbeeld van hacking van SolarWind is in dit opzicht symptomatisch [19]. Een nationaal onafhankelijke, maar onvoldoende beveiligde dienst zou een single point of failure vormen die een kritiek risico inhoudt.

⁹   “Gezondheidsgegevens zijn aantrekkelijk voor cybercriminelen omdat ze financiële en persoonlijke gegevens bevatten, die gebruikt kunnen worden voor chantage en bovenal ideaal zijn voor frauduleuze facturering” [20].

¹⁰   Deze inhoud omvat, in het geval van confidential virtual machines, ook het besturingssysteem dat een minimale grootte moet hebben.

¹¹ Als de infrastructuurleverancier gedeeltelijk de inhoud controleert van de confidential virtual machine of de confidential container en dat de klant geen mechanisme heeft om dit te verifiëren, dan blijft het vertrouwen in de leverancier ongeschonden.

¹² Indien de infrastructuurleverancier het attest ondertekent, dan blijft het vertrouwen in deze leverancier totaal.

_________________________

Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Nederlandstalige versie

Modèles de langue

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

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

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

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

Question answering basé sur des modèles de langue 

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

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

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

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

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

Frameworks

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

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

Qualité du output

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

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

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

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

Conclusion

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

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

Version en français

Retrieval Augmented Generation (RAG)

In de context van generatieve AI is er veel interesse in “chat with your data” toepassingen waarbij je vragen kunt stellen over bedrijfseigen informatie. Grote taalmodellen (LLM’s – Large Language Models) zoals GPT-4 zijn in staat om taalkundig correcte tekst te genereren. Standaard gebeurt dat op basis van de gegevens waarop ze getraind zijn. Die kennis is echter beperkt in de tijd; het taalmodel heeft geen kennis van meer recente gebeurtenissen en informatie. Men spreekt van een knowledge cut-off op een bepaalde datum. Een taalmodel heeft ook geen toegang tot bedrijfseigen informatie. Om antwoorden te verkrijgen omtrent recentere gegevens of eigen gegevens, moeten deze op één of andere manier aangeleverd worden aan het taalmodel. Enter de Retrieval Augmented Generation (RAG) architectuur. Dit is een aanpak waarbij de prompt – dit is de input die men geeft aan het taalmodel – verrijkt wordt met de meest relevante stukken tekst uit een informatiebron. Op die manier kan het taalmodel toch antwoorden formuleren op basis van eigen informatiebronnen.

Figuur 1: Uitvoeringsfase van een RAG pipeline

Een initiële basisversie van zo’n generatieve question answering toepassing is snel opgezet, maar de échte uitdaging zit in het bekomen van een zekere kwaliteit van de antwoorden.

Hieronder geven we een aantal technieken mee die de kwaliteit kunnen helpen verbeteren. Deze lijst is niet exhaustief, maar geeft in grote lijnen aan op welke vlakken er verbeteringen mogelijk zijn.

Ingestion fase

Ingestion is de voorbereidende fase waarin de originele gegevensbronnen (knowledge base) omgevormd worden en bijgehouden worden in een vector store index. Uit die vector store index kunnen dan in de uitvoeringsfase de meest relevante stukken tekst opgehaald worden (retrieval) om die mee te geven als context aan het taalmodel voor het genereren van het antwoord.

Figuur 2: Ingestion fase van een RAG pipeline

Knowledge base en data extractie

De eerste stap in de ingestion pipeline is het extraheren van de tekst uit de knowledge base. De kwaliteit van de gegevens die uiteindelijk in de index zullen belanden, bepaalt in hoge mate de kwaliteit van het uiteindelijk antwoord. Daarom is het nuttig om niet-relevante informatie weg te filteren en de knowledge base eventueel uit te breiden met bijkomende bronnen die wél relevante informatie bevatten.

Chunking

Een volgende stap is het opsplitsen van de originele tekst in kleinere delen (chunks) zodat kleine, coherente stukken tekst kunnen opgezocht worden die relevant zijn voor de inputvraag en als context kunnen meegegeven worden aan het taalmodel voor het genereren van een antwoord.

Dat opsplitsen (chunking) kan op verschillende manieren gebeuren. De meest eenvoudige techniek is om te splitsen volgens een vast aantal characters. Een testomgeving zoals de open source LangChain Text Splitter Playground laat toe om te experimenteren met de grootte (chunk size) en de eventuele overlap tussen de stukken tekst (chunk overlap). Te grote chunks kunnen irrelevante informatie bevatten en te kleine chunks mogelijk te weinig.

Nog beter dan opsplitsen volgens een vast aantal characters is om de tekst op te splitsen op basis van de structuur. Een minimum hierbij is om zinnen of paragrafen in zijn geheel te behouden. Dat kan bijvoorbeeld met de RecursiveCharacterTextSplitter van LangChain. We kunnen daarenboven ook rekening houden met de structuur van documenten. Een voorbeeld hiervan is de HTMLHeaderTextSplitter die toelaat om een HTML document op te splitsen op basis van bepaalde header elementen (h1, h2, etc). Zo zijn de chunks meer één coherent geheel.

Finetunen van het embedding model

De laatste stap voor het creëren van de index is het aanmaken van vector embeddings op basis van de tekst chunks. Een embedding model zet de chunks en de inputvraag om naar embeddings. Dat zijn multi-dimensionele vectoren die de semantiek van de tekst capteren. Dat laat toe om die stukken tekst op te zoeken die semantisch het meest gerelateerd zijn aan de inputvraag.

Het is duidelijk dat het embedding model een belangrijke bijdrage kan leveren aan de kwaliteit van het vraag-antwoordsysteem. De keuze van het embeddings model moet gealigneerd zijn met de noden van het project, zoals ondersteuning voor meertalige content. Eventueel kan het embedding model gefinetuned worden om domein-eigen termen beter te capteren. Dat vereist echter een zekere effort.

Uitvoeringsfase

De uitvoeringsfase is de fase waarbij de inputvraag van de gebruiker verwerkt wordt en via de retrieval en generation stappen uiteindelijk leidt tot een gegenereerd antwoord. Ook en vooral in deze fase zijn er een aantal technieken die de kwaliteit van het eindresultaat gunstig kunnen beïnvloeden.

Hybrid search

Eenmaal de content voorbereid is en de index opgebouwd werd, is de vraag hoe we díe stukken tekst kunnen vinden die het meest relevant zijn voor de inputvraag. De meest eenvoudige techniek is semantic search: voor de gegeven inputvraag zoeken we de k “dichtste”, meest semantisch gerelateerde, stukken tekst in de vectorruimte.

Hybrid search is een combinatie van een tekstuele zoekopdracht (lexical search of keyword search) en semantic search op basis van een index die zowel gewone tekst bevat als vector embeddings.

Het voordeel van vector search is dat informatie kan teruggevonden worden die semantisch verband houdt met de inputvraag, zelfs als er geen keyword matches zijn. Zo kan de vraag “hoe oud moet ik zijn voor een studentenjob” toch gelinkt worden aan een fragment als “de minimumleeftijd is 16 jaar”. Het voordeel van lexical search is dan weer de precisie door het exact matchen van woorden.

Beide zoekopdrachten – lexicaal en semantisch – worden in parallel uitgevoerd en de resultaten van beide zoekopdrachten worden gecombineerd in één lijst van resultaten. Die resultaten worden vervolgens opnieuw gerangschikt (re-ranking) volgens hun relevantie ten opzichte van de inputvraag. Deze belangrijke stap zorgt ervoor dat de meest relevante resultaten teruggegeven worden, los van het feit of ze nu het resultaat zijn van een semantische zoekopdracht of lexicale zoekopdracht. Een dergelijke re-ranking stap is in het bijzonder nuttig bij retrieval technieken die een uitgebreide of diverse lijst van documenten teruggeven, zoals query expansion (zie hieronder).

Technieken met betrekking tot de inputvraag

Een aantal technieken zijn erop gericht om de input voor de retriever uit te breiden (query expansion) om de resultaten van de retrieval te verbeteren. De retrieval kan immers verschillende resultaten opleveren door subtiele wijzigingen in de inputvraag of indien de embeddings de semantiek van de gegevens niet goed capteren.

Multi-query retriever – Deze eerste techniek maakt gebruik van een LLM om op basis van de originele inputvraag bijkomende vragen te genereren, als varianten op de originele inputvraag. Voor elk van die vragen (inclusief de originele vraag) wordt een retrieval uitgevoerd van de relevante documenten. Uiteindelijk wordt de combinatie van alle resultaten teruggeven. Op die manier wordt getracht om een rijkere, diversere set van resultaten te bekomen bij de retrieval.

HyDE (Hypothetical Document Embeddings) is een methode waarbij door middel van een extra LLM oproep een hypothetisch antwoord gegenereerd wordt voor de gegeven inputvraag. Zowel dat hypothetisch antwoord als de originele inputvraag dienen dan als input voor de retrieval. De onderliggende gedachte is dat het hypothetische antwoord dichter bij de relevante documenten kan liggen in de embedding space, in vergelijking met de inputvraag.

Sub-queries – Een complexe of samengestelde inputvraag kan opgesplitst worden in meerdere eenvoudigere vragen (sub-queries). Dat kan uiteindelijk leiden tot meer relevante antwoorden omdat elke deelvraag afzonderlijk kan worden behandeld.

Query re-writing – Tenslotte kunnen lange vragen door een LLM samengevat worden tot de essentie (re-writing), wat de kwaliteit van de retrieval ten goede kan komen.

Merk op dat de bovenstaande technieken gebruik maken van een LLM en als gevolg een hogere totale kost kunnen hebben. Het finale antwoord kan ook langer op zich laten wachten door het uitvoeren van de extra LLM oproepen.

Verrijken van de context

Het idee van onderstaande technieken is om meer context mee te geven aan het taalmodel (zie LLM generator stap in figuur 1) dan enkel de kleine chunks op zich die we bekomen tijdens de retrieval.

Sentence window retriever – Bij deze techniek wordt initieel een specifieke zin (sentence) opgehaald die het meest relevant is voor de inputvraag. Die zin wordt dan uitgebreid met een breder venster van zinnen vóór en na de zin in kwestie. Zo kan meer context meegegeven worden aan het taalmodel voor het genereren van een antwoord, wat uiteindelijk tot een beter antwoord kan leiden.

Auto-merging retriever (of Parent document retriever) – Hier wordt elke chunk initieel opgesplitst in een hiërarchische structuur van een parent node en leaf nodes. Tijdens de retrieval worden de meest relevante leaf nodes gezocht. Als een bepaald aantal van de leaf nodes van een parent node matchen met de inputvraag, dan wordt een merging uitgevoerd van de kleinere leaf nodes in de grotere parent node en wordt de volledige parent node meegegeven als context aan het taalmodel.

Post-processing

Na de retrieval stap, maar vóór het aanroepen van het taalmodel voor het genereren van het antwoord, kan de lijst van opgehaalde documenten nog bijgewerkt worden om de kwaliteit van het antwoord positief te beïnvloeden.

Re-ranking – Het kan nuttig zijn om de opgehaalde documenten opnieuw te ordenen op basis van relevantie, met de hulp van een model. Dit is een stap die in het bijzonder nuttig is bij retrieval technieken die een uitgebreide of diverse lijst van documenten teruggeven, zoals multi-query retrieval.

Compression – Gewoon maar méér context aanleveren uit het idee dat “het antwoord er wel ergens zal instaan” doet geen goed aan de kwaliteit van het antwoord. Het taalmodel krijgt het moeilijker om de echt relevante informatie terug te vinden in de context. Daarom kan het nuttig zijn om redundante en overtollige informatie uit de opgehaalde documenten te halen.

Prompt engineering en finetuning van het taalmodel

Waar de vorige technieken zich toeleggen op het optimaliseren van het aanleveren van een optimale context aan het taalmodel, zijn er ook technieken die gericht zijn op de manier waarop het model te werk moet gaan. Prompt engineering is de kunst om de juiste instructies te geven aan het taalmodel. Few-shot prompting is een techniek waarbij één of enkele voorbeelden gegeven worden van de input en de output die verwacht wordt van het taalmodel.

Het taalmodel op zich kan gefinetuned worden zodat het bepaalde instructies beter opvolgt of beter omgaat met bedrijfseigen terminologie. Dit vereist echter een zekere effort en is duidelijk geen laaghangend fruit.

Conclusie

Er zijn heel wat technieken die kunnen helpen om de kwaliteit van de antwoorden in een generatief vraag-antwoordsysteem te verbeteren. In dit artikel hebben we er slechts enkele van besproken. In onze ervaring levert een hybride search al een significante verbetering op van de accuraatheid van de antwoorden. Andere technieken kunnen zeker ook hun nut bewijzen, afhankelijk van de specifieke noden van het project; er is geen “one-size-fits-all” oplossing.

Zelfs indien we finaal een hoge kwaliteit bekomen, kunnen er toch nog fouten opduiken en moeten we hiermee rekening houden, zowel op vlak van verwachtingsbeheer als op juridisch vlak. Zo is een melding dat het antwoord gegenereerd werd door AI onontbeerlijk en moet de eindgebruiker zich hiervan bewust zijn. Feedback van eindgebruikers is een goede manier om zicht te krijgen op de kwaliteit van het systeem en om voortdurend te kunnen bijsturen waar nodig.

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.

Nederlandstalige versie

Retrieval Augmented Generation (RAG)

Dans le contexte de l’IA générative, les applications “chat with your data” qui permettent de poser des questions sur des informations propriétaires suscitent un vif intérêt. Les grands modèles de langage (LLM – Large Language Models) tels que GPT-4 sont capables de générer des textes linguistiquement corrects. Par défaut, ils opèrent sur la base des données sur lesquelles ils sont entraînés. Ces connaissances sont toutefois limitées dans le temps. En effet, le modèle de langage n’a pas connaissance d’événements et informations plus récents. On parle de knowledge cut-off à une certaine date. De même, un modèle de langage n’a pas accès à des informations propriétaires. Pour obtenir des réponses concernant des données plus récentes ou des données propriétaires, celles-ci doivent être transmises au modèle de langage d’une manière ou d’une autre. C’est là qu’intervient l’architecture Retrieval Augmented Generation (RAG). Il s’agit d’une approche dans laquelle le prompt, c’est-à-dire l’entrée communiquée au modèle de langage, est enrichi des éléments de texte les plus pertinents en provenance d’une source d’information. De cette manière, le modèle de langage est bel et bien en mesure de formuler des réponses sur la base de sources d’information propres.

Illustration 1 : Phase d’exécution d’un pipeline RAG

Si une version de base d’une telle application générative de questions-réponses peut être mise sur pied rapidement, le véritable défi consiste à livrer des réponses de qualité.

Nous présenterons ci-dessous diverses techniques qui peuvent aider à améliorer la qualité. Cette liste n’est pas exhaustive, mais offre un aperçu succinct des améliorations possibles.

Phase d’ingestion

La phase dite Ingestion est la phase préparatoire au cours de laquelle les sources de données originales (base de connaissances) sont converties et stockées dans une base de données vectorielle (vector store).
Dans la phase d’exécution, les fragments de texte les plus pertinents peuvent ensuite être extraits (retrieval) de ce vector store pour être livrés à titre de contexte au modèle de langage en vue de la génération de la réponse.

Illustration 2 : Phase d’ingestion d’un pipeline RAG

Base de connaissances et extraction de données

La première étape du pipeline Ingestion consiste à extraire le texte de la base de connaissances. La qualité des données qui atterriront dans l’index détermine largement la qualité de la réponse finale. Aussi convient-il d’écarter les informations non pertinentes et éventuellement d’enrichir la base de connaissances avec des sources complémentaires qui, quant à elles, contiennent bel et bien des informations pertinentes.

Chunking

L’étape suivante consiste à scinder le texte original en fragments plus petits (chunks). Cela permet de cibler des fragments de textes cohérents et en lien avec la question d’entrée pouvant servir de contexte au modèle de langage.

Cette scission (chunking) peut s’effectuer de plusieurs manières. La technique la plus simple vise à scinder le texte sur la base d’un nombre fixe de caractères. Un environnement de test comme l’open source LangChain Text Splitter Playground permet d’expérimenter la taille (chunk size) et l’éventuel chevauchement de fragments de texte (chunk overlap). Les chunks trop grands peuvent contenir des informations superflues, tandis que les chunks trop petits sont susceptibles de contenir trop peu d’informations.

Mieux encore que de scinder le texte sur la base d’un nombre fixe de caractères, il est possible de scinder le texte sur la base de sa structure. Il s’agit ici à tout le moins de conserver les phrases ou les paragraphes dans leur ensemble. Cette opération peut être réalisée par exemple avec le RecursiveCharacterTextSplitter de LangChain. Il est en outre possible de tenir compte de la structure des documents. Citons par exemple l’outil HTMLHeaderTextSplitter, qui permet de scinder un document HTML sur la base de certains éléments d’en-tête (h1, h2, etc.). De cette manière, les chunks forment un ensemble plus cohérent

Affinement du modèle d’embedding

La dernière étape avant la création de l’index est la création d’embeddings vectoriels basés sur les chunks. Un modèle d’embedding convertit en embeddings les chunks et la question d’entrée. Il s’agit de vecteurs multidimensionnels qui saisissent la sémantique du texte. Cela permet de rechercher les fragments de texte les plus liés sémantiquement à la question d’entrée.

Il est clair que le modèle d’embedding peut largement contribuer à la qualité du système de questions-réponses. Le choix du modèle d’embedding doit être aligné sur les besoins du projet, tels que la prise en charge d’un contenu multilingue. Le cas échéant, le modèle d’embedding peut être affiné pour mieux saisir les termes spécifiques à un domaine. Cela requiert toutefois un certain effort.

Phase d’exécution

La phase d’exécution est la phase au cours de laquelle la question d’entrée de l’utilisateur est traitée pour au final aboutir à la génération d’une réponse via les étapes d’extraction (retrieval) et de génération (generation). C’est aussi et surtout lors de cette phase que diverses techniques peuvent influencer favorablement la qualité du résultat final.

Recherche hybride

Une fois le contenu préparé et l’index construit, la question est de savoir comment trouver les fragments de texte qui répondent à la question d’entrée. La technique la plus simple est la recherche sémantique : pour la question d’entrée, il s’agit de rechercher les fragments de texte les plus “proches” et les plus sémantiquement liés dans l’espace vectoriel.

La recherche hybride combine une recherche textuelle (recherche lexicale ou recherche par mots-clés) et une recherche sémantique sur la base d’un index contenant à la fois du texte brut et des embeddings vectoriels.

L’avantage de la recherche vectorielle est qu’elle permet de trouver des informations sémantiquement corrélées à la question d’entrée, même en l’absence d’une correspondance de mots-clés. Par exemple, la question “Quel âge dois-je avoir pour un job d’étudiant ?” peut bel et bien être liée à un fragment tel que “à partir de 16 ans“. L’avantage de la recherche lexicale réside dans la précision apportée par la correspondance exacte des mots.

Les deux recherches – lexicale et sémantique – sont exécutées en parallèle et les résultats de ces deux recherches sont combinés en une seule liste de résultats. Ces résultats sont ensuite reclassés (re-ranking) en fonction de leur pertinence par rapport à la question d’entrée.
Cette étape importante garantit que les résultats les plus pertinents sont restitués, qu’ils soient le fruit d’une recherche sémantique ou d’une recherche lexicale. Cette étape de reclassement est particulièrement utile dans les techniques d’extraction qui restituent une liste étendue ou diversifiée de documents, comme la query expansion (voir ci-dessous).

Techniques concernant la question d’entrée

Un certain nombre de techniques ont pour but d’élargir l’entrée pour l’extracteur (query expansion) afin d’améliorer les résultats de l’extraction. En effet, l’extraction peut produire des résultats différents en raison de changements subtils dans la question d’entrée ou si les embeddings ne saisissent pas correctement la sémantique des données.

Multi-query retriever – Cette première technique utilise un LLM pour générer des questions supplémentaires basées sur la question d’entrée originale, comme variantes de la question d’entrée originale. Pour chacune de ces questions (y compris la question originale), une extraction des documents est exécutée. Enfin, la combinaison de tous les résultats est restituée. Le but est ainsi d’obtenir un ensemble de résultats plus riche et plus diversifié lors de l’extraction.

HyDE (Hypothetical Document Embeddings) est une méthode qui consiste à générer une réponse hypothétique pour la question d’entrée au moyen d’un appel supplémentaire au LLM. Cette réponse hypothétique et la question d’entrée originale servent alors d’entrée pour l’extraction. L’idée sous-jacente est que la réponse hypothétique peut être plus proche des documents pertinents dans l’espace d’embedding, en comparaison de la question d’entrée.

Sub-queries – Une question d’entrée complexe ou composée peut être divisée en plusieurs questions plus simples (sub-queries). Cela permet d’obtenir des réponses plus pertinentes, car chaque sous-question peut être traitée séparément.

Query re-writing – Enfin, les longues questions peuvent être résumées à l’essentiel (re-writing) par un LLM, ce qui peut profiter à la qualité de l’extraction.

Notons que les techniques ci-dessus recourent à un LLM et peuvent dès lors avoir un coût global plus élevé. La réponse finale peut aussi prendre plus de temps à parvenir en raison de l’exécution des appels supplémentaires au LLM.

Enrichissement du contexte

L’idée des techniques ci-dessous est d’apporter plus de contexte au modèle de langage (voir l’étape de génération du LLM dans l’illustration 1) que les seuls petits chunks obtenus lors de l’extraction.

Sentence window retriever – Cette technique consiste à initialement extraire une phrase (sentence) spécifique qui est la plus pertinente pour la question d’entrée. Cette phrase est ensuite élargie avec une fenêtre plus large de phrases avant et après la phrase en question. Ainsi, le modèle de langage peut bénéficier d’un contexte plus large pour générer une réponse, ce qui peut aboutir à une meilleure réponse.

Auto-merging retriever (ou Parent document retriever) – Ici, chaque chunk est initialement divisé selon une structure hiérarchique composée d’un parent node et de leaf nodes. Lors de l’extraction, les leaf nodes les plus pertinents sont recherchés. Si un certain nombre de leaf nodes d’un parent node correspondent à la question d’entrée, les leaf nodes plus petits sont fusionnés dans le parent node plus grand et l’intégralité du parent node est transmise à titre de contexte au modèle de langage.

Post-traitement

Après l’étape d’extraction, mais avant l’appel au modèle de langage pour générer la réponse, la liste des documents extraits peut encore être actualisée pour optimiser la qualité de la réponse.

Re-ranking – Il peut être utile de reclasser les documents extraits en fonction de leur pertinence, à l’aide d’un modèle. Cette étape est particulièrement utile dans les techniques d’extraction qui restituent une liste étendue ou diversifiée de documents, comme le multi-query retrieval.

Compression – Le simple fait de fournir plus de contexte dans l’idée que “la réponse se trouve quelque part” n’améliore pas la qualité de la réponse. Le modèle de langage a en effet plus de mal à trouver les informations réellement pertinentes dans le contexte. Il peut dès lors être utile d’éliminer les informations redondantes et superflues des documents récupérés.

Prompt engineering et affinement du modèle de langage

Si les techniques susmentionnées visent à optimiser la fourniture d’un contexte optimal au modèle de langage, il existe également des techniques axées sur la manière dont le modèle doit procéder. Le prompt engineering désigne l’art de communiquer les bonnes instructions au modèle de langage. Le few-shot prompting est une technique qui consiste à donner un ou plusieurs exemples de l’entrée et de la sortie attendues du modèle de langage.

Le modèle de langage proprement dit peut être affiné de manière à mieux suivre certaines instructions ou mieux gérer la terminologie spécifique. Cela demande toutefois un gros effortet n’est clairement pas évident à réaliser.

Conclusion

De nombreuses techniques peuvent contribuer à améliorer la qualité des réponses dans un système génératif de questions-réponses. Dans cet article, nous n’en avons abordé que quelques-unes. D’après notre expérience, une recherche hybride permet déjà d’améliorer considérablement la précision des réponses. D’autres techniques peuvent certainement s’avérer utiles, en fonction des besoins spécifiques du projet ; il n’existe pas de solution universelle.

Même si nous parvenons finalement à une qualité élevée, des erreurs demeurent possibles et celles-ci doivent être prises en compte, tant sur le plan de la gestion des attentes des utilisateurs que sur le plan juridique. Une notification indiquant que la réponse est le produit de l’intelligence artificielle est donc indispensable et l’utilisateur final doit en être conscient. Le retour d’information des utilisateurs finaux est un bon moyen d’évaluer la qualité du système et de procéder à des ajustements constants si nécessaire.

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

In een vorige blogpost hebben we een aantal technieken beschreven voor het verbeteren van de kwaliteit van de antwoorden in een generatief vraag-antwoordsysteem.

Ter herinnering, RAG (Retrieval Augmented Generation) is de aangewezen architectuur om hallucinaties te vermijden door taalmodellen van context te voorzien. Vooraleer het taalmodel een antwoord genereert, wordt eerst de meest relevante informatie voor de vraag opgezocht (retrieval). Die informatie wordt dan als context meegegeven aan het taalmodel met als opdracht om een antwoord te genereren op basis van die meegeleverde context (generation). Zowel bij de retrieval-stap als bij de generatie-stap kunnen er fouten optreden. Daarom is het nodig om de vinger aan de pols te houden om de kwaliteit te bewaken.

Figuur 1: Uitvoeringsfase van een RAG pipeline

In dit artikel bespreken we het belang van het meten van de kwaliteit van een RAG systeem, de uitdagingen die zich stellen, de metrieken die we kunnen toepassen en de tools en frameworks die ons daarbij kunnen ondersteunen.

Het belang van evalueren

Vooraleer we aangeven hoé we een generatief vraag-antwoordsysteem kunnen evalueren, staan we toch even stil bij het waarom.

Een generatief vraag-antwoordsysteem is inherent onderhevig aan fouten (hallucinaties, onnauwkeurigheden). Het is daarom belangrijk om de kwaliteit te kennen van de output om pijnpunten bloot te leggen en de kwaliteit gericht te kunnen verbeteren.

Evaluaties laten toe om een benchmark op te stellen van een eerste versie van het vraag-antwoordsysteem. De kwaliteit van nieuwere versies van het systeem kan dan vergeleken worden met deze baseline of vorige versies. Zo kan de impact van veranderingen gemeten worden, zoals het verbeteren van de retrieval component, het inzetten van een ander taalmodel of een aanpassing van de prompt.

Evaluaties kunnen helpen bij het nemen van de beslissing om het systeem al dan niet in productie te nemen. Ze kunnen het vertrouwen in het systeem vergroten door aan te tonen dat het nauwkeurig en betrouwbaar is.

De uitdagingen bij evalueren

Metrieken – In tegenstelling tot traditionele software, is de output van LLM-gebaseerde toepassingen niet deterministisch: een specifieke input kan leiden tot meerdere correcte (of foutieve) outputs. De output kan subjectief zijn. Daarom kunnen we als evaluatiecriterium niet eenvoudig “juist of fout” gebruiken en moeten we onze toevlucht nemen tot andere criteria. Vergelijk het met het evalueren van een opstel (niet deterministisch) versus het evalueren van antwoorden op meerkeuzevragen (wel deterministisch).

Schaalbaarheid – Om snel een eerste indruk te krijgen van de kwaliteit van een generatief vraag-antwoordsysteem kan je manueel enkele testen uitvoeren, bijvoorbeeld een 20-tal vragen stellen en de kwaliteit van de gegenereerde antwoorden manueel evalueren. Maar dit is moeilijk vol te houden als je op grotere schaal wil evalueren, bij een grotere testset of bij het evalueren van alle antwoorden als het systeem in productie draait. In dat geval loont het de moeite om automatische evaluaties uit te voeren. Daarbij wordt een taalmodel ingezet om een bepaald aspect te beoordelen. Er wordt gesproken van “LLM-as-judge”.

Kwaliteit – Het gebruik van taalmodellen voor het evalueren van de output van … taalmodellen is enigszins verrassend. Dergelijke automatische evaluaties kunnen op zich ook fouten bevatten; we moeten waakzaam zijn over de kwaliteit ervan.

Kostenefficiëntie –Het uitvoeren van automatische evaluaties op basis van taalmodellen brengt kosten met zich mee voor het gebruik van die LLM’s die typisch als API service in de cloud aangeboden worden. Als we niet opletten kan de kost voor die evaluaties fors oplopen en de kost van het afhandelen van de vragen van eindgebruikers zelfs overstijgen.

Vertrouwelijkheid – Bij het uitvoeren van evaluaties op basis van LLM’s kan vertrouwelijke informatie blootgesteld worden aan de leveranciers van cloudgebaseerde LLM diensten.

Granulariteit – Je wil niet alleen weten hoe nauwkeurig het gegenereerde antwoord is, maar je wil ook de oorzaak achterhalen van eventuele fouten of onnauwkeurigheden. Daarvoor is het nodig om gedetailleerde log traces bij te houden.

Het interpreteren van wat nu precies gemeten werd met een bepaalde metriek is uiteraard belangrijk. Hierna trachten we de meestgebruikte metrieken duidelijk toe te lichten.

Evaluatiemetrieken

Alhoewel er nog geen standaardisatie is van metrieken, duiken er toch initiatieven op die een belangrijk houvast kunnen bieden. Zo beschrijft de RAG triad van TruEra 3 metrieken die verband houden met de vraag van de eindgebruiker (query), de context opgehaald door het retrieval systeem (context) en het antwoord dat uiteindelijk gegenereerd wordt door het taalmodel (response).

Figuur 2: De RAG triad (bron: https://truera.com/ai-quality-education/generative-ai-rags/what-is-the-rag-triad/)

• Context relevance geeft aan hoe relevant de context is voor de gestelde vraag. De context die opgehaald wordt in de retrieval stap is gebaseerd op een semantische zoekopdracht (similarity search), wat niet noodzakelijk betekent dat die context relevant is voor de gestelde vraag. Deze metriek helpt om eventuele problemen te identificeren in de retrieval stap.
• Groundedness geeft aan in hoeverre het antwoord ondersteund wordt door de context. Zelfs indien alle relevante context aangeleverd wordt aan het taalmodel, kan het taalmodel nog altijd een (deel van het) antwoord verzinnen. Deze metriek checkt of (de verschillende delen van) het antwoord teruggeleid kunnen worden tot statements in de context. Met andere woorden: is er voor het antwoord bewijs terug te vinden in de aangeleverde context? Indien de groundedness score niet hoog genoeg is kan ervoor gekozen worden om het gegenereerde antwoord niet door te geven aan de gebruiker, maar eerder aan te geven dat er niet genoeg informatie beschikbaar is om de vraag te beantwoorden.
• Answer relevance geeft aan in hoeverre het antwoord effectief een antwoord is op de gestelde vraag. Het antwoord kan feitelijk correct zijn en ondersteund zijn door de context, maar toch geen antwoord zijn op de gestelde vraag. Deze metriek houdt geen rekening met de feitelijke correctheid van het antwoord, maar straft wel onvolledige of redundante antwoorden af.

Naast deze 3 metrieken kan het antwoord ook vergeleken worden met een referentie-antwoord (ground truth, of expert-antwoord dat als correct beschouwd wordt), zoals deze metrieken uit het Ragas framework:

• Answer semantic similarity geeft een beoordeling van de semantische overeenkomst tussen het gegenereerde antwoord en het referentie-antwoord.
• Answer correctness: dit is een combinatie van semantic similarity en factual similarity. Het idee van factual similarity is om te meten in hoeverre de beweringen in het gegenereerde antwoord overeenkomen met die in het referentie-antwoord.

Verder zijn er ook metrieken om de chunking strategie te evalueren, zoals deze van Galileo:

• Chunk attribution geeft aan hoeveel chunks en welke chunks gebruikt werden voor het genereren van het antwoord. Teveel chunks ophalen die niet bijdragen tot het antwoord verlaagt de kwaliteit van het systeem en leidt tot hogere kosten omdat er onnodig veel tokens naar het taalmodel worden gestuurd.
• Chunk utilization meet voor een bepaalde chunk hoeveel ervan effectief gebruikt werd voor het genereren van het antwoord. Een lage score betekent dat een groot deel van de chunk niet relevant is voor het beantwoorden van de vraag. Een bijsturing van de grootte van de chunks kan het systeem optimaliseren.

Deze beide metrieken kunnen gebruikt worden om de chunking strategie te optimaliseren. Optimale waarden voor deze metrieken betekent dat er minder irrelevante informatie aangeleverd wordt aan het taalmodel, wat de kosten beperkt en het model helpt om de focus te behouden.

Bij alle bovenvermelde metrieken ligt de focus op de kwaliteit van de antwoorden of zaken die daartoe bijdragen. Daarnaast kunnen ook metrieken geëvalueerd worden om na te gaan of de antwoorden schadelijk zijn (schadelijke of ongepaste inhoud, jailbreaks, etc), of de juiste vorm hebben (coherent, beknopt, de juiste toon, etc). Ook non-functionals kunnen meegenomen worden zoals latency en kost.

Tot slot is het belangrijk om te vermelden dat LLM-gebaseerde metrieken niet met behulp van wiskundige formules gedefinieerd zijn. Fouten zijn mogelijk en het meetresultaat moet gezien worden als een approximatieve indicatie. Daarom blijft een evaluatie door business experten onmisbaar.

Men spreekt in deze context over alignment: ervoor zorgen dat de generatieve AI toepassing antwoordt volgens de verwachtingen van de business.

Wanneer evalueren?

Evaluaties kunnen in principe uitgevoerd worden bij elke fase van de levenscyclus van een toepassing: bij elke bugfix of feature update, bij elke deployment, en eens de toepassing operationeel is.

Er zijn mogelijkheden om automatische evaluaties te integreren in de CI pipeline, bijvoorbeeld pre-commit of pre-release. Tools als CircleCI zetten in op dergelijke ondersteuning.

Om de verandering van de kwaliteit te kunnen meten over verschillende iteraties van het systeem heen is het belangrijk om een vaste testset op te stellen met een aantal vragen en overeenkomstige referentie-antwoorden. De vragen zijn best zo representatief mogelijk voor het soort vragen die effectief zullen gesteld worden door eindgebruikers.

De metrieken die gebruikt worden om het systeem te verbeteren vóór de inproductiestelling kunnen ook gebruikt worden tijdens de productiefase om na te gaan of échte vragen van eindgebruikers nauwkeurig genoeg beantwoord worden. Zoals eerder vermeld moet hier zeker de kost in overweging genomen worden voor het gebruik van taalmodellen als evaluator zodat de kosten niet ontsporen.

Tools en frameworks

Zonder exhaustief te willen zijn, zijn hieronder enkele tools en frameworks aangegeven die het uitvoeren van evaluaties sterk kunnen ondersteunen:

• Galileo is een platform voor het evalueren en monitoren van generatieve AI toepassingen. Het biedt specifieke metrieken voor het optimaliseren van de chunking strategie (chunk attribution en chunk utilization, zie hierboven). Er is ook de mogelijkheid om in realtime guardrails toe te passen: het antwoord kan bijgestuurd worden, bijvoorbeeld in het geval van hallucinaties of schadelijk content. De resultaten van de evaluaties zijn visueel te inspecteren in een console die standaard cloudgebaseerd is, maar ook op eigen infrastructuur kan gehost worden. Om de kost van evaluaties te drukken en gegevens vertrouwelijk te houden werkt Galileo tenslotte aan een oplossing op basis van lichtere modellen die lokaal kunnen draaien.
• Ragas is een open source framework voor het evalueren van RAG-gebaseerde toepassingen. Het biedt een uitgebreide set aan metrieken die het gehele systeem evalueren. Zo zijn er ook metrieken die het gegenereerde antwoord vergelijken met een referentie-antwoord (answer semantic similarity en answer correctness).
• TruLens is een open source community project onder de vleugels van TruEra. TruEra bedacht de term “RAG triad” die 3 metrieken combineert voor het evalueren van hallucinaties in LLM-gebaseerde toepassingen.

Conclusie

Frameworks voor het evalueren van RAG toepassingen laten toe om de kwaliteit van generatieve vraag-antwoordsystemen systematisch te beoordelen en op te volgen. Ze voorzien een manier om verschillende aspecten te meten, zoals het vermogen om relevante informatie op te halen (retrieval) en de kwaliteit van de gegenereerde antwoorden. Dergelijke metrieken zijn cruciaal om inzicht te krijgen in de eventuele zwakke punten van een RAG systeem en waar nodig te kunnen bijsturen.

Het gebruik van een LLM kan het uitvoeren van evaluaties automatiseren en het uitvoeren van testen schaalbaar maken. Het is wel opletten met de kosten die dit teweeg kan brengen. Een taalmodel als evaluator is bovendien niet vrij van fouten, maar ze kunnen voldoende inzicht bieden in de mogelijke verbeterpunten van een generatief vraag-antwoordsysteem. De meetresultaten moeten echter gezien worden als een approximatieve indicatie, we kunnen er niet blind op vertrouwen. Daarom blijft een evaluatie door business experten onmisbaar.

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.

Nederlandstalige versie

Dans un précédent article de blog, nous avons décrit quelques techniques permettant d’améliorer la qualité des réponses dans un système génératif de questions-réponses.

Pour rappel, RAG (Retrieval Augmented Generation) est l’architecture appropriée pour éviter les hallucinations en fournissant aux modèles de langage un contexte. Avant que le modèle de langage ne génère une réponse, il récupère d’abord les informations les plus pertinentes pour la question (retrieval). Ces informations sont ensuite fournies en tant que contexte au modèle de langage, qui a pour mission de générer une réponse sur la base de ce contexte (generation). Des erreurs peuvent se produire à la fois lors de l’étape dite du retrieval et lors de l’étape dite de la generation. Il est donc nécessaire de surveiller la qualité.

Illustration 1 : Phase d’exécution d’un pipeline RAG

Dans cet article, nous examinons l’importance de mesurer la qualité d’un système RAG, les défis à relever, les mesures que nous pouvons appliquer et les outils et cadres qui peuvent nous aider à le faire.

L’importance de l’évaluation

Avant de décrire comment évaluer un système génératif de réponse aux questions, prenons le temps de réfléchir aux raisons de cette évaluation.

Un système génératif de réponse aux questions est intrinsèquement sujet à des erreurs (hallucinations, imprécisions). Il est donc important de connaître la qualité des résultats afin d’identifier les points de friction et d’être en mesure d’améliorer la qualité de manière ciblée.

Les évaluations permettent d’établir un benchmark d’une première version du système de questions-réponses. La qualité des nouvelles versions du système peut ensuite être comparée à ce baseline ou aux versions précédentes. Ainsi, l’impact des changements peut être mesuré, comme l’amélioration de la composante de retrieval, le déploiement d’un modèle de langage différent ou la modification du prompt.

Les évaluations peuvent aider à décider si le système doit être mis en production ou non. Elles peuvent renforcer la confiance dans le système en démontrant qu’il est précis et fiable.

Les défis de l’évaluation

Métriques – Contrairement aux logiciels traditionnels, l’output des applications LLM n’est pas déterministe : une entrée spécifique peut conduire à de multiples outputs corrects (ou erronés). L’output peut être subjectif. Par conséquent, nous ne pouvons pas simplement utiliser “vrai ou faux” comme critère d’évaluation, nous devons recourir à d’autres critères. Comparons cela à l’évaluation d’une dissertation (non déterministe) par rapport à l’évaluation de réponses à des questions à choix multiples (déterministe).

Scalabilité – Pour avoir une première impression rapide de la qualité d’un système génératif de questions-réponses, vous pouvez effectuer des tests manuellement, par exemple en posant une vingtaine de questions et en évaluant manuellement la qualité des réponses générées. Mais cette méthode est difficile à maintenir si vous souhaitez effectuer une évaluation à plus grande échelle, avec un set de test plus important ou lorsque toutes les réponses sont évaluées alors que le système fonctionne en production. Dans ce cas, il est intéressant d’effectuer des évaluations automatiques. Cela implique l’utilisation d’un modèle de langage pour évaluer un aspect particulier. On parle alors de “LLM-as-judge“.

Qualité – L’utilisation de modèles de langage pour évaluer les résultats des modèles de langage est quelque peu surprenante. De telles évaluations automatiques peuvent elles-mêmes contenir des erreurs ; nous devons être vigilants quant à leur qualité.

Rentabilité – L’exécution d’évaluations automatiques basées sur des modèles de langage implique des coûts pour l’utilisation de ces LLM typiquement offerts comme un service API dans le cloud. Si nous ne faisons pas attention, le coût de ces évaluations peut augmenter considérablement et même dépasser le coût de traitement des requêtes des utilisateurs finaux.

Confidentialité – La réalisation d’évaluations basées sur les LLM peut exposer des informations confidentielles aux fournisseurs de services LLM basés sur le cloud.

Granularité – Vous voulez non seulement connaître le degré de précision de la réponse générée, mais aussi découvrir la cause de toute erreur ou inexactitude. Pour ce faire, vous devez conserver des log traces détaillés.

Il est évidemment important d’interpréter ce qui a été mesuré par une métrique particulière. Ci-dessous, nous essayons d’expliquer clairement les métriques les plus couramment utilisées.

Métriques d’évaluation

Bien qu’il n’y ait pas encore de normalisation des métriques, des initiatives émergent qui peuvent fournir des orientations importantes. Par exemple, la RAG triad de TruEra décrit trois métriques liées à la requête de l’utilisateur final (query), au contexte récupéré par le retrieval system (context) et à la réponse éventuellement générée par le modèle de langage (response).

Illustration 2 : RAG triad (source : https://truera.com/ai-quality-education/generative-ai-rags/what-is-the-rag-triad/)

• Context relevance indique le degré de pertinence du contexte par rapport à la question posée. Le contexte récupéré lors de l’étape retrieval est basé sur une recherche sémantique (similarity search), ce qui ne signifie pas nécessairement que ce contexte est pertinent par rapport à la question posée. Cette métrique permet d’identifier les problèmes éventuels lors de l’étape de retrieval.
• Groundedness indique dans quelle mesure la réponse est étayée par le contexte. Même si tout le contexte pertinent est fourni au modèle de langage, ce dernier peut toujours inventer (une partie de) la réponse. Cette métrique vérifie si (les différentes parties de) la réponse peuvent être retracées jusqu’aux statements du contexte. En d’autres termes, peut-on trouver des preuves de la réponse dans le contexte fourni ? Si le score groundedness n’est pas assez élevé, la réponse générée peut ne pas être transmise à l’utilisateur, mais plutôt indiquer qu’il n’y a pas assez d’informations disponibles pour répondre à la question.
• Answer relevance indique dans quelle mesure la réponse est effectivement une réponse à la question posée. La réponse peut être correcte sur le plan factuel et étayée par le contexte, sans pour autant constituer une réponse à la question posée. Cette métrique ne tient pas compte de l’exactitude factuelle de la réponse, mais pénalise les réponses incomplètes ou redondantes

Outre ces trois métriques, la réponse peut également être comparée à une réponse de référence (ground truth ou réponse d’un expert considérée comme correcte), comme les métriques du framework Ragas :

• Answer semantic similarity donne une évaluation de la similarité sémantique entre la réponse générée et la réponse de référence.
• Answer correctness: il s’agit d’une combinaison de l‘answer semantic similarity et de l’answer factual similarity. L’idée de la factual similarity est de mesurer la pertinence des énoncés de la réponse générée par rapport à ceux de la réponse de référence.

En outre, il existe également des métriques permettant d’évaluer la stratégie de chunking, telles que celle proposée par Galileo :

• Chunk attribution indique combien de chunks et quels chunks ont été utilisés pour générer la réponse. L’extraction d’un trop grand nombre de chunks qui ne contribuent pas à la réponse diminue la qualité du système et entraîne des coûts plus élevés parce que de nombreux tokens sont envoyés inutilement au modèle de langage.
• Chunk utilization mesure, pour un chunk donné, la part de celui-ci qui a été effectivement utilisée pour générer la réponse. Un score faible signifie qu’une grande partie du chunk n’est pas pertinente pour répondre à la question. Un ajustement de la taille des chunks peut permettre d’optimiser le système.

Ces deux métriques peuvent être utilisées pour optimiser la stratégie de chunking. Des valeurs optimales pour ces métriques signifient que moins d’informations non pertinentes sont fournies au modèle de langage, ce qui réduit les coûts et aide le modèle à rester concentré.

Pour toutes les métriques susmentionnées, l’accent est mis sur la qualité des réponses ou sur les éléments qui y contribuent. En outre, les métriques peuvent également être évaluées pour vérifier si les réponses sont nuisibles (contenu nuisible ou inapproprié, jailbreaks, etc.), ou si elles ont la bonne forme (cohérentes, concises, le bon ton, etc.). Les aspects non fonctionnels peuvent également être pris en compte, tels que la latence et le coût.

Enfin, il est important de mentionner que les métriques basées sur le LLM ne sont pas définies à l’aide de formules mathématiques. Des erreurs sont possibles et le résultat de la mesure doit être considéré comme une indication approximative. Par conséquent, l’évaluation par des experts business reste indispensable.

Dans ce contexte, on parle d’alignement : il s’agit de s’assurer que l’application d’IA générative répond aux attentes du business.

Quand évaluer ?

Les évaluations peuvent en principe être effectuées à chaque étape du cycle de vie d’une application : à chaque correction de bogue ou mise à jour de fonctionnalité, à chaque déploiement et une fois que l’application est opérationnelle.

Il existe des moyens d’intégrer des évaluations automatiques dans le pipeline CI, par exemple pre-commit ou pre-release. Des outils comme CircleCI misent sur ce type de support.

Afin de mesurer l’évolution de la qualité entre les différentes itérations du système, il est important de mettre en place un set de test fixe avec un certain nombre de questions et les réponses de référence correspondantes. Les questions doivent être aussi représentatives que possible du type de questions qui seront effectivement posées par les utilisateurs finaux.

Les métriques utilisées pour améliorer le système avant sa mise en production peuvent également être utilisées pendant la phase de production pour vérifier si les réponses aux questions réelles des utilisateurs finaux sont suffisamment précises. Comme indiqué précédemment, le coût de l’utilisation de modèles de langage en tant qu’évaluateur doit être pris en compte afin de ne pas faire dérailler les coûts.

Outils et frameworks

Sans vouloir être exhaustifs, voici quelques outils et cadres qui peuvent fortement appuyer la conduite des évaluations :

• Galileo est une plateforme d’évaluation et de suivi des applications d’IA générative. Elle fournit des métriques spécifiques pour l’optimisation de la stratégie de chunking (chunk attribution et chunk utilisation, voir ci-dessus). Il est également possible d’appliquer des guardrails en temps réel : la réponse peut être ajustée, par exemple en cas d’hallucinations ou de contenu nuisible. Les résultats des évaluations peuvent être inspectés visuellement dans une console qui est basée sur le cloud par défaut, mais qui peut également être hébergée sur une infrastructure interne. Enfin, pour réduire le coût des évaluations et préserver la confidentialité des données, Galileo travaille sur une solution basée sur des modèles plus légers qui peuvent être exécutés localement.
• Ragas est un framework open source pour évaluer les applications basées sur RAG. Il fournit un ensemble complet de métriques qui évaluent l’ensemble du système. Il s’agit notamment de mesures qui comparent la réponse générée à une réponse de référence (answer semantic similarity et answer correctness).
• TruLens est un projet communautaire open source sous l’égide de TruEra. TruEra a inventé le terme “RAG triad” qui combine 3 métriques pour évaluer les hallucinations dans les applications basées sur le LLM.

Conclusion

Les frameworks d’évaluation des applications RAG permettent un suivi et une évaluation systématiques de la qualité des systèmes génératifs de questions-réponses. Ils permettent de mesurer différents aspects, tels que la capacité à récupérer des informations pertinentes (retrieval) et la qualité des réponses générées. Ces métriques sont essentielles pour comprendre les faiblesses d’un système RAG et apporter les ajustements nécessaires.

L’utilisation d’un LLM peut automatiser l’exécution des évaluations et rendre les tests évolutifs. Cependant, il faut faire attention aux coûts que cela peut engendrer. Un modèle de langage en tant qu’évaluateur n’est pas exempt d’erreurs, mais il peut fournir un aperçu suffisant des domaines d’amélioration possibles d’un système génératif de questions-réponses. Toutefois, les résultats des mesures doivent être considérés comme une indication approximative ; nous ne pouvons pas nous y fier aveuglément. Par conséquent, l’évaluation par des experts business reste indispensable.

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.