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

26 KiB
Raw Blame History

AXE C — Shadow learning, Fine-tuning VLM grounding, Memory store visuel

Date : 2026-05-23 Auteur : Claude (agent recherche prospective) Statut : lecture seule, recherche externe + croisement avec dette interne (DETTE-005, DETTE-009). Aucune modif de code. Sources web < 6 mois priorisées. Périmètre : 3 sous-axes prospectifs sur l'apprentissage et la mémoire visuelle pour rpa_vision_v3.

1. TL;DR + recommandation priorisée

Insight central : les 3 axes (C1 Shadow, C2 Fine-tuning, C3 Memory) ne sont pas substituables mais séquentiels :

  • C3 (memory) est l'investissement le plus immédiatement rentable : VisualEmbeddingManager est déjà écrit, le pattern Skyvern (cache + fallback IA) est éprouvé à 10–100× speed-up, et ça réduit la latence de la démo SANS toucher au grounding.
  • C1 (shadow) est la collecte de carburant pour C2 : sans traces propres (DETTE-009), pas de dataset de fine-tuning Easily Assure. ShadowLearningHook orphelin = blocage prioritaire à lever.
  • C2 (fine-tuning) est le différenciateur à 6–12 mois : la littérature 2025–2026 (Visual-RFT, UI-R1, GUI-R1, SE-RFT, GUI-Actor) prouve qu'on peut atteindre SOTA avec 3k–10k exemples via GRPO sur Qwen2.5-VL-3B/7B, pour quelques dizaines d'euros HF Jobs. Mais ça suppose un dataset propre, donc C1 d'abord.

Séquence recommandée :

  1. Vague courte (1–2 semaines) : activer VisualEmbeddingManager (C3) en cache opportuniste devant la cascade _resolve_target + activer ShadowLearningHook (C1) sur les replays réussis. Aucun ML, juste du câblage.
  2. Vague moyenne (1–2 mois) : collecter ≥ 1k traces Shadow propres sur Easily Assure via la démo récurrente, formaliser le format de trace inspiré OpenAdapt (SQLite trajectoires).
  3. Vague longue (3–6 mois post-démo client) : fine-tuning GRPO Qwen2.5-VL-3B sur 3k–5k exemples Easily Assure spécifiques, via HF Jobs ou DGX Spark. Coût attendu < 50 €.

Dépendance critique avec AXE_B2 Validator : un Shadow learning sur traces sales (replay qui croit avoir réussi mais a cliqué à côté — cf. bug step 10 Imagerie/bandeau Edge) injecte du poison dans la mémoire. Le Validator sémantique doit précéder l'activation de C1, sinon SignatureStore accumule des faux positifs.

2. C1 — Shadow learning : OpenAdapt + ShadowLearningHook orphelin

2.1 OpenAdapt — pipeline détaillé

Repo : github.com/OpenAdaptAI/OpenAdapt (~7k★ mai 2026)

Architecture meta-package modulaire (refonte récente vs monorepo initial) :

Sous-paquet Rôle
openadapt-capture Enregistrement actions utilisateur + screenshots → SQLite. Paires observation/action = "trajectoires".
openadapt-privacy Scrub PII/PHI avant stockage (intérêt direct pour notre démo médicale).
openadapt-retrieval Index sémantique (FAISS-like) sur les démonstrations stockées.
openadapt-ml Moteur ML : charge trajectoires, fine-tune VLM, génère templates automation.
openadapt-grounding Mappe intention → coords UI au runtime.
openadapt-evals Bench sur benchmarks publics.

Pipeline complet : Demonstrate → Learn → Execute. La devise "success traces become new training data" (citée INSPIRATION_FRAMEWORKS_2026-05-10.md §5) est instanciée par : openadapt-capture (Demonstrate) → openadapt-ml (Learn fine-tune VLM) → openadapt-grounding (Execute conditionné sur les démos via retrieval ET fine-tuning, combinés).

Format de trace (déduit du repo, pas accessible en détail sans cloner) : table SQLite recordings + tables screenshots, action_events, window_events, chaînées par recording_id. Chaque clic = ligne action_events avec coords + screenshot lié + window title. Schéma très proche de notre data/runner_captures/ actuel + métadonnées agent_v0.

Différenciateur : OpenAdapt conditionne au runtime l'agent sur des démos humaines récupérées via retrieval sémantique. C'est la combo cache + fine-tuning + grounding que rpa_vision_v3 a en pièces détachées (TargetMemoryStore Phase 1 = retrieval embryonnaire, ShadowLearningHook = capture, fine-tuning = TODO).

2.2 Comment activer ShadowLearningHook orphelin (DETTE-009)

Constat investigation INVESTIGATION_MEMOIRE_VISUELLE_ORPHELINE_2026-05-09.md :

  • Fichier : core/grounding/shadow_learning_hook.py (156 lignes, commit 73cea2385 du 2026-04-25, "Phase 6").
  • 0 site d'instanciation au runtime.
  • Attend un callback on_click_observed(x, y, screenshot, window_title, target_label) qui n'est jamais appelé.
  • Le ShadowObserver (core/workflow/shadow_observer.py) ne configure aucun callback de ce type.
  • Phase 5 (e2046837c) câble FAST→SMART→THINK dans ORA mais oublie d'instancier la Phase 6.

Hooks d'activation envisageables (à valider avec Dom avant code) :

Point d'accroche Avantage Risque
Callback dans ShadowObserver._on_mouse_click Apprentissage en temps réel sur démo humaine Pollution si Validator absent (cf. dépendance B2)
Hook post-success dans replay_engine.py (après REPORT success=True) Apprentissage uniquement sur traces "vérifiées" Faux positifs si pHash global laxiste (bug step 10 connu)
Job offline batch sur data/runner_captures/<session>/events.jsonl Aucun risque runtime, repassable Pas de boucle d'amélioration continue

Recommandation : commencer par le job batch offline (sécurisé), puis migrer vers post-success hook quand AXE_B2 Validator sémantique sera en place. Ne PAS activer sur ShadowObserver direct tant que Validator pHash global est en vigueur — c'est précisément ce que feedback_phash_vs_dialog_in_vm.md reproche.

2.3 Autres frameworks — patterns Shadow 2025–2026

  • Skyvern : pattern "explore → replay" déterministe. Quand un agent réussit une tâche, le sélecteur (ou la coord visuelle) est mémorisé dans un cache indexé par cache_key Jinja2 rendu à partir des paramètres du workflow. Réutilisation 10–100× plus rapide. Si le cache miss ou si replay échoue, fallback IA + mise à jour du cache. (deepwiki)
  • browser-use : tableau learned_skills avec success_rate, usage_count, last_used. Modèle de skills nommés réutilisables. (source)
  • AGUVIS : 4.2M trajectoires GUI multimodales (grounding + planning). Format normalisé multi-OS. (aguvis-project)
  • UGround : 10M éléments / 1.3M screenshots, ~95% web. Dataset le plus volumineux du domaine. (osu-nlp-group)

2.4 Datasets RPA traces publiquement disponibles

Repérés via Computer-Browser-Phone-Use-Agent-Datasets :

  • AGUVIS — 4.2M sample elements + 1.3M trajectoires (license à vérifier).
  • UGround — 10M GUI elements, ~95% web (license à vérifier).
  • ScreenSpot / ScreenSpot-v2 / ScreenSpot-Pro — benchmarks d'évaluation, pas vraiment training (mais utilisables en few-shot).
  • AndroidControl — mobile, utilisé par UI-R1.
  • Mind2Web — web tasks.
  • WebVoyager — Skyvern à 85.85%, benchmark.

Aucun de ces datasets ne couvre Easily Assure ni le domaine hospitalier français. Ils servent de base pré-entraînement, pas de dataset cible. Notre asset : les traces internes de la démo MOREL Catherine et autres.

2.5 Recommandation d'intégration C1

Court terme (1–2 semaines) :

  1. Job batch offline : itérer sur data/runner_captures/<session>/events.jsonl post-démo réussie, appeler ShadowLearningHook.on_click_observed rétrospectivement → enrichit SignatureStore.
  2. Mesurer le hit-rate de SignatureStore au replay suivant.

Moyen terme (1 mois) : 3. Définir notre format de trace canonique (inspirer du schéma OpenAdapt SQLite + privacy scrub avant tout). 4. Brancher le hook sur ShadowObserver._on_mouse_click UNIQUEMENT après merge du Validator sémantique (B2).

Anti-pattern à éviter : activer le hook sur des replays VWB sans Validator. Cf. bug step 10 mai : on apprendrait à cliquer dans le bandeau Edge au lieu du tab Imagerie.

3. C2 — Fine-tuning VLM grounding 2025–2026

3.1 Table comparée des techniques

Méthode Modèle base Données Gain vs SFT Source
Visual-RFT (mars 2025) Qwen2-VL-2B / 7B 239 images (LISA few-shot) à 500 steps +24.3% classif, +21.9 mAP COCO 2-shot arxiv 2503.01785
UI-R1 (AAAI 2026, mars 2025) Qwen2.5-VL-3B 2k–3k exemples +22.1% ScreenSpot, +6.0% ScreenSpot-Pro, +12.7% AndroidControl github UI-R1
GUI-R1 (avril 2025) Qwen2.5-VL 3k exemples (0.02% du training OS-Atlas) Bat OS-Atlas-7B SFT sur tous les bench arxiv 2504.10458
GUI-G1 (mai 2025) Qwen2.5-VL R1-Zero style Analyse théorique R1 grounding openreview
SE-GUI / SE-RFT (mai 2025) 7B 3k samples SOTA ScreenSpot-Pro auto-supervisé arxiv 2505.12370
GUI-Actor (NeurIPS 2025) Qwen2.5-VL-7B Coordinate-free grounding 42.2/44.6 ScreenSpot-Pro microsoft/GUI-Actor
GUI-CURSOR (2025) Qwen2.5-VL-7B — 88.8→93.9 SS-v2, 26.8→56.5 SS-Pro arxiv 2509.21552
POINTS-GUI-G (2026) 8B — 59.9 SS-Pro, 66.0 OSWorld-G arxiv 2602.06391
GUI-AIMA (2025) 3B 509k samples / 101k screenshots SOTA data-efficient arxiv 2511.00810

Convergence claire :

  • GRPO (Group Relative Policy Optimization, originaire de DeepSeek-R1) > SFT pour le grounding GUI.
  • Reward function rule-based : IoU pour box, accuracy 0/1 pour clic point, format compliance JSON.
  • Quelques milliers d'exemples suffisent (3k–10k) pour un gain SOTA sur Qwen2.5-VL-3B/7B base.
  • Le base model Qwen2.5-VL domine la littérature (vs UI-TARS, vs InfiGUI).

3.2 Datasets et licences

Dataset Volume License Utilisable commercialement ?
ScreenSpot 1.2k instructions À vérifier (paperswithcode) Probable academic only
ScreenSpot-v2 corrigé v1 OS-Copilot/ScreenSpot-v2 HF À vérifier
ScreenSpot-Pro high-res pro likaixin2000/ScreenSpot-Pro-GUI-Grounding À vérifier
UGround 10M elements OSU-NLP-Group Academic, vérifier CC-BY-NC
AGUVIS 4.2M aguvis-project Académique, vérifier
UI-R1 (modèle + data) 2k–3k Apache-2.0 ✅ Commercial OK
GUI-Actor — Microsoft, MIT-like Commercial OK

Action immédiate : lire chaque LICENSE avant entraînement commercial. La conclusion forte est qu'aucun dataset public ne couvre Easily Assure. La valeur sera dans notre propre dataset interne dérivé des traces démo.

3.3 Plan concret pour fine-tuner sur Easily Assure

Hypothèse de travail : on cible un fine-tuning complémentaire au modèle de base (Qwen2.5-VL-3B ou Qwen3-VL-8B), spécifique au domaine Easily Assure (UI typique, fonts, layout, vocabulaire médical FR).

Étapes proposées (à valider Dom) :

  1. Collecte (C1) : 100 sessions Shadow réussies × ~30 clics utiles = 3 000 paires (screenshot, target_text, click_xy). Ratio compatible UI-R1 / GUI-R1.
  2. Format : JSONL {image_path, instruction, bbox_xyxy_or_point, screen_resolution}. Pré-process via smart_resize officiel (DETTE-014 résolue d'abord).
  3. Anonymisation : appliquer core/anonymize/* (déjà existant t2a) sur chaque crop avant export. Critique pour healthtech.
  4. Méthode : GRPO + LoRA sur Qwen2.5-VL-3B base.
    • Reward function : IoU > 0.5 (cible 1.0, sinon 0) + format JSON valide.
    • 500–1000 steps suffisent (cf. Visual-RFT 200 steps + 500 grounding).
  5. Hardware : HF Jobs / DGX Cloud H100 (8.25 $/h, source — ATTENTION : service deprecated avril 2025, vérifier alternative HF Jobs actuel). Ou DGX Spark Dom roadmap (memory/project_roadmap_vision.md).
    • Alternative cloud GPU 2026 : H100 $4.50–$36/h AWS, $2.99/h en marketplace (spendark).
  6. Durée estimée : 8–12h sur 1× H100 (basé sur QLoRA 7B), ou 4–6h sur 8× H100 parallèle.
  7. Coût estimé : 30–80 € (1 run complet) ou < 10 € si A100 marketplace + QLoRA 3B.
  8. Évaluation : split 80/20 sur les traces internes + non-régression sur ScreenSpot-Pro public.

3.4 LoRA vs Full Fine-Tuning — recommandation

Source clé : arxiv 2410.21228 "LoRA vs Full Fine-tuning: An Illusion of Equivalence" — LoRA introduit des "intruder dimensions" qui réduisent la généralisation hors-domaine.

Mais pour notre cas (spécialisation Easily Assure) :

  • On NE VEUT PAS généraliser — on veut sur-fit (sainement) une UI spécifique.
  • LoRA / QLoRA suffisent : Qwen2.5-VL-3B + LoRA tient sur RTX 4070 12 GB (source).
  • Full FT sur 3B "hit practical limits with unstable loss curves and VRAM pressure" (kaitchup).

Reco : QLoRA 4-bit sur Qwen2.5-VL-3B, rang 16–64. Iteration locale possible sur le RTX 5070 du Dom. Pas besoin HF Jobs pour le prototype. HF Jobs uniquement pour les runs de production.

À éviter : full FT 7B+ pour un usage Easily Assure. ROI insuffisant face à la complexité ops.

4. C3 — Memory store visuel

4.1 Skyvern prompt caching — architecture détaillée

Sources : skyvern deepwiki, skyvern blog MCP, zread optimization

Mécanisme :

  1. Cache key : template Jinja2 rendu à partir des paramètres du workflow (URL cible, valeurs de form, etc.).
  2. Stockage : quand une action AI réussit, Skyvern stocke le selector_path (DOM) ou la coord visuelle.
  3. Replay : runs suivants avec mêmes paramètres → match cache_key → exécute le script pré-généré (Python ou JS), sans appeler le LLM.
  4. Fallback : si replay échoue (UI a changé), AI re-engage automatiquement et met à jour le cache.

Gain mesuré : 10–100× speed-up sur runs cachés. "Deterministic replay flags if a price or SKU changes" — Skyvern utilise les changements détectés comme signal d'invalidation.

Différence vs Anthropic/OpenAI "prompt caching" classique : Skyvern cache les artefacts d'exécution (scripts/sélecteurs), pas les tokens du prompt. C'est plus proche de notre TargetMemoryStore que d'un cache LLM.

Transposable à rpa_vision_v3 :

  • Cache key = (workflow_id, step_id, target_label, target_description, screen_context_hash).
  • Cache value = (click_xy, source: ocr|template|vlm, confidence, last_validated_at).
  • Invalidation = pHash zone d'intérêt change OU REPORT failure récent.

4.2 FAISS + CLIP/DINOv2 vs ColPali/ColQwen — comparaison

Approche Index size Latence query Granularité Pertinence UI
CLIP global + FAISS 1 vec/image (512–768d) < 1 ms Image entière Bonne pour "ai-je déjà vu cet écran"
DINOv2 + FAISS 1 vec/image (768–1536d) < 1 ms Image entière Meilleur que CLIP en self-sup, robuste aux occlusions (source)
DINOv2 crops + FAISS 1 vec/widget (768d) 1–5 ms Par widget Cas idéal pour "ai-je déjà vu ce bouton dans CE contexte"
ColPali / ColQwen N patches × 128d 5–50 ms (late interaction) Patches × tokens query SOTA documents visuels, plus lourd, Nemotron ColEmbed V2 NDCG@10=63.42 sur Vidore V3
UISearch (arxiv 2511.19380) Graph attributé 47.5 ms median Hiérarchie + spatial 0.92 Top-5 sur 20k UIs financières

Recommandation pour rpa_vision_v3 :

  • Niveau 1 (cache exact) — pHash zone d'intérêt (déjà partiellement utilisé). Latence < 1 ms.
  • Niveau 2 (cache flou widget) — DINOv2-base crops + FAISS indexé par widget. Réutilise VisualEmbeddingManager (déjà écrit, DETTE-005) mais swap CLIP → DINOv2 (gain mesuré sur déduplication, encord).
  • Niveau 3 (recherche sémantique cross-screens) — différé. ColPali/ColQwen attrayants mais lourd à déployer ; UISearch très prometteur mais code non-public.

Verdict : FAISS + DINOv2 = bon compromis pragmatique 2026. ColPali = différé si besoin de retrieval cross-écrans riches.

4.3 Comment activer VisualEmbeddingManager orphelin (DETTE-005)

Constat investigation 2026-05-09 :

  • core/visual/visual_embedding_manager.py — 651 lignes, commit a27b74cf2 (2026-01-29).
  • core/visual/screenshot_validation_manager.py — 571 lignes, idem.
  • 0 site d'instanciation runtime, ni VEM ni SVM.
  • Investigation recommandait ARCHIVE sauf cas d'usage prod identifié, car redondant avec SignatureStore + fusion_engine.embedding_cache.

Réévaluation à la lumière de l'AXE_C :

Le verdict "archivage" du 9 mai était correct dans le cadre étroit "ce composant est-il actuellement utile ?". Mais l'AXE_C ouvre un cas d'usage clair :

  • VEM = couche cache widget visuel devant la cascade _resolve_target.
  • SVM = validation continue des targets stockées (cache invalidation par re-validation périodique).

Recommandation révisée (à statuer Dom) :

Option Pro Contra
A. Archiver VEM/SVM (verdict initial), refaire propre dans core/grounding/ Pas de dette de réécriture, unifié avec SignatureStore Perd 1200 lignes + tests existants
B. Réactiver VEM/SVM en swappant backbone CLIP → DINOv2 Tests existants, archi serializer HMAC déjà signée Architecture dupliquée avec SignatureStore, risque incohérence
C. Hybride : extraire la logique de cache HMAC + serializer signé de VEM dans SignatureStore, archiver le reste Best-of-both, signature crypto réutilisée 1 jour de refactor

Mon vote : C, après livraison démo client. Mais acter B comme MVP rapide si la fenêtre est < 1 semaine et qu'on veut tester C3 sans refactor lourd.

4.4 Cache invalidation — quand la mémoire devient stale

Stratégies observées dans la littérature 2025–2026 :

  1. Re-validation périodique (SVM ScreenshotValidationManager prévoit ça) — recapture le widget, vérifie embedding similarity > seuil, sinon STATUS=WARNING.
  2. Invalidation sur échec — Skyvern : si replay déterministe échoue, fallback IA + update cache.
  3. TTL versionné — invalidation forcée à chaque changement de version du logiciel cible (Easily Assure update).
  4. Watermark pHash — pHash du widget au moment du cache. Si match au runtime → réutilise. Sinon → re-grounding.
  5. Counter d'échecs — success_rate, usage_count (pattern browser-use). Si success_rate < 0.6 après N usages → purge.

Recommandation pour rpa_vision_v3 :

  • Combo pHash watermark (rapide) + counter d'échecs glissant (robuste). Pas de SVM périodique au runtime (coût pour bénéfice douteux).
  • TTL nominal 7 jours, reset sur chaque succès vérifié par Validator sémantique (B2).
  • Hard requirement : ne JAMAIS écrire dans le cache sans Validator sémantique OK. Sinon poison cache cf. bug step 10 mai.

5. Recommandation séquence — 3 vagues d'effort

Vague 1 — Court terme (1–2 semaines, post-démo client)

Objectif : quick wins sans toucher ML.

  1. C3 niveau 1 : étendre le cache pHash existant aux widgets résolus avec succès. Storage SQLite simple.
  2. C1 batch offline : script ad-hoc qui rejoue data/runner_captures/<session>/events.jsonl post-réussite, appelle ShadowLearningHook.on_click_observed rétroactivement. Mesure hit-rate SignatureStore au replay suivant.
  3. Définir le format de trace canonique (inspirer OpenAdapt SQLite + anonymisation t2a-style).

Coût : ~3–5 j-h. Risque : très bas. Dépendance : aucune (offline, hors chemin chaud).

Vague 2 — Moyen terme (1–2 mois)

Objectif : collecter du dataset et fiabiliser le cache.

  1. Attendre AXE_B2 Validator sémantique (cf. dépendance critique §1).
  2. Une fois B2 livré : activer ShadowLearningHook sur callback post-success replay (PAS sur Shadow direct).
  3. C3 niveau 2 : prototyper DINOv2 + FAISS sur 100 widgets démo. Option B (VEM réactivé) ou C (refactor propre).
  4. Collecter ≥ 1k traces Easily Assure propres via démos répétées + anonymisation.

Coût : ~5–10 j-h. Risque : moyen (Validator semantic = chemin critique). Dépendance forte : AXE_B2 Validator sémantique merged.

Vague 3 — Long terme (3–6 mois post-démo client)

Objectif : fine-tuning VLM spécifique Easily Assure.

  1. Dataset 3k–5k paires propres + anonymisées + smart_resize correct.
  2. GRPO + QLoRA 4-bit sur Qwen2.5-VL-3B (méthode UI-R1 / Visual-RFT). 500–1000 steps.
  3. Run local RTX 5070 ou cloud H100 marketplace. Coût attendu : 10–80 €.
  4. Évaluation : split interne 80/20 + non-régression ScreenSpot-Pro.
  5. Déploiement progressif : modèle fine-tuné en fallback du modèle base, A/B test sur démo.

Coût : ~10–15 j-h + budget cloud < 100 €. Risque : moyen (succès très dépendant qualité dataset C1). Dépendance forte : AXE_A1 (choix modèle base finalisé : Qwen2.5-VL-3B vs Qwen3-VL-8B vs UI-R1-3B comme nouveau base déjà fine-tuné).

6. Dépendances avec autres AXEs

  • AXE_B2 Validator (collecte de traces propres) : bloquant pour C1 sur replay live + prérequis pour cache C3 sans poison. Tant que Validator pHash global laxiste (bug step 10) → C1 et C3 sur traces démo seulement.
  • AXE_A1 (modèles à fine-tuner) : choix base entre Qwen2.5-VL-3B (UI-R1 le valide), Qwen3-VL-8B (memory/reference_vlm_models.md retient), InfiGUI-G1-3B (production actuelle). À trancher avant C2.
  • DETTE-014 smart_resize : doit être résolue avant fine-tuning sinon coords mal calées dans le dataset.

7. Sources

C1 — Shadow learning

C2 — Fine-tuning VLM grounding

C3 — Memory store visuel

Document destiné à être lu en complément de SYNTHESE_TECHNOS_REPLAY_2026-05-23.md, INSPIRATION_FRAMEWORKS_2026-05-10.md, et INVESTIGATION_MEMOIRE_VISUELLE_ORPHELINE_2026-05-09.md. Toute action à prendre nécessite décision Dom.

Reference in New Issue View Git Blame Copy Permalink