{"notes":[{"id":"text-spotting/olmocr","category":"text-spotting","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"olmOCR","subtitle":"モデルにカンペを渡す","author":"Z. Yuan","paperDate":"2025-02-25","publishedOn":"2026-02-03","paperTitle":"olmOCR: Unlocking Trillions of Tokens in PDFs with Vision Language Models","paperUrl":"https://arxiv.org/abs/2502.18443","bibliography":{"title":"olmOCR: Unlocking Trillions of Tokens in PDFs with Vision Language Models","authors":["Jake Poznanski","Aman Rangapur","Jon Borchardt","Jason Dunkelberger","Regan Huff","Daniel Lin","Aman Rangapur","Christopher Wilhelm","Kyle Lo","Luca Soldaini"],"url":"https://arxiv.org/abs/2502.18443","pdfUrl":"https://arxiv.org/pdf/2502.18443v3","codeUrl":"https://github.com/allenai/olmocr","preprint":{"id":"2502.18443","submittedOn":"2025-02-25","url":"https://arxiv.org/abs/2502.18443"},"publication":null,"citation":"@misc{textspottingolmocr2025,\n  title = {{olmOCR: Unlocking Trillions of Tokens in PDFs with Vision Language Models}},\n  author = {Jake Poznanski and Aman Rangapur and Jon Borchardt and Jason Dunkelberger and Regan Huff and Daniel Lin and Aman Rangapur and Christopher Wilhelm and Kyle Lo and Luca Soldaini},\n  year = {2025},\n  eprint = {2502.18443},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2502.18443}\n}\n","citationPath":"/content/papers/citations/text-spotting/olmocr.48e77a79a2cb.bib"},"thumbnail":{"src":"/content/papers/assets/044c3df431d57e98d00da32fff3b3df21f0cad1cb9a2e9176487efa55b628c17.png","width":994,"height":622},"locale":"ja","path":"/content/papers/ja/text-spotting/olmocr.a9e2cdc3eb4a.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"document-anchoringpdf内の文字も一緒にモデルへ渡す","text":"Document anchoring：PDF内の文字も一緒にモデルへ渡す","depth":3},{"id":"gpt-4oで学習データを作る","text":"GPT-4oで学習データを作る","depth":3},{"id":"7bの専用モデルをファインチューニングする","text":"7Bの専用モデルをファインチューニングする","depth":3},{"id":"考察","text":"考察","depth":2},{"id":"olmocr-benchユニットテストで採点する","text":"olmOCR-Bench：ユニットテストで採点する","depth":3},{"id":"言語モデルの学習に使う","text":"言語モデルの学習に使う","depth":3},{"id":"コスト","text":"コスト","depth":3},{"id":"コミュニティの反応","text":"コミュニティの反応","depth":3},{"id":"この論文を読むときの注意点","text":"この論文を読むときの注意点","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"Web上には、兆単位のPDFがあります。論文、レポート、マニュアル、政府文書。多くの内容はPDFの中にしかなく、Webページでは見つかりません。言語モデルを学習させるチームにとっては、まだ掘られていない鉱山です。\n\n厄介なのは、PDFがもともと「テキストを読み出す」ために設計されていないことです。\n\nPDFは元来、「文書を紙にどう印刷するか」を記述するためのものでした。ファイルに保存されているのは、見出しや段落といった意味のある単位ではありません。一つひとつの字形と、そのフォント、サイズ、座標です。論文のFigure 2に例があります。タイトルの「olmOCR」はPDF内では6件の記録で、1件に1文字ずつ、それぞれ変換行列を持っています。どの文字から読み、どの段落がどこに続くのか、PDFは関知しません。\n\nアレン人工知能研究所（Ai2）は、2025年2月にolmOCRを発表しました。目標は、大量のPDFを、きれいで読み順どおりに並んだプレーンテキストに変換することです。本稿は2025年7月のv3に基づきます。モデル、学習データ、コードは、いずれも寛容なライセンスで公開されています。\n\n## 問題の定義\n\n当時の方法は、大きく二派に分かれていました。\n\n- **多段式ツール**：MinerUやMarkerは、レイアウト分割や表の解析など、複数のモデルをつなぎます。GROBIDやPaperMageのようなツールは、学術論文の処理に特化しています。\n- **エンドツーエンドモデル**：NougatやGOTは、ページ画像を入力し、テキストを直接出力します。\n\n著者らが指摘するように、画像しか見ないエンドツーエンドモデルは、一つの手がかりを手放しています。**多くのPDFはもともとデジタルで作られていて、中にすでにテキストがある**のです。そのテキストは乱雑でも、文字そのものは正しいのです。\n\n一方で、GPT-4oのような汎用VLMにそのまま読ませても、品質は足りません。著者らの観察では、文字が密集していたりレイアウトが複雑だったりするページで、画像だけを頼りにしたGPT-4oは、内容を読み落とし、書き換え、原文を「補完」しがちです。頼まれてもいないのに、図に説明を付けることもあります。付録には、さらに具体的に書かれています。ページ画像だけを与えると、モデルは途中で切れた文を補完し、画像が不鮮明なときには、もっと長い文章を作り出すことさえあります。\n\nそこで、問いはこうなります。VLMに画像を見せると同時に、PDF内のテキストも参考として渡せないか？\n\n## 問題の解決\n\n### Document anchoring：PDF内の文字も一緒にモデルへ渡す\n\n[![document anchoringの模式図：左はPDFの1ページ、右はそこから抽出したアンカーテキスト。ページサイズ、画像の位置、座標付きのテキストブロック（「[71x459]Figure 1」「[71x398]1 Introduction」など）を含む](/content/papers/assets/044c3df431d57e98d00da32fff3b3df21f0cad1cb9a2e9176487efa55b628c17.png)](/content/papers/assets/044c3df431d57e98d00da32fff3b3df21f0cad1cb9a2e9176487efa55b628c17.png)\n\n*原論文Figure 3。[**v3 PDFの17ページ**](https://arxiv.org/pdf/2502.18443v3#page=17)から抜粋、CC BY 4.0。左がPDFのページ、右がプロンプトに挿入するアンカーテキストです。*\n\n右側の枠が、著者らのいう**document anchoring**です。手順は次のとおりです。\n\n1. pypdfでPDF内部の構造を読み、各テキストブロックと画像を、ページ上の座標とともに取り出します。\n2. 優先順位に従ってブロックを選び、文字数の上限までプロンプトに入れます。見出し、要旨、フッターの情報は文書の冒頭と末尾に多いので、そこにあるブロックを優先します。\n3. このアンカーテキストをページ画像と一緒にVLMへ渡し、そのページのプレーンテキストを出力させます。\n\n図の形式を見てみましょう。`[71x459]Figure 1`は、座標(71, 459)に「Figure 1」というテキストがあることを示します。`[Image 480x298 to 525x312]`は、画像の位置を表します。\n\n著者らは率直に、このアンカーテキストは**ノイズが多い**と述べています。読み順は保たれておらず、本文にさまざまな定型文や、PDFのレンダリングで生じたノイズが混ざっています。それでも、モデルがそのまま写せる文字と、ページ上でのおおよその位置を提供します。VLMはレイアウトを読み取って順序を整え、PDFのテキストは文字を固定する役目を担います。\n\nページがスキャン画像で埋め込みテキストがなければ、アンカーテキストにはページサイズと画像の位置しか残りません。モデルは主に画像から読むことになります。\n\n### GPT-4oで学習データを作る\n\nアンカリングの方法ができたので、著者らはまずそれを使って学習データを作りました。\n\n2024年10月に、「教師」モデルの候補をいくつか比べています。Gemini 1.5はRECITATIONエラーを頻繁に返し、GPT-4o miniはハルシネーションが多すぎ、Claude Sonnet 3.5は高すぎました。最終的に選ばれたのは`gpt-4o-2024-08-06`です。\n\nプロンプトでは、GPT-4oに構造化されたJSONで答えるよう求めます。まずページの言語、向き、表の有無などのメタデータを出力させ、次に読み順どおりのテキストを出力させます。著者らは、この構造が重要だと気づきました。ページにテキストがないとき、GPT-4oが図の説明をでっち上げるのを防げるのです。\n\nこうして作られた**olmOCR-mix-0225**は、258,641ページ、102,825件の文書からなります。そのうち96,929件は約2.4億件の公開WebのPDFからのサンプル、5,896件はInternet Archiveのパブリックドメインの書籍です。サンプリングによる推定では、学術文書が約56%を占め、次いでパンフレットと法律文書です。\n\n### 7Bの専用モデルをファインチューニングする\n\nアンカリングのプロンプトでGPT-4oを動かす効果は上々でした。ただ、その効果はモデルによって異なり、データ生成の技法として使うほうが向いていると著者らは気づきます。そこで次の問いに進みます。より小さな専用VLMで、GPT-4oと同じくらい良くできないか？\n\nQwen2-VL-7B-Instructを出発点に、olmOCR-mix-0225で約1.2エポックのファインチューニングを行いました。H100を8枚積んだマシン1台で、16時間の学習です。ファインチューニングでは、ページを長辺1,024ピクセルに縮小し、アンカーテキストは6,000文字を上限とします。典型的な1ページの入力は、画像が約1,000トークン、アンカーテキストが約1,800トークンで、合計約3,000トークンです。\n\n## 考察\n\n### olmOCR-Bench：ユニットテストで採点する\n\nOCRシステムを比べるにあたり、著者らは編集距離のような「参照解答にどれだけ似ているか」の指標を使いたくありませんでした。挙げている例は数式です。$x$と$x_i$は、文字列としてはわずかな差ですが、意味はまったく違います。\n\nそこで作ったのが**olmOCR-Bench**です。約1,400件のPDFと、合格か不合格かが決まる7,010個のユニットテストからなり、どのテストもプログラムで明確に判定できます。\n\n- **テキストの存在**：1〜3文程度のテキストが、出力に現れるか。\n- **テキストの不在**：ヘッダー、フッター、ページ番号といった周辺の内容が、除外されているか。\n- **読み順**：二つのテキストの前後関係が正しいか。たとえば1ページに複数のニュース記事があるなら、各記事の見出しが第1文より前にあるかだけを確認し、記事同士の順序は問いません。\n- **表**：ある値のセルが存在し、その上と左のセルが期待どおりか。\n- **数式**：参照のLaTeXをKaTeXでレンダリングして各記号の相対位置を記録し、出力に同じ配置の記号の組があるかを見ます。\n- **基本チェック**：全ページに適用します。テキストが出力されていること、末尾に30回を超えて繰り返されるn-gramがないこと、中国語・日本語の文字や絵文字がないことを確認します。\n\n基本チェックは、「繰り返しに陥る」と「あるはずのない文字が出てくる」を、そのまま必須問題にしたものです。\n\n\n> [!NOTE]\n> \n> 論文には、このベンチマークの規模について3通りの書き方があります。要旨は1,400件のPDF、§3は1,402件、結論は1,403件です。テスト数はいずれも7,010です。\n\n\n[![olmOCR-Benchの結果表：GOT OCR、Marker、MinerU、Mistral OCR API、GPT-4o、Gemini Flash 2、Qwen 2 VL、Qwen 2.5 VL、olmOCRについて、ArXiv、古いスキャンの数式、表、古いスキャン、ヘッダー・フッター、多段組み、長文の小さな文字、基本チェックの8つのソースごとの合格率と総合スコア](/content/papers/assets/970cd043bba14de362481d37c8428e947780e9ec1c949f7846a8be7c4f58fbbf.png)](/content/papers/assets/970cd043bba14de362481d37c8428e947780e9ec1c949f7846a8be7c4f58fbbf.png)\n\n*原論文Table 4。[**v3 PDFの8ページ**](https://arxiv.org/pdf/2502.18443v3#page=8)から抜粋、CC BY 4.0。列は順にArXiv、古いスキャンの数式、表、古いスキャン、ヘッダー・フッター、多段組み、長文の小さな文字、基本チェックです。総合スコアは各ソースの平均で、95%信頼区間を付けています。*\n\n総合スコアが最も高いのはアンカリング版のolmOCRで、75.5です。商用のMistral OCR APIは72.0、Markerは70.1、MinerUは61.5、GOTは48.3にとどまります。著者らは、olmOCR-Benchをモデルの学習が終わった**後で**作ったと特に断っています。ベンチマークに合わせてモデルを何度も調整するのを避けるためです。\n\n表には、細かく見る価値のある対照が一組あります。**アンカリングの効果は、モデルによって大きく違う**のです。\n\n| モデル | アンカーなし | アンカーあり | 差 |\n| --- | ---: | ---: | ---: |\n| GPT-4o | 68.9 | 69.9 | +1.0 |\n| Gemini Flash 2 | 57.8 | 63.8 | +6.0 |\n| olmOCR | 74.7 | 75.5 | +0.8 |\n\nolmOCR自身にとって、アンカリングで増えたのは0.8点だけで、信頼区間の幅と同程度です。本当の進歩は主に、アンカリングで作った学習データから来ています。同じQwen2-VLのベースモデルは、ファインチューニングなしでは31.5点しかありません。\n\nまた、olmOCRは「古いスキャン」の列で42.2しかなく、表も71.0前後です。埋め込みテキストのないスキャン画像は、依然として難所です。\n\n### 言語モデルの学習に使う\n\n著者らは、このテキストが言語モデルの役に立つかも測りました。OLMo-2-7Bの途中のチェックポイントを取り、それぞれ500億トークンで事前学習を続けます。一方は、GROBIDとルールで抽出した従来のpeS2o学術論文。もう一方は、同じPDF群をolmOCRで処理し直したものです。\n\nMMLU、ARC、DROP、HellaSwagなど6つのタスクで、平均は53.9から55.2へ、1.3ポイント上がりました。\n\n### コスト\n\n| システム | 百万ページあたりのコスト（米ドル） |\n| --- | ---: |\n| GPT-4o（バッチ） | 6,240 |\n| Marker（H100） | 1,484 |\n| Mistral OCR API | 1,000 |\n| MinerU（L40S） | 596 |\n| Gemini Flash 2（バッチ） | 249 |\n| olmOCR（L40S） | 176 |\n\n*表：原論文Table 6から抜粋。L40Sは1時間0.79米ドル、H100は1時間2.69米ドルで見積もり、olmOCRは12%の再試行率を含みます。*\n\n要旨にある「100万ページでわずか176米ドル」は、L40Sで自前の推論を回した場合の見積もりです。\n\n### コミュニティの反応\n\nolmOCRは、2025年2月28日にHacker Newsに登場しました。スレッドでは、生成型OCRの昔からの問題であるハルシネーションと結果の不安定さを、はっきり指摘する人がいました。Markerを開発しているユーザーのvikpは、自分たちのテストセットではolmOCRに読み落としやハルシネーションがかなり見られたと返信しています。また、論文がMarkerのAPI価格とolmOCRの自前推論のコストを比べているのは、条件が対等でないと疑問を呈しました。[Hacker News、2025-02-28](https://news.ycombinator.com/item?id=43174298)\n\nvikpは競合製品の開発者なので、その立場も考慮に入れる必要があります。ただ、彼が指摘したコスト比較の条件は、確かにTable 6で確認できます。Markerの行はH100での強制OCRモード、olmOCRの行はL40Sです。\n\n### この論文を読むときの注意点\n\n1. **学習データはGPT-4o由来**。olmOCRが学んでいるのは、アンカリングのプロンプトを与えたGPT-4oの出力です。教師の誤りも一緒に学んでいる可能性があります。著者らは付録で、生徒と教師の一致度を別に測っています。\n2. **ベンチマークは自作**。olmOCR-Benchの設計は大いに参考になりますが、最初の比較結果は著者ら自身によるものです。\n3. **アンカリングはPDFの品質に依存する**。デジタルで作られたPDFで最も効果が高く、純粋なスキャン画像には使える埋め込みテキストがありません。\n\n## 結論\n\nolmOCRの核心は、とても素朴な発想です。**PDFの中にもう文字があるなら、それをモデルに見せればいい**。\n\n1. **Document anchoring**は、PDFに埋め込まれたテキストと座標をプロンプトに入れ、VLMにそのまま写せる文字を与えます。\n2. **アンカリングでデータを作り、小型モデルをファインチューニングする**：26万ページ分のGPT-4oによるアノテーションと7BのQwen2-VLで、総合スコアはGPT-4o自身を上回りました。\n3. **olmOCR-Benchは、類似度の代わりにユニットテストを使う**：繰り返し、読み落とし、読み順を、自動で判定できる問題として書き出しています。\n\n生成型OCRの最大のリスクは、よく見えないときに自分で文字を補ってしまうことです。olmOCRの答えの一つは、こうです。まず、推測しなくて済む文字がないか探してみる。\n","imageSizes":{"/content/papers/assets/044c3df431d57e98d00da32fff3b3df21f0cad1cb9a2e9176487efa55b628c17.png":{"width":994,"height":622},"/content/papers/assets/970cd043bba14de362481d37c8428e947780e9ec1c949f7846a8be7c4f58fbbf.png":{"width":1394,"height":527}}}