従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想

従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想

ドキュメントのデジタル化においてOCR（光学文字認識）は長年不可欠な技術でした。しかし従来のOCRは「テキストを読み取る」ことだけに最適化されており、文書中に含まれるチャートや図表、UIレイアウトといったグラフィカルな要素はピクセル単位のラスター画像として切り出すしかありませんでした。dots.mocrはこの根本的な限界に対して、テキストとグラフィクスを同一のモデルで統合的に解析するマルチモーダルOCR（MOCR）という新しいパラダイムを提示しています。2026年3月に公開されたこのオープンソースモデルは、わずか3Bパラメータでありながら主要ベンチマークでオープンソース最高水準を記録し、ドキュメント解析の実務に大きなインパクトを与えつつある存在です。

テキスト認識だけでは不十分だった従来OCRの3つの構造的弱点

従来型のOCRシステムには、実務で文書を扱ううえで見過ごせない3つの構造的な弱点がありました。第一に、グラフィクス要素の切り捨てです。テキスト以外の視覚的要素、たとえば棒グラフ・円グラフ・フローチャート・化学構造式などは認識対象外とされ、ラスター画像としてトリミングされるだけでした。これでは文書全体の意味構造を把握できません。

第二に、レイアウト情報と意味関係の分断が挙げられます。多段組みのページやヘッダー・フッターが入り組んだ文書では、テキストの読み順が崩れやすく、抽出結果の信頼性が大きく損なわれるケースが頻発していました。第三の弱点は、出力形式の再利用性の低さです。従来のOCRが出力するプレーンテキストやラスター画像は後続の機械処理に再利用しにくく、人手による修正コストが発生し続けるという課題を抱えていました。dots.mocrはこの3つの弱点すべてに対して、統合型マルチモーダル解析というアプローチで回答を示しています。

小紅書AI研究所が2026年3月に公開したdots.mocrの開発背景

dots.mocrを開発・公開したのは、中国の大手SNSプラットフォーム「小紅書（REDnote）」のAI研究部門であるrednote-hilabです。同チームは2025年7月にdots.ocrという1.7Bパラメータの多言語ドキュメント解析モデルをリリースしており、すでにオープンソースOCR分野で高い評価を得ていました。その約8か月後の2026年3月19日、テキスト認識にグラフィクス解析を統合した次世代モデルとしてdots.mocrが発表された経緯です。

rednote-hilabはOCRモデルだけでなく、大規模言語モデルのdots.llm1（142Bパラメータ、14Bアクティブ）やビジョン言語モデルのdots.vlm1なども開発しており、総合的なAIモデルファミリーを構築しています。dots.mocrはその中で「ドキュメント理解」に特化した位置づけにあり、小紅書が保有する大量のユーザー投稿コンテンツの解析基盤としても活用が想定されるモデルでしょう。GitHubとHugging Faceの双方で公開され、論文もarXivで参照可能です。

グラフィクスをSVGコードとして出力するMOCRパラダイムの定義

dots.mocrが提唱するMOCR（Multimodal OCR）パラダイムの最大の特徴は、文書内のグラフィカル要素をラスター画像としてではなく、構造化されたSVGコードとして出力する点にあります。棒グラフや折れ線グラフ、UIレイアウト、科学図版、化学式などを編集可能なベクター表現に変換できるため、後続処理での再利用性は飛躍的に高まるでしょう。

従来のOCRでは、チャート内の数値を読み取りたい場合にも画像から人手で情報を拾う必要がありました。MOCRパラダイムでは、モデルがチャートの構造そのものを理解したうえでSVGコードを生成するため、要素の位置関係やデータの意味までプログラム的にアクセスできる仕組みです。この考え方は論文中で「視覚的シンボルを一級市民（first-class parsing targets）として扱う」と表現されており、テキストとグラフィクスの間にある意味的関係をモデルが活用できる点が技術的な新規性といえます。

dots.ocrからdots.mocrへリブランドされた経緯と機能的な差分

dots.mocrは完全な新規モデルではなく、前身のdots.ocr-1.5をリブランドしたものです。2025年7月にリリースされたdots.ocrは1.7BパラメータのLLMを基盤とした多言語文書解析モデルで、同規模モデルの中ではSOTA（最先端）の成績を残していました。その後2025年10月にはdots.ocr.baseというOCRタスク特化の基盤VLMも公開されています。

dots.mocrへのリブランドに伴い、モデルパラメータは3Bに拡大され、グラフィクス解析機能が本格的に統合されました。olmOCR-Benchにおけるスコアもdots.ocrの79.1点からdots.mocrの83.9点へと4.8ポイント向上した結果です。さらにSVG変換に特化したdots.mocr-svgという派生モデルも同時リリースされており、用途に応じた使い分けが可能になりました。名称変更は単なるブランディングではなく、テキスト中心のOCRからマルチモーダルOCRへの技術的転換を反映した意味のあるリブランドでしょう。

MITライセンスと追加利用規約の二重構造で定められた公開条件の実務的意義

dots.mocrのソースコードはMITライセンスの下で公開されており、基本的に商用利用・改変・再配布が認められています。ただしリポジトリには「dots.mocr LICENSE AGREEMENT」という追加の利用規約が同梱されており、MITライセンスを補完する形で追加条件が定められている点に注意が必要です。具体的には、違法コンテンツの識別利用やプライバシー侵害目的での使用、著作権で保護された出版物の無断一括デジタル化などが禁止用途として明記されています。

さらに、派生モデルを配布する場合は「Built with dots.mocr」の帰属表示が求められ、準拠法は中華人民共和国法、紛争解決は杭州仲裁委員会と定められています。競合モデルのPaddleOCR-VLはApache 2.0ライセンス、olmOCR-2もオープンソース公開と、2025年以降のOCR領域ではオープン化の流れが加速中です。一方でMistral OCRはAPIベースの有料サービスとして提供されており、1000ページあたり約1ドルの課金が発生する仕組みとなっています。dots.mocrのセルフホスト運用は大量文書処理においてコスト面で大きな優位性を持ちますが、導入前に追加利用規約の禁止条項を確認しておくことが不可欠でしょう。

テキストもグラフィクスも統合解析する3Bパラメータモデルの技術基盤

dots.mocrの技術的な核心は、3Bという比較的コンパクトなパラメータ数でありながら、テキスト認識とグラフィクス解析の両方を高精度にこなせるアーキテクチャ設計にあります。高解像度対応のビジョンエンコーダと自己回帰型の言語モデルデコーダを組み合わせた構成に加え、PDF・Webページ・SVGアセットという3種類のデータソースを活用した段階的学習が性能の鍵です。ここでは、モデルの内部構造と学習プロセスを具体的に見ていきましょう。

高解像度ビジョンエンコーダと自己回帰型デコーダによる2段アーキテクチャ

dots.mocrのアーキテクチャは、大きく分けてビジョンエンコーダとランゲージモデルデコーダの2段構成で設計されています。ビジョンエンコーダは高解像度の入力画像を受け取り、文書のレイアウトやグラフィカル要素の空間情報を保持したまま特徴量へ変換する役割を担います。この段階で文字の位置だけでなく、チャートの軸構造やUI要素の配置関係も視覚的にエンコードされるのが特徴です。

デコーダ部分は自己回帰型の言語モデルで構成されており、エンコーダが出力した視覚特徴量をもとに、テキストやSVGコードを逐次的に生成する仕組みとなっています。この2段構成によって、モデルは「何がどこに書いてあるか」（グラウンディング）と「それをどう表現するか」（認識・生成）を一貫して処理可能です。汎用的なビジョン言語タスクにおいてもQwen3-VL-4Bと同等の性能を保持しており、OCR特化でありながら汎用性も犠牲にしていないバランスの良い設計といえるでしょう。

PDF・Webページ・SVGアセットの3種データで段階学習する仕組み

dots.mocrの学習パイプラインは、3種類の異なるデータソースを段階的に活用する点が大きな特徴です。第一のデータソースはPDF文書で、dots.ocrを自動ラベリングエンジンとして使用し、レイアウト領域と読み順を含む構造化されたページ転写データを生成する方式を採用しています。言語・ドメイン・レイアウト複雑度に基づく層別サンプリングを行い、特に困難な文書に重点を置いた学習設計です。

第二のデータソースはWebページで、クローリングしたページをレンダリングしたうえで、HTML/DOMから得られる構造情報をMOCR形式に変換しています。PDFだけでは得にくい高解像度で複雑なレイアウトパターンを補完する役割を果たしています。第三のデータソースはネイティブSVGアセットで、グラフィクスのコードレベルでの教師信号を提供するものです。この3種のデータを組み合わせた段階的事前学習と教師あり微調整によって、テキストとグラフィクスの両面で高い精度が実現されました。

チャートやUI画面をSVGコードへ変換するグラフィクス解析の原理

dots.mocrが他のOCRモデルと最も差別化されるのは、チャート・UIレイアウト・科学図版・化学式などのグラフィカル要素を直接SVGコードに変換できる能力です。従来のモデルがこうした要素をピクセルの集合として切り出すのに対し、dots.mocrは幾何学的構造と意味的グルーピングを理解したうえで、編集可能かつスケーラブルなベクター表現を生成する仕組みとなっています。

グラフィクス解析の評価にはUniSVGのISVGENメトリクスが使用されており、モデルが出力したSVGを実際にレンダリングし、元画像との視覚的一致度を定量化する方式です。dots.mocrは複数の画像→SVGベンチマークにおいてGemini 3 Proよりも高い再構成品質を達成しました。ただし3Bパラメータという制約から、特に複雑なSVG変換タスクでは限界もあり、SVG変換に最適化された派生モデルdots.mocr-svgが同時公開されています。用途に応じた使い分けがポイントになるでしょう。

Qwen3-VL-4Bと同等の汎用視覚タスク性能を維持できる理由

OCR特化モデルでありながら、dots.mocrは汎用的なビジョン言語タスクにおいてもQwen3-VL-4Bと比較可能な性能を保持しています。具体的にはCharXivの記述的評価で77.4点、推論評価で55.3点、InfoVQAで73.76点、DocVQAで91.85点、ChartQAで83.2点、OCRBenchで86.0点、AI2Dで82.16点といった数値が報告されました。

この汎用性が維持できる理由は、MOCRの学習パラダイム自体がマルチモーダルな理解を前提としている点にあるでしょう。テキストとグラフィクスを統合的に処理する学習過程で、モデルは視覚的コンテンツの意味理解能力を自然に獲得していきます。文書のコンテキストに応じた応答生成やインタラクティブな対話もサポートしており、単なるOCRエンジンにとどまらない柔軟な活用が可能です。これは文書理解タスクだけでなく、チャートの質問応答やUI画面の解釈といった周辺タスクにも応用できる実用的な強みといえます。

レイアウト検出から読み順保持まで11カテゴリを識別する分類精度

dots.mocrは文書のレイアウト解析において、11種類の要素カテゴリを識別可能です。具体的にはCaption（キャプション）、Footnote（脚注）、Formula（数式）、List-item（リスト項目）、Page-footer（ページフッター）、Page-header（ページヘッダー）、Picture（画像）、Section-header（セクション見出し）、Table（表）、Text（本文）、Title（タイトル）の11種となっています。

各要素にはバウンディングボックス（bbox座標）が付与され、要素間の読み順（リーディングオーダー）も保持される設計です。出力はJSON形式で構造化されるため、後続のパイプライン処理に直接組み込めるでしょう。多段組みのページや、ヘッダー・フッターが混在する複雑なレイアウトでも自然な読み順を維持できる点は、実務的に非常に重要な特性です。この分類精度がolmOCR-BenchのMulti-column（多段組み）カテゴリで高スコアを獲得している背景の一つとなっています。

olmOCR-Bench 83.9点を記録したdots.mocrのベンチマーク実績

dots.mocrの性能を客観的に評価するうえで最も重要な指標となるのが、主要ベンチマークにおけるスコアです。olmOCR-Benchでは83.9点というオープンソースモデル最高水準を達成し、OCR ArenaのEloランキングでも安定した上位評価を獲得しました。ここでは各ベンチマークの測定方法とdots.mocrのスコアを詳しく確認し、どのような文書タイプに強みを持つのかを具体的に見ていきましょう。

1403件のPDFと7010件のテストケースで測るolmOCR-Benchの評価基準

olmOCR-BenchはAllen AIが開発したOCR評価ベンチマークで、1403件のPDFファイルと7010件以上のユニットテストケースで構成されています。評価対象は主要カテゴリに分かれており、ArXiv論文の数式認識、古いスキャン文書の数学記号、表組みの構造保持、古いスキャン文書全般、ヘッダー・フッターの除去、多段組みレイアウトの読み順、長文の微小テキスト認識、基本テキスト認識の各カテゴリでテストが実施される仕組みです。

従来のOCR評価で使われていた文字誤り率（CER）や単語誤り率（WER）ではなく、バイナリ形式のユニットテストを採用している点がolmOCR-Benchの特徴でしょう。「この文字列が出力に含まれるか」「表のセルが正しい位置に配置されているか」「数式がLaTeX形式で正確に再現されているか」といった決定論的な検証を行います。この方式により、部分的な一致ではなく実務上の正確性を厳密に測定できる設計となっています。

オープンソースモデル初の83.9点達成とGemini 3 Proとの差

dots.mocrはolmOCR-Benchにおいて83.9±0.9点を記録し、オープンソースOCRモデルとして新たなSOTA（最先端スコア）を達成しました。この数値は、同時期に評価された他のオープンソースモデルを明確に上回っています。たとえばLightOnOCR-2-1Bが83.2点、Chandra（9Bパラメータ）が83.1点、olmOCR-2-7Bが82.4点、前身のdots.ocrが79.1点という状況の中での最高スコアです。

一方、OCR Arena Eloランキングでは、Gemini 3 Proが全3ベンチマーク（olmOCR-Bench・OmniDocBench v1.5・XDocParse）で1位を維持しており、dots.mocrは2位に位置しています。Gemini 3 Proはクローズドソースの商用APIであり、モデルサイズも公開されていないため単純な比較は困難でしょう。ただしオープンソースモデルの中では現時点で最もGemini 3 Proに迫るポジションにあることは間違いありません。

OCR Arena Eloランキングで全3ベンチマーク2位を獲得した安定性

dots.mocrの評価は単一ベンチマークだけにとどまりません。OCR Arenaで採用されているEloスコア評価では、olmOCR-Bench・OmniDocBench v1.5・XDocParseの全3ベンチマークにおいて、オープンソースモデルの中で最高位を獲得しました。Eloスコア方式では、高性能なビジョン言語モデル（Gemini 3 Flash）が審判役となり、2つのOCR出力をペアで比較して品質を判定する仕組みです。

このElo方式の利点は、従来の厳密一致メトリクスでは捉えきれない「忠実度」「構造保持」「フォーマット品質」を総合的に評価できる点にあるでしょう。dots.mocrが3つの異なるベンチマークすべてで安定的に高評価を得ているということは、特定のテストセットに過学習しているわけではなく、多様な文書タイプに対して汎用的に高い解析品質を発揮できることを示しています。この安定性は実務導入時の信頼性を判断するうえで重要な材料となるはずです。

数式90.7点・表組み94.0点などカテゴリ別スコアに見る得意と苦手

olmOCR-Benchのカテゴリ別スコアを見ると、dots.mocrの得意領域が明確に浮かび上がります。論文中で報告されている内訳は、ArXiv数式が85.9点、古いスキャン数学が85.5点、表組みが90.7点、古いスキャン全般が48.2点、ヘッダー・フッター除去が94.0点、多段組みが85.3点、長文微小テキストが81.6点、基本テキストが99.7点という結果です。

特に表組み（90.7点）とヘッダー・フッター除去（94.0点）、基本テキスト（99.7点）が突出しており、構造化された文書要素の認識に強みがあることがわかるでしょう。一方で古いスキャン全般（48.2点）は比較的低く、劣化した画像からの認識には課題が残ります。この傾向は、dots.mocrがデジタルPDFやWebレンダリングを主な学習データとしていることと整合的であり、スキャン品質が低い歴史的文書の処理には別途前処理や補完が必要になるケースも想定すべきです。

前身dots.ocrの79.1点から4.8点向上した改善ポイントの内訳

dots.mocrの83.9点という数値は、前身のdots.ocrが記録した79.1点からの4.8ポイント向上を意味しており、同規模モデルのバージョンアップとしてはかなり大きい改善幅です。改善の主な要因は、MOCRパラダイムの導入によるマルチモーダル学習の効果と、モデルパラメータの拡大（1.7B→3B）、そして学習データの拡充にあるでしょう。

特に数式を多く含むページでの改善が顕著で、論文中ではMOCRのマルチモーダル学習アプローチが複雑なコンテンツの処理に効果的であったと報告されています。グラフィクスのコードレベル教師信号を学習に組み込むことで、テキストと視覚的要素の間の意味的関係をモデルが捉えやすくなり、結果としてテキスト認識の精度も副次的に向上したと考えられます。dots.ocrからdots.mocrへの移行は、単なるスケールアップではなく学習パラダイムの転換による質的な進化といえるでしょう。

PaddleOCR-VLやMistral OCRとの精度・コスト・対応範囲の違い

dots.mocrを実務に導入する際、避けて通れないのが競合モデルとの比較でしょう。2025年から2026年にかけてオープンソースOCR領域は爆発的な成長を遂げており、PaddleOCR-VL、Mistral OCR、olmOCR-2、DeepSeek-OCR、Chandraなど有力な選択肢が多数存在します。ここでは精度・処理速度・コスト・対応言語・固有の強みという5つの軸で主要モデルを比較し、dots.mocrが最適な場面とそうでない場面を整理していきましょう。

パラメータ数0.9B〜9Bの主要5モデルとの精度・速度一覧比較

2026年4月時点で比較対象となる主要オープンソースOCRモデルを、パラメータ数・olmOCR-Benchスコア・処理速度の3軸で一覧にまとめました。処理速度は二次情報源による推計値であり、ハードウェア構成や文書特性によって変動する点に留意してください。

dots.mocrは3Bパラメータという中間的なサイズでありながら最高スコアを記録しており、精度とリソース効率のバランスが優れた選択肢です。9BのChandraと比較しても0.8ポイント上回っている点は注目に値するでしょう。処理速度はPaddleOCR-VLと同程度の約2ページ/秒で、DeepSeek-OCRほどの高速処理はできないものの、実用上は十分な水準です。

セルフホスト運用時の1000ページあたり処理コストと商用APIとの差

OCRモデルの選定において、精度と並んで重要なのが処理コストでしょう。商用APIのMistral OCRは1000ページあたり約1ドル、GPT系のモデルを使う場合は1000ページあたり約15ドルのコストが発生します。Azure Document IntelligenceやAWS Textractなどのクラウドサービスでは、100万ページあたり1500ドル〜5万ドルという価格帯が一般的な水準です。

一方、dots.mocrをGPU環境でセルフホスト運用した場合、PaddleOCR-VLの事例を参考にすると1000ページあたり約0.09ドル（コンシューマーGPU使用時）という水準での処理が見込めます。これは商用APIと比較して100倍以上のコスト差になるでしょう。ただしセルフホストにはGPUインフラの初期投資と運用コストが必要であり、処理量が少ない場合はAPI利用のほうが合理的なケースもあります。月間100万ページ以上の処理を行う組織であれば、セルフホスト運用のコストメリットが特に顕著です。

80以上の言語に対応するPaddleOCR-VLに対する多言語サポート範囲の違い

多言語対応はOCRモデル選定の重要な判断基準の一つです。PaddleOCR-VLはBaiduが開発したモデルで、PaddleOCRエコシステム全体としては80以上の言語に対応する業界有数のカバー範囲を誇ります。キリル文字、アラビア文字、デーヴァナーガリー文字、タイ文字など、多くのOCRシステムが苦手とするスクリプトにも対応しており、グローバル展開する企業にとって強力な選択肢でしょう。

dots.mocrも多言語対応を掲げていますが、PaddleOCR-VLほどの明確な言語数は公式には公表されていません。前身のdots.ocrの時点で「ほぼあらゆる人間のスクリプトを認識できる」と説明されており、dots.mocrでもこの多言語能力は継承されています。ただし、特定言語での精度を公式ベンチマークで個別に検証した結果は限定的です。日本語・中国語・英語など主要言語での利用であればdots.mocrで問題ない一方、少数言語やマイナーなスクリプトへの対応を重視する場合はPaddleOCR-VLが安全な選択となるでしょう。

画像→SVG変換でGemini 3 Proを上回るグラフィクス解析の独自優位性

dots.mocrの最も明確な差別化ポイントは、画像からSVGコードへの変換能力です。複数の画像→SVGベンチマークにおいて、クローズドソースのGemini 3 Proよりも高い再構成品質を達成しました。チャート、UIレイアウト、科学図版、化学構造式といった多様なグラフィカル要素でこの優位性が確認されており、グラフィクス解析はdots.mocrの独自領域といえるでしょう。

PaddleOCR-VLやolmOCR-2といった競合モデルは主にテキスト認識とレイアウト解析に特化しており、グラフィカル要素をSVGコードとして出力する機能は備えていません。この機能差は、たとえば技術文書に含まれるチャートをそのまま編集可能な形式で抽出したい場合や、UIスクリーンショットからデザイン要素を再利用したい場合に決定的な違いとなります。テキスト認識だけが目的であれば他のモデルも十分な性能を持ちますが、グラフィクスの構造的再利用まで視野に入れるならdots.mocrが現時点で最有力です。

用途別に見るdots.mocr・PaddleOCR-VL・olmOCR-2の最適な選び方

3つの主要モデルにはそれぞれ最適な活用場面があり、一律に「どれが最良か」とは言い切れません。dots.mocrが最も力を発揮するのは、テキストとグラフィクスの両方を含む技術文書や学術論文を構造的に解析したい場合でしょう。チャートや図表をSVGとして取り出せる唯一のオープンソースモデルであるため、文書の完全な再構成が求められるワークフローに適しています。

PaddleOCR-VLは0.9Bパラメータと軽量でありながら80以上の言語に対応しており、多言語の請求書処理や帳票OCRなど、大量かつ多様な言語の文書を低コストで処理するシナリオに最適です。olmOCR-2は7Bパラメータと大きめですが、Allen AIが提供する充実したパイプラインツールとファインチューニング環境が魅力で、自社文書に特化したカスタムOCRを構築したいチームに向いています。導入前に処理対象の文書タイプを棚卸しし、テキスト中心かグラフィクス中心かで判断するのが合理的な選び方でしょう。

vLLMとTransformersで始めるdots.mocrの環境構築と導入手順

dots.mocrを実際に動かすには、Python環境の構築からモデルのダウンロード、推論エンジンの選択まで、いくつかのステップを踏む必要があります。推奨されるデプロイ方法はvLLMを使用したサーバー構成ですが、Transformersライブラリを使ったローカル推論も選択肢の一つです。ここでは公式ドキュメントに基づいた環境構築の具体的な手順と、導入時につまずきやすいポイントへの対処法を解説していきましょう。

Python 3.12とCUDA対応GPUを前提としたconda環境の構築手順

dots.mocrの動作にはPython 3.12以上とCUDA対応のGPUが必要です。公式リポジトリではcondaによる仮想環境の構築が推奨されており、以下の手順でセットアップを行います。

1. condaで新規環境を作成しましょう。conda create -n dots_mocr python=3.12を実行し、環境をアクティベートしてください
2. GitHubからリポジトリをクローンします。git clone https://github.com/rednote-hilab/dots.mocr.gitを実行し、ディレクトリに移動してください
3. 使用しているCUDAバージョンに合わせたPyTorchをインストールしましょう。CUDA 12.8対応の場合はpip install torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu128を実行します
4. 推論速度の向上のためflash-attn==2.8.0.post2のインストールが推奨されています
5. 最後にpip install -e .を実行すれば基本的な環境構築は完了です

PyTorchのバージョンはCUDA環境に依存するため、公式サイトで自分のCUDAバージョンを確認してからインストールコマンドを選択してください。flash-attnのインストールに失敗する場合は、後述するvLLMでの推論を選択することで回避可能です。

vLLM v0.11.0以降の公式統合を利用した推奨デプロイ方法

dots.mocrの公式ドキュメントでは、推論とデプロイにvLLMの使用が強く推奨されています。vLLMバージョン0.11.0以降でdots.mocrが公式に統合されており、動作検証済みの環境として利用可能です。vLLM v0.17.1以降のDockerイメージ（vllm/vllm-openai）をそのまま活用できるのも利点でしょう。

vLLMサーバーの起動コマンドはCUDA_VISIBLE_DEVICES=0 vllm serve rednote-hilab/dots.mocr --tensor-parallel-size 1 --gpu-memory-utilization 0.9 --chat-template-content-format string --trust-remote-codeです。このコマンド1つでAPIサーバーが立ち上がり、OpenAI互換のAPIエンドポイント経由でリクエストを送信できるようになります。GPUメモリの利用率は0.9（90%）がデフォルト設定ですが、他のプロセスとGPUを共有する場合は値を下げて調整してください。dots.mocr-svgを使う場合はモデル名をrednote-hilab/dots.mocr-svgに変更するだけで同様にデプロイ可能です。

Transformersで動かす場合のuse_hf設定と速度低下の注意点

vLLM環境を用意できない場合は、Hugging FaceのTransformersライブラリを使ったローカル推論も選択肢になるでしょう。parser.pyの実行時に--use_hf trueオプションを付与するか、PythonコードでDotsMOCRParserのインスタンス生成時にuse_hf=Trueを指定する方式です。Transformersベースの推論ではAutoModelForCausalLMとAutoProcessorを使用し、flash_attention_2のアテンション実装とbfloat16の精度設定が推奨されています。

ただし公式ドキュメントでも明記されているとおり、Transformersによる推論はvLLMと比較して処理速度が大幅に低下します。大量のPDFを処理するバッチ処理ではvLLMが圧倒的に有利であり、Transformersは少量ファイルの動作確認やプロトタイピング段階での使用に限定するのが実用的でしょう。推論コードの詳細はリポジトリ内のdots_mocr/model/inference.pyとdots_mocr/utils/prompts.pyに記載されており、パラメータやプロンプト設定のベストプラクティスを確認できます。

モデル保存パスのディレクトリ名にピリオドを使えない既知制約と回避策

dots.mocrの導入時に見落としやすい既知の制約として、モデル保存パスにピリオド（.）を含むディレクトリ名を使用できない問題が挙げられます。たとえばモデルを./weights/dots.mocr/に保存しようとするとエラーが発生するでしょう。これはTransformersとの統合に関する一時的なワークアラウンドとして公式に告知されている制約です。

対処法はシンプルで、モデル保存ディレクトリの名前からピリオドを除去するだけです。公式リポジトリでは./weights/DotsMOCR/のようにキャメルケースのディレクトリ名を使用する例が示されています。モデルのダウンロードはpython3 tools/download_model.pyで実行でき、中国国内からアクセスする場合はModelScopeからのダウンロードオプション（--type modelscope）も用意されている状況です。この制約は今後のTransformers統合の進展に伴い解消される見込みですが、現時点では手動での対応が必要となっています。

Dockerイメージを使った依存関係トラブルの回避とGPUメモリ設定

dots.mocrの環境構築でつまずきやすいのが、PyTorchやflash-attnなどの依存関係の解決でしょう。CUDAバージョンの不一致やコンパイルエラーが発生する場合は、公式が提供するDockerイメージの利用が最も確実な回避策です。vLLMの公式Dockerイメージ（vllm/vllm-openai:v0.17.1-cu130など）には必要な依存関係がすべてプリインストールされています。

GPUメモリについては、3Bパラメータモデルであるdots.mocrは比較的少ないVRAMで動作可能です。bfloat16精度であれば約6〜8GBのVRAMが目安となり、NVIDIA RTX 3060（12GB）以上のGPUであれば動作が見込めるでしょう。ただし高解像度の大型PDFを処理する場合や、バッチサイズを増やしたい場合にはより多くのVRAMが必要になります。vLLMの--gpu-memory-utilizationパラメータで使用率を0.5〜0.95の範囲で調整でき、環境に応じたチューニングが可能です。メモリ不足エラーが発生する場合は、まずこの値を下げて試してみてください。

PDF解析からSVG変換まで実務で使うdots.mocrの具体的活用例

環境構築が完了したら、実際にdots.mocrを使って文書を解析してみましょう。dots.mocrはPDF解析・画像OCR・レイアウト検出・SVG変換といった多様なタスクに対応しており、コマンドラインから手軽に実行できる設計です。ここではparser.pyを使った基本操作から、vLLM API経由のバッチ処理、出力データの活用方法まで、実務で使える具体的なワークフローを紹介します。

1コマンドでPDFをMarkdownとJSONに変換するparser.pyの基本操作

dots.mocrの最も基本的な使い方は、parser.pyを使った単一ファイルの解析です。画像ファイルの場合はpython3 dots_mocr/parser.py demo/demo_image1.jpg、PDFファイルの場合はpython3 dots_mocr/parser.py demo/demo_pdf1.pdf --num_thread 64のように実行します。PDFはページ数に応じてnum_threadの値を大きくすることで処理速度を向上させられるでしょう。

解析結果は2種類のファイルとして出力される仕組みです。1つ目はJSON形式の構造化レイアウトデータで、検出された各要素のバウンディングボックス座標、カテゴリ分類（Table・Text・Formulaなど11種）、および抽出テキストが含まれます。2つ目はMarkdown形式の変換ファイルで、レイアウト構造を反映した読みやすいテキストデータが得られるでしょう。この2つの出力を組み合わせることで、構造情報を活用したプログラム的な処理と人間向けのテキスト出力の両方をカバーできます。

レイアウト検出のみ・テキスト抽出のみを切り替えるプロンプト指定

dots.mocrはプロンプト指定によって解析モードを柔軟に切り替えることが可能です。デフォルトではレイアウト検出とテキスト認識の両方を実行しますが、用途に応じて一方のみを実行するオプションも用意されています。レイアウト検出のみを行う場合はpython3 dots_mocr/parser.py demo/demo_image1.jpg --prompt prompt_layout_only_enのように指定しましょう。

テキスト抽出のみを行いたい場合は--prompt prompt_ocrを指定する方式です。このモードではPage-headerとPage-footerを除外したテキスト抽出が行われるため、ヘッダー・フッターのノイズを排除した本文テキストだけが必要な場面で便利でしょう。プロンプトの詳細な設定はdots_mocr/utils/prompts.pyに定義されており、カスタムプロンプトを作成して独自の解析モードを実装することも技術的には可能です。処理速度を優先したい場合は、不要な解析を省略することで処理時間を短縮できます。

dots.mocr-svgを併用して図表やアイコンをベクター化する実務手順

ドキュメント内のチャートや科学図版、ロゴなどをSVGコードとして抽出したい場合は、SVG変換に最適化されたdots.mocr-svgの使用が推奨されます。vLLMサーバーの起動時にモデル名をrednote-hilab/dots.mocr-svgに変更するだけで、SVG変換性能が強化された推論環境を構築可能です。

dots.mocr-svgは棒グラフ・折れ線グラフ・散布図・複合チャートといった統計図表から、UIレイアウト・化学構造式・科学イラストレーションまで幅広いグラフィカル要素に対応しています。出力されるSVGコードは構造的にグルーピングされており、そのまま編集ソフトで開いて修正を加えたり、Webページに埋め込んだりすることが可能でしょう。標準のdots.mocrでもSVG変換は行えますが、3Bパラメータの制約により複雑な図版では精度が不十分になる場合もあります。高品質なSVG出力が求められるプロジェクトではdots.mocr-svgの併用を検討してください。

vLLM APIサーバー経由でバッチ処理を実現する大量PDF変換の構成例

数百〜数千件のPDFを一括処理する実務シナリオでは、vLLM APIサーバーを使ったバッチ処理構成が効率的です。まずvLLMサーバーを起動しておき、OpenAI互換のAPIエンドポイントに対して複数のリクエストを並行送信する構成をとります。推論コードの実装例はdots_mocr/model/inference.pyに記載されているため確認してください。

大量処理時に押さえておくべきポイントは3つあります。第一に、GPUメモリの利用率を適切に設定することです。バッチ処理中にメモリ不足でサーバーが停止しないよう、--gpu-memory-utilizationを0.85程度にしてマージンを確保しましょう。第二に、PDFのページ数が多い場合は--num_threadを大きく設定して並列処理を活用することです。第三に、エラーハンドリングとリトライ機構を実装し、特定ページの処理失敗が全体に波及しないようにすることでしょう。複数GPUが利用可能な環境では--tensor-parallel-sizeを増やすことでさらなるスループット向上が見込めます。

出力JSONのbbox・カテゴリ・テキストを後続処理に活用する設計例

dots.mocrが出力するJSONデータには、文書内の各要素について豊富な構造情報が含まれています。各要素はバウンディングボックス座標（x1, y1, x2, y2）、カテゴリ分類（Caption・Table・Formulaなど11種）、および抽出テキストの3点セットで構成されており、この情報を後続の処理パイプラインに組み込むことで多様な活用が実現するでしょう。

たとえば、表（Table）カテゴリの要素だけをフィルタリングして抽出し、表内テキストをCSV形式に変換するパイプラインの構築が考えられます。数式（Formula）カテゴリの要素をLaTeX形式で蓄積し、数式データベースを構築する用途にも応用可能です。また、バウンディングボックス座標を利用して元のPDF上に解析結果をオーバーレイ表示するビジュアライゼーションツールの開発も有力な活用方法でしょう。出力JSONの構造が統一されているため、一度パイプラインを構築すればさまざまなドキュメントに対して再利用できる点が実務的な強みです。

3Bモデルゆえの制約と今後のアップデートで期待される機能拡張

dots.mocrは3Bパラメータモデルとしては突出した性能を示していますが、モデルサイズに起因する制約が存在しないわけではありません。導入を検討する際には、現時点での限界を正確に理解したうえで判断することが重要でしょう。ここではSVG変換精度の課題、スループットへの影響、スキャン文書での認識限界、そしてrednote AIエコシステムの今後の展望を整理していきます。

SVG変換精度に残る課題とdots.mocr-svgで補完が必要な場面

dots.mocrの公式論文でも率直に認められているとおり、3Bパラメータという容量制約のため、SVG変換タスクにおいてすべての場面で高精度を発揮できるわけではありません。特に複雑な科学イラストレーションや多層的なUIレイアウトなど、要素数が多く空間的関係が入り組んだ図版では、出力SVGの再現精度が低下する傾向が見られます。

この制約を補うために同時リリースされたのがdots.mocr-svgです。SVG解析タスクに特化したファインチューニングが施されており、標準版では対応しきれない複雑なグラフィクスでもより高品質な出力が期待できるでしょう。実務での運用としては、まず標準のdots.mocrで全体の文書解析を行い、SVG変換の品質が不十分な要素についてのみdots.mocr-svgで再処理するという2段階の構成が効率的です。今後のアップデートでこの制約が緩和される計画が公式に示されており、将来的には1モデルでの統合処理が実現する可能性もあります。

3Bパラメータモデルが日次数万ページの大規模処理に与えるスループットへの影響

3Bパラメータというモデルサイズは、精度とスループットのトレードオフにおいて中間的なポジションにあります。処理速度の目安は約2ページ/秒（H100 GPUの場合）で、DeepSeek-OCRの約4.65ページ/秒やLightOnOCRの約5.55ページ/秒と比較すると高速処理向きとはいえないでしょう。

日次で数千〜数万ページの処理が必要な大規模運用では、この処理速度がボトルネックになる可能性もあります。対策としては複数GPUによるtensor-parallel構成や、複数のvLLMサーバーインスタンスを立てたロードバランシング構成が考えられるでしょう。また、処理速度を最優先する場合はDeepSeek-OCRの6段階解像度モードのように速度と精度をトレードオフできるモデルを選択する方法もあります。dots.mocrの強みはスループットではなく精度とグラフィクス解析のユニークさにあるため、速度要件が厳しい場合は用途に応じたモデルの使い分けが合理的です。

手書き文字や劣化スキャン文書で認識精度が低下する具体的な条件と限界

olmOCR-Benchのカテゴリ別スコアで確認したとおり、dots.mocrは古いスキャン文書全般（48.2点）において他のカテゴリと比較して低いスコアを記録しました。この傾向は、学習データの主体がデジタルPDFとWebページレンダリングであることに起因すると考えられます。紙面の劣化、インクのかすれ、傾き補正が必要なスキャン画像は、dots.mocrの学習分布からやや外れたドメインでしょう。

手書き文字の認識についても、dots.mocrが特別に最適化されているわけではありません。手書き文書の処理が主な用途である場合は、olmOCR-2やChandraなど手書き文書を含む学習データで訓練されたモデルのほうが適している可能性があります。dots.mocrは印刷文書・デジタル文書・Webコンテンツを対象とした解析に最も強みを発揮するモデルであり、スキャン品質が低い歴史的文書や手書き文書の処理には前処理（画像強調・傾き補正）との組み合わせや、別モデルとの使い分けを検討すべきでしょう。

dots.llm1やdots.vlm1との連携で広がるAIエコシステムの展望

dots.mocrは単独のOCRモデルとしてだけでなく、rednote-hilabが構築するAIモデルファミリーの一部として理解する必要があるでしょう。同チームはdots.llm1（142Bパラメータ、14Bアクティブの大規模MoEモデル）、dots.vlm1（1.2Bビジョンエンコーダ＋DeepSeek V3ベースのVLM）、そしてdots.mocrという3系統のモデルを展開中です。

将来的にはこれらのモデルを組み合わせた統合パイプラインが構築される可能性があります。たとえばdots.mocrで文書の構造解析とテキスト抽出を行い、dots.vlm1でグラフィカル要素の意味理解と質問応答を処理し、dots.llm1で抽出データに基づく高度な推論や要約を行うといった多段構成です。rednote-hilabがGitHub上で複数リポジトリを積極的に公開・更新している点からも、エコシステムとしての発展は今後も続くと見込まれるでしょう。dots.mocrを導入する際は、将来のモデル連携も視野に入れたアーキテクチャ設計を意識しておくと拡張性の面で有利です。

自社の文書環境で導入前に確認すべき5つのチェックポイントと判断基準

ここまでの内容を踏まえ、dots.mocrの導入前に確認すべき5つのチェックポイントを整理しましょう。これらの条件を事前に評価することで、導入可否を合理的に判断できます。

• 処理対象の文書にグラフィカル要素（チャート・図表・UIなど）が含まれるか。テキストのみの文書であれば、より軽量なPaddleOCR-VLやDeepSeek-OCRで十分な場合がある
• 必要な処理速度と月間処理量はどの程度か。日次1万ページ以上の大規模処理では複数GPU構成の検討が必要になる
• 対象言語の範囲はどこまでか。日本語・中国語・英語が中心であればdots.mocrで問題ないが、マイナー言語への対応が必要ならPaddleOCR-VLが安全な選択となる
• スキャン文書の品質はどの程度か。古い劣化文書が多い場合はdots.mocrの弱点に該当するため、前処理の追加や別モデルの併用を計画に組み込むべきである
• CUDA対応GPUを含むインフラが確保できるか。GPUがない環境ではセルフホスト運用が難しいため、Mistral OCR APIなどの商用サービスを選択するのが現実的な判断となる

5つのチェックポイントすべてがdots.mocrの適用条件と合致している場合、olmOCR-Bench 83.9点の精度とグラフィクス→SVG変換という独自機能を活かした高品質なドキュメント解析パイプラインの構築が期待できるでしょう。逆に一つでも大きなミスマッチがある場合は、他のモデルとの併用や代替を検討することが建設的な判断です。