社内のPDFを検索したいだけなのに、背後では文章生成にも使える大きなモデルが動いている。H Companyが公開した「NeoMME」は、視覚情報を使う文書検索に残る、この設計上の負担に向き合うモデルです。帳票や報告書では、文字だけでなく表の配置、図、見出しの位置も検索の手がかりになります。そのため画像と言語を扱えるモデルが役立ちますが、検索結果を探す処理そのものに文章生成の機能が必要とは限りません。

原文によると、ColPaliなどの文書検索モデルは、生成型の視覚言語モデルを検索用エンコーダーへ転用しています。エンコーダーとは、入力を検索や比較に使う数値表現へ変換するモデルです。転用された構成には、画像を処理する独立した「ビジョンタワー」と、文章を順番に生成するための因果デコーダーが残り、検索では使い切れない構造が計算量やパラメータ数の負担になります。



NeoMMEは、この二つを持たず、単一の双方向Transformerで文章と画像を処理します。公開されたモデルの規模は約2.6億と約8億パラメータで、検索向けに追加学習したものが「NeoMME-Retriever」です。小さい方でも視覚的な文書検索の評価で、約37.5億パラメータの比較モデルに近い成績を示しました。

企業が注目すべき点は、単純にモデルが小さいことだけではありません。文書を登録する計算、検索時の応答、検索用データの保存という別々のコストを、精度と合わせて検討できる点です。ただし、視覚的な文書検索での好成績を、あらゆる社内検索での優位性と読み替えることはできません。NeoMMEの価値は、対象文書と運用条件を絞って見る必要があります。

NeoMMEでは、文章をトークンという処理単位に分け、画像は重なりのない32×32ピクセルの小片に分割します。この画像の小片が「パッチ」です。文章と画像は入口でそれぞれ数値表現へ変換されますが、その後は同じTransformerの層を通ります。画像専用の大きなモデルで特徴を抽出してから言語モデルにつなぐ構成とは異なり、共通の処理基盤をランダムな初期状態から学習しています。

文章側には、ALBERTという言語モデルで使われた方式に沿う、埋め込みの因数分解を採用しています。256次元の表現をモデル内部の幅へ変換する仕組みです。画像側は2層のMLPというニューラルネットワークでパッチを変換し、別途事前学習されたSigLIP2などのビジョンタワーは使いません。「単一タワー」とは、入力形式まで同一にすることではなく、文章と画像が主要な処理層を共有する設計を指します。



両モデルが扱える文脈長は16,384トークンです。原文では、3,840×2,160ピクセルの4K UHD画像を2枚、パッチ化して収められる長さと説明されています。ただし、入力できることと、細かな文字まで正しく検索に利用できることは別の評価項目です。実務では、文字の大きさやページ構成も確かめる必要があるでしょう。

計算を抑えるため、多くの層は近くの入力を双方向に参照し、6層ごとと最終層では入力全体を参照します。近傍の情報とページ全体の関係を扱い分ける構成です。また、独自に学習した語彙数131,072のトークナイザーは、FLORES-200の指定評価データに含まれる対象14言語で、ModernBERTよりトークン数が44.4％少なかったとされています。この数字は対象データでの結果であり、日本語の社内文書でも同じ削減率になるという意味ではありません。

文章と画像を同じモデルに入れても、モデルが両方を十分に使うとは限りません。周囲の文章だけで答えを推測できれば、画像を読む必要が薄れるためです。NeoMMEの事前学習は、文章の一部を隠し、見えている情報から復元する「離散マスク拡散」を使います。画像がある場合には、そのパッチも復元の手がかりとして与える方式です。

文章のみの学習区間では、隠す割合を0から100％の範囲で一様に選びます。文章と画像を組み合わせた区間では、その範囲を30から100％に設定しています。文章がほとんど見えている状態を避け、言語情報だけに頼る近道を減らす狙いです。ここでいう拡散は事前学習の方法を表しており、検索時に回答文や画像を生成するという意味ではありません。



画像を利用する効果は、条件を変えて比較するアブレーション実験でも調べられています。文章の90％を隠した条件で、ページ画像のパッチが見えるようにすると、隠されたトークンの正答率は2.6億モデルで38.4ポイント、8億モデルで40.5ポイント上がりました。これは、強く文章を隠した条件で画像が復元を助ける証拠です。ただし、検索精度が同じ幅だけ向上したという結果ではない点に注意が必要です。

学習規模は小さくありません。各学習実行で処理した入力は約5,240億トークンで、このうち文章のみの部分が約2,900億トークンを占めます。使用したH100アクセラレーターは、それぞれ16基と32基です。モデルのパラメータ数が少ないことと、事前学習が少ない計算資源で済むことは分けて考えるべきでしょう。企業にとって現実的な検討対象は、公開済みモデルを使った推論や、自社データでの評価・追加学習に必要な負担です。

NeoMME-Retrieverは、共通のモデルに二つの検索用出力を追加しています。一つは入力全体を集約する密ベクトルの出力で、複数の次元幅を利用するMatryoshka方式に対応します。もう一つは、各文章トークンと画像パッチを128次元のベクトルへ変換する「レイトインタラクション」の出力です。両方を一度の推論で得られるため、文書全体の表現と細かな部分の表現を用途に応じて検討できます。

レイトインタラクションは、問い合わせと文書をそれぞれ符号化した後で、部分ごとの一致を評価する検索方式です。ページ全体を一つのベクトルにまとめる場合より細かな対応を扱える反面、保持するベクトルが多くなります。検索精度の数字は、この保存負担と合わせて読む必要があります。



視覚的な文書検索のベンチマーク「ViDoRe v3」では、2.6億モデルがnDCG@10で0.523、8億モデルが0.556を記録しました。nDCGは、関連性の高い文書を上位に並べられているかを見る指標で、@10は上位10件を評価することを示します。正答率そのものではありません。2.6億モデルと、約37.5億パラメータのColQwen2.5-v0.2との差は0.002以内です。約14.4分の1の規模で近い成績を得た点は、計算資源を抑えたい企業にとって検証する理由になります。

ただし、8億モデルは同程度の規模のVultron Retriever Flashを0.9ポイント下回っています。文章検索のBEIR-15でも、レイトインタラクションの評価値はそれぞれ0.4881と0.5126で、1.49億パラメータのLateOnの0.5722には届きませんでした。著者らは文章検索の教師データ規模を一因に挙げていますが、規模を増やせば差が解消するという実証ではありません。文字中心の検索までNeoMMEへ統一する判断は、現時点の結果だけでは支えられません。

文書検索の費用は、モデルを動かすGPUだけで決まりません。レイトインタラクションでは、文書の各部分に対応する多数のベクトルを検索用インデックスに保存します。原文によると、2,048×2,048ピクセルのページからは4,162本のベクトルが得られ、float32形式ではViDoRe v3の文書当たり約1.5MBになります。文書数が増えるほど、この保存量が運用上の検討事項になります。

NeoMMEでは、階層的なトークンプーリングと量子化を組み合わせて容量を抑えます。プーリングは複数の表現をまとめ、ベクトルの数を減らす操作です。量子化は数値をより少ないビット数で表現し、一本当たりの保存量を減らします。どちらも情報の持ち方を簡略化するため、圧縮後の検索品質を確認する必要があります。



プーリング係数10で、問い合わせと文書の両方をint8にすると、容量は1ページ当たり39.0kBとなり、39.4倍の削減を達成しました。この設定で維持したnDCG@10は基準値の99.16％です。係数8で問い合わせをint8、文書をバイナリ表現にした場合は6.0kBとなり、削減倍率は255.5倍、維持率は95.19％でした。これらの維持率は基準スコアに対する比率であり、検索の正答率を示すものではありません。

つまり、6.0kBという最小の数字には品質との交換条件があります。資料の候補を広く探す用途と、必要な記述の取りこぼしをできるだけ避けたい用途では、適切な設定が異なるでしょう。表示容量は丸められているため、記載値だけから計算した倍率が厳密に一致するとも限りません。また、ここで示されているのは検索用表現の容量です。元のPDF、メタデータ、バックアップなどを含むシステム全体の保存費用が、同じ割合で減るわけではありません。

公開条件も導入候補を選ぶ材料になります。原文では、すべてのチェックポイントがApache 2.0ライセンスで提供され、公開初日からHugging Face Transformersに対応するとされています。Hugging Face Transformersは、学習済みモデルを利用するためのライブラリです。既存の機械学習基盤で扱う際の接続点が用意されていることは、試験導入を進めるうえで役立ちます。ただし、ライブラリ対応だけで文書管理システムとの連携まで完成するわけではありません。

処理性能では、単一のNVIDIA L40Sで、2.6億モデルが毎秒51.3ページを符号化しました。2,048×2,048ピクセルの入力をそろえた比較では、ColModernVBERTの毎秒26.0ページに対して1.97倍です。CPUのみのホストで問い合わせを符号化する時間は78.3ミリ秒と報告されています。この数値は問い合わせの変換時間であり、インデックス検索や通信を含む応答時間全体を示してはいません。



日本企業での評価は、表や図を含むPDFと、文字中心の規程・議事録を分けて始めると、得意不得意を把握しやすくなります。前者ではページの配置が検索に役立つか、後者では既存の文章検索モデルを置き換える理由があるかを確認できます。多言語対応という説明だけでは、日本語の略語、社内固有の用語、小さな注記への対応力までは判断できません。原文が弱点に挙げる自然画像への転用性能も、文書検索の成績とは別に考える必要があります。

実行する一歩は、実際に利用者が探す代表的な文書と問い合わせを組にして、評価用セットを作ることです。既存方式とNeoMMEについて、上位に必要文書が出るかを比較し、同じデータで登録時間、検索全体の応答時間、インデックス容量を測ります。そのうえで39.0kBと6.0kBの圧縮設定も試せば、自社の検索品質を保てる条件でどこまで負担を減らせるかを判断できます。

原文記事：H Company Releases NeoMME: A Family of 260M and 800M Single-Tower Multimodal Encoders That Drop the Vision Tower and Causal Decoder

数値と公開条件は提供された原文に基づきます。仕組みの補足と日本企業向けの評価手順は、原文の結果を踏まえた解説・提案です。