Dom/t2a_v2

Files

dom 909e051cc9 feat: architecture multi-modèles LLM + quality engine + benchmark

- Multi-modèles : 4 rôles LLM (coding=gemma3:27b-cloud, cpam=gemma3:27b-cloud,
  validation=deepseek-v3.2:cloud, qc=gemma3:12b) avec get_model(role)
- Prompts externalisés : 7 templates dans src/prompts/templates.py
- Cache Ollama : modèle stocké par entrée (migration auto ancien format)
- call_ollama() : paramètre role= (priorité: model > role > global)
- Quality engine : veto_engine + decision_engine + rules_router (YAML)
- Benchmark qualité : scripts/benchmark_quality.py (A/B, métriques CIM-10)
- Fix biologie : valeurs qualitatives (troponine négative) non filtrées
- Fix CPAM : gemma3:27b-cloud au lieu de deepseek (JSON tronqué par thinking)
- CPAM max_tokens 4000→6000, viewer admin multi-modèles
- Benchmark 10 dossiers : 100% DAS valides, 10/10 CPAM, 243s/dossier

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-02-20 00:21:09 +01:00

1.9 KiB

Raw Blame History

Règles (vetos + décisions)

Ce dossier contient la configuration "métier" pour piloter le moteur qualité.

Fichiers

base.yaml : socle commun (règles activées par défaut).
enabled.yaml : choisit les overlays à activer (site/spécialité).
specialties/*.yaml : overrides par spécialité.
sites/*.yaml : overrides par établissement.

Principe

Une règle non listée est considérée activée.
- Ça évite de casser le comportement historique lors d'une montée de version.
Une règle listée peut être :
- enabled: false → désactivée
- (VETO) force_severity: "HARD"|"MEDIUM"|"LOW" → force la sévérité

Exemple d'override

Créer config/rules/sites/chu_poitiers.yaml :

version: 1
rules:
  VETO-12:
    enabled: false
  VETO-09:
    force_severity: "HARD"

Puis activer dans enabled.yaml :

active:
  site: "chu_poitiers"
  specialty: ""
  extra: []

Routage automatique (router.yaml)

Le fichier router.yaml permet d’activer automatiquement des packs de règles en fonction des signaux du dossier (codes, biologie, extraits). Concrètement :

Par défaut, seuls les packs listés dans defaults.enabled_packs sont actifs.
Quand un trigger match, on ajoute ses enable_packs.
Le routage est appliqué par dossier (et re-appliqué sur la version fusionnée).

Mode strict

Quand mode: strict, une règle non listée dans base.yaml est considérée désactivée dès que le routage runtime est actif.

Ça force une approche “catalogue explicite” : tout ce qui tourne en prod est visible et gouvernable.

Exemple

Activer les règles ionogramme uniquement si un code E87.* est détecté ou si la biologie mentionne Sodium/Potassium :

triggers:
  - id: TRG-ELECTROLYTES
    enable_packs: [bio_electrolytes]
    when_any:
      codes_prefix: ["E87."]
      lab_tests: ["sodium", "potassium"]

1.9 KiB Raw Blame History Unescape Escape