5 décembre 2023
IA
Les Large Language Models (LLM) sont à l’avant-garde de l’adoption de l’IA dans de nombreux secteurs. Pour un usage en santé, il y a-t-il suffisamment de garanties légales et techniques pour assurer une utilisation adéquate et durable ?
Cet article tient compte des derniers documents de l’Organisation Mondiale de la Santé (OMS) (deux rapports de 2023), des éléments de proposition réglementaire européens par la Commission Européenne (CE) (AI Act et amendements, juin 2023) et s’appuiera sur la notion française de donnée de santé. Nous comparerons les versions de ces textes avec l’existant afin de détailler les failles des LLM pour les applications en santé en Europe et en France.
Les progrès réalisés dans le domaine du traitement du langage naturel (NLP) ont été exceptionnels au cours de l’année écoulée avec entre autres l’émergence des LLM (GPT-3.5, LLaMA13B, Mistral7B…). Cependant, un manque de réglementation et de discussion ouverte pourrait nuire gravement aux utilisateurs, aux entreprises et à l’adoption de la technologie en santé. La réglementation est en cours d’élaboration avec la première version de l’AI Act qui devrait sortir dans les prochains jours. À partir des éléments disponibles, il est utile d’émettre un premier constat.
Par cet article, nous souhaitons partager notre opinion et ouvrir un débat avec l’ensemble des acteurs, et plus particulièrement avec le régulateur français. Nous illustrerons nos propos à travers certains cas d’usage. La plupart des exemples s’appliquent à tous les LLM, quelle qu’en soit la taille ou la licence.
Cet article exprime l’opinion de Nuvocare concernant les derniers développements des LLM (Large Language Models) et leur application dans le domaine de la santé. Il s’appuie sur des documents publiés par l’OMS, la CE et la législation française.
Les éléments de travail réglementaire produits jusqu’ici par les institutions publiques indiquent que les LLM en santé seront très prochainement soumis à un contrôle renforcé. Les institutions publiques expriment des attentes sur plusieurs critères (transparence, gouvernance, respect, contrôle…). Chaque pays déclinera les textes de lois selon son cadre juridique, en se basant sur les consignes internationales existantes. En France, l’AI Act fera foi et nous pouvons nous appuyer sur ses avancées pour analyser la conformité actuelle.
D’après notre analyse, les entreprises qui développent et vendent des LLM et leurs applications sous-jacentes pour la santé ne répondent pas de manière satisfaisante aux attentes de transparence, de qualité, de contrôle et de gouvernance énumérées par ces institutions publiques. En fonction de ces attentes, nous constatons que les garanties de sécurité mises en place sont faibles et que de nombreuses entreprises ne font pas suffisamment d’efforts pour connaître et évaluer leurs données d’entrainement, de test et collectées lors du déploiement.
Cette non-conformité peut être expliquée par une limitation technologique. Expliquer un modèle, ses résultats ou analyser précisément ses jeux de données textuelles est difficile en raison d’un manque d’outils. Il n’y a pas de protocoles d’évaluation communs définis et certifiés aujourd’hui.
Nous rappelons à une concertation collective Française qui rassemblerait davantage de profils techniques, médicaux, juridiques et administratifs pour agir avec pertinence en tant que régulateur continu à une échelle nationale.
Nous reconnaissons que les LLM et les applications associées ont la possibilité d’améliorer significativement l’efficacité du secteur de la santé. Nous alertons sur les possibles conséquences négatives importantes des modèles et solutions non réglementées (contenu faux, inégalité d’accès aux soins, discrimination, mauvais usage et perte de confiance des patients et du personnel médical).
Si vous êtes déjà familier avec le NLP et les LLM, vous pouvez directement passer à la partie suivante.
Une façon de comprendre le mot LLM est de le lire à l’envers.
En « Machine Learning » (Apprentissage automatique), nous désignons un modèle comme un programme apprenant des règles à partir d’une entrée pour produire une sortie. Cette procédure est appelée “apprentissage statistique”. Un modèle est quelque chose qui, après avoir vu un certain nombre de paires entrée-sortie, est capable de prédire une valeur pour une nouvelle entrée (prédire le poids à partir d’une taille, les ventes à partir de l’affluence…).
Langage fait référence au fait que ce modèle est spécifiquement conçu pour avoir des mots en entrée et/ou en sortie. Ce modèle traite les données textuelles.
Large fait référence à la taille du modèle (le nombre de paramètres ajustables). Celle-ci est très importante pour permettre de prédire des mots les uns après les autres. Pour réaliser cette performance, il faut avoir appris sur un énorme ensemble de données textuelles.
Si vous souhaitez en savoir plus, j’ai répertorié des ressources utiles en bas de la page pour comprendre le fonctionnement des LLM.
Les LLM ne sont pas des chatbots. Un chatbot est le moyen le plus courant, efficace et convivial de créer une interaction entre les humains et les machines. C’est une interface où un utilisateur peut écrire du texte et obtenir une réponse du modèle. Aujourd’hui, le plus célèbre est ChatGPT, mais beaucoup d’autres existent (HuggingChat, Bard, Claude…). Aujourd’hui, la plupart des chatbots utilisent un LLM comme moteur pour fournir des réponses aux requêtes. Auparavant, les chatbots se basaient plutôt sur la détection de mots et des arbres de possibilités, souvent produisant de mauvais résultats car très limités.
Une astuce utilisée pour rendre les LLM plus adaptés à la discussion est le RLHF (Reinforcement Learning with Human Feedback). L’idée est d’apprendre “doucement” (fine-tune) au modèle à préférer certains types de réponses par rapport à d’autres (comment expliquer davantage, adopter un ton différent, insister sur ceci ou cela…).
Un LLM est un modèle puissant de Deep-Learning qui a appris la structure du langage à partir de millions de documents et peut discuter via un chatbot.
La santé est un domaine d’application de l’IA. Par exemple, les algorithmes de vision par ordinateur ont été adoptés par les radiologues pour être plus précis et plus rapides dans l’analyse des images. L’OMS « reconnaît le potentiel de l’IA pour améliorer les résultats de santé en renforçant les essais cliniques ; en améliorant le diagnostic médical, le traitement, les soins autogérés et centrés sur la personne ; et en complétant les connaissances, les compétences et les capacités des professionnels de la santé » (Considérations réglementaires sur l’intelligence artificielle pour la santé, OMS, Octobre 2023).
Maintenant que nous atteignons un point où le traitement et la génération de texte sont accessibles et précis, plusieurs façons de l’utiliser sont à l’étude. Nuvocare se focalise sur deux cas d’utilisation :
Pour répondre aux enjeux, les entreprises et les chercheurs ont déjà commencé à produire des LLM pour la santé. Google a publié MedPaLM (v1 et v2), qui sont des LLM entièrement dédiés aux questions cliniques et médicales. HuggingFace héberge de nombreux modèles qui ont une portée médicale, prouvant qu’un mouvement open-source est lancé avec des ensembles de données et des modèles accessibles. Ainsi, le secteur de la santé commence à disposer d’outils spécialisés pour le faire.
Il y a aussi les LLM « généralistes », c’est-à-dire des modèles qui sont entraînés sur tout (qu’il s’agisse de sujets médicaux ou non). Par exemple, il est possible d’utiliser GPT 3.5 (le modèle derrière ChatGPT) pour demander un avis sur des symptômes ou bien un traitement. Il est alors difficile de déterminer où se situe la frontière entre les utilisations médicales et les utilisations courantes car bon nombre des modèles actuels tentent de relever de nombreux défis en même temps (programmation, rédaction, analyse d’images…). Cela soulève de sérieuses préoccupations quant à la capacité du modèle à fournir des réponses pertinentes pour la santé.
Une façon de relever ce défi (partiellement) est d’utiliser la génération augmentée par recherche (RAG). Cette méthode utilise un système de requête intermédiaire pour fournir aux LLM des éléments sérieux et fiables sur lesquels se baser pour répondre. Le LLM reçoit une question et des aides pour prédire une réponse finale et claire. Là encore l’usage est délicat car la notion de pertinence et la qualité de la base documentaire sont sensibles.
Aujourd’hui, les modèles accessibles librement peuvent être utilisés pour ces usages. Les entreprises qui les ont développés sont conscientes d’un certain risque associé pour les sujets médicaux. Qu’il s’agisse d’un modèle spécialisé, généraliste ou intégré à un système RAG, elles se protègent alors par les Conditions d’utilisation.
Celles-ci sont essentielles pour garantir la sécurité de l’utilisation de cet outil d’IA. Mais elle laisse transparaitre une certaine ambiguïté et une décharge de la responsabilité. Par exemple, les conditions d’utilisation d’OpenAI spécifient que personne ne doit utiliser le contenu généré pour des questions liées à la santé. Mais en réalité, il est toujours possible de poser des questions et obtenir une réponse concernant une maladie, des symptômes… Bien que l’utilisation du contenu soit prohibée, la génération n’est pas interdite ou empêchée.
Ainsi, toute personne ayant accès à un API, à un Chatbot ou à un LLM peut l’utiliser pour générer du contenu à usage médicale. Cela peut être fait sans avoir de compétences techniques particulières car de nombreuses applications sont accessibles uniquement avec une simple connexion internet. L’utilisation actuelle des LLM en santé n’est ni sûre ni contrôlée.
Le cadre juridique autour de l’IA s’est construit avec une certaine latence (début des travaux en 2021) même si un effort significatif a été déployé en 2023. Les propositions actuelles se précisent, en particulier autour des modèles « fondations ».
Notre analyse repose principalement sur 4 documents :
Dans son dernier rapport, l’OMS promeut des principes fondamentaux afin de réglementer l’utilisation de l’IA en santé. Les six axes sont tous pertinents. Cependant, trois d’entre eux sont particulièrement liés aux cas d’usage présentés plus haut :
La documentation et la transparence exigent des développeurs et des entreprises de détailler et de spécifier le but médical prévu et l’approche utilisée dans des documents accessibles. Il s’agit d’un résumé de la phase de développement et d’une justification des décisions prises concernant les paramètres, les ensembles de données, les mesures d’évaluation… En particulier, il y a une exigence sur l’analyse profonde et complète des données relatives au modèle et son utilisation.
La validation analytique et clinique est essentielle lors de la création de tout modèle d’IA en santé. Par exemple, la création d’un modèle qui prédit la probabilité d’avoir un cancer de la peau nécessite de le tester. À partir de ces tests, il est possible d’extraire des statistiques prouvant la performance plus ou moins bonne du modèle dans cette tâche. Associées à des seuils de sécurité, ces statistiques nous permettent d’accepter ou de rejeter un modèle candidat. Les LLM ne sont pas exempts de cette étape cruciale.
La confidentialité et la protection des données sont des exigences visant à obliger les acteurs à se conformer aux règles de juridiction sur les données personnelles et la confidentialité. L’évaluation de cet élément doit être effectuée dès la phase de développement afin d’anticiper la conformité et les risques.
Ces points clés sont également essentiels dans l’acte de la CE sur l’IA. En général, il est attendu des développeurs et des entreprises qu’ils construisent des modèles et solutions transparentes, valides et respectueuses.
La CE définit un « système à haut risque » comme « un système qui crée un risque élevé pour la santé et la sécurité ou les droits fondamentaux des personnes physiques » (Titre III). Pour catégoriser comme tel, le régulateur se base sur l’utilisation prévue du modèle. La CE propose une première liste d’utilisations classées comme à “haut risque”, mais pouvant être modifiée ultérieurement (Annexe III AI Act).
Au départ la liste était relativement courte et manquait de clarté car seule une partie des applications potentiellement à haut risque y étaient détaillées. Il n’y figurait pas uniquement les applications en santé mais aussi d’autres sujets sensibles (justice, éducation, sécurité…). Une série d’amendements est venu préciser que l’usage de l’IA pour la santé constitue un motif pour être catégorisé comme système à « haut risque ». Aujourd’hui, les LLM seuls ne sont pas encore clairement affectés dans cette catégorie.
Les systèmes à « haut risque » nécessitent des efforts importants en matière de transparence, de qualité, de contrôle et de conformité. Les attentes de la CE sont très similaires à celles de l’OMS. Elles mettent un accent particulier sur la collaboration avec les autorités compétentes et sur la notification proactive des défaillances potentielles. De plus, il est attendu des entreprises qu’elles conçoivent un système de gestion des risques en effectuant une analyse approfondie.
La CE définit un cadre plus strict en réaffirmant les mêmes principes que l’OMS. La qualification de « haut risque » signifie un niveau de sécurité et de conformité plus élevée dans la conception du système. C’est aussi une mise en garde pour les acteurs travaillant sur cette typologie d’utilisation.
Les deux organisations, l’OMS et la CE, insistent sur la nécessité de documenter les ensembles de données utilisés pour entrainer le modèle, le tester et tout au long de son déploiement. Cette documentation devrait contenir :
Ce document est également essentiel lors de l’évaluation des performances du modèle sur l’ensemble de test, l’ensemble de validation et lors de son déploiement. Il permet aussi de relativiser sa pertinence par rapport à des benchmarks clairs.
La représentativité des langues dans les données est extrêmement importante pour la santé. Les performances des modèles dans différentes langues sont étroitement liées à la capacité des développeurs à collecter suffisamment de données. Si le modèle se comporte différemment en fonction des langues d’entrée, cela devrait être signalé tôt pour éviter une mauvaise utilisation. Le risque d’inégalité d’accès et d’utilisation est accru.
Un autre élément concerne les biais liés aux noms, aux genres et aux origines. Les données utilisées pour construire les LLM proviennent d’Internet et de sources privées qui peuvent contenir des données biaisées. Un examen approfondi de ces biais devrait être effectué pour déterminer si un LLM a été entraîné avec un biais et comment le corriger. Là aussi, un risque de discrimination peut survenir.
Enfin, un schéma approprié de gouvernance des données est requis. Cette règle est particulièrement importante pour le contenu généré par le modèle. Les contenus générés, les questions et l’ensemble de la discussion peuvent contenir des informations très sensibles, qui doivent être stockées de manière sûre et responsable. Il s’agit alors de prévenir les fuites de données et autres possibles « hacks ».
Ces règles sont aussi valables pour les applications reposant sur le RAG. La base de données documentaires pour justifier la réponse est-elle biaisée ? Est-elle en une seule langue ?
La base réglementaire de la CE date de 2021, et a depuis subi différentes modifications. Les LLM étant une technologie ayant connu un essor en fin 2022, plusieurs amendements ont été ajoutés en juin 2023 pour définir un périmètre autour de cette typologie de modèle. Le premier bloc étant difficilement transposable à ces modèles dits « généralistes ».
Dans son amendement, le Conseil Européen définit un modèle de « fondation » (comme les LLM) comme : « un grand modèle d’IA entrainé à partir d’une grande quantité de données, capable d’exécuter avec compétence un large éventail de tâches spécifiques, y compris, par exemple, la production de vidéos, de textes, d’images, la conversation en langage latéral, l’informatique ou la production de code informatique ».
Selon le Conseil Européen, le terme « IA à but général » correspond à un système qui « peut être basé sur un modèle d’IA, peut inclure des composants supplémentaires tels que des logiciels traditionnels et, par le biais d’une interface utilisateur, a la capacité de servir une variété d’objectifs, à la fois pour une utilisation directe et pour l’intégration dans d’autres systèmes d’IA ».
Dans ces amendements, un besoin de transparence et conformité est détaillé (amendement 100, 101 et 102). Mais il est précisé que les LLM en général ne sont pas systématiquement des systèmes à haut-risque puisque la possibilité de buts d’utilisation est très (trop ?) vaste. Réguler les LLM au global est un sujet extrêmement complexe puisque la régulation fait face à de grandes réticences (particulièrement exprimées par l’Allemagne, la France et l’Italie). « Sur-réguler » le secteur mettrait les entreprises européennes en position de faiblesse par rapport aux acteurs américains, qui ont une plus grande marge de manœuvre. En date du 30 Novembre 2023, il n’est pas clair dans quelle mesure la première version de l’AI Act est contraignante à ce sujet, les discussions étant en cours et soumise à diverses influences privées.
Dans le cadre de la santé, les amendements de Juin 2023 catégorisent clairement les usages en santé comme à « haut risque » (amendement 721). Il est clair que, quel que soit le modèle utilisé, la santé est un champ où un contrôle renforcé sera effectué. Le fait que les LLM soient intrinsèquement considérés comme candidat à la labellisation de système à « haut risque » ajoute une seconde couche de vigilance sur leurs usages en santé. Des attentes de transparence, sécurité et gouvernance sont à respecter.
Le bloc initial des propositions de réglementation était très généraliste. Malgré les amendements de juin 2023 spécifiant la notion de modèle « fondation » et le cas d’usage en santé, nous pouvons nous attendre à de progressives mises à jour puisque le secteur évolue rapidement. Avec les éléments à disposition, nous pouvons déjà estimer à quel point le secteur est loin d’un niveau de conformité satisfaisant puisque les LLM pour un usage en santé sont des systèmes avec de haut risques.
Les plus grandes lacunes identifiées sont les suivantes :
Ces remarques s’appliquent aux entreprises développant des LLM ainsi qu’à celles construisant des solutions autour de ces derniers.
En peu de temps, de nombreux modèles ont été construits par différents acteurs et avec différents degrés de transparence concernant le modèle lui-même ou ses données. Les applications/solutions se basant sur ces modèles ont également grandi rapidement. On note une différence de philosophie chez les entreprises dans l’accessibilité qu’elles offrent (open-source vs privé). Cette différence viendra aussi questionner le secteur de la santé pour savoir avec quel type d’acteurs elle souhaitera travailler.
Un exemple parlant est GPT4, le dernier modèle d’OpenAI qui est accessible via ChatGPT avec un compte premium ou sur un API. La documentation technique est pauvre et ne fournit aucun détail sur l’architecture ou le jeu de données utilisé. Ce choix est justifié par des raisons de compétitivité et pourrait évoluer avec le temps. Néanmoins, seules des hypothèses existent aujourd’hui sur le fonctionnement de ce (ces ?) modèle(s). Ainsi, utiliser ce modèle comme base pour des applications de santé pose de sérieux problèmes de transparence et de maitrise.
D’autres modèles sont plus ou moins ouverts et disponibles publiquement. Meta et HuggingFace ont tous deux joué un rôle important dans la démocratisation de l’utilisation de LLM open-source et donc vérifiable. Les modèles LLaMa ou Mistral sont de bons exemples de LLM où l’architecture est connue, les choix techniques sont documentés et une compréhension relativement bonne est possible.
Cependant, tous les acteurs échouent à documenter clairement leurs données d’entrainement et de déploiement. Pour atteindre leurs performances actuelles, les LLM doivent être entraînés sur une énorme quantité de données textuelles, ce qui rend extrêmement difficile de cerner ce qu’il y a à l’intérieur et si ce sont des données sensibles. Les « milliards de tokens » vus par le modèle représentent une énorme masse d’informations (privées et publiques) sur laquelle peu de rapports de sécurité sont établis. Par rapport aux attentes de la réglementation, les LLM sont confrontés à un défi pour résumer et analyser leurs données de manière rigoureuse. Ce constat est encore plus cruel pour les modèles se basant sur des jeux de données privées dont nous ne savons rien.
La plupart des modèles sont évalués sur leurs performances dans différentes langues et leurs capacités à répondre correctement à un large éventail de questions (générales, avec ou sans contexte, par sujet…). Sur ces éléments, nous pouvons souligner que les acteurs du secteur ont déjà intégré ces considérations linguistiques.
La première vague d’utilisateurs sur le premier ChatGPT le prouve : de nombreuses astuces étaient possibles pour générer du contenu nocif et les réponses pouvaient rapidement devenir inexactes voire farfelues. De nombreuses corrections ont été nécessaires pour réguler et limiter le modèle.
Le problème est que, encore aujourd’hui, les LLM sont publiés sans réelles études sur les impacts potentiels et les risques associés à leur mauvais usage. Pour être utilisés dans le domaine de la santé, les développeurs doivent étudier davantage les impacts négatifs potentiels et les risques associés à l’utilisation de leurs modèles.
Par exemple, fournir des détails sur des informations incohérentes ou des erreurs de diagnostic/conseils dans nos cas d’usage. L’impact négatif à long terme peut être la perte de confiance des professionnels et des patients, jusqu’à l’erreur médicale grave.
Les modèles ne disposent pas de filtres pour les questions de santé. Il faut proscrire totalement la réponse des modèles à des questions de santé pour prévenir au maximum les risques. Seuls les modèles prouvant une pertinence à ce cas d’usage devraient être autorisés. Pour les requêtes contenant des informations sensibles, les entreprises doivent mettre en place un système de détection et le documenter pour prouver que les données de santé sont traitées de manière appropriée.
À l’intérieur des modèles eux-mêmes, il n’est pas facile de comprendre la modération pour ne pas générer de contenu nocif ou erroné. Pour contrer ce problème, de nombreux développeurs encouragent l’utilisation du RAG (Retrieval Augmented Generation) décrit plus haut. En fournissant un contexte pertinent pour répondre, le modèle a tendance à mieux performer et à être plus robuste. Mais cette réponse reste assujettie à la notion de pertinence et de qualité de la base documentaire. Il n’y a pas de réponse miracle aujourd’hui.
Dans leurs textes, tant l’OMS que la CE soulignent la nécessité de documenter les ensembles de données utilisés pour entrainer le modèle et durant son déploiement. Les notions de gouvernance et de conformité sont particulièrement importantes dans le contexte français des soins de santé. La juridiction française définit les données de santé comme : « des données relatives à la santé physique ou mentale, passée, présente ou future, d’une personne physique (y compris la prestation de services de santé) qui révèlent des informations sur l’état de santé de cette personne. » L’exemple le plus évident est d’avoir un tableau reliant les noms et les chirurgies ou les traitements subis.
Le problème est que les données textuelles sont souvent oubliées et sous- estimées dans le domaine de la santé. Cependant, elles peuvent aussi devenir des données de santé. Par exemple, quand quelqu’un demande un conseil ou une explication sur sa chirurgie et fournit un nom dans la requête au chatbot. En réalité, dans certains chatbots comme ChatGPT, il faut créer un compte avec un nom et un numéro de téléphone. Ces identifiants peuvent ensuite être utilisés pour déduire ou suivre les antécédents médicaux, car le développeur pourrait collecter toutes les questions liées à la santé en regardant les interactions passées. Par conséquent, les LLM et les chatbots peuvent être confrontés à des données sensibles lorsqu’ils sont sollicités par un utilisateur. Malgré ce constat, ils ne gèrent pas ces requêtes de manière appropriée.
Actuellement, les requêtes et les contenus générés sont stockés sur les serveurs des fournisseurs de LLM ou des sociétés qui les hébergent. Il y a une très forte probabilité que des données relevant de la définition des données de santé ne soient pas stockées et chiffrées comme cela est requis (en France on doit avoir la certification HDS par exemple).
Le pire étant qu’à long terme ces données sont utilisables pour devenir une base de ré entrainement. Les données sont donc collectées, stockées et traitées sans mettre en place une gouvernance adéquate (en tout cas au regard des attentes françaises).
Bien que des défauts évidents soient visibles dans la manière dont l’industrie construit et vend des produits liés aux LLM, atteindre le niveau approprié de conformité ne sera pas facile. Dans ce domaine où tout évolue rapidement, nous manquons d’outils techniques, de cadres et de voix pertinentes.
L’apprentissage profond est un domaine de recherche empirique et toujours en cours de développement. L’entraînement de modèles avec des milliards de paramètres est une pratique assez expérimentale. L’interprétation des paramètres et des résultats des modèles est difficile. Fournir un bon niveau de documentation des modèles pour les soins de santé est très délicat aujourd’hui pour plusieurs raisons.
L’interprétabilité de l’IA est un domaine de recherche qui progresse, mais toujours plus lentement que les domaines qui produisent les modèles. Notre capacité à comprendre les choix du modèle et pourquoi une telle phrase a été générée sera sûrement toujours en retard par rapport aux dernières architectures de modèles.
La sécurité de l’IA en est à ses débuts. Les LLM nous mettent au défi de trouver des astuces pour modérer leurs capacités génératives. Aujourd’hui, nous ne pouvons pas prétendre avoir une réponse globale à ce défi.
Le traitement, l’analyse et la synthèse de trillions de mots sont impossibles sans un grand sacrifice de temps et d’argent. Le traitement d’une telle quantité de données est extrêmement coûteux en termes de temps et d’argent. De plus, cela nécessiterait une méthodologie préalablement spécifiée validée par les régulateurs. Cela ajouterait une autre contrainte aux projets d’IA.
Les architectures actuelles des LLM sont brutes. Les LLM prédisent un mot à la fois. Nous ne contrôlons pas l’idée exprimée et les concepts que le modèle utilise. Les dernières rumeurs concernant Q* et les LLM structurés de manière différente pourraient apporter une nouvelle perspective à cette question. Cependant, à ce jour, les LLM ne sont que des prédicteurs autorégressifs. Ils prédisent un mot après l’autre sans offrir un contrôle sur leurs « idées ».
Lors de la construction et l’évaluation de modèles, les chercheurs ont besoin de références pour comparer les performances et s’améliorer. Même avec la dernière version de GAIA, les références sont assez généralistes. On note tout de même la présence de datasets comme MedQA, MedDialog, MedMCQA… Ces jeux de données sont limités à une poignée de langues et d’usages, pas forcément les nôtres.
Ce manque vient directement faillir à l’exigence de validité clinique et analytique édictée par la CE. Évaluer, oui, mais comment ? Aujourd’hui il est difficile de comparer les modèles entre eux sans ce socle commun. Ces benchmarks doivent donc venir structurer le développement des modèles et aussi faciliter leur représentativité qui fait cruellement défaut.
Tout d’abord, en termes de langues, la plupart des ensembles de données disponibles sont en anglais, comme le montre l’ensemble de données MedPalm et la majorité des jeux de données sur HuggingFace. La cause de cette situation est la difficulté de rendre publiques des ensembles de données en santé compte tenu de la sensibilité de certaines informations. Un possible manque d’échanges entraine aussi une relative lenteur. Cela nous amène à notre dernier point, nous ne collaborons pas suffisamment et à une échelle suffisamment grande.
Les LLM et leurs applications sont maintenant poussés par de grandes entreprises qui construisent des modèles généralistes. Ces modèles peuvent ensuite être déclinés sur des sujets spécifiques (MedPalm ou BloombergGPT). Cependant, la capacité de l’industrie à concevoir des modèles adaptés dépend de la volonté de collaboration des acteurs de la santé et du régulateur.
Aujourd’hui, les écarts constatés entre les réglementations, les modèles et leurs utilisations devraient déclencher une alarme pour créer une structure mixte en charge de :
Une telle procédure conduira probablement à un besoin d’acteurs spécialisés et spécifiques à chaque pays, car les attentes des réglementations peuvent différer selon les industries et les régions. Selon nous, c’est une option qui permettrait de garantir un déploiement sûr et durable des dernières avancées IA en santé en France.
Mieux informer,
mieux soigner