🐶 らぼまる🐶⚡の解説分析

• 🏢 開発元・ラボ: H Company
• 🧠 パラメータ規模: 260M (262,937,906) / 800M (793,715,032)
• 💻 動作要件・必要VRAM: CPU推論可能（クエリ応答78.3ms）/ GPU稼働時VRAM 4GB〜
• 📜 ライセンス: Apache 2.0（商用利用可能）
• 💰 利用料金: 完全無料 $0（オープンソースモデル）
• 🎯 最適ユースケース: 視覚的文書（PDF/図表）の高精度ベクトル検索（RAG）、Dense & Late-Interaction複合インデックス構築

独立したVision TowerとCausal Decoderを廃止し、単一タワー型構造を採用することで、260Mという軽量サイズでありながら3.75B規模の視覚文書検索精度に匹敵する「NeoMME」が公開されました。VRAMフットプリントとレイテンシを大幅に削減可能なエンコーダモデルです。

要点サマリー（結論）と実務インパクト

H Companyが発表した「NeoMME」シリーズ（260Mおよび800M）は、視覚的文書検索（Visual Document Retrieval: ViDoRe）に向けた単一タワー型双方向マルチモーダルエンコーダです。

従来のColPaliやColQwen2.5といったモデルは、生成用途のVLM（Vision-Language Model）を転用しているため、検索処理においては「生成を行わないデコーダ（Causal Decoder）」や「独立したVision Tower」が不要な計算コストやメモリオーバーヘッドとなっていました。NeoMMEはこれらを排し、スクラッチで学習された単一のTransformerタワー構造を採用しています。

実務上の価値は、パラメータサイズを従来の14.4分の1（260M）に抑えつつ、3.75B規模のColQwen2.5-v0.2と同等の検索精度を達成している点にあります。これにより、高価なGPUリソースが必須であった視覚RAGシステムを、エッジサーバーやCPUホスト環境で運用できるようになり、1リクエストあたりの計算コスト（Unit Economics）の大幅な最適化が期待できます。

制約と前提の解体（落とし穴と現実の検証）

NeoMMEをプロダクション環境に適用するにあたり、以下の設計上の制約に留意する必要があります。

1. テキスト生成能力の非搭載 NeoMMEは埋め込み表現の抽出（エンコーダ）に特化しています。画像や文書に対する直接のキャプション生成や対話応答を行う機能はありません。RAG構成では、検索結果を別途生成用LLM（ClaudeやGPT-4o等）に引き渡す必要があります。
2. パッチ分割と入力制限 画像入力は32x32 RGBパッチとして処理されます。最大16,384トークンのコンテキスト長に対応しますが、解像度が極めて高い図面や細長い画像では事前のアスペクト比補正や適切な分割前処理が必要です。
3. ベンチマークとドメイン特化の乖離 ViDoRe v3における260Mモデルのスコアは0.523 nDCG@10であり、ColQwen2.5（0.525）に肉薄しています。しかし、業界独自の特殊な手書き文字や複雑なレイアウトの帳票では、800Mモデル（0.556 nDCG@10）の利用や追加ファインチューニングの検討が必要です。

挙動とワークフローの差異（他モデルとの動作・安全性比較）

従来モデルとの主な違いは、1回のフォワードパスで性質の異なる2つのベクトル表現を同時に抽出できる点にあります。

• Matryoshka Dense Embedding: 一次スクリーニング用の高速なベクトル近傍検索に適合。
• 128次元 Late-Interaction Embedding: トークン/パッチレベルでの精度調整（再ランキング）に適合。

これにより、ベクトル検索用モデルと再ランキング用モデルを別々に運用する複雑さが排除されます。また、モデル自身による自動文章生成が発生しないため、ハルシネーション（誤情報の出力）のリスクなく確定的なインデックス化が行えます。

環境構築と最小実行コード（実装とクイックスタート）

NeoMMEはHugging Face Transformers（Day-zeroサポート）に対応しており、既存のPyTorch環境で動作可能です。

ローカルGPU環境がない場合でも、RunPod などのクラウドGPUを利用することで迅速に試走環境を構築できます。

1. 依存ライブラリのインストール

pip install transformers torch pillow

2. クイックスタートコード（Dense & Late-Interaction表現の同時抽出）

import torch
from PIL import Image
from transformers import AutoModel, AutoProcessor

# モデルとプロセッサの読み込み
model_id = "H-Company/NeoMME-260M-Retriever"
model = AutoModel.from_pretrained(model_id, trust_remote_code=True)
processor = AutoProcessor.from_pretrained(model_id, trust_remote_code=True)

# サンプルテキストと画像のロード
text = "2026年第3四半期の売上高推移のグラフ"
image = Image.open("sample_chart.png").convert("RGB")

# 入力の処理
inputs = processor(text=[text], images=[image], return_tensors="pt")

with torch.no_grad():
    outputs = model(**inputs)

# 1回のフォワードパスでDense表現とLate-Interaction表現を抽出
dense_vector = outputs.dense_embeds  # 一次検索用 Matryoshka Denseベクトル
late_interaction_embeds = outputs.late_interaction_embeds  # 精密再ランキング用表現

print(f"Dense Vector Shape: {dense_vector.shape}")
print(f"Late Interaction Shape: {late_interaction_embeds.shape}")

主要競合との比較マトリクス（費用対効果・ベンチマーク比較: 2026年09月07日時点）

項目	NeoMME-260M	NeoMME-800M	ColQwen2.5-v0.2	ModernBERT (Text Only)
アーキテクチャ	単一タワー型双方向	単一タワー型双方向	VLM転用 (Vision+Decoder)	双方向テキストエンコーダ
パラメータ数	260M	800M	3.75B	149M
ViDoRe v3 スコア	0.523 nDCG@10	0.556 nDCG@10	0.525 nDCG@10	N/A (画像非対応)
CPU推論レイテンシ	78.3 ms	約210 ms	測定不能 (メモリ超過)	45 ms
インデックス速度	51.3 pages/sec (L40S)	28.1 pages/sec (L40S)	6.2 pages/sec (L40S)	N/A
VRAMフットプリント	< 2 GB	< 4 GB	> 16 GB	< 1 GB
トークン効率比	ModernBERT比 44.4%削減	同等	基準値	基準値

現場の実践Tips・コミュニティ知見（裏設定・最適化フラグ・回避策）

• 2段階検索（2-Stage Retrieval）によるスループット最適化 まず「Dense埋め込み」を用いてQdrantやMilvusなどの近傍検索で上位候補（例: 100件）を高速抽出した後、「Late-Interaction表現」で精確なスコアリングを実施する構成をとることで、検索精度を維持したままQPS（1秒あたりの処理件数）を向上させられます。
• 広範語彙 BPE Tokenizerによるテキスト圧縮率 131,072語彙のTokenizerを採用しており、多言語テキストにおけるトークン消費が抑えられています。日本語文書を含むコンテキスト長上限への到達速度が緩やかになる利点があります。

採用判断チェックリスト（導入すべきケース vs 見送るべきケース）

導入すべきケース ⭕

• 大規模なPDFや図面資料から、レイアウト情報を保持した視覚RAGを低インフラコストで運用したい場合
• 既存のColPali等のVLM系エンコーダによるVRAM消費やサーバーコストを削減したい場合
• 省電力サーバーやエッジ環境でのローカル推論インデックスを構築したい場合

見送るべきケース ❌

• 入力画像に対して「この図の内容を説明して」といった自然言語での直接回答生成をモデル単体に求めている場合
• テキストデータのみの検索であり、画像やPDFの視覚的レイアウト情報が含まれない場合

よくある質問（FAQ）

Q1. NeoMMEだけでユーザーの質問に回答するAIチャットボットを作れますか？

いいえ、NeoMMEは検索・ベクトル抽出に特化したエンコーダです。NeoMMEで検索した情報を生成LLM（ClaudeやGPT-4o等）へ渡すRAG構成が必要です。

Q2. 260Mと800Mモデルの使い分けの基準は何ですか？

一般的なPDF/図表検索やコスト優先の場合は260M（3.75B級と同等精度）で十分です。より複雑な図面や最高精度が求められる場合は800Mモデルを推奨します。

Q3. GPUなしのCPUサーバーだけでも実用的に動作しますか？

はい、NeoMME-260MはCPUホストのみでもクエリエンコードを約78.3msで処理可能なため、低コストなCPUサーバー環境でも実効性のある検索システムを構築できます。