Marc 00:00:00 – 00:00:13 : Aujourd’hui, je reçois Samuel Humeau, Lead Machine Learning chez Nabla. Nabla est une start-up française qui construit un outil pour les médecins qui les aide à rédiger leurs documentations. Ils viennent de lever une série B et sont 35, basée à Paris. Bonjour Samuel. 

 

Samuel 00:00:13 – 00:00:14 : Bonjour Marc. 

 

Marc 00:00:14 – 00:00:18 : Alors Samuel, est-ce que tu peux nous parler un petit peu plus de Nabla? ? 

 

Samuel 00:00:18 – 00:01:06 : Oui, donc comme tu l’as dit, Nabla est une startup française. Nabla fait un outil qui s’appelle aussi Nabla et qui est un assistant pour les médecins. In fine, Nabla cherche à aider les médecins dans toutes leurs tâches, mais actuellement, on se focalise sur une tâche en particulier qui est les aider à faire leur documentation médicale. La documentation médicale, c’est tout ce que le médecin rédige pendant une consultation avec un patient ou après, selon le temps. rédige ou entre dans le logiciel médecin. Et plus précisément, du coup, Nabla écoute ce que le médecin a dit à son patient et essaie de pré-mâcher le travail ou de le faire en entier. C’est ce qu’on appelle un ambiance scribe, un scribe ambiant, j’imagine, en français. 

 

Marc 00:01:06 – 00:01:08 : Alors, quel était le constat sur le besoin ? 

 

Samuel 00:01:08 – 00:03:12 : Donc Nabla a eu une vie passée où elle était une clinique en ligne spécialisée dans la santé des femmes. Donc on avait une équipe médicale et initialement à cette époque, notre but était de créer un business model où on aurait des patients qui auraient accès à leur médecine en ligne avec une équipe médicale qui était chez nous. Et on s’est intéressé à comment optimiser les process à ce moment-là parce que pour mettre à l’échelle ce business model, on avait besoin d’être efficace. Et il s’est trouvé que la documentation médicale, donc renseigner tout ce que le patient a dit, écrire le diagnostic, tout ce qu’on a appris dans le logiciel patient prenait énormément de temps. C’est assez intuitif, je pense. Si tu vas chez le médecin, tu constateras qu’il passe son temps à écrire sans forcément te regarder dans les yeux. Nous, on essaie de rendre ça quasi automatique. On n’invente rien, mais on capte ce que le médecin dit et on fait en sorte qu’il n’ait pas besoin ni de le taper, ni de le renseigner de quelconque manière que ce soit. Un peu plus tard, on s’est aperçu que si le besoin existait en France, qui est un environnement où les médecins sont quand même sous la pression du temps, le besoin était encore plus présent aux États-Unis. Parce que là-bas, documenter ce qui s’est passé dans une consultation est un besoin légal. D’accord. Parce que le médecin justifie… à l’assurance maladie, pourquoi l’assurance maladie devrait payer ce qu’elle paye. L’assurance maladie peut créer des poursuites légales. Donc les médecins passent énormément de temps à documenter leur interaction avec le patient, leur diagnostic, leur conclusion, plusieurs heures par jour. Et actuellement, il y a 60% des médecins aux US qui estiment être en burn-out ou ont des signes de burn-out. Donc Nabla, après avoir constaté ça, est en train d’essayer de conquérir le marché US. On est principalement basé aux US d’ailleurs. 

 

Marc 00:03:12 – 00:03:14 : Alors quel genre de données vous traitez ? 

 

Samuel 00:03:14 – 00:04:31 : Comme je l’ai dit, Nabla écoute ce que le médecin dit à son patient. Donc on traite de l’audio en entrée. Et en sortie, on crée une documentation médicale qui, pour le coup, est un mélange de textes. Car une documentation médicale, certaines parties sont du texte. Par exemple, l’histoire de la maladie, qui est quelque chose que le médecin va remplir, et un résumé, un texte, qui relate ce que le patient a dit, quels symptômes il exposait, toute l’histoire de la consultation jusqu’aux conclusions du médecin, on va dire. Oui. mais aussi des choses qui ne sont pas du texte libre, qui sont structurées. Par exemple, si le médecin renseigne le poids, ce n’est pas du texte libre, c’est un champ structuré. Ce qui est particulièrement un pain point pour les médecins aux US, c’est tout ce qui est le diagnostic. Aux États-Unis, quand un médecin dit « Ok, voici mes conclusions, il y a tel diagnostic, tel diagnostic, telle condition, telle condition », Il choisit parmi 74 000 entrées d’une taxonomie standard. On sent la difficulté de choisir bien parmi ces 74 000 entrées. En France, il y a une version plus light de ce système qui a quand même une dizaine de milliers d’entrées. 

 

Marc 00:04:31 – 00:04:37 : Vos applications de machine learning, si on prend tout le pipe de traitement de la donnée, quelles sont-elles ? 

 

Samuel 00:04:37 – 00:05:21 : À haut niveau, du coup, là, le produit actuel prend en entrée de l’audio et sort du texte et des données structurées. On split le problème en plusieurs phases. On va d’abord extraire le transcript de la conversation. OK. Donc on a une partie speech to text. Et on a également une partie texte vers texte pour toutes les parties qui s’apparentent à du résumé. On peut le voir comme une double tâche de résumé et de traduction en langage médecin et pas profane. Et on a aussi tout ce qui est structuration, tout ce qui est codification, qui est quasiment une tâche en soi, structuration de texte. Oui, oui, oui. 

 

Marc 00:05:22 – 00:05:39 : Sur la première speech-to-texte, comment ça se décompose à son tour en sous-algorithme ? On connaît Whisper qui permet de traduire la voix d’une personne en texte. Est-ce que ça suffit ? Est-ce que vous avez besoin de plus ? 

 

Samuel 00:05:39 – 00:07:12 : Alors, il y a plusieurs choses. Est-ce que juste le transcript des mots suffit ? Ou est-ce que, par exemple, il faut capter qui est en train de parler, donc la diarisation, quel est le sentiment de la personne, est-ce qu’elle a une voix chevrotante, ce genre de choses ? On peut aller très loin en ne considérant que le texte. Ça ne suffit pas en général, parce qu’on a des consultations avec plusieurs patients qui parlent en même temps. Des fois, le docteur va mentionner ses propres problèmes de santé. Donc la diarisation est quelque chose sur lequel on travaille, mais on peut aller déjà très très loin avec un speech-to-texte. maintenant tu prenais l’exemple de Whisper. quelqu’un pourrait faire une ébauche de ce que fait Nabla assez rapidement en mettant bout à bout par exemple Whisper et un LLM grand public d’ailleurs c’est une question d’entretien que j’aime bien. comment tu ferais pour faire une ébauche de ce que fait Nabla en une après-midi ? Mais tu ne pourras pas obtenir un système que tu peux vendre facilement. Si je prends l’exemple de Whisper, par exemple, Whisper est assez mauvais sur tous les termes médicaux. Quand je dis termes médicaux, c’est l’anatomie, les médicaments, particulièrement les nouveaux médicaments, des conditions médicales. Ce genre de termes qui sont très importants pour faire la documentation médicale. Et donc, si on fait un système qui est basé juste sur une transcription Whisper, on va vite se heurter au fait que les termes médicaux ne sont pas compris du tout. 

 

Marc 00:07:12 – 00:07:37 : Ça, justement, c’est un problème que j’ai vu plusieurs fois en mission dans le cadre d’accompagnement client. Le fait de développer un speech-to-texte qui puisse comprendre plein de termes spécifiques, pas que médicaux. Comment est-ce qu’on va chercher ce manque de performance sur ce vocabulaire spécifique ? Comment est-ce qu’on obtient un speech to text performant sur des mots qu’on ajouterait au vocabulaire d’une certaine façon ? 

 

Samuel 00:07:37 – 00:08:47 : Donc à Nabla, c’est un problème qu’on a taclé depuis pas mal de temps. Parce que déjà, à l’époque où Nabla était une clinique de santé, on avait une brique de speech-to-texte parce qu’on avait des consultations en ligne. Et donc, à cette époque-là, on a commencé à enregistrer des consultations médicales. On avait des médecins partenaires et des patients consentants. D’ailleurs, pour la petite histoire, le formulaire de consentement était écrit en taille 18 et faisait cinq phrases complètes. Et une écrasante majorité des patients étaient tout à fait d’accord, d’ailleurs, pour donner leur consentement à ce qu’on utilise cet audio à des fins de recherche. On a réuni, du coup, une centaine, plusieurs centaines d’heures d’audio médical enregistrés en consultation. Et notre première version du speech-to-texte était un whisper qui venait de sortir, qui avait été fine-tuné sur ces conversations médicales. Il s’est trouvé qu’il était bien meilleur à reconnaître tous les termes utilisés couramment en médecine. Et un peu plus tard, il y a eu des versions beaucoup plus complètes de ce dataset et de ce système qui percevait tous les termes. 

 

Marc 00:08:48 – 00:08:54 : D’accord, donc votre solution, ça a été de fine-tuner sur des conversations médicales. Oui. Et ça a bien fonctionné. 

 

Samuel 00:08:54 – 00:09:07 : Ça fonctionne très bien. Là où Whisper et Azure Speech-to-Text, je parle d’Azure parce que sur nos benchmarks, c’est Azure qui fait le moins d’erreurs sur les termes médicaux. 

 

Marc 00:09:07 – 00:09:12 : Il y a Whisper V3 sur votre benchmark ou pas ? Oui. Parce qu’il est assez récent, donc je ne sais pas. 

 

Samuel 00:09:12 – 00:09:20 : Il est assez récent, mais les deux font, sur nos benchmarks, 18% d’erreurs sur les termes médicaux en anglais. 

 

Marc 00:09:20 – 00:09:22 : Les deux, Azure et Whisper V3 ? 

 

Samuel 00:09:22 – 00:09:36 : Oui, ils sont proches. C’est 18 et 19. Je ne vais peut-être pas m’aventurer dans les chiffres très précisément. En français, ces systèmes sont probablement entraînés sur un peu moins de français, donc l’erreur est plus haute. Notre système fait deux à trois fois moins d’erreurs sur les termes médicaux. 

 

Marc 00:09:36 – 00:10:04 : Super intéressant. Et alors, un autre problème qui revient beaucoup quand on travaille avec de l’audio, sur la diarisation, qui est nettement… Je ne sais pas ce que tu en penses. Moi, je trouve nettement plus difficile que le speech-to-texte. Comment est-ce que vous gérez l’aspect conversationnel, comme tu disais, le fait que deux personnes parlent en même temps ? Et puis, quelle est la base de départ ? Est-ce que tu peux nous partager un bon point de départ pour faire de la diarisation, comme on a Whisper en termes de speech-to-texte ? 

 

Samuel 00:10:04 – 00:11:07 : Je ne vais pas trop m’aventurer là-dessus parce que c’est actuellement un problème sur lequel on travaille activement à Nabla. Je ne vais pas m’aventurer à donner des solutions. On a en tout cas un dataset de conversation médicale diarisée qui semble être un bon point de départ. Et c’est un sujet sur lequel on travaille actuellement. On est plutôt aidé dans cette tâche par deux choses. Le premier, c’est que la grande majorité de nos conversations sont un médecin qui parle à un patient. Et c’est un problème où le contexte permet de savoir assez facilement qui parle, puisque généralement, celui qui expose ses problèmes de santé, c’est le patient. Celui qui prescrit des médicaments, c’est le docteur. C’est assez rare que ça aille dans l’autre sens. Et quand on ne sait pas qui est en train de parler, souvent c’est que la conversation n’est pas médicale, parce qu’ils sont en train de parler de tout et de rien. Donc pour les cas les plus courants, on est aidé par le fait que la diarisation a une importance moindre. 

 

Marc 00:11:07 – 00:11:08 : Ok. 

 

Samuel 00:11:09 – 00:11:28 : On est aussi aidé sur le fait qu’une partie de nos consultations, des consultations qu’on traite à Nabla, se fait en ligne ou auquel cas on se branche sur le système vidéo. Et du coup, on sait, enfin, on a le flux audio d’un côté du patient, on a le flux audio du docteur et la diarisation du coup est donnée pour toutes les consultations. 

 

Marc 00:11:28 – 00:11:32 : Vous avez deux, d’accord. Oui, parce que c’est de la visio en fait, la visioconférence la plupart du temps. 

 

Samuel 00:11:33 – 00:11:42 : Non, alors la plupart de nos consultations maintenant sont faites sur place avec quelqu’un qui utilise son iPhone comme un micro dans le cabinet, un docteur. 

 

Marc 00:11:42 – 00:11:43 : Donc là, il y a une seule source ? 

 

Samuel 00:11:43 – 00:11:57 : Là, il y a une seule source, mais on a une part substantielle de téléconsultation via une extension Chrome. Et là-dessus, du coup, on dispose des deux flux entrant et sortant. Et du coup, la diarisation est donnée. Bien sûr. 

 

Marc 00:11:57 – 00:12:03 : Et ça peut même vous servir de dataset pour entraîner une diarisation monoflux, quoi ? 

 

Samuel 00:12:03 – 00:13:44 : Oui, alors dans une certaine mesure, parce qu’à Nabla, on n’enregistre par défaut aucune donnée. C’est un choix que Nabla a fait. À un moment, Nabla avait le choix entre enregistrer tout ou n’enregistrer rien. La première solution, intuitivement, on sent que c’est intéressant pour avoir de meilleurs modèles assez rapidement. Mais la seconde possibilité nous permettait d’arriver plus rapidement sur le marché, de convaincre plus facilement les docteurs de nous faire confiance si on n’enregistrait pas leurs données, de convaincre plus facilement des grands groupes hospitaliers de nous faire confiance, en allégeant notamment tous les procédés de vérification de comment on traite les données. Du coup, on est allé plutôt vers cette seconde solution, mais via une tierce voie qui est que, par défaut, on n’enregistre rien. Et on autorise, pour les organisations qui sont OK avec ça, les médecins à partager le transcript et la documentation qu’on génère avec nous, s’ils le veulent et s’ils ont le consentement de leurs patients. Hum. Ça, ça permet concrètement aux médecins de nous montrer quand il y a des problèmes dans l’outil. C’est un mécanisme de feedback. Ça nous permet d’améliorer l’outil. Pour les organisations qui le souhaitent, ça nous permet de réentraîner nos modèles. Mais du coup, c’est la donnée qu’on acquiert est cantonnée à ce mécanisme de feedback. Donc quand tu disais, ça peut nous permettre d’accumuler un dataset, oui, juste dans la mesure où médecins et patients ont consenti à nous donner cette donnée. 

 

Marc 00:13:45 – 00:14:06 : Sur la deuxième partie, la diarisation est faite, vous avez un transcript de consultation. Cette deuxième partie, c’est extraire de ce transcript des informations clés pour la consultation. Tu nous parlais du poids, par exemple. Qu’est-ce que vous cherchez à extraire et quelles sont les technologies que vous utilisez pour le faire ? 

 

Samuel 00:14:06 – 00:14:51 : Il y a deux parties. Il y a une partie structurée, tout ce qui est constante vitale, observation, poids à la taille, rythme cardiaque, toutes les observations usuelles. Également, particulièrement pour les US, quels sont les codes de diagnostic ? Quels sont les problèmes de santé que le patient rencontre ? Le tout doit être projeté dans ces taxonomies duquel je parlais. Donc ça, c’est ce qu’on appelle du coding médical. Particulièrement pour cette dernière partie, il se trouve que les LLM du commerce, donc GPT-4 par exemple, de quelque manière, on lui pose la question, sont assez mauvais. D’ailleurs, il y a eu un papier il y a trois jours du New England Journal of Medicine qui appuyait ça. 

 

Marc 00:14:51 – 00:14:55 : Ils extraient mal les taxonomies médicales d’une conversation ? 

 

Samuel 00:14:55 – 00:15:57 : Oui, il y a plusieurs problèmes là-dessus. D’abord, ces taxonomies sont gigantesques. On ne peut pas facilement juste balancer la taxonomie tout entière dans le contexte. On est obligé de faire du retrieval augmented generation ou d’entraîner directement notre modèle à avoir cette taxonomie en tête, à connaître cette taxonomie. Nous, on a choisi la seconde voie. On a fait des essais avec du Retrival Augmented Generation basé sur GPT-4 qui n’ont pas été très concluants non plus. Du coup, pour toute la partie codification, on a demandé à des équipes professionnelles, dont c’est le travail actuellement qui existe aux US, d’annoter pour nous plusieurs milliers d’exemples de comment ils codifieraient ces conversations médicales. Et actuellement, notre système se base sur un fine-tuning d’un modèle génératif, actuellement en production c’est Phi2, entraîné à générer token par token cette codification. 

 

Marc 00:15:57 – 00:16:23 : Ok, vous avez fine-tuné un LLM sur de la codification médicale pour votre tâche. Ok, ça c’est hyper intéressant parce que c’est extrêmement rare de fine-tuner des LLM. aujourd’hui, on entend beaucoup de cas d’usage de RAG. de retrieval augmented generation, mais très peu de fine tuning. Donc, je pense que ça vaut le coup de creuser un petit peu le sujet. De quelle taille de modèle on parle et de quelle taille de dataset on parle ? 

 

Samuel 00:16:23 – 00:16:58 : Je vais commencer par le dataset. Le dataset comporte plusieurs milliers d’exemples de couples, conversations vers la codification finale. La codification sont ces codes d’une taxonomie qui s’appelle ICD-10, d’ailleurs je ne sais pas si je l’ai mentionné, qui correspondent à des problèmes médicaux ou aux diagnostics que le médecin produit. Tant qu’à faire, on a inclus aussi toutes les constantes vitales ou tout ce qui est codifié, de façon à avoir qu’un seul modèle qui fait toute la codification d’un coup. Donc plusieurs milliers de couples, conversation, codification finale. 

 

Marc 00:16:58 – 00:17:05 : Oui, la tâche, c’est générer l’extraction. La tâche, c’est à partir de l’input qui est la conversation, générer l’extraction. 

 

Samuel 00:17:07 – 00:17:40 : D’ailleurs, je vais peut-être y revenir plus tard, mais la beauté d’utiliser des modèles génératifs et particulièrement fine-tunés, c’est qu’on peut obtenir directement une sortie cohérente. Littéralement, on obtient directement un JSON de sortie qu’on peut utiliser. Pour le modèle, actuellement en production, on se base sur un modèle open source qui s’appelle Phi 2, qui avait été entraîné par Microsoft. Actuellement, il y a quelques jours, ils ont sorti une nouvelle version qui s’appelle Phi 3. Je vous laisse deviner ce qu’on est en train de faire actuellement. 

 

Marc 00:17:40 – 00:17:42 : C’est spécialisé au domaine médical ? 

 

Samuel 00:17:42 – 00:18:12 : Non, pas du tout. Il est très généraliste, mais en le fine-tuning sur cette tâche, il apprend très vite la taxonomie. On augmente également, donc on a ces milliers de couples, conversations vers codification, qu’on augmente également avec des variations. Donc on fait de la data augmentation pour augmenter un peu la taille de ce dataset. Ouais. Et pour le fine-tuning, on se base sur des techniques, LORA, qui permettent de fine-tuner à moindre coût, on va dire, ce genre de modèle. 

 

Marc 00:18:12 – 00:18:19 : Oui, restreindre le champ des possibles, restreindre la dimensionnalité de ce qu’on apprend pour pouvoir le faire sur un dataset plus petit, finalement. 

 

Samuel 00:18:19 – 00:19:04 : Oui. Pourquoi on a choisi Phi 2 et pas un modèle plus gros ? On a fait des essais avec des modèles plus gros, des modèles à 7 milliards de paramètres, comme Mistral 7B par exemple, ou plus gros. Actuellement, on a choisi ce modèle-là car la performance était bonne tout en gardant un temps d’inférence qui était très rapide, inférieur à 2 secondes. Ce qui veut dire que si le… Concrètement, actuellement, si le médecin choisit d’éditer le résumé de l’interaction qu’il a eue avec le patient, deux secondes plus tard, on lui fait une proposition de codification. Il n’a pas à attendre plus de deux secondes. Sur du hardware, facile à trouver sur un hyperscaler comme GCP, qui sont des GPU L4 actuellement. 

 

Marc 00:19:05 – 00:19:10 : constituent à peu près, c’est des GPU qui ont quoi comme mémoire ? 

 

Samuel 00:19:10 – 00:19:29 : Là, c’est des GPU qui ont 24 Go de RAM intégrés, qui ne sont pas aussi puissants que, disons, des H100, par exemple, qui sont plus des machines qu’on va utiliser pour le training. Mais vu que le modèle tourne sur un seul de ces GPU, ça nous permet de scaler facilement, horizontalement, notre service. 

 

Marc 00:19:29 – 00:19:34 : OK. Et la taille de Phi 2 et de Phi 3, du coup, c’est quoi ? 

 

Samuel 00:19:34 – 00:20:01 : donc FIDE a 2,7 milliards de paramètres. donc selon la manière dont on le sérialise le plus courant étant de le sérialiser en flotte 16 on a du coup le double en termes de de taille. donc on est sur du 5,4 gigaoctets. ok Fi3, la version mini qui est sortie il y a quelques jours, est un peu plus grosse à 3,8 milliards de paramètres, donc 7,6 gigaoctets. 

 

Marc 00:20:01 – 00:20:14 : D’accord. Et ils sont conçus pour le fine tuning, ces modèles ? Pourquoi Microsoft sort encore des modèles ? comme ceux-là en marge de tous les modèles qui existent aujourd’hui. 

 

Samuel 00:20:14 – 00:21:29 : C’est très pratique d’avoir des petits modèles performants d’une manière générale, soit parce qu’en production, on peut avoir des tâches qui sont extrêmement simples, mais remplace le nom du patient par son vrai nom tout en gérant les fautes. d’accord bon ça c’est des tâches qui pour un LLM sont extrêmement simples. il n’y a pas besoin de faire un appel à GPT-4 pour ce genre de choses. donc ça aide d’avoir des modèles généralistes qui sont capables pour le fine tuning. c’est pratique aussi puisque généralement quand on fine tune un modèle c’est parce qu’on veut perdre de la généralité pour de la performance dans une tâche donnée typiquement une tâche. maintenant qu’il y a des LLM facilement accessibles par API pour n’importe quelle tâche on va commencer par utiliser un modèle très généraliste voir ce qu’on peut en faire. et plus la tâche est définie et plus on a besoin de performance soit en termes de rapidité soit en termes de coûts Soit en termes, dans certains cas, par exemple le cas de la codification, en termes de performance, de qualité pure, plus on va aller vers le fine tuning. Et du coup, on est intéressé plus par des petits modèles qui vont performer très rapidement une tâche restreinte en production. 

 

Marc 00:21:30 – 00:21:44 : Alors à part utiliser des petits modèles, tu as d’autres conseils pour les gens qui veulent finetuner des LLM ? C’est quand même une tâche difficile, c’est de l’entraînement, la convergence n’est pas garantie, on est sur des compétences qui sont différentes. 

 

Samuel 00:21:44 – 00:23:01 : Je vais peut-être donner un conseil qui va à contre-pied, qui est avant de finetuner quelque chose, c’est pas mal d’attente d’en avoir vraiment besoin, soit pour des contraintes de performance, soit de coût, soit… Particulièrement, moi je suis Anabla qui est une startup. Dans une startup, l’output du système va évoluer beaucoup plus souvent pour des raisons de produit parce qu’on comprend mieux de semaine en semaine quels sont les besoins, dans notre cas, du médecin. Au tout début, on a besoin de flexibilité. Du coup, je dirais que particulièrement pour une startup, pour des tâches de texte-to-texte ou de texte vers données structurées, c’est bien de voir au maximum ce qu’on peut faire avec un modèle généraliste avant de finiturer son propre modèle de manière très paradoxale. Mon conseil pour les gens qui veulent fine-tuner des modèles, c’est de prendre deux secondes à réfléchir. Est-ce qu’on en a vraiment besoin ? Dans certains cas, qui est celui de Nabla, par exemple, on en a vraiment besoin. Et plus ça va, plus ça devient un avantage d’avoir des modèles fine-tunés parce qu’on peut avoir la même inférence pour un prix beaucoup plus bas en étant beaucoup plus rapide, etc. 

 

Marc 00:23:01 – 00:23:08 : D’accord. Alors, si toutefois, on avait besoin de fine-tuner quand on était arrivé là ? 

 

Samuel 00:23:08 – 00:23:52 : Là, j’ai un tout petit peu beauté en touche en disant que je suis très content de ne pas avoir à donner beaucoup de conseils parce que la communauté open source, particulièrement Hugging Face, a mis à disposition des ressources qui sont tellement accessibles qu’il devient assez facile de finetuner un modèle aujourd’hui, ce qui est beaucoup plus dur actuellement. c’est de savoir exactement ce que ton client veut, récolter des données très spécifiques qui ont besoin d’être annotées par des professionnels médicaux. Finalement, ces deux parties sont, je pense, beaucoup plus dures que la partie fine-tuner en soi. 

 

Marc 00:23:52 – 00:24:13 : Oui, indéniablement. Mais du coup, le conseil, si je le reformule, c’est d’utiliser Hugging Face. Concentrez-vous sur la data et utilisez l’interface graphique du site web Hugging Face pour uploader votre data, mettre en place une infra et récupérer votre modèle fine-tuné. C’est un peu ça. Je vais trop loin dans l’interface graphique. 

 

Samuel 00:24:14 – 00:24:22 : Non, je ne suis pas en train de faire de la pub pour l’interface graphique de Hugging Face. Je pensais plus aux nombreuses ressources qu’ils mettent à disposition en termes de script de fine-tuning. 

 

Marc 00:24:23 – 00:24:25 : Donc la librairie, Transformers… 

 

Samuel 00:24:25 – 00:26:19 : Oui, mais au-delà de ça, je n’ai pas de conseils particuliers à donner pour qui voudrait fine-tuner un LLM. Quelque chose qui est intéressant et qu’on a vu à la fois pour le speech-to-texte ou là où on fine-tune, quelque chose qui reste un modèle génératif, qui est Whisper, ou un large language model, c’est des fois il y a une certaine contradiction entre la loss qu’on utilise, qui est du coup à quel point il est perplexe du prochain token qu’il voit, et le résultat final. Et par exemple dans le cas de Whisper, qui est aussi quelque chose qu’on fine-tune, Ça peut être très intéressant de loguer au cours du training et la loss et la performance finale puisque finalement la tâche n’est pas tout à fait la même. On entraîne un Large Language Model sur prédire le prochain token En fonction des tokens précédents. Et en fait, lorsqu’on l’utilise, ce n’est pas exactement la même tâche puisqu’on lui demande de générer des tokens. Donc au moment où il se trompe ou alors il sort un peu de ce qu’il devrait outputer, après, quelque part, il improvise. Donc on a constaté dans ces deux tâches, à la fois la tâche de générer une structuration et la tâche de speech-to-texte, une légère différence entre la courbe qu’on obtient de la loss au cours du temps, qui typiquement va être assez académique avec une loss qui commence par baisser sur les valse 7 puis remonte, Et si on observe la loss sur le World Error Rate, par exemple dans le cas de Whisper ou de l’erreur finale de codification qu’on mesure d’une autre façon, mais aussi pas dérivable dans le cas de la structuration, on se rend compte qu’en fait, des fois, le moment où il faut arrêter le fine tuning ou au moins le checkpoint qu’on va prendre peut être légèrement différent du minimum de la loss académique. Ok, d’accord. 

 

Marc 00:26:21 – 00:26:31 : Il vaut mieux s’arrêter en regardant la loss par rapport à la tâche finale que celle qui calcule mot après mot la perplexité. 

 

Samuel 00:26:31 – 00:26:36 : En tout cas, c’est bien de s’intéresser à la performance finale du modèle si on peut pendant le fainting. 

 

Marc 00:26:38 – 00:27:16 : Ok. Tiens, une autre question qui me vient par rapport à ça, c’est quand on fine-tune, par rapport au retrieval augmented generation, on perd un petit peu cette capacité à retrouver la source. Pourquoi est-ce qu’on a répondu ça dans le RAG ? Donc on va dire « Ok, j’ai retrouvé, c’est dans tel chunk de données ». Comment est-ce que vous abordez ce problème-là, si c’en est un pour vous ? La fiabilité de ce fantôme qu’est l’hallucination, quand on travaille avec des LLM, cette monstruosité qu’on veut absolument éviter. Comment est-ce que, dans le cadre du large language model, comment vous gérez le contrôle qualité, d’une certaine façon ? 

 

Samuel 00:27:16 – 00:30:33 : Oui, donc particulièrement pour les pièces de documentation qui sont du texte, du résumé. Un des problèmes qu’on rencontre, comme tu le dis, c’est comment on évalue cette pièce de texte et particulièrement qu’elles sont arrivées à quantifier le taux d’hallucination auquel on va faire face ou au moins le taux de choses qui ne sont pas particulièrement justifiées dans notre cas par le transcripte. Nous, on est un peu aidé par le fait que notre tâche est très souvent du résumé, ce qui enlève beaucoup de cas d’hallucination car il y a moins de place pour l’imagination quand on fait un résumé orienté. Donc là-dessus, on est pas mal aidé. Nous, on a un contrôle qualité qu’on a mis en place qui peut être vu comme une suite de tests unitaires. puisqu’on contrôle à la fois est-ce que l’information est bien présente et est-ce qu’elle est vraie et est-ce que ce qu’on génère respecte un certain style. donc on a pour ce qui est du recall donc de quel pourcentage d’informations qui devrait être dans la documentation est effectivement dans la documentation. On a, pour certains cas qui ont été partagés par nos médecins, écrit dans cette note, il devrait y avoir l’information que le patient est atteint d’un diabète de type 2, par exemple. Et du coup, lorsque notre système génère une documentation, lorsqu’on va l’évaluer, on va prendre ces tests unitaires qu’on a écrits et poser la question à un large language model. Donc on utilise GPT-4 pour évaluer nos systèmes. Du coup, on pose la question dans cette génération, dans cette documentation qui a été générée, est-ce qu’on mentionne que le patient est atteint de diabète de type 2 ? Donc, on sait qu’il y a des faits qui devraient être présents et on pose la question à un juge, à un LLM, de savoir est-ce que l’information est présente. En découpant l’évaluation en des micro-tâches qui sont beaucoup plus faciles à exécuter pour un LLM, on obtient un juge qui est capable d’estimer la performance en termes de modèle sans avoir d’oracle absolu, sans avoir besoin de manuellement regarder. est-ce que le modèle fait un bon travail ? C’est comme ça qu’on évalue la performance en termes de recall, donc sur la documentation qu’on génère, est-ce que les faits qu’on devrait rapporter sont bien présents, qu’on évalue en termes de style via des questions du même type ? Est-ce qu’on n’est pas redondant entre la partie histoire de la maladie, par exemple, et la partie plan ? Est-ce que les informations sont dans les bonnes sections ? C’est ce qu’on appelle du style. Et également, en termes de véracité, où là, on découpe la tâche en deux autres sous-tâches, qui est de décomposer le résumé qu’on a fait de la consultation en des faits atomiques et demander la tâche plus simple, du coup, à un juge, qui est un LLM, de « est-ce que tu peux justifier cette pièce d’information unitaire depuis le transcript 

 

Marc 00:30:33 – 00:30:35 : ? ». D’accord, ok. 

 

Samuel 00:30:35 – 00:31:41 : La tâche étant plus simple que de générer de but en blanc la note ou des sections de documentation, on va avoir une évaluation plutôt fidèle de quel est le pourcentage de faits qui sont discutables, on va dire. Ok. Je devrais mentionner qu’en plus de ça, il y a aussi une évaluation humaine. On repasse par exemple sur les résultats de ce juge pour corroborer à chaque fois qu’on update notre système, corroborer avec ce que… l’ingénieur qui va updater ce système pense. Et on a également un mécanisme de feedback. Il faut voir que l’interface graphique qu’on propose est assez intuitive, pousse les médecins à lire et modifier, s’ils veulent, le contenu des notes et d’une manière générale nous rapporte tout ce qui semble être des imprécisions. Donc on a aussi un mécanisme d’évaluation online via le retour des médecins de quel est le degré d’imprécision de nos systèmes. D’accord, ok. 

 

Marc 00:31:42 – 00:31:45 : Parce que le premier mécanisme dont on parlait, c’était plutôt pour la recherche. 

 

Samuel 00:31:45 – 00:32:08 : Voilà, c’est ça. On a un mécanisme offline et un mécanisme online. Le mécanisme offline, il doit être entièrement automatisé et permettre d’itérer rapidement. Ouais. Et une fois qu’on a une certaine certitude qu’on peut pousser ce nouveau système en production, on fait un contrôle humain et ensuite on a le retour des docteurs. 

 

Marc 00:32:09 – 00:32:13 : Ok, super. Est-ce que tu as une anecdote à nous partager ? 

 

Samuel 00:32:13 – 00:32:19 : Oui, je vais parler de celle-là. C’est aussi une erreur qu’on a faite par le passé, ça concerne le speech-to-texte. 

 

Marc 00:32:20 – 00:32:20 : D’accord. 

 

Samuel 00:32:22 – 00:33:35 : Une première version de notre speech-to-texte avait été finetunée sur uniquement des pièces d’audio où quelqu’un parlait et assez peu de moments de silence ou de bruit extérieur. Et du coup, la première version basée sur Whisper Le comportement quand il entendait une pièce d’audio qui n’était pas de quelqu’un qui parle était assez indéfini. Et dans les premières versions, on a eu des retours de médecins qui disaient quand je ferme une porte, le système écrit bruit de porte qui se ferme. Est-ce que c’est normal ? Alors, on trouvait ça intéressant jusqu’au moment où certaines conclusions étaient fausses ou hâtives. Donc, par exemple, on avait des retours qui disaient, le système dit qu’il y a eu des bruits de portière qui se fermaient, or j’étais dans mon cabinet, il n’y a eu aucun bruit similaire. Ou alors, un retour d’un médecin qui devait avoir un ventilateur qui faisait un craquement bizarre, qui nous a dit, écoutez, le système dans le transcript dit qu’il y a des bruits corporels très gênants, comment ça se fait ? On a depuis augmenté le dataset pour gérer un peu mieux les bruits divers quand personne ne parle. D’accord. 

 

Marc 00:33:35 – 00:33:39 : Les prochaines étapes pour Nabla, c’est quoi, côté IA ? 

 

Samuel 00:33:39 – 00:35:00 : Côté IA, il reste certaines pièces de documentation qui sont générées via appel à un LLM public. Il se trouve que GPT-4 est un excellent résumeur, donc pour certaines pièces de documentation, nous n’avons pas encore de modèle in-house pour ces parties-là. Donc évidemment, le futur… C’est pas si évident que ça, mais tant pour des raisons de rapidité et qualité, ce que je citais tout à l’heure. Pour nous, le futur, c’est un ou plusieurs modèles in-house qui font absolument tout. Pour l’instant, il reste encore quelques pièces qui sont des appels à un LLM externe. Et le second point, c’est du flow de données, mais ce n’est pas exactement du machine learning. C’est une intégration parfaite avec les logiciels patients qu’utilisent les médecins, ce qui nous permettra de gagner en contextualisation de la documentation. Actuellement, notre seule source de données est ce qui se passe lors de la consultation. plus ce que le médecin dicte ou renseigne. Et à terme, Nabla est tellement intégré avec les logiciels patients qu’au moment où le patient franchit le seuil de la porte, on sait déjà l’intégralité des problèmes de santé qu’il a rencontrés par le passé et on peut adapter la documentation en fonction. 

 

Marc 00:35:01 – 00:35:08 : D’accord. Est-ce que tu as un invité à me suggérer que tu aimerais entendre dans un prochain épisode de Data Driven 101 ? 

 

Samuel 00:35:08 – 00:35:21 : Je n’ai pas de nom en tête, mais je serais très intéressé par un invité qui est dans le domaine du légal, comme Doctrine ou Legal Place, parce que je pense qu’ils ont des problématiques très similaires aux nôtres, et ça m’intéresserait beaucoup d’entendre leur point de vue là-dessus. 

 

Marc 00:35:21 – 00:35:23 : Moi aussi. Merci Samuel. 

 

Samuel 00:35:23 – 00:35:24 : Je t’en prie Marc. 

 

Marc 00:35:24 – 00:35:28 : Vous venez d’entendre Samuel Humeau, lead ML chez Nabla, sur Data Driven 101.