GRDF exploite la GenAI pour réduire les interventions infructueuses

Deux centres pour tester et déployer l’IA générative

La conviction, c’est que les retours de ces tests doivent raffiner la stratégie GenAI chez GRDF. « Personne ne peut décider quelles seront l’architecture cible et l’organisation qui en résultera », considère Jean de la Fayolle. Il serait trop tôt pour cela.

De ce fait, GRDF a mis en place deux centres. Il y a d’abord un centre dédié aux « POC IA Gen ». Son rôle est de tester des solutions sur étagère et de combiner des services d’IA disponibles dans le cloud. Il est dirigé par une équipe « POC et innovation ». Ici, il n’agit pas d’entraîner des modèles, mais de les exploiter. Ses membres ont déjà utilisé de nombreux services d’IA. Ils sont soutenus par un centre d’excellence rassemblant des data scientists et des data engineers expérimentés. Eux peuvent et savent entraîner des modèles d’IA, de machine learning et d’IA générative. Ils sont chargés des déploiements en production des projets les plus pertinents mis en œuvre par le centre de POC. Ces deux entités sont, in fine, au service des métiers.

« Nous avons également mis en place un test de Microsoft Copilot 365 sur un périmètre limité de 300 usagers », ajoute Jean de la Fayolle. Pour rappel, en 2022, GRDF employait plus de 11 800 collaborateurs. « Nous l’utilisons pour rédiger les mails, résumer des réunions dans Teams, générer des présentations PowerPoint, etc. ». GRDF s’est assuré que les données restent dans les tenants Microsoft Azure de l’entreprise.

Dans un même temps, les équipes, dans le cadre de la stratégie GenAI, ont récolté « 100 à 150 idées » auprès des différentes entités de l’entreprise. « Finalement, les idées véritablement réalisables, pertinentes et avec un retour sur investissement, il y a en a quelques dizaines », observe-t-il.

Parmi les cas d’usage à valeur ajoutée, le directeur de la data science évoque un système mis en place pour aider les techniciens à mener leurs interventions.

Structurer les données pour réduire les interventions infructueuses

Les agents de GRDF sont amenés à installer, maintenir et relever (en partie) 15 millions de compteurs chez les usagers finaux. « Nous réalisons environ 2,5 millions d’interventions chaque année en France. Nous avons des problématiques d’accès dans les grands bâtiments collectifs ».

Qui dit grand immeuble/copropriété, dit codes d’accès. « Il y a des codes d’accès pour ouvrir la grille, prendre l’ascenseur, pour garer le véhicule d’intervention, etc. », liste le responsable. « C’est une information qui se périme vite : les codes changent au minimum tous les ans ».

Lors des interventions, les agents n’ont pas le temps de structurer leur note.

« Généralement, les tablettes restent dans les fourgonnettes. Les agents tapent rapidement leur compte rendu après l’intervention, avant de passer à la prochaine ou de rentrer chez eux. C’est compliqué d’obtenir de très bonnes qualités de données, d’autant qu’ils utilisent des abréviations », note Jean de la Fayolle. « Nous avons peu de leviers pour améliorer cet aspect ».

 Résultat, « les codes d’accès sont perdus dans un mélange d’informations techniques au sein des commentaires d’intervention ». Du fait que ces données sont non structurées, il n’est pas possible de propager l’information d’accès aux autres compteurs et ouvrage du bâtiment. Or, les compteurs – dont les données sont accessibles à distance par les agents – peuvent accueillir de petites quantités de données structurées, comme des séries de chiffres et de lettres.

L’équipe de data scientists a tenté d’extraire ces informations d’accès avec un modèle de traitement du langage naturel (NLP) traditionnel. En vain. Elle s’est donc mis en tête d’installer un système de « NLP++ ».

« Nous entraînons un grand modèle de langage pour détecter quels sont les codes d’accès parmi les chiffres présents dans les commentaires et les structurer, les propager, les mettre à jour et les rassembler par bâtiment », décrit le responsable.

Pourquoi GRDF préfère les « petits » LLM

Là encore, cela a demandé de tester plusieurs techniques d’apprentissage. Le centre d’excellence a d’abord tenté d’effectuer un fine-tuning léger d’un « gros » LLM. « Cela fonctionne assez bien, mais cela coûte cher une fois déployé », note le head of data science. « Le fine-tuning et la maîtrise des données est plus complexe avec un LLM de grande taille ».

« [...] Ce n'est pas le modèle qui est le plus important ».

Il a donc été décidé d’entraîner un « petit » LLM, de sept à huit milliards de paramètres. Ici, plusieurs modèles ouverts ont été mis en compétition. Gemma 2 7B, Llama 3-8B, Llama 3.1-8B, Mistral 7B, OpenChat 3.6, Starling 7B, NousHermes 2 7B ainsi que Phi 3 mini forment le gros de la cohorte testé par les data scientists de GRDF.

Il faut dire qu’un fine-tuning léger d’un modèle de petite taille offre différents avantages. Cela ne prend que deux minutes pour obtenir les premiers résultats sur une instance AWS EC2 G5 équipée d’un GPU Nvidia A10G doté de 24 Go de VRAM, à l’aide la librairie Unsloth. L’instance est dédiée : elle est déployée derrière le VPC de GRDF.

Lors de leurs tests, les data scientists sont progressivement passés d’un jeu de 1 000 à 1 500 paires d’instructions-réponses. Les résultats ont oscillé entre 85 % et 92 % de précision. C’est finalement NousHermes 2 7B, une variante fine-tunée de Mistral 2 7B, qui a été retenue. « NousHermes 2 a été entraîné sur des bases de code et est performant pour générer des résultats en JSON, mais ce n’est pas le modèle qui est le plus important », souligne Jean de la Fayolle. L’écart de performance n’est pas si élevé que cela entre les LLM et la plateforme Hugging Face pullule de modèles « open weight » régulièrement réentraînés. C’est principalement l’architecture autour du modèle qu’il faut soigner, prévient le head of data science. Il faut qu’elle soit la plus réutilisable possible, sans modification lourde.

Ces techniques pour industrialiser un cas d’usage d’IA générative

Problème, ce n’est pas un jeu de 1 500 commentaires d’intervention qu’il faut « scanner », mais plus de 920 000. Or un LLM de 7 milliards de paramètres n’a pas forcément la fenêtre de contexte suffisante pour ce faire et le fera lentement. « Comment faire pour que cela ne prenne pas trois semaines ? », expose le spécialiste.

Une partie de la réponse est de conditionner les résultats pour éviter les faux positifs. Or, les grands modèles de langage sont réputés pour leur caractère non déterministe. C’est en tout cas leur nature technique et c’est un argument repris par Gartner pour évoquer les risques de fiabilité qu’ils peuvent poser. « C’est assez faux », considère Jean de la Fayolle. « L’on peut sélectionner la température » et utiliser les seeds (les signatures des prompts qui ont donné les meilleurs résultats), entre autres, pour contrôler la génération, explique-t-il. « Par exemple, nous avons mis en place un moyen de respecter le format JSON ».  

Une autre partie de la solution consiste à exécuter des inférences en batch. Là, il s’agit d’utiliser les bonnes librairies qui accélèrent les traitements et de « quantizer », de compresser les poids du modèle, afin qu’il occupe un espace réduit dans la mémoire vive du GPU. Dans le cas présent, l’équipe de GDRF utilise un format BF16 afin que le LLM conserve ses performances. Dans cet état, il occupe environ 16 Go sur les 24 Go de VRAM disponible. Les data scientists ont divisé son jeu de données à traiter en lots de 200 à 300 commentaires. « Cela prend environ 6 heures pour traiter les 920 000 commentaires sur un petit GPU », commente-t-il. « Si vous avez accès à de plus gros GPU, comme les A100 ou H100, cela peut aller beaucoup plus vite ou vous pouvez traiter de plus gros batch ». Mais il y a plusieurs avantages à utiliser un petit GPU : les coûts liés à la consommation dans le cloud sont moindres, donc les émissions carbone sont plus faibles et surtout il est possible d’exécuter le LLM sur une infrastructure sur site, voire une station de travail. Un GPU A10G dispose de la même quantité de VRAM qu’une carte RTX 4090 à peu près aussi performante.

Lors de la V1 du projet, plus de 130 000 codes d’accès ont été extraits et structurés. Une V2 est déjà en cours. Une fois que les résultats seront jugés suffisamment bons, ce sont six millions de codes qui pourront être transférés vers les compteurs et ouvrages. « Nous estimons que nous pouvons éviter 30 000 interventions vaines pour cause d’inaccessibilité par an », annonce Jean de la Fayolle.

« Nous estimons que nous pouvons éviter 30 000 interventions vaines pour cause d’inaccessibilité par an ».

Vérifier les résultats d’un algorithme de correspondance

Le centre d’excellence IA Gen de GRDF applique une méthodologie similaire pour vérifier les résultats d’un algorithme « fuzzy match » devant rapprocher les données sur les clients du registre SIRET.

Ce système doit effectuer un « croisement multicritère syntaxique » entre 40 millions d’identités clients GRDF et 20 millions d’enregistrements SIRET toutes les semaines. Or, il arrive régulièrement que ce modèle n’arrive pas à relier une même entité nommée différemment entre les registres. « Nous avons fine-tuné un LLM afin d’identifier les correspondances correctes, incorrectes ou indéterminées. Il obtient un score de 91 % de précision de vérification de correspondance avec seulement 1 % de faux positifs. Cela est compliqué à faire avec un modèle NLP, cela réclame des centaines de règles métiers ».