BenTsao (Huatuo-Llama-Med-Chinese) : micro-ajustement LoRA pour le question-réponse médical en chinois

Un problème de qualité des réponses médicales en chinois, pas un problème de modèle

Un modèle de langage généraliste répond mal aux questions médicales en chinois. Le README part de ce constat : les modèles de base sont limités dans ce scénario, et le micro-ajustement par instructions est présenté comme un moyen efficace de leur donner la capacité de répondre à des questions humaines. Le dépôt ne cherche donc pas à construire un nouveau modèle médical depuis zéro. Il part de poids ouverts existants et les adapte. Le public visé est précis : des équipes qui disposent déjà d'un modèle de base téléchargeable et d'une carte GPU, et qui veulent mesurer l'apport d'un corpus médical chinois sans réentraîner un modèle complet. C'est un projet de recherche reproductible, pas un produit. Les auteurs publient des poids LoRA, des scripts et une partie des données, ce qui permet de refaire l'inférence, mais pas de refaire la collecte.

Quatre modèles de base, une seule méthode d'adaptation

Le dépôt couvre quatre bases : Huozi 1.0, un modèle de question-réponse chinois développé à partir de Bloom-7B ; Bloom-7B ; Alpaca-Chinese-7B, dérivé de LLaMA ; et LLaMA-7B. Pour toutes, la même approche est retenue : un micro-ajustement LoRA en demi-précision. Le README justifie ce choix par un compromis entre ressources de calcul et performance. Concrètement, on ne modifie pas les poids du modèle de base. On entraîne une paire de fichiers, adapter_config.json et adapter_model.bin, qui vient se greffer sur la base au moment de l'inférence. Le gain pratique est net : un même socle peut servir plusieurs adaptateurs, et le stockage reste limité à ces deux fichiers par variante. La contrepartie est classique : le LoRA hérite des limites du modèle de base, y compris de ses biais linguistiques et de ses connaissances générales, que le corpus médical ne corrige pas.

Deux chaînes de données distinctes : base de connaissances et littérature

La première chaîne part d'une base de connaissances médicale chinoise, publique et auto-construite, dont le projet indique s'être largement inspiré de cMeKG. Les entités tournent autour des maladies, des médicaments et des indicateurs d'examen, avec des champs comme les complications, les facteurs de risque, l'examen histologique, les symptômes cliniques, le traitement médicamenteux et les traitements adjuvants. Un exemple du README montre une entrée structurée pour la migraine, avec les maladies associées, les symptômes, le service concerné et la localisation. Ces entrées sont transformées en paires question-réponse via l'API GPT-3.5, avec plusieurs formulations de prompt. La seconde chaîne est différente : elle part d'articles médicaux chinois de 2023 sur le cancer du foie et génère des dialogues multi-tours à partir des sections de conclusion. Le fichier data_literature/liver_cancer.json contient environ 1 000 exemples d'entraînement selon le README. Un point mérite d'être dit franchement : les deux chaînes dépendent d'un modèle propriétaire externe pour produire les réponses cibles. La qualité du corpus est donc liée à celle de ce générateur, et le dépôt ne documente pas de filtrage des réponses générées.

Le micro-ajustement par knowledge tuning, une étape de plus

Le dépôt va au-delà de la simple paire question-réponse. Il décrit un knowledge tuning en trois phases : le modèle remplit d'abord les paramètres de recherche à partir de la question (terme central et attributs), interroge ensuite la base pour récupérer la connaissance correspondante, puis génère la réponse à partir de cette connaissance. L'objectif annoncé est que le modèle exploite explicitement la base au moment de l'inférence, au lieu de se contenter de restituer ce qu'il a mémorisé pendant l'entraînement. Un exemple de données est fourni dans data/knowledge_tuning_data_sample.txt. C'est la partie la plus intéressante du dépôt sur le plan méthodologique, et aussi la moins directement réutilisable : elle suppose de disposer d'une base interrogeable avec le bon schéma de champs. Le dépôt ne fournit pas cette base, seulement la méthode et un échantillon.

Mise en route : dépendances, poids LoRA et scripts

L'installation se limite à pip install -r requirements.txt, avec un environnement Python 3.9 ou supérieur recommandé. Les poids LoRA ne sont pas dans le dépôt : ils se téléchargent via Baidu Netdisk ou Hugging Face, avec des liens distincts selon la base et selon le corpus utilisé (base de connaissances, littérature, ou les deux). Après décompression, le dossier doit contenir adapter_config.json et adapter_model.bin. L'inférence se lance avec bash ./scripts/infer.sh pour la base de connaissances, ou bash ./scripts/infer-literature-single.sh et bash ./scripts/infer-literature-multi.sh pour la littérature. Le script appelle infer.py avec les arguments --base_model, --lora_weights, --use_lora True, --instruct_dir et --prompt_template. Trois de ces valeurs doivent être remplacées : le chemin du modèle de base, celui des poids LoRA et celui du jeu de test. Le choix du template dépend du modèle : templates/bloom_deploy.json pour Huozi et Bloom, templates/med_template.json ou templates/literature_template.json pour LLaMA et Alpaca. Se tromper de template est l'erreur la plus probable au premier essai, car rien dans le script ne semble la détecter. Le fichier data/infer.json sert d'exemple de format d'entrée.

Ce que le dépôt ne fournit pas

Le README est explicite sur deux points. D'abord, le code de construction de la base de connaissances et du jeu de données est encore en cours de préparation au moment de la rédaction ; il n'est donc pas dans le dépôt. Ensuite, les auteurs reconnaissent que le jeu d'entraînement, environ huit mille exemples, contient des erreurs et des imperfections, et qu'il sera révisé. Ces deux constats ont une conséquence directe : on peut reproduire l'inférence et le micro-ajustement sur ses propres données, mais pas reproduire la chaîne de génération des données publiées. Pour la partie littérature, la couverture est encore plus étroite : seuls les paramètres entraînés sur le cancer du foie sont ouverts. Le projet annonce vouloir étendre à seize maladies liées au foie, aux voies biliaires et au pancréas, mais cette extension n'est pas disponible. Enfin, le tableau de comparaison des sorties est daté de mars 2023 et tronqué dans le matériel fourni, ce qui empêche d'en tirer une évaluation actuelle.

Ressources de calcul et coût de maintenance

Le README donne des repères concrets pour l'entraînement sur LLaMA : une seule carte A100-SXM-80GB, dix époques, environ 2 h 17 min, avec une occupation mémoire d'environ 40 Go pour un batch_size de 128. Le projet estime qu'une carte de 24 Go comme une 3090 ou une 4090 peut suffire, à condition d'ajuster le batch_size. Ces chiffres concernent LLaMA-7B et ne sont pas garantis pour les autres bases. Le coût de maintenance réel ne vient pas du code, qui est compact, mais de la chaîne de données : régénérer un corpus médical propre demande un accès à un générateur externe et une relecture. Côté licence, le code est publié sous Apache-2.0, ce qui autorise la réutilisation et la modification avec conservation des mentions. Cette licence ne couvre pas les poids LoRA ni les modèles de base, qui ont leurs propres conditions, notamment celles de LLaMA. Le dépôt ne tranche pas cette question et il faut la vérifier séparément avant tout usage autre que la recherche.

Comparer avec une approche par récupération seule

L'alternative la plus proche n'est pas un autre modèle médical, c'est une architecture de génération augmentée par récupération, sans micro-ajustement. Dans ce montage, on interroge la base de connaissances à chaque question et on insère les passages pertinents dans le prompt d'un modèle généraliste. La différence de méthode est structurelle. Le micro-ajustement modifie les poids et fige la connaissance au moment de l'entraînement : mettre à jour la base impose de réentraîner. La récupération garde les poids intacts et met à jour l'index, mais elle dépend entièrement de la qualité du module de recherche et consomme plus de contexte à chaque requête. Le knowledge tuning du dépôt se situe entre les deux : il apprend au modèle à formuler la requête, tout en gardant la base externe. Ce choix a un coût : il faut une base interrogeable et un format de champs stable, ce que le dépôt ne fournit pas. Pour un test rapide sur quelques questions, la récupération seule est plus simple à mettre en place. Pour un domaine au vocabulaire stable et à la base peu évolutive, le LoRA entraîné une fois est plus léger à servir.

Conclusion éditoriale

Ce dépôt s'adresse aux équipes de recherche et aux développeurs qui veulent expérimenter le micro-ajustement LoRA sur des modèles ouverts avec des données médicales chinoises, et qui acceptent de reconstruire eux-mêmes la chaîne de données. Il ne convient pas à un déploiement clinique : les auteurs signalent des erreurs dans les jeux d'entraînement et ne fournissent pas le code de construction des données. Avant toute réutilisation, vérifiez que votre base correspond bien au modèle de prompt attendu, par exemple templates/med_template.json pour LLaMA et templates/bloom_deploy.json pour Bloom ou Huozi, puis contrôlez la licence Apache-2.0 du code séparément de celle des poids et des modèles de base.

Sources officielles

1. Issues
2. License: Apache-2.0
3. README
4. SCIR-HI/Huatuo-Llama-Med-Chinese on GitHub