ハクソク

世界を動かす技術を、日本語で。

「Gemini 2.5」はバウンディングボックスに優れていますか？

319日前原文(simedw.com)

概要

  • Gemini 2.5 Pro は、MS-COCOベンチマークで Yolo v3 (2018) と同等の性能を示す物体検出モデル
  • mAP 0.34 で、最新モデルには及ばないが、マルチモーダルLLMとしては十分健闘
  • データセット収集・アノテーション・学習不要 という利点
  • 出力形式やトークン数 による性能差やエラー傾向
  • CNNと比較した際の実用性や今後の展望

Gemini 2.5 Proによる物体検出ベンチマーク

  • MS-COCO は物体検出分野で定番のデータセット、80クラス収録
  • Gemini 2.5 Proの性能比較のため MS-COCO valセット(5000枚) を使用
  • プロンプト にはCOCOクラスリストを埋め込み、出力形式をJSONで指定
  • 出力例
    • "label": クラス名
    • "confidence": 信頼度(0.0-1.0)
    • "box_2d": 正規化済みバウンディングボックス
    • "mask": base64エンコードバイナリマスク

実験設定

  • Structured/Unstructured出力、 Thinking Budget(トークン数) の有無で比較
  • 最低Thinking Budget は128トークン（Gemini Proの場合）、2048トークンまで検証
  • マスク出力 は無効なトークン生成や無限ループを引き起こしやすい傾向

mAP(Mean Average Precision)について

  • mAP はIoU(Intersection over Union)閾値を0.5-0.95で変化させて計算
  • 高mAP値 ほど検出精度が高い
  • 評価指標 として[0.50, 0.55, ..., 0.95]の各閾値でAPを算出し平均

各モデル・設定ごとの結果

| モデル | Think Tokens | モード | mAP | [email protected] | 無効出力数 | 平均時間 | |:-------|:-------------|:------|:-----|:---------|:-------------|:---------| | flash | 0 | structured | 0.224 | 0.381 | 47/5000 | 0.18s | | flash | 0 | unstructured | 0.261 | 0.417 | 57/5000 | 0.20s | | flash | 1024 | structured | 0.160 | 0.311 | 23/5000 | 0.27s | | pro | 128 | structured | 0.332 | 0.495 | 5/5000 | 0.20s | | pro | 1024 | structured | 0.340 | 0.517 | 6/5000 | 0.46s | | pro | 2048 | structured | 0.325 | 0.506 | 5/5000 | 0.30s | | pro | 1024 | unstructured | 0.288 | 0.438 | 25/5000 | 0.47s | | flash-lite | 0 | structured | 0.156 | 0.279 | 335/5000 | 0.37s | | flash-lite | 0 | unstructured | 0.211 | 0.338 | 216/5000 | 0.23s |

  • Gemini Pro 2.5 structured のmAPは 約0.34 で、 Yolo v3 (2018) の 約0.33 と同等
  • 最新の Co-DETR 等は 約0.60 mAP と大幅に高精度
  • Thinking Budget増加 や Structured/Unstructured出力 の違いで性能に差
  • Invalid output はProで大幅に減少

考察・結論

  • CNNモデル は特定クラスに最適化されており、 速度・コスト・解釈性 で依然有利
  • Gemini 2.5 Pro は 汎用性 と 手軽さ が強み
    • アノテーションや学習不要 で多用途に利用可能
  • バウンディングボックスの粗さ は、後処理で SAM 等のセグメンテーションモデルで補完可能
  • マルチモーダルLLM は今後も進化が期待される分野

関連リソース・参考文献

  • Simon Willison による可視化ツール・ブログ
  • 論文「How Well Does GPT-4o Understand Vision? Evaluating Multimodal Foundation Models on Standard Computer Vision Tasks」
    • Recursive Zooming 手法での評価（本ベンチマークとは異なるアプローチ）

今後の展望

  • CNN と マルチモーダルLLM の使い分け
    • 速度・コスト重視 ならCNN、 柔軟性重視 ならLLM
  • より高精度な汎用物体検出 への期待
  • サイドプロジェクト や プロトタイピング での活用推奨

Hackerたちの意見

数ヶ月前に似たような記事を書いたんだけど、今回はPDFのバウンディングボックスに焦点を当てて、コンテンツの抜粋の周りにボックスを描くことについてだったんだ。Geminiはこういうオブジェクト検出タスクが本当にすごいよね。

└

それは面白いね、シェアしてくれてありがとう！PDFに埋め込まれたテキストがない場合、スキャンした文書のようなケースで、そのアプローチを実際に使ってるの？その用途でいくつか実験したけど、期待してたほどの結果にはならなかったんだよね。

└

この投稿ありがとう！私も個人的な趣味プロジェクトで似たようなことをやってるんだ（古いサンスクリットのスキャンPDFを扱おうとしてる）。あなたのスクリーンショットの「Sub-TOI」の隣のバウンディングボックスは、私も遭遇しているものと似てるよ：明らかに特定の幅と高さのボックスがあることを「知っている」けど、なぜかボックスが実際の位置からずれているんだ。そういうことについて何か洞察はある？試したことはそれを修正できた？

触れられていない詳細だけど、Googleのモデルは>= Gemini 2.0がこのバウンディングボックス検出のタスクのために明示的にポストトレーニングされてるんだ。著者が特定のbox_2dフォーマットを使っていることから、この機能を活用していることがわかるから、ちょっと強調したいな。私の直感では、このタイプのポストトレーニングがない基本的なマルチモーダルLLMは、性能がかなり悪くなると思う。

└

確かにそうだね、だから他のモデルプロバイダーとベンチマークを取らなかったんだ。この特定のフォーマットにかなり調整されているから、box_2dフォーマットの順序を(ymin, xmin, ymax, xmax)から(xmin, ymin, xmax, ymax)に変えるだけでも、性能がガクッと落ちちゃう。

└

最初にこれを見たときは本当に驚いたけど、そう、トレーニングデータに含まれてるんだよね。機能を考えてなかった。

└

Geminiモデルができることは本当にすごいよね。セグメンテーションも！

└

なぜ彼らはセグメンテーションを小さな専用モデルに任せるのではなく、後処理を行うのかな？

消費電力がどれくらい違うのか気になるな。クラシックなCNNの方が専門的だから安くなるんじゃないかな。> データセットの収集、アノテーション、トレーニングをスキップできる魅力は、数晩テストするのを無駄にするにはあまりにも魅力的だよね。アノテーション作業はどうなの？「その物体」のすべてのピクセルをマークする必要があるの？それとも、トレーニングプロセスが「物体」が入っている画像を受け入れて、「物体じゃない」ものを無視するように学ぶの？もし後者なら、Geminiのイマイチなバウンディングボックスを使って、無限に退屈じゃないアノテーターとして使えるかもね。

└

もしうまくいくなら、最初の数千件はLLMを使って、その後にこれらの注釈を使って効率的な教師ありモデルをトレーニングして切り替えることができるよ。それなら効率的でコスト効果も高いしね。

地面の真実（緑）とGeminiの予測（青）のバウンディングボックスを切り替えるには、ホバーまたはタップしてください。 時々、Geminiは地面の真実よりも優れていることがあります。 「それは地面の真実じゃなくて、ただのMS-COCOのデータだよ。」 詳しくは https://en.wikipedia.org/wiki/Ground_truth を見てね。

└

それは完璧じゃないから「地面の真実じゃない」って言ってるの？ 地面の真実っていうのは、機械学習でデータセットのラベルを示すための用語なんだ。 あなたが送ったリンクからの引用では、地面の真実が完璧じゃない可能性があることを認めているよ。「地面の真実の不正確さは、結果として得られるスパム/非スパムの判定の不正確さに関連する。」

私たちは論文でGemini 2.5を100のオープンソースの物体検出データセットでベンチマークしたよ。 https://arxiv.org/abs/2505.20612 （表2を見てね） 特に、RF100VLのような分布外データに対するパフォーマンスはすごく劣化してた。 ゼロショットではすごくうまくいったけど（基盤モデルの分野と比較して）、13.3の平均mAPを達成したんだ。 でも逆に、視覚的な例を与えると検出のパフォーマンスが落ちちゃったし、物体を見つけるためのテキスト指示を追加のコンテキストとして与えると、さらに悪化した。 だから、ある程度の物体検出のゼロショットトレーニングはあるみたいだけど、追加のコンテキストや一般的な世界知識をその検出能力に組み込むほど賢くはないみたい。

本当に疑問なんだけど、これってどういう仕組みなの？ LLMはどうやって物体検出をするの？ もっと一般的に言うと、LLMはテキスト以外のことをどうやってやるの？ こういうタスクは普通、別の（つまり視覚）モデルに任せられると思ってたんだけど、投稿では同じモデルがテキスト生成と視覚の両方をやってるみたいに話してる。 Gemini 2と2.5が異なる視覚能力を持つ理由が理解できないんだけど、両方とも同じ目的で訓練された最先端の視覚モデルにアクセスできるはずじゃないの？

└

昔はそうやってやってたけど、最近のマルチモーダルLLMは画像とテキストのトークンを混ぜて訓練するから、別の画像エンコーダーは必要ないんだ。 すべてを処理する1つのモデルがあるんだよ。

└

画像をトークン化して、一般的に大規模な事前訓練とは別に訓練された視覚エンコーダーを通して通すんだ（例えば、対照的キャプショニングを使って）。 それからRLHFの時にモデルに追加される。 今も事前訓練で視覚エンコーダーが使われてるなら驚かないよ。 これはもちろん、次のトークン予測とは異なる目的になる（画像の次のトークン予測を使ってるわけじゃないと思うけど）。 異なるモデルには異なるエンコーダーがあって、モデル間で共有されてないし、データセットもモデルによって異なるから、モデル間のパフォーマンスは変わるよ。 あなたが考えてるのは、テキストモデルが視覚モデルのAPIを呼び出してるだけだと思ってるかもしれないけど、それは違う。 もっと内蔵的なもので、フォワードパスは視覚アーキテクチャを通って言語アーキテクチャに行くんだ。 ロボティクスの研究はこれをしばらくやってるよ。

└

トークンはトークンだよ。

└

こういうタスクは普通、別の（つまりビジョン）モデルに任せると思ってたけど、この記事では同じモデルがテキスト生成とビジョンの両方をやってるみたいに書いてあるね。ほとんどのビジョンLLMは実際には別のビジョンモデルを使ってないんだ。https://huggingface.co/blog/vlms で何が起こっているかの良い説明があるよ。最近の大きなLLMのほとんどはビジョンLLMで、ClaudeモデルやOpenAIモデル、Grok、ほとんどのGeminiモデルはテキストに加えて画像も受け付けてる。私の知る限り、これに対して別のビジョンモデルを呼び出してるものはないよ。ローカルモデルの中にもこれができるものがあって、Mistral SmallやGemma 3がその例だね。彼らが何かにツール呼び出しをしてないのは、単一のモデルの重みファイルから直接動いてるからわかるよ。

ひとつ驚いたことがあるんだけど（もっと早く気づくべきだった）、 トレーニングされてないものの周りにバウンディングボックスを作るのがめちゃくちゃ下手なんだよ（PCBの回路図の部品のバウンディングとか）。

└

これって、実際には何をしているのかを理解していないってことを示してるよね。 本当の知能はここにはない。 このタスクには古いYOLOネットワークを使った方がいいかも。

そうだね、しばらくいい感じだよ。私たちがAndroid用のツールを作ったとき、OpenAIやClaude、llamaなどの中で一番安くて良い選択肢だったんだ。プランナーのフェーズと、ビジョンモデルを使う「ファインダー」のフェーズがあるよ。以下はプランナーとファインダーの結果のまとめだよ。いくつかは「進行中」って感じで、ツール呼び出しをサポートしてなかったり、すごく下手だったりするけどね。

+------------------------+------------------+------------------+ | モデル | プランナー | ファインダー | +------------------------+------------------+------------------+ | Gemini 1.5 Pro | おすすめ | おすすめ | | Gemini 1.5 Flash | 使用可能 | おすすめ | | OpenAI GPT 4o | おすすめ | 進行中 | | OpenAI GPT 4o mini | おすすめ | 進行中 | | llama 3.2 最新 | 進行中 | 進行中 | | llama 3.2 ビジョン | 進行中 | 進行中 | | Molmo 7B-D-4bit | 進行中 | おすすめ | +------------------------+------------------+------------------+

これには全然驚かないよ。今のVLMはローカライズがかなり苦手なのに、オブジェクト検出タスクで明示的に後処理されてるからね。著者が指摘してるのは、後処理の際に使われる座標系の不一致なんだ。モデルを入れ替えても似たような結果は得られないよ。Geminiは0-1000の間の整数で(ymin, xmin, ymax, xmax)を使ってるし、Qwenは0-1の間の浮動小数点数で(xmin, ymin, xmax, ymax)を使ってる。私たちはバウンディングボックスやセグメンテーションマスクのためにほとんどの最先端モデルを評価してきたけど、これは新しいユーザーにとってはかなりの足元をすくわれる要因だよ。オブジェクト検出を専門のツールに任せることにした理由の一つは、パフォーマンスが悪いからなんだ（Geminiで約0.34 mAP、DETRのようなアーキテクチャで0.6 mAP）。最近リリースしたこのクックブック[1]をチェックしてみて。オブジェクト検出や顔検出、他のクラシックなCVタスクを専門モデルに任せつつ、ユーザーにはVLMの開発体験を提供してるよ。

いい投稿だね。私たちもIBMのDocLayNetベンチマークを使ってドキュメントセグメンテーションの評価をしたよ：https://ds4sd.github.io/icdar23-doclaynet/task/ でも、MistralやOpenAI、Geminiのような現代のドキュメントOCRモデルを使ってね。そしたら、似たようなパフォーマンスが見つかったよ。DETRベースのセグメンテーションモデルは約2倍良いんだ。開示：私はhttps://aryn.ai/で働いてるよ。