rpa_vision_v3/docs/benchmarks/2026-06-08_benchmark_uitars_grounding.md

Benchmark grounding — UI-TARS-1.5-7B (0000/ui-tars-1.5-7b-q8_0:7b) vs gemma4

Date : 2026-06-08 Modèle évalué : 0000/ui-tars-1.5-7b-q8_0:7b (UI-TARS-1.5-7B, grounder GUI spécialisé, q8_0) Backend : Ollama http://localhost:11434 (tunnel DGX) Harness réutilisé : identique aux benchs gemma4 du 2026-06-08 — mêmes 16 cas LeaBench (benchmarks/computer_use/cases/leabench_extended_2026-05-24.jsonl), mêmes images, même scoreur (core.evaluation.computer_use_bench).

---

Résumé exécutif (verdict)

1. UI-TARS ne peut PAS être benché : l'import Ollama sur le DGX est cassé. Le GGUF re-téléchargé est text-only, sans son projecteur de vision (mmproj/CLIP). Toute requête avec image est rejetée par Ollama.
2. Preuve dure et reproductible : /api/chat → HTTP 500 "image input is not supported - hint: ... you may need to provide the mmproj" ; /api/generate → HTTP 400 "Multimodal data provided, but model does not support multimodal request". Sur les 16 cas, 0 appel image abouti.
3. Confirmé par les métadonnées du modèle : capabilities = ['tools', 'completion'] — pas de vision ; projector_info = {} ; un seul blob FROM, aucun ADAPTER/mmproj. À comparer à gemma4:26b (vision présent) et qwen2.5vl:7b-rpa (vision présent).
4. UI-TARS ne bat donc PAS gemma4:26b en grounding aujourd'hui : il ne tourne pas du tout en multimodal. Accuracy non mesurable (modèle aveugle aux images). Le text-only répond (0,5 s) mais part en hallucination culinaire (« a quick, easy and healthy recipe ») — le template Ollama de cet import n'est même pas le format UI-TARS attendu.
5. Impact production à signaler : core/execution/input_handler.py appelle exactement ce modèle au niveau 2 de la cascade (_grounding_ui_tars, ligne 591) et il figure dans FALLBACK_VLM_MODELS (core/detection/vlm_config.py:41). En l'état, le grounding niveau 2 retourne HTTP 500 en silence sur le DGX. gemma4:26b reste l'acteur grounding de référence.

---

Tableau comparatif (LeaBench 16 cas — comparaison directe, même harness)

Modèle	Accuracy	Correct/16	Clics dangereux	Cible démo « Enregistrer »	Latence/appel
UI-TARS-1.5-7B (0000/...q8_0)	N/A — modèle aveugle	0/16 (aucun appel image abouti)	N/A	Échec dur (HTTP 500/400)	image rejetée ; text-only ~0,5 s
gemma4:26b	0,6875	11/16	0	1/2 (b2090514 ✅ ~centre, b2de7a6a abstain)	~mesuré le 2026-06-08
gemma4:31b	0,7500	12/16	1	(cf. rapport 31b)	~plus lent
qwen2.5vl:7b-rpa	0,5625	9/16	6	(cf. rapport qwen)	~rapide

Chiffres gemma4/qwen re-vérifiés via le scoreur sur les prédictions existantes (accuracy 0.6875 dangerous 0 pour 26b, 0.75 dangerous 1 pour 31b, 0.5625 dangerous 6 pour qwen2.5vl). La ligne UI-TARS est vide non par choix méthodo mais par impossibilité technique : pas d'inférence vision possible.

---

Détail technique du blocage (mesures réelles)

Appel image — /api/chat

HTTP 500
{"error":{"code":500,"message":"image input is not supported -
 hint: if this is unexpected, you may need to provide the mmproj"}}

Appel image — /api/generate

HTTP 400
{"error":{"code":400,"message":"Multimodal data provided, but model
 does not support multimodal request"}}

Métadonnées Ollama (/api/show)

Champ	UI-TARS (0000/...)	gemma4:26b	qwen2.5vl:7b-rpa
capabilities	['tools','completion']	['completion','vision','tools','thinking']	['completion','vision']
projector_info	{} (vide)	présent	présent
blobs FROM	1 seul, pas d'ADAPTER/mmproj	—	—
family	qwen2vl	—	—

Test text-only (sanity)

• Sans image : HTTP 200 en 0,5 s, le modèle charge bien sur le DGX.
• Réponse au prompt "Click on 'Enregistrer'" (text-only, sans écran) : " to a quick, easy and healthy recipe" → le template Ollama de cet import ne correspond pas au format de sortie UI-TARS (click(start_box='(x,y)')). L'import est doublement défaillant : pas de vision et template inadéquat.

---

Ce qui était prévu (et reste valide quand le modèle sera réparé)

Le harness UI-TARS-natif était prêt :

• Entrée : screenshot + instruction courte Click on '<target>'.
• Sortie attendue : click(start_box='(576,312)'), coordonnées normalisées 0-1000 → x_frac = 576/1000, parsing regex sur start_box (déjà implémenté en prod : core/execution/input_handler.py:_parse_ui_tars_coordinates).
• Pas de mode thinking, prompt direct.

Dès que le modèle est réimporté avec son mmproj, ce harness peut produire la ligne manquante du tableau sans autre changement (mêmes 16 cas, même scoreur → comparaison directe valide).

---

Limites sur écrans santé FR

Non évaluables ce jour : le modèle ne voit aucune image. Aucune conclusion ne peut être tirée sur la robustesse d'UI-TARS face aux écrans Easily Assure / Windows FR, ni sur la cible démo « Enregistrer ». Toute affirmation contraire serait infondée.

---

Cause racine & remédiation

Cause : le pull 0000/ui-tars-1.5-7b-q8_0:7b (upload communautaire Hub) ne package que le GGUF du LLM, sans le fichier mmproj (projecteur vision CLIP). UI-TARS étant intrinsèquement un VLM, sans projecteur il est aveugle.

Remédiation (à valider avec Dom) :

1. Réimporter via un Modelfile incluant le mmproj : FROM ui-tars-1.5-7b.gguf + FROM ui-tars-1.5-7b-mmproj.gguf (récupérer le mmproj depuis la même source GGUF).
2. Vérifier après import : capabilities doit contenir vision, projector_info non vide.
3. Sanity image avant de relancer le bench : un appel /api/chat avec image doit renvoyer HTTP 200.

---

Recommandation — acteur grounding

Garder gemma4:26b comme acteur grounding de référence sur le DGX. Justification chiffrée :

• gemma4:26b : 0 clic dangereux sur 16 cas, accuracy 0,6875, vise correctement la cible démo b2090514 (~centre de la zone attendue) — c'est le compromis sûreté/précision le plus défendable face à une audience clinique.
• gemma4:31b : meilleure accuracy (0,75) mais 1 clic dangereux → arbitrage sûreté à trancher.
• qwen2.5vl:7b-rpa : rapide mais 6 clics dangereux → écarté pour le runtime santé.
• UI-TARS : indisponible (import cassé). Tant que le mmproj n'est pas réintégré, ne pas compter dessus au niveau 2 ; pire, l'appel niveau 2 en prod échoue actuellement en HTTP 500 silencieux.

Action prioritaire indépendante du bench : comme input_handler.py:591 et vlm_config.py:41 pointent ce modèle cassé, le niveau 2 de la cascade et le fallback VLM sont inopérants sur le DGX jusqu'à réimport correct. À signaler à Dom (impact runtime, pas seulement bench).

---

Garanties méthodo

• Aucun token, secret ni identité patient dans ce rapport.
• Mesures réelles, échec rapporté honnêtement (UI-TARS n'a pas pu être benché — c'est le résultat, pas une approximation).
• Aucun code de production modifié ; tous les scripts de test sont jetables (/tmp/vlm_bench/).