a679fbb62b
MACRO : planificateur LLM (décompose "traite les dossiers de janvier") MÉSO : acteur décisionnel (regarde, comprend, décide, agit) MICRO : grounding + exécution (localise et clique) Phase 1 = workflows comme templates avec variables Phase 2 = acteur qui compare états et décide Phase 3 = planificateur macro avec boucles Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
147 lines
4.5 KiB
Markdown
147 lines
4.5 KiB
Markdown
# Plan Acteur Intelligent — RPA Vision V3
|
|
|
|
**Date** : 5 avril 2026
|
|
**Validé par** : Dom + Claude
|
|
|
|
---
|
|
|
|
## Vision finale
|
|
|
|
L'utilisateur dit : "Traite-moi tous les dossiers du mois de janvier"
|
|
Le robot exécute. Autonome, adaptatif, intelligent.
|
|
|
|
---
|
|
|
|
## Architecture 3 niveaux
|
|
|
|
```
|
|
MACRO → Planificateur LLM
|
|
"traite les dossiers de janvier"
|
|
→ décompose en étapes
|
|
→ boucle sur les éléments
|
|
→ rend compte des résultats
|
|
|
|
MÉSO → Acteur intelligent
|
|
Pour chaque étape :
|
|
→ regarde l'écran (gemma4)
|
|
→ comprend l'état
|
|
→ décide : agir / adapter / passer
|
|
→ exécute l'action
|
|
|
|
MICRO → Grounding + exécution
|
|
→ qwen2.5vl localise l'élément (bbox_2d)
|
|
→ Bézier mouse + char-by-char typing
|
|
→ Polling titre pour vérification
|
|
```
|
|
|
|
---
|
|
|
|
## État actuel (5 avril 2026)
|
|
|
|
### MICRO — Opérationnel
|
|
- Grounding qwen2.5vl:7b sur GPU (Ollama 0.16.3, port 11434)
|
|
- Grounding sur fenêtre active (crop depuis screenshot live)
|
|
- Template matching 80x80 pour icônes (seuil 0.90)
|
|
- Position hint pour désambiguïser (en bas, en haut, à gauche)
|
|
- Pré-vérification titre fenêtre (par nom d'application)
|
|
- Post-vérification polling titre (max 10s)
|
|
- Bézier mouse + frappe char-by-char (anti-bot)
|
|
|
|
### MÉSO — À construire
|
|
- gemma4:e4b disponible sur GPU (Docker Ollama 0.20, port 11435)
|
|
- Enrichissement build_replay : gemma4 lit les éléments sans OCR ✓
|
|
- Auto-déchargement gemma4 après build ✓
|
|
- Manque : boucle perception → compréhension → décision au replay
|
|
|
|
### MACRO — À concevoir
|
|
- Pas encore démarré
|
|
- Nécessite : workflows comme templates avec variables
|
|
|
|
---
|
|
|
|
## Plan d'implémentation
|
|
|
|
### Phase 1 : Workflow comme template (build_replay)
|
|
|
|
**Objectif** : l'enregistrement produit un template paramétrable
|
|
|
|
Pour chaque action, stocker :
|
|
- `intention` : ce que l'utilisateur veut faire (gemma4)
|
|
- `variables` : les données qui changent (nom de fichier, texte, date)
|
|
- `expected_state` : description de l'écran avant l'action (gemma4)
|
|
- `expected_result` : description de l'écran après l'action
|
|
|
|
Exemple :
|
|
```json
|
|
{
|
|
"intention": "Ouvrir un fichier existant dans le Bloc-notes",
|
|
"action": "click",
|
|
"by_text": "voiture elec",
|
|
"variables": {"filename": "voiture elec"},
|
|
"expected_state": "Bloc-notes ouvert avec plusieurs onglets",
|
|
"expected_result": "L'onglet du fichier est actif"
|
|
}
|
|
```
|
|
|
|
**Moteur** : gemma4 (Docker, port 11435) — une seule fois pendant le build
|
|
**Impact** : le build_replay devient plus riche, pas de changement au replay
|
|
|
|
### Phase 2 : Acteur décisionnel (replay)
|
|
|
|
**Objectif** : l'acteur compare l'état attendu et décide
|
|
|
|
Avant chaque action :
|
|
1. Capturer la fenêtre active
|
|
2. Comparer titre de fenêtre (rapide, gratuit)
|
|
3. Si mismatch → décrire l'état via gemma4 (texte pur, pas d'image)
|
|
4. Comparer état décrit vs expected_state
|
|
5. Décider : exécuter / adapter / passer
|
|
|
|
La décision est prise par gemma4 en **mode texte** (pas d'image = pas de VRAM) :
|
|
```
|
|
État attendu : "Bloc-notes ouvert avec un document vide"
|
|
État actuel : "Bloc-notes ouvert avec du contenu existant"
|
|
Action prévue : "Taper du texte"
|
|
→ Décision : "Ouvrir un nouvel onglet avant de taper"
|
|
```
|
|
|
|
**Moteur** : gemma4 texte (CPU, rapide) pour les décisions
|
|
**Impact** : changement dans l'executor côté agent
|
|
|
|
### Phase 3 : Planificateur (macro)
|
|
|
|
**Objectif** : décomposer une instruction en étapes
|
|
|
|
L'utilisateur dit : "Traite les dossiers de janvier"
|
|
Le planificateur :
|
|
1. Identifie le workflow appris ("traiter un dossier")
|
|
2. Liste les éléments (fichiers de janvier)
|
|
3. Pour chaque élément, instancie le template avec les variables
|
|
4. Lance l'acteur sur chaque instance
|
|
5. Collecte les résultats
|
|
|
|
**Moteur** : LLM (gemma4 ou plus gros modèle)
|
|
**Impact** : nouveau module de planification
|
|
|
|
---
|
|
|
|
## Contraintes techniques
|
|
|
|
| Ressource | Utilisation |
|
|
|-----------|-------------|
|
|
| GPU (12 GB) | Un seul modèle VLM à la fois |
|
|
| Port 11434 (host) | qwen2.5vl:7b — grounding (replay) |
|
|
| Port 11435 (Docker) | gemma4:e4b — compréhension (build + décision) |
|
|
| Séquencement | Build (gemma4) → auto-unload → Replay (qwen2.5vl) |
|
|
| Décisions replay | gemma4 en mode texte (CPU, pas de VRAM) |
|
|
|
|
---
|
|
|
|
## Ordre de réalisation
|
|
|
|
1. **Phase 1** d'abord — enrichir l'enregistrement (intentions + variables + état)
|
|
2. **Phase 2** ensuite — acteur qui décide pendant le replay
|
|
3. **Phase 3** après — planificateur macro
|
|
|
|
Chaque phase est testable indépendamment.
|