Les services numériques doivent non seulement être rentables, mais également robustes : ils doivent continuer à fonctionner si certains fournisseurs ou éléments de base font défaut pour une raison quelconque. Il ne s’agit pas uniquement d’une question purement technique, d’un enfermement propriétaire (vendor lock-in) ou d’architecture multicloud. Nous assistons une fois de plus à l’émergence de questions fondamentales d’indépendance, de sécurité et d’autonomie stratégique : la souveraineté numérique est tendance.

On comprend aisément pourquoi : avec un revirement politique d’une ampleur sans précédent, la réputation des États-Unis en tant que partenaire commercial fiable s’est volatilisée en un temps record. Du jour au lendemain, un service peut être interrompu ou des droits de douane peuvent être introduits sans raison valable. Quiconque développe ou gère des infrastructures IT critiques en tremble rien qu’à l’idée. Et l’autonomie vaut soudain à nouveau son pesant d’or.

Piliers stratégiques

Le cœur de la souveraineté numérique réside dans la capacité à choisir, déployer et gérer des solutions technologiques sans dépendances externes étendues. Ces dépendances sont souvent plus profondes que nous ne le pensons, comme l’a démontré une expérience intéressante du journaliste de Gizmodo, Kashmir Hill, il y a quelques années. La dépendance technologique représente toujours un risque. Afin de le minimiser, nous pouvons entre autres :

• Investir dans le développement local et open source des technologies
• Construire nous-même des infrastructures robustes et décentralisées
• Développer nos propres compétences et capacités technologiques
• Inclure des conditions d’interopérabilité, de migration de données, de flexibilité, d’interruption, etc. dans des clauses contractuelles et les marchés publics.
• …

En matière de développement logiciel pratique également, les choix qui favorisent l’agilité technologique présentent un avantage :

• Choisir des normes ouvertes et des API robustes et standardisées
• Développer des solutions non seulement modulaires et évolutives, mais également agnostiques vis-à-vis du cloud
• Implémenter des middleware capables de relier différentes technologies
• Prêter attention à la portabilité, à la compatibilité multiplateforme et à la compatibilité entre navigateurs
• …

La souveraineté sur les données est également très importante. Une souveraineté numérique exige de conserver un contrôle maximal sur la collecte, le stockage, le traitement et la protection des données. Cela peut se faire en organisant le stockage et le traitement des données localement, de préférence en appliquant des mécanismes solides de gouvernance des données, ou en les confiant à un tiers qui offre les garanties nécessaires et opère dans le cadre d’une législation compatible.

La Belgique se débrouille plutôt bien en matière d’autonomie infrastructurelle, avec le cloud gouvernemental G-Cloud et le réseau Belnet, entre autres.

Le rôle de l’open source

Les technologies open source, en tant que vecteurs d’indépendance technologique, sont des éléments fondamentaux de la souveraineté numérique. Elles offrent une totale transparence du code, permettent la modification ou le propre développement, et diminuent la dépendance vis-à-vis des géants technologiques étrangers.

Cependant, cela a également un coût. L’utilisation de logiciels open source et de normes ouvertes implique de fournir soi-même l’ensemble du support, de la formation, des mises-à-jour, de la compatibilité, du débogage, etc. En échange de l’autonomie, il faut inclure un éventail de tâches connexes. Cela implique notamment un investissement dans la gestion active, ainsi que la maintenance et le développement des connaissances. Les acteurs commerciaux proposant des solutions propriétaires s’en chargent généralement.

Devenir totalement autonome est donc généralement impossible. Il existe un cas d’étude bien connu, celui de la ville de Munich, qui a ambitieusement basculé en 2006 vers un environnement Linux développé en interne, mais qui, en raison de problèmes persistants de compatibilité et de l’augmentation des coûts de gestion qui en découle, a mis fin au programme en 2017 pour revenir à un environnement Microsoft standardisé.

Chez nos voisins

L’Allemagne est une fervente partisane de la souveraineté numérique depuis longtemps. L’Open Source Business Alliance allemande utilise même le terme dans son slogan. L’expérience munichoise a donné naissance à l’actuel Open Source Programme Office de la ville. Le niveau fédéral allemand encourage également l’indépendance technique, notamment :

• Des projets propres tels que Sovereign Cloud Stack (actuellement en transformation après la fin du financement),
• Le Sovereign Tech Fund, qui fournit des fonds pour maintenir les composants open source essentiels,
• Le Zentrum Digitale Souveränität (ZenDis), qui aide les gouvernements à réduire leurs dépendances technologiques.

Ce dernier investit également avec succès dans deux projets propres :

• La plateforme OpenCode, où les services publics peuvent publier et partager leur code avec d’autres,
• L’environnement de travail administratif OpenDesk, qui inclut également des options typiques pour les entreprises telles que l’authentification unique et les intégrations entre les réunions, les « chats », le calendrier et les courriers électroniques.
  

La France n’est pas en reste non plus. Plusieurs initiatives en faveur de la souveraineté numérique sont menées par la Direction interministérielle du Numérique (DINUM). Ils comptent également leur propre dépôt sous la forme de code.gouv.fr. En outre, ils développent de manière proactive de nouvelles applications dans leur propre incubateur. Cela a donné naissance à des projets tels que La Suite Numérique, une suite enterprise level de bureautique qui offre des fonctionnalités telles que le chat vidéo, les webinaires et le transfert de fichiers, et qui est en cours d’extension pour inclure des traitements de texte et des tableurs. La France s’est également engagée dans une stratégie de cloud computing la plus indépendante possible et, tout aussi important, elle s’efforce de motiver et de former ses fonctionnaires par le biais de la communauté des Blue Hats. Du côté des entreprises, l’union des entreprises du logiciel libre et du numérique ouvert (CNLL) s’est engagé en faveur de la souveraineté numérique.

Ce qui est frappant à la fois avec l’OpenDesk allemand et La Suite Numérique française, c’est qu’ils sont tous deux également disponibles en anglais. Même dans le contexte gouvernemental, on prend de plus en plus conscience que les initiatives open source ont de meilleures chances de succès si l’on investit de manière proactive dans l’internationalisation. Plus prometteur encore, DINUM et ZenDis ont commencé une collaboration concrète avec une application de prise de notes développée conjointement. Cette dernière a été présentée lors du dernier FOSDEM, la grand-messe annuelle des développeurs open source à Bruxelles, où les collaborations gouvernementales étaient à l’honneur.

Le tandem franco-allemand est un signe prometteur de la volonté de l’Europe de s’unir pour promouvoir la souveraineté numérique. Nous savons déjà que les Pays-Bas souhaitent se joindre à cette collaboration. En effet, le débat social y est également bien vivant, même à la Seconde Chambre, avec des discussions sur les services cloud ou le DNS. L’Organisation néerlandaise pour la recherche scientifique appliquée (TNO) a publié un long rapport sur la souveraineté numérique, les universités en font un sujet de discussion et le monde des affaires y prête également attention. La souveraineté numérique est à l’ordre du jour à tous les niveaux de gouvernement.

Le rôle de l’Europe

L’Union européenne a un intérêt stratégique évident dans la souveraineté (numérique). Les éléments clés à cet égard sont le récent Digital Markets Act (DMA) et le Digital Services Act (DSA). Ces deux cadres législatifs visent à limiter le pouvoir des géants technologiques étrangers et à rendre le « terrain de jeu » plus équitable et transparent pour les entreprises européennes. L’UE souhaite ainsi renforcer son autonomie stratégique en établissant des règles claires en matière de gestion des données et des plateformes, rendant les États membres européens moins vulnérables aux dépendances extérieures. Le Cybersecurity Act et la directive NIS2 devraient garantir que la sécurité et la fiabilité ne soient pas compromises.

L’UE entreprend également de nombreuses initiatives pertinentes, mais toutes ne décollent pas tout aussi facilement. La fragmentation européenne est une vieille plaie. Les petits projets restent souvent petits et, une fois le financement terminé, ils se transforment en abandonware. Par exemple, il est impossible de savoir si la nouvelle European Open Source Academy survivra à la fin de son cycle de financement en 2027. D’autre part, les consortiums à grande échelle ont de nombreux problèmes de coordination et de contrôle. Le projet GAIA-X a ainsi acquis la réputation d’être plus une histoire de mémos que de démos, si bien que les nouveaux projets tels qu’OpenEuroLLM sont également accueillis avec un certain scepticisme. Le déploiement des European Data Spaces dans divers domaines devrait favoriser la souveraineté sur les données. Cela deviendra obligatoire pour la santé (EHDS), qui pourrait insuffler un nouvel élan. Cela ne suffit cependant pas à apaiser les inquiétudes : le rapport complet EuroStack de la Bertelsmann Stiftung présente même à l’UE une vision plus ambitieuse sur un plateau d’argent.

Sous l’égide de l’Europe Interopérable, on retrouve l’Open Source Observatory and Repository (OSOR), en plus de Public Sector Techwatch et GovTech Connect. Ils surveillent l’utilisation de l’open source dans les administrations gouvernementales européennes depuis plus de 15 ans maintenant, et encouragent les partenariats et la réutilisation. L’Open Source Solutions Catalogue récemment lancé devrait permettre aux pays de réutiliser plus facilement les solutions des uns et des autres. Ils publient également des rapports, des études de cas, des catalogues nationaux (dans lesquels nous trouvons ict-reuse.be) et une lettre d’information. Les gouvernements qui souhaitent mettre en place leur propre Open Source Program Office (OSPO) afin de contribuer activement aux projets open source tels que celui de l’UE, y trouvent le soutien nécessaire. Les Pays-Bas sont déjà convaincus. Si les autorités belges veulent contribuer visiblement à la souveraineté numérique, voilà une excellente occasion.

Conclusion

La souveraineté numérique est plus qu’un choix technique. C’est une stratégie continue pour retrouver un pouvoir d’agir dans un monde numérique hautement interconnecté où les éléments fondamentaux peuvent soudainement changer. Nous ne voulons pas nous contenter de consommer la technologie, mais aussi la façonner, la comprendre et la contrôler activement. Cela nous permettrait de réduire les dépendances externes et les risques qui en découlent. La pensée et la coopération européennes offrent des possibilités de synergies.

L’autonomie technologique nécessite un écosystème technologique sain. Une attention constante au capital humain et au développement des connaissances est indispensable. Pour y parvenir de manière durable, les initiatives de soutien doivent bénéficier des ressources nécessaires :

• Développer de manière proactive des alternatives technologiques, qui anticipent la demande,
• Participer à l’échange de connaissances, à des évènements et réseauter, avec des pairs, des institutions du savoir, des pays voisins, avec l’UE, etc.
• Investir ou participer activement aux solutions open source existantes que l’on réutilise,
• Construire des communautés autour de projets propres,
• Investir dans un design attrayant et l’intuitivité des solutions propres,
• Rendre sa propre solution disponible en dehors de ses murs : publier en open source, intégrer dans des catalogues, ajouter une documentation et une traduction anglaise, etc.
• Travailler sur la notoriété de la marque : sites web, promotion, marketing, salons professionnels, médias (sociaux), etc.
• …

Les personnes intéressées par ce thème peuvent suivre les organisations et les initiatives mentionnées dans cet article sur les médias sociaux ou à travers leurs lettres d’information. Pour une analyse approfondie, le rapport EuroStack mentionné ci-dessus est intéressant. Si vous cherchez des alternatives pour les dépendances dans vos propres projets, european-alternatives.eu, euro-stack.com ou alternativeto.net sont de bons points de départ. Enfin, la souveraineté numérique est un effort d’équipe, n’hésitez donc surtout pas à partager d’autres sources, projets ou liens intéressants dans les commentaires ci-dessous !

______________________

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

Digitale dienstverlening moet niet alleen kostenefficiënt zijn, maar ook robuust: het moet blijven werken als bepaalde toeleveranciers of bouwblokken het laten afweten, om welke reden dan ook. Dat is niet alleen een louter technisch vraagstuk van vendor lock-in of multicloud architectuur. We zien fundamentele kwesties rond onafhankelijkheid, veiligheid en strategische autonomie opnieuw ter sprake komen: Digitale Soevereiniteit is hot.

De aanleiding is niet ver te zoeken: met een beleidsomslag van jewelste is de reputatie van de VS als betrouwbare handelspartner in recordtempo verdampt. Zonder aanleiding kan van de ene dag op de andere een dienstverlening stopgezet, of een handelstarief ingevoerd worden. Wie kritische infrastructuur en IT ontwikkelt of beheert, trekt lijkbleek weg van het idee alleen al. En zo is zelfredzaamheid plots weer goud waard.

Strategische pijlers

De kern van digitale soevereiniteit ligt in het kunnen kiezen, implementeren en beheren van technologische oplossingen zonder verregaande externe afhankelijkheden. Die afhankelijkheden zitten dieper dan we vaak denken, zoals enkele jaren geleden nog gedemonstreerd in een interessant experiment van Gizmodo journaliste Kashmir Hill. Technologische afhankelijkheid vormt altijd een risico. Om dat te minimaliseren kunnen we onder andere:

• Investeren in lokale en open-source technologie-ontwikkeling
• Zelf robuuste, gedecentraliseerde infrastructuren opbouwen
• Eigen technologische vaardigheden en capaciteiten uitbouwen
• Voorwaarden qua interoperabiliteit, data-migratie, flexibiliteit, stopzetting, … opnemen in contractuele clausules en openbare aanbestedingen
• …

Ook bij praktische software-ontwikkeling hebben keuzes die technologische wendbaarheid bevorderen een streepje voor:

• Verkies open standaarden en robuuste, gestandaardiseerde APIs
• Ontwikkel niet alleen modulair en schaalbaar maar ook cloud-agnostisch
• Implementeer eventueel middleware die verschillende technologieën kan overbruggen
• Besteed aandacht aan portabiliteit, cross-platform en cross-browser compatibiliteit
• …

Daarnaast is ook data-autonomie van groot belang. Zo vereist digitale soevereiniteit dat men maximale controle over data-verzameling, -opslag, -verwerking en -bescherming behoudt. Dat kan door de data-opslag en -verwerking lokaal te organiseren, liefst met toepassing van degelijke data governance mechanismes, of door ze bij een derde partij onder te brengen die de nodige garanties biedt en tenminste onder een compatibele wetgeving opereert.

Het mag gerust gezegd worden dat België het op het vlak van infrastructurele autonomie, met onder andere de overheidscloud Gcloud en Belnet, best goed doet.

De rol van open-source

Open-source technologieën zijn, als enablers van technologische onafhankelijkheid, fundamentele bouwstenen voor digitale soevereiniteit. Ze bieden volledige transparantie van code, geven de mogelijkheid tot aanpassing of eigen ontwikkeling, en ze verminderen de afhankelijkheid van buitenlandse technologiereuzen.

Dat heeft echter ook een kostenplaatje. Wie in eigen beheer open-source software en open standaarden wil aanwenden, moet ook zelf voorzien in alle ondersteuning, opleiding, upgrades, compatibiliteit, eventueel debuggen, etc. In ruil voor autonomie moet je een heel takenpakket mee opnemen in de marge. Dat impliceert dat je moet willen investeren in actief beheer, onderhoud en kennisopbouw. Commerciële spelers met bedrijfseigen oplossingen ontzorgen je daar meestal van.

“All the way” zelfvoorzienend worden is daarom meestal onhoudbaar. Een bekende case studie is die van de stad München, die vanaf 2006 ambitieus overschakelde naar een zelf ontwikkelde Linux-omgeving, maar omwille van aanslepende compatibiliteitsproblemen en de daarmee gepaard gaande oplopende beheerskosten, in 2017 de stekker uit het programma trok en opnieuw voor een gestandaardiseerde Microsoft-omgeving koos.

In de buurlanden

Duitsland draagt het idee van digitale soevereiniteit dus al langer een warm hart toe. De Duitse Open Source Business Alliance zet de term zelfs in hun slogan. De ervaring van München evolueerde naar het huidige Open Source Programme Office van de stad. Het Duitse federale niveau moedigt technische onafhankelijkheid ook aan, met onder andere:

• Eigen projecten zoals Sovereign Cloud Stack (lijkt momenteel in transformatie na afloop financiering),
• Het Sovereign Tech Fund, dat financiering voorziet om kritische open-source componenten te onderhouden,
• Het Zentrum Digitale Souveränität (ZenDis), dat overheden ondersteunt bij de afbouw van technologische afhankelijkheden.

Die laatste investeert ook met succes in 2 eigen projecten:

• Het platform OpenCode waar overheidsdiensten hun code kunnen publiceren en delen met anderen,
• De administratieve werkomgeving OpenDesk , die ook typische enterprise-opties omvat zoals Single Sign-on en integraties tussen meetings, chats, kalender, en email.

Frankrijk zit evenmin stil. Verschillende initiatieven voor digitale soevereiniteit worden bij onze zuiderburen getrokken door DINUM, de centrale interministeriële dienst voor digitalisering. Met code.gouv.fr hebben zij ook hun eigen code repository. Daarnaast ontwikkelen ze zelf proactief nieuwe toepassingen in een eigen incubator. Dat resulteerde onder andere in La Suite Numérique, een enterprise-level kantoorsuite die functionaliteiten zoals videochat, webinars, en file transfer aanbiedt, en nu wordt uitgebreid met tekstverwerkers en spreadsheets. Frankrijk zet eveneens in op een maximaal onafhankelijke cloud-strategie, en minstens zo belangrijk, werken ze aan motivatie en kennis bij hun overheidsmedewerkers via de Blue Hats community. Vanuit het bedrijfsleven zet CNLL zich in voor digitale soevereiniteit.

Opvallend aan zowel het Duitse OpenDesk als het Franse La Suite Numérique, is dat beide ook beschikbaar zijn in het Engels. Zelfs in overheidscontext is dus ondertussen het bewustzijn gegroeid dat open-source initiatieven betere slaagkansen hebben als men proactief investeert in internationalisering. Nog hoopgevender is dat DINUM en ZenDis concreet zijn beginnen samenwerken. Op het laatste FOSDEM evenement, de jaarlijks weerkerende hoogmis voor open-source developers in Brussel, stonden overheidssamenwerkingen in de kijker en presenteerden ze een tesamen ontwikkelde notitie-app.

Deze Duits-Franse tandem is een veelbelovend teken dat, als het gaat over het bevorderen van digitale soevereiniteit, de wil alleszins bestaat om Europese krachten wat te bundelen. Er is alvast bekend dat Nederland wil aansluiten bij hun samenwerking. Daar leeft de maatschappelijke discussie immers ook, tot in de Tweede Kamer, met debatten over clouddiensten of DNS. Het onderzoeksinstituut TNO publiceerde er een lijvig rapport over digitale soevereiniteit, de universiteiten agenderen het, en ook het bedrijfsleven besteedt er aandacht aan. Op alle bestuursniveaus ligt digitale soevereiniteit er op tafel.

De rol van Europa

De EU heeft een evident strategisch belang bij (digitale) soevereiniteit. Centrale elementen hierin zijn de recente Digital Markets Act (DMA) en Digital Services Act (DSA). Beide wetgevende kaders hebben tot doel om de macht van buitenlandse technologiereuzen te beperken en het speelveld voor Europese bedrijven gelijkwaardiger en transparanter te maken. Hiermee wil Europa haar strategische autonomie versterken door duidelijke regels te stellen rondom data- en platformbeheer, waardoor Europese lidstaten minder kwetsbaar worden voor externe afhankelijkheden. De Cybersecurity Act en de NIS2-richtlijn moeten erover waken dat daarbij niet aan veiligheid en betrouwbaarheid wordt ingeboet.

Ze onderneemt daarnaast tal van relevante initiatieven, maar die komen niet allemaal even vlot van de grond. De Europese versnippering is een oud zeer. Kleine projecten blijven vaak klein, en eens de financiering afloopt, verworden ze tot abandonware. Zo is het onvoorspelbaar of het net gestarte European Open Source Academy het einde van haar financieringsronde in 2027 zal overleven. Grootschalige consortia kennen dan weer heel wat problemen met coördinatie en sturing. Het GAIA-X project heeft zo enigszins de reputatie gekregen als een verhaal van meer memo’s dan demo’s, wat maakt dat ook nieuwe projecten zoals OpenEuroLLM met enige scepsis onthaald worden. De uitrol van de Europese Data Spaces in verschillende domeinen moet data-autonomie bevorderen. Voor gezondheid (EHDS) wordt deze verplicht, wat misschien voor nieuw momentum kan zorgen. Maar dat is niet genoeg om de bezorgdheden weg te nemen: het lijvige EuroStack rapport van de Bertelsmann Stiftung stelt de EU zelfs op een dienblaadje een ambitieuzere visie voor.

Onder de paraplu van Interoperable Europe vinden we naast Public Sector Techwatch en GovTech Connect ook OSOR, het Open Source Observatory and Repository, terug. Zij monitoren ondertussen al meer dan 15 jaar het gebruik van open-source in Europese overheidsadministraties, en moedigen samenwerkingsverbanden en hergebruik aan. Met de recent gelanceerde Open Source Solutions Catalogue moet het gemakkelijker worden voor landen om elkaars oplossingen te hergebruiken. Daarnaast publiceren ze rapporten, case studies, nationale catalogi (waarin we ict-reuse.be terugvinden) en een nieuwsbrief. Overheden die zelf een Open Source Program Office (OSPO) willen oprichten om actief bij te dragen aan open-source projecten, net zoals de EU er een heeft, vinden bij hen steun. Nederland is alvast overtuigd. Als Belgische overheden zichtbaar willen bijdragen aan digitale soevereiniteit, ligt hier nog een uitgelezen kans.

Conclusie

Digitale soevereiniteit is meer dan een technische keuze. Het is een continue strategie om agency terug te winnen in een sterk geïnterconnecteerde digitale wereld waarvan fundamentele bouwblokken plots kunnen verschuiven. We willen niet alleen technologie consumeren, maar deze ook actief vormgeven, begrijpen en controleren. Zo beperken we externe afhankelijkheden en de risico’s die daarmee gepaard gaan. Europees denken en samenwerken biedt daarbij opportuniteiten voor synergieën.

Technologische autonomie vereist een gezond technologisch ecosysteem. Permanente aandacht voor menselijk kapitaal en kennisopbouw zijn een must. Om dat te doen slagen op een duurzame manier, verdienen ondersteunende initiatieven de nodige middelen:

• Proactief technologische alternatieven ontwikkelen, anticiperend op de vraag,
• Participeren in kennisuitwisseling, evenementen en netwerken, met vakgenoten, kennisinstellingen, buurlanden, EU, …
• Actief meewerken aan, of investeren in, bestaande open-source oplossingen die je zelf hergebruikt,
• Communities uitbouwen rondom eigen projecten,
• Investeren in aantrekkelijke vormgeving en gebruiksgemak van de eigen oplossingen,
• Eigen oplossingen inzetbaar maken buiten de eigen muren: publiceren als open-source, integreren in catalogi, een Engelse vertaling en documentatie toevoegen,
• Werken aan naambekendheid: websites, promotie, marketing, vakbeurzen, (social) media, …
• …

Wie interesse heeft om dit thema verder op te volgen, kan de in dit artikel vermelde organisaties en initiatieven volgen op sociale media of via hun nieuwsbrieven. Voor een deep dive is het bovenvermelde EuroStack rapport interessant. Om alternatieven te zoeken voor afhankelijkheden in je eigen projecten, zijn european-alternatives.eu, euro-stack.com, of alternativeto.net goede startpunten. Tot slot: digitale soevereiniteit is een team effort, voel je daarom vrij om andere bronnen, projecten, of interessante links te delen in de commentaren hieronder!

______________________

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

Avec la popularité des applications d’IA dotées d’une interface conversationnelle, un “vieux casse-tête” refait surface : comment protéger les données personnelles communiquées, souvent sans méfiance, à un système automatisé de conversation ? Par extension, cette question se pose pour toute application où des données personnelles doivent être partagées avec des tiers. Les dépendances externes d’une application peuvent toutefois constituer un enchevêtrement complexe. Il n’est pas non plus toujours possible (ou économiquement viable) d’éviter les grands acteurs d’infrastructures informatiques d’IA – du moins pas si vous souhaitez rester à jour avec les dernières capacités de manière rentable.

Une solution possible est connue sous le nom de PII Filtering. En l’occurrence, PII est l’acronyme anglais de Personal(ly) Identifiable/Identifying Information, c’est-à-dire les informations par lesquelles une personne peut être identifiée. L’idée est assez simple : un filtre supplémentaire est placé devant l’application, qui élimine les informations à caractère personnel des données d’entrée, avant que celles-ci ne soient transmises à l’application. Si cela fonctionne bien, alors ce que l’application fait de ces données en coulisses n’a pas d’importance.

PII vs. Personal Data

Avant toute chose, il est crucial de comprendre que les PII ne peuvent être assimilées à des “Personal Data” telles que définies par le RGPD et d’autres législations européennes. Les PII sont un concept ancré dans le droit états-unien. Elles font généralement référence à un ensemble fini d’informations d’identification qui peuvent être utilisées dans le but de distinguer ou de confirmer l’identité d’un individu, comme les numéros de registre national, les adresses et les numéros de téléphone. Aux États-Unis, les réglementations sont souvent prescriptives à cet égard : par exemple, HIPAA (réglementation sur la protection des données relatives à la santé) comprend une liste de 18 identifiants définis comme PII. Cela présente le grand avantage d’être relativement facile à implémenter : une fois que la liste est entièrement cochée, il n’y a plus guère de débat juridique possible.

En revanche, la RGPD européenne adopte une approche de principe : elle définit un concept plus large de Personal Data (données à caractère personnel). Ce concept englobe “toute information se rapportant à une personne physique identifiée ou identifiable”. Cela signifie que même des informations en apparence anodines, comme la couleur “rouge”, peuvent être considérées comme des données à caractère personnel si elles se rapportent, par exemple, à la couleur préférée d’une personne. Cette définition des données à caractère personnel dépendante du contexte rend toutefois pratiquement impossible le développement de détecteurs ou de filtres génériques et polyvalents pour ces données. Ce qui est considéré comme des données personnelles ou non doit être évalué au cas par cas. Les développeurs sont donc confrontés à une personnalisation plus importante qu’ils ne le souhaiteraient, mais les juristes, les DPO et les autorités de protection des données ont également fort à faire avec de telles évaluations dans chaque pays de l’UE.

Ainsi, les solutions de filtrage des PII considérées comme conformes aux États-Unis risquent toujours de ne l’être que partiellement dans l’Union européenne. Étant donné que le terme PII semble s’être imposé sur le marché mondial, nous ferons dans le présent article uniquement référence aux PII. Gardez toujours à l’esprit que le Personal Data doit être le point de départ dans le contexte de l’UE.

Détection et filtrage des PII

Afin de filtrer des informations textuelles, nous utilisons généralement des modèles techniques de reconnaissance de formes et de traitement automatique des langues (Natural Language Processing ou NLP). Ces modèles analysent les données non structurées, à la recherche de formes telles que des formats d’adresses e-mail ou des chaînes numériques similaires à un registre national ou encore à des numéros de téléphone, afin de les modifier ou de les anonymiser par la suite. En outre, des formes d’expression régulières (regex) personnalisées sont souvent ajoutées afin de reconnaître les formes d’informations sensibles spécifiques à l’application en question.

Un filtrage efficace des PII repose en grande partie sur la reconnaissance d’entités nommées (Named Entity Recognition ou NER), une méthode NLP qui identifie les entités telles que les noms, les dates et les lieux dans un texte. Nous avons déjà publié des articles plus détaillés à ce sujet – voir les articles sur NLP et NER.  L’essor de l’IA générative n’a pas encore changé grand-chose à la conception des techniques de NER. Aujourd’hui encore, de nombreux outils de filtrage de PII utilisent des outils NLP sous-jacents bien développés tels que NLTK, SpaCy ou Flair.

Toutefois, les PII peuvent également apparaître dans des images : scans de documents, photos de visages ou de plaques d’immatriculation, … Le filtrage de ces images nécessite une approche plus sophistiquée, car les données sensibles peuvent apparaître sous diverses formes, de notes écrites à la main à des reflets sur des photos. La reconnaissance optique de caractères (Optical Character Recognition ou OCR) permet d’extraire le texte des images et de le convertir dans un format qui peut être analysé de la même manière que des données textuelles. Une fois le texte extrait, il est soumis au même processus de filtrage des PII à l’aide de techniques NLP. Des algorithmes de reconnaissance d’objets sont utilisés pour reconnaître les éléments visuels sensibles (tels que des visages ou des documents personnels) contenus dans l’image elle-même.

Une fois identifiées, vous devez décider de ce qu’il convient de faire avec les PII détectées. Les options possibles sont les suivantes :

• Remplacement/substitution par une autre valeur. Celle-ci peut éventuellement être créée à l’aide d’un outil de génération de données synthétiques, de sorte que l’original est remplacé par une alternative d’apparence réaliste.
• Masquage / obfuscation : remplacement par un caractère ou une barre. Cela peut être partiel, afin de ne pas perdre des informations plus générales utiles : par exemple, nous pouvons toujours voir que +32********* est un numéro de téléphone belge.
• Suppression
• Hashage (mieux encore avec salage en prévention des attaques par force brute)
• Chiffrement, éventuellement préservant le format des données
• …

D’autres fonctions sont possibles pour les images, notamment :

• Flouter (blurring) ou d’autres filtres. Il convient de noter ici que certains filtres sont réversibles.
• Couvrir ou écraser, par exemple avec un rectangle noir.
• …

Le remplacement par une valeur alternative du même type peut toutefois créer des effets étranges, parce que l’entité n’est pas toujours estimée correctement ou parce que trop peu ou pas de contexte peut être pris en compte. Certains outils peuvent ainsi ne pas tenir compte du genre si un nom aléatoire doit être choisi pour remplacer un nom réel, alors qu’il peut être nécessaire de rester cohérent sur le plan grammatical ou sur celui du contenu. Il arrive également que des noms de lieux comme Saint-Nicolas soient anonymisés en Saint-Kevin, par exemple, parce que Nicolas est considéré comme un prénom. Les modèles de langage utilisés pour la NER ne sont donc certainement pas sans faille.

En théorie, il devrait être possible d’obtenir de meilleurs résultats en activant des LLM modernes comme le GPT-4 avec des requêtes construites de manière intelligente. Des mesures dans ce sens verront probablement le jour sous peu, mais aujourd’hui, les besoins en puissance de calcul, la consommation d’énergie et le coût sont encore trop élevés, et le temps de réponse trop lent, pour que l’on puisse également faire évoluer cette méthode.

Outils courants

Les personnes qui recherchent des systèmes de filtrage de PII à grande échelle, et qui souhaitent pouvoir analyser des bases de données, des réseaux ou des systèmes de fichiers entiers, se retrouvent avec des outils du domaine de Data Loss Prevention. Ceux-ci devraient empêcher les PII de quitter l’entreprise sans les autorisations nécessaires. Vous trouverez une vue d’ensemble du marché en consultant Gartner. Les géants de l’internet proposent également des solutions à cette fin, telles que Amazon Macie, Google SDP, ou IBM Guardium. Les techniques utilisées dans ces outils sont quelque peu liées à celles utilisées dans les enquêtes judiciaires – ce que l’on appelle l’eDiscovery, que nous avons déjà évoquée.

Les créateurs d’applications sont plus susceptibles d’être intéressés par des outils sous forme de bibliothèques, de SDK ou d’API. Les projets intéressants sont les suivants :

• Pour le texte :
  • Microsoft Presidio (démo) (également disponible sous la forme de Docker containers), ou le service PII detection sur Azure
  • Amazon Comprehend (démo)
  • Les EU Language Services pour NLP (login requis) : pour l’anonymisation des documents dans les langues de l’UE, basé sur le projet MAPA-EU, qui peut également être utilisé via Docker Compose.
  • PIICatcher (pour les bases de données et les systèmes de fichiers)
• Pour les images :
  • Google Magritte (pour les visages)
  • Meta Research EgoBlur (Pour les visages et les plaques d’immatriculation)
  • OctoPII (Uniquement la détection, pas la modification. Pour les documents et les systèmes de fichiers, avec Tesseract pour OCR engine)

De nouvelles recherches sont également en cours dans les universités. Par exemple, PII-Codex est le résultat d’un projet universitaire qui présente une caractéristique intéressante : il utilise Presidio ou Comprehend, mais ajoute également son propre score de risque, qui devrait être en mesure d’indiquer dans quelle mesure la non modification des PII reconnues pourrait poser un risque (pour la protection de la vie privée). En outre, la plupart des outils permettent d’utiliser vos propres modèles ou ceux des autres. Vous pouvez éventuellement les peaufiner vous-même pour la détection personnalisée d’entités, si vous disposez des données d’entraînement nécessaires à cet effet.

Si nous nous appuyons sur la NER ou la reconnaissance d’images pour la détection des PII, il est certain que certaines PII ne seront pas détectées et qu’à l’inverse, des éléments non PII pourraient également être classés à tort comme des PII. En effet, aucune de ces technologies ne garantit une précision de 100 %. Le taux de réussite variera également en fonction de la langue et du type d’entité que l’on tente de détecter. Il n’est jamais possible de garantir complètement le remplacement ou la suppression de chaque entité dans un document. Il est donc préférable de vérifier le résultat dans les cas où cela s’avère crucial.

Conclusion

Les solutions de filtrage de PII peuvent certainement contribuer à la protection de données à caractère personnel dans un contexte européen. Les techniques sont simples à comprendre et faciles à mettre en œuvre. Cependant, il n’y a jamais de garantie de détection totalement précise de toutes les données à caractère personnel et, dans la plupart des cas, leur utilisation devra donc faire partie d’un éventail plus large de mesures visant à promouvoir la conformité avec la RGPD et d’autres législations.

La technologie sous-jacente est “classique”, en ce sens que la NER et la reconnaissance d’images existent depuis longtemps et sont désormais bien développées. Aujourd’hui, elles bénéficient de l’attention portée à l’intelligence artificielle, et toutes sortes d’étalons leur permettent de rester à la pointe du progrès. Dans la pratique, nous constatons que le texte anonymisé qui en résulte peut parfois sembler un peu aliénant, car certains problèmes tout aussi classiques auxquels la NER est généralement confrontée ne sont pas encore totalement écartés.

______________________

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

De populariteit van AI-toepassingen met chat-interface, doet een “oud zeer” opnieuw bovendrijven: hoe beschermen we persoonsgegevens die, vaak nietsvermoedend, via chat worden meegedeeld aan een geautomatiseerd systeem? Bij uitbreiding stelt zich deze vraag voor elke toepassing waar persoonsgebonden gegevens gedeeld moeten worden met derde partijen. De externe afhankelijkheden van een toepassing kunnen echter een ingewikkeld kluwen zijn. Het is ook niet altijd mogelijk (of economisch haalbaar) om de grote spelers op het vlak van cloud- en AI-diensten te ontwijken – toch niet als je mee wil zijn met de nieuwste mogelijkheden op een kostenefficiënte manier.

Een mogelijke oplossing staat bekend als PII Filtering. PII is daarbij het Engels acroniem voor Personal(ly) Identifiable/Identifying Information, i.e. de informatie waarmee iemand geïdentificeerd kan worden. Het idee is eenvoudig genoeg: we plaatsen een extra filter voor de applicatie, die de persoonlijke gegevens uit de input filtert, voordat die input aan de applicatie wordt doorgegeven. Als dat goed lukt, dan maakt het in principe niet meer uit wat de applicatie achter de schermen met die gegevens doet.

PII vs. Personal Data

Het is allereerst cruciaal om te begrijpen dat “PII” niet gelijkgesteld kan worden aan “Personal Data” zoals de GDPR en andere Europese wetgeving die definieert. PII is een concept dat geworteld is in Amerikaanse wetgeving. Het doelt meestal op een eindige set identificatiegegevens die kunnen worden gebruikt om de identiteit van een individu te onderscheiden of te achterhalen, zoals rijksregisternummers, adressen en telefoonnummers. Amerikaanse regelgeving is op dat vlak vaak prescriptief van aard: zo bevat de HIPAA (privacywetgeving m.b.t. gezondheidsgegevens) een lijst met 18 identifiers die als PII worden gedefinieerd. Dat heeft als groot voordeel dat het relatief gemakkelijk te implementeren is: wanneer het lijstje helemaal afgevinkt kan worden, is er ook juridisch weinig discussie meer.

Daarentegen hanteert de Europese GDPR (AVG) een principiële benadering: ze definieert een breder concept van Personal Data (persoonsgegevens). Dat omvat “alle informatie met betrekking tot een geïdentificeerde of identificeerbare natuurlijke persoon”. Dit betekent dat zelfs schijnbaar onschuldige informatie, zoals de kleur “rood”, beschouwd kan worden als persoonsgegeven, als deze bijvoorbeeld betrekking heeft tot iemands lievelingskleur. Deze contextafhankelijke definitie van persoonsgegevens, maakt het echter ook nagenoeg onmogelijk om generieke, algemeen inzetbare detectoren of filters ervoor te ontwikkelen. Wat beschouwd wordt als persoonsgegeven of niet, moet geval per geval beoordeeld worden. Niet alleen ontwikkelaars worden daardoor geconfronteerd met meer maatwerk dan hen lief is, ook juristen, DPO’s en Gegevensbeschermingsautoriteiten hebben met zulke beoordelingen in elk EU-land de handen vol.

Oplossingen voor PII-filtering die voldoen voor gebruik in de VS, lopen dus altijd een risico om in de EU slechts gedeeltelijk tegemoet te komen aan de vereisten. Omdat de term PII echter algemeen ingang gevonden lijkt te hebben in de globale markt, spreken we verder in dit artikel enkel nog over PII. Houd wel permanent in het achterhoofd dat Personal Data altijd het uitgangspunt moet zijn in EU-context.

PII Detectie en Filtering

Om tekstuele input te filteren gebruiken we doorgaans patroonherkenningstechnieken en Natural Language Processing (NLP)-modellen. Deze modellen scannen ongestructureerde gegevens, op zoek naar patronen zoals e-mailformaten of numerieke reeksen die lijken op rijksregister- of telefoonnummers, om deze nadien te kunnen redigeren of anonimiseren. Daarnaast worden aangepaste regex-patronen vaak toegevoegd om vormen van gevoelige informatie te herkennen die specifiek zijn voor de betrokken toepassing.

Effectieve PII-filtering steunt sterk op Named Entity Recognition (NER), een NLP-methode die entiteiten zoals namen, data en locaties in een tekst identificeert. We publiceerden daar eerder al over in meer detail – zie deze artikels over NLP en NER. De opkomst van generatieve AI heeft aan de opzet van NER-technieken nog niet veel veranderd. Ook vandaag gebruiken veel PII filtering tools achterliggend goed ontwikkelde NLP-toolkits zoals NLTK, SpaCy of Flair.

PII kan echter ook in afbeeldingen opduiken: scans van documenten, foto’s van gezichten of nummerplaten, … Om dat weg te filteren is een geavanceerdere aanpak vereist, omdat de gevoelige gegevens kunnen verschijnen in uiteenlopende vormen, van handgeschreven notities tot reflecties in foto’s. Optical Character Recognition (OCR) wordt gebruikt om tekst uit afbeeldingen te extraheren en deze om te zetten in een formaat dat op dezelfde manier kan worden geanalyseerd als tekstuele gegevens. Zodra de tekst is geëxtraheerd, ondergaat deze hetzelfde PII-filterproces met behulp van NLP-technieken. In gevallen waarin de afbeelding zelf gevoelige visuele elementen bevat (zoals gezichten of persoonlijke documenten), worden algoritmen voor beeldherkenning gebruikt om dergelijke inhoud te herkennen.

Eenmaal geïdentificeerd, moet je besluiten wat er dient te gebeuren met de gedetecteerde PII. Opties kunnen zijn:

• Vervanging / substitutie door een andere waarde. Deze kan eventueel aangemaakt worden met een synthetic data tool, zodat het origineel vervangen wordt door een realistisch ogend alternatief.
• Masking / obfuscation: vervang door een karakter of balkje. Dit kan eventueel gedeeltelijk, om nuttige algemenere info niet te verliezen: zo zien we nog dat +32********* een Belgisch telefoonnummer is.
• Verwijdering
• Hashing (best met salt ter preventie van brute-force attacks)
• Encryptie, eventueel formaat-behoudend
• …

Voor afbeeldingen zijn andere functies mogelijk, waaronder:

• Vervagen (blurring) of andere filters. Hierbij moet men er wel op letten dat sommige filters omkeerbaar zijn.
• Bedekken of overschrijven, bijvoorbeeld met een zwarte rechthoek.
• …

De vervanging door een alternatieve waarde van dezelfde soort kan echter soms ook voor vreemde effecten zorgen, omdat de entiteit niet altijd correct wordt ingeschat of omdat er te weinig of geen rekening gehouden kan worden met de context. Zo kan het zijn dat sommige tools geen acht slaan op het geslacht als een willekeurige naam moet worden gekozen om een echte naam te vervangen, terwijl dat wel nodig kan zijn om grammaticaal of inhoudelijk consistent te blijven. We zien soms ook plaatsnamen zoals Sint-Niklaas geanonymiseerd worden als pakweg Sint-Kevin, omdat Niklaas als naam werd aanzien. De taalmodellen gebruikt voor NER zijn dus zeker niet feilloos.

Het zou in theorie mogelijk moeten zijn om betere resultaten te halen door recente LLMs zoals GPT-4 in te schakelen met slim geconstrueerde prompts. Waarschijnlijk zullen er binnenkort wel stappen in die richting worden gezet, maar vandaag zijn de rekenkrachtvereisten, energieconsumptie en kostprijs daarvan nog te hoog, en de responstijd te traag, om dat ook schaalbaar te maken.

Tools of the trade

Wie op zoek gaat naar grootschalige PII Filtering systemen, en volledige databases, netwerken of filesystems wil kunnen scannen, komt terecht bij Data Loss Prevention tools. Deze moeten verhinderen dat PII het bedrijf verlaat zonder de nodige toelatingen. Voor een marktoverzicht verwijzen we naar Gartner. Ook de internetgiganten bieden daarvoor oplossingen aan, zoals Amazon Macie, Google SDP, of IBM Guardium. De daarbij gebruikte technieken zijn enigszins verwant met diegene gebruikt bij forensisch onderzoek – de zogenaamde eDiscovery, waarover we ook al eerder schreven.

Applicatiebouwers zijn waarschijnlijk eerder geïnteresseerd in tools in de vorm van bibliotheken, SDK’s of API’s. Interessante projecten zijn:

• Voor tekst:
  • Microsoft Presidio (demo) (ook beschikbaar als Docker containers), of de PII detection dienst op Azure
  • Amazon Comprehend (demo)
  • De EU Language Services voor NLP (inloggen vereist): voor anonymisering van documenten in EU-talen, gebaseerd op het MAPA-EU project dat ook via Docker Compose gebruikt kan worden.
  • PIICatcher (voor databases en filesystems)
• Voor afbeeldingen:
  • Google Magritte (voor gezichten)
  • Meta Research EgoBlur (voor gezichten en nummerplaten)
  • OctoPII (enkel detectie en geen redactie. Voor documenten en filesystems, met Tesseract als OCR engine)

Ook in academia wordt er verder onderzoek gedaan. Zo is PII-Codex het resultaat van een universitair project, met een interessante feature: achterliggend maakt het gebruik van Presidio of Comprehend, maar het voegt ook een eigen risico-score toe, die moet kunnen aangeven in welke mate het niet-redigeren van de herkende PII een (privacy-)risico zou kunnen inhouden. Daarnaast laten de meeste tools ook toe om andere of eigen modellen in te pluggen. Deze kan je eventueel zelf gefinetuned hebben voor detectie van custom entiteiten, als je daarvoor de nodige trainingsdata hebt.

Als we vertrouwen op NER of beeldherkenning voor PII-detectie, dan kunnen we er zeker van zijn dat sommige PII niet gedetecteerd zal worden, en dat ook andersom niet-PII foutief als PII aangemerkt kan worden. Geen van deze technologieën garandeert immers 100% accuraatheid. Het succespercentage zal ook variëren afhankelijk van de taal en het entiteitstype dat men probeert te detecteren. Volledige vervanging of verwijdering van elke entiteit in een document kan nooit worden gegarandeerd. Daar waar dat cruciaal is, wordt het resultaat achteraf dus best nog gecontroleerd.

Conclusie

Oplossingen voor PII-filtering kunnen in Europese context zeker bijdragen aan de bescherming van persoonsgegevens. De techniek is eenvoudig te begrijpen en gemakkelijk inzetbaar. Er is echter nooit een garantie op volledige accurate detectie van alle persoonsgegevens, en dus zal hun gebruik in de meeste gevallen een onderdeel moeten zijn van een ruimere waaier aan maatregelen om compliance met GDPR en andere wetgeving te bevorderen.

De achterliggende technologie is “klassiek”, in de zin dat NER en beeldherkenning al lang bestaan en ondertussen goed ontwikkeld zijn. Vandaag profiteren ze mee van de aandacht voor artificiële intelligentie, en allerlei benchmarks laten toe om de state-of-the-art op te volgen. In de praktijk merken we wel dat de resulterende geanonymiseerde tekst soms wat bevreemdend kan overkomen, omdat enkele al even klassieke problemen waar NER typisch mee kampt, nog altijd niet helemaal van de baan zijn.

______________________

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

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

Embeddings vectoriels

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

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

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

Recherche de similarité

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

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

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

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

Recherche hybride

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

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

Domaines d’application

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

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

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

Aperçu du marché

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

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

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

Conclusion

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

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

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

In de wereld van AI zijn vector databases een belangrijk hulpmiddel geworden. Ze stellen ons in staat om grote hoeveelheden ongestructureerde gegevens efficiënt op te slaan en te doorzoeken, wat cruciaal is voor veel toepassingen.

Vector embeddings

Vector databases beheren in essentie vectorgegevens. Dat zijn gegevens die worden weergegeven als een reeks getallen, of vectoren, die een punt in een hoog-dimensionale ruimte vertegenwoordigen. Het aantal getallen in een vector komt overeen met het aantal dimensies.

Het omzetten van gegevens naar vectoren gebeurt op basis van een embedding model, waarbij de betekenis (semantiek) ervan gecapteerd wordt. We spreken van vector embeddings. Zo zal de vector voor het woord “puppy” bijvoorbeeld dicht bij de vector voor “hond” liggen, en verder weg van “appel”.

Die vectoren worden geïndexeerd in een vector database opgeslagen, op zo een manier dat het opzoeken zo efficiënt mogelijk verloopt.

Similarity search

Het unieke aan vector databases is dat ze kunnen zoeken naar gelijkaardige gegevens ten opzichte van een inputvraag (query). We spreken van similarity search: in plaats van te zoeken naar exacte overeenkomsten kunnen vector databases zoeken naar gegevens die het meest vergelijkbaar zijn met een gegeven query.

Dat ‘vergelijkbaar zijn’ wordt berekend op basis van de afstand tussen vectoren in de zoekruimte: hoe kleiner de afstand tussen twee vectoren, hoe vergelijkbaarder ze zijn. Er bestaan verschillende functies om de afstand tussen twee vectoren te berekenen. De keuze kan afhangen van verschillende factoren: de gegevens, het gebruikte embedding model, en de afweging tussen accuraatheid en snelheid van uitvoering.

De meest voor de hand liggende manier om de dichtste vectoren te zoeken ten opzichte van een query vector is om de query vector exhaustief te vergelijken met alle vectoren in de databank (k-Nearest-Neighbors of kNN). Op die manier zijn we zeker dat we de k dichtste vectoren terugvinden. We krijgen  in dit geval perfecte accuraatheid. De keerzijde is echter dat het een rekenintensieve methode is die niet schaalt.

Om performanter te kunnen zoeken in grote hoeveelheden gegevens zijn er approximatieve methodes waarbij er geen exhaustieve vergelijking is tussen de query en de vectoren in de databank (Approximative Nearest Neighbors of ANN). De meest gebruikte methode hiervoor is wellicht HNSW (Hierarchical Navigable Small World). Dat is een methode op basis van een hiërarchische graaf waarbij elke node een vector vertegenwoordigt en de links tussen de nodes de afstand ertussen aangeeft. Tijdens een zoekopdracht navigeert het algoritme efficiënt door de graaf, beginnend op hogere niveaus (waar de dichtheid van nodes lager is) en geleidelijk afdalend naar lagere niveaus om de dichtste buren te vinden.

Hybrid search

Hybrid search is een geavanceerde zoektechniek die de sterktes van vector search combineert met die van een klassieke keyword search. Keyword search (lexicaal zoeken) maakt gebruik van exacte overeenkomsten van trefwoorden in de tekst. Het is snel en eenvoudig, maar mist soms de contextuele nuances. Bij vector search (semantisch zoeken) wordt de betekenis in rekening gebracht. In de praktijk blijkt dat een combinatie van beide methodes betere resultaten oplevert dan elke methode afzonderlijk.

Om de relevantie van de zoekresultaten nog te verbeteren kan er semantic ranking toegepast worden. Daarbij wordt een geavanceerd machine learning model gebruikt om de zoekresultaten te herschikken op basis van hun relevantie ten opzichte van de zoekopdracht. Dit is typisch een betalende feature of API waarbij je betaalt volgens verbruik. Een voorbeeld van zo’n dienst is Cohere Rerank.

Toepassingsgebieden

Vector databases kunnen voor een divers aantal toepassingen ingezet worden:

• Semantic search – Het mag ondertussen duidelijk zijn dat vector databases een belangrijke bijdrage kunnen leveren bij het verbeteren van de zoekresultaten op basis van semantische betekenis in plaats van enkel exacte matches.
• Question answering & RAG – Recent is er veel aandacht voor generatieve vraag-antwoordsystemen. Vector databases kunnen ingezet worden als retriever component in zo’n systeem. Men spreekt over Retrieval Augmented Generation (RAG). Dit is een aanpak waarbij een taalmodel antwoorden formuleert op basis van de meest relevante informatie uit een kennisbank.
• Aanbevelingen (recommender systemen) – Vector databases kunnen ook ingezet worden om informatie of producten aan te bevelen aan gebruikers, al dan niet op basis van hun historiek of voorkeuren.
• Multimodal similarity search – Bepaalde embedding modellen zijn in staat om vectoren aan te maken voor meerdere types van gegevens: niet enkel tekst, maar ook afbeeldingen, audio of video. Vector databases kunnen op die manier zoeken mogelijk maken naar gelijkaardige content, ongeacht of het gaat over tekst, afbeeldingen, audio of video.

Marktoverzicht

De initiële spelers op de markt voor vector databases, zoals Chroma, Milvus, Pinecone en Weaviate, boden voornamelijk purpose-built oplossingen aan. Pas later sprongen de meer gevestigde spelers op de kar. Zo bieden ElasticSearch en Postgresql (met de pgvector extensie) ook ondersteuning voor vector search. Uiteraard zijn ook de grote spelers vertegenwoordigd in het landschap: Microsoft biedt Azure AI Search, Google Vector AI Vector Search en Amazon Kendra.

Zo goed als alle oplossingen integreren met LLM orchestratie oplossingen zoals LangChain en LlamaIndex. Meer en meer bieden vector databases ook ingebouwde ondersteuning voor RAG, waarbij het aanmaken van embeddings en aanroepen van een taalmodel niet meer extern aan de vector database moet georchestreerd worden.

Ook vermeldenswaardig is Neo4j, dat naast graph search ook vector search ondersteunt en daarmee geschikt is voor cases met zowel gestructureerde als ongestructureerde gegevens.

Conclusie

Tot slot kunnen we stellen dat vector databases kunnen zorgen voor betere, relevantere zoekresultaten ten opzichte van een eenvoudige keyword search. Bij generative question answering toepassingen kunnen vector databases helpen een taalmodel antwoorden te laten formuleren op basis van de meest relevante informatie uit een kennisbank. Terwijl het niet evident is om grote taalmodellen op eigen infrastructuur te draaien, is dat bij vector database als retrieval component wel mogelijk, wat een gunstige factor kan zijn in het kader van gegevensbescherming.

Uit eigen ervaring merken we dat hybride search, een combinatie van vector search en lexical search, een quick win kan zijn om de zoekresultaten te verbeteren. Semantic ranking kan daarbovenop nog een extra boost geven aan de relevantie van de resultaten.

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.

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é.

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).

• 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.

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.

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).

• 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.

(NL) De term “confidential computing” duikt vaak op in gesprekken over gegevensbescherming en cloudinfrastructuren. Maar wat is vertrouwelijke gegevensverwerking? Wat zijn de belangrijkste bestaande technieken? Wat kunnen ze? Hoe werken ze? Wat zijn hun beperkingen? Deze presentatie probeert deze vragen zo eenvoudig mogelijk te beantwoorden. Er worden voorbeelden gegeven van producten die beschikbaar zijn gesteld door fabrikanten in de sector en er wordt afgesloten met enkele aanbevelingen en waarschuwingen.

Recording

Presentation

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.

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.

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.