Het opmerkelijke meertalige potentieel van grote taalmodellen (LLM’s) heeft bijgedragen aan de brede verspreiding en integratie ervan binnen AI-gebaseerde toepassingen. Er bestaan echter prestatieverschillen tussen het Engels en andere talen, met name talen met beperkte middelen.

Bij de evaluatie van een door ons ontwikkelde RAG-chatbot stelden we een duidelijk verschil vast in de kwaliteit van de antwoorden, afhankelijk van de gebruikte taal. De chatbot leverde namelijk betere antwoorden in het Frans dan in het Nederlands. De in het Frans gegenereerde antwoorden waren vlotter en betrouwbaarder ten opzichte van de door de gebruiker gevraagde informatie. De antwoorden in het Nederlands waren over het algemeen minder relevant. Deze resultaten wijzen op een cruciale uitdaging bij de ontwikkeling van LLM’s die door chatbots worden gebruikt: hoewel deze indrukwekkende meertalige capaciteiten hebben, vertonen de huidige modellen vaak een uitgesproken voorkeur voor talen met veel middelen, zoals het Engels.

In deze blogpost beschrijven we de resultaten van ons onderzoek naar de door ons vastgestelde taalkloof en tonen we de bevindingen van ons onderzoek.

Prestatieverschil tussen het Engels en de andere talen: oorzaken en factoren

Verschillende factoren dragen bij aan de taalvoorkeur voor het Engels. Deze omvatten:

• Onevenwichtige datasets: het trainingsproces van grote taalmodellen is gebaseerd op omvangrijke tekstcorpora, maar deze worden sterk gedomineerd door het Engels, gevolgd door talen met veel taalkundige middelen zoals het Chinees, het Frans en het Spaans. Daarentegen zijn de data in talen met beperkte middelen vaak van mindere kwaliteit vanwege het beperkte aantal bronnen. Dit onevenwicht in de data leidt tot slechte prestaties in andere talen dan het Engels, met hogere foutpercentages en hallucinaties tot gevolg. Om dit probleem op te lossen, maken modelontwikkelaars gebruik van een techniek die “interlinguïstische overdracht” genoemd wordt. Hierbij verbetert een model zijn prestaties in minder goed uitgeruste talen door universele of gedeelde taalkundige patronen af te leiden uit talen met veel middelen. Hoewel het exacte percentage Engelstalige data in propriëtaire modellen niet openbaar bekend is, is 93% van de data die worden gebruikt om GPT-3 te trainen in het Engels. Leveranciers van grote taalmodellen, zoals OpenAI en Google, maken vaak gebruik van het Common Crawl-webgegevensarchief, dat zelf wordt gekenmerkt door een dataset waarin het Engels overheerst (44% in het Engels, 4% in het Frans, 2% in het Nederlands). Deze vertekening wordt nog versterkt in gespecialiseerde domeinen zoals financiën en gezondheidszorg, waar hoogwaardige data bijzonder schaars is. Het is belangrijk op te merken dat het Nederlands wordt beschouwd als een taal met hoge middelen in het domein van automatische natuurlijke taalverwerking (NLP), hoewel het over minder middelen beschikt dan het Frans of het Engels.
• Morfologie en tokenisatie: modelarchitecturen zijn vaak geoptimaliseerd voor het Engels. Tokenisatieprocessen kunnen ingewikkeld zijn voor talen die niet met het Latijns alfabet worden geschreven, zoals het Chinees of het Japans, alsook voor talen met een gemiddelde tot hoge morfologische complexiteit, zoals het Nederlands. Engelse tokenizers kunnen het moeilijk hebben met het verwerken van samengestelde woorden (de combinatie van meerdere zelfstandige naamwoorden in een woord), wat kan leiden tot grammaticaal foute resultaten wanneer modellen tekst genereren.

Zeer weinig studies hebben de prestaties geanalyseerd van grote taalmodellen in het Frans en het Nederlands. Een onderzoek naar de taalkundige kwaliteit van LLM’s in deze twee talen bracht aan het licht dat de prestaties algemeen beter waren in het Frans dan in het Nederlands, in het bijzonder bij taken waarbij tekst moest worden gegenereerd [1]. Een ander onderzoek rapporteerde betere prestaties van LLM’s in het Engels in vergelijking met het Nederlands bij een vraag-antwoordtaak [2].

In de industrie blijven er grote uitdagingen bestaan met betrekking tot de toepassing van grote taalmodellen op niet-Engelse technische domeinen, met name in de medische en financiële sector. De huidige implementaties vereisen vaak een verfijning van de vooraf getrainde modellen zoals Mistral en Llama om bevredigende prestaties te bereiken.

Een andere bekende uitdaging bij de toepassing van AI-modellen in de Nederlandse taalomgeving is spraakherkenning. Dit is grotendeels een gevolg van de grote variatie in regionale accenten. Onze experimenten met het transcriberen van opnames van Teams-vergaderingen hebben aangetoond dat de Franse transcripties systematisch van betere kwaliteit waren dan de Nederlandse. Gespecialiseerde tools zoals Sembly leveren echter acceptabele transcriptieresultaten in het Nederlands.

Vergelijkende analyse van de prestaties van het Nederlands en het Frans in een chatbot

Er is een vergelijkende analyse van de prestaties uitgevoerd op een chatbot die is ontwikkeld om vragen van burgers te beantwoorden. Voor de eerste evaluatie van de chatbot hebben we een reeks vragen gebruikt die door experts zijn opgesteld. Deze vragen werden in het Frans en het Nederlands aan de chatbot voorgelegd, waarna de antwoorden door dezelfde expert werden beoordeeld en door twee andere personen werden gecontroleerd. Uit de eerste evaluatie blijkt een aanzienlijk verschil in prestaties tussen de twee talen: de chatbot behaalde een nauwkeurigheid van 95% in het Frans, tegenover 82% in het Nederlands.

Na de implementatie van de chatbot in een productieomgeving werd een tweede evaluatiefase uitgevoerd op basis van vragen die door gebruikers waren ingediend en in een database waren opgeslagen. We merkten opnieuw een verschil in prestaties: 82% nauwkeurigheid in het Frans en 69% in het Nederlands.

Verschillende factoren kunnen bijdragen aan deze waargenomen verschillen, waaronder:

• de vooringenomenheid van de beoordelaars – beoordelaars zijn minder of meer streng in hun beoordelingen;
• de variatie in het soort vragen (dubbelzinnig, slecht geformuleerd, niet ter zake) – dezelfde vragen werden niet systematisch in beide talen beoordeeld;
• het kwaliteitsverschil bij het ophalen van de bronnen (retrieval) – er zijn verschillen tussen de talen in de data-bronnen die worden opgehaald om de generatie te voeden;
• de intrinsieke capaciteiten van het generatieve model (GPT-4o) in beide talen.

Er was dus aanvullend onderzoek nodig om de waargenomen verschillen in het Frans en het Nederlands volledig te begrijpen en deze factoren te verminderen.

Test

Om de prestaties van LLM’s in zowel het Frans als het Nederlands grondig te evalueren, werd een experiment uitgevoerd met de chatbot. We selecteerden een aantal vragen waarvan de eerdere antwoorden van LLM’s als onjuist waren beoordeeld, waarbij we ervoor zorgden dat de vragen niet te complex of te simplistisch waren. Het was van cruciaal belang dat elke vraag van een gebruiker tussen het Frans en het Nederlands werd vertaald om een directe vergelijking te vergemakkelijken. Bij het evaluatieproces waren twee onafhankelijke evaluatoren betrokken, een vakexpert en een technisch expert, om vooringenomenheid te beperken en een robuuste evaluatie te garanderen. De evaluatoren beoordeelden de nauwkeurigheid, relevantie en vlotheid van de gegenereerde antwoorden. Daarnaast werden ook andere modellen dan GPT-4o getest.

Naast de tests in het Nederlands en het Frans hebben we ook een test uitgevoerd waarbij vragen in het Nederlands naar het Engels werden vertaald. De antwoorden werden in het Engels gegenereerd en vervolgens opnieuw naar het Nederlands vertaald.

Resultaten

Vraag in het Nederlands, antwoord in het Engels

Het experiment waarbij vragen in het Nederlands naar het Engels werden vertaald en hierna de antwoorden naar het Nederlands werden vertaald leverde een genuanceerd resultaat. Hoewel de vertaling van Nederlandstalige vragen naar het Engels leidde tot ietwat betere antwoorden, van 67% naar 73%, verslechterde de kwaliteit van de antwoorden bij het omgekeerde proces, namelijk het vertalen van de gegenereerde Engelse antwoorden naar het Nederlands.

Nauwkeurigheid van Franse antwoorden versus nauwkeurigheid van Nederlands antwoorden

Tijdens ons experiment hebben we de antwoorden gegenereerd op basis van Nederlandstalige vragen vergeleken met hun Franse equivalenten in verschillende tekstreeksen. We hebben vastgesteld dat de samenstelling van deze reeksen een invloed had op de evaluatie van het model. De scores varieerden namelijk van set tot set voor elk model en elke taal, en de prestatieverschillen tussen de talen kwamen niet altijd tot uiting. Dit onderstreept het belang van het selectieproces van de testvragen: voor onze laatste test hebben we een evenwichtige testset samengesteld met voorbeelden van vragen die door gebruikers in beide talen zijn ingediend en vragen die door domeinexperts zijn opgesteld. In tegenstelling tot wat aanvankelijk werd waargenomen, laten de onderstaande resultaten slechts een klein verschil in nauwkeurigheid zien tussen het Frans en het Nederlands voor onze use case.

Tabel 1. Resultaten van de eindevaluatie van de chatbot.

Opmerking: slecht geformuleerde vragen in het Frans of Nederlands werden uit de testset verwijderd omdat ze moeilijk nauwkeurig in de andere taal te vertalen bleken.

Vergelijking van de LLM’s

GPT-5 presteerde goed op het vlak van nauwkeurigheid en beknoptheid. Het vertoonde echter een groter verschil in nauwkeurigheid tussen het Frans en het Nederlands dan de andere modellen. Gemini presteerde weliswaar beter in zowel het Frans als het Nederlands, maar genereerde aanzienlijk langere antwoorden, wat leidde tot een hoger tokengebruik. We hebben ook vastgesteld dat Claude Sonnet, met een vergelijkbare nauwkeurigheid als Gemini, soms Engelse termen invoegde in het gegenereerde antwoord, en dit vaker in het Nederlands dan in het Frans. Na evaluatie concludeerden de experts op dit gebied dat Gemini het meest geschikte model was voor hun use case.

Effect van de retrieval

Het proces van retrieval bestaat erin om relevante tekstfragmenten te extraheren om een vraag te beantwoorden vanuit de vector database, afhankelijk van de gelijkenis tussen de vraag en deze fragmenten. Deze gelijkenis wordt berekend met behulp van vectorrepresentaties van de teksten, gegenereerd door een embeddingmodel. We hebben vragen geanalyseerd die aanvankelijk betere resultaten opleverden in het Frans dan in het Nederlands en hebben vastgesteld dat ongeveer 50% van de opgehaalde informatie (context) in beide talen voorkwam. Om de impact van de resterende 50% afwijkende informatie te evalueren, hebben we het model (Gemini) aan identieke contexten onderworpen om zowel Franstalige als Nederlandstalige antwoorden te genereren. Ondanks het gebruik van deze identieke contexten bleef het model prestatieverschillen vertonen tussen het Frans en het Nederlands. Het retrievalproces lijkt dus een beperkte invloed te hebben op het waargenomen prestatieverschil tussen de twee talen.

Conclusie en aanbevelingen

Het prestatieverschil tussen het Nederlands en het Engels in grote taalmodellen is een vaststaand feit, dat geworteld is in de overweldigende dominantie van het Engels in de trainingscorpora. Dit verschil wordt nog versterkt door de specifieke morfologie van het Nederlands. Ter vergelijking: als LLM’s over het algemeen betere resultaten opleveren in het Frans, is dat te danken aan een betere vertegenwoordiging van de taal in de trainingscorpora.

Ons experiment heeft waardevolle informatie opgeleverd over de prestaties van LLM’s in een RAG-toepassing (Retrieval Augmented Generation) in het Nederlands en het Frans. Hoewel we aanvankelijk een significant verschil in nauwkeurigheid tussen de antwoorden in het Nederlands en de antwoorden in het Frans constateerden, bleek uit grondig onderzoek dat andere factoren dan de capaciteit van het model de resultaten konden beïnvloeden. Het prestatieverschil is dus minder groot dan we dachten. Bovendien hebben we vastgesteld dat variaties in de samenstelling van de testset kleine schommelingen in de resultaten veroorzaakten. Deze conclusies tonen aan dat de prestaties van LLM’s zeer gevoelig zijn voor de context en de specifieke formulering van de vragen. We hebben ook een lichte kwaliteitsverbetering  van de antwoorden waargenomen bij de Engelse vertaling van Nederlandstalige vragen; dit voordeel werd echter grotendeels tenietgedaan door de daaropvolgende Nederlandse vertaling van deze Engelse antwoorden.

De bovenstaande conclusies gelden voor een chatbot die zorgvuldig opgestelde inhoud in algemene taal gebruikt om vragen te beantwoorden. Ze zijn niet noodzakelijkerwijs van toepassing op andere use cases. Het is daarom essentieel om voor elk geval grondige evaluaties uit te voeren, zeker wanneer men in specifieke domeinen zoals gezondheidszorg, financiën, recht, enzovoort werkt.

Moeten we een eentalig model gebruiken?

We hebben deze vraag niet grondig kunnen onderzoeken. Ons literatuuronderzoek heeft geen overtuigend bewijs opgeleverd dat LLM’s voor het Nederlands de prestaties verbeteren; integendeel, de aanwezigheid van talen met veel bronnen in meertalige modellen lijkt de prestaties van minder goed bedeelde talen tot op zekere hoogte te verbeteren. Er zijn echter verschillende initiatieven genomen om LLM’s voor het Nederlands te ontwikkelen. De meest opvallende zijn:

–           GEITje: model gebaseerd op Mistral 7B en verfijnd voor het Nederlands. Dit model is niet langer beschikbaar vanwege auteursrechtelijke problemen.

–           GPT-NL: lopend initiatief, ondersteund door Nederland, om een LLM te ontwikkelen die is aangepast aan de Nederlandse taal en cultuur.

Referenties

1. Exploratory Study on the Impact of English Bias of Generative Large Language Models in Dutch and French (Rigouts Terryn & de Lhoneux, HumEval 2024)
2. Performance of Large Language Models in Domain-Specific and Underrepresented Languages: A Case Study on the Transportation Domain and Dutch Language (UHasselt)
3. MEGA: Multilingual Evaluation of Generative AI (Ahuja et al., 2023)
4. A Dutch Financial Large Language Model (Sander Noels, Jorne De Blaere & Tijl De Bie, 2024)
5. Multilingual LLMs: Progress, Challenges, and Future Directions (PremAI blogpost)
6. https://hogent-cads.github.io/blog/posts/vlaamse-spraakherkenning/ (HoGent blogpost)
7. Webinar Smals Research – Generatieve AI: verder dan de hype | Smals Research

Le potentiel multilingue remarquable des grands modèles de langage (LLM) a contribué à leur adoption et à leur intégration généralisées au sein des applications basées par l’IA. Cependant, des disparités de performance existent entre l’anglais et d’autres langues, notamment les langues à faibles ressources.

Lors de l’évaluation d’un agent conversationnel (chatbot) RAG que nous avons développé, nous avons constaté une différence nette en termes de qualité des réponses selon la langue utilisée. Plus précisément, le chatbot a produit des réponses de meilleure qualité en français par rapport au néerlandais. Les réponses générées en français se caractérisaient par une plus grande fluidité et une meilleure fidélité aux informations requises par l’utilisateur. Les réponses en néerlandais ont tendance à être moins pertinentes. Ces résultats soulignent un défi crucial dans le développement des LLM utilisés par les chatbots : bien que ceux-ci présentent des capacités multilingues impressionnantes, les modèles actuels manifestent souvent un biais prononcé en faveur des langues à ressources élevées telles que l’anglais.

Cet article de blogue détaille les résultats de notre recherche sur l’écart linguistique que nous avons identifié, présentant les résultats de notre investigation.

Écart de performance entre l’anglais et les autres langues : causes et facteurs

Plusieurs facteurs contribuent au biais linguistique en faveur de l’anglais. Ceux-ci incluent :

• Déséquilibre des données : Le processus d’entraînement des grands modèles de langage repose sur des corpus textuels importants, mais ces derniers sont massivement dominés par l’anglais, suivi par les langues bien dotées en ressources linguistiques telles que le chinois, le français ou l’espagnol. En revanche, les données dans les langues à faibles ressources sont souvent de mauvaise qualité en raison d’un nombre limité de sources. Ce déséquilibre des données entraîne de faibles performances dans les langues autres que l’anglais, donnant des taux d’erreur plus élevés et des hallucinations. Afin de remédier à ce problème, les développeurs de modèles s’appuient sur une technique appelée “transfert inter linguistique”, où un modèle améliore ses performances dans les langues moins dotées en déduisant des schémas linguistiques universels ou partagés à partir des langues à ressources élevées. Bien que le pourcentage exact de données en langue anglaise dans les modèles propriétaires ne soit pas publiquement connu, 93 % des données utilisées pour entraîner GPT-3 sont en anglais. Les fournisseurs de grands modèles de langage, tels qu’OpenAI et Google, utilisent fréquemment l’archive de données web Common Crawl, qui est lui-même caractérisé par un ensemble de données ou l’anglais est prédominant (44 % en anglais, 4 % en français, 2 % en néerlandais). Ce biais est exacerbé dans des domaines spécialisés, tels que la finance et la santé, où les données de haute qualité sont particulièrement rares. Il est important de noter que le néerlandais est considéré comme une langue à ressources élevées dans le domaine du traitement automatique du langage naturel (NLP) bien que disposant de moins de ressources que le français ou l’anglais.
• Morphologie et tokenisation : Les architectures de modèles sont souvent optimisées pour l’anglais. Les processus de tokenisation peuvent être difficiles pour les langues à écriture non latine, telles que le chinois et le japonais, ainsi que pour les langues à morphologie de complexité moyenne à élevée, telles que le néerlandais. Les tokeniseurs centrés sur l’anglais peuvent éprouver des difficultés à traiter les mots composés (la combinaison de plusieurs noms en un seul mot), ce qui peut mener à un résultat grammaticalement incorrect lorsque les modèles génèrent du texte.

Très peu d’études comparatives ont analysé les performances des grands modèles de langage en néerlandais et en français. Une étude analysant la qualité linguistique des LLM dans ces deux langues a révélé que les performances étaient généralement meilleures en français qu’en néerlandais, en particulier dans les tâches de génération d’articles [1]. Une autre étude a rapporté de meilleures performances des LLM en anglais comparativement au néerlandais dans une tâche de question-réponse [2].

Des défis importants persistent dans l’industrie concernant l’application des grands modèles de langage à des domaines techniques non anglais, en particulier dans des secteurs tels que la médecine et la finance. Les déploiements actuels nécessitent souvent un affinage des modèles pré-entrainés tels que Mistral et Llama pour atteindre des performances satisfaisantes.

Un autre défi bien connu dans l’application de modèles d’IA dans l’environnement linguistique néerlandais est la reconnaissance vocale, largement due à la grande variation des accents régionaux. Nos expériences de transcription d’enregistrements de réunions Teams ont révélé que les transcriptions françaises étaient systématiquement de meilleure qualité que les transcriptions néerlandaises. Cependant, des outils spécialisés tels que Sembly fournissent des résultats de transcription en néerlandais acceptables.

Analyse comparative des performances du néerlandais et du français dans un chatbot

Une analyse comparative des performances a été menée sur un chatbot développé pour répondre aux questions formulées par les citoyens. Pour l’évaluation initiale du chatbot, nous avons utilisé un ensemble de questions proposées par les experts métier. Ces mêmes questions ont été présentées au chatbot en français et en néerlandais, les réponses ont été évaluées par le même expert et revues par deux autres personnes. Les premières évaluations ont révélé une différence significative de performance entre les deux langues : le chatbot a obtenu un taux de précision de 95 % en français, contre 82 % en néerlandais.

Suite au déploiement du chatbot dans un environnement de production, une seconde phase d’évaluation a été réalisée en utilisant des questions soumises par les utilisateurs et enregistrées dans une base de données. Nous avons de nouveau relevé une divergence de performances : 82 % de précision en français et 69 % en néerlandais.

Plusieurs facteurs pourraient contribuer à ces écarts observés, notamment :

• Les biais introduits par les évaluateurs – les évaluateurs sont plus ou moins sévères dans leurs évaluations;
• La variation dans les types de questions (ambiguës, mal formulées, hors sujet) – les mêmes questions n’ont pas été systématiquement évaluées dans les deux langues;
• La différence de qualité dans la récupération des sources (retrieval) – on observe des variations entre les langues dans les sources de données récupérées pour alimenter la génération;
• Les capacités intrinsèques du modèle génératif (GPT-4o) dans les deux langues.

Des investigations supplémentaires étaient donc nécessaires pour pleinement comprendre les différences observées en français et en néerlandais et atténuer ces facteurs.

Test

Afin d’évaluer rigoureusement les performances des LLM à la fois en français et en néerlandais, une expérience a été menée avec le chatbot. Nous avons sélectionné un échantillon de questions où les réponses précédentes des LLM avaient été jugées inexactes, en nous assurant que les questions étaient ni trop complexes, ni trop simplistes. Il était crucial que chaque question formulée par un utilisateur soit traduite entre le français et le néerlandais pour faciliter une comparaison directe. Le processus d’évaluation a impliqué deux évaluateurs indépendants, un expert métier et un expert technique, afin de réduire les biais et d’assurer une évaluation robuste. Les évaluateurs ont évalué l’exactitude, la pertinence et la fluidité des réponses générées. De plus, d’autres modèles que GPT-4o ont été testés.

En plus des tests en néerlandais et en français, nous avons également réalisé un test où des questions en néerlandais ont été traduites en anglais. Les réponses ont été générées en anglais puis traduites à nouveau en néerlandais.

Résultats

Question en néerlandais, Réponse en anglais

L’expérience consistant à traduire des questions posées en néerlandais en anglais et à traduire ensuite des réponses en néerlandais a révélé une performance nuancée. Si la traduction des questions néerlandaises en anglais a entraîné une légère amélioration de la qualité des réponses, passant de 67 % à 73 %, le processus inverse, traduisant les réponses anglaises générées en néerlandais, a davantage dégradé la qualité des réponses.

Précision des réponses françaises versus précision des réponses néerlandaises

Lors de notre expérience, nous avons comparé les réponses générées à partir de questions en néerlandais et leurs équivalents en français sur plusieurs ensembles de test. Nous avons observé l’influence de la composition de ces ensembles sur l’évaluation du modèle. En effet, Les scores variaient d’un ensemble à l’autre pour chaque modèle et chaque langue, et les disparités de performance entre les langues ne se manifestaient pas toujours. Cela souligne l’importance du processus de sélection des questions de test: pour notre dernier test, nous avons constitué un ensemble de test équilibré intégrant des échantillons de questions soumises par les utilisateurs dans les deux langues et des questions élaborées par des experts du domaine. Contrairement à ce qui avait été initialement observé, les résultats présentés ci-dessous ne révèlent qu’une différence légère en termes de précision entre le français et le néerlandais pour notre cas d’utilisation.

Table 1. Résultats de l’évaluation finale du chatbot.

Note : Les questions mal formulées en français ou en néerlandais ont été exclues de l’ensemble de test car elles se sont révélées difficiles à traduire avec précision dans l’autre langue.

Comparaison des LLM

GPT-5 a démontré de bonnes performances en termes de précision et de concision, cependant il a présenté un écart de précision plus important entre le français et les néerlandais que les autres modèles. Gemini, bien qu’il affiche de meilleures performances tant en français qu’en néerlandais, a généré des réponses notablement plus longues, ce qui a entraîné une utilisation de jetons plus élevée. Nous avons également observé que Claude Sonnet, qui présente une précision similaire à celle de Gemini, avait quelques fois intégré de l’anglais dans la réponse générée, plus souvent en néerlandais qu’en français. Après évaluation, les experts du domaine ont conclu que Gemini était le modèle le plus adapté à leur cas d’utilisation.

Effet de la récupération

Le processus de récupération consiste à extraire des fragments de texte pertinents pour répondre à une question à partir de la base de données vectorielle, en fonction de la similarité entre la question et ces fragments. Cette similarité est calculéee à l’aide des représentations vectorielles des textes, générées par un modèle d’embedding. Nous avons analysé des questions qui avaient donné initialement de meilleurs résultats en français qu’en néerlandais et avons observé qu’environ 50 % de l’information récupérée (contexte) était partagée entre les deux langues. Afin d’évaluer l’impact des 50 % restants d’informations divergentes, nous avons soumis le modèle (Gemini) à des contextes identiques pour générer des réponses tant en français qu’en néerlandais. Malgré l’utilisation de ces contextes identiques, le modèle a continué à présenter des disparités de performance entre le français et le néerlandais. Par conséquent, le processus de récupération semble avoir une influence limitée sur l’écart de performance observé entre les deux langues.

Conclusions et recommandations

L’écart de performance des grands modèles de langage rapporté entre le néerlandais et  l’anglais est un fait établi, enraciné dans la domination écrasante de l’anglais dans les corpus d’entraînement. Cet écart est exacerbé par la morphologie spécifique du néerlandais. Comparativement, si les LLM produisent généralement de meilleurs résultats en français, cela est dû à une meilleure représentation de la langue au sein des corpus d’entraînement.

Notre expérience a fourni des informations précieuses sur les performances des LLM dans une application RAG (Retrieval Augmented Generation) en néerlandais et en français. Bien que nous ayons initialement observé une différence significative en termes de justesse entre les réponses en néerlandais et les réponses en français, des investigations approfondies ont révélé que d’autres facteurs que la capacité du modèle pouvaient influencer les résultats. L’écart de performance est donc moins important que ce que nous pensions. De plus, nous avons constaté que les variations dans la composition de l’ensemble de test introduisaient de légères fluctuations dans les résultats. Ces conclusions démontrent que la performance des LLM est très sensible au contexte et à la formulation spécifique des questions. Nous avons également observé une légère amélioration de la qualité des réponses lors de la traduction des questions néerlandaises en anglais; cependant, cet avantage a été largement annulé par la traduction ultérieure de ces réponses anglaises en néerlandais.

Les conclusions présentées ci-dessus sont valables lorsqu’on considère un chatbot utilisant des contenus soigneusement rédigées dans un langage commun pour répondre à des questions. Elles ne sont pas nécessairement applicables à d’autres cas d’utilisation, il est donc essentiel de réaliser des évaluations approfondies pour chaque cas, en particulier lorsqu’on travaille dans des domaines spécifiques tels que la santé, la finance, le droit…

Devrions-nous utiliser un modèle monolingue ?

Nous n’avons pas été en mesure d’examiner cette question de manière approfondie. Notre recherche dans la littérature n’a pas révélé de preuves solides indiquant une amélioration des performances grâce aux LLM dédiés au néerlandais ; a contrario, la présence de langues à ressources élevées dans les modèles multilingues semble améliorer la performance de langues moins dotées jusqu’à un certain degré. Cependant, plusieurs initiatives ont été lancées pour le développement de LLM en néerlandais. Les plus notables sont :

• GEITje : Un modèle basé sur Mistral 7B et affiné sur le néerlandais. Ce modèle n’est plus disponible en raison de problèmes de droits d’auteur.
• GPT-NL : Une initiative en cours, soutenue par les Pays-Bas, visant à développer un LLM adapté à la langue et à la culture néerlandaise.

Références

1. Exploratory Study on the Impact of English Bias of Generative Large Language Models in Dutch and French(Rigouts Terryn & de Lhoneux, HumEval 2024)
2. Performance of Large Language Models in Domain-Specific and Underrepresented Languages: A Case Study on the Transportation Domain and Dutch Language (UHasselt)
3. MEGA: Multilingual Evaluation of Generative AI (Ahuja et al., 2023)
4. A Dutch Financial Large Language Model (Sander Noels, Jorne De Blaere & Tijl De Bie, 2024)
5. Multilingual LLMs: Progress, Challenges, and Future Directions (article de blogue PremAI)
6. https://hogent-cads.github.io/blog/posts/vlaamse-spraakherkenning/ (article de blogue HoGent)

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

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

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

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

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

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

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

Conclusie

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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.

Note : il s’agit d’un article de vulgarisation consacré à une réglementation future, basé sur la publication officielle du 12/07/2024. Adressez-vous toujours à un·e juriste pour obtenir un avis juridique professionnel.

L’AI Act européen (en français le règlement sur l’intelligence artificielle) est une des pierres angulaires d’une série d’initiatives législatives à grande échelle destinées à réglementer l’économie numérique en Europe. Il vient ainsi compléter la législation antérieure relative à certains aspects de l’intelligence artificielle, comme le RGPD, le Digital Services Act (DSA) et le Digital Markets Act (DMA), le Data Act, le Data Governance Act, le CHIPS Act et le Cyber Resilience Act en cours d’élaboration. Après de longues négociations, l’AI Act a été approuvé par le Parlement européen en mars 2024 et par le Conseil européen en mai 2024. La publication au Journal officiel de l’Union européenne, que l’on peut appeler Moniteur européen, a eu lieu le 12 juillet 2024. Les premières règles entreront en vigueur début 2025. Vous pouvez également consulter cette chronologie.

Un RGPD bis ?

Le texte intégral de l’AI Act, y compris l’ensemble des préliminaires et annexes, comprend 144 pages. Fort heureusement, de bons résumés sont déjà disponibles ici et là. Il est ainsi presque deux fois plus long que le RGPD qui ne fait, lui, “que” 88 pages. L’impact de ce dernier est énorme : toutes les organisations traitant des données à caractère personnel – il suffit d’avoir une administration du personnel ou un fichier de clients – se sont en effet vues confrontées aux exigences relatives aux délégués à la protection des données, aux registres de traitement et aux bases juridiques du traitement des données. Chaque pays a également dû mettre en place une  Autorité de protection des données habilitée à infliger des amendes en cas d’infraction.

Le RGPD s’est également accompagné d’une certaine confusion, notamment par son utilisation fréquente de termes ouverts à l’interprétation (“approprié”, “adéquat”, “adapté”, “suffisant”…).
La nécessité de les concrétiser à nouveau pour chaque cas d’espèce alimente ce que l’on peut aujourd’hui appeler une petite industrie juridique. L’AI Act vise à fournir un peu plus d’indications, en revêtant une forme plus technique. Il comporte ainsi une liste d’annexes avec des énumérations pratiques des attentes en matière de documentation, de conformité, de transparence, etc.

L’AI Act est parti d’une proposition plus compacte de 125 pages (annexes incluses). Au cours des négociations cependant, on a assisté à l’essor fulgurant de l’IA générative et des grands modèles de langage. Cette nouvelle donne a nécessité la révision et l’ajout de certains éléments, tels qu’un nouveau chapitre (5) entièrement consacré aux modèles d’IA à usage général, parmi lesquels on compte les grands modèles de langage. Quant à certaines sections, on peut se demander ce qu’elles viennent faire dans l’AI Act, notamment un système de “bacs à sable réglementaires de l’IA” (article 57) qui doit permettre aux régulateurs de faciliter l’innovation. Certains articles sont formulés de manière plutôt énigmatique, comme la section dédiée aux “organismes d’évaluation de la conformité notifiés” (article 29), qui ne sont ni plus ni moins que des auditeurs. Des voix critiques se font donc entendre, craignant que la somme de mesures qui en résulte ne débouche avant tout sur un véritable imbroglio.

AI Act – Fondamentaux

L’AI Act s’adresse aux développeurs et aux fournisseurs d’IA, et ce uniquement lorsqu’ils publient des systèmes d’IA et les mettent à la disposition de tiers. Tous les développements et tests internes préalables sont explicitement exemptés (article 2 §8). L’AI Act ne s’applique pas non plus aux activités personnelles auxquelles vous vous adonnez dans un contexte non professionnel (article 2 §10). De même, la recherche scientifique (article 2 §6) et les applications militaires (article 2 §3) ne sont pas concernées. Bien évidemment, cela ne signifie pas que tout est permis dans tous ces cas.
Il va de soi que d’autres législations existantes restent en vigueur. Les droits des citoyens étaient déjà protégés par l’article 22 du RGPD entre autres, tandis que la législation sur les droits d’auteur continue de protéger les auteurs.

Par ailleurs, la définition de l’IA utilisée est particulièrement large et empruntée à l’OCDE : en résumé, “un système IA […] déduit, à partir des entrées, la manière de générer des sorties […]” (article 3 + considérant 12). La quasi-totalité de l’apprentissage automatique entre dans ce cadre. Dans d’autres définitions, on lit parfois que l’IA comporte un aspect cognitif (quelque chose doit être “reconnu”), mais il n’en est pas fait mention ici. Il n’est pas non plus fait mention de techniques spécifiques : tout ce qui apprend de manière adaptative ou peut réagir de manière quelque peu autonome à l’environnement est presque toujours inclus. Il s’agit donc également des systèmes que vous connaissez depuis des années, sans vous rendre compte qu’ils reposent sur l’intelligence artificielle, tels que les filtres antispam, les recommandations sur les sites web, voire les prévisions météorologiques.

L’AI Act définit d’abord et surtout une liste de pratiques interdites (article 5), qui prendra effet dès le début de l’année 2025. Cette liste est exhaustive, ce qui signifie en principe que tout ce qui n’est pas explicitement interdit est autorisé (sauf dispositions contraires prévues par d’autres lois). Aussi est-il intéressant d’examiner ce qui figure et ce qui ne figure pas dans cette liste d’interdictions, ainsi que les dispositions supplémentaires qui s’y rapportent. On découvre ainsi que :

• §1(f) : L’interdiction de la reconnaissance des émotions ne mentionne que le lieu de travail et l’enseignement.
• §1(g) : L’interdiction des systèmes d’IA biométriques ne mentionne que la déduction automatique concernant la race, la sexualité, l’affiliation à une organisation syndicale, la religion, les convictions politiques et philosophiques.
• §1(e) : L’interdiction de la reconnaissance faciale ne concerne que les systèmes basés sur ce qu’on appelle “moissonnage non ciblé”.

Elle est donc plus nuancée qu’une liste d’interdictions générales, car le contexte et l’objectif interviennent également. La reconnaissance des émotions dans les jeux vidéo, par exemple, reste ainsi autorisée. Les considérants 15 à 17 précisent que l’IA biométrique reste autorisée pour la vérification d’identité et l’authentification. Parallèlement, des exceptions sont prévues entre autres pour l’assistance médicale et la lutte contre la criminalité, bien que ces exceptions soient soumises à un contrôle strict (article 5, §2-§7), y compris une liste des infractions pénales qui entrent en ligne de compte (annexe 2).

Les systèmes qui assurent la sécurité des utilisateurs ou qui sont énumérés à l’annexe 3 sont des systèmes à haut risque (article 6). Il s’agit principalement de systèmes susceptibles d’avoir un impact majeur sur les libertés, la vie, la carrière ou la santé d’un individu. Bien que cette section de l’AI Act n’entrera en vigueur qu’à l’été 2026, il convient de noter qu’il subsiste des lacunes à combler. Par exemple, la Commission doit encore fournir des lignes directrices précisant l’interprétation de cet article (article 6 §5) et se réserve le droit d’apporter des modifications même après coup (article 6 §6-§8, article 7).

AI Act – Obligations

Quiconque souhaite construire ou a construit un système à haut risque devra se conformer à une série d’obligations, qui doivent notamment permettre aux autorités compétentes d’intervenir en cas de non-respect. Les développeurs de systèmes à haut risque devront adopter certaines pratiques, notamment :

• Un système itératif de gestion des risques (article 9), qui doit permettre d’identifier et d’évaluer les risques et d’atténuer les abus potentiels à l’avance. Le texte est relativement peu concret : il parle de “risques raisonnablement prévisibles” et de “mesures appropriées” sans autre précision. Ceci fera donc encore l’objet de discussions, mais dans la pratique, on peut déjà aujourd’hui se contenter en partie des normes récemment élaborées à cette fin, telles que la norme ISO/IEC 42001. Étant entendu qu’elle n’est pas explicitement conçue pour la loi sur l’IA Act, des mesures supplémentaires peuvent s’imposer.
• La gestion de données de qualité (article 10), qui se résume en grande partie à la transparence sur l’origine, les limites, les marges d’erreur et la représentativité. L’utilisation de Data Sheets (fiches de données), dont c’est l’objectif, est devenue populaire dans le secteur au cours des dernières années.
• Fournir une documentation technique conforme aux exigences de l’annexe 4 (annexe 11 pour l’IA à usage général). Ceci est quelque peu analogue aux Model Cards (cartes modèles) que l’on peut trouver sur le HuggingFace Hub, bien que la Commission européenne ne se contente pas de listes cochées et exige plus de détails, y compris sur la surveillance et le contrôle pendant la durée de vie du système.
• L’enregistrement (article 12) ainsi que la transparence et la fourniture d’informations aux utilisateurs (article 13).
• Le contrôle humain pendant la durée de vie du système (article 14). Si l’article 22 du RGPD en faisait déjà un droit civil, l’AI Act impose aux développeurs de prendre les mesures nécessaires à cette fin. Par exemple, il devra toujours être possible d’ignorer, de remplacer ou d’arrêter le système d’IA (article 14 §4 (d-e)).
• Prendre des mesures “appropriées” en matière de cybersécurité, de robustesse et d’exactitude (article 15). Cet article reste lui aussi relativement vague à l’heure actuelle et fait référence à l’intention de la Commission de soutenir le développement des étalonnages nécessaires.

Quiconque publie, met à disposition, incorpore dans son propre produit, importe ou distribue un système à haut risque devra prendre des mesures similaires, notamment :

• Vérifier et prouver la conformité du système (article 16 §e-l, articles 40-47), établir une déclaration de conformité (annexe 5) et obtenir le marquage CE (article 48). 
• Utiliser un système de gestion de la qualité (article 17).
• Conserver la documentation nécessaire pendant 10 ans après la mise en service (article 18).
• Coopérer avec les autorités compétentes (article 21).
• Enregistrer le système (article 49) dans une base de données européenne dédiée (article 71).
• Désigner une personne de contact ou un représentant pour tout ce qui précède (article 22).
• Mettre en place la surveillance nécessaire et agir en cas de problème (article 26 §5 et articles 72-73), notamment en informant l’autorité compétente.

Par analogie avec l’analyse d’impact relative à la protection des données du RGPD, certaines organisations, dont toutes les autorités publiques et les organisations de service public, devront réaliser une analyse d’impact sur les droits fondamentaux (Fundamental Rights Impact Assessment ou FRIA) dont les résultats devront être communiqués aux régulateurs du marché compétents (article 27). L’AI Office européen est déjà chargé de développer les questionnaires automatisés nécessaires à l’acquittement de cette obligation (article 27 §5).

On en oublierait presque que la grande majorité des systèmes d’IA sont simplement des systèmes à faible risque. À cet égard, l’AI Act est assez succinct : ils doivent satisfaire à des exigences minimales de transparence uniquement pour des applications spécifiques (article 50). Ainsi, l’utilisateur final doit toujours savoir qu’il interagit avec un système d’IA, et les résultats générés artificiellement doivent être clairement identifiés comme tels. La mainmise redoutée sur l’ensemble de l’industrie de l’IA est donc toute relative.

IA à usage général

Le développement récent de l’IA générative à usage général pour le texte et les images a nécessité l’ajout d’une catégorie distincte de systèmes, à savoir l’IA à usage général. La Commission européenne considère que ce type d’IA, indépendamment d’un éventuel risque élevé en matière de droits civils, peut également présenter un risque systémique (article 51). Le bien-fondé ou non de cette position fait l’objet d’un débat acharné dans les cercles techniques et philosophiques, mais l’UE adopte une approche prudente et prévoit un bâton juridique.

La Commission européenne se donne la liberté de déterminer les systèmes qui présentent un tel risque (article 51 §1). Bien qu’elle affirme appliquer des critères objectifs pour ce faire (annexe 13), il n’y a pas de véritable formule. Néanmoins, l’article 51 §2 fixe étonnamment une limite très concrète, à savoir qu’à partir du moment où son entraînement requiert une puissance de calcul de 10²⁵ FLOPS, un modèle d’IA à usage général est par définition considéré comme présentant un risque systémique. Cela correspond approximativement à un temps d’entraînement d’un an sur un cluster de 4000 GPU de type Nvidia RTX4090 (avec une puissance de calcul de 82×10¹² FLOPS). Pour éviter que tout cela ne devienne obsolète demain, la Commission se réserve le droit d’adapter ces valeurs à l’avenir en fonction des évolutions du domaine (article 51 §3).

Outre les exigences minimales de l’article 50 et indépendamment de la classification des risques, l’IA à usage général est soumise à son propre ensemble d’exigences en matière de documentation technique (article 53, annexe 11), qui seront un peu élargies en présence d’un risque systémique (article 55). Les constructeurs de modèles d’IA à usage général sans risque systémique publiés sous licence libre sont exemptés de certaines obligations (article 53 §2, voir également les considérants 102 à 104) et ne sont pas non plus tenus de désigner une personne de contact ou un représentant (article 54 § 6).

AI Office (Bureau de l’IA)

L’AI Act devra également être appliqué. Un rôle majeur dans ce cadre sera joué par l’AI Office (Bureau de l’IA, article 64), qui devrait être à l’AI Act ce que le Contrôleur européen de la protection des données est au RGPD. L’AI Office est actuellement mis en place à grande vitesse, les premières dispositions entrant en vigueur début 2025. Outre la responsabilité de compléter une série d’articles en suspens de l’IA Act, l’AI Office se verra confier la compétence exclusive de la surveillance de l’IA à usage général (article 75).

En pratique, l’AI Office fera partie de la DG CONNECT, commencera avec 140 collaborateurs et sera dirigé par Lucilla Sioli. Il sera soutenu dans son fonctionnement par le Centre européen pour la transparence algorithmique (ECAT), un Comité AI (article 65), un forum consultatif des parties prenantes (article 67) et un groupe scientifique d’experts indépendants (article 68).

Des régulateurs doivent également être désignés au niveau national (article 70). Ils devront travailler en étroite collaboration avec l’AI Office de l’UE et avec les régulateurs industriels et sectoriels existants, qui aujourd’hui sont déjà responsables du marquage CE, par exemple. Aux Pays-Bas, l’Autoriteit Persoonsgegevens joue clairement un rôle de pionnier dans la mise sur pied d’une autorité néerlandaise de l’IA, qui sera probablement établie dans le giron de l’Autoriteit Persoonsgegevens. En Belgique, la situation reste calme, même si le temps presse. En effet, on ne peut pas non plus engager n’importe qui pour occuper ces fonctions assez spécialisées.

Conclusion

Il est important de retenir que l’AI Act n’impose aucune restriction aux systèmes d’IA à faible risque, à l’exception de l’IA à usage général qui requiert la transparence nécessaire. Ce n’est que pour les systèmes à risques élevés ou systémiques et mis en production qu’interviennent des exigences strictes et la nécessité de se conformer aux réglementations pertinentes. Même dans ce cas, de nombreuses mesures d’atténuation offrent une marge de manœuvre supplémentaire au développement interne, aux initiatives open source, à la science, à la défense, etc.

Dans une certaine mesure, l’AI Act se veut concret, par une énumération détaillée des attentes et la mention de diverses précisions dans les considérants et les annexes. Il y parvient en partie et devient ainsi assez technique, de sorte qu’un juge concerné devra apprendre ce que sont les FLOPS. Parallèlement, il subsiste de nombreuses lacunes à combler et il reste à voir où le nouvel AI Office placera la barre dans les futures Commissions. La possibilité de modifier ultérieurement l’IA Act a été envisagée ici et là. La version actuelle de l’IA Act ne sera donc certainement pas la dernière.

Enfin, en Belgique, il ne s’agit pas d’attendre trop longtemps pour désigner et organiser le(s) régulateur(s) national(aux) pour l’AI Act si l’on veut être un tant soit peu en phase avec le reste de l’Europe. Pour obtenir des outils pratiques qui peuvent, entre autres, vous aider à vous mettre en conformité, vous pouvez d’ores et déjà consulter la base de données du Kenniscentrum Data & Maatschappij. De nombreux autres documents y seront certainement publiés lorsque l’AI Act entrera effectivement en vigueur.

______________________

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.

Noot: dit is een populariserend artikel over toekomstige regelgeving, gebaseerd op de officiële publicatie dd. 12/07/2024. Wend u steeds tot een jurist voor professioneel juridisch advies.

De Europese AI Act (in het Nederlands de verordening artificiële intelligentie) is een hoeksteen van een reeks grootschalige wetgevende initiatieven die de digitale economie in Europa in een gereguleerd framework moeten gieten. Ze is daarmee complementair met eerdere wetgeving die bepaalde aspecten van het AI-gebeuren beïnvloedt, zoals de GDPR (AVG), de Digital Services Act (DSA) en Digital Markets Act (DMA), de Data Act, de Data Governance Act, de CHIPS Act en de voorgestelde Cyber Resilience Act . Na lang onderhandelen werd de AI Act in maart 2024 goedgekeurd door het Europees parlement en in mei door de Europese raad. De publicatie in het Official Journal of the European Union, zeg maar het Europese Staatsblad, vond plaats op 12 juli 2024, waarna de eerste regels begin 2025 van kracht worden – zie ook deze tijdslijn.

GDPR bis?

De volledige (Engelstalige) tekst van de AI Act, inclusief alle voorbeschouwingen en bijlagen, is een fenomenale 144 bladzijden lang – gelukkig zijn er her en der al goede samenvattingen te vinden. Daarmee is ze bijna 2 keer langer dan de “slechts” 88 pagina’s tellende GDPR. Van die laatste is de impact enorm: elke organisatie die persoonsgegevens verwerkt – een personeelsadministratie of klantenbestand hebben is voldoende – kreeg te maken met DPO’s, verwerkingsregisters, en rechtsgronden voor gegevensverwerking. Elk land moest ook een Gegevensbeschermingsautoriteit opzetten met de bevoegdheid om inbreuken te beboeten.

De GDPR bracht ook heel wat onzekerheid met zich mee, met name door haar veelvuldig gebruik van termen die voor interpretatie vatbaar zijn (“appropriate”, “adequate”, “suitable”, “sufficient”, …). De nood om die opnieuw te concretiseren voor elke voorliggende zaak, is de voedingsbodem voor wat ondertussen een kleine juridische industrie kan genoemd worden. De AI Act poogt om iets meer houvast te geven, door een meer technische toer op te gaan. Zo bevat ze een lijst Annexen met praktische opsommingen over wat verwacht wordt als gevraagd wordt naar documentatie, conformiteit, transparantie e.d.

De AI Act begon met een compacter voorstel van 125 bladzijden (inclusief bijlagen). Tijdens de onderhandelingen zagen we echter de razendsnelle opkomst van generatieve AI en de Large Language Models. Dat noodzaakte om een en ander te herzien en toe te voegen, zoals een nieuw hoofdstuk (5) over General Purpose AI, waartoe LLMs gerekend kunnen worden. Van andere onderdelen kan men zich dan weer afvragen wat ze in de AI Act komen doen, zoals een systeem van “Regulatory Sandboxes” (Art.57) dat regulatoren moet toelaten om innovatie te faciliteren. Sommige artikels zijn wel erg cryptisch verwoord, zoals de sectie over “Notified Conformity Assessment Bodies” (Art.29), waarmee men eigenlijk gewoon auditors bedoelt. Er zijn dan ook kritische stemmen te horen, die vrezen dat de resulterende optelsom aan maatregelen vooral een ingewikkeld kluwen is geworden.

De AI Act – basics

De AI Act is gericht op AI-ontwikkelaars en -aanbieders, en dat eigenlijk pas zodra ze AI-systemen publiceren en ter beschikking stellen van derden. Alle in-house ontwikkeling en testing die daaraan vooraf gaat, is expliciet uitgezonderd (Art.2§8). De AI Act grijpt ook niet in op wat je persoonlijk in niet-professionele context doet (Art.2§10). Wetenschappelijk onderzoek (Art.2§6) en militaire toepassingen (Art.2§3) tellen ook niet mee. Dat betekent natuurlijk niet dat in al die gevallen alles mag: uiteraard blijft andere bestaande wetgeving gewoon van kracht. De rechten van burgers werden al beschermd door de GDPR met o.a. haar Art.22, en de auteursrechtenwetgeving blijft auteurs beschermen.

De gehanteerde definitie van AI is dan weer opvallend breed, en is geleend van de OESO: samengevat, “AI systems infer, from their input, how to generate outputs” (Art.3 + Overweging 12). Zowat alle machine learning valt daaronder. In andere definities leest men al eens dat er een cognitief aspect aan AI verbonden is (er moet iets “herkend” worden), maar daar is hier geen sprake van. Ook over specifieke technieken wordt met geen woord gerept: al wat adaptief leert of enigszins autonoom kan reageren op de omgeving, valt er haast altijd onder. Dit gaat dus ook over systemen die je al jarenlang kent, zonder er bij stil te staan dat er AI achter zit: spamfilters, aanbevelingen op websites, zelfs weersvoorspellingen.

De AI Act definieert eerst en vooral een lijst met verboden toepassingen (Art.5), die begin 2025 al van kracht zal worden. Deze lijst is een limitatieve opsomming, wat in principe ook betekent dat wat niet expliciet verboden is, toegelaten is (tenzij verhinderd door andere wetten). Het is daarom interessant om in detail te kijken wat wel en niet in die lijst staat, en met welke bijkomende bepalingen. Zo lezen we:

• §1(f): Het verbod op emotieherkenning vermeldt enkel de werkvloer en het onderwijs,
• §1(g): Het verbod op biometrische AI-systemen vermeldt enkel de automatische afleiding van ras, seksualiteit, vakbondslidmaatschap, religie, politieke en filosofische overtuiging,
• §1(e): Het verbod op gezichtsherkenning heeft het enkel over systemen op basis van “untargeted scraping”,

Het is genuanceerder dan een lijstje algemene verbodsbepalingen, want ook context en doel spelen een rol. Emotieherkenning in bijvoorbeeld computergames blijft op die manier dus toegelaten. Overwegingen 15-17 preciseren dat biometrische AI toegelaten blijft voor identiteitsverificatie en authenticatie. Daarnaast zijn er ook enkele uitzonderingen ingebouwd voor o.a. de medische hulpverlening en de criminaliteitsbestrijding – al worden die uitzonderingen wel onder een streng toezicht geplaatst (Art.5§2-§7), inclusief een lijst van criminaliteit die ervoor in aanmerking komt (Annex 2).

Systemen die instaan voor de veiligheid van gebruikers, of die opgesomd zijn in Annex 3, zijn hoogrisico-systemen (Art.6). Het gaat hierbij vooral om systemen die een grote impact kunnen hebben op iemands vrijheden, levensloop, carrière of gezondheid. Hoewel dit onderdeel van de AI Act pas in voege zal treden in de zomer van 2026, valt het op dat er nog verschillende gaten in te vullen zijn. Zo moet de Commissie nog met een reeks verduidelijkende richtlijnen komen voor de interpretatie van dit artikel (Art.6§5), en behoudt ze zich het recht voor om ook achteraf nog wijzigingen aan te brengen (Art.6§6-§8, Art.7).

AI Act – verplichtingen

Wie een hoogrisicosysteem wil bouwen of gebouwd heeft, zal aan een reeks verplichtingen moeten voldoen, die o.a. moeten toelaten dat de bevoegde autoriteiten kunnen ingrijpen als het ontspoort. Ontwikkelaars van hoogrisicosystemen zullen bepaalde praktijken moeten adopteren, waaronder:

• Een iteratief risicobeheerssysteem (Art.9), dat moet toelaten de risico’s te inventariseren, in te schatten, en potentieel misbruik op voorhand te mitigeren. Concreter dan dat wordt het niet gemaakt: de tekst spreekt van “reasonably foreseeable risks” en “appropriate measures” zonder verdere specificatie. Dit zal dus nog voor wat discussie zorgen, maar in de praktijk kan men zich vandaag al deels behelpen met standaarden die recent voor dit doel ontwikkeld zijn, zoals ISO/IEC 42001 – met dien verstande dat die niet expliciet voor de AI Act is gemaakt en bijkomende maatregelen nodig kunnen zijn.
• Kwalitatief databeheer (Art.10), wat er grotendeels op neerkomt dat er transparantie moet zijn over de oorsprong, beperkingen, foutenmarges en representativiteit. Het gebruik van “Data Sheets“, die dit beogen, was de laatste jaren in de sector sowieso al populair geworden.
• Het voorzien van technische documentatie volgens de vereisten in Annex 4 (Annex 11 voor General Purpose AI). Dit is enigszins analoog met de Model Cards zoals men die kan vinden op de HuggingFace Hub, al neemt de Europese Commissie geen genoegen met afgevinkte lijstjes en vraagt ze meer detail, onder andere over monitoring en controle tijdens de levensduur van het systeem.
• Het voorzien van logging (Art.12) en transparante informatievoorziening naar de gebruikers toe (Art.13)
• Menselijk overzicht tijdens de levensduur van het systeem (Art.14). Waar GDPR art.22 daar al een burgerrecht van maakte, verplicht de AI Act aan de ontwikkelaars om de nodige maatregelen daartoe te nemen. Er zal bijvoorbeeld altijd de mogelijkheid moeten zijn om het AI-systeem te negeren, te overrulen, of te stoppen (Art.14§4(d-e)).
• Het nemen van “appropriate” maatregelen inzake cybersecurity, robuustheid en accuraatheid (Art.15). Ook dit artikel blijft momenteel nog relatief vaag en verwijst naar de intentie van de Commissie om de ontwikkeling van de nodige benchmarks te ondersteunen.

Wie een hoogrisicosysteem publiceert, ter beschikking stelt, verwerkt in een eigen product, importeert of distribueert, zal gelijkaardige maatregelen moeten nemen, waaronder:

• De conformiteit van het systeem controleren en bewijzen (Art.16§e-l, Art. 40-47), een conformiteitsverklaring opstellen (Annex 5), en CE markering bekomen (Art.48)
• Een kwaliteitsmanagementsysteem benutten (Art.17)
• De nodige documentatie tot 10 jaar na ingebruikname bijhouden (Art.18)
• Samenwerken met de bevoegde autoriteiten (Art.21)
• Het systeem registreren (Art.49) in een speciaal daartoe opgezette EU database (Art.71)
• Voor al het bovenstaande een contactpersoon of vertegenwoordiger aanduiden (Art.22)
• De nodige monitoring opzetten en actie ondernemen wanneer het misloopt (Art.26§5, Art.72-73), waaronder het inlichten van de bevoegde autoriteit.

Naar analogie met Gegevensbeschermingseffectbeoordeling (Data Protection Impact Assessment – DPIA) uit de GDPR, zullen sommige organisaties, waaronder alle overheidsinstanties en organisaties van publieke dienstverlening, een Fundamental Rights Impact Assessment of FRIA moeten uitvoeren, waarvan de resultaten aan de bevoegde marktregulatoren meegedeeld moeten worden (Art. 27). Het Europese AI Office krijgt alvast de taak om voor deze verplichting de nodige geautomatiseerde vragenlijsten te ontwikkelen (Art. 27§5).

Men zou bijna vergeten dat verreweg de meeste AI-systemen gewoon laag-risico systemen zijn. Daarover is de AI Act vrij kort: die moet enkel voor specifieke toepassingen voldoen aan minimale transparantievereisten (Art.50). Zo moet de eindgebruiker altijd weten wanneer die met een AI-systeem interageert, en moet artificieel gegenereerde output duidelijk als dusdanig gemarkeerd worden. Met die gevreesde wurggreep rond de gehele AI-industrie valt het dus eigenlijk best wel mee.

General purpose AI

De recente ontwikkeling van algemeen inzetbare generatieve AI voor tekst en afbeeldingen noopte tot de toevoeging van een aparte categorie aan systemen: General Purpose AI (GPAI). De Europese Commissie is van mening dat dit soort AI, onafhankelijk van een eventueel hoog risico inzake burgerrechten, ook een systemisch risico met zich mee kan brengen (Art.51). Of dat gegrond is of niet, is in zowel technische als filosofische kringen onderwerp van fel debat, maar de EU neemt het zekere voor het onzekere en voorziet een juridische stok achter de deur.

De Commissie geeft zichzelf de vrijheid om te beslissen welke systemen zo’n risico manifesteren (Art.51§1). Hoewel ze zich voorneemt daarvoor objectieve criteria te benutten (Annex 13), is er geen vaste formule. Of toch: er is verrassend genoeg 1 opvallend concrete grenswaarde vastgelegd in Art.51§2: vanaf dat de training 10²⁵ FLOPs aan rekenkracht vergt, wordt een GPAI per definitie aanzien als systemisch risicovol. Dit komt ongeveer overeen met een trainingstijd van 1 jaar op een cluster van 4000 GPUs van het type Nvidia RTX4090 (met 82*10¹² FLOPs aan rekenkracht). Om te vermijden dat dit alles morgen al achterhaald is, behoudt de Commissie zich het recht voor om deze waarden in de toekomst aan te passen aan de evoluties in het domein (Art.51§3).

General Purpose AI wordt, naast de minimale vereisten van Art.50, en ongeacht de risicoclassificatie, onderworpen aan een eigen reeks technische documentatieverplichtingen (Art. 53, Annex 11), die nog wat uitgebreid worden wanneer een systemisch risico aanwezig is (Art. 55). Bouwers van GPAI modellen zonder systemisch risico die onder vrije (¹) open-source licenties worden vrijgegeven, zijn van sommige verplichtingen uitgezonderd (Art.53§2, zie ook Overwegingen 102-104), en hoeven ook geen contactpersoon of vertegenwoordiger aan te duiden (Art.54§6).

Het AI Office

De AI Act zal ook afgedwongen moeten worden. Een grote rol daarbij is weggelegd voor het Europese AI Office (NL: AI-bureau, Art.64), dat voor de AI Act moet zijn wat de European Data Protection Supervisor is voor de GDPR. Het AI Office wordt momenteel aan sneltempo in de steigers gezet, want begin 2025 treden de eerste bepalingen in voege. Naast de verantwoordelijkheid om nog een reeks openstaande onderdelen van de AI Act in te vullen, zal ze ook exclusief bevoegd worden voor het toezicht op General Purpose AI (Art.75).

Het AI Office wordt in de praktijk onderdeel van DG CONNECT, zal van start gaan met 140 medewerkers en geleid worden door Lucilla Sioli. Het zal voor haar werking ondersteund worden door het Centrum voor Algoritmische Transparantie (ECAT), een AI Board (Art.65), een adviserend forum van belanghebbenden (Art.67), en een panel van onafhankelijke wetenschappers (Art.68).

Ook nationaal moeten er regulatoren worden aangeduid (Art.70). Deze zullen nauw moeten samenwerken met het EU AI Office en met de reeds bestaande industriële en sectorale regulatoren, die bijvoorbeeld vandaag al voor CE-markeringen bevoegd zijn. In Nederland speelt de Autoriteit Persoonsgegevens een duidelijke voortrekkersrol in de uitwerking van een Nederlandse AI-autoriteit, die daar waarschijnlijk in de schoot van de Autoriteit Persoonsgegevens zal worden opgericht. In België blijft het ondertussen stil, hoewel de tijd dringt – je kan immers ook niet eender wie aanwerven om die vrij gespecialiseerde rollen in te vullen.

Conclusie

Het is belangrijk om te onthouden dat de AI Act geen beperkingen oplegt aan AI-systemen die weinig risico inhouden – met uitzondering van General Purpose AI waarvan de nodige transparantie wordt gevraagd. Alleen voor systemen die hoge of systemische risico’s met zich meebrengen en in productie worden gezet, komen er strikte vereisten en de noodzaak tot conformiteit met relevante reguleringen. Ook dan zijn er heel wat verzachtende maatregelen die de interne ontwikkeling, open source initiatieven, wetenschap, defensie enz. extra ademruimte geven.

Tot op zekere hoogte probeert de AI Act concreet te zijn, door in detail op te sommen wat er verwacht wordt en een resem verduidelijkingen in de Overwegingen en Annexen op te nemen. Ze slaagt daar deels in en wordt zo nogal technisch – een betrokken rechter zal moeten leren wat FLOPs zijn. Tegelijk zijn er nog heel wat gaten in te vullen, waarbij het afwachten wordt waar het nieuwe AI Office onder toekomstige Commissies de lat zal leggen. Op verschillende plekken werd de mogelijkheid voorzien om de AI Act later te amenderen. De huidige versie van de AI Act zal dus zeker niet de laatste zijn.

Tenslotte mogen we in België zeker niet te lang meer wachten met het aanduiden en organiseren van de nationale toezichthouder(s) voor de AI Act, als we enigszins mee willen zijn met de rest van Europa. Voor praktische tools die o.a. kunnen helpen om conform te zijn, kan je vandaag al zoeken in de database van het Kenniscentrum Data & Maatschappij. Daar zal zeker nog veel meer materiaal verschijnen eens de AI Act effectief in werking treedt.

______________________

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.

1. In de ontwerptekst was het Engelse “free” oorspronkelijk foutief vertaald als “gratis”. In de publicatie in het Official Journal is deze vertaalfout alsnog gecorrigeerd en staat er “vrij”. ︎

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

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

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

Extensions pour IDE

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

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

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

Un LLM sur votre ordinateur portable 

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

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

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

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

Interlude : à propos du matériel

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

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

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

Un LLM sur votre serveur 

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

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

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

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

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

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

Exemple

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

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

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

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

#!/bin/bash

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

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

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

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

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

#!/bin/bash

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

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

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

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

#!/bin/bash

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

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

# Change to the directory
cd "$1"

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

# Initialize previous_size to 0
previous_size=0

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

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

    # Update previous_size
    previous_size=$size
done

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

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

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

Conclusion

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

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

______________________

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

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

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

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

IDE plugins

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

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

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

Een LLM op je laptop

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

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

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

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

Intermezzo: over hardware

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

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

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

Een LLM op je server

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

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

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

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

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

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

Voorbeeld

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

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

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

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

#!/bin/bash

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

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

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

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

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

#!/bin/bash

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

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

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

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

#!/bin/bash

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

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

# Change to the directory
cd "$1"

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

# Initialize previous_size to 0
previous_size=0

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

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

    # Update previous_size
    previous_size=$size
done

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

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

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

Conclusie

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

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

______________________

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