ロボットアームがテーブルの上のカップをつかもうとしている。つかむ前に判断すべきことがある。カップは皿の左か右か、指先から何センチか、どこに置けばいいのか。人間には一瞬の判断だが、今の視覚言語モデル(VLM、画像と文章をまとめて扱うモデル)はこの判断を文章で書く。「左です」「約2.4メートルです」「(0.37, 0.52)の地点です」。ここで座標 (0.37, 0.52) は画面上の位置を横・縦の比率で表した値だ。
ところが答えは、すでにごく狭い選択肢の中にある。左か右か、いくつかの距離区間のうちの一つ、画面上の一点。それなのにモデルはその答えを一文字ずつ自己回帰(autoregressive、前のトークンを見て次のトークンを選ぶ方式)で書き連ね、私たちはその文章を改めて読んで数値を取り出す。MJev-Spatial はこの動作を変える。答えを文章にする代わりに、あらかじめ用意した候補ごとにスコアを付け、その中の一つを選ぶ。
選択式の試験を思い浮かべると、なぜ損なのかがはっきりする。答えが①〜④のどれかなのに、マークシートに塗る代わりに「正解は3番で、その理由は…」と長い文章を書かせるようなものだ。書くのに時間がかかり(生成コスト)、採点者はその文章を改めて読んで番号を拾い出さなければならない(パースコスト)。
コストだけの問題ではない。モデルは空間的な答えだけを学ぶのではない。その答えを包んだ文章の口調や決まり文句まで一緒に学んでしまう。空間判断とは無関係な文章作法が学習シグナルに混ざり込む。
速度の制約もある。ロボットが物をつかんだり、エージェントがシーンの中を動き回ったりするとき、判断が遅ければその場で立ち止まる。著者らはここで相互作用レート(interaction rate、ロボットやエージェントが止まらないために合わせなければならない判断の周期)を持ち出す。必要なのは、ゆっくり考えて出す答えではなく、速くて自動的な判断、心理学でいう System 1(意識的に考え込まずに即座に出てくる思考)に近い反応だ。
空間タスクの出力は大きく分けて三つある。選択肢から一つ選ぶ、数値一つ(距離・角度・個数)、画面上の2次元の点一つ。どれも有限の候補リストとして書き下せる。選択肢はもともと有限だ。数値と座標は、範囲と解像度を決めて区間に分ければ — これを離散化(連続した値をいくつかの区間にまとめて「マス」として扱うこと)という — やはり有限になる。こうして三つのタスクが「候補から一つ選ぶ」という一つのルールにまとまる。
選ぶには、候補ごとにスコアを付けなければならない。普通はそのために分類用の出力層(分類ヘッド)を新たに取り付ける。MJev-Spatial は取り付けない。質問と画像、そして各候補をそれぞれ数値の束に変換したうえで、質問・画像に各候補がどれだけ当てはまるかを関連度スコアとして計算する。この計算は、バックボーン(土台となる事前学習モデル)がもともと使っていた比較の機能をそのまま借りる。だから新たに増やすパラメータが一つもない。性能を押し上げる別部品があるからではなく、答えを生成するために遊ばせていた既存の能力を空間判断の側に振り向けた結果だ。
掘り下げ — スコアはどこから出るのか トランスフォーマーのアテンションは、各トークンを query(何を探すか)と key(何を差し出すか)の二つのベクトルに変換したうえで、両者を突き合わせて関連度を測る。前の段落で「数値の束に変換してスコアを出す」と言った過程がまさにこれだ。答えを決める位置の状態が query になり、各候補の状態が key になる。両者を突き合わせた値がその候補のスコアで、いま有効な候補どうしを比較して確率に変える(softmax)。MJev-Spatial はこの query・key 変換を一から作り直すわけではない。事前学習された射影を初期値として持ち込むが、そのまま置いておかず、空間タスクに合わせて微調整する。凍結するのはビジョンエンコーダと merger だけで、持ち込んだ言語側のパラメータは一緒に学習される(スコアを読み取る readout 層には別の学習率を与える)。つまり新しい分類部品を足さないだけで、既存のパラメータを学習しないという意味ではない。
技術注 — なぜ最終層ではなくアテンションの射影なのか 候補を突き合わせるとき、トランスフォーマーの最後の MLP 層ではなくアテンションの query・key 射影を使う。最後の MLP 層は表現を「次の単語の予測」の側へ押しやり、意味どうしを突き合わせる能力を落とす傾向があるからだ(著者らは FreeRet の観察を根拠に挙げる)。そこで、その変換が起きる前、比較に特化した射影の段階で候補を見比べる。
距離や座標は候補が多すぎる。1センチメートルから数十メートルまで、あるいは画像上のすべての点を一度に並べると、リストが手に負えない。そこで、広い区間から狭い区間へと範囲を絞っていく粗から密へ(coarse-to-fine)の方式で、二〜三回に分けて選ぶ。
先ほどのカップに戻ろう。カップが画面のどこにあるかを座標で打たなければならない。まず画面を3×3、つまり9マスに分ける。モデルはカップが入っているマスを一つ選ぶ。選んだマスだけを原本から改めて切り出し、また9マスに分けて、もう一度一つのマスを選ぶ。こうして三回選べば、実質的に27×27の格子から一マスを打つことになり、最後のマスの中心が座標になる。毎回、直前の切れ端ではなく原本から改めて切り出すのは、切ったり縮めたりするときに生じる誤差が段階ごとに積み重ならないようにするためだ。
距離も同じやり方だ。二つの物体が何メートル離れているかを問われたら、ステップ1で広い距離帯を一つ選ぶか、「ちょうど0」または「範囲外」を選ぶ。ステップ2でその区間をさらに細かく分けたマスを一つ選び、そのマスの中間値を答えとして出す。広く一回、狭く一回。二回の選択で連続的な距離値に届く。
既存の空間モデルと MJev-Spatial が分かれる地点は三つある。
| 区分 | 従来の方式 | MJev-Spatial |
|---|---|---|
| 出力 | 空間的な答えをより上手に「生成」しようとする | 選択肢・数値・座標をすべて「候補選び」一つにまとめる |
| スコア計算 | 候補スコア用の出力層を別途学習 | バックボーンの事前学習された比較機能をそのまま借用(追加パラメータ0) |
| 精密化 | 座標をテキストで生成 | 領域選択を分類として教師あり学習、選んだマスを原本から改めて切り出して次の根拠に使う |
総合スコア65.64%で、比較した8個のモデルのうち最も高く、12個のベンチマークのうち7個で1位だった。手を加えていない自己回帰の原本(同じバックボーン Qwen3.5-4B)と比べると、12個すべてでより良かった。
総合スコアは平均だ。だから「平均的に最も良い」とまでは言えても、どのタスクで大きく勝ち、どのタスクで負けたのか、1位を逃した五つのベンチマークでどれだけ遅れたのかは、この数字一つだけではわからない。
速度は12個のベンチマーク全般で、最も速い自己回帰の競合モデルより2.5倍、同じバックボーンの原本より5.6倍速かった。二つの倍数は基準が違う。2.5倍は最も速い競合との比較なのでより保守的な値であり、5.6倍は自分の原本との比較だ。どちらも、答えのトークンを一文字も生成せず、決定ごとに計算を一度(forward pass 一回)だけ回して終える、という設計から出てくる。
結果だけを見ると「自己回帰生成という形式そのものが空間タスクでは重荷だった」と読みたくなる。だがこのモデルは形式だけを変えたのではない。分類という新しい目標で学習し直し、粗から密への構造とクロップ(切り出した切れ端)の再エンコードも一緒に入れた。形式を取り除いた場所に、空間タスクに合わせた学習と構造を足した結果と見るのが妥当だ。
その証拠の一つがアブレーション実験(ablation、一部分だけを変えて効果を見る実験)から出てくる。長さをより粗く離散化したら — つまりマスをより大きく取ったら — 解像度は下がったのに予測誤差が減る区間があった。なぜだろう。マスを細かく分けると、各マスが代表する値の誤差は減るが、モデルが区別すべき候補が増えて「選ぶこと」が難しくなる。二つの力が拮抗し、ある点を越えると「候補が多くて選べない」側が大きくなる。解像度を上げたからといって精度がついてくるわけではない、という意味だ。
ここで設計上の問題が一つ生じる。候補の間隔、ステップ数、一回の判断に使える時間、そしてタスクが許容する誤差 — この四つは別々に決められず、一緒に合わせなければならない。より細かく刻めば良くなるわけではないので、最適値はドメインごとに実測で見つけるしかない。
「追加パラメータ0」も気をつけて読まなければならない。パラメータを足さないことと、計算を足さないことは別だ。候補が増えればスコアを付ける対象が増え、座標のようにステップが多いタスクは毎ステップでクロップを再エンコードする。だから「部品は増えていない」のは正しくても、全体の計算まで軽いかどうかはタスクごとに改めて検討すべきことだ。
著者らが自ら明かした限界もここに接している。粗い段階で間違えると、正解が入った領域そのものが候補から外れる。点予測の幾何学的な誤差上限は「正しいマスを選んだとき」の保証にすぎず、前の段階が間違えれば意味がない。数値の量子化誤差の上限もコードブック(候補リスト)に対する保証であって、モデルが実際に当てられるかどうかに対する保証ではない。粗から密への構造の宿命的な弱点、すなわち上の段階の誤りが下へ波及する問題を隠さなかったわけだ。
同じ条件で突き合わせた実験でも、著者らはこの方式が専用の分類ヘッドより「常に」優れているとは言わない。「競争力があり学習コストが低いが、タスクによって損得が分かれる」という立場だ。適用範囲もはっきりしている。この方法は、出力が有限の候補で表せるときにだけきれいに回る。質問が開かれていて自由記述が必要だったり、候補をあらかじめ絞り込めなかったりすると、この枠組みをそのまま使うことはできない。数値コードブック(長さ・角度・個数)の範囲と間隔も特定のタスク分布に合わせた選択なので、別のドメインへ移すなら改めて設計し直して検証する必要がある。
数値を選ぶときに使う候補リストをコードブックという。値ごとに次のように組まれている。
| 値 | 候補の構成 |
|---|---|
| 長さ・距離 | ステップ1:log1p 間隔の正の区間30個 + ちょうど0 + 範囲超過 → ステップ2:選んだ区間を線形に4マスまたは8マスへ。選んだマスの中間値が答え |
| 角度 | 30度の正の区間 + 0 + 範囲超過、区間あたり32マス |
| 個数 | 粗いグループ32個 × グループあたり整数32個で0〜1023を正確に復元 |
短い寸法と遠い距離を一つのメートル基準のコードブックでまとめて扱うために、距離のステップ1の区間は対数間隔(log1p)で広げてある。このコードブックはチェックポイントに一緒に保存され、学習ラベル・区間テキスト・推論値が互いに食い違わない。
同じ物体が複数あってすべて指し示さなければならないときは、可能性が高いマスどうしをまとめて物体一つの位置とする。再学習なしで3段階の分類器をツリーに展開する方式だ。ステップ1で左上にも右下にも物体がありそうなら、経路が二つに分かれてそれぞれさらに深く降りていく。最終マスごとにそこまでに選んだ確率を掛けた値が付いて一種の空間確率マップになり、ピークに比べて一定水準以上に高いマスをまとめて、物体ごとに代表点を一つずつ返す。いくつ出すかはまとまったグループ数が決めるので、「もう終わり」を別途学習させる必要がない。
評価は12個の空間ベンチマークで8個のモデルを比較した。指標は総合スコア(精度系の平均)と推論レイテンシ(一度答えるのにかかる時間)だ。バックボーンは Qwen3.5-4B、学習データは既存の空間データセット5個(RefSpatial, SAT, SenseNova-SI, VSI-590K-image, VST-P)を分類形式に変換した1230万個の質問-答えペアだ。タスク別では、選択式の空間QA 710万、点ローカライズ 350万、長さ推定 160万、角度推定 12万、個数カウント 3.8万。この数字は段階に展開する前の元のQA基準だ。点・数値タスクは二〜三段階に展開されるので、モデルが実際に教師あり学習される「決定」の数はこれより多い。
アブレーション実験からもう一つ。数値をデコードするとき、選んだ粗い区間内の精密なマスに期待値(条件付き平均)を取る方法は72K規模の実験で誤差がむしろ大きくなって採用せず、代わりに argmax で選んだマスの中間値を使う。
技術注 — 学習をどう回したのか 不均質な空間データは文章の長さも画像クロップの数もばらばらなので、バッチに空き(パディング)が生じ、GPUごとに作業量がまちまちになる。著者らは、長さを考慮したグローバルバッチングとGPU間の負荷分散によって、オプティマイザのバッチ構成はそのままに、この無駄を減らして学習スループットを30.8%引き上げた。この30.8%は精度ではなく学習速度の利得だ。また、すべての粗から密への段階を teacher forcing(正解をあらかじめ入れて各段階を一緒に学習させる方式)で一度の forward pass で教師あり学習しつつ、タスクごとに段階別の損失を平均して、3段階の点問題が1段階の選択式より大きな重みを持たないように調整した。
空間判断の外でも、出てくる答えがあらかじめいくつかに決まっている仕事なら、同じ問いを立てられる。「わざわざ文章で書かせて、また読んで取り出す必要があるのか?」
ONTLE のリクエストルーティングがそういう場面だ。たとえば Slack に「来週月曜までに詳細ページのバナー案を二つだけ、急ぎでお願いします」というリクエストが入る。AI PM はこれを読んでデザインタスクに分類し、担当ペルソナとデザインキューへ渡さなければならない。渡す先は決まったカテゴリ数個ですでに有限なのに、いまは普通、LLM が分類結果を文章で書き、私たちがそこからカテゴリを取り出してルーティングする。MJev-Spatial が空間タスクで指摘したあの非効率と、形がまったく同じだ。
ただしここまでは適用結果ではなく仮説だ。試すには条件が一つある。カテゴリ候補の上でスコアを安定して読み取れるようにモデルを合わせなければならない — 論文のように分類目標で学習するにせよ、候補確率を一貫して出す別の方法にせよ。そして論文が認めた落とし穴もそのまま持ち越される。一次分類で「デザイン」を「データ修正」へ誤って送った瞬間、そのあとの細分類はすべて無意味になる。上の段階の誤りが下へ波及する問題がルーティングにも同じように生じるので、上位分類の確信が低いときは人に渡す安全装置を一緒に置かなければならない。
だから検討するなら、緊急度まで多段階に刻む拡張を描く前に、リクエストルーティング一つから比較するのが妥当だ。同じリクエストのまとまりを、いまの生成・パース方式と候補スコア方式でそれぞれ処理し、(1)決定あたりのレイテンシ、(2)見当違いのキューへ行った誤分類の割合、(3)人が再度見なければならなかった割合を測る。効果は分けて見なければならない。答えの文章を作らなければレイテンシが減り、パース段階がなくなるのでフォーマットが崩れて見当違いのキューへ行く誤りは減る。だがカテゴリそのものを間違って選ぶ分類精度の問題はそのまま残る。これに加えて、スコアが低かったリクエストと実際にキューを誤ったリクエストがどれだけ重なるかを見なければならない。その重なりを知って初めて、「確信が何点を下回れば人へ」という検討基準を数字で定められる。
この実装は Qwen3.5-4B をバックボーンに使います。以前のプロトタイプは Molmo2-ER ベースに LoRA と別途の決定ヘッドを載せていましたが、現在のモデルは Qwen3.5-4B に変え、言語パラメータ全体を学習しました。核心のアイデア(事前学習された query・key 射影の再活用)は特定のモデルに縛られませんが、他のバックボーンでの性能はこの論文が報告した範囲の外です。
いいえ。複数の経路を展開してマップを作るのは一度に複数の点を取り出すための仕掛けであって、ステップ1で間違えたものを復旧する仕掛けではありません。単一経路の推論には巻き戻しがなく、粗い段階が間違えれば正解領域が候補から外れ、以降の段階の保証は意味を失います。
記述的な根拠は出ません。出力は選んだ候補一つと、有効な候補どうしを比較して得た確率だけです。つまり「なぜ」に対する説明の代わりに「どれだけ確信しているか」という数字が残ります。この確率を運用でどう使うかは本文の「ONTLE の視点」で扱います。