Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
de73cbd404cf9fa9198d1ab020c2ceea5b2eaedb
rpa_vision_v3/docs/recherche/AXE_A5_SCREEN_TOKENIZATION.md

21 KiB
Raw Blame History

AXE A5 — Tokenisation d'écran (OmniParser, Set-of-Marks, modèles natifs)

Date : 2026-05-23 Auteur : Claude (agent dispatché par session principale) Statut : lecture seule, recherche pour arbitrage post-démo. Pas d'action proposée. Axes liés : A1 (modèles VLM grounding), A4 (OCR/docTR/RapidOCR), CLAUDE.md §asymétrie record/replay.

1. TL;DR

Recommandation : Scénario B (log implicite, no risk) maintenant, Scénario A (OmniParser V2 dans la cascade replay) à instruire post-démo, Scénario C (OS-Atlas / GUI-Actor) à benchmarker en R&D mais hors trajectoire courte.

Top finding : core/detection/som_engine.py est déjà câblé sur les weights OmniParser (/home/dom/ai/OmniParser/weights/icon_detect/model.pt, YOLOv8) côté serveur. Utilisé en recording (stream_processor.py:607-638) ET déclaré dans une voie _resolve_set_of_marks du resolve_engine.py:1083-1325. L'asymétrie pointée par CLAUDE.md n'est donc pas "UI-DETR-1 vs rien", elle est "SomEngine activé selon les paths". À vérifier au runtime si _resolve_set_of_marks est effectivement appelé en replay — possible code orphelin (cf. champs de mines CLAUDE.md).

Trois faits 2025 qui changent l'arbitrage :

  1. OmniParser V2 (publié 12 février 2025, MIT pour le code + Florence-2, AGPL-3.0 pour les poids YOLOv8 icon_detect) — 0.6 s/frame A100, 0.8 s/frame RTX 4090, état de l'art ScreenSpot-Pro 39.6 % combiné GPT-4o. Notre RTX 5070 ≈ 12 GB VRAM tient le pipeline complet (icon_detect ~150 MB + Florence-2 base ~750 MB).
  2. Set-of-Mark (Yang et al., arXiv 2310.11441, NeurIPS 2023) — pattern qui sous-tend OmniParser, Magma, ShowUI. Devenu vocabulaire standard du domaine en 2025.
  3. Coordinate-free grounding émerge : GUI-Actor (Microsoft, NeurIPS 2025) et Aguvis (ICML 2025) bypassent le besoin d'un étage de tokenisation séparé. GUI-Actor-7B sur Qwen2.5-VL = 44.6 % ScreenSpot-Pro, > UI-TARS-72B. Tendance : la tokenisation explicite OmniParser-style devient un raccourci d'aujourd'hui que les VLM "GUI-natifs" intégreront demain.

Verdict honnête pour rpa_vision_v3 : la cause des bugs récents (cf. REPLAY_BLOCAGE_NOTES_MEDICALES_2026-05-08.md) est transport HTTP + OCR-DIRECT center-of-line, pas la cascade vision. Ajouter OmniParser V2 en replay ne réparera rien des bugs P0 ouverts. Mais c'est la brique manquante pour le Validator (Skyvern-style) et pour un log de candidats parsés côté replay (suggestion §4.1 de INSPIRATION_FRAMEWORKS).

2. OmniParser V2 — fiche détaillée

2.1. Identité

2.2. Architecture interne (2 modèles)

Sous-modèle Rôle Taille Backend Licence
icon_detect YOLOv8 fine-tuné sur dataset Microsoft d'éléments interactifs (boutons, icônes, champs) ~150 MB Ultralytics YOLO AGPL-3.0 ⚠
icon_caption Florence-2 base fine-tuné sur 7K paires icon-description annotées GPT-4o ~750 MB Transformers MIT

OCR : OmniParser embarque aussi un OCR (PaddleOCR ou EasyOCR selon config). Notre som_engine.py actuel a remplacé par docTR (cf. lignes 117-127).

2.3. Format de sortie ("interactable elements")

Liste de dicts avec :

  • bbox (coordonnées normalisées 0-1)
  • interactivity (true / false)
  • content (caption Florence-2 : "close button", "search field", "OK")
  • source ("box_yolo_content_ocr" / "box_yolo_content_yolo" / "icon")

Cette sortie est conçue pour être insérée dans le prompt du VLM principal (GPT-4o, Claude) sous forme de tableau numéroté → c'est du Set-of-Marks appliqué automatiquement.

2.4. Performance benchmarks

Métrique Valeur Source
ScreenSpot-Pro + GPT-4o 39.6 % Microsoft Research article 2026-02-12
ScreenSpot-Pro GPT-4o seul (sans OmniParser) 0.8 % idem
Latence A100 (1 frame) 0.6 s idem
Latence RTX 4090 (1 frame) 0.8 s idem
VRAM mini 4 GB (inference) / 8 GB (recommandé loop agent) GitHub Issue #31
Résolution supportée 640 → 1920 px côté long (icon_detect) doc HF V2.0

Implication directe rpa_vision_v3 : nos screenshots Léa sont 2560×1600 (RTX 5070). Il faudra resize à 1920 px côté long → ratio ~0.75. Toutes les coordonnées YOLO de retour doivent être re-scalées. Risque : c'est le même piège que smart_resize Qwen2.5-VL bbox_2d (DETTE-006/010/014, MIGRATION_VLM_PLAN_2026-05-09.md §2). À traiter explicitement.

2.5. Licence — point sensible commercial

Combinaison AGPL-3.0 (icon_detect) + MIT (icon_caption + code) :

  • AGPL-3.0 sur icon_detect = interdit en produit commercial fermé sans rachat de licence YOLOv8 commercial (Ultralytics, ~5 000 $/an estimé), ou remplacement par un détecteur alternatif (Florence-2 task <OD>, ou détecteur custom).
  • Pour rpa_vision_v3 en POC interne / GHT / Anoust : usage actuel défendable. Pour vente externe : showstopper sur icon_detect tel quel.

Le code de notre som_engine.py charge directement /home/dom/ai/OmniParser/weights/icon_detect/model.pt (AGPL-3.0) → audit licence à reprendre.

2.6. État interne du projet — code existant

  • core/detection/som_engine.py (316 lignes, complet) — singleton thread-safe, YOLO + docTR + annotation. Device par défaut cpu (cf. get_shared_engine).
  • core/detection/omniparser_adapter.py — wrapper plus complet citant Florence-2 caption. Sépare du som_engine.py simplifié.
  • agent_v0/server_v1/stream_processor.py:607-700 — appel SoM au recording pour enrichir chaque event click avec l'élément cliqué (cf. UI-DETR-1 dans INSPIRATION_FRAMEWORKS_2026-05-10.md §4 — c'est en fait SoM, pas un détecteur tiers).
  • agent_v0/server_v1/resolve_engine.py:1083-1325 — voie _resolve_set_of_marks au replay. Lance SomEngine, fallback template matching anchor↔éléments YOLO. À tracer au runtime pour confirmer qu'elle est invoquée.

→ L'asymétrie record/replay décrite dans CLAUDE.md n'est peut-être pas l'asymétrie réelle. À valider explicitement avec Dom au prochain run.

3. Set-of-Marks original

3.1. Identité

3.2. Approche

  1. Segmenter l'image en régions sémantiques (SEEM ou SAM, off-the-shelf)
  2. Overlayer chaque région avec un mark (numéro, lettre, masque coloré, bbox)
  3. Demander au VLM : "click on mark 7" plutôt que "click at (x=420, y=380)"

Bénéfice : le VLM raisonne en identifiants discrets et non en coordonnées continues. Évite le bug des coords mal calibrées (cf. notre DETTE-006 bbox_2d Qwen2.5-VL).

3.3. Résultats clés (papier 2023)

GPT-4V + SoM en zero-shot bat le SOTA fine-tuned sur RefCOCOg (referring expression comprehension). Pour la première fois, un modèle généraliste prompted dépasse les modèles spécialisés sur ce benchmark.

3.4. Complémentarité avec OmniParser

  • SoM = méthode de prompting (overlay sur l'image, le VLM répond un ID)
  • OmniParser = pipeline complet (détection + caption + format prompt)
  • OmniParser = "SoM industrialisé pour les UIs". OmniParser fournit les régions ET les marks ET les captions, contre SoM original qui fournit seulement les marks à partir d'une segmentation SEEM/SAM générique.
  • Magma (Microsoft, CVPR 2025) entraîne explicitement le modèle sur des images SoM-labellisées → SoM passe de "trick de prompting" à "supervision de pré-entraînement".

4. Modèles VLM qui tokenisent nativement

4.1. OS-Atlas-Base (ICLR 2025)

  • Repo : https://github.com/OS-Copilot/OS-Atlas
  • Modèles : OS-Atlas-Base-4B (sur InternVL2-4B) et OS-Atlas-Base-7B (sur Qwen2-VL-7B-Instruct)
  • Approche : entraînement sur 13 M éléments GUI cross-platform (Windows, Linux, macOS, Android, web). Tokens spéciaux <|box_start|>(x1,y1),(x2,y2)<|box_end|>. Coordonnées normalisées 0-1000.
  • Tokenise nativement ? Pas au sens "produit une liste d'éléments en sortie", mais internalise la grammaire bbox comme tokens spéciaux. Le modèle apprend que "(124, 380) → (228, 412)" est une bbox, pas une séquence d'entiers libres.
  • Coût : OS-Atlas-Base-7B = ~14 GB FP16, ~7 GB en 4-bit. Compatible RTX 5070 12 GB en 4-bit ou avec Flash-Attn.

4.2. ShowUI-2B (CVPR 2025, Outstanding Paper NeurIPS 2024 workshop)

  • Repo : https://github.com/showlab/ShowUI
  • HF : https://huggingface.co/showlab/ShowUI-2B
  • Innovation clé : UI-Guided Visual Token Selection — construit un graphe UI au sein du modèle, élimine 33 % des tokens visuels redondants. 5× plus rapide, 2× plus précis que les VLM généralistes en localisation.
  • Perf : 75.1 % accuracy zero-shot ScreenSpot grounding avec seulement 2B params + 256K échantillons de training.
  • Tokenise nativement ? Oui, c'est sa nature : la sélection des tokens visuels EST une forme de tokenisation. Pas de pipeline externe.
  • Coût : 2B params → ~4 GB FP16, ~2 GB en 4-bit. Léger pour notre RTX 5070.

4.3. Aguvis (ICML 2025)

  • Repo : https://aguvis-project.github.io/
  • Approche : framework "pure vision" multi-plateforme avec inner monologue structuré. Pipeline 2 étapes (grounding séparé de planification).
  • Caractéristique : premier agent GUI pure-vision entièrement open-source (sans dépendance closed-source).

4.4. GUI-Actor (Microsoft, NeurIPS 2025) — le plus pertinent

  • Repo : https://github.com/microsoft/GUI-Actor
  • HF : https://huggingface.co/microsoft/GUI-Actor-7B-Qwen2.5-VL
  • Innovation : coordinate-free. Au lieu de produire "(420, 380)", produit un token <ACTOR> qui s'attache via attention aux patches visuels pertinents. Génère plusieurs régions candidates en 1 forward.
  • Perf : GUI-Actor-7B sur Qwen2.5-VL = 44.6 % ScreenSpot-Pro (> UI-TARS-72B).
  • Implication directe : tue le bug d'échelle bbox_2d (DETTE-006/010/014) à la racine. Pas de smart_resize à débugger. Pas de mismatch de résolution.
  • Coût : 7B + Qwen2.5-VL → ~14 GB FP16, ~7 GB 4-bit. Compatible RTX 5070 en 4-bit.

4.5. Magma (Microsoft, CVPR 2025)

  • Repo : https://github.com/microsoft/Magma
  • Approche : pré-entraînement multimodal avec Set-of-Mark labellisation automatique des éléments cliquables + Trace-of-Mark pour la planification d'actions (videos). Premier modèle multi-domaine (GUI + robotique).
  • Tokenise nativement ? Oui, SoM est dans la supervision de pré-entraînement, pas une étape inférence externe.

5. Comparaison latence / perf / robustesse

5.1. Tableau synthèse

Approche Latence / écran 2560×1600 VRAM Sortie Licence Tokenise nativement ?
UI-DETR-1 record-only (actuel) n/a (recording offline) n/a événements VWB enrichis propriétaire MS non, étape séparée
SomEngine actuel (YOLO icon_detect + docTR) ~150-300 ms estimé (docTR seul ~100 ms, YOLO ~15 ms, +overhead annotation) ~1 GB liste SomElement AGPL-3.0 (YOLO) non
OmniParser V2 complet (YOLO + Florence-2 caption) 0.8 s (RTX 4090) → ~1.0 s (RTX 5070 estimé) après resize 1920 ~2 GB liste interactable_element + caption sémantique AGPL-3.0 + MIT non
YOLOv8-UI fine-tuned custom (sans caption) ~50-100 ms ~200 MB bbox seules AGPL-3.0 par défaut, MIT possible si from scratch non
ShowUI-2B grounding direct, ~1-2 s estimé ~2-4 GB coord ou région code MIT oui (UI-guided token selection)
GUI-Actor-7B grounding direct, ~2-3 s estimé ~7-14 GB régions multiples via attention code MIT oui (attention head dédiée)
OS-Atlas-Base-7B grounding direct, ~2-3 s estimé ~7-14 GB bbox tokens spéciaux code MIT (modèle Qwen2-VL Apache 2.0) partiellement
InfiGUI-G1-3B (actuel) déjà mesuré ~1-2 s 3.9 GB bbox Apache 2.0 (Qwen) partiellement

5.2. Robustesse — ce que dit la littérature 2025

  • GUI-Robust (arXiv 2506.14477) : tous les MLLM (y compris GUI-spécialisés) se dégradent significativement sur 7 types d'anomalies (popups, modifications de layout, désactivation). OmniParser ne corrige PAS ces anomalies à lui seul — il aide à voir les éléments, pas à comprendre les bugs UI.
  • Magma + SoM (CVPR 2025) : SoM en supervision > SoM en prompting inference-only. Confirme que la prochaine génération est "SoM natif", pas "OmniParser externe".

5.3. Comparaison concrète avec notre cascade actuelle

Notre cascade _resolve_target (cf. cartography_execution_flow.md) :

OCR docTR (~200 ms) → template cv2 (~50 ms) → YOLO/SoM optionnel → VLM (1-15 s)

Avec SomEngine déjà existant et OmniParser V2 disponible localement (/home/dom/ai/OmniParser/), le coût marginal d'ajouter le caption Florence-2 = ~500-700 ms (Florence-2 base). Total cascade enrichie : ~2 s vs actuel ~1-15 s suivant l'étage qui réussit. Latence pas un blocker.

6. Recommandation pour rpa_vision_v3 — 3 scénarios

Scénario A — Intégrer OmniParser V2 complet dans la cascade replay

Description : activer _resolve_set_of_marks en replay, brancher icon_caption Florence-2 pour enrichir les éléments YOLO avec des descriptions sémantiques, exposer cette "vue parsée" à VWB UI et au VLM principal en prompt.

Pour :

  • Asymétrie record/replay corrigée explicitement.
  • Vue parsée disponible pour debug (UI VWB pourrait overlayer les éléments détectés sur captures Léa).
  • Caption Florence-2 = donnée d'entrée pour un Validator sémantique post-clic (compare "j'attendais Notes médicales" vs "j'ai cliqué sur élément captioned 'Imagerie tab'").
  • Coût latence ~1 s — compatible démo.

Contre :

  • Licence AGPL-3.0 sur icon_detect → audit légal avant déploiement commercial Anoust / GHT vente.
  • N'efface AUCUN des 5 bugs P0 post-démo (transport HTTP, Stop VWB, mss monitors, échelle pixel, skip ord 13).
  • Ajoute une dépendance lourde (/home/dom/ai/OmniParser/) au runtime.
  • Le bug primaire diagnostiqué 8 mai est OCR-DIRECT center-of-line, pas un manque de candidats détectés.

Effort : 1-2 j (le code SomEngine existe, manque le câblage Florence-2 caption + UI debug).

Risque : moyen-faible. Tout est déjà en place côté code.

Scénario B — Log implicite des candidats (no risk, à faire dès stabilisation post-démo)

Description : à chaque appel _resolve_target, logger systématiquement dans logs/audit/ la liste des candidats produits par CHAQUE étage de la cascade (docTR lignes/spans, template matches > seuil, sorties YOLO si SomEngine actif, sorties VLM). JSON structuré, 1 ligne par résolution.

Pour :

  • Zéro nouveau modèle, zéro nouvelle dépendance. Pure instrumentation.
  • Vue parsée gratuite, exploitable hors-bande (analyse, dashboard).
  • Comble l'asymétrie record/replay au sens "trace équivalente".
  • Préalable indispensable à tout Validator sémantique futur.
  • Aligné avec la suggestion §4.1 de INSPIRATION_FRAMEWORKS_2026-05-10.md ("logger systématiquement la liste des candidats détectés par chaque étage de la cascade").

Contre :

  • N'apporte aucune nouvelle robustesse en propre — juste de l'observabilité.

Effort : 0.5 j.

Risque : très bas.

→ À faire en priorité, indépendamment des autres scénarios.

Scénario C — Remplacer la cascade par un modèle VLM qui tokenise nativement

Description : remplacer _resolve_target par un appel direct à GUI-Actor-7B (ou ShowUI-2B en option légère) qui produit la zone-cible en coordinate-free. Peut coexister avec OCR docTR pour validation post-action.

Pour :

  • Tue le bug d'échelle bbox_2d (DETTE-006/010/014) — plus de smart_resize à débugger.
  • État de l'art ScreenSpot-Pro (44.6 % GUI-Actor > UI-TARS-72B).
  • Architecture plus simple long-terme : 1 modèle = 1 grounder.
  • ShowUI-2B = 2× moins gourmand que notre InfiGUI-G1-3B actuel.

Contre :

  • Décision structurelle, pas réversible facilement. Réécrit la moitié de resolve_engine.py.
  • Aucun bench interne pour valider sur nos écrans Easily / Citrix réels.
  • Pas de caption sémantique = pas de Validator sémantique post-action.
  • Effort production-grade : 1-2 semaines.

Effort : 5-10 j.

Risque : élevé tant que pas benché sur nos workflows.

7. Recommandation finale

Maintenant (post-démo, semaine du 26 mai) :

  1. Scénario B obligatoirement — log des candidats. Coût minimal, valeur immense pour debug futur.
  2. Vérifier au runtime si _resolve_set_of_marks est appelé en replay. Si non = code orphelin (CLAUDE.md §champs de mines). Si oui = on est déjà mi-Scénario A sans le savoir.
  3. Audit licence AGPL-3.0 sur icon_detect avant tout pitch commercial.

Sprint suivant (juin si bande passante) : 4. Scénario A partiel — activer Florence-2 icon_caption sur l'événement de recording VWB ET sur les résolutions en échec replay (sentinelle, pas systématique). Caption disponible pour un Validator sémantique futur. 5. Bench GUI-Actor-7B et ShowUI-2B sur 10-20 captures Easily Assure réelles. Décision Scénario C uniquement sur preuves.

À ne PAS faire :

  • Activer OmniParser V2 systématiquement en runtime tant que les 5 bugs P0 (LESSONS_LEARNED_GHT_2026-05.md) ne sont pas refermés. Latence supplémentaire sur démo fragile.
  • Remplacer InfiGUI-G1-3B sans bench comparatif documenté.

8. Sources

OmniParser V2

Set-of-Marks

Modèles GUI natifs 2025

Florence-2 (sous-jacent OmniParser icon_caption)

Robustesse GUI agents

Computer use / pure vision

Référence interne

  • core/detection/som_engine.py (316 lignes) — SomEngine YOLO + docTR déjà câblé
  • core/detection/omniparser_adapter.py — wrapper Florence-2 caption
  • agent_v0/server_v1/resolve_engine.py:1083-1325 — voie _resolve_set_of_marks au replay
  • agent_v0/server_v1/stream_processor.py:607-700 — SoM au recording
  • docs/INSPIRATION_FRAMEWORKS_2026-05-10.md §4 — vague d'inspirations frameworks RPA visuels
  • docs/SYNTHESE_TECHNOS_REPLAY_2026-05-23.md §5.3 — note sur l'asymétrie OmniParser ↔ cascade
  • docs/MIGRATION_VLM_PLAN_2026-05-09.md §2 — bug d'échelle bbox_2d (lien Scénario C)
  • docs/LESSONS_LEARNED_GHT_2026-05.md §🔴 — 5 bugs P0 qui restent prioritaires sur tout ajout d'étage
Reference in New Issue View Git Blame Copy Permalink