feat: architecture multi-modèles LLM + externalisation des prompts
- Ajout OLLAMA_MODELS (coding/cpam/validation/qc) dans config.py avec get_model() - Paramètre role= dans call_ollama() pour dispatch par rôle - Cache Ollama : modèle stocké par entrée (migration auto de l'ancien format) - 7 prompts externalisés dans src/prompts/templates.py (format str.format) - Viewer : admin multi-modèles, endpoint PDF avec redaction, source texte - Documentation prompts dans docs/prompts.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
dom
155
docs/prompts.md
Normal file
155
docs/prompts.md
Normal file
@@ -0,0 +1,155 @@
|
||||
# Prompts LLM — Pipeline T2A
|
||||
|
||||
Ce document récapitule les 7 prompts externalisés dans `src/prompts/templates.py`.
|
||||
|
||||
Chaque template utilise `str.format(**kwargs)` — les accolades JSON sont échappées via `{{` / `}}`.
|
||||
|
||||
---
|
||||
|
||||
## 1. CODING_CIM10 — Codage CIM-10 (DP / DAS)
|
||||
|
||||
| Paramètre | Valeur |
|
||||
|-----------|--------|
|
||||
| **Rôle** | `coding` |
|
||||
| **Température** | 0.1 |
|
||||
| **Max tokens** | 2 500 |
|
||||
| **Appelé par** | `rag_search.py → _build_prompt()` |
|
||||
|
||||
**Variables** : `texte`, `type_diag`, `ctx_str`, `sources_text`
|
||||
|
||||
**Fonction** : Code un diagnostic en CIM-10 à partir des sources RAG. Le LLM joue un médecin DIM et doit discriminer entre codes candidats en citant les règles d'inclusion/exclusion.
|
||||
|
||||
**Sortie JSON** : `analyse_clinique`, `codes_candidats`, `discrimination`, `regle_pmsi`, `code`, `confidence`, `justification`, `preuves_cliniques[]`
|
||||
|
||||
---
|
||||
|
||||
## 2. CODING_CCAM — Codage CCAM (actes)
|
||||
|
||||
| Paramètre | Valeur |
|
||||
|-----------|--------|
|
||||
| **Rôle** | `coding` |
|
||||
| **Température** | 0.1 |
|
||||
| **Max tokens** | 2 500 |
|
||||
| **Appelé par** | `rag_search.py → _build_prompt_ccam()` |
|
||||
|
||||
**Variables** : `texte`, `ctx_str`, `sources_text`
|
||||
|
||||
**Fonction** : Code un acte chirurgical/médical en CCAM (4 lettres + 3 chiffres). Vérifie activité, regroupement, et tarif secteur 1.
|
||||
|
||||
**Sortie JSON** : `analyse_acte`, `codes_candidats`, `discrimination`, `code`, `confidence`, `justification`
|
||||
|
||||
---
|
||||
|
||||
## 3. DAS_EXTRACTION — Extraction DAS supplémentaires
|
||||
|
||||
| Paramètre | Valeur |
|
||||
|-----------|--------|
|
||||
| **Rôle** | `coding` |
|
||||
| **Température** | 0.1 |
|
||||
| **Max tokens** | 2 000 |
|
||||
| **Appelé par** | `rag_search.py → _build_prompt_das_extraction()` |
|
||||
|
||||
**Variables** : `dp_texte`, `existing_str`, `ctx_str`, `text_medical`
|
||||
|
||||
**Fonction** : Identifie les DAS non encore codés dans le texte médical. Exclut les doublons, les symptômes expliqués par un diagnostic précis, et les antécédents non pertinents. Attention aux valeurs biologiques normales.
|
||||
|
||||
**Sortie JSON** : `diagnostics_supplementaires[{texte, code_cim10, justification}]`
|
||||
|
||||
---
|
||||
|
||||
## 4. QC_VALIDATION — Validation qualité post-codage
|
||||
|
||||
| Paramètre | Valeur |
|
||||
|-----------|--------|
|
||||
| **Rôle** | `qc` |
|
||||
| **Température** | 0.1 |
|
||||
| **Max tokens** | 2 500 |
|
||||
| **Appelé par** | `cim10_extractor.py → _validate_justifications()` |
|
||||
|
||||
**Variables** : `ctx_str`, `codes_section`
|
||||
|
||||
**Fonction** : Contrôle qualité du codage complet. Vérifie pour chaque code : preuve clinique, spécificité, conflits/redondances. Peut recommander de maintenir, reclasser ou supprimer un code.
|
||||
|
||||
**Sortie JSON** : `validations[{numero, code, verdict, confidence_recommandee, commentaire}]`, `alertes_globales[]`
|
||||
|
||||
---
|
||||
|
||||
## 5. CPAM_EXTRACTION — Passe 1 : extraction structurée
|
||||
|
||||
| Paramètre | Valeur |
|
||||
|-----------|--------|
|
||||
| **Rôle** | `cpam` |
|
||||
| **Température** | 0.0 |
|
||||
| **Max tokens** | 1 500 |
|
||||
| **Appelé par** | `cpam_response.py → _extraction_pass()` |
|
||||
|
||||
**Variables** : `dp_str`, `das_str`, `tagged_text`, `titre`, `arg_ucr`, `decision_ucr`, `dp_ucr_line`, `da_ucr_line`
|
||||
|
||||
**Fonction** : Comprend la contestation CPAM sans argumenter. Extrait les éléments cliniques pertinents, les points d'accord potentiels, et identifie les codes en jeu.
|
||||
|
||||
**Sortie JSON** : `comprehension_contestation`, `elements_cliniques_pertinents[{tag, pertinence}]`, `points_accord_potentiels[]`, `codes_en_jeu{dp_etablissement, dp_ucr, difference_cle}`
|
||||
|
||||
---
|
||||
|
||||
## 6. CPAM_ARGUMENTATION — Passe 2 : contre-argumentation (3 axes)
|
||||
|
||||
| Paramètre | Valeur |
|
||||
|-----------|--------|
|
||||
| **Rôle** | `cpam` |
|
||||
| **Température** | 0.1 |
|
||||
| **Max tokens** | 4 000 |
|
||||
| **Appelé par** | `cpam_response.py → _build_cpam_prompt()` |
|
||||
|
||||
**Variables** : `dossier_str`, `asymetrie_str`, `tagged_str`, `titre`, `arg_ucr`, `decision_ucr`, `codes_str`, `definitions_str`, `sources_text`, `extraction_str`
|
||||
|
||||
**Fonction** : Produit la contre-argumentation CPAM complète selon 3 axes :
|
||||
1. **Axe médical** — bien-fondé clinique avec citations exactes du dossier (tags `[XX-N]`)
|
||||
2. **Axe asymétrie d'information** — éléments que la CPAM n'avait pas (biologie, imagerie, traitements)
|
||||
3. **Axe réglementaire** — erreurs d'interprétation avec citations verbatim des sources
|
||||
|
||||
**Contraintes clés** :
|
||||
- Doit reconnaître au moins un point valide de la CPAM (crédibilité)
|
||||
- Codes CIM-10 toujours cités explicitement avec libellé
|
||||
- Références au format `[Document - page N]` + citation verbatim
|
||||
- Prend en compte âge, mode d'entrée, durée de séjour
|
||||
|
||||
**Sortie JSON** : `analyse_contestation`, `points_accord`, `contre_arguments_medicaux`, `preuves_dossier[{ref, element, valeur, signification}]`, `contre_arguments_asymetrie`, `contre_arguments_reglementaires`, `references[{document, page, citation}]`, `conclusion`
|
||||
|
||||
---
|
||||
|
||||
## 7. CPAM_ADVERSARIAL — Passe 3 : validation adversariale
|
||||
|
||||
| Paramètre | Valeur |
|
||||
|-----------|--------|
|
||||
| **Rôle** | `validation` |
|
||||
| **Température** | 0.0 |
|
||||
| **Max tokens** | 800 |
|
||||
| **Appelé par** | `cpam_response.py → _validate_adversarial()` |
|
||||
|
||||
**Variables** : `response_json`, `factual_section`, `normes_section`, `dp_ucr_line`, `da_ucr_line`
|
||||
|
||||
**Fonction** : Relecture critique de la contre-argumentation générée. Vérifie :
|
||||
1. Les valeurs citées existent dans les éléments factuels
|
||||
2. Les qualifications bio (élevée/basse) respectent les normes de référence
|
||||
3. La conclusion est cohérente avec l'argumentation
|
||||
4. Les points d'accord ne contredisent pas les contre-arguments
|
||||
5. Les codes CIM-10 de la conclusion sont cohérents
|
||||
|
||||
**Point architectural** : ce prompt utilise le rôle `validation` (modèle **différent** du générateur) pour garantir une vérification indépendante.
|
||||
|
||||
**Sortie JSON** : `coherent` (bool), `erreurs[]`, `score_confiance` (0-10)
|
||||
|
||||
---
|
||||
|
||||
## Architecture multi-modèles
|
||||
|
||||
Les rôles LLM sont définis dans `src/config.py` :
|
||||
|
||||
| Rôle | Modèle par défaut | Variable d'env |
|
||||
|------|-------------------|----------------|
|
||||
| `coding` | `gemma3:27b-cloud` | `T2A_MODEL_CODING` |
|
||||
| `cpam` | `deepseek-v3.2:cloud` | `T2A_MODEL_CPAM` |
|
||||
| `validation` | `deepseek-v3.2:cloud` | `T2A_MODEL_VALIDATION` |
|
||||
| `qc` | `gemma3:12b` | `T2A_MODEL_QC` |
|
||||
|
||||
Le rôle `validation` utilise volontairement un modèle différent du `cpam` pour éviter l'auto-validation.
|
||||
Reference in New Issue
Block a user