Holo3 + Cerebras を使った電子カルテ退院サマリ自動抽出パイプラインの実験結果スナップショット (合成データ)
Computer use agent が「クリック対象の単語を事前に知らず」画面上のクリック可能・入力可能要素を
visual affordance だけで列挙できるかを評価。
Prompt: 「画面内でクリックできる・入力できる UI 要素を全列挙」。文字列ヒントなし。
GT: 各画面の DOM から button, input, textarea, select, a[href], [role=button/tab/link/menuitem/checkbox/combobox], [contenteditable]
を実際にナビゲートしながら収集 (可視要素のみ)。
Matching: 予測点が GT bbox 内に落ちたら TP、余剰予測 = FP、未検出 GT = FN。
| 画面 | GT | Pred | TP | FP | FN | P | R | F1 | Lat |
|---|---|---|---|---|---|---|---|---|---|
| login | 4 | 5 | 4 | 1 | 0 | 0.80 | 1.00 | 0.89 | 11s |
| patient_list | 11 | 33 | 11 | 22 | 0 | 0.33 | 1.00 | 0.50 | 58s |
| karte | 24 | 50 | 11 | 39 | 13 | 0.22 | 0.46 | 0.30 | 85s |
| labs | 25 | 50 | 22 | 28 | 3 | 0.44 | 0.88 | 0.59 | 86s |
| meds | 29 | 50 | 23 | 27 | 6 | 0.46 | 0.79 | 0.58 | 86s |
| diagnoses | 25 | 50 | 24 | 26 | 1 | 0.48 | 0.96 | 0.64 | 86s |
✅ Recall は総じて高い (0.46-1.00): シンプルな画面 (login/patient_list/diagnoses) ではほぼ全ての GT 要素を発見。
⚠ Precision は低い (0.22-0.80): GT 数の 2 倍近い予測を返す傾向。内訳は
「DOM フィルタから外れた装飾要素 (見出し、表の行番号等)」+「同じ要素の重複検出」。
🔴 karte で F1=0.30 と苦戦: カルテ本文の「バイタル / 処方 / 検査 / 病名」タブ + 日付リストで 100 超のエレメントが画面上にあり、50 個キャップで一部取りこぼし + 順序が予測と合わない。
⏱ Latency は画面あたり 60-90 秒: 出力トークンが長くなる (50要素 × ~40token = 2000token) のが支配的。
Computer use agent 実装への示唆: Qwen3.6-27B BF16 は「画面を眺めて操作候補の座標リストを吐く」task を
F1=0.53 でこなせる。R が高いので「候補漏れ」は少なく、FP は後段の LLM Planner が絞り込めばよい。
文字列ヒント grounding (hit 0.84) と併用すれば実用レベル。
同一の6画面スクショ (login/patient_list/karte/labs/meds/diagnoses) で Grounding (DOM bbox と予測点の一致率) と OCR (画面から構造化抽出 → SQLite GT との recall) を測定。下記は JSON Schema 制約付き最終版。llama.cpp の response_format: json_schema で出力形式を強制し、{"x":[69,33],"y":[27]} のような壊れた配列出力を防止。
| モデル | 量子化 | Schema | Hit rate | Mean dist | OCR | g-lat | Total (35 calls) |
|---|---|---|---|---|---|---|---|
| Holo3-35B-A3B | BF16 (vLLM) | — | 0.84 (27/32) | 149px | 0.67 | — | — |
| Qwen-27B dense | Q8_0 | ✗ | 0.63 (20/32) | 111px | 1.00 | 5.0s | 178s |
| Qwen-27B dense | Q8_0 | ✓ | 0.84 (27/32) | 148px | 1.00 | 3.3s | 123s |
| Qwen-27B dense | BF16 | ✗ | 0.66 (21/32) | 105px | 1.00 | 3.1s | 147s |
| Qwen-27B dense | BF16 | ✓ | 0.84 (27/32) | 127px | 1.00 | 2.8s | 137s |
| Qwen-35B MoE | Q8_0 | ✗/✓ | 0.09 (3/32) | 388px | 1.00 | 1.9s | 72s |
| Qwen-35B MoE | BF16 | ✗/✓ | 0.06 (2/32) | 376px | 1.00 | 2.2s | 82s |
| 画面 | Holo3 | 27B-Q8 +sch | 27B-BF16 +sch | 35B-Q8 +sch | 35B-BF16 +sch |
|---|---|---|---|---|---|
| login | 2/2 | 2/2 | 2/2 | 2/2 | 2/2 |
| patient_list | 6/6 | 6/6 | 6/6 | 1/6 | 0/6 |
| karte | 5/6 | 4/6 | 4/6 | 0/6 | 0/6 |
| labs | 5/6 | 6/6 | 6/6 | 0/6 | 0/6 |
| meds | 5/6 | 4/6 | 4/6 | 0/6 | 0/6 |
| diagnoses | 4/6 | 5/6 | 5/6 | 0/6 | 0/6 |
問題: 27B-dense はしばしば {"x": [69, 33], "y": [27]} のような壊れた配列を返していた。パーサは配列から 1 点を取り出せず grounding 失敗。
解決: llama.cpp response_format: json_schema で x: integer, y: integer を強制。
27B-dense は hit率 0.63-0.66 → 0.84 に +0.19 の大幅改善で Holo3 タイ。
35B-MoE は 0.09/0.06 のまま不変 — 出力フォーマットではなく active 3B による認識精度の構造的限界が原因と確定した。
✅ 推奨: Qwen3.6-27B dense (Q8_0 or BF16) + JSON schema 制約 がベストチョイス。
・Holo3 とタイの hit率 0.84
・Holo3 を上回る OCR 1.00 と mean dist 127px (BF16)
・Holo3 特化 fine-tune なしに GUI agent として成立
・llama.cpp で動くので運用容易 (BF16 で A100 80GB 50GB 使用)
❌ 避けるべき: Qwen3.6-35B-A3B (MoE) は grounding 用途に非推奨。active 3B が構造的に足りない。OCR 用途 (3.2s/call 最速) なら使える。
座標系注記: Qwen3.6 は指示に関わらず 0-1000 正規化座標を返す (Qwen-VL踏襲)。pred × image_size / 1000 で変換必要。どの量子化でも共通。
各 bench の viewer では grounding trial 毎に Latency 列と「Show grounding prompts & raw responses」トグルがあり、送信プロンプト全文と モデルの生レスポンス全文を展開して確認できる。schema 付き run では raw response が {"x": 255, "y": 55} の整った形で返っていることが確認できる。