Aivanov_scan_ogc

Dom/Aivanov_scan_ogc

Fork 0

Commit Graph

Author	SHA1	Message	Date
Dom	3f2e2ee9f4	feat(extract): second passage VLM sur crop colonne Recodage (P0) Qwen ne lit systématiquement que la colonne de gauche du tableau Codage quand on lui donne la page recueil entière : la colonne droite (Recodage) a 27% de couverture en V2.0 avec 100% de validité — une régression majeure puisque c'est le cœur métier du contrôle T2A. Solution : après le passage principal, refaire une extraction dédiée sur un crop zonal de la seule colonne Recodage (y=0.330→0.490 pour exclure le bloc Actes adjacent). Prompt strict anti-hallucination ("beaucoup de lignes sont vides, n'invente rien"). Le résultat écrase partiellement `codage_reco` (DP/DR/DAS) dans le JSON principal. Classification Python par règle métier : - 1er code sans position → DP - 2e code sans position → DR (ignoré si == DP : Qwen duplique parfois) - codes avec position → DAS Filtre CIM-10 par regex en Python pour retirer les codes CCAM (actes) qui pourraient rester si le crop déborde. Ajout d'une env var `QWEN_MAX_PIXELS` (défaut 800) pour ajuster la consommation VRAM sur machines avec GPU partagé (test sur RTX 5070 avec rpa_vision_v3 en parallèle). Ajout de `torch.cuda.empty_cache()` après chaque inférence pour réduire la fragmentation VRAM sur exécutions longues. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-24 15:54:35 +02:00
Dom	ed4d9bd765	feat(pipeline): extraction OGC via Qwen2.5-VL-3B Pipeline modulaire remplaçant le monolithe extract_ogc.py (conservé en legacy pour comparaison). Modules : - ingest.py : PDF → PNG 300dpi avec cache par SHA256 - ocr_qwen.py : wrapper singleton Qwen2.5-VL-3B (bfloat16, ~7 Go VRAM) - ocr_glm.py : wrapper GLM-OCR 0.9B (alternatif, conservé) - classify.py : détection type de page + routing par index standard (ordre des 6 pages OGC → -50% d'appels OCR) - prompts.py : JSON schemas par type (recueil, concertation 1/2/2/2, preuves) + mots-clés de classification - checkboxes.py : détection Accord/Désaccord par densité de pixels (inner-frac 0.35, 17/17 corrects sur échantillon vérifié ; GLM-OCR et Qwen échouent sur les checkboxes, cf. scratch/test_prompt_crop_v2.py) - extract.py : orchestration 1 dossier (ingest → classify → OCR → parse JSON tolérant aux boucles + validation ATIH) - persist.py : sauvegarde JSON + metadata (pipeline_version, ocr_model, timestamp) - cli.py : `python -m pipeline.cli <pdf\|dir>` Temps mesuré : ~35s/dossier (6 pages) sur RTX 5070. Qwen2.5-VL-3B retenu après comparaison avec GLM-OCR 0.9B, GOT-OCR2.0, Surya, PaddleOCR (cf. scratch/). Il extrait correctement dp_libelle, praticien_conseil et les 4 GHM/GHS là où les autres échouent. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-24 15:05:40 +02:00

Author

SHA1

Message

Date

Dom

3f2e2ee9f4

feat(extract): second passage VLM sur crop colonne Recodage (P0)

Qwen ne lit systématiquement que la colonne de gauche du tableau
Codage quand on lui donne la page recueil entière : la colonne droite
(Recodage) a 27% de couverture en V2.0 avec 100% de validité — une
régression majeure puisque c'est le cœur métier du contrôle T2A.

Solution : après le passage principal, refaire une extraction dédiée
sur un crop zonal de la seule colonne Recodage (y=0.330→0.490 pour
exclure le bloc Actes adjacent). Prompt strict anti-hallucination
("beaucoup de lignes sont vides, n'invente rien"). Le résultat écrase
partiellement `codage_reco` (DP/DR/DAS) dans le JSON principal.

Classification Python par règle métier :
- 1er code sans position  → DP
- 2e code sans position   → DR (ignoré si == DP : Qwen duplique parfois)
- codes avec position     → DAS

Filtre CIM-10 par regex en Python pour retirer les codes CCAM (actes)
qui pourraient rester si le crop déborde.

Ajout d'une env var `QWEN_MAX_PIXELS` (défaut 800) pour ajuster la
consommation VRAM sur machines avec GPU partagé (test sur RTX 5070
avec rpa_vision_v3 en parallèle).

Ajout de `torch.cuda.empty_cache()` après chaque inférence pour
réduire la fragmentation VRAM sur exécutions longues.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-24 15:54:35 +02:00

Dom

ed4d9bd765

feat(pipeline): extraction OGC via Qwen2.5-VL-3B

Pipeline modulaire remplaçant le monolithe extract_ogc.py (conservé
en legacy pour comparaison).

Modules :
- ingest.py      : PDF → PNG 300dpi avec cache par SHA256
- ocr_qwen.py    : wrapper singleton Qwen2.5-VL-3B (bfloat16, ~7 Go VRAM)
- ocr_glm.py     : wrapper GLM-OCR 0.9B (alternatif, conservé)
- classify.py    : détection type de page + routing par index standard
                   (ordre des 6 pages OGC → -50% d'appels OCR)
- prompts.py     : JSON schemas par type (recueil, concertation 1/2/2/2,
                   preuves) + mots-clés de classification
- checkboxes.py  : détection Accord/Désaccord par densité de pixels
                   (inner-frac 0.35, 17/17 corrects sur échantillon vérifié ;
                   GLM-OCR et Qwen échouent sur les checkboxes, cf.
                   scratch/test_prompt_crop_v2.py)
- extract.py     : orchestration 1 dossier (ingest → classify → OCR →
                   parse JSON tolérant aux boucles + validation ATIH)
- persist.py     : sauvegarde JSON + metadata (pipeline_version,
                   ocr_model, timestamp)
- cli.py         : `python -m pipeline.cli <pdf|dir>`

Temps mesuré : ~35s/dossier (6 pages) sur RTX 5070.

Qwen2.5-VL-3B retenu après comparaison avec GLM-OCR 0.9B, GOT-OCR2.0,
Surya, PaddleOCR (cf. scratch/). Il extrait correctement dp_libelle,
praticien_conseil et les 4 GHM/GHS là où les autres échouent.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-24 15:05:40 +02:00

2 Commits