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

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

Piliers stratégiques

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

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

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

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

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

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

Le rôle de l’open source

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

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

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

Chez nos voisins

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

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

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

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

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

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

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

Le rôle de l’Europe

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

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

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

Conclusion

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

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

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

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

______________________

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

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

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

Strategische pijlers

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

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

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

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

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

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

De rol van open-source

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

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

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

In de buurlanden

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

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

Die laatste investeert ook met succes in 2 eigen projecten:

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

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

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

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

De rol van Europa

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

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

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

Conclusie

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

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

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

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

______________________

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

Data quality management, regelmatig besproken in deze blog, bestaat vaak uit het verwerken (vergelijken, vergemakkelijken, transformeren, “fonetiseren”, enz.) van karakterketens: namen van mensen, ondernemingen, steden, straten, telefoonnummers, e-mailadressen, …

In deze blogpost nemen we een kijkje naar het soort problemen dat kan worden opgespoord wanneer data gekoppeld raken met geografische coördinaten (breedtegraden, lengtegraden), rekening houdend met open data van het project BeSt Address (Belgian Street Address), van de FOD BOSA, authentieke bron voor adressen in België. Dit project verzamelt en consolideert gegevens van de gewesten (UrbiS voor het Brussels Gewest, het Adressenregister voor Vlaanderen en ICAR voor Wallonië), die op hun beurt adresgegevens ophalen die verzameld zijn door elke gemeente, de instantie die verantwoordelijk is voor de toewijzing van adressen. Een reeks CSV- of XML-bestanden kan hier worden gedownload met de officiële spelling en geografische coördinaten van elk adres in België.

Onze ervaring heeft ons geleerd dat de BeSt Address data veruit de meest kwalitatieve zijn in vergelijking met andere officiële bronnen die adressen bevatten (Rijksregister, Werkgeversregister, Kruispuntbank van Ondernemingen, enz.), ten minste de klassieke aspecten van datakwaliteit (consistentie van namen, afwezigheid van afkortingen, enz.), het resultaat van de enorme inspanningen van de teams in de gewesten en de FOD BOSA. Toch konden we een aantal anomalieën vinden die alleen geïdentificeerd konden worden door naar de geografische gegevens en ruimtelijke analyses te kijken.

De meeste geïdentificeerde anomalieën komen overeen met verkeerd geplaatste adressen (verkeerde coördinaten) of problematische postcodes. Opschoning kan alleen worden uitgevoerd door de entiteiten op het terrein, d.w.z. de gemeenten.

Merk op dat de anomalieën die hieronder worden gepresenteerd het resultaat zijn van een “academische” analyse. Deze is al besproken met een aantal mensen van de relevante instanties (gewesten, rijksregister, FOD BOSA, NGI, etc.), en sommige van deze afwijkingen worden aanvaardbaar geacht. Deze blogpost wil geen kritiek uiten op de kwaliteit van de data, maar simpelweg een methodologie presenteren en deze illustreren met een relevante databron.

Context

Zoals in een vorige blogpost is beschreven, bestaat België op het moment van schrijven uit 581 gemeenten (dit aantal zal de komende maanden afnemen na een reeks fusies van gemeenten). Elk van deze gemeenten bestaat uit een of meer postcodes (verbonden met een naam in Brussel en Vlaanderen), en elk van deze postcodes kan een of meer deelgemeenten of lokaliteiten bevatten (part of municipality in Wallonië, in BeSt Address-jargon).

Voor de onderstaande analyse baseerden we ons op de CSV-bestanden die beschikbaar zijn op https://opendata.bosa.be/, en voerden we vier soorten analyses uit: 

• In de eerste analyse kijken we of alle busnummers op hetzelfde adres dicht bij elkaar liggen;
• In de tweede vergelijken we de grenzen van de postcodes gedefinieerd door bpost (de Belgische postdienst) met de postcodes van adressn uit BeSt Adress;
• In de derde analyse gaan we op zoek naar inconsistenties in straatnamen die geografisch dicht bij elkaar liggen (bv. een ‘rue Roi Albert I‘ naast een ’rue du Roi Albert I’);
• In de vierde zoeken we naar geometrische afwijkingen in de vorm van een straat.

Inconsistentie van bussen

Zoals eerder beschreven bevat een adres altijd een ‘huisnummer’, dat verwijst naar het gebouw, en soms een ‘ busnummer’, dat verwijst naar de wooneenheid binnen dat gebouw. In BeSt Address vinden we voor elk adres met een bus altijd een gelijkwaardig basisadres (zelfde straat, postcode, nummer) zonder bus. Laten we bijvoorbeeld zeggen dat de Fonsnylaan 20 twee bussen heeft, ‘bus 1’ en ‘bus 2’: we vinden drie items in BeSt Address: ‘Fonsnylaan 20’; ‘Fonsnylaan 20 bus 1’ en ‘Fonsnylaan 20 bus 2’. 

Voor elk adres (straat, postcode, nummer) hebben we gecontroleerd of de coördinaten die bij de bussen horen niet abnormaal ver uit elkaar liggen. In de overgrote meerderheid van de gevallen hebben de verschillende bussen met hetzelfde nummer allemaal dezelfde coördinaten, maar dit is niet altijd het geval.

Voor elk adres met busnummers schetsen we de ‘minimum rotated rectangle’ , d.w.z. de rechthoek met de minimale oppervlakte die alle punten omvat (de coördinaten van het ‘basis’-adres, voorgesteld door ‘/’, en die van elk van de bussen), waarbij elke rotatie van de rechthoek mogelijk is. Zo’n rechthoek die twee punten omvat zal een breedte van nul hebben en een lengte gelijk aan de afstand tussen de punten. In het geval van meerdere niet-uitgelijnde punten zullen beide afmetingen positief zijn.

De anomalieën werden voornamelijk gedetecteerd in Vlaanderen, met meer dan 100 gevallen. In Wallonië zijn de coördinaten van de verschillende bussen steeds gelijk aan de coördinaten van het basisadres. In Brussel werden slechts twee afwijkingen vastgesteld.

Om dit te illustreren nemen we twee voorbeelden, weergegeven in de figuur hieronder. Het eerste voorbeeld (Abdijstraat, 41 te 9140 Stekene) toont aan dat het basisadres (Abdijstraat, 41, voorgesteld door een ‘/’) zich op 11 kilometer van Abdijstraat, 41 bus 12 bevindt. We vonden bijna honderd zeer vergelijkbare voorbeelden.

Het tweede is een gevolg van het probleem dat in ons vorige artikel werd geïllustreerd: om adressen tussen ‘1’ en ‘3’ te maken, kun je ze maken met huisnummers ‘1A’, ‘1B’, ‘1C’… (zonder busnummer), of ze allemaal ‘nummer 1’ noemen, maar met een busnummer ‘A’, ‘B’, ‘C’… In de ‘Diamantstraat’ in Diksmuide is (ongetwijfeld per ongeluk) een hybride keuze gemaakt: naast de 1 vinden we ‘1A’, ‘1B’, … ‘1F’, dan … ‘1 bus G’! Dit creëert een grote afstand tussen de 1 (basisadres) en de 1 (bus G).

Postgrenzen

In deze analyse vergelijken we de door bpost gedefinieerde postcodegrenzen. Om dit te doen, kijken we voor elk BeSt-adres in welke bpost-polygoon het valt en selecteren we de adressen waarvoor er een inconsistentie is tussen de BeSt-postcode en de bpost-postcode.

Om nauwkeurigheidsproblemen van een punt dat precies op de grens ligt te voorkomen, verwijderen we een strook van 50 meter uit de contouren in de postcodes die door bpost zijn gedefinieerd. Een inconsistentie wordt daarom slechts geïdentificeerd wanneer een adres in een P1 postcode (volgens BeSt) eigenlijk in de polygoon van een P2 postcode (volgens bpost) ligt, met P1 ≠ P2.

In de onderstaande afbeeldingen kunnen we enkele van de geïdentificeerde voorbeelden zien. De rode lijn stelt de grens voor die overeenkomt met de postcode in kwestie, volgens bpost (6700 voor het hoofdvoorbeeld). Binnen deze lijn bevinden zich een groot aantal BeSt-adressen die bij dezelfde postcode horen. Deze adressen worden hier niet getoond om het beeld niet te overladen. De gekleurde stippen buiten de rode omlijning zijn dus adressen die BeSt associeert met de code in de titel, maar die volgens het postkantoor de postcode hebben uit de legende (6704 in het blauw, 6706 in het oranje voor de 1^e voorbeeld).

Merk op dat de geregistreerde ‘uitwisselingen’ altijd binnen dezelfde gemeente liggen (Aarlen voor het voorbeeld). Terwijl BeSt ervan uitgaat dat alle adressen in de gemeente Aarlen op 6700 liggen, gaat bpost er wel van uit dat een deel van het grondgebied op 6704 (Guirsch) of 6706 (Autelbas-Barnich) ligt, twee postcodes die BeSt niet kent.

Dit is niet alleen een kwestie van een bestand (Shapefile) dat niet up-to-date is op de website van de Post: de online adresvalidatietool van bpost is consistent met de getoonde postcodes.

Tijdens sommige gesprekken kregen we te horen dat gemeenten de vrijheid hebben om de toewijzing van postcodes op hun grondgebied te wijzigen. Hierover bestaat echter geen consensus: in de “Gids voor het vaststellen en toekennen van adressen”, staat dat “Postcodes en hun systematisering zijn echter eigendom van de dienstverlener van de universele postdienst, in voorkomend geval (…) bpost. Ze kunnen alleen worden toegekend en gewijzigd op basis van een voorstel van bpost en na een gemotiveerd advies van het BIPT en de goedkeuring van de minister overeenkomstig artikel 135 van de wet van 21 maart 1991. (Artikel 22)”.

We troffen iets meer dan 8000 anomalieën aan in Wallonië (op een totaal van 1,85 miljoen relevante adressen), ~ 11 000 in Vlaanderen (op 3,83 miljoen) en een marginaal aantal in Brussel (op 860 000). Merk op dat sommige afwijkingen aanvaardbaar zijn, zoals gebouwen (kastelen, boerderijen, enz.) die ver van de voordeur liggen. BeSt lokaliseert het gebouw, maar de postcode komt overeen met die van de ingang.

Inconsistentie van namen

Voor deze analyse gaan we een ‘klassieke’ benadering op basis van karakterketen combineren met een geografische benadering. We starten met het identificeren van de lijst van alle paren van aangrenzende straten (d.w.z. de ene heeft een adres op minder dan 100 meter van de andere). Vervolgens controleren we op kleine verschillen in straatnamen. We zien meestal twee situaties:

• Straten die verschillende gemeenten doorkruisen en in elke gemeente een andere schrijfwijze hebben: ‘Rue de Monténégro, 1060’, vs ‘Rue du Monténégro, 1190’;
• Straten met twee verschillende schrijfwijzen binnen dezelfde gemeente: ‘Chaussée Brunehault’ of ‘Chaussée Brunehaut’, in 4452 in beide gevallen.

Er zijn ook een paar fout-positieven: ‘Rue de Mars’ vs ‘Rue de Mai’. We schrappen namen uit onze vergelijkingen die identiek zijn op een geïsoleerde laatste letter na (“Hensellaan A” vs “Hensellaan B”), evenals namen waarbij slechts een cijfer verandert (‘5de Zijweg’ vs ‘6de Zijweg’).

Met betrekking tot de eerste situatie, waarbij de naam verandert wanneer men van de ene gemeente naar de andere gaat, is het betreurenswaardig dat er een gebrek aan consistentie is, wat in strijd is met artikel 5 van de hierboven beschreven richtlijn, waarin staat dat “[a]ls een weg zich uitstrekt over het grondgebied van meerdere gemeenten en die weg dezelfde naam behoudt, dan moeten die gemeenten erop toezien dat de spelling van die straatnaam in alle betrokken gemeenten dezelfde is”. De richtlijn is echter niet bindend, gemeenten kunnen dus een eigen spelling behouden.

Het is echter de moeite waard om je af te vragen of de spelling die in BeSt wordt gebruikt (zoals doorgegeven door de gemeenten) echt de juiste is. Bijvoorbeeld, ‘Rue Walckiers’ in 1030 Schaarbeek is een uitbreiding van ‘Rue Walkiers’ in 1140 Evere. Het (enige) Schaarbeekse bord voor deze straat schrijft het echter als … ‘Rue Walkiers’! Hetzelfde geldt voor het (kleine) deel van de Tervuerenlaan in Oudergem, dat als dusdanig gespeld wordt in Sint-Pieters-Woluwe en op de straatnaambordjes in Oudergem, maar in Oudergem vermeld staat als ‘Tervurenlaan’. Er zijn nog veel meer voorbeelden.

De situatie waarin, binnen dezelfde gemeente, soms zelfs voor dezelfde postcode, twee straatsecties niet op dezelfde manier worden gespeld, is een duidelijke indicatie van een probleem met de kwaliteit van de gegevens. We hebben tientallen van dergelijke gevallen geïdentificeerd, voornamelijk in Wallonië, en noemen er hier slechts enkele ter illustratie. 

Inconsistente geometrie

Hier bekijken we de geometrische vorm die bestaat uit de opeenvolging van punten van adressen met dezelfde pariteit, voor dezelfde straat en postcode. Vervolgens berekenen we een aantal metrieken op deze lijn, ervan uitgaande dat de hoogste waarden duiden op een afwijking.

We hebben op experimentele basis een aantal metrieken gedefinieerd. We zullen er slechts twee nader toelichten waarvan we vonden dat ze het meest relevant waren voor de analyse. In een diepgaande analyse moeten ze echter worden gecombineerd met andere: 

• delta_ratio: voor elk paar adressen in dezelfde straat en van dezelfde pariteit berekenen we de verhouding van het verschil tussen het numerieke deel van de huisnummers en de afstand. Een hoge waarde geeft aan dat twee huizen met zeer verschillende huisnummers abnormaal dicht bij elkaar liggen. Dit is vaak te verklaren door twee verschillende fenomenen:
  • Normale situatie: een “cirkelvormige” straat, waarin het laatste nummer naast het eerste staat,
  • Abnormale situatie: op de hoek tussen twee straten is een gebouw toegewezen aan de verkeerde straat. Of, meer algemeen, een inversie tussen twee nummers;
• prev_to_prev²_ratio: over het algemeen wordt verwacht dat een getal dichter bij het volgende getal (van dezelfde pariteit) ligt dan het getal dat daarop volgt. Indien nummer 2 veel dichter bij nummer 6 ligt dan bij nummer 4, is het waarschijnlijk dat nummer 4 op de verkeerde plaats staat. Hier berekenen we de ratio tussen de afstand tussen een nummer en het vorige nummer (bijvoorbeeld tussen 4 en 6) en de afstand tussen dat nummer en het nummer ervoor (bijvoorbeeld tussen 2 en 6). Een waarde van 100 geeft dus aan dat een getal (aangegeven met een ‘hn:…’ in de titel van de grafiek) 100 keer dichter bij twee nummers achter ligt dan bij het vorige nummer.

De eerste metriek zal adressen uitlichten die zich in de juiste straat bevinden, maar niet op de juiste plaats. De tweede geeft adressen aan die ver verwijderd zijn van andere nummers in dezelfde straat.

In de volgende illustraties zijn de stippen opeenvolgend gekleurd volgens de numerieke waarde van het huisnummer, gaande van paars voor de laagste waarde tot geel voor de hoogste. Een lijn verbindt deze stippen in numerieke volgorde. 

De analyse van deze anomalieën moet vaak van geval tot geval worden bekeken, om te bepalen of het om een duidelijke fout gaat of om de weerspiegeling van een enigszins ongebruikelijke bepaling. Dit werk kan enkel uitgevoerd worden door de lokale overheden, die de informatie doorgeven aan de gewesten en vervolgens aan het FOD BOSA.

Het slotwoord

De code (Python-notebook) waarmee we al deze anomalieën hebben geïdentificeerd, is beschikbaar op Github en biedt een interactieve weergave van alle kaarten die hierboven zijn gepresenteerd. Het is niet aan ons om voor elk van de anomalieën te bepalen of het werkelijk een fout is (er zullen veel fout-positieven zijn), en zo ja, op welk niveau het zich voordoet: de gemeente, de consolidatie door de regio’s of het FOD BOSA, bpost, het straatnaambord, enz. 

Bovendien blijft het aantal probleemgevallen klein in vergelijking met de 6,5 miljoen adressen in BeSt Address. Toch vonden we de methodologie interessant genoeg om te publiceren. Ze zou ook kunnen worden toegepast op andere datasets, zoals OpenStreetMap of andere open bronnen.

Hoe een databank ook wordt gevuld, er sluipen altijd fouten in. De gewesten en de FOD BOSA verrichten al bergen werk om ervoor te zorgen dat de gegevens van zeer hoge kwaliteit zijn. Het zal echter altijd mogelijk zijn om nieuwe problemen op te sporen. Met dit artikel hopen we zelf een klein steentje bij te dragen.

Deze post is een individuele bijdrage van Vandy Berten, gespecialiseerd in data science bij Smals Research. Dit artikel is geschreven onder zijn eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.

La gestion de la qualité de données (Data Quality), régulièrement abordée dans ce blog, consiste souvent à traiter (comparer, simplifier, transformer, “phonétiser”…) des chaînes de caractères : des noms de personnes, d’entreprises, de villes, de rues, numéros de téléphones, adresses email…

Dans cet article, nous allons considérer le genre de problèmes que l’on peut détecter lorsque les données sont associées à des coordonnées géographiques (latitudes, longitudes), en considérant les données ouvertes du projet “BeSt Address” (pour “Belgian Street Address”), du SPF BOSA (Service Public Fédéral Stratégie & Appui), source authentique des adresses en Belgique. Ce projet agrège et consolide les données des régions (UrbiS pour la région bruxelloise, le Adressenregister pour la Flandre et ICAR pour la Wallonie), qui elles-mêmes récupèrent les données d’adresses collectées par chaque commune, autorité responsable de l’attribution des adresses. On peut y télécharger une série de fichiers CSV ou XML, permettant, pour chaque adresse en Belgique, d’en connaitre l’orthographe officielle ainsi que les coordonnées géographiques.

Notre expérience nous a montré que les données des BeSt Address sont de loin les données de la meilleure qualité par rapport à d’autres sources officielles contenant des adresses (Registre national, Répertoire des employeurs, Banque Carrefour des Entreprises…), à tout le moins sur les aspects classiques de la qualité de données (cohérence des noms, absence d’abréviation…), résultat de l’énorme travail réalisé par les équipes des régions et du SPF BOSA. Néanmoins, nous avons pu y trouver un certain nombre d’anomalies identifiables uniquement en considérant les données géographiques et des analyses spatiales.

Les anomalies identifiées correspondent en grande majorité à des adresses mal placées (mauvaises coordonnées), ou à des codes postaux problématiques. Le nettoyage ne pourra être fait que par les entités sur le terrain, à savoir les communes.

Notons que les anomalies présentées ci-dessous sont issues d’une analyse “académique”. Celle-ci a déjà été discutée avec un certain nombre de personnes des instances concernées (régions, registre national, SPF BOSA, IGN…), et certaines de ces anomalies sont considérées comme acceptables. Le but de cet article n’est pas de critiquer la qualité des données, mais simplement de présenter une méthodologie, en l’illustrant avec une source de données pertinentes.

Contexte

Comme déjà expliqué dans un article précédent, la Belgique est composée, à l’heure d’écrire ces lignes, de 581 communes (ce nombre diminuera dans les prochains mois, suite à une série de fusions de communes). Chacune de celles-ci est composée d’un ou plusieurs codes postaux (associés à un nom à Bruxelles et en Flandre), et chacun de ces codes postaux peut contenir une ou plusieurs sous-communes, ou localités (part of municipality en Wallonie, dans le jargon BeSt Address).

Pour l’analyse ci-dessous, nous sommes partis des fichiers CSV disponibles sur https://opendata.bosa.be/, et avons mené quatre types d’analyse : 

• Dans la première, nous regardons si tous les numéros de boite d’une même adresse sont bien localisés proches les uns des autres ;
• Dans la deuxième, nous comparons les frontières des codes postaux définis par bpost (la poste belge) avec les codes postaux des adresses BeSt Address ;
• Dans la troisième, nous recherchons des incohérences sur des noms de rues géographiquement proches (par exemple une “Rue Roi Albert I” juste à côté d’une “Rue du Roi Albert I”) ;
• Dans la quatrième, nous recherchons des anomalies géométriques dans la forme d’une rue.

Incohérence de boites

Comme détaillé précédemment, une adresse contient toujours un “numéro de police”, ou numéro de maison, qui désigne le bâtiment, et, parfois, un “numéro de boite”, qui désigne l’unité d’habitation au sein de ce bâtiment. Dans BeSt Address, pour chaque adresse avec une boite, nous trouvons toujours une adresse équivalente de base (même rue, code postal, numéro) sans boite. Imaginons qu’au 20 de l’avenue Fonsny, on trouve deux boites, “boite 1” et “boite 2” : on trouvera trois items dans BeSt Address : “Avenue Fonsny 20” ; “Avenue Fonsny 20 boite 1” et “Avenue Fonsny 20 boite 2”. 

Nous avons regardé pour chaque adresse (rue, code postal, numéro) si les coordonnées associées aux boites ne sont pas anormalement éloignées. Dans une grande majorité des cas, les différentes boites d’un même numéro auront toutes les mêmes coordonnées, mais ça n’est pas toujours le cas.

Pour chaque adresse ayant des numéros de boite, nous construisons pour ce faire le “rectangle orienté minimum” (minimum rotated rectangle), à savoir le rectangle de surface minimale englobant l’ensemble des points (les coordonnées de l’adresse “de base”, représentée par “/”, ainsi que celles de chacune des boites), en autorisant toute rotation du rectangle. Un tel rectangle englobant deux points aura une largeur nulle et une longueur équivalente à la distance entre les points. En cas de points multiples non alignés, les deux dimensions seront positives.

Les anomalies ont essentiellement été détectées en Flandre, avec plus de 100 cas. En Wallonie, les coordonnées des différentes boites sont toujours égales aux coordonnées de l’adresse de base. À Bruxelles, seules deux anomalies ont été détectées.

Pour illustrer ceci, prenons deux exemples, représentés dans la figure ci-dessous. Le premier exemple (Abdijstraat, 41 à 9140 Stekene) montre que l’adresse de base (Abdijstraat, 41, représenté par un “/”) est située à 11 kilomètres de Abdijstraat, 41 bus 12. Nous avons trouvé près d’une centaine d’exemples très similaires.

Le second est une conséquence du problème illustré dans notre article précédent : pour créer des adresses entre le “1” et le “3”, on peut soit créer les numéros de maison “1A”, “1B”, “1C”… (sans numéro de boite), soit toutes les appeler “numéro 1”, mais avec un numéro de boite “A”, “B”, “C”… Dans la “Diamantstraat” à Dixmude, un choix hybride (sans doute par erreur) a été fait : à côté du 1, on retrouve bien le “1A”, “1B”, … “1F”, puis … “1 boite G” ! Ceci génère une grande distance entre le 1 (adresse de base) et le 1 (boite G). 

Frontières postales

Dans cette analyse, nous comparons les frontières des codes postaux définies par bpost. Pour ce faire, pour chaque adresse de BeSt, nous regardons dans quel polygone de bpost elle tombe et on retient celles pour lesquelles il y a une inconsistance entre le code postal de BeSt et celui de bpost.

Pour éviter les problèmes de précision d’un point qui serait juste à la frontière, on supprime un ruban de 50 mètres des contours dans les codes postaux définis par bpost . On identifie donc une inconsistance uniquement quand une adresse d’un code postal P1 (selon BeSt) est réellement dans le polygone d’un code postal P2 (selon bpost), avec P1 ≠ P2.

Dans les images ci-dessous, on peut voir quelques-uns des exemples identifiés. La ligne rouge représente la limite correspondant au code postal en titre, selon bpost (6700 pour l’exemple principal). À l’intérieur de cette ligne sont localisées un grand nombre d’adresses de BeSt, associées au même code postal, que nous ne représentons pas ici pour ne pas surcharger l’image. Les points de couleurs en dehors du contour rouge sont donc des adresses que BeSt associe au code en titre, mais qui, selon la poste, sont du code postal indiqué dans la légende (6704 en bleu, 6706 en orange pour le 1er exemple).

Notons que les “échanges” relevés se font toujours au sein d’une même commune (Arlon pour l’exemple). Mais alors que BeSt considère que toutes les adresses de la commune d’Arlon sont sur 6700, bpost considère qu’une partie du territoire est sur 6704 (Guirsch) ou 6706 (Autelbas-Barnich), deux codes postaux inconnus de BeSt.

Il ne s’agit pas uniquement d’une question d’un fichier (Shapefile) qui ne serait pas à jour sur le site de bpost : l’outil en ligne de validation d’adresse de bpost est bien cohérent avec les codes postaux présentés.

Lors de certaines discussions, il nous a été répondu que les communes avaient la liberté de modifier, au sein de leur territoire, l’attribution des codes postaux. Mais il n’y a pas de consensus là-dessus : dans le “Guide en matière de constatation et attribution d’adresses“, il est dit que “(…) les codes postaux et leur systématisation sont la propriété du prestataire du service postal universel, en l’occurrence (…) bpost. Ils ne peuvent être attribués et modifiés que sur proposition de bpost, et après avis motivé de l’IBPT et l’approbation du ministre conformément à l’article 135 de la loi du 21 mars 1991. (Article 22)”.

Nous avons trouvé un peu plus de 8.000 anomalies en Wallonie (sur un total de 1.85 M adresses pertinentes), ~11.000 en Flandre (sur 3.83 M), et un nombre marginal à Bruxelles (sur 860.000). Notons que certaines anomalies sont acceptables, comme par exemple le cas de bâtiments (château, ferme…) loin de la porte d’entrée. BeSt localise le bâtiment, mais son code postal correspond à celui de son entrée.

Incohérence de noms

Pour cette analyse, nous allons combiner une approche “classique” basée sur des comparaisons de chaînes de caractères, et une approche géographique. Nous commençons par identifier la liste de tous les couples de rues adjacentes (c’est-à-dire que l’une a une adresse distante de moins de 100 mètres d’une adresse de l’autre). On regarde ensuite si l’on ne trouve pas de petites différences dans les noms de rue. Nous rencontrons typiquement deux situations :

• Des rues traversant plusieurs communes avec une orthographe différente dans chacune d’elle : “Rue de Monténégro, 1060″, vs “Rue du Monténégro, 1190″ ;
• Des rues avec deux orthographes différentes au sein de la même commune : “Chaussée Brunehault” ou “Chaussée Brunehaut“, à 4452 dans les 2 cas.

On trouvera également quelques faux positifs : “Rue de Mars” vs “Rue de Mai”. On élimine de nos comparaisons les noms identiques à part une dernière lettre isolée (“Hensel laan A” vs “Hensel laan B”), ainsi que les noms où seul un chiffre change (“5de Zijweg” vs “6de Zijweg”).

Concernant la première situation, où le changement de nom arrive au passage d’une commune à l’autre, on peut regretter le manque de cohérence qui va à l’encontre de l’article 5 de la directive décrite plus haut, qui dit que “[d]ans l’hypothèse où une voie s’étend sur le territoire de plusieurs communes, et que cette voie garde le même nom, ces communes doivent s’assurer que l’orthographe de ce nom de rue soit identique dans toutes les communes concernées”. La directive n’est cependant pas contraignante, les communes sont donc libres de garder leur orthographe propre.

Il est cependant pertinent de se demander si l’orthographe présente dans BeSt (transmise par les communes) est réellement la bonne. On peut par exemple citer la “Rue Walckiers” à 1030 Schaerbeek, qui prolonge la “Rue Walkiers” à 1140 Evere. Or, la (seule) plaque schaerbeekoise de la rue l’orthographie … “Rue Walkiers” ! Il en va de même pour la (petite) portion auderghemoise de l’avenue de Tervueren, orthographiée comme telle à Woluwé-Saint-Pierre, ainsi que sur les plaques de rue à Auderghem, mais reprise dans BeSt comme “Avenue de Tervuren” à Auderghem. Nous pourrions citer bien d’autres exemples.

La situation où, au sein d’une même commune, parfois même pour un même code postal, deux portions de rue n’ont pas la même orthographe, dénote de façon plus évidente d’un problème de qualité de données. Nous en avons identifié des dizaines, principalement en Wallonie, nous n’en reprenons ici que quelques-uns pour illustration. 

Géométrie incohérente

Nous considérons ici la forme géométrique composée de la séquence de points des adresses de même parité, pour une même rue et un même code postal. Sur cette ligne, nous calculons ensuite un certain nombre de métriques, en supposant que les valeurs les plus élevées dénotent d’une anomalie.

Nous avons défini de façon expérimentale un certain nombre de métriques. Nous allons juste en détailler deux qui nous ont paru les plus pertinentes à l’analyse. Mais dans une analyse approfondie, il conviendra de les combiner avec d’autres : 

• delta_ratio : pour chaque couple d’adresses d’une même rue et de même parité, on calcule le ratio de la différence entre la partie numérique des numéros de maison et la distance. Une valeur élevée indique que deux maisons de numéros très distants sont anormalement proches. Ceci s’explique souvent par deux phénomènes distincts :

  • Situation normale : une rue “circulaire”, dans laquelle le dernier numéro se situe à côté du premier,

  • Situation anormale : sur le coin entre deux rues, un bâtiment a été assigné à la mauvaise rue. Ou plus généralement, une inversion entre deux numéros ;

• prev_to_prev²_ratio : on s’attend en général à ce qu’un numéro soit plus proche du numéro suivant (de même parité) que de celui d’encore après. Si le numéro 2 est beaucoup plus proche du 6 que du 4, il est probable que le 4 soit mal placé. On calcule ici le ratio de la distance d’un numéro au numéro précédent (par ex. entre 4 et 6) sur la distance entre ce numéro et celui qui précède le précédent (par ex. entre 2 et 6). Une valeur de 100 indique donc qu’un numéro (indiqué un ‘hn:…’ dans le titre du graphique) est 100 fois plus proche de deux numéros en arrière que du numéro précédent.

La première métrique mettra en évidence des adresses qui ont été localisées dans la bonne rue, mais pas au bon endroit. La seconde fera ressortir des adresses qui ont été localisées très loin des autres numéros de la même rue.

Dans les illustrations suivantes, les points sont colorés séquentiellement selon la valeur numérique du numéro de police, allant de mauve pour la plus petite valeur à jaune pour la plus grande. Une ligne relie ces points dans l’ordre numérique. 

L’analyse de ces anomalies nécessite souvent une attention au cas par cas, pour savoir s’il s’agit d’une erreur manifeste, ou du reflet d’une disposition un peu particulière. Ce travail ne peut être fait que par des instances de terrain, à savoir les communes, qui transmettent ces informations aux régions puis au SPF BOSA.

Le mot de la fin

Le code (notebook Python) qui nous a permis d’identifier toutes ces anomalies est disponible sur Github, et permet entre autres une vue interactive de toutes les cartes présentées ci-dessus. Pour chacune des anomalies, il ne nous revient pas de déterminer s’il s’agit réellement d’une erreur (il y aura beaucoup de faux positifs), et, le cas échéant, à quel niveau elle se situe : la commune, la consolidation par les régions ou le SPF BOSA, bpost, la plaque de rue… 

Par ailleurs, le nombre de cas problématiques reste faible par rapport aux 6,5 millions d’adresses que contient BeSt Address. Mais la méthodologie nous paraissait suffisamment intéressante pour la publier. On pourrait par ailleurs l’appliquer à d’autres jeux de données, comme par exemple OpenStreetMap, ou d’autres sources ouvertes.

Quelle que soit la façon dont est alimentée une base de données, des erreurs s’y introduisent. Les régions et le SFP BOSA font déjà un travail considérable pour garantir des données d’une très bonne qualité. Mais il sera toujours possible de détecter des nouveaux problèmes. Par cet article, nous espérons apporter notre modeste contribution à l’édifice.

Ce post est une contribution individuelle de Vandy Berten, spécialisé en data science chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Geocodering is de bewerking waarbij een tekstueel postadres (‘Fonsnyln 20, 1060 Brussel’) omgevormd wordt tot een in componenten opgesplitste en gestandaardiseerde versie, gelinkt aan een geografische locatie1¹ :

{"street":  "Fonslylaan", 
 "number":  20, 
 "zipcode": 1060,  
 "city":    "Sint-Gillis",
 "lat":     50.8358216, 
 "lon":     4.3386884}

In een vorig artikel hebben we aangetoond dat er een aantal tools bestaan om deze bewerking uit te voeren en dat het, onder bepaalde omstandigheden, nodig is om over een on-site (on-premise) of lokale tool te beschikken. We zetten eerder al NominatimWrapper in de kijker, een oplossing die we ontwikkeld hebben op basis van OpenStreetMap.

In België beheert de federale overheidsdienst “Strategie en Ondersteuning” (BOSA) BeSt Address, de authentieke bron voor Belgische adressen. Ze zijn beschikbaar als open data in verschillende formaten. In dit artikel stellen gaan we dieper in op de volgende vraag: is het mogelijk om een lokale geocoder op te stellen gebaseerd op deze gegevens? Het antwoord vergt zekere nuance: Ja, maar…

Ten eerste stelt BOSA een aantal webservices ter beschikking maar met twee beperkingen:

• Deze zijn enkel beschikbaar voor overheidsdiensten, niet voor bedrijven of burgers.
• Ze bieden geen ‘standaardisatie’: je moet de juiste schrijfwijze van een straat of (deel)gemeente kennen om het te gebruiken.

Pelias

Met het opensourceproject Pelias kan een geocoder opgezet worden op basis van je eigen gegevens. In combinatie met OpenAddresses.io, een project dat open adresgegevens samenbrengt, is het mogelijk om Pelias in te zetten voor een reeks landen of steden, waaronder België met BeSt Address (in combinatie met OpenStreetMap).

Hoewel het eenvoudig is om een geocoder op te zetten die Pelias en BeSt Address combineert en die goed lijkt te werken wanneer je hem test op een paar adressen, raak je al snel teleurgesteld wanneer je probeert naar een hogere versnelling te schakelen en hem datasets stuurt van de (Belgische) Kruispuntbank van Ondernemingen, het werkgeversrepertorium (RSZ) of het rijksregister.

Met Pelias zijn er twee vraagmodi: gestructureerd ({“address”: “Fonsnylaan 20”, “postalcode”: 1060, “locality”: “Sint-Gillis”}) of ongestructureerd ({“query”: “Fonsnylaan 20, 1060 Sint-Gillis”}). Van de gegevens die we gestructureerd (cfr. “pelias_struct” in de grafiek hieronder) getest hebben (10 000 adressen afkomstig van verschillende bronnen in onderstaande legende), was Pelias slechts in staat om 55 % van de adressen exact te lokaliseren. Enkele percentages (1-2) zijn gelokaliseerd wat betreft de straat en in +/- 35% van de gevallen vond Pelias enkel de stad… met andere woorden niks bruikbaars. En in 7-10 % krijgen we zelfs geen enkel resultaat.   

Pelias doet iets beter ‘ongestructureerd’ (pelias), aangezien hij bijna altijd in staat is om een resultaat te verschaffen, en 11 % bijkomende adressen worden exact gelokaliseerd.

Het is interessant om een paar zaken op te merken:

• Wanneer het resultaat niet exact is, bevat het resultaat geen gegevens van BeSt Address, maar van OpenStreetMap (niveau ‘street’) of WhosOnFirst (niveau ‘city’);
• Soms geeft een adres geen resultaat in ‘gestructureerde’ modus, maar wel in ‘ongestructureerde’ modus, en omgekeerd;
• In gestructureerde modus lijkt Pelias vaak in de war te raken door de aanwezigheid van de parameter ‘locality’ naast de ‘postalcode’. Vaak geeft een adres een resultaat op niveau ‘city’ wanneer deze parameter wordt opgegeven, maar een resultaat op niveau ‘building’ wanneer alleen de postcode wordt opgegeven (naast de straat en het nummer). Je kunt het verschil zien in de grafiek op de regel “pelias_struc_noloc”, waar het precies gelokaliseerde deel (‘building’, in groen) met bijna 25% toeneemt. Aan de andere kant verdwijnt het deel gelokaliseerd op stadsniveau, dat grotendeels gebaseerd is op dit ‘locality’-argument, zo goed als;
• Het door Pelias geleverde resultaat bevat geen ‘BeSt id’ die het mogelijk zou maken om de unieke en authentieke identificatie van een adres te verkrijgen;
• Noch de Franstalige adressen van de Vlaamse faciliteitengemeenten (en vice-versa), noch de Duitstalige adressen van de Oostkantons worden geïmporteerd.

Maar op het moment van schrijven is er een nog groter probleem: de gegevens die Pelias gebruikt, dateren van midden 2021, om twee redenen: 

• Het door OpenAddresses erkende formaat veranderde rond oktober 2021 en is niet langer compatibel met de door Bosa beschikbaar gestelde bestanden;
• OpenAddresses veranderde zijn ‘dataflow’ midden 2021: de voorbereide gegevens werden eerst ter beschikking gesteld op het adres https://results.openaddresses.io/ dat nog steeds beschikbaar is maar waarvan de gegevens niet meer up-to-date zijn; ze zijn wel up-to-date op https://batch.openaddresses.io/data. Pelias werd echter niet aangepast en blijft de gegevens van het oude systeem downloaden.

bePelias

Het lijkt dus duidelijk dat Pelias in zijn huidige vorm geen serieuze kandidaat is voor een toepassing die geocodering van adressen in België vereist. Zowel de geïmporteerde gegevens (te oud, geen ID, geen gegevens op straatniveau als een nummer niet geïdentificeerd is) als de robuustheid ontbreken. Maar het leek ons dat het potentieel aanwezig was en we gingen aan de slag om het te verbeteren. Er waren twee mogelijkheden: 

• Een ‘kloon’ van Pelias maken door de code aan te passen. Met het risico om wijzigingen aan te brengen die niet compatibel zouden zijn met de toekomstige ontwikkelingen van Pelias, en een grote inspanning op het vlak van begrip en ontwikkeling;
• Een ‘extra laag’ toevoegen, zoals we al met succes hebben gedaan met NominatimWrapper, om de tekortkomingen van Pelias te compenseren. Het is deze tweede optie die we hebben gekozen.

Deze tool die we ‘bePelias’ hebben genoemd en die we open source ter beschikking stellen (https://github.com/SmalsResearch/bePelias) doet hoofdzakelijk twee dingen:

• Een meer volledige voorbereiding van de ‘BeSt Address-’gegevens, inclusief een reeks aanvullende gegevens (adres- en straatidentificatienummers, NIS-codes voor gemeenten, enz.), die het meertalige aspect vervolledigen en identificatie op straatniveau mogelijk maken wanneer het nummer niet bekend is. We hebben Pelias ook geconfigureerd om interpolatie mogelijk te maken (ervan uitgaande dat de ‘8’ van een straat, indien niet bekend, tussen de ‘6’ en de ’10’ ligt).
• Een tussenlaag tussen Pelias en de client, in de vorm van een REST API, om een reeks varianten van een adres uit te proberen. Een reeks combinaties van de volgende varianten wordt getest, totdat er één een bevredigend resultaat geeft:
  • Gestructureerde of ongestructureerde versie van de oproep tot Pelias;
  • Met de lokaliteit (plaats), of alleen de postcode;
  • Met een reeks reguliere expressies om de straat- of plaatsnaam op te schonen. Meestal zullen we alle tekst tussen haakjes verwijderen, wat heel gebruikelijk is in straatnamen om een opmerking of de naam van de deelgemeente te specificeren;
  • Door het huisnummer op te schonen, dat heel vaak ook een busnummer bevat, wat in de meeste gevallen de locatie niet verandert.

In de praktijk zien we dat de ‘basis’ gestructureerde versie (zonder opschoning of selectie) een resultaat geeft voor +/- 53 % van de adressen (voor KBO-gegevens, zie bijgevoegde figuur). Dit wordt gevolgd door 20 % na verwijdering van de lokaliteit, nog steeds in gestructureerde vorm, dan 11% in ongestructureerde vorm, 8% na opschoning in gestructureerde vorm, en dan een reeks andere combinaties voor een klein aantal adressen. Bijna alle combinaties zijn op een bepaald moment bruikbaar.

Resultaten

Het resultaat is zichtbaar in onderstaande grafieken. De bePelias-oplossing is bijna net zo efficiënt als Here WeGo (here in de grafieken) of Microsofts Bing Maps (bing); beter dan Google Maps (google), dat vrij gevoelig is voor ruis in adressen, zoals tekst tussen haakjes, en NominatimWrapper, dat enkel de straten lokaliseert voor een groot deel van de adressen.

We hebben ook de nauwkeurigheid van de bePelias-resultaten getest met behulp van een ‘majority voting’-methodologie door dezelfde dataset naar verschillende geocoders te sturen. We presenteerden de resultaten in een recent webinar, waaruit bleek dat de prestaties zeer vergelijkbaar zijn met die van Here WeGo of Bing Maps, en opnieuw aanzienlijk beter dan Google Maps, dat naast het feit dat het vaak alleen de straat lokaliseert, een vervelende neiging heeft om te hallucineren en resultaten biedt die duizenden kilometers verwijderd zijn van het juiste antwoord.

Wat snelheid betreft, geeft het feit dat de oplossing lokaal draait een aanzienlijk voordeel, namelijk twee keer zo snel als Google Maps of 5 keer zo snel als Bing Maps. Hiervoor moet de geocoder natuurlijk zo dicht mogelijk bij de toepassing die hem nodig heeft worden geïnstalleerd.

Conclusies: tool bePelias

Op basis van bovenstaande stellen wij een werkende oplossing, bePelias, ter beschikking, die je in staat stelt om lokaal een geocoder te instantiëren, met behulp van Docker, uitsluitend gebaseerd op open source code (Pelias) en open data (voornamelijk BeSt Address), met nauwelijks een paar duizend regels extra code in Python of Bash.

Onze oplossing heeft natuurlijk niet alleen maar voordelen:

• bePelias werkt alleen voor België;
• bePelias werkt alleen voor adressen. Je krijgt geen antwoord op ‘Smals, Sint-Gillis’ of ‘Bakker, Namen’;
• bePelias vereist de installatie, het beheer en het onderhoud (updaten van de server, bePelias en ‘BeSt Address’-gegevens) van een server met ongeveer 15 GB schijfruimte en minstens 8 GB RAM geheugen, wat, afhankelijk van het project, een hogere kost kan betekenen dan het gebruik van een commerciële cloud-oplossing;
• In dit stadium is dit nog een onderzoeksproject dat zich moet bewijzen in een industriële omgeving.

Daar staat tegenover dat:

• bePelias vergelijkbare prestaties biedt met de grote commerciële spelers in de sector;
• bePelias on-premise werkt, wat de problemen van vertrouwelijkheid en GDPR oplost;
• bePelias gebaseerd is op BeSt Address, de (recente) authentieke bron van adressen in België. Het verkrijgen van een ‘BeSt id’ maakt het gemakkelijker om te communiceren met een reeks webservices die deze bron hebben geïntegreerd.

Feedback is zeer welkom en zal helpen om deze tool, die klaar staat om gebruikt te worden, te verbeteren!

1. Dit is een vereenvoudigd illustratief voorbeeld, waarvan de syntaxis niet overeenkomt met een bekende tool. ︎

Deze post is een individuele bijdrage van Vandy Berten, gespecialiseerd in data science bij Smals Research. Dit artikel is geschreven onder zijn eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.

Le géocodage est l’opération qui permet de transformer une adresse postale textuelle (“av. Fonsny 20, 1060 Bruxelles”) en une version décomposée et standardisée, associée à une localisation géographique¹ :

{"street":  "Avenue Fonsny", 
 "number":  20, 
 "zipcode": 1060,  
 "city":    "Saint-Gilles",
 "lat":     50.8358216, 
 "lon":     4.3386884}

Dans un article précédent, nous avons montré qu’il existe une série d’outils pour réaliser cette opération et que, dans certaines circonstances, il est nécessaire de disposer d’un outil sur site (on-premise), ou local. Nous avons déjà mis en avant NominatimWrapper, une solution que nous avons développée, basée sur OpenStreetMap.

En Belgique, le service public fédéral “Stratégie et Appui” (BOSA) gère BeSt Address, la source authentique des adresses belges. Elles sont disponibles en open data dans différents formats. Dans cet article, nous allons nous pencher sur la question suivante : est-il possible de mettre en place un géocodeur local basé sur ces données ? La réponse nécessite une certaine nuance : Oui, mais…

Précisons d’abord que BOSA met à disposition une série de web services, mais avec deux limitations :

• Ceux-ci sont uniquement disponibles pour les services publics, pas pour les entreprises ou les citoyens ;
• Ils n’offrent pas l’aspect “standardisation” : il est nécessaire de connaitre l’orthographe (quasi) exacte d’une rue ou d’une (sous-)commune pour l’utiliser.

Pelias

Le projet open source Pelias permet de mettre en place un géocodeur basé sur ses propres données. En combinaison avec OpenAddresses.io, un projet rassemblant des données d’adresses ouvertes, il est possible de déployer Pelias pour une série de pays ou de villes, dont la Belgique avec BeSt Address (en combinaison avec OpenStreetMap).

S’il est facile de mettre en place un géocodeur combinant Pelias et BeSt Address qui semble bien marcher quand on le teste sur quelques adresses, on déchante vite quand on tente de passer à la vitesse supérieure, en lui envoyant des ensembles de données venant de la Banque Carrefour des Entreprises (belge), du répertoire des employeurs (ONSS) ou encore du registre national.

Pelias permet deux modes d’interrogation : structuré ({“address”: “Avenue Fonsnsy 20”, “postalcode”: 1060, “locality”: “Saint-Gilles”}) ou non structuré ({“query”: “Avenue Fonsnsy 20, 1060 Saint-Gilles”}). Sur les données que nous avons testées (10.000 adresses provenant de diverses sources en légende ci-dessous) en mode structuré (cf. “pelias_struct” dans le graphique ci-dessous), Pelias n’a été capable de localiser précisément que de l’ordre de 55 % des adresses. Quelques pour cents (1-2) sont localisés au niveau de la rue, et dans +/- 35 % des cas, Pelias n’a trouvé que la ville … autant dire, rien d’exploitable. Et dans 7-10 %, on ne reçoit même aucun résultat.   

Pelias fait un petit peu mieux en mode “non-structuré” (pelias), puisqu’il sera presque toujours capable de fournir un résultat, et 11 % des adresses supplémentaires sont localisées précisément.

Il est intéressant de remarquer quelques éléments :

• Quand le résultat n’est pas précis, le résultat ne contient pas de données provenant de BeSt Address, mais d’OpenStreetMap (niveau “street”) ou WhosOnFirst (niveau “city”) ;
• Il arrive qu’une adresse ne donne pas de résultat en mode “structuré”, mais en donne en “non-structuré”, et vice-versa ;
• En mode structuré, Pelias semble fréquemment perturbé par la présence du paramètre “locality” en addition du “postalcode”. Souvent, une adresse donne un résultat de niveau “city” quand on lui fournit ce paramètre, mais de niveau “building” quand on lui fournit uniquement le code postal (en plus de la rue et du numéro). On peut voir la différence dans le graphique sur la ligne “pelias_struc_noloc”, où la partie localisée précisément (“building”, en vert) augmente de près de 25 %. En contrepartie, la partie localisée au niveau de la ville, grandement basée sur cet argument “locality”, disparaît quasiment ;
• Le résultat fourni par Pelias ne contient pas de “BeSt id”, qui permettrait d’obtenir l’identifiant unique et authentique d’une adresse ;
• Ni les adresses en français des communes flamandes à facilités (et vice-versa) ni les adresses germanophones des cantons de l’Est ne sont importées.

Mais il y a à l’heure d’écrire ces lignes un problème encore plus important : les données utilisées par Pelias datent de mi-2021, et ce pour deux raisons : 

• Le format reconnu par OpenAddresses a changé vers octobre 2021 et n’est plus compatible avec les fichiers mis à disposition par Bosa ;
• OpenAddresses a changé son flux de données mi-2021 : au préalable, les données préparées étaient mises à disposition à l’adresse https://results.openaddresses.io/, qui est toujours disponible mais dont les données ne sont plus mises à jour ; elles le sont maintenant sur https://batch.openaddresses.io/data. Mais Pelias n’a pas été adapté et continue à télécharger les données sur l’ancien système.

bePelias

Il semble donc assez clair que Pelias n’est en l’état, pas un candidat sérieux pour une application nécessitant de géocoder des adresses en Belgique. Tant les données importées (trop anciennes, sans ID, sans données au niveau des rues si un numéro n’est pas identifié) que la robustesse font défaut. Mais il nous semblait que le potentiel était là et avons cherché à l’améliorer. Il y avait deux pistes : 

• Créer un “clone” de Pelias, en modifiant son code. Avec le risque de faire des changements qui ne soient pas compatibles avec les futures évolutions de Pelias, et un effort de compréhension et de développement important ;
• Rajouter une “sur-couche”, comme nous l’avons déjà fait avec succès dans NominatimWrapper, pour pallier les défaut de Pelias. C’est cette seconde voie que nous avons choisie.

Cet outil, que nous avons appelé “bePelias” et que nous mettons à disposition en open source (https://github.com/SmalsResearch/bePelias), fait principalement deux choses :

• Une préparation plus complète des données de BeSt Address, incluant une série de données additionnelles (id des adresses, des rues, codes NIS des communes…), complétant l’aspect multilingue et permettant l’identification au niveau de la rue quand le numéro n’est pas connu. Nous avons par ailleurs configuré Pelias pour permettre l’interpolation (supposant que le “8” d’une rue, s’il n’est pas connu, se situe entre le “6” et le “10”).
• Une couche intermédiaire entre Pelias et le client, sous forme de REST API, pour tenter une série de variantes d’une adresse. On testera une série de combinaisons des variantes suivantes, jusqu’à ce qu’une donne un résultat satisfaisant :
  • Version structurée ou non-structurée de l’appel à Pelias ;
  • Avec la localité, ou uniquement le code postal ;
  • En nettoyant, avec une série d’expressions régulières, le nom de rue ou de localité. Typiquement, on enlèvera tout texte entre parenthèses, très fréquent dans les noms de rue pour préciser un commentaire ou le nom de la sous-commune ;
  • En nettoyant le numéro de maison, qui contient très souvent également un numéro de boite, ce qui ne change pas la localisation dans la plupart des cas.

Dans la pratique, on constate que la version structurée “de base” (sans nettoyage ou sélection) donne un résultat dans +/- 50 % des adresses (pour les données KBO, cf. figure ci-jointe). Viennent ensuite 20 % après suppression de la localité, toujours en structuré, puis 11 % en non structuré, 8 % après nettoyage en structuré, puis une série d’autres combinaisons pour un petit nombre d’adresses. Quasiment toutes les combinaisons sont utiles à un moment.

Résultats

Le résultat est visible dans les graphiques ci-dessous. La solution bePelias est quasiment aussi efficace que Here WeGo (here dans les graphiques) ou Bing Maps de Microsoft (bing); meilleure que Google Maps (google), qui s’avère assez sensible au bruit dans les adresses, comme du texte entre parenthèse, ainsi que NominatimWrapper, qui localise uniquement les rues d’une grande proportion d’adresses.

Nous avons également testé l’exactitude des résultats de bePelias selon une méthodologie de vote par majorité en envoyant un même ensemble de données à plusieurs géocodeurs. Nous avons présenté les résultats lors d’un récent webinaire, qui nous montrent des performances très proches de Here WeGo ou Bing Maps, et, à nouveau, sensiblement meilleures que Google Maps, qui outre le fait qu’il ne situe fréquemment que la rue, a une fâcheuse à l’hallucination, en proposant des résultats à des milliers de kilomètres de la bonne réponse.

En termes de vitesse, le fait que la solution soit sur site lui donne un avantage non-négligeable, en étant deux fois plus rapide que Google Maps ou 5 fois que Bing Maps. Ceci nécessitera bien sûr d’installer le géocodeur au plus près de l’application qui en a besoin.

Conclusions : outil bePelias

Sur base de ce qui précède, nous proposons une solution fonctionnelle, bePelias, qui permet d’instancier un géocodeur localement. Ceci se fait à l’aide de Docker, est basé uniquement sur du code source ouvert (Pelias) et de données ouvertes (principalement BeSt Address), avec à peine un gros milliers de lignes de code additionnel en Python ou Bash.

Elle n’a bien sûr pas que des avantages :

• Elle ne marche que pour la Belgique ;
• Elle ne marche que pour des adresses. Vous n’aurez pas de réponse à “Smals, Saint-Gilles”, ou “Boulangerie, Namur” ;
• Elle nécessite la mise en place, la gestion et la maintenance (mise à jour du serveur, de bePelias et des données de BeSt Address) d’un serveur avec une quinzaine de GB de disque et au moins 8 GB de mémoire RAM, ce qui, en fonction du projet, peut représenter un coût supérieur à l’utilisation d’une solution cloud commerciale ;
• Il s’agit encore à ce stade d’un projet de recherche qui doit faire ses preuves dans un environnement industriel.

Mais en contrepartie :

• Elle offre des performances comparables aux grands acteurs commerciaux du secteur ;
• Elle est on-premise, ce qui règle des problèmes de confidentialité ou liés aux RGPD ;
• Elle est basée sur BeSt Address, c’est-à-dire la (récente) source authentique des adresses en Belgique. L’obtention d’un “BeSt id” permettra d’interagir plus facilement avec une série de webservices qui auront intégré cette source.

Des retours d’expérience sont bienvenus et aideront à faire progresser cet outil qui ne demande qu’à être utilisé !

1. Il s’agit d’un exemple illustratif simplifié, dont la syntaxe ne correspond à aucun outil connu. ︎

Ce post est une contribution individuelle de Vandy Berten, spécialisé en data science chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

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

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

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

L’importance de l’évaluation

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

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

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

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

Les défis de l’évaluation

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

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

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

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

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

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

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

Métriques d’évaluation

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

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

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

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

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

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

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

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

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

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

Quand évaluer ?

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

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

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

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

Outils et frameworks

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

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

Conclusion

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

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

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

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

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

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

Het belang van evalueren

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

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

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

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

De uitdagingen bij evalueren

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

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

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

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

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

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

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

Evaluatiemetrieken

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

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

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

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

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

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

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

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

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

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

Wanneer evalueren?

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

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

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

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

Tools en frameworks

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

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

Conclusie

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

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

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

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

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

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

Extensions pour IDE

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

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

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

Un LLM sur votre ordinateur portable 

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

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

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

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

Interlude : à propos du matériel

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

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

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

Un LLM sur votre serveur 

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

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

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

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

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

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

Exemple

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

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

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

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

#!/bin/bash

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

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

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

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

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

#!/bin/bash

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

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

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

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

#!/bin/bash

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

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

# Change to the directory
cd "$1"

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

# Initialize previous_size to 0
previous_size=0

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

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

    # Update previous_size
    previous_size=$size
done

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

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

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

Conclusion

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

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

______________________

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

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

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

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

IDE plugins

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

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

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

Een LLM op je laptop

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

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

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

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

Intermezzo: over hardware

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

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

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

Een LLM op je server

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

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

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

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

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

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

Voorbeeld

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

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

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

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

#!/bin/bash

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

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

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

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

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

#!/bin/bash

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

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

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

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

#!/bin/bash

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

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

# Change to the directory
cd "$1"

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

# Initialize previous_size to 0
previous_size=0

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

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

    # Update previous_size
    previous_size=$size
done

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

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

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

Conclusie

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

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

______________________

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