答えが合っていたかだけを採点するAIは多い。OneSearch-VLが違うのは、「その答えにどうやってたどり着いたか」まで別途採点するという点だ。
一枚の写真、複数枚、そして動画まで、三種類の視覚入力を一つのエージェント(自ら道具を選んで使いながら仕事を処理するAI)で調べさせる、8B(80億パラメータ)規模のモデルだ。核心となる仕掛けは二つを見つめる。一つ、答えを支える事実が実際に道具の返した画面と検索結果から出てきたのか。二つ、画面で見当違いな場所ではなく正しい地点を押さえ、その後の調査を引っ張ったのか。
効果は著者らが実験で裏付けた。答えとクエリの品質だけを採点していた報酬に、この「プロセス採点」を重ねたところ、標準性能試験(ベンチマーク)の平均が57.3から61.1に上がった。答えに至る道を採点しただけなのに、たどり着いた答えそのものが良くなったのだ。
街並みをゆっくり映していく10秒の動画がある。店の看板がいくつか通り過ぎる。問いはこうだ。「この動画に映ったブランドのうち、創業から50年を超えたところは何件か?」
目で見るだけでは解けない。創業年は画面に書かれていないからだ。きちんと答えるには、こんな連鎖をたどらなければならない。まず看板が映る区間を選び、その瞬間のフレームを抜き出す。看板を一つずつ切り出して文字を読み、どのブランドかを識別する。ブランドごとに創業年をウェブで検索する。そのうち50年を超えたところだけを選んで数える。そこでようやく件数が出る。
これをするためにモデルは複数の道具を使う。区間選び、フレーム抜き出し、切り出し、文字読み取り、画像検索、ウェブ検索といったものだ。重要なのは、道具がばらばらに動くわけではないという点だ。道具の種類が何であれ、同じ窓口に命令を出し、同じ形式で結果を受け取る。だから一枚の写真であれ動画であれ、一つのエージェントが同じやり方で扱う。
さて、モデルが「3件」と答えたとしよう。正解だ。だが、この3件はきちんと調べて出たものなのか、それとも見当違いなフレームを見て適当に当てたのが運よく合っただけなのか。最終的な答えだけを見れば、両者は同じに見える。ブランドをすべて当てても創業年を取り違えれば間違いだし、プロセスがでたらめでも偶然3件が合うこともある。難しいのは最後の数字ではなく、そこまでたどり着く連鎖だ。この論文の賭けははっきりしている。その連鎖を丸ごと捕まえて、データ・学習・評価に同じように使う、ということだ。
この連鎖をデータにどう残すかが、本当の課題だ。既存の研究が何度も足を滑らせてきた地点でもある。
刑事ドラマの証拠ボードを思い浮かべてみよう。壁に写真を貼り、画鋲で書類を留め、糸で写真と書類と結論をつなぐ、あのボードだ。事件を解くのは一枚の写真ではなく、それをつなぐ糸だ。既存の手法がしばしば失っていたのが、まさにこの糸だった。証拠をグラフのような構造に収めて使いはしたが、「看板 → ブランド → 創業年 → 件数」とつながる依存の連鎖を最後まで保てなかった。写真や最終結論は残したのに、その間をつなぐ部分を取りこぼした。動画のほうはもっとひどく、キーフレームを検索の種としてしか使わず、「この結論がどの観測から出たのか」という出所を明示的に残さなかった。
OneSearch-VLがデジタルに移した証拠ボードが、VGEG(視覚根拠証拠グラフ)だ。壁に貼った写真は、画面で「ここを見た」と指し示した地点(アンカー)と、それが何であるかに当たる。画鋲で留めた書類は、出所が裏付ける外部の事実だ。両者をつなぐ糸は、アンカーと事実と演算のあいだの依存関係だ。ここに、事実を束ねて答えを作る演算 — 数える、比較する、計算する — が加わる。先ほどの動画の問いなら、看板が写ったフレーム(写真)、各ブランドの創業年の書類(画鋲の書類)、そして「この看板 = このブランド = その創業年 = 50年基準に該当」をつなぐ糸が、一枚のボードに集まる。
核心は、このボード一枚を四か所で同じように使うところにある。問いを作るとき、専門家の解き方をふるいにかけるとき、モデルが自分で解いて点数を受け取るとき、演算ごとに成績をつけるとき。学習と評価が互いに別々のものさしで動く代わりに、同じボードを見る。課題が与えられると、入力全体の大きな証拠地図から、その課題に必要な部分だけを切り取って小さなボードを作る。巨大な地図から、今回の問いに使う区画だけを示したミニマップというわけだ。
ボードを中心にデータも作り出す。使えそうなウェブ動画250万本を、識別可能な対象と検索の余地があるものに絞り込んで7万本にする。各動画を細かく分割し、画面のあちこちに「ここにこれがある」というアンカーを埋め込み、そのアンカーを画像検索・文字読み取り・ウェブ検索で実際の事実と出所につなぐ。できあがったボードに照らして問いと答えを作り、最後に、専門家モデルが実際に道具を使いながら残した解き方のうち、答えも合っていてプロセスの品質も通過したものだけを残す。こうして集めたのが、学習用データのSFT-110KとRL-10Kだ(二つの数字がそれぞれ何を数えたものかは末尾のFAQで)。
一つ押さえておきたいことがある。この研究は新しい検索能力を加えたわけではない。前作のデータと報酬を受け継ぎ、その上に「証拠をどう扱ったか」を監督する枠組みを重ねて、複数画像と動画へ範囲を広げたほうに近い。
冒頭で触れた、あの二つの採点軸には仕掛けの名前がある。EVGRだ。課題ごとに採点表を作る。答えの核心は何で、それを支える事実は何で、その事実の出所と根拠となる文はどれで、どのフレームと領域を見るべきか。モデルの解き方をこの採点表に重ねて見て、点数をつける。
二つの軸をあえて分けた理由が重要だ。答えだけを見れば、運で当てた道ときちんとたどった道が同じに見える。しかし「事実が本当に観測から出たのか」と「画面で正しい場所を押さえたのか」を別々に問えば、偶然正解にたどり着いただけのでたらめな解き方をふるい落とす隙間が生まれる。
そして、この二つの軸は入力の種類によって重みが違う。一枚の写真や複数枚では、見るべき場面がすでにすべて与えられている。だから関連する瞬間を収めたフレームを自分で選ばなければならない負担がない — 追加で視覚ツールを必ず呼び出さなければならないわけではない、という意味であって、まったく使わないという話ではない。写真にも切り出し(Crop)・文字読み取り(OCR)といった道具が同じように与えられ、実際に複数枚を調べるときは画面を何度も切り出して見る場合もある。動画は違う。関連する瞬間を収めたフレームを自分で選ばなければならず、その選択を誤れば後続の検索が丸ごと狂う。だから「画面で正しい場所を押さえたか」という軸は、動画でとりわけ重く働く。動画調査が難しい本当の理由は、ここにある。
学習は二段階だ。まず、専門家が実際に道具を使って残した解き方を丸ごとまねて学ぶ。次に、モデルに自分で道具を使わせ、受け取った点数で判断をより精緻に磨く。前半が模倣、後半が試行錯誤だ。
設計で注目すべき点をいくつか。まねて学ぶ段階では、道具が返した結果物を「うまく当てたか」の採点から外す。それはモデルが作り出したものではなく外から入ってきた値なので、モデルが自ら選んだ行動だけを評価するのが公平だ。磨く段階の点数は、答えの正確さ、クエリの品質、そしてEVGRのプロセス点数を合わせた値だ。ただし、推論と道具呼び出しと応答の形式が正しいときにだけ点数を与える。もう一つ、ライブのウェブ検索は途中で失敗するのがほぼ常だ。だから道具の実行が途切れた解き方も丸ごと捨てず、失敗の直前までの無事な部分だけを選り分けて学習に使う。ささいに見えても、実戦では決定的な処理だ。
では、うまくできたかをどう測るのか。最終的な答えは、GPT-4oが参照解答と比べて正解・不正解に振り分ける。比較相手は三層に用意した。道具なしで即座に答えるもの、検索結果を添えてやるもの、道具を使うエージェント。このうち、同じ8B規模のベースモデルに道具だけを付けたバージョンが、最も公平な相手だ。
賢い選択は、評価を「何を問うか」ではなく「どんな演算が必要か」で切り分けたことだ。新たに作った二つのベンチマークは、同じ演算分類を使う。アンカー一つで解ける問題、何度も検索を乗り継がなければならない問題、条件をかけて数える問題、複数のアンカーをつなぎ合わせたり計算したり比較したりする問題。なぜここまで切り分けたのか。正解率一つでは、失敗がどこで起きたのかが見えないからだ。対象を見つけられなかったのか、関係をつなげられなかったのか、条件を絞れなかったのか。演算ごとに分けてこそ、その地点が浮かび上がる。
ただし、こうした賢さが逆に怪しい部分も生んだ。この二つのベンチマークを組む演算分類が、モデルを学習させたデータエンジンの分類と同じ体系なのだ。試験問題を出した基準と、勉強させた基準が同じ、という意味だ。だから、この二つのベンチマークの成績には「同じ枠組みを共有する有利さ」がいくらか混ざっていると見るべきだ。そのため、外部で作られた動画ベンチマークVideoDRと、既存の単一画像の七つのベンチマークを合わせて見てこそ、バランスが取れる。もう一つ、GPT-4oの二値判定は最終的な答えだけを測る。そこまで至った経路の質は測れない。その空白を埋めるのが、EVGRの二人の審判と、先ほど述べた演算ごとの分解だ。
では数字を見よう。単一画像の七つのベンチマーク平均は58.3。同じベースモデルに道具だけを付けたエージェントより16.3%p、前作OpenSearch-VLより1.7%p高い。七つすべてで前作を上回り、道具を使う他の手法と比べても七つ中六つで最高だった。この結果が語ることは一つだ。複数画像・動画の解法まで一つの釜に入れて一緒に学んだのに、一枚の写真を調べる実力が削られなかった。混ぜて学んだことが損ではなかったという、最初の兆しだ。
複数画像と動画では、差がさらに開く。新しいベンチマーク二つで、道具を付けた同級モデルをそれぞれ20.2%p、17.6%p上回り、外部で作られたVideoDRでは27.0%pの差をつけた。
重要なのは、差がどこで開いたかだ。単純な照会ではなかった。複数の証拠をふるいにかけて編み、計算する複合的な問題で大きく開いた。複数画像では、条件をかけて数える(+29.8%p)、複数のアンカーを集めて計算する(+26.3%p)、比較する(+22.5%p)。動画では、何度も検索を乗り継ぐ(+25.5%p)、計算する(+20.0%p)、アンカーをつなぎ合わせる(+19.2%p)。どれも、データエンジンが最初から狙った組み合わせ演算だ。
パターンは一方にはっきり偏っている。単純な探しものでは差が小さく、証拠を組み合わせなければならない場でだけ、とりわけ大きく開く。この偏りは、このモデルが「散らばった証拠をより上手く編み上げる」方向に改善されたことを示唆する。データ設計の段階から狙っていた、まさにその能力で点差が開いたわけだ。ただし、ここには明確な一線がある。論文は演算ごとの正解率と報酬除去(アブレーション)実験は報告するが、検索回数を統制したり、検索量の影響だけを切り離したりした実験は示していない。だから、複合的な問題で改善幅が大きいという事実だけで「検索をより多くしたから上がったのではない」と断定することはできない。今言えるのは、このパターンが証拠の組み合わせ能力の改善を示唆する、というところまでだ。
裏付けとなる実験が、もう二つある。一つ目、三つの入力を一緒に学んだ構成が6ベンチマーク平均55.8で、一つの種類だけを学んだ場合(51.7〜55.1)より高かった。混ぜることが得だということを、数字で裏付けた。二つ目が、冒頭で挙げたあの結果だ。答え・クエリの報酬だけを使っていたところにプロセス採点を加えたときの上昇 — プロセスを採点する報酬が、結果の点数まで引き上げるという直接の証拠だ。ただし、この二つの実験は互いに異なる設定(データ混合 / 報酬構成)から出た値だ。55.8と冒頭のあの上昇を、一続きにして読んではいけない。
押さえるべき点は四つだ。
一つ、評価も報酬も「判定モデル」に頼っている。最終的な正否はGPT-4oが、プロセス点数は二つの審判モデルがつける。審判の品質と偏りが、そのまま評価と報酬の天井になる。審判が間違えれば、正否も報酬も一緒に間違う。
二つ、データエンジンがLLMの生成・検証・フィルタに大きく依存している。250万本を7万本へと削ぎ落とす思い切った絞り込みは、残ったデータの品質を上げる一方で、何が生き残るかが上流モデルの傾向に左右されるという意味でもある。
三つ、報告された成績は8Bという一つの規模のものだ。より大きい、あるいは小さいモデルでも同じ利点が出るのか、コストはどれほどかは、この論文は答えない。
四つ、先に述べた新規ベンチマークのホームアドバンテージだ。ただし、外部で作られた動画ベンチマークでも差が大きく出たという事実が、この懸念をかなり和らげてくれる。
OneSearch-VLの問題意識は、私たちが毎日向き合う悩みとそっくりだ。答えがもっともらしければ、正しいかのように見える。根拠があるのかないのかは、答えだけを見ても分からない。ONTLEのAI PMにも、まさにこの急所がある。
一つの場面を最後まで追ってみよう。顧客が10分の決済画面の録画をアップロードしながら尋ねる。「うちの決済フローで、競合に比べて抜けているものは何か」。PMがやるべきことは、先ほど見た動画調査と事実上同じだ。決済ステップが映る区間とフレームを押さえ、画面の中のボタンが何の機能かを識別し、外部の資料を検索して競合の標準と突き合わせたうえで、それらの事実を束ねて結論を出す。
過去に痛い目に遭った地点が、まさにここだった。もっともらしく聞こえるのに、動画のどこにも、どの出所にも根拠のない結論。EVGRの発想をONTLEの言葉に置き換えると、こうなる。答えが合っていたかとは別に、その結論を支える事実が、顧客のアップロードした動画のそのフレームと、検索して読んだその資料から実際に出てきたのか、そしてPMが動画の「正しい瞬間」を本当に押さえたのかを、別途確認する。
だから製品に下す結論は一行だ。結論を先に出して根拠を後から挟み込まないこと。結論ごとに「画面のどの地点」と「どの外部出所」を、最初から一緒に束ねて保存する。ONTLEの顧客画面は、作業を時系列の流れで見せる。その流れの一つひとつのノードに「この結論はアップロード動画03:12のその場面と外部出所2件に基づく」が、はじめから添えられているようにするのだ。そうすれば、後から根拠をたどる作業が、事後に付け足す機能ではなく、作業の構造そのものから生まれる。顧客画面には、内部用語なしで「根拠:アップロード動画03:12、参考出所2件」のように、顧客の言葉だけで映ればいい。もっともらしさではなく、たどり直せる根拠をデフォルトに。これが、この論文がONTLEの決済動画の一場面に与える、実質的な結論だ。
論文はプロジェクトのリポジトリとしてGitHub(appletea233/OneSearch-VL)、モデルハブとしてHuggingFace(OneSearch-VL)を示している。公開範囲・ライセンス・チェックポイントの具体的な事項は、当該リポジトリで直接確認する必要がある。
数えた対象が違う。SFT-110Kは統合マルチターン形式でまとめた専門家の解法過程(トラジェクトリ)の集まりで、RL-10Kは三つの入力タイプを網羅する課題プールから構成した課題だ。一方は「トラジェクトリ」、もう一方は「課題」単位なので、混ぜて読んではいけない。
問いに対象の名前がそのまま出てしまうと、モデルが視覚入力を見なくても答えられてしまう。そこでデータエンジンは、明示的な名前の言及を「視覚的に指し示す参照」に置き換えて使い、テキストだけで自信を持って答えられる設問は別途取り除く。視覚入力を必ず経由させるための仕掛けだ。
ぶれることはある。ウェブ検索・画像検索は外部のウェブに問い合わせるので、ウェブの内容が変われば結果も変わりうる。この種のシステム全般の構造的な変数だ。再現を望むなら、評価の時点と道具の環境を合わせて固定し、記録しておくほうが安全だ。