- 複雑な文書から情報を抽出する際、従来のOCRやパース方式では意味を十分に保持できない
- MorphikはColPaliモデルベースのビジュアル文書埋め込み方式により、表、チャート、レイアウトの文脈まで直接理解する方法を実装している
- 既存パイプラインと比べて、この方法は精度と情報保持の面で大きく優れており、ベンチマークテストで最大95.56%の精度を達成した
- さらに、MUVERAとTurbopufferの導入により、大規模な文書検索で高速化を実現した
- 今後はマルチ文書推論、ワークフロー統合、専門家級の解釈など、実用的な文書業務の自動化を目標としている
複雑な文書パースの限界とRAGの苦難
- チャート、図表、表が混在する複雑なPDF文書から情報を抽出しようとすると、OCRやパースのパイプラインが必要な情報をしばしば失ってしまう問題がある
- 入れ子になった表、重要な図表、注釈の多い技術文書、さらにはテキストのないマニュアルなど、実際の現場で従来パイプラインの限界を痛感する
- 従来パイプラインの工程:
- PDFにOCRを適用する（数字や文字を誤読することがある）
- レイアウト検出モデルで表や図表の判別を試みる（失敗する可能性が高い）
- 読み順の復元（視覚的な流れを取りこぼすことがある）
- 図表キャプションの認識（ニュアンスが抜け落ちやすい）
- テキストのチャンク化（関連情報が分断されることがある）
- ベクトル埋め込みの生成とベクトルDBへの保存（位置情報や文脈が失われる）
- 例: 単純な表でも
1,000 を l,0O0 と読み違えたり、表とヘッダーが分離されて合計計算に失敗したりするケースが多い
- 図表の凡例を本文と誤認し、パーセント値が見当違いの位置に散らばる問題など、実際の情報損失事例が頻繁に起きる
新しいアプローチ：視覚ベースの文書理解への転換
- Morphikチームは**「文書を人間のように視覚オブジェクトとして理解したらどうだろう？」**という問いから転換点を見いだした
- 最新研究（ColPali）とVision Language Model(VLM) の進歩により、画像を直接埋め込むことで、パースやOCRなしに文書全体の文脈や視覚情報を保持できる
- 各文書ページを高解像度画像として処理し、パッチ単位に分割して、視覚情報とテキスト情報の両方を反映した埋め込みを生成する
- SigLIP-So400m Vision Transformerが視覚パッチ埋め込みを生成し、PaliGemma-3B言語モデルが文書構造を理解する
- クエリ（「Q3売上推移」など）に対して、テキスト・チャート・表・色など多様な視覚的手がかりまで含めたlate interaction検索方式で関連情報を正確に抽出する
- 文書内の位置、レイアウト、色、グラフの変化など、あらゆる視覚情報を維持—人が文書をひと目で把握するのに近い
従来のパースとColPali方式の比較
- 従来のパースベースのパイプラインは各段階で情報が失われ、テキスト埋め込みと画像埋め込みが分離されるため、文書内の空間的関係を解釈できない
- 一方、ColPali方式は単一の視覚埋め込み空間ですべての情報を統合し、文書全体の意味と文脈を保持する
- 実際のベンチマーク（財務文書中心、公開データセット）では、Morphik（ColPaliベース）は最大95.56%の精度を記録した（既存のLangChain+OpenAI text-embeddingは72%、OpenAI File Searchは13.33%にとどまる）
- ViDoReベンチマークでは、視覚ベース方式が従来のパース方式に対してnDCG@5で14ポイント以上高い性能を達成した
性能最適化と実運用への適用
- 初期方式の欠点は計算負荷による速度低下であり、パッチごとにベクトル検索が必要な構造のため、毎秒数千万件超のクエリには不向きだった
- MUVERA論文を参考に、マルチベクトル検索を単一ベクトル検索に置き換える方式（固定次元エンコーディング）を導入した
- Turbopuffer特化型ベクトルDBとの組み合わせにより、クエリ速度を3〜4秒から30ms水準まで改善した
- これにより、従来のテキストパースよりも大幅に速い速度で数百万件規模の文書検索が可能になった
活用分野とシンプルなAPI提供
- さまざまな種類の文書において、視覚構造や情報損失を伴わない高精度検索を支援する
- 複雑な表やチャートが重要な金融文書
- 図面中心の技術マニュアル
- 請求書、レシートにおけるレイアウトベースの情報抽出
- 研究論文内の視覚資料・数値資料の理解
- 医療記録におけるレイアウトベースの関係認識
- APIは文書アップロード後に自然言語で問い合わせるだけの非常にシンプルな構造で、「1万ドル超の罰金条項がある契約書をすべて見せて」といった要求に対応できる
今後の方向性：マルチ文書インテリジェンスとより深い理解
- マルチ文書インテリジェンス: 複数文書間の相互参照や情報追跡機能を開発中
- 単一文書検索を超えて、複数文書間の関係追跡と推論（例: 契約書の条項→規制文書→実行マニュアルまで連携）を支援する
- エージェント理解体系: 文書内の単純な質疑応答を超え、条項抽出→他文書での検証→詳細のクロスチェックといったチャンク間の論理推論の自動化を目指す
- ワークフロー統合: 複数契約書間の条件比較、技術判断の履歴追跡など、実務プロセスに合わせた文書自動化インテリジェンスを高度化する
限界と今後の目標
- 現在の方式は専門家レベルの解釈や文脈判断力にはまだ達していない
- 金融専門家による深い解釈のような部分は、なお技術的に不十分であり、信頼性、不確実性の定量化などエンタープライズ要件に向けた追加開発が必要だ
- ビジュアル理解とドメイン知識グラフの結合、因果関係推論、信頼性指標の提供などが今後の主要課題となる
結論
- 文書は視覚的な知識オブジェクトとして扱うべきであり、パースの限界を超えて画像ベースの文書理解がRAG環境でより優れた解決策となる
- Morphikは文書情報抽出の新たな標準を提示しようとしており、複雑な文書ワークフローの自動化と実務への適用を目指している
- 詳細な機能体験はmorphik.aiで可能
1件のコメント
Hacker Newsの意見
多くの人が知っておくべき根本的な問題がいくつもある
LLMは一般に4kテキストトークンで事前学習され、その後で長いコンテキストウィンドウへ拡張される（4000から4001へ増やすのは簡単だが、画像はトークナイズ方式が異なるためそれができない）
その結果、分布外となり、2〜3枚以上の画像を扱うとハルシネーションの問題が深刻に発生する
1536×2048解像度のPDFはテキストより3〜5倍多くのトークンを使うため、推論コストが増え、応答速度も遅くなる
低解像度に落とすと画像がぼやける
画像は元サイズ自体が重いため、必要な画像をダウンロードするだけでも各リクエストに待ち時間が追加される
小規模ベンチマークでは、チャートや表が多い金融文書に対しては、基本的なテキストチャンク方式より当然うまく機能する
個人的には、GeminiのようにOCRで画像に注釈を付けられるようにして結果を比較してみたい
エンドツーエンドの画像アプローチは特殊ケース（特許、建築ダイアグラムなど）では理にかなっているが、本当に最後の手段だ
LLMには読めない部分にもっともらしいテキストを作り出してしまう問題があり、結果をさらにひどくすることがある
たとえばGPT4.1は1296×179サイズのスクリーンショットでは完璧に動作したが、50%に縮小して650×84で与えると、"Pdf's at 1536 × 2048 use 3 to 5X more tokens" を "A PNG at 512x 2048 is 3.5k more tokens" に変えて返した
たいていは正しくやってくれるが、このように微妙なディテールが変わる点には注意が必要だ
gemma3系の興味深い特性は、入力画像サイズを増やしても処理メモリ要件が増加しないことだ
第2段階エンコーダが固定サイズのトークンに圧縮するためだ
実際かなり有用だ
ただしそうすると、処理する文書群全体が大型VLMを必ず通ることになる
高コストかつ低速になりすぎるかもしれない
ここには明確にトレードオフがある
ほとんどの場合、今のやり方が最も効果的だった
何でもLLMに入れることがあるが、状況によっては適していないかもしれない
すべてを必ずLLMで処理する必要はない
これはRAGパイプラインを変えるアイデアへ拡張できそうだ
各RAG結果ごとに、モデル処理段階で画像からユーザークエリに直接関係する情報を抽出し、そのテキスト結果を集めて最終生成の入力にできる
こうすれば複数画像のトークン上限を回避し、画像理解の過程を並列化できる
私と同僚は6か月前、フランス政府機関向けにこうした実装を試した
オープンソースとしてここで公開している: https://github.com/jolibrain/colette
本業ではなく放置気味だが、多少のチューニングでかなり効率よく動く
真の醍醐味は、パイプライン全体を完全に微分可能にして、特定データセット向けにviz ragをファインチューニングできる点だ
レイアウトモデルもカスタマイズして精密な文書理解が可能だ
通常、最大の障害は高品質な評価セットが必要なことだ（これが常に障害だ）
OCR 対 画像 + 汎用LLM のベンチマーク研究を多数行った: https://getomni.ai/blog/ocr-benchmark
画像から直接抽出する方式の最大の問題はマルチページ文書だ
単一ページでは（OCR=>LLM vs Image=LLM）でわずかに直接画像のほうが良かったが、5枚以上の画像になるとOCR先行方式に比べて精度が急激に落ちる
実際、テキストにおけるロングコンテキスト再現も難題だが、LLMはそのために最適化されている一方、画像のロングコンテキスト再現はまだかなり不十分だ
画像の上に直接小さなLLM変換レイヤーを載せるのもかなり効果的だ（つまり直接OCRする代わりに、5枚の画像を一度に小規模ビジョンモデルへ送り、文書の最重要ポイントだけを抽出する方式）
現在はLLMのキャッシュやアテンションマップを修正して、より大きな画像バッチがうまく動くよう研究している
スライディングウィンドウや無限リトリーバルのようなアプローチが有望に見える
個人的な推測だが、マルチモーダルモデルの進歩が加速しているのを見ると、画像のロングコンテキストもまもなく大きな問題ではなくなると思う
このブログ記事は、リトリーバルにビジョンモデルを使うことについて良い指摘をしているが、いくつか問題を指摘したい
文書パースとは、文書をMarkdown/JSON（あるいは抽出時にはスキーマに沿った出力）といった構造化テキストに変換する作業だ
RAGはその用途の一つにすぎず、他にもさまざまな用途がある
ColPaliはリトリーバルには優れているが、（少なくともネイティブでは）純粋な文書パースには使えない
著者は主にビジュアルリトリーバルのベンチマークにしか触れていない
標準OCRよりうまく動くことが多いが、
a. 依然としてロングテールの精度問題がある
b. confidence score、bounding boxなどのメタデータが欠ける
c. スクリーンショットのパイプライン自体も高度化するには手間がかかる
画像トークンのほうがはるかに強力だが、テキストトークンは保存コストがはるかに安く、リトリーバル時に文書全体へクエリできる（チャンク単位ではなく）
（参考までに、私はllamaindexのCEOで、LlamaCloudでパース／リトリーバルの両方をやってきた。単なる一般論としての見解だ）
去年、特許文書分析システムを作るのにかなり時間を費やした
特許には抽象的なダイアグラム、化学式、数式など多様なコンテンツが含まれており、LLM向けにデータを準備するのは本当に厄介だ
私が見つけた最も簡単な方法は、各ページを「写真を撮るように」変換したうえで、LLMにその内容を説明するJSONとメタデータ（ページ番号、視覚要素数など）を生成させることだった
複雑な画像はモデルに描写させればよい
こうすれば、望みのベクトルストアなどにJSONを簡単に埋め込める
コスト効率は評価しづらいが、この方法は著者の提案より簡単で効果的だ
たとえばチャートからx, yの組をモデルが大半うまく取り出せたとしても、ユーザーが特定のx/yをピンポイントで尋ねたら取りこぼすかもしれない
モデル推論段階で画像を直接見せれば、ユーザーの質問に正確に答えられるので、このアプローチのほうが効果的だ
ここで唯一の本当の障害はリトリーバル品質で、これは比較的小さな問題だ
つまり、適切なコンテキスト伝達さえできれば、残りはLLMがうまくカバーしてくれる
そうでなければ、OCR、パース、画像描写など、対処すべき問題が急増する
ただ、LLMの機会は既存価値（特許文書など）の再分類／再処理に集中していることを示している
90〜00年代にはソフトウェア企業が既存の紙書類をDBに変えて事業で成功した
新しく価値あるデータセットをゼロから作るのは、今でも多大な投資と労力が必要だ
経験上、この方式はいまひとつだ
フォントによってはo（オー）と0（ゼロ）の区別が難しい
文書（doc/xls/pdf/html）を画像に変換すると、そうした識別情報が失われる
シリアル番号などは、人間でも見分けられないことがある
そのためPDFは画像としてレンダリングして抽出するのがかなり合理的だ
それ以外のフォーマットは文書を直接パースするほうがよい
ただし実務的には、ページデザインを行う際、実際の画像をモデルに見せるほうがコードだけを渡すよりデバッグにずっと効果的だ
1 vs I、0 vs O の問題は現実に存在するが、データ自体にダイアグラムやチャートが多い文書は、画像だけで処理したほうがはるかに楽だった経験が多い
（選択バイアスがあるかもしれない）
Geminiにスケジュールをコピーして問い合わせようと数分試したが、HTMLでもうまくいかなかった
結局スクリーンショットを撮り、不要部分を黒塗りして画像を入れたら非常によく動いた
マルチモーダルRAGでもうこの問題は解決されているように思え、気になる
Flash 2.5、Sonnet 3.7などでかなり満足のいく画像分析結果を得ている
むしろテキストより画像を与えたほうが良い応答を得られる感触がある
https://www.youtube.com/watch?v=p7yRLIj9IyQ
ただし初期状態のマルチベクトル（マルチモーダルRAGの基盤）は非常に扱いにくく、類似度計算も非常に高コストで、スケールアップが難しい
量子化、単一ベクトル変換（固定次元エンコーディング）、インデックス最適化などが必要だ
それこそが私たちがMorphikでやっていることだ
私もすべての請求書をまとめてスキャンしようとして、メールボックスから添付ファイルだけを抽出し、1つずつアップロードするスクリプトを回して「インボイス: はい／いいえ」と、各項目／業者名／日付／インボイス番号などを抽出させた
結果として読取率は高く、3時間以上LLMコールが走ったが自動化なので気にしなかった
その後、銀行明細との照合までLLMにやらせたが、添付ファイルで来なかった一部のインボイスだけが漏れた
ただし、インボイスと明細の照合はLLMがかなり雑で、数ドル違うだけでもその明細だと答えてしまった
なので当面は会計士が必要そうだ
コストはざっくり予想しておらず、Claude 3.7のような安価なモデルを使った
ColPaliが直感的で強力なのは理解するが、それでも文書処理方式には利点がある