PDFやスライドを検索するとき、最初に考えるべき工程は本当にOCRなのでしょうか。
NeoMME: an efficient Multimodal-native and Multilingual Encoder は、H Companyが公開した多言語・マルチモーダル対応のエンコーダです。260Mと800Mの2サイズがあり、画像パッチとテキストトークンを単一の双方向Transformerで処理します。Visual Document Retrieval向けのNeoMME-Retrieverでは、密な埋め込みとlate-interaction用の埋め込みを1回の推論で返す設計が示されています。
ここで重要なのは、単に小さく速いモデルが出たことではありません。文書検索の設計思想が、「まずテキストに変換してから検索する」ものから、「ページそのものを検索対象として扱う」方向へ動いている点です。
従来のRAGでは、PDFをOCRやパーサでテキスト化し、チャンクに分け、ベクトル化する流れが一般的でした。この方法は扱いやすい一方で、表、図、レイアウト、注釈、文字サイズの差といった情報を落としやすい。業務文書では、むしろその視覚的な配置が意味を持つ場面があります。契約書、請求書、研究資料、管理表、設計書では、どこに書かれているかが何を意味するかに直結します。
NeoMMEが示している機会は、RAGの前処理を減らすことです。ページ画像をそのまま埋め込み、必要なページを取得し、後段のVLMに渡す。もちろん、すべての用途でOCRが不要になるわけではありません。監査可能なテキスト抽出、正確な引用、全文検索との併用は今後も必要です。それでも、検索の第一段階でレイアウトを捨てなくてよい選択肢が現実的になる意味は大きいです。
特に実務上の判断点は、精度だけではありません。NeoMME-Retriever-260Mは、記事中の評価で2048×2048入力時にNVIDIA L40S上で約51ページ/秒のエンコード速度を示し、late-interactionの保存容量も圧縮手法により大きく削減できるとされています。これは、PoCではなく継続的に文書を取り込む運用で効いてきます。検索品質が少し上がるだけでなく、インデックス更新の時間、GPU利用時間、ストレージ費用の見積もりが変わるからです。
導入判断としては、まず「テキスト化で意味が落ちる文書」が多いかを見るべきです。表や図が多い社内資料、レイアウト依存の帳票、多言語が混在する文書群では、Visual RAGの価値が出やすい。一方、本文中心のナレッジベースなら、既存のテキストRAGの方が単純で運用しやすい可能性があります。
NeoMMEは、RAGをより大きな生成モデルで補強する話ではなく、検索前の情報の捨て方を問い直す材料です。AI導入で見落とされがちなのは、モデルの賢さよりも、モデルに渡す前に何を失っているかです。文書が画像として意味を持つなら、検索基盤もそこから設計し直す余地があります。
関連記事
- Inside Microsoft’s two-decade push to cut water intensity while scaling for growth
- Introducing Claude Opus 5
- Granite 4.2 LLMs: How They’re Built
参考文献
コメント