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)

AI Sheets est un outil no-code développé par Hugging Face pour l’enrichissement et la transformation de données avec l’IA.  Grace à des prompts et à une interface intuitive, il permet d’évaluer et d’affiner les sets de données, en s’intégrant à l’écosystème open-source.

NL

AI Sheets is een no-code tool ontwikkeld door Hugging Face voor het verrijken en transformeren van data met behulp van AI. Dankzij prompts en een intuïtieve interface, kan het worden gebruikt om datasets te evalueren en te verfijnen, en integreert het in het open-source ecosysteem.

Systemen die gebaseerd zijn op retrieval augmented generation (RAG) zijn een van de populairste toepassingen van grote taalmodellen (LLM’s). Deze systemen verbeteren LLM’s door hun antwoorden te verankeren in gecontroleerde databronnen. Ze vertonen echter enkele beperkingen, met name wat betreft het onder controle houden van hallucinaties. Onlangs is er een nieuw paradigma ontstaan dat deze beperkingen omzeilt: GraphRAG. GraphRAG is een variant van RAG die de kracht van LLM’s en knowledge graphs combineert, wat leidt tot nauwkeurigere en betrouwbaardere antwoorden.

Dit artikel gaat dieper in op het concept van GraphRAG en behandelt de architectuur, de voordelen en de implementatie ervan.

Basisbegrippen

Om GraphRAG te begrijpen, moeten eerst enkele basisbegrippen worden geïntroduceerd.

Graphs en knowledge graphs

Een graph is een gestructureerde manier om gegevens te organiseren in nodes en hun relaties. Een knowledge graph (KG) geeft betekenis aan data door middel van een ontologie en maakt redeneren over de graph mogelijk. Bovendien maken knowledge graphs het mogelijk om verschillende databronnen te combineren. Een gedetailleerde beschrijving van het concept van knowledge graphs vind je hier: Graphtechnologieën, de toepassingen ervan en tools: een overzicht (deel 2) | Smals Research.

Retrieval-augmented generation (RAG)

LLM’s worden verbeterd door informatie uit een externe knowledge base (bijvoorbeeld pdf’s, webpagina’s) te gebruiken om een antwoord op een vraag van een gebruiker te genereren. Doorgaans haalt RAG informatie uit ongestructureerde documenten die in kleine stukjes tekst (chunks) worden opgedeeld en in een vector database worden geïndexeerd in de vorm van embeddings. De stukjes die relevant zijn voor de query worden uit de vector database opgehaald door middel van semantische similariteitsberekening (zie Een eigen vraag- en antwoordsysteem op basis van taalmodellen.

Hoewel traditionele RAG-systemen de kwaliteit van de antwoorden van LLM’s verbeteren, vertonen ze een aantal problemen:

• Ze slagen er niet in om complexe query’s te beantwoorden die meerstapsredenering vereisen en ze missen een “overzicht” van de informatie door het ontbreken van een gestructureerde context. Traditionele RAG-systemen werken namelijk door korte tekstfragmenten uit een database op te halen en deze aan een LLM te voeren om een vraag te beantwoorden. De fragmenten worden afzonderlijk verwerkt en de relaties tussen hen worden genegeerd. Deze techniek werkt goed voor gerichte query’s die lokale antwoorden vereisen, maar schiet tekort voor brede query’s die inzicht vereisen in patronen en relaties op hoog niveau die verspreid zijn over documenten – LLM’s hebben moeite om betekenis te geven aan gefragmenteerde gegevens.

• De context die bij de prompt wordt geleverd, bevat ruis. Retrieval op basis van semantische gelijkenis levert vaak buitensporige en redundante stukken tekst op, waardoor het voor LLM’s moeilijk is om relevante details in de context te vatten, wat leidt tot een verminderde nauwkeurigheid van het gegenereerde antwoord. Bovendien, als de retrieval-fase er niet in slaagt relevante chunks te extraheren, krijgt de LLM onvolledige informatie, wat kan leiden tot hallucinaties.

Wat is GraphRAG?

GraphRAG staat voor Graph-Aided Retrieval-Augmented Generation en is een RAG-configuratie die gebruikmaakt van de interne verbondenheid van knowledge graphs.

KG’s zijn om de volgende redenen een logische keuze om RAG te verbeteren:

• Graph-structuren, waarin kennis wordt weergegeven in de vorm van entiteiten en relaties, maken diepgaander redeneren mogelijk. Een graph vangt conceptuele verbanden beter op die het redeneren sturen.
• Ze bieden een gestructureerde kennisbron die LLM helpt om antwoorden te verankeren in verifieerbare feiten.

Door een graph te gebruiken om de relaties tussen stukjes informatie te modelleren, stelt GraphRAG het model in staat om de context beter te begrijpen. Het gaat hier niet om een enkel algoritme, maar om een reeks architecturale patronen die graphs gebruiken om de relevantie, consistentie en traceerbaarheid van antwoorden te verbeteren. Afhankelijk van het probleem dat moet worden opgelost, bestaan er verschillende manieren om GraphRAG te implementeren. Deze kunnen worden onderverdeeld in drie grote categorieën, op basis van de vorm die de graph aanneemt:

• Indexgebaseerde GraphRAG: graphs worden gebruikt als index om de ruwe teksten van een corpus te ordenen. De tekstfragmenten worden georganiseerd in een graphstructuur waarin de relaties tussen deze chunks worden benut om de tekst efficiënt en semantisch bewust op te halen. Deze relaties worden gedefinieerd door de semantische gelijkenis tussen chunks en/of gedeelde entiteiten. De onderliggende graph is een lexicale graph. Deze architectuur wordt doorgaans gebruikt voor RAG op lange documenten, de graph maakt het dan mogelijk om de structuur van het document te behouden door de volgorde van de chunks (“is het vervolg van”-relatie) of de hiërarchie van het document (“is een subsectie van”-relatie) te volgen.

• Kennisgebaseerde graphRAG: de (knowledge) graphs zijn gebruikt als belangrijkste vectoren van kennis waar de nodes concepten zijn en de edges hun semantische relaties weergeven. De knowledge graph geeft doorgaans de kennis van het vakgebied weer.  Volgens deze configuratie kan een niet-gestructureerde tekst worden omgezet in expliciete, gestructureerde gegevens in de knowledge graph. Hierdoor kan direct op de graph worden geredeneerd.

• Hybride GraphRAG: deze aanpak combineert vectorgebaseerd ophalen en graphgebaseerd zoeken voor betere resultaten.

Voordelen van GraphRAG

Beter contextueel begrip

Knowledge graphs geven kennis beter weer: ze bieden een rijke context van relaties die het begrip van de LLM verbeteren. Retrieval uit een graph legt complexe afhankelijkheden tussen stukken informatie bloot die met traditionele RAG mogelijk niet worden opgemerkt.

Minder hallucinaties

De informatie die in een KG wordt opgeslagen is gestructureerd en bevat geen ruis. Bovendien integreren geavanceerde graphs ontologieën die formele definities geven voor de concepten. Dit alles draagt bij tot het verankeren van de LLM’s in feiten en het verminderen van hallucinaties.

Verklaarbaarheid

Het redeneringspad door de KG kan gemakkelijk worden getraceerd en gevisualiseerd door gebruikers. In combinatie met de uitleg van de LLM zorgt dit voor een transparanter RAG-systeem.

Implementatie van GraphRAG in de praktijk

Opbouw van de graph

a) Data ingestion

De meeste stappen in het data ingestion proces zijn vergelijkbaar met die in traditionele RAG: verzamelen, opschonen en opdelen van het corpus in kleinere eenheden, enz.

b) Entiteiten en relaties extraheren

LLM’s of regelgebaseerde systemen worden gebruikt om entiteiten en relaties in de tekst te identificeren.

c) Registratie van entiteiten, relaties en/of chunks in de graph

Vaak wordt de graph verrijkt met samenvattingen van gemeenschap van noden voor een globale context. Groeperingsalgoritmen zoals Louvain of Leiden worden vervolgens gebruikt om hiërarchische gemeenschappen binnen de graph te creëren en voor elke community vat een LLM vervolgens de informatie van de community samen.

d) Creatie van embeddings voor nodes, relaties en samenvattingen van gemeenschappen

Merk op dat de kosten om een knowledge graph op te bouwen op basis van ongestructureerde gegevens snel kunnen oplopen door de vele query’s die naar de LLM’s worden gestuurd.

Knowledge retrieval

De methodes om kennis op te halen zijn talrijk, deze sectie beschrijft enkel de meest voorkomende.

De eerste stap voor knowledge retrieval bestaat uit het vinden van de toegangspunten in de graph. Dit gebeurt door middel van een semantische zoekopdracht op de vectorrepresentatie van een chunk of een node, of door een declaratieve query te genereren in de taal van de graph (Cypher voor Neo4j) op basis van de in natuurlijke taal geformuleerde gebruikersquery. De informatie die door de zoekopdracht wordt teruggestuurd, wordt vervolgens naar de LLM gestuurd om het definitieve antwoord te genereren.

Er bestaan twee strategieën om een graph query van het type Cypher te genereren. De eerste is gebaseerd op vooraf gedefinieerde querymodellen, die tijdens de uitvoering worden aangevuld door de LLM, die automatisch de nodige parameters uit de oorspronkelijke query van de gebruiker haalt. Deze basisconfiguratie heeft het voordeel dat zij eenvoudig en correct geformatteerd is, maar mist flexibiliteit omdat het aantal query’s dat op de graph kan worden uitgevoerd beperkt is. De tweede bestaat uit het dynamisch laten construeren van de query op de graph door een LLM. De LLM genereert vervolgens de complete graph query gebaseerd op de aard van de vraag van de gebruiker en het opgegeven graphschema. Deze methode is flexibeler maar minder betrouwbaar. Het is daarom aan te raden om een paar voorbeelden toe te voegen aan de prompt en om syntaxiscontrolemechanismen te implementeren.

Een andere veelgebruikte methode voor het ophalen van informatie is een vectorzoekopdracht op de chunks, gevolgd door het doorlopen van de graph om aanvullende informatie over de relaties tussen de chunks en de entiteiten te verzamelen. Zoals hierboven vermeld, hangt de manier waarop informatie wordt opgehaald af van het doel dat men wil bereiken.

Andere technieken voor het ophalen van informatie:

• Hierarchical retrieval. De graph is georganiseerd in een hiërarchische structuur waarin de hoogste niveaus algemene informatie bevatten voor een breed contextueel begrip (bijv. samenvattingen van community’s), terwijl het laagste niveau meer specifieke informatie bevat. In het kader van onze experimenten hebben we een eenvoudige versie van deze methode toegepast op een chatbot (RAPTOR), wat de kwaliteit van de antwoorden heeft verbeterd.
• Multi-hop retrieval. Voor het redeneren wordt de informatie meerdere stappen verwijderd van de oorspronkelijke vraag opgehaald via een extra doorloop, eventueel gestuurd door een ontologie. De geëxtraheerde paden worden vervolgens gelineariseerd in tekstformaat om de LLM te voeden (zie Fig. 2).
• Multi-turn retrieval. Het antwoord wordt iteratief verfijnd via een feedbackloop tussen de graph en de LLM, waarbij de LLM aanvullende query’s formuleert als de informatie die uit de graph wordt opgehaald niet volledig is.

Strategieën voor verbetering van de retrieval

Knowledge retrieval gaat vaak gepaard met verwerkingsoperaties vóór of na de uitvoering van de query:

• Query decomposition: als de query complex is, wordt deze vóór de retrieval-fase verder verwerkt. De query wordt met behulp van een LLM opgesplitst in eenvoudige subquery’s, die vervolgens worden vertaald naar graph-taal. De resultaten van de subquery’s worden gegroepeerd om een antwoord te genereren.
• Query expansion: de oorspronkelijke query wordt verrijkt met extra context. De knowledge graph wordt vervolgens gebruikt om het toepassingsgebied van de query uit te breiden door nieuwe entiteiten of relaties toe te voegen aan de query.
• Pruning (het verwijderen van nutteloze informatie) en herschikken van queryresultaten.

Uitdagingen bij de implementatie

Hoewel GraphRAG veel verbeteringen biedt aan traditionele RAG, brengt het ook enkele uitdagingen met zich mee:

• De juiste balans vinden voor een kwalitatief goede graph: een te dichte graph gaat ten koste van de prestaties, maar een te dunne graph gaat ten koste van de nauwkeurigheid.
• Graph/tekst-alignment: gangbare LLM’s zijn niet ontworpen om native graph-structuren te verwerken.
• Schaalbaarheid: omvangrijke graphs vereisen efficiënte algoritmen voor het identificeren van relevante subgraphs.
• Ondubbelzinnigheid: entiteiten moeten correct worden geïdentificeerd om contextfouten te voorkomen.

Conclusie

GraphRAG is een concept om in de gaten te houden. Afhankelijk van de toepassing kan het de prestaties van taalmodellen aanzienlijk verbeteren in vergelijking met traditionele RAG-systemen. Dankzij de gestructureerde weergave van informatie in knowledge graphs, vergroot GraphRAG het redeneervermogen van LLM’s en kan het zijn antwoorden motiveren, waardoor een transparanter systeem kan worden opgebouwd en hallucinaties aanzienlijk worden verminderd. Deze verandering is met name van cruciaal belang voor sectoren zoals de gezondheidszorg of de publieke sector, waar nauwkeurigheid en interpreteerbaarheid vereist zijn.

Les systèmes basés sur la génération augmentée par récupération (RAG) sont l’une des applications les plus populaires des grands modèles de langage (LLM). Ces systèmes augmentent les LLM en ancrant leurs réponses dans des sources de données contrôlées. Ils ont néanmoins, fait preuve de certaines limites notamment dans le contrôle des hallucinations. Un nouveau paradigme a récemment émergé qui permet de dépasser ces limites: GraphRAG. GraphRAG est une variation du RAG qui combine la puissance des LLM et des graphes de connaissances, ce qui conduit à des réponses plus précises et plus fiables.

Cet article explore le concept de GraphRAG ; il couvrira son architecture, ses avantages et son implémentation.

Concepts de base

Pour comprendre le GraphRAG, il faut d’abord introduire quelques concepts de base.

Les graphes et graphes de connaissances

Un graphe est une manière structurée d’organiser des données en nœuds et leurs relations. Un graphe de connaissances (KG) ajoute du sens aux données grâce à une ontologie et permet le raisonnement sur le graphe. En outre, les graphes de connaissances permettent de combiner différentes sources de données. Une description détaillée du concept de graphe de connaissances peut être trouvée ici : Les technologies graphes, leurs applications et leurs outils: un tour d’horizon (Partie 2) | Smals Research.

Génération augmentée par récupération (RAG)

Le RAG améliore les LLM en exploitant des informations provenant d’une base de connaissances externe (par exemple, des PDF, des pages web) afin de générer une réponse à la question d’un utilisateur. Typiquement, le RAG récupère des informations à partir de documents non structurés qui sont divisés en petits morceaux de texte (chunks) et indexés dans une base de données vectorielle sous forme d’embeddings. Les morceaux pertinents pour la requête sont récupérés de la base vectorielle par calcul de similarité sémantique (voir Un propre système de questions/réponses basé sur des modèles de langue | Smals Research).

Bien qu’améliorant la qualité des réponses des LLM, les systèmes RAG traditionnels présentent certains problèmes:

• Ils ne parviennent pas à répondre aux requêtes complexes qui nécessitent un raisonnement en plusieurs étapes et ils manquent de « vue d’ensemble » sur l’information en raison de l’absence de contexte structuré. En effet, les systèmes RAG traditionnels fonctionnent en récupérant de courts extraits de texte dans une base de données et en les fournissant à un LLM pour répondre à une question. Les morceaux sont traités isolément et les relations entre eux sont ignorées. Cette technique fonctionne bien pour des requêtes ciblées nécessitant des réponses localisées, mais elle est insuffisante pour des requêtes larges qui nécessitent la compréhension de motifs et de relations de haut niveau dispersés dans les documents – les LLM ont du mal à donner du sens aux données fragmentées.
• Le contexte fourni au prompt contient du bruit. La récupération basée sur la similarité sémantique renvoit souvent des morceaux de texte excessifs et redondants, rendant difficile pour les LLM de capturer les détails pertinents dans le contexte ce qui entraîne une diminution de la précision de la réponse générée. De plus, si la phase de récupération échoue à extraire des chunks pertinents, le LLM recevra des informations incomplètes, ce qui peut entraîner des hallucinations.

Qu’est-ce que le GraphRAG ?

GraphRAG signifie génération augmentée par récupération basée sur les graphes, c’est une configuration RAG qui tire parti de la nature interconnectée des graphes de connaissances.

Les KG sont un choix naturel pour améliorer le RAG pour les raisons suivantes :

• Les structures de graphe, où la connaissance est représentée sous la forme d’entités et de relations, permettent un raisonnement plus approfondi ; un graphe capture mieux les connexions conceptuelles qui guideront le raisonnement.
• Ils fournissent une source de connaissances structurée aidant le LLM à ancrer les réponses dans des faits vérifiables.

En utilisant un graphe pour modéliser les relations entre les chunks d’information, le GraphRAG permet au modèle de mieux comprendre le contexte. Il ne s’agit pas d’un algorithme unique, mais d’un ensemble de motifs d’architecture exploitant les graphes pour améliorer la pertinence, la cohérence et la traçabilité des réponses. Il existe différentes façons d’implémenter le GraphRAG en fonction du problème à résoudre. On peut les classer en trois grandes catégories en fonction de la forme que prendra le graphe :

• GraphRAG basé sur l’indexation : les graphes sont utilisés comme index pour organiser les textes bruts d’un corpus. Les morceaux de texte sont organisés dans une structure graphe où l’exploitation des relations entre ces chunks facilite une récupération de texte efficace et sémantiquement consciente. Ces relations sont définies par la similarité sémantique entre les chunks et/ou les entités partagées. Le graphe sous-jacent est un graphe lexical. Cette architecture est typiquement utilisée pour le RAG sur des documents longs ; le graphe permet alors de préserver la structure du document en suivant l’ordre des chunks (relation « est le morceau suivant de ») ou la hiérarchie du document (relation « est une sous-section de »).
• GraphRAG basé sur les connaissances : les graphes (de connaissances) sont utilisés comme principaux vecteurs de connaissance où les nœuds sont des concepts et les arcs représentent leurs relations sémantiques. Typiquement, le graphe de connaissances représente la connaissance du domaine métier. Selon cette configuration, un texte non structuré peut être transformé en données explicites et structurées dans le graphe de connaissances. Cela permet un raisonnement direct sur le graphe.
• GraphRAG hybride : cette approche combine la récupération basée sur les vecteurs et l’exploration basée sur les graphes pour obtenir de meilleurs résultats.

Les avantages du GraphRAG

Meilleure compréhension contextuelle

Les graphes de connaissances ont une meilleure représentation des connaissances ; ils fournissent un contexte riche en relations qui améliore la compréhension du LLM. La récupération à partir d’un graphe révèle des dépendances complexes entre les éléments d’information qui pourraient ne pas être capturées avec le RAG traditionnel.

Réduction des hallucinations

Les informations stockées dans un KG sont structurées et ne contiennent pas de bruit. De plus, les graphes avancés intègrent des ontologies qui fournissent des définitions formelles pour les concepts. Tout cela contribue à ancrer les LLM dans les faits et à réduire les hallucinations.

Explicabilité

Le chemin de raisonnement à travers le KG peut être facilement tracé et visualisé par les utilisateurs. Associé aux explications données par le LLM, il fournit un système RAG plus transparent.

Implémentation GraphRAG en pratique

Construction du graphe

a) Ingestion des données

La plupart des étapes du processus d’ingestion des données sont similaires à celles du RAG traditionnel : collecte, nettoyage et division du corpus en plus petites unités, …

b) Extraction des entités et des relations

Des LLM ou des systèmes basés sur des règles sont utilisés afin d’identifier les entités et les relations à partir du texte.

c) Enregistrement des entités, relations et/ou chunks dans le graphe.

Très souvent, on enrichit le graphe avec des résumés de communautés de nœuds pour un contexte global. Des algorithmes de regroupement tels que Louvain ou Leiden sont alors utilisés pour créer des communautés hiérarchiques au sein du graphe et pour chaque communauté, un LLM résume ensuite les informations de la communauté.

d) Création d’embeddings pour les nœuds, les relations et les résumés communautaires.

Notons que le coût de construction d’un graphe de connaissances à partir de données non structurées peut rapidement grimper dû aux nombreuses requêtes envoyées aux LLM.

Récupération des connaissances

Les méthodes de récupération des connaissances sont nombreuses, seules les plus communes sont décrites dans cette section.

La première étape de l’opération de récupération consiste à trouver les points d’entrée dans le graphe. Soit une recherche par similarité sémantique est effectuée sur la représentation vectorielle d’un chunk ou d’un nœud, soit une requête déclarative est générée dans le langage du graphe (Cypher pour Neo4j) à partir de la requête utilisateur formulée en langage naturel. Les informations retournées par la recherche sont alors envoyées au LLM pour générer la réponse finale.

Il existe deux stratégies pour générer une requête graphe du type Cypher. La première repose sur des modèles de requêtes prédéfinis, complétés au moment de l’exécution par le LLM qui extrait automatiquement les paramètres nécessaires de la requête initiale de l’utilisateur. Cette configuration de base a l’avantage d’être simple et correctement formattée mais manque de flexibilité car le nombre de requêtes qui peuvent être effectuées sur le graphe est limité. La deuxième consiste à  faire construire dynamiquement la requête sur le graphe par un LLM. Le LLM génère alors la requête graphe complète en se basant sur la nature de la question de l’utilisateur et le schéma du graphe qui lui aura été fourni. Cette méthode est plus flexible mais moins fiable. Il est donc conseillé d’ajouter quelques exemples au prompt et d’implémenter des mécanismes de vérifications de syntaxe.

Une autre méthode de récupération très répandue consiste à faire une recherche vectorielle sur les chunks, suivie de traversées effectuées dans le graphe pour collecter des informations supplémentaires sur les relations entre les chunks et les entités. Comme mentionné ci-dessus, la manière de récupérer de l’information dépend de l’objectif que l’on veut atteindre.

On peut citer d’autres techniques de récupération telles que :

•  La récupération hiérarchique. Le graphe est organisé en une structure hiérarchique où les niveaux les plus élevés contiennent des informations globales pour une compréhension contextuelle large (ex : résumés de communautés) tandis que le niveau le plus bas contient des informations plus spécifiques. Dans le cadre de nos expériences, nous avons appliqué une version simple de cette méthode à un chatbot, (RAPTOR), ce qui a eu pour effet d’augmenter la qualité des réponses.
• La récupération multi-sauts (multi-hop retrieval). Pour le raisonnement, les informations sont récupérées à plusieurs sauts de la requête initiale par l’intermédiaire d’une traversée supplémentaire éventuellement dirigée par une ontologie. Les chemins extraits sont ensuite linéarisés au format texte pour alimenter le LLM (voir Fig. 2).
• La récupération multi-tours (multi-turn retrieval). La réponse est affinée de manière itérative par l’intermédiaire d’une boucle de rétroaction entre le graphe et le LLM où le LLM formule des requêtes supplémentaires si les informations récupérées dans le graphe ne sont pas complètes.

Stratégies d’amélioration de la récupération

La récupération des connaissances s’accompagne souvent d’opérations de traitement avant ou après l’exécution de la requête :

• Décomposition de la requête (query decomposition) : si la requête est complexe, un traitement supplémentaire lui est appliquée avant l’étape de récupération. La requête est décomposée à l’aide d’un LLM en sous-requêtes simples, chacune de ces sous-requêtes étant ensuite traduite en langage graphe. Les résultats retournés par les sous-requêtes sont regroupés pour générer une réponse.
• Extension de la requête (query expansion): la requête initiale est enrichie en ajoutant du contexte supplémentaire. Le graphe de connaissances est alors utilisé pour élargir le champ d’application de la requête en fournissant de nouvelles entités ou relations qui sont ajoutées à la requête.
• Élagage (pruning) et réordonnancement des résultats de la requête.

Défis d’implémentation

Bien que le GraphRAG apporte de nombreuses améliorations au RAG traditionnel, il présente certains défis :

• Trouver le bon équilibre pour un graphe de qualité: un graphe trop dense nuit à la performance, cependant un graphe trop pauvre nuit à la précision.
• L’alignement graphe/texte : Les LLM courants ne sont pas conçus pour traiter nativement des structures graphe.
• L’extensibilité : les graphes massifs nécessitent des algorithmes efficaces pour l’identification de sous-graphes pertinents.
• La désambiguïsation : les entités doivent être correctement résolues pour éviter les erreurs de contexte.

Conclusion

GraphRAG est un concept à suivre de près. Suivant l’application, il peut considérablement améliorer les performances des modèles de langage par rapport aux systèmes RAG traditionnels. Grâce à la représentation structurée de l’information dans les graphes de connaissance, le GraphRAG augmente les capacités de raisonnement des LLM et est capable de justifier ses réponses ce qui permet de construire un système plus transparent tout en réduisant de manière significative les hallucinations. Ce changement est particulièrement critique pour des secteurs comme la santé ou le secteur publique où la précision et l’interprétabilité sont nécessaires.

Références

https://neo4j.com/blog/genai/graphrag-manifesto

https://microsoft.github.io/graphrag/

Graph Retrieval-Augmented Generation: A Survey, Peng et al.

A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models, Zhang et al.

Dans le contexte des grands modèles de langage, la qualité des données joue un rôle crucial dans la performance des modèles et des applications basées sur ces modèles. Cette présentation explore les meilleures pratiques pour assurer la qualité des données tout au long du processus d’ingestion des données. Nous abordons les défis courants tels que la gestion des biais, la détection et la correction des erreurs, la gestion de la diversité des formats de données, etc. En outre, nous discutons des outils et des techniques qui peuvent être intégrés dans le pipeline d’ingestion pour garantir une qualité optimale. Enfin, nous examinons les implications de la qualité des données sur les résultats des modèles de langage et proposons des stratégies pour surmonter les obstacles rencontrés.

La présentation a été donnée dans le cadre d’une conférence organisée par le groupe de contact FNRS “Analyse critique et amélioration de la qualité de l’information numérique”.

NL

In de context van grote taalmodellen speelt de kwaliteit van de gegevens een cruciale rol in de prestaties van de modellen en de toepassingen die daarop gebaseerd zijn. Deze presentatie verkent de beste praktijken om de kwaliteit van de gegevens te waarborgen gedurende het hele proces van gegevensinvoer. We behandelen veelvoorkomende uitdagingen zoals het omgaan met vooroordelen, het opsporen en corrigeren van fouten, het beheren van de diversiteit aan gegevensformaten, enzovoort. Daarnaast bespreken we de tools en technieken die in de invoerpijplijn kunnen worden geïntegreerd om een optimale kwaliteit te garanderen. Tot slot bekijken we de implicaties van de gegevenskwaliteit op de resultaten van taalmodellen en stellen we strategieën voor om de tegengekomen obstakels te overwinnen.

De presentatie werd gegeven in het kader van een conferentie georganiseerd door de FNRS-contactgroep ‘Kritische analyse en verbetering van de kwaliteit van digitale informatie’.

Presentation

Een paar dagen geleden vond de conferentie “Artificial Intelligence Action Summit” plaats, waar de deelnemers hun prioriteiten op het gebied van AI (her)bevestigden. Deze prioriteiten omvatten een streven naar AI die openstaat voor iedereen, “inclusief, transparant, ethisch, veilig en betrouwbaar is, met inachtneming van internationale kaders”. Europa is pionier op dit gebied en introduceerde de eerste wetgeving op het gebied van artificiële intelligentie: de AI Act. De AI Act is een verordening die een aantal verplichtingen oplegt aan leveranciers en deployers van AI-systemen en -modellen, afhankelijk van het risiconiveau van deze systemen en modellen (zie onze blogpost “Een eerste kennismaking met de AI Act”).

De AI Act is op 1 augustus 2024 in werking getreden, maar de invoering ervan verloopt volgens een tijdschema dat loopt tot augustus 2027. De eerste belangrijke mijlpaal werd bereikt op 2 februari, toen het verbod op bepaalde AI-systemen en de vereisten voor AI literacy van kracht werden.

Om zich beter voor te bereiden op de implementatie van de AI Act heeft Smals zich aangesloten bij het programma van het AI-bureau van de Europese Commissie: AI Pact.

Dit AI Pact vraagt de deelnemers om drie kernacties door te voeren:

• Het vaststellen van een AI-governancestrategie;
• Het vaststellen en in kaart brengen van AI-systemen die waarschijnlijk behoren tot de categorie high risk;
• en het bevorderen van kennis over AI.

In deze blogpost delen we onze eerste ervaringen met AI literacy.

AI Literacy

AI Act, Art. 4:  AI-geletterdheid

“Aanbieders en gebruiksverantwoordelijken van AI-systemen nemen maatregelen om, zoveel als mogelijk, te zorgen voor een toereikend niveau van AI-geletterdheid bij hun personeel en andere personen die namens hen AI-systemen exploiteren en gebruiken, en houden daarbij rekening met hun technische kennis, ervaring, onderwijs en opleiding en de context waarin de AI-systemen zullen worden gebruikt, evenals met de personen of groepen personen ten aanzien van wie de AI-systemen zullen worden gebruikt.“

Dit artikel wordt aangevuld door het recital 20.

Definitie van AI-geletterdheid (AI Act, art. 3).

“AI-geletterdheid”: vaardigheden, kennis en begrip die aanbieders, gebruiksverantwoordelijken en betrokken personen, rekening houdend met hun respectieve rechten en plichten in het kader van deze verordening, in staat stellen geïnformeerd AI-systemen in te zetten en zich bewuster te worden van de kansen en risico’s van AI en de mogelijke schade die zij kan veroorzaken;

AI-geletterdheid geldt voor elk AI-product, ongeacht het risiconiveau.

Waarom is het belangrijk?

AI-geletterdheid is belangrijk om concurrerend te blijven. AI is een transformerende technologie, vaak vergeleken met elektriciteit of het internet, die de aard van veel beroepen verandert. In onze IT-business in het bijzonder zal het in de toekomst moeilijk worden om toepassingen te ontwerpen zonder AI te integreren. Om de nieuwe mogelijkheden van AI te benutten, moet een bedrijf zijn werknemers voldoende vaardigheden bijbrengen.

Hieronder staan de meest voorkomende valkuilen die te wijten zijn aan een gebrek aan AI-vaardigheden bij organisaties die AI-toepassingen ontwikkelen:

• De verkeerde technologiekeuzes maken. Veel leveranciers bieden “wonderoplossingen”, maar het gebruik van de krachtigste technologie zal niet leiden tot de gewenste resultaten als het niet het juiste antwoord is op een probleem.
• Artificiële intelligentie lijkt eenvoudig onder de knie te krijgen, maar dat is het niet. Het lukraak implementeren van algoritmes die op internet te vinden zijn (alles uitproberen en kijken wat werkt) kan bij mensen in de praktijk de valse indruk wekken dat ze de technologie onder de knie hebben. Dit stimuleert weliswaar ideevorming en creativiteit, en intelligente toepassingen kunnen hiervan het product zijn, maar het levert weinig succes op en leidt niet tot robuuste systemen. De oplossing voor dit probleem is om gebruikers te voorzien van een solide basis en van de tijd en middelen om voortdurend bij te leren.

• AI-technologieën gebruiken om het vakje ‘innovatie’ aan te vinken. Besluitvormers kunnen, onder druk om innovatieve projecten op te leveren, ambitieuze AI-initiatieven lanceren om snel hun doelen te bereiken. Het is echter niet eenvoudig om de problemen te identificeren waarbij AI een echte toegevoegde waarde heeft. In een beperkte omgeving kan een snel prototype wonderen doen, maar zodra het geïndustrialiseerd is, verdwijnt de gepercipieerde waarde snel. Organisaties zitten dan met een aanzienlijke hoeveelheid verborgen (menselijk) werk om het systeem te laten werken en tegen de tijd dat dat lukt, is de oplossing al achterhaald. Innovatie wordt verondersteld zowel nieuwigheid als echte waarde te brengen. De oplossing is om managers en besluitvormers te informeren over de werkelijke mogelijkheden en beperkingen van AI, zodat ze beter voorbereid zijn om de marketinghype te weerstaan.

• Een revolutionaire technologie gebruiken in combinatie met oude werkwijzen. AI verschilt in veel opzichten van traditionele softwareontwikkeling en dezelfde methoden toepassen zal waarschijnlijk mislukken. Hier zijn een paar voorbeelden van de unieke kenmerken van AI:
  • AI is probabilistisch: de regels worden niet expliciet geschreven door een mens, maar geleerd uit data. Een AI-systeem kan zich aanpassen aan scenario’s die het tijdens de training niet is tegengekomen, maar het gedrag ervan is niet volledig gedetermineerd en blijft beïnvloed door de gegevens die tijdens de training zijn gebruikt;
  • De ontwikkeling van op AI-gebaseerde toepassingen vereist meerdere iteraties in elke fase van het ontwikkelingsproces en vereist vaak een herdefiniëring van de vereisten. Helaas stoppen veel projecten bij de eerste ‘mislukking’, bij de eerste iteratie;
  • Het gebruiksgemak en de interactie in natuurlijke taal met AI-systemen vergroot het overgrote vertrouwen in deze systemen nog verder en hun onvoorspelbare aard wordt snel over het hoofd gezien;
  • Omdat de interne werking van AI-modellen niet volledig bekend is, moeten AI-systemen voortdurend worden gecontroleerd en aangepast.

Als er geen rekening wordt gehouden met deze verschillen, is het risico groot dat een schadelijk systeem wordt geïmplementeerd. In het beste geval zal het inefficiënt zijn, in het slechtste geval kan het schade opleveren voor sommige gebruikers (bijv. besluitvormingssystemen). Veel organisaties begrijpen niet goed hoe AI-governance werkt, ondanks de belangrijke rol die het speelt bij het voorkomen van dergelijke schade. Met een goede kennis en inzicht in de specifieke kenmerken van AI zullen organisaties echter evolueren van een situatie waarin slechte AI-governance enkel geïmplementeerd wordt omdat dit wettelijk verplicht is, naar een situatie waarin AI-governance wordt aangenomen in het belang van de organisatie en de mensen die met AI-systemen te maken hebben.

Het is belangrijk op te merken dat de problemen die gepaard gaan met het niet beheersen van AI zoals hierboven beschreven, leiden tot aanzienlijke financiële kosten.

Implementatie van AI literacy bij Smals

Smals startte in 2024 met een AI-geletterdheidsprogramma dat in 2025 verder ontwikkeld zal worden. Het doel van dit programma is drieledig. Ten eerste wordt algemene informatie over AI verstrekt aan alle deelnemers, om te verzekeren dat iedereen een basisbegrip heeft van wat AI is, de toepassingen ervan en de impact op onze sector. Ten tweede zouden de werknemers van Smals uitgerust worden met de vaardigheden om AI-tools doeltreffend te gebruiken in hun dagelijkse taken, om zo de interne processen te verbeteren en de algehele productiviteit binnen Smals te verhogen. Ten slotte wil het een groep mensen voorbereiden op meer gespecialiseerde rollen, door hen de nodige expertise te bieden om de ontwikkeling van AI-gebaseerde toepassingen van concept tot voltooiing voor hun rekening te nemen.

Dit programma is ontworpen met de technische vaardigheden en ervaring van de betrokkenen in gedachten. Het is onderverdeeld in drie categorieën:

• algemene opleiding, gericht op de hele onderneming;
• rolgebaseerde opleidingen, specifiek ontworpen voor bepaalde functies;
• projectgebaseerde opleidingen, die worden gegeven tijdens de levenscyclus van een AI-project.

Algemene inleiding tot AI

Deze opleiding is ontworpen om een uitgebreid overzicht te geven van artificiële intelligentie voor alle werknemers, met speciale aandacht voor generatieve AI. De opleiding heeft als doel het bewustzijn van de mogelijkheden, risico’s en beperkingen van AI te vergroten, zodat deelnemers een evenwichtig begrip hebben van wat AI wel en niet kan bereiken. Daarnaast behandelt de opleiding de richtlijnen voor het gebruik van AI binnen Smals, met aandacht voor compliance en ethische overwegingen. De opleiding wordt gegeven in de vorm van informatiesessies en videocapsules.

Rolgebaseerde opleidingen

De belangrijkste rollen in ons ‘AI literacy’-programma zijn:

• AI-ambassadeurs. Dankzij hun grondige kennis van de sterktes en beperkingen van AI kunnen AI-ambassadeurs potentiële use cases identificeren en prioriteren waarin AI een toegevoegde waarde kan hebben. Hun rol bestaat erin opportuniteiten te identificeren, AI te implementeren en nauw samen te werken met ons competentiecentrum om de toepassing van deze technologieën te promoten en te vergemakkelijken.
• De experts. AI-experts spelen een cruciale rol in het ontwerp, de ontwikkeling, implementatie en ondersteuning van AI-systemen binnen Smals. Ze beschikken over een diepgaande en uitgebreide kennis van verschillende AI-benaderingen, -technieken, -modellen, -tools en -frameworks, waardoor ze effectieve oplossingen kunnen creëren die zijn afgestemd op onze behoeften. Deze experts zijn proactief bezig met continue bijscholing, zodat ze voorop blijven lopen op de technologische vooruitgang op het gebied van AI. Ze vormen ook de cruciale brug tussen Smals en externe leveranciers van AI-oplossingen. Hun expertise stelt hen in staat om de AI-oplossingen van deze leveranciers te evalueren en te begeleiden, zodat we de meest geschikte en kwaliteitsvolle technologieën kunnen selecteren en implementeren.
• Data engineers richten zich op de cruciale aspecten van datamanagement. Ze moeten in staat zijn om de specifieke vereisten van AI op het gebied van gegevensverwerving, -integratie en -voorbereiding te begrijpen. Dit omvat het ontwerpen en implementeren van robuuste pipelines om gegevens te verzamelen, op te kuisen en te transformeren in formaten die geschikt zijn voor AI-modellen. Daarnaast moeten ze een gedegen kennis hebben van ‘data governance’-principes.
• Functies zoals schrijver van webcontent, developer, projectmanager, etc. Deze groepen hebben opleidingen nodig die zijn afgestemd op hun specifieke functies. Ze moeten in staat zijn om AI-ondersteunde software van gespecialiseerde leveranciers te gebruiken om hun werk te optimaliseren.
• Functionarissen voor gegevensbescherming en het juridische team. Deze mensen moeten een grondig begrip hebben van de ethische kwesties rond AI, AI governance, AI-risico’s en naleving van de regelgeving.

Projectgebaseerde training

Voor elk AI-project organiseren we korte, op maat gemaakte opleidingssessies voor alle belanghebbenden die betrokken zijn bij het bouwen van de AI-oplossing. Voor het technische team zijn deze opleidingssessies bedoeld om ervoor te zorgen dat ze een actueel begrip hebben van de technieken die worden gebruikt om de oplossing te implementeren. Businessexperts spelen ook een cruciale rol in het begeleiden van ontwerpbeslissingen en het valideren van het AI-systeem. Zij krijgen bijgevolg voorrang tijdens opleidingssessies om ervoor te zorgen dat hun expertise ten volle wordt benut om de AI-oplossing vorm te geven. Businessexperts moeten een goed begrip hebben van de praktische implicaties van AI-technologieën – de mogelijkheden en beperkingen ervan – risicobeheer en ten slotte governance-eisen.

Conclusie

Voor een organisatie is AI-geletterdheid een pijler van een succesvolle AI-strategie. Het is essentieel om iedereen die op verschillende niveaus voor de organisatie werkt erbij te betrekken. Een groot deel van de mislukkingen in AI-initiatieven is te wijten aan een gebrek aan AI-kennis of een verkeerde indruk van AI-geletterdheid. Het ontwerp van een ‘AI literacy’-programma hangt af van het gebruik dat van AI wordt gemaakt en het maturiteitsniveau van de organisatie. Het EU AI Office zal op zijn website een reeks voorbeeldprogramma’s beschikbaar stellen voor het grote publiek, samen met een aantal leidraden over dit onderwerp. Het bovenstaande programma is aangepast voor Smals.

Hoewel onze praktijken op het gebied van AI literacy nog in de kinderschoenen staan, hebben we het volgende waargenomen:

• Een verhoogde betrokkenheid van werknemers bij innovatie: onze eerste AI-opleidingssessies stimuleerden interne innovatie, wat leidde tot talrijke voorstellen om businessprocessen te verbeteren;
• Een beter begrip van de mogelijkheden van AI om de efficiëntie van interne processen te verbeteren: er is bijvoorbeeld een groeiende vraag naar tools om informatie te verzamelen en te analyseren (insight);
• Een groter bewustzijn van de risico’s die gepaard gaan met AI: onze teams gaan voorzichtiger om met het gebruik van generatieve AI-toepassingen zoals conversational agents;
• Stimuleren van continue bijscholing: de demystificatie van AI heeft geleid tot nieuwsgierigheid en self learning.

Il y a quelques jours se déroulait la conférence « Sommet pour l’action sur l’intelligence artificielle » dont les participants ont (ré)affirmé leurs priorités en matière d’IA. Parmi ces priorités, on retrouve leur engagement pour une IA ouverte à tous, « inclusive, transparente, éthique, sûre, sécurisée et digne de confiance, dans le respect des cadres internationaux ». L’Europe s’est montrée pionnière en la matière en introduisant la première législation sur l’intelligence artificielle : l’AI Act. L’AI Act est un règlement qui impose un certain nombre d’obligations aux fournisseurs et déployeurs de systèmes et modèles d’IA en fonction du niveau de risques de ces systèmes et modèles (voir notre article de blog « Premier tour d’horizon de l’AI Act ».).

L’AI Act est entré en vigueur le 1^er août 2024 mais sa mise en œuvre se fait graduellement suivant un calendrier qui s’étale jusqu’août 2027. Le premier jalon important a été atteint le 2 février, date à laquelle sont entrés en application les interdictions de certains systèmes d’IA et les obligations en matière de connaissance de l’IA (eng. « AI literacy »).

Afin de mieux nous préparer à la mise en œuvre de l’AI Act, Smals s’est inscrite au programme lancé par le Bureau de l’IA de la Commission Européenne : AI Pact.

Ce pacte pour l’IA invite les participants à s’engager sur trois actions principales :

• L’adoption d’une stratégie de gouvernance de l’IA ;
• L’identification et la cartographie des systèmes d’IA susceptibles d’appartenir à la catégorie haut-risque ;
• Et la promotion de la connaissance de l’IA.

Dans cet article de blog, nous introduisons l’AI literacy de manière générale et nous partageons nos premières expériences en matière d’AI literacy.

AI Literacy

AI Act, Art. 4 :  Maîtrise de l’IA

« Les fournisseurs et les déployeurs de systèmes d’IA prennent des mesures pour garantir, dans toute la mesure du possible, un niveau suffisant de maîtrise de l’IA pour leur personnel et les autres personnes s’occupant du fonctionnement et de l’utilisation des systèmes d’IA pour leur compte, en prenant en considération leurs connaissances techniques, leur expérience, leur éducation et leur formation, ainsi que le contexte dans lequel les systèmes d’IA sont destinés à être utilisés, et en tenant compte des personnes ou des groupes de personnes à l’égard desquels les systèmes d’IA sont destinés à être utilisés. » Cet article est complété par le récital 20.

Définition de la Maîtrise de l’IA (AI Act, Art. 3)

« (56) “maîtrise de l’IA”, les compétences, les connaissances et la compréhension qui permettent aux fournisseurs, aux déployeurs et aux personnes concernées, compte tenu de leurs droits et obligations respectifs dans le cadre du présent règlement, de déployer des systèmes d’IA en connaissance de cause, ainsi que de prendre conscience des possibilités et des risques de l’IA et des dommages éventuels qu’elle peut causer » 

L’AI literacy s’applique à tout produit IA quel que soit le niveau de risque.

Pourquoi est-ce important ?

La maîtrise de l’IA est importante pour rester compétitif. L’IA est une technologie présentée comme transformative souvent comparée à l’électricité ou à l’internet qui change la nature de beaucoup de métiers. Dans le cas particulier de notre entreprise IT, il sera difficile dans le futur de concevoir des applications sans y intégrer de l’IA. Pour saisir les nouvelles opportunités apportées par l’IA, notre entreprise doit fournir à ses collaborateurs un niveau suffisant de compétences.

Voici les pièges les plus courants dus à un manque de maîtrise de l’IA que l’on retrouve dans les organisations qui développent des applications d’IA :

• Faire les mauvais choix technologiques. Beaucoup de fournisseurs proposent des solutions « miracles » mais utiliser la technologie la plus performante ne produira pas les résultats espérés si elle n’est pas la réponse adéquate à un problème.
• L’IA semble facile à maîtriser, mais ce n’est pas le cas. Pour les praticiens, l’implémentation sans discernement d’algorithmes trouvés sur Internet (essayer tout et voir ce qui fonctionne) peut donner une fausse impression de maîtrise de la technologie. Cela stimule certainement l’idéation et la créativité, et des applications intelligentes peuvent en découler, mais cette méthode produit très peu de réussites et ne conduit pas à des systèmes robustes. La solution à ce problème est de fournir des bases solides aux praticiens et de leur donner le temps et les ressources nécessaires pour un apprentissage continu.
• L’adoption des technologies d’IA pour cocher la case « innovation ». Sous la pression de livrer des projets innovants, les décideurs peuvent lancer des initiatives ambitieuses en IA pour atteindre rapidement leurs objectifs. Cependant, identifier les problèmes où l’IA apporte une véritable valeur ajoutée n’est pas une tâche facile. Un prototype rapide peut faire des merveilles dans un cadre restreint, mais une fois industrialisé, la valeur perçue disparaît rapidement. Les organisations se retrouvent alors avec un travail (humain) caché non négligeable pour faire fonctionner le système et, au moment où il fonctionne, la solution est déjà dépassée. L’innovation est censée apporter à la fois de la nouveauté et une réelle valeur. La solution ici est de former les managers et décideurs aux véritables possibilités et limites de l’IA, afin de mieux les préparer à résister à l’appel du battage marketing.
• L’utilisation d’une technologie révolutionnaire avec de vieilles façons d’opérer. L’IA diffère du développement logiciel traditionnel à bien des égards et l’application des mêmes méthodes a beaucoup de chance d’échouer. Voici quelques exemples de spécificités propres à l’IA :
  • L’IA est probabiliste : les règles ne sont pas explicitement écrites par un humain mais apprises à partir de données. Un système d’IA est capable de s’adapter à des scénarios non rencontrés lors de son entrainement, mais son comportement n’est pas entièrement contraint et reste influencé par les données utilisées lors de l’entraînement ;
  • La facilité d’utilisation et l’interaction en langage naturel avec les systèmes d’IA augmentent la confiance excessive dans ces systèmes et leur nature aléatoire est rapidement négligée ;
  • Le développement d’applications basées sur de l’IA nécessite plusieurs itérations à chaque étape du processus de développement et nécessite souvent de redéfinir les besoins. Malheureusement de nombreux projets s’arrêtent au premier « échec », à la première itération ;
  • Parce que le fonctionnement interne des modèles d’IA n’est pas entièrement connu, les systèmes d’IA doivent être constamment surveillés et ajustés.

Si ces différences ne sont pas prises en compte, le risque de mettre en œuvre un système dommageable est élevé. Au mieux il sera inefficace, au pire il pourrait causer du tort à certains utilisateurs (p. ex. systèmes de prise de décision). La gouvernance de l’IA joue un rôle majeur dans la prévention de ces dommages mais celle-ci n’est pas pleinement comprise par de nombreuses organisations. Cependant, avec une bonne connaissance et compréhension des spécificités de l’IA, les organisations passeront d’une situation où (la mauvaise) gouvernance de l’IA est mise en œuvre uniquement parce que cela est exigé par la loi à une situation où la gouvernance de l’IA est adoptée dans l’intérêt de l’organisation et des personnes affectées par les systèmes d’IA.

Il est important de noter que les problèmes liés à la non-maîtrise de l’IA et décrits ci-dessus entrainent des coûts financiers importants.

Implémentation de l’AI literacy chez Smals

En 2024, Smals a démarré un programme de maîtrise de l’IA qui sera davantage développé en 2025. L’objectif de ce programme est triple. Tout d’abord, il vise à fournir des informations générales sur l’intelligence artificielle à tous les participants, garantissant ainsi que chacun dispose d’une compréhension de base de ce qu’est l’IA, de ses applications et de son impact sur notre secteur. Ensuite, le programme cherche à doter les collaborateurs de Smals des compétences nécessaires pour utiliser efficacement les outils d’IA dans leurs tâches quotidiennes, afin d’améliorer les processus internes et d’augmenter la productivité globale au sein de Smals. Enfin, il vise à préparer un groupe de personnes à assumer des rôles plus spécialisés, en leur fournissant l’expertise nécessaire pour prendre en charge le développement d’applications basées sur l’IA, de la conception à la réalisation.

Ce programme a été conçu en considérant les compétences techniques et l’expérience des personnes concernées. Il est divisé en trois catégories :

• des formations générales, destinées à l’ensemble de la société;
• des formations basées sur des rôles, conçues spécifiquement pour des fonctions données;
• des formations basées sur des projets, qui sont dispensées au cours du cycle de vie du projet IA.

Introduction générale à l’IA

Cette formation est conçue pour offrir une vue d’ensemble complète de l’intelligence artificielle à tous les collaborateurs avec un accent particulier sur l’IA générative. Elle a pour objectif de sensibiliser les participants aux capacités, risques et limites de l’IA, s’assurant ainsi que les participants possèdent une compréhension équilibrée de ce que l’IA peut et ne peut pas accomplir. De plus, la formation couvre les lignes directrices qui régissent l’utilisation de l’IA au sein de Smals, mettant en avant le respect des règles et les considérations éthiques. La formation est donnée sous forme de sessions d’information et de capsules vidéo.

Formations basées sur des rôles

Les principaux rôles identifiés dans notre programme d’AI literacy sont les suivants :

• Les ambassadeurs IA.  Grâce à une connaissance approfondie des forces et des limites de l’IA, les ambassadeurs IA sont capables d’identifier et de prioriser les cas d’utilisation potentiels où l’IA peut apporter une valeur ajoutée. Leur rôle implique la détection des opportunités, l’implémentation de l’IA et la collaboration étroite avec notre centre de compétence pour promouvoir et faciliter l’adoption de ces technologies.
• Les experts. Les experts en IA jouent un rôle crucial dans la conception, le développement, le déploiement et le soutien des systèmes d’IA au sein de Smals. Ils possèdent une connaissance approfondie et complète des différentes approches, techniques, modèles, outils et frameworks de l’IA, leur permettant de créer des solutions efficaces et adaptées à nos besoins. Ces experts sont proactivement engagés dans un apprentissage continu, garantissant ainsi qu’ils restent à la pointe des avancées technologiques dans le domaine de l’IA. Ils forment également les ponts cruciaux entre Smals et les fournisseurs externes de solutions d’IA. Leur expertise leur permet d’évaluer et de guider les solutions d’IA proposées par ces fournisseurs, garantissant ainsi que nous sélectionnons et mettons en œuvre les technologies de haute qualité les mieux adaptées.
• Les ingénieurs de données se concentrent sur les aspects cruciaux de la gestion des données. Ils doivent pouvoir comprendre les exigences spécifiques de l’IA en matière d’acquisition, d’intégration et de préparation des données. Cela inclut la conception et la mise en œuvre de pipelines robustes pour collecter, nettoyer et transformer les données dans des formats adaptés aux modèles d’IA. En outre, ils doivent posséder de solides connaissances des principes de gouvernance des données.
• Les fonctions telles que rédacteur de contenus web, développeur, gestionnaire de projets, … Ces groupes ont besoin d’une formation adaptée à leurs fonctions spécifiques. Ils doivent pouvoir utiliser des logiciels augmentés par l’IA fournis par les vendeurs spécialisés et qui leur permettent d’optimiser leur travail.
• Les Délégués à la protection des données et l’équipe juridique. Ces personnes doivent avoir une connaissance approfondie des questions éthiques concernant l’IA, de la gouvernance de l’IA, des risques de l’IA et de la conformité réglementaire.

Formations basées sur des projets

Pour chaque projet d’IA, nous organisons de courtes sessions de formation sur mesure pour toutes les parties prenantes impliquées dans la construction de la solution d’IA. Ces sessions de formation visent, pour l’équipe technique, à nous assurer d’avoir une compréhension actuelle des techniques utilisées pour l’implémentation de la solution. Les experts métier jouent aussi un rôle crucial dans l’orientation des décisions de conception et la validation du système d’IA. Par conséquent, ils seront prioritaires lors des sessions de formation afin de s’assurer que leur expertise est pleinement exploitée pour façonner la solution d’IA. Les experts métiers doivent pouvoir comprendre dans les grandes lignes les implications pratiques des technologies d’IA – leurs capacités et leurs limites – la gestion des risques et enfin les exigences en matière de gouvernance.

Conclusion

Pour une organisation, l’AI literacy est un pilier d’une stratégie d’IA réussie. Il est essentiel d’impliquer toute personne travaillant pour l’organisation à des degrés divers. Une grosse partie des échecs relatifs aux initiatives IA est due au manque de connaissance de l’IA ou à la fausse impression de maîtrise de l’IA. La conception d’un programme d’AI literacy dépend de l’usage qui est fait de l’IA et du niveau de maturité de l’entreprise. L’EU AI Office mettra à disposition du grand public une série d’exemples de programmes sur son site et quelques éléments d’orientation  sur le sujet. Le programme qui a été présenté ci-dessus est un programme adapté à Smals.

Bien que nos pratiques en matière d’AI literacy soient encore à leurs débuts, nous avons pu observer les éléments suivants :

• Une participation accrue des collaborateurs à l’innovation : nos premières sessions de formation en IA ont stimulé l’innovation interne, conduisant à de nombreuses propositions d’amélioration des processus métier ;
• Une compréhension améliorée des capacités de l’IA pour une plus grande efficacité des processus internes : il y a par exemple une demande croissante pour des outils de collecte et d’analyse d’informations (insight) ;
• Une conscience accrue des risques associés à l’IA : nos équipes adoptent une approche prudente concernant l’utilisation d’applications d’IA générative telles que les agents conversationnels ;
• La stimulation de l’apprentissage continu : la démystification de l’IA a instillé curiosité et auto-apprentissage.

Data ingestion is het proces waarbij data uit verschillende bronnen worden verzameld en geïmporteerd in een gecentraliseerd opslagsysteem (datawarehouse, data lake, vector store, etc.) met het oog op gebruik voor specifieke doeleinden. Data kunnen uit verschillende bronnen komen, zoals databases, PDF/Excel/xml-bestanden, logbestanden, API’s en evenementen of websites. Het ingestion-proces moet waarborgen dat de data correct en volledig zijn en in bijna realtime beschikbaar zijn om bedrijfsanalyses te ondersteunen.

Hoewel de traditionele ingestion-methodes bekend zijn, heeft het gebruik van data om grote taalmodellen (LLM’s) te voeden een aantal specifieke kenmerken. In dit artikel bespreken we de ingestion van voornamelijk ongestructureerde data om de knowledge bases op te bouwen waarop generatieve AI-toepassingen zoals chatbots zijn gebaseerd.

Beschrijving van een data ingestion pipeline

De hieronder weergegeven pipeline [Representatie van een ingestion pipeline in een systeem voor question answering] is van toepassing op een RAG-systeem (Retrieval-Augmented Generation) voor het genereren van antwoorden op vragen op basis van een knowledge base. De knowledge base wordt gevoed door verschillende databronnen die de pipeline doorlopen, van verzamelen tot indexeren in een vector database. De voornaamste stappen in deze pipeline zijn de volgende.

Data laden

De belangrijkste stap bij het bouwen van een ingestion pipeline voor een bepaald project is het identificeren van de databronnen die nodig zijn om dat project te voltooien. De input die gebruikt wordt in RAG-projecten bestaat voornamelijk uit ongestructureerde data uit verschillende bronnen, zoals websites, sociale netwerken, locale directories, databases, content management tools (bijv. SharePoint, Confluence), en opslagdiensten (bijv. S3). Voor elk van de gebruikte bronnen is het essentieel om over de juiste connectoren te beschikken en te controleren of je de benodigde toegangsrechten hebt.

Extractie

Zodra de bronnen zijn geïdentificeerd en de connectoren zijn geconfigureerd, kan de extractie van de inhoud beginnen. Het extractieproces hangt af van de databron en het dataformaat. Als de databron een webpagina is, moet een scrapingtool worden gebruikt om de HTML-inhoud te extraheren, waarna de inhoud moet worden geanalyseerd om de relevante informatie te extraheren. Als de databron een afbeelding is, moet je misschien een OCR-tool gebruiken, terwijl je voor databases de juiste SQL-query’s moet schrijven.

De inhoudsextractie kan gecombineerd worden met een inhoudsverrijkingsproces om metadata te genereren. Deze metadata worden uit de databron zelf gehaald (bijv. documentnaam, auteursnaam, URL, aanmaak- en wijzigingsdatum, tags) of uit de inhoud zelf (koptekst, titel, XML-tags). Een andere methode voor dataverrijking bestaat uit het gebruik van generatieve modellen om de beschrijvingen van afbeeldingen en tabellen in de data te genereren.

Ongeacht het formaat van de originele data, moet het resultaat van het extractieproces gestandaardiseerd zijn. Over het algemeen bestaat het uit tekst en bijbehorende metadata in JSON-formaat.

Opschonen en transformeren

Data geëxtraheerd uit bronnen is zelden bruikbaar zoals het is, en moet opgeschoond worden. Het opschonen is de meest tijdrovende fase en varieert afhankelijk van de use case. De meest voorkomende operaties die worden toegepast op inhoud zijn de volgende:

• Opschonen van leestekens en speciale karakters.
• Verwijderen van duplicaten.
• Verwijderen van onnodige informatie, zoals reclamebanners en cookies in inhoud van websites die ruis introduceren in de data.
• Controleren en corrigeren van tegenstrijdige, inconsistente of valse informatie, die het antwoord dat aan de andere kant van de RAG-procesketen wordt gegenereerd sterk beïnvloedt.
• Verwerken van ontbrekende informatie. Enkele voorbeelden van ontbrekende informatie in ongestructureerde data zijn links naar andere webpagina’s met aanvullende informatie op de geëxtraheerde inhoud, e-mails die verwijzen naar andere e-mails, enz.

Chunking

Chunking is het opsplitsen van tekst in kleinere eenheden. Hierdoor kan het model alleen die passages ophalen die informatie bevatten die relevant is voor het antwoord. Er bestaan verschillende chunkingmethoden, die kunnen worden gegroepeerd in twee categorieën: chunking op basis van vooraf gedefinieerde regels (vaste grootte, per alinea) en chunking op basis van semantiek (groepering van gelijksoortige segmenten). Efficiënt chunken bestaat uit het vinden van de juiste balans tussen wachttijd en kosten. Hoe kleiner de chunk, hoe meer opslag er nodig is en hoe hoger de latency; hoe groter de chunk, hoe groter de context van het model en dus hoe hoger de kosten. Welke methode ook gekozen wordt, het is belangrijk om rekening te houden met de structuur van de tekst en de maximale contextlengte van het taalmodel.

Genereren van vector database weergave (Embedding)

Dit is de fase waarin tekstdata wordt omgezet in vectoren waarop het semantisch zoeken specifiek voor RAG (retrieval) kan worden toegepast. Er bestaan verschillende embeddingstechnieken, maar de meest effectieve is de contextual embeddingstechniek gebaseerd op grote taalmodellen.

Indexering

Dit is de laatste fase in de ingestion pipeline. De data-output van de pipeline wordt geïndexeerd in een vector database zoals Weaviate, Pinecone, ElasticSearch, enz. Metadata wordt ook in de database geplaatst, zodat de resultaten kunnen worden verfijnd tijdens het zoeken (retrieval). De keuze van de Vector databases en het type indexering hangt af van het volume van de op te slaan data en de vereiste prestaties.

Andere aspecten om te overwegen

Batch of streaming ingestion

In batchmodus worden data massaal opgenomen met regelmatige tussenpozen of op aanvraag.

In streamingmodus worden nieuwe data direct in realtime of bijna realtime opgenomen. De streamingmodus wordt gekozen als de meest actuele informatie nodig is en als deze informatie snel verandert. Streaming ingestion vereist constante controle om de kleinste verandering in de datastructuur te detecteren.

Updates beheren

Om updates te beheren, is de traceerbaarheid van data belangrijk. Dit houdt in dat informatie zoals bron, versie, tijdstempel, laatste wijzigingsdatum, enz. wordt bijgehouden. Er zijn twee mogelijke strategieën voor het beheren van updates in bestemmingsdatabases: incrementeel updaten (alleen data die veranderd is wordt opgenomen) of volledig updaten. De veelheid aan databronnen en -formaten die worden gebruikt door LLM-gebaseerde toepassingen introduceert tal van problemen die ofwel te wijten zijn aan slecht beheer van de data bij de bron, of aan slechte tracering van wijzigingen door de dataverbruiker.

Beheer van de veiligheid

Zoals bij alle systemen die data verwerken, is er een minimum aan veiligheidsmaatregelen van toepassing op het ingestion proces:

• Toegang tot bronnen controleren.
• De juiste toegangsrechten toekennen wanneer inhoud wordt ingevoegd in de doeldatabase.
• Beveiligen van dataoverdracht tussen de bron en het ingestion systeem om knoeien met data (data tampering) te voorkomen.
• Enz.

Bij RAG-toepassingen worden persoonsgegevens regelmatig aangetroffen in niet-gestructureerde documenten. Deze gegevens vereisen bijzondere aandacht, omdat ze onderhevig zijn aan strikte regelgeving (GDPR). Gegevens moeten vaak worden geanonimiseerd voordat ze worden ingevoegd in de bestemmingsdatabase. Daarom is het noodzakelijk om een filterfase in te bouwen voor persoonlijk identificeerbare gegevens of PII filtering in de pipeline. Doeltreffende tools bestaan, maar ze garanderen geen 100% correcte filtering.

Een ander aandachtspunt specifiek voor RAG is de keuze van betrouwbare bronnen. In veel geavanceerde RAG-toepassingen wordt informatie uit websites gehaald. Een good practice is om de toepassing te beperken tot een lijst van vooraf gedefinieerde websites die kunnen worden opgevraagd.

Monitoring en foutenbeheer

Bij elke stap van de pipeline moeten fouten worden geregistreerd in logboeken en moeten waarschuwingssystemen worden ingesteld.

De algemene evaluatie van het ingestion systeem gebeurt indirect door de prestaties van het RAG-systeem te monitoren. Een slechte antwoord kan te wijten zijn aan een gebrek aan informatie in de database (de bronnen opnieuw evalueren), slechte chunking ( het gebruik van chunks en hun impact op de geleverde antwoord meten), enz….

Enkele bijzondere gevallen

RAG gecombineerd met web search

Typisch zijn de informatiebronnen die het vraag-antwoordsysteem voeden de knowledge base die wordt gevoed door de ingestion pipeline en de resultaten van web queries die on the fly worden uitgevoerd tijdens het verwerken van de vraag.

Het extractieproces wordt aangestuurd door het generatieve model (LLM) dat, afhankelijk van de query, de meest geschikte bron of een combinatie van de twee aanroept.

Multimodale RAG

Multimodale RAG maakt het mogelijk om data in verschillende vormen op te vragen: tekst, beeld, video en audio.

Er bestaan diverse strategieën om deze verschillende soorten data in te voeren:

• Gebruik van een referentiemodaliteit. Een modaliteit dient als referentie voor de datarepresentatie en de andere modaliteiten worden verankerd in deze referentiemodaliteit met behulp van specifieke modellen. In het hierboven weergegeven pipeline-voorbeeld is de referentiemodaliteit tekst en wordt voor elk beeld in de data een tekstuele samenvatting gegenereerd die dat beeld weergeeft.
• Gebruik van een multimodaal model. Een enkel multimodaal embeddingmodel wordt gebruikt om vectorrepresentaties van alle soorten data te genereren.

Tools

De keuze van een ingestion-platform hangt af van de complexiteit van het proces, het volume van de verwerkte data, de vereiste verwerkingssnelheid en de beschikbare bron- en bestemmingsconnectoren.

• Airbyte. Engine voor gestructureerde en ongestructureerde data-integratie die wordt gebruikt om datawarehouses of data lakes te voeden.
• Unstructured. Tool voor het bouwen van data pipelines voor LLM’s [Hier vindt u een link naar een quick review die wij over deze tool geschreven hebben].
• Langchain. Bijzonder veelzijdige tool voor het ontwikkelen van toepassingen op basis van generatieve AI, integreert met tal van databronnen en het Unstructured-platform, biedt tal van chunkingfuncties.
• LlamaIndex. Tool voor het ontwikkelen van toepassingen op basis van generatieve AI voor het doorzoeken van knowledge bases. LlamaIndex biedt ook een service voor het beheer van LLamaClouddata pipelines.
• Ray. Python library voor het beheren van gedistribueerde computerprocessen.
• Data ophalen van een webpagina: BeautifulSoup (Python library), Playwright, FireCrawl.
• Presidio: Filteren van persoonsidentificerende gegevens.

Conclusies

Data ingestion is een kritieke stap bij de ontwikkeling van een toepassing gebaseerd op generatieve AI omdat, zoals het gezegde luidt, “garbage in, garbage out”. Het bovenstaande artikel presenteert enkele technieken en best practices voor data ingestion; elke toepassing heeft echter zijn eigen specifieke kenmerken en moeilijkheden, die grotendeels afhangen van het toepassingsdomein van de oplossing. Daarom moet de ontwikkeling van een data ingestion-strategie het resultaat zijn van een nauwe samenwerking tussen een technisch expert en een domeinspecialist.

L’ingestion de données est le processus de collecte et d’importation de données provenant de différentes sources vers un système de stockage centralisé (data warehouse, data lake, vector store, etc.) en vue de les exploiter pour des usages spécifiques. Les données peuvent provenir de sources diverses telles que les bases de données, les fichiers PDF/excel/xml, les logs, les APIs et événements ou les sites web. Le processus d’ingestion doit s’assurer que les données sont correctes, complètes et disponibles en temps quasi-réel pour soutenir les analyses d’entreprise.

Si les méthodes d’ingestion de données traditionnelles sont bien connues, l’utilisation de données pour alimenter de grands modèles de langage (LLM) présente quelques spécificités. Dans cet article, nous allons discuter de l’ingestion de données, principalement non structurées, pour constituer les bases de connaissance sur lesquelles s’appuient des applications d’IA générative telles que les chatbots.

Description d’un pipeline d’ingestion de données

Le pipeline présenté ci-dessous s’applique à un système de type RAG (Retrieval-Augmented Generation) pour la génération de réponses aux questions basée sur une base de connaissance. La base de connaissance est alimentée par plusieurs sources de données qui traverse le pipeline, de la collecte à l’indexation dans une base de données vectorielle. Les principales étapes de ce pipeline sont les suivantes.

Chargement des données

L’étape la plus importante dans la construction d’un pipeline d’ingestion pour un projet donné consiste à identifier les sources de données nécessaires pour la réalisation de ce projet. Les inputs utilisées dans le cadre de projets RAG sont principalement des données non structurées provenant de multiples sources telles que les sites internet, les réseaux sociaux, les répertoires locaux, bases de données, les outils de gestion de contenus (par exemple SharePoint), Confluence et les services de stockage (par exemple S3). Pour chacune des sources utilisées, il est essentiel de disposer des connecteurs appropriés et de vérifier que l’on possède les droits d’accès nécessaires.

Extraction

Une fois les sources identifiées et les connecteurs configurés, l’extraction du contenu peut commencer. Le processus d’extraction dépend de la source de données et du format de données. Si la source de données est une page web, il convient d’utiliser un outil de scraping pour extraire le contenu HTML, puis d’analyser ce contenu pour en extraire les informations pertinentes. Si la source de données est une image, il sera nécessaire d’utiliser un outil OCR, tandis que pour les bases de données, il faudra écrire des requêtes SQL appropriées.

L’opération d’extraction du contenu peut être associé à un processus d’enrichissement du contenu par génération de métadonnées. Ces métadonnées sont extraites de la source de données elle-même (par exemple le nom du document, le nom de l’auteur, l’URL, les dates de création et de modification, les tags) ou du contenu lui-même (l’en-tête, le titre, les tags XML). Une autre méthode d’enrichissement de données consiste à utiliser des modèles génératifs pour générer les descriptions images et de tableaux se trouvant dans les données. 

Quelle que soit le format des données d’origine, le résultat du processus d’extraction doit être uniformisé. Il consiste généralement en un texte et les métadonnées associées sous format JSON.

Nettoyage et transformation

Les données extraites des sources sont rarement utilisables telles quelles et nécessitent d’être nettoyées. L’opération de nettoyage est l’étape la plus chronophage et varie selon le cas d’utilisation. Les opérations les plus communes appliquées au contenu sont les suivantes :

• Nettoyage de la ponctuation et de caractères spéciaux.
• Suppression des doublons.
• Suppression des informations inutiles comme par exemple les bannières publicitaires et cookies présentes dans les contenus provenant de sites internet qui introduisent du bruit dans les données.
• Contrôle et correction des informations contradictoires, incohérentes ou fausses, celles-ci affectent fortement la réponse générée à l’autre bout de la chaine du processus RAG.
• Traitement des informations manquantes. Quelques exemples d’informations manquantes dans les données non structurées sont par exemple des liens vers d’autres page web contenant des informations complémentaires au contenu extrait, des emails renvoyant vers d’autres emails, etc.

Chunking

Le chunking est l’opération de découpage d’un texte en plus petites unités. Cela permet au modèle de récupérer uniquement les passages contenant l’information pertinente pour la réponse. Ils existent plusieurs méthodes de chunking qui peuvent être regroupées en deux catégories : le chunking basé sur des règles prédéfinies (taille fixe, par paragraphe) et le chunking basé sur la sémantique (groupement de segments similaires). Un chunking efficace nécessite de trouver le bon équilibre entre temps d’attente et coût. Plus petit est le chunk, plus on a besoin de stockage et plus le temps de latence est élevé, plus le chunk est grand, plus le contexte du modèle est grand et donc le coût élevé. Quelle que soit la méthode choisie, il est important de prendre en compte la structure du texte et la longueur maximale de contexte du modèle de langage.

Génération des représentations vectorielles de données (Embedding)

C’est l’étape de conversion des données textuelles en vecteurs sur lesquels pourra s’appliquer la recherche sémantique propre au RAG (retrieval). Ils existent plusieurs techniques d’embedding mais la plus performante est la technique d’embedding contextuelle basée sur les grands modèles de langage.

L’indexation

C’est l’étape ultime du pipeline d’ingestion. Les données en sortie du pipeline sont indexées dans une base de données vectorielle telle que Weaviate, Pinecone, ElasticSearch, etc. Les métadonnées sont également insérées dans la base de données, elles permettent d’affiner les résultats lors de l’opération de recherche (retrieval). Le choix de la base de données vectorielle ainsi que du type d’indexation se fait en fonction du volume de données à stocker et des performances recherchées.

Autres aspects à prendre en compte

Ingestion en batch ou en streaming

En mode batch, les données sont ingérées en masse à intervalles réguliers ou sur demande.

En mode streaming, les nouvelles données sont directement ingérées en temps réel ou presque. On choisit le mode streaming quand il est nécessaire d’avoir l’information la plus récente et que celle-ci évolue rapidement. L’ingestion en streaming requiert un monitoring constant afin de détecter le moindre changement dans la structure des données.

Gestion des mises à jour

Pour gérer les mises à jour, la traçabilité des données est importante. Ceci implique de traquer des informations tels que source, version, timestamp, date de dernière modification, … La mise à jour est alors déclenchée par les informations traquées. Deux stratégies sont possibles pour gérer les mises à jour dans les bases de données de destination : la mise à jour incrémentale (seules les données qui ont changé sont ingérées) ou la mise à jour intégrale. La multiplicité des sources et des formats des données utilisées par les applications basées sur les LLM introduit de nombreux problèmes qui sont soit dus à une mauvaise gouvernance des données à la source, soit dus à un mauvais traçage des changements par le consommateur de données.

Gestion de la sécurité

Comme pour tout système qui traite des données, un minimum de mesures de sécurité s’applique au processus d’ingestion:

• Le contrôle des accès aux sources.
• L’attribution des droits d’accès appropriés au moment de l’insertion du contenu dans la base de données cible.
• La sécurisation du transfert des données entre la source et le système d’ingestion pour éviter la modification de données (data tampering).
• Etc.

Dans le cas des applications RAG, on retrouve régulièrement des données à caractère personnel dans les documents non-structurés. Celles-ci requièrent une attention particulière car soumise à une régulation stricte (RGPD). Bien souvent une anonymisation des données est nécessaire avant insertion dans la base de données de destination. Il faut donc prévoir une étape de filtrage de données personnelles identifiables ou PII filtering dans le pipeline. Des outils efficaces existent mais ceux-ci ne garantissent pas un filtrage à 100% correct.

Un autre point d’attention propre au RAG est le choix de sources fiables. Dans beaucoup d’applications RAG avancées, les informations sont extraites à la volée de sites web. Une bonne pratique consiste à restreindre l’application à une liste de sites web prédéfinis qui peuvent être interrogés.

Monitoring et gestion des erreurs

A chaque étape du pipeline les erreurs doivent être enregistrés dans des journaux et des systèmes d’alertes doivent être mis en place.

L’évaluation globale du système d’ingestion se fait de façon indirecte en monitorant les performances du système RAG. Une mauvaise réponse peut être due au manque d’informations dans la base de données (réévaluer les sources), à un mauvais chunking (mesurer l’utilisation des chunks, leur impact dans la réponse fournie), etc…

Quelques cas particuliers

Le RAG combiné à une recherche web

Typiquement, les sources d’information qui alimentent le système de question-réponse sont la base de connaissance alimentée par le pipeline d’ingestion et le résultat de requêtes web exécutées à la volée au moment de traiter la question.

Le processus d’extraction est piloté par le modèle génératif (LLM) qui, en fonction de la question, fait appel à la source la plus appropriée ou à une combinaison des deux.

Le RAG multimodal

Le RAG multimodal permet d’interroger les données sous différentes formes : texte, image, vidéo, audio. Plusieurs stratégies sont alors possibles pour ingérer ces différents types de données :

• Utilisation d’une modalité de référence. Une modalité sert de référence pour la représentation des données et les autres modalités sont ancrées dans cette modalité de référence grâce à des modèles spécifiques. Dans l’exemple de pipeline illustré ci-dessus, la modalité de référence est le texte et pour chaque image présente dans les données on génère un résumé textuel qui représente cette image.
• Utilisation d’un modèle multimodal. Un modèle d’embedding unique et multimodal est utilisé pour générer les représentations vectorielles des données quelque soit leur type.

Outils

Le choix d’une plateforme d’ingestion dépend de la complexité du processus, du volume de données traité, de la rapidité de traitement nécessaire et des connecteurs source et destination disponibles.

• Airbyte. Moteur d’intégration des données structurées et non structurées utilisé pour alimenter les data warehouse ou data lake.
• Unstructured. Outil de construction de pipelines de données pour les LLM [vous trouverez une quick review que nous avons écrit sur cet outil en suivant ce lien].
• Langchain. Outil très versatile de développement d’applications basées sur l’IA générative, s’intègre avec de nombreuses sources de données ainsi que la plateforme Unstructured, propose de nombreuses fonctions de chunking.
• LlamaIndex. Outil de développement d’applications basées sur l’IA générative pour la recherche dans les bases de connaissance. LlamaIndex dispose également d’un service de gestion des pipelines de données LLamaCloud.
• Ray. Bibliothèque Python pour la gestion des processus computationnels distribués.
• Récupération des données d’une page web : BeautifulSoup (bibliothèque Python), Playwright, FireCrawl.
• Presidio : Filtrage des données personnelles identifiables.

Conclusions

L’ingestion de données est une étape critique dans la construction d’une application basée sur l’IA générative car comme le dit l’adage, « garbage in, garbage out ». L’article ci-dessus présente quelques techniques et bonnes pratiques d’ingestion de données ; cependant, chaque cas d’application a ses spécificités et ses difficultés qui dépendent largement du domaine d’application de la solution. C’est pourquoi, l’élaboration d’une stratégie d’ingestion de données doit être le résultat d’une collaboration étroite entre un expert technique et un spécialiste du domaine.