この記事の要点
- NeoMMEは、文字と画像を1つの双方向Transformerで扱う多言語・マルチモーダルのエンコーダです。
- NeoMME-Retrieverは、PDFページを画像のまま検索対象にする視覚文書検索向けに調整されています。
- モデルは260Mと800Mの2サイズで、Hugging Face TransformersとApache 2.0のチェックポイントとして公開されています。
生成AIの裏側で、検索AIが主役になる
AIが長いPDFを扱う時、最初の壁は答えを書くことではありません。どのページを読めばよいかを探すことです。
今回の発表で出たNeoMMEは、そこに向けたモデルです。ここで変わるのは、書類検索の土台が軽くなることです。
画像と言葉を1本の道で扱う
NeoMMEは、マルチモーダル（文字と画像を一緒に扱う）で多言語のエンコーダ（情報を検索しやすい形に変えるAI部品）です。発表では、260Mと800Mの2サイズが示されました。
特徴は、画像用と文章用を別々に持たない点です。文字トークンと生の画像パッチを、1つの双方向Transformer（前後の関係を見るAIの仕組み）で処理します。
画像は32×32の小片に分けて入ります。文脈長は16,384トークンです。発表では、標準的な4K UHD（高精細な画像規格）画像なら2枚分を扱えると説明されています。
PDFを文字起こしの外へ広げる
NeoMME-Retrieverは、この土台を視覚文書検索（PDFや画像のページを見た目ごと探す技術）向けに調整したモデルです。従来の文章検索では、PDFから文字を抜き出してから探す流れが中心でした。
しかし書類には表があります。グラフもあります。文字の大きさや配置も意味を持ちます。
ページを画像のまま扱えば、OCR（画像内の文字読み取り）だけでは落ちやすい手がかりを残せます。ここが、普通の文章検索との大きな違いです。
使える形と書かれていないこと
いつから使えるのかは、読者が気になるところです。発表は一般向けアプリの新ボタンではなく、Hugging Face Transformers（AIモデルを扱う開発者向けライブラリ）で使うモデル公開に近い話です。
| 項目 | 発表で読める内容 |
|---|---|
| 発表日 | 2026年9月3日 |
| Transformersへの追加 | 2026年8月31日に追加 |
| モデルサイズ | 260Mと800M |
| 公開形態 | Transformersとチェックポイント |
| ライセンス | Apache 2.0 |
| 料金 | 発表に書かれていない |
Apache 2.0（商用利用もしやすいオープンなライセンス）で出た点は大きいです。一方で、実行に使う計算資源の費用は別の話です。
小さいモデルが重い書類に向く
発表で目立つのは、性能の数字よりもバランスです。NeoMME-Retriever-260Mは、ViDoRe v3（視覚文書検索の性能比較テスト）のnDCG（検索結果の並びの良さを見る指標）で0.523と報告されています。
同じ発表では、800M未満の評価対象で最も高い値とされています。ColQwen2.5との差は0.002で、パラメータ（AIの内部規模）は約14分の1です。
速度の話も現実的です。NVIDIA L40Sで2048×2048画像を扱う条件では、260Mモデルが毎秒約51ページをエンコード（検索用の表現に変換）したとされています。
さらに、late-interaction（細部ごとに照合する検索方式）の保存量は課題でした。発表では、約1.5MBから6kBへ減らし、品質を95%超残した構成が紹介されています。
検索が変わると、仕事の入口が変わる
非エンジニアに近い意味は、AIの答え方より前にあります。社内資料を探す力が弱いと、生成AIは読ませる資料を間違えます。
NeoMMEの方向性は、AIに渡す前の書類選びを強くすることです。答えを書くAIの前に、見つけるAIが進むという流れです。
RAG（検索した資料をもとにAIが答える仕組み）では、ここが効きます。元のページ画像を取り出せると、生成AIは表や配置を含めて読めます。
もちろん、NeoMMEは一般読者が今日から触るアプリ名ではありません。それでも、PDFだらけの仕事にAIが入り込む入口は見えます。
AIが賢くなる話は、会話のうまさだけではありません。どの資料を見つけるかが変わると、仕事のスピードも静かに変わります。