POC de triage médical par LLM : de la préparation des données au déploiement d'une API démonstrative
Fil directeur
Construire un POC défendable de bout en bout plutôt qu'un simple prototype de modèle
Chaîne technique
Pipeline data, SFT, DPO, FastAPI, vLLM, CI/CD et smoke tests
Positionnement
POC traçable et déployé, avec limites cliniques clairement assumées
Détail
Lecture du projet
La fiche présente la logique du projet, les choix techniques structurants, les éléments de déploiement et les limites assumées, sans sur-vendre le niveau de maturité.
Résumé
01
Le projet vise à construire un POC cohérent et défendable de triage médical assisté par modèle de langage. L'enjeu n'est pas de promettre un système clinique prêt à l'emploi, mais de montrer une chaîne de travail sérieuse allant de la donnée jusqu'à une API déployée, avec traçabilité, critères de validation et limites explicites.
Problème adressé
02
Un usage de triage ne peut pas être abordé comme un simple exercice de prompting. Il faut maîtriser la qualité des données, distinguer validation technique et validation clinique, cadrer l'évaluation et conserver une lecture prudente des résultats. Le projet cherche donc à démontrer une démarche d'AI Engineering plus qu'un effet de démonstration.
Pipeline data et gouvernance
03
La première étape a consisté à structurer un pipeline de données propre et auditable : inventaire des datasets, ingestion raw, normalisation dans un schéma canonique, contrôles qualité, anonymisation et exports adaptés aux phases d'entraînement. Cette base a été traitée comme une condition préalable au reste du projet, pas comme une tâche secondaire.
Stratégie d'entraînement
04
La trajectoire retenue suit une progression explicite : préparation des données, fine-tuning supervisé de type SFT, puis alignement via DPO. Le choix d'un petit modèle de base avec adaptation LoRA permet de garder un périmètre réaliste, reproductible et techniquement défendable dans le cadre du projet.
Évaluation et logique de go / no-go
05
Le projet a été piloté avec une logique de gating entre phases plutôt qu'avec une accumulation de scripts isolés. L'objectif était de pouvoir dire proprement si le pipeline data, le SFT puis le DPO étaient suffisamment stables pour justifier la suite, tout en gardant séparée la question de la validation clinique, explicitement hors périmètre.
Déploiement cible
06
La solution de démonstration retenue repose sur un proxy FastAPI exposé publiquement devant un moteur vLLM exécuté sur serveur GPU, avec chargement séparé du modèle de base et de l'adapter LoRA. Ce choix permet de présenter une API claire, de conserver un journal d'interactions et de disposer d'un chemin de déploiement concret sans fusionner les poids du modèle.
CI/CD, observabilité et exploitation
07
Le déploiement a été structuré pour rester rejouable localement et en CI/CD. Les étapes de lint, test, build, déploiement manuel et smoke test sont explicites. L'observabilité repose sur des reports, du logging JSONL, des identifiants de requête et un suivi MLflow, ce qui donne un niveau de traçabilité cohérent pour un POC technique.
Résultats structurants
08
Le projet aboutit à un socle de données propre, à un entraînement supervisé validé, à une phase DPO jugée exploitable dans le cadre du POC, puis à un endpoint FastAPI + vLLM déployé avec smoke test concluant. La valeur démontrée tient à la cohérence d'ensemble de la chaîne, plus qu'à une promesse de robustesse clinique exhaustive.
Limites assumées
09
Le benchmark reste léger, l'infrastructure de démonstration est ciblée et la gouvernance clinique ou réglementaire n'est pas couverte. Le projet doit donc être lu comme un POC robuste et traçable, pas comme un dispositif prêt pour un usage réel en environnement médical.
Suites possibles
10
Les prolongements logiques seraient d'étendre l'évaluation clinique, de renforcer les tests adversariaux, d'améliorer la robustesse sur les cas ambigus et de formaliser des critères de go / no-go beaucoup plus exigeants avant tout usage métier sensible.