KARAKURI VLの学習データ準備について

こんにちは。カラクリ株式会社 R&D Team の Tech Lead の吉田です。

弊社はGENIACの第2期プロジェクトにおいて、汎用的なコンピュータユースを念頭に置いたマルチモーダルモデル KARAKURI VL を開発しました（概要はこちらの記事をご参照ください）。私は主に学習データの収集・設計の取りまとめを担当しました。本稿では、データ準備にあたって考えたこと・実施したことを具体的に記したいと思います。

1. 開発目的: カスタマーサポートの現場で動くコンピュータユースエージェント

KARAKURI VL の開発目的は、コンピュータユース、とりわけカスタマーサポートの現場で業務支援が可能なコンピュータユースエージェントを構築することにありました。

LLMにコンピュータを操作させようとすると、いくつかの方法が考えられます:

• アプリごとにカスタムツール作り込み: 特定のアプリケーション（例: Salesforce, Zendesk, Excelなど）ごとに専用のAPIコネクタや操作ラッパーを実装する方式。精度や堅牢性は高いが、開発・保守コストが膨大になる（新しいアプリの追加のたびに毎回開発が必要）
• ブラウザユース方式: ブラウザ操作を標準化し、ユーザーが普段使っているWebアプリを「人間がブラウザを使うのと同じように」操作させる方式。任意のWebアプリに対して汎用的に動作可能
• コンピュータユース方式: OSレベルでマウス・キーボード操作やスクリーンの読み取りを通じてアプリを利用させる方式。Webアプリ・デスクトップアプリ関係なく、全てのアプリを（人間が操作可能なように）エージェントから操作可能

このうち「アプリごとに作り込む方式」は、多種多様なカスタマーサポートの現場ごとに異なるアプリが使用されていることを考えると、個別の作り込みが途方もありません。また、現場の業務フローの変更にも脆弱です。

一方で、ブラウザユース方式とコンピュータユース方式に関しては、最初はどちらを採用するか迷いがありました。コンピュータユース方式の方が汎用性は高いですが、ブラウザユースと比べて実現難易度は高いです。なぜなら、ブラウザユースでは単に人間が視覚的に認識しているWebページのレンダリングされた結果だけでなく、ブラウザとの直接通信によってWebページのソースコードをテキストで直接読み出したり、操作もマウスやキー入力ではなくブラウザとの直接通信を介することで確実性が高く実施できるのに対して、コンピュータユースではそれらの「隠れ変数」に基本的にアクセスできないためです。

しかしながらカスタマーサポートの現場で動くという目的に照らし合わせると、選択肢は自ずとコンピュータユースに絞られました。なぜなら、オペレータは多数のアプリケーションを行き来しているためです。以前に私はコールセンターの業務を見学したことがありますが、オペレータは「内製のCRM（=顧客情報管理）アプリ」「デスクトップ版の Excel」「メモ帳」「ブラウザで開かれた社内FAQ」「ブラウザの別ウィンドウで開かれたチャット画面」を素早く切り替えながら^[1]業務をされていました。このような現場では、ブラウザユースの活躍範囲は極めて限定的とならざるを得ません。

2. マルチモーダルモデルにおける能力の偏り

Webページのソースにテキストでアクセス可能なブラウザユースと異なり、コンピュータユースでは「VLM (Vision Language Model) の視覚理解能力」が必須となります。つまり、インプットされた画像の内容を正確に理解できることが必要です。ただし、ひとくちに「画像」といっても様々な種類があります：

• 写真（風景・人物など）
• 線画・イラスト
• 文書の画像（PDFやスライドのページ）
• スクリーンショット（多数のUI要素が含まれる）

コンピュータユースを想定したVLMでは、この中でも「文書画像」や「スクリーンショット」を理解できる必要が特に高いと考えられます。しかしながら、これらは写真やイラストと比較して定量的かつ複雑な情報をしばしば含んでおり、それらをVLMが正確に認識できるかどうかは自明ではありませんでした。そこで、商用のものからOSSまで様々なVLMの挙動をいくつかのタスクで評価したところ、テキスト領域での性能と比較して視覚的推論において顕著な性能不足が（当時）観察されました。一例を挙げます:

• 縦書きの日本語の認識に弱い: 縦書きで書かれた複数行の日本語テキストを正しく読み取れない

• 小学3年生レベルの棒グラフの読解に失敗: ラベルに出てこない値を目分量で読み取ることができない

• 積み木の個数のカウント等の初歩的課題に失敗: 小学校入試にも出題されるような、床に積まれた積み木の個数を数えるだけの課題を正答できない

端的に言えば、テキスト領域では大学生レベルの理解力と言われる一方、図表理解では小学校低学年以下ということになってしまいます。これを念頭に、VLMに学習させるデータを以下のように準備していきました。

3. 図表理解強化のためのデータ設計

図表理解についての上記の課題に対処するため、私たちは、既存の公開データセットを改良しつつ合成データを大量に生成しました。主な内容は以下の通りです。

• グラフ理解

  • グラフ画像の合成データセット FigureQA（GitHub）を基盤に、問題文テキストを日本語化、グラフの種類・問題の種類を大幅に拡充、グラフの外見を多様化
    

• OCR（光学文字認識）強化

  • OCR訓練用の合成データセット RenderedText（GitHub）を日本語（複数行の縦書き含む）に対応
    

• 小学校入試型タスク

  • 積み木のカウント問題（問題文・問題画像・期待される応答）をロジックベースで合成
    
  • 複数の天秤のイラストから重さ順を判定する問題（問題文・問題画像・期待される応答）をロジックベースで合成
    

• フローチャート認識

  • コールセンターのオペレータ向けのトークスクリプトや業務手順書にしばしば登場するフローチャート画像をロジックベースで合成。与えられた状況に合わせて、フローチャートの分岐を正しく辿っていけるように学習させる
    

これらのタスク全てがコールセンターの現場で生じるとは限りませんが（特に小学校入試の問題を解くようなことはほぼ無いでしょう）、むしろこれらは、図表を介した情報取得の初歩的能力を網羅的に鍛えるタスク集として位置付けて準備しました。ただし、これらで十分に網羅されているとは言えず、基礎能力を十分に鍛えるためにはデータセットのさらなる多様化が必要と考えています。

4. 日本語環境におけるコンピュータユースデータ収集

並行して、日本語環境でのコンピュータ操作データの収集を目的に、独自のレコーダーを開発しました。

• 入力イベントの記録
  • マウスクリック
  • スクロール
  • キーボード打鍵列
• 画面情報のキャプチャ
  • 各イベント直前のスクリーンショットを取得

このレコーダーを用いて、複数の人間の作業者が特定のタスクを遂行している様子を多数記録しました^[2]。タスクは以下を用いました：

• MiniWob++
• LLMに生成させたタスク集（例：Twitter で『#programming』のハッシュタグを検索し、最初に表示されたツイートの内容を報告してください。）
• ほか、作業者がその場で思いついたタスク（例：GoogleカレンダーのToDoリストに締め切りが過ぎているものがあったら、その締め切りを明日までに再設定してください）

5. まとめ

本稿では、KARAKURI VL における学習データ準備のアプローチを概観しました。

• 図表理解の脆弱性に対し、合成データを用いた強化を実施
• 日本語コンピュータユースに対応するため、日本語環境での人間のコンピュータ操作データ収集基盤を構築

KARAKURI VL は現状、図表をはじめとする画像の認識に一定の強みを持つ一方、現実的なコンピュータ操作エージェントとしてはさらなる改善余地が大きいと認識しています。今後も実運用に即したデータ収集とモデル強化を継続し、実際の業務現場で即応可能な AI エージェントを目指していきます。

脚注

1. さらに電話で受け答えをしながら（！）

2. 主にインターン生の皆様にご協力いただきました。