5ea4960e65
Backup état complet après enregistrement vidéo démo de bout en bout. À utiliser comme point de référence pour la consolidation post-démo. Changements majeurs de la session 18-19 mai : - AIVA-URGENCE : page autonome avec preset URL + auto-focus chain - Workflow Demo_urgence_3_db : merge linux_db + steps AIVA + pause humaine NoMachine - Bypass LLM (static_result / static_text) dans replay_engine pour démos déterministes sans appel Ollama - Fix api_stream:3013 — replay_paused au premier polling /next - dag_execute : lift duration_ms vers top-level pour wait runtime - NPM bypass auth /aiva-urgence/ via location ^~ (proxy_host/10.conf hors git) - scripts/cancel-replays.sh — workaround Stop VWB qui ne purge pas la queue Anchors visuels (468) forcés dans le commit pour garantir restorabilité. DB workflows actuelle + ~12 .bak DB de la journée incluses. Sujets identifiés pour consolidation post-démo (TODO) : 1. Bug VWB recapture anchor ne régénère pas le PNG 2. Léa client accumule état mémoire (restart périodique requis) 3. Stop VWB ne purge pas la queue serveur (lien manquant vers /replay/cancel) 4. Bug coord client mss tronqué 2560x60 → mapping Y cassé 5. delay_before/delay_after ignorés au runtime (fix partiel duration_ms) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
10 KiB
Évaluation comparative de LLMs pour la décision de facturation urgences
Démo aiva-vision — décision automatisée forfait urgences vs requalification en hospitalisation MCO Date : 28 avril 2026
Contexte et enjeu business
À la sortie d'un passage aux urgences, deux régimes de facturation T2A/PMSI sont possibles :
- Forfait urgences (FFU/ATU) : passage simple, retour à domicile — valorisation ~30-200 €
- Requalification en hospitalisation MCO (GHM) : séjour court avec surveillance prolongée, soins continus, transfert spécialisé — valorisation 1 000 à 5 000 €+
L'écart financier est massif et la décision repose sur des critères PMSI/ATIH lisibles dans le DPI urgences (durée de présence, surveillance scopée, oxygénothérapie, soins IV itératifs, transferts, etc.). Aujourd'hui cette décision est prise manuellement par les médecins DIM, avec un risque significatif de sous-codage (manque à gagner) ou de sur-codage (risque de contrôle ATIH).
L'objectif de cette évaluation est d'identifier le LLM le plus pertinent pour assister cette décision dans le cadre d'aiva-vision, en respectant la contrainte d'un déploiement 100 % local (RGPD/HDS).
Méthodologie
Jeu d'évaluation
15 DPI urgences synthétiques en français médical réaliste, structurés en trois catégories :
| Catégorie | N | Description |
|---|---|---|
| Simple (forfait clair) | 5 | Entorse, plaie suturée, colique néphrétique soulagée, fièvre virale, asthme léger |
| Complexe (hospit. évidente) | 5 | Pneumopathie hypoxémiante, OAP, AVC thrombolysé, sepsis, SCA NSTEMI |
| Borderline | 5 | Douleur thoracique tropos négatives, gériatrie post-malaise UHCD 27 h, intoxication médicamenteuse, vertige rotatoire, pyélonéphrite simple |
Les cas borderline sont la vraie métrique business — ils représentent les situations où la décision est ambiguë et où le LLM apporte de la valeur.
Tâche évaluée
Pour chaque DPI, le modèle doit produire un JSON structuré contenant :
decision:FORFAIT_URGENCEouREQUALIFICATION_HOSPITALISATIONelements_pour_hospitalisation: faits littéralement extraits du DPIelements_pour_forfait: faits littéralement extraits du DPIduree_passage_heures: calculée depuis les horaires du dossierjustification: 2-3 phrasesconfiance:elevee/moyenne/faible
Le prompt impose une extraction littérale (pas d'invention) et une modulation honnête de la confiance.
Modèles évalués
Onze modèles, locaux et cloud, balayant le spectre des architectures et tailles disponibles fin avril 2026 :
- Médicaux spécialisés :
medgemma:4b,medgemma:27b-it(Q4_K_S),Apollo2-9B - Fine-tune T2A maison :
t2a-gemma3-27b-q4 - Généralistes locaux :
qwen2.5:7b,qwen2.5:14b,gemma4 - Reasoning models :
DeepSeek-R1,qwen3-next:80b-cloud - Top tier cloud :
gemma3:27b-cloud,gpt-oss:120b-cloud
Résultats
Classement global
| # | Modèle | VRAM | Type | Accuracy | Simple | Complex | Border | FN | Latence |
|---|---|---|---|---|---|---|---|---|---|
| 1 | t2a-gemma3-27b-q4 (fine-tune maison) | 16 GB* | Local FT | 15/15 (100 %) | 5/5 | 5/5 | 5/5 | 0 | 52 s |
| 2 | gpt-oss:120b-cloud | ~70 GB | Cloud | 15/15 (100 %) | 5/5 | 5/5 | 5/5 | 0 | 7,5 s |
| 3 | gemma3:27b-cloud | ~16 GB | Cloud | 15/15 (100 %) | 5/5 | 5/5 | 5/5 | 0 | 5,6 s |
| 4 | medgemma:27b-it (Q4_K_S) | 16 GB* | Local | 15/15 (100 %) | 5/5 | 5/5 | 5/5 | 0 | 61 s |
| 5 | qwen2.5:7b | 4,7 GB | Local | 15/15 (100 %) | 5/5 | 5/5 | 5/5 | 0 | 5,1 s |
| 6 | qwen2.5:14b | 9,0 GB | Local | 14/15 (93 %) | 5/5 | 5/5 | 4/5 | 1 | 10,5 s |
| 7 | gemma4:latest | 9,6 GB | Local | 14/15 (93 %) | 5/5 | 5/5 | 4/5 | 0 | 3,0 s |
| 8 | medgemma:4b | 3,3 GB | Local | 13/15 (87 %) | 5/5 | 4/5 | 4/5 | 1 | 3,5 s |
| 9 | Apollo2-9B Q4_K_S | 5,5 GB | Local | 12/15 (80 %) | 5/5 | 3/5 | 4/5 | 3 | 9,9 s |
| 10 | DeepSeek-R1:latest (distill 5 GB) | 5,2 GB | Local | 12/15 (80 %) | 5/5 | 3/5 | 4/5 | 3 | 4,2 s |
| 11 | qwen3-next:80b-cloud | ~50 GB | Cloud | 8/15 (53 %) | 2/5 | 4/5 | 2/5 | 0 | 20 s |
*16 GB sur disque, déborde de la 12 GB VRAM de la machine de test → offload CPU. Sur DGX Spark (128 GB unified) : estimation 5-8 s/cas.
Insights majeurs
1. La spécialisation médicale anglophone n'aide pas sur cette tâche.
medgemma:4b (13/15) et Apollo2-9B (12/15) sont battus par des généralistes plus petits ou non médicaux. Apollo2-9B, pourtant le seul modèle médical avec un support français explicite (FrenchMedMCQA, MMLU_FR), rate deux cas complexes tranchés (Pneumopathie hypoxémiante, SCA NSTEMI) — ce qui est rédhibitoire pour un déploiement.
Le levier de performance n'est pas la connaissance médicale générique, mais la connaissance des règles T2A/PMSI/ATIH françaises.
2. Le fine-tune T2A maison atteint 100 % et égale GPT-OSS 120B.
t2a-gemma3-27b-q4 (fine-tune sur le domaine T2A) est au niveau d'un modèle 5 fois plus gros tournant en cloud. C'est la confirmation que l'effort de fine-tuning sur le domaine PMSI paie clairement.
3. Reasoning models trop heavy pour une décision binaire structurée.
qwen3-next:80b-cloud (53 %) "over-thinks" : le budget tokens est consommé par le raisonnement avant la sortie JSON. Quand il répond, le raisonnement est de très haute qualité (CURB-65, IDSA/ATS cités), mais le coût n'est pas justifié pour cette tâche.
DeepSeek-R1:latest (distill 5 GB local, 80 %) souffre du même problème en plus léger — 3 faux négatifs sur des urgences évidentes.
4. qwen2.5:7b écrase le rapport perf/coût.
Avec 4,7 GB VRAM, 5,1 s/cas et 15/15, ce modèle généraliste atteint la performance des 27B et 120B sur cette tâche. C'est le candidat évident pour la démo immédiate sur la machine actuelle.
Calibration de la confiance
| Modèle | Élevée | Moyenne | Faible | Commentaire |
|---|---|---|---|---|
| qwen2.5:14b | 7 | 8 | 0 | Meilleure modulation |
| gemma3:27b-cloud | 13 | 2 | 0 | Acceptable |
| qwen2.5:7b | 10 | 5 | 0 | Acceptable |
| t2a-gemma3-27b-q4 | 15 | 0 | 0 | Aucune modulation (effet du fine-tuning) |
| medgemma:27b-it | 15 | 0 | 0 | Aucune modulation |
| gpt-oss:120b-cloud | 15 | 0 | 0 | Aucune modulation |
Les modèles 100 % accuracy ont tous tendance à sortir « élevée » systématiquement. C'est un point d'amélioration à intégrer dans une v2 du fine-tune (ajout d'exemples avec confiance modulée dans le dataset d'entraînement).
Choix retenu pour la démo aiva-vision
Modèle : qwen2.5:7b
Justification selon les trois critères opérationnels :
| Critère | qwen2.5:7b | Détail |
|---|---|---|
| Aucune erreur diag | 15/15 (100 %) | À égalité avec les top tiers (27B+, 120B) |
| Latence | 5,1 s/cas | La plus basse parmi les 100 % |
| Ressources | 4,7 GB VRAM | La plus légère parmi les 100 % |
Le modèle tient sur GPU consumer (12 GB VRAM), laisse 7 GB libres pour les services aiva-vision concurrents (CLIP, FAISS, grounder UI), et atteint la performance des modèles 5-25 fois plus gros sur cette tâche. C'est l'optimum pour la démonstration.
Recommandation pour le déploiement production
Cible : DGX Spark (128 GB unified memory)
Sur la machine cible de production, deux options crédibles :
Option A — Fine-tune T2A maison (t2a-gemma3-27b-q4)
- 100 % local, IP propriétaire, contrôle total
- Performance équivalente à GPT-OSS 120B et MedGemma 27B sur ce benchmark
- Latence estimée 5-8 s/cas sur DGX Spark (sans offload CPU)
- Conforme RGPD/HDS sans réserve
- À privilégier pour la production hospitalière
Option B — qwen2.5:7b en première ligne, fine-tune en escalade
- qwen2.5:7b répond immédiatement (5 s)
- Fine-tune T2A appelé uniquement sur les cas où qwen2.5 sort en confiance « moyenne » ou « faible »
- Compromis débit/qualité optimal
Limites de l'évaluation
- Échantillon petit : 15 cas. Les écarts entre 14/15 et 15/15 ne sont pas statistiquement significatifs. Pour une validation prod, viser 100-300 cas labellisés couvrant l'intégralité de la grille ATIH.
- Cas synthétiques : les DPI ont été générés à partir de la connaissance médicale, pas extraits de production. La validation finale nécessite des cas réels anonymisés.
- Calibration de confiance : les modèles 100 % sortent tous « élevée » — leur capacité à signaler l'incertitude n'a pas pu être discriminée sur ce jeu.
- PMSI 2026 : le format V016 (en vigueur depuis le 1er janvier 2026) introduit de nouvelles règles non couvertes ici (champ « Nombre de disciplines de service » étendu). À intégrer dans la v2 du dataset.
Pistes d'amélioration
- Étendre le jeu d'évaluation à 100+ cas réels anonymisés couvrant les 28 GHM les plus fréquents en MCO.
- Recoller le fine-tune T2A avec un dataset incluant la modulation de confiance (cas borderline annotés « moyenne »).
- Intégrer les évolutions PMSI 2026 (V016, nouvelles règles SMR) dans le prompt et le training.
- Évaluer un système hybride à deux étages (qwen2.5:7b → t2a-gemma3-27b-q4 sur escalade).
- Mettre en place un eval harness automatique tournant en CI sur chaque mise à jour de modèle.
Annexe — Détail par cas
Les 15 cas et les prédictions par modèle sont consolidés dans resultats_v2.json.
Cas qui ont discriminé les modèles :
- Cas 6 (Pneumopathie hypoxémiante) : raté par medgemma:4b et Apollo2-9B — pourtant tous les critères HOSPIT sont présents (O2, scope, ATB IV, transfert pneumo, durée 22 h). Cas-test pivot.
- Cas 12 (Personne âgée UHCD 27 h) : raté par qwen2.5:14b. Borderline gériatrique avec durée > 24 h comme seul critère décisif. Cas-test pivot.
- Cas 10 (SCA NSTEMI) : raté par Apollo2-9B et DeepSeek-R1. Devrait être trivial pour un modèle médical.
Reproductibilité
Tous les scripts et données sont dans /home/dom/ai/rpa_vision_v3/demo/facturation_urgences/ :
cas_dpi.py 15 DPI synthétiques (Python)
run_simulation.py v1 mono-modèle (référence historique)
run_simulation_v2.py v2 multi-modèles, prompt durci, support reasoning
run_qwen3_only.py rerun ciblé qwen3-next:80b-cloud
run_extra_models.py batch t2a + DeepSeek + gpt-oss
run_medgemma27b.py test MedGemma 27B (thiagomoraes)
run_apollo2.py test Apollo2-9B
resultats_v2.json résultats consolidés des 11 modèles (source de vérité)
RESULTATS.md ce document
Lancement : python3 -u run_simulation_v2.py. Prérequis : Ollama démarré sur localhost:11434.