# GLM-OCR Technical Report > [!abstract] 概要(arXiv アブストラクトの日本語訳) > GLM-OCR は実世界の文書理解を目的として設計された、効率的な 0.9B パラメータのコンパクトなマルチモーダルモデルである。0.4B パラメータの CogViT ビジョンエンコーダと 0.5B パラメータの GLM 言語デコーダを組み合わせ、計算効率と認識性能の高いバランスを実現している。決定論的な OCR タスクにおける標準的な自己回帰デコードの非効率性に対処するため、GLM-OCR はマルチトークン予測(MTP)機構を導入し、1 ステップで複数トークンを予測することでデコードスループットを大幅に向上させつつ、パラメータ共有によってメモリオーバーヘッドを低く抑える。システムレベルでは 2 段階パイプラインを採用し、PP-DocLayout-V3 がまずレイアウト解析を行い、続いて並列リージョンレベル認識を行う。公開ベンチマークと産業シナリオでの広範な評価から、GLM-OCR は文書パース、テキスト・数式のトランスクリプション、表構造復元、キー情報抽出において競争力のある、あるいは最先端の性能を達成することが示された。コンパクトなアーキテクチャと構造化生成機能により、リソース制約のあるエッジ展開と大規模プロダクションシステムの両方に適している。 ## 論文情報 - **著者**: Shuaiqi Duan⋆, Yadong Xue⋆, Weihan Wang⋆, Zhe Su, Huan Liu, Sheng Yang, Guobing Gan, Guo Wang, Zihan Wang, Shengdong Yan, Dexin Jin, Yuxuan Zhang, Guohong Wen, Yanfeng Wang, Yutao Zhang, Xiaohan Zhang, Wenyi Hong, Yukuo Cen, Da Yin, Bin Chen, Wenmeng Yu†, Xiaotao Gu†, Jie Tang (⋆ 同等貢献, † プロジェクトリーダー) - **所属**: [[Zhipu AI]](著者 1 を除く全員), [[Tsinghua University]]([[Jie Tang]]) - **公開**: arXiv:2603.10910v2 (2026-03-16) - **分野**: cs.CL - **コード**: https://github.com/zai-org/GLM-OCR - **モデル**: https://huggingface.co/zai-org/GLM-OCR - **デモ**: https://ocr.z.ai/ ## 概要 GLM-OCR は [[Zhipu AI]] が開発した 0.9B パラメータの軽量マルチモーダル OCR モデルである。[[GLM]]ファミリー(GLM-V エンコーダ・デコーダフレームワーク)の一員として、実世界の文書理解を産業スケールで実現することを目標に設計された。大規模モデルに依存せず、モデルアーキテクチャ・デコード戦略・タスク構造の慎重な整合によって効率利得を実現することを設計原則とする。 GLM-OCR の祖先モデルである GLM ファミリーは [[Jie Tang]]([[Tsinghua University]]) が率いる GLM チームによって開発されており、GLM-130B から ChatGLM 系列、GLM-4、GLM-4.5V まで発展を続けている(参照: [[@2024__arXiv__ChatGLM - A Family of Large Language Models from GLM-130B to GLM-4 All Tools]])。 ## 問題設定 文書理解は金融レポート・科学論文・契約書・請求書などビジュアルリッチで複雑レイアウトな文書から知識を抽出・構造化する能力であり、現代情報システムの基盤的要求である。従来の OCR システムは平文トランスクリプションに焦点を当て、レイアウト解析と下流情報抽出にはハンドクラフトのルールを持つ多段パイプラインに依存していた。 近年のマルチモーダル大規模言語モデル(MLLM)は視覚認識と言語理解を単一フレームワークに統合し文書理解性能を大幅に向上させたが、モデルの大規模化と自己回帰デコードパラダイムにより計算コスト・推論遅延・メモリ消費が増大し、高並列または低リソース環境での大規模展開が困難になっている。 本論文が解決する具体的課題は次の 3 つである: 1. 複雑な表・数式・コード・印鑑などの複雑コンテンツでの高性能 2. 高スループット・低遅延の推論 3. 柔軟な統合とドメイン適応 ## 提案手法 ### アーキテクチャ GLM-OCR Core は GLM-V エンコーダ・デコーダフレームワークに基づく視覚言語生成パラダイムで構成される。 - **ビジョンエンコーダ(CogViT, 約 400M パラメータ)**: 大規模画像テキストデータで訓練され、文書画像からハイレベルな視覚表現を抽出する。 - **クロスモーダルコネクタ**: 視覚特徴を言語埋め込み空間に射影しデコーダへのプレフィックストークンとして供給する。 - **言語デコーダ(GLM, 約 500M パラメータ)**: 視覚埋め込みとテキストプロンプトを条件として構造化テキスト出力(Markdown / JSON)を自己回帰的に生成する。 MTP 機構として、主予測ヘッドに加えて k 個のパラメータ共有補助ヘッドを付与し、次の k トークンを同時に予測する。これらのヘッドは同一パラメータを共有しながら異なる未来オフセットをモデル化するよう訓練される。推論時には 1 ステップで複数トークンを生成でき、レイテンシを削減しつつローカル構造的一貫性を向上させる。実際には 10 トークン/ステップを予測するよう訓練され、推論時に平均 5.2 トークン/ステップを生成し、スループットが約 50% 向上する。 システムレベルでは 2 段階パイプラインを採用する: - **タスク 1(文書パース)**: PP-DocLayout-V3 がレイアウト解析を行い文書を意味的に一貫したリージョン(段落・表・数式)に分解する。各リージョンを GLM-OCR Core が独立処理し、Merge & Post Process モジュールが読み取り順序を復元して Markdown/JSON 出力を生成する。 - **タスク 2(キー情報抽出; KIE)**: 文書全体画像をタスク固有のテキストプロンプトとともに GLM-OCR Core に直接入力し、プロンプト誘導で関連リージョンに暗黙的に注意する。 両タスクを条件付き構造化生成問題として統一し、前処理戦略とプロンプト指定のみで差異化する設計は、パラメータ効率とクロスタスク知識転移を促進する。 ### 訓練レシピ 4 ステージの多段訓練で事前学習から強化学習へと段階的に進む: | ステージ | フェーズ | データ種別 | |---|---|---| | Stage 1 | ビジョンエンコーダ訓練 | 画像テキストペア・グラウンディング/検索データ | | Stage 2.1 | 事前学習 | 画像テキストペア・文書パース・グラウンディング・VQA | | Stage 2.2 | MTP 付き事前学習 | 文書パース・グラウンディング・VQA | | Stage 3 | MTP 付き SFT | テキスト/数式/表認識・KIE | | Stage 4 | 強化学習(RL) | テキスト/数式/表認識・KIE | **Stage 1** では大規模画像テキストおよびグラウンディングデータで MIM と CLIP の二重目的でビジョンエンコーダを訓練し、社内の大型 ViT から知識蒸留を行う。訓練データは数百億の画像テキストペアにスケールアップ。 **Stage 2** では GLM-0.5B をビジョンエンコーダに結合して全体を事前学習し、マルチモーダル表現をアライメント。Stage 2.2 で MTP 目的関数を導入し効率的な構造化生成に適応させる。 **Stage 3(SFT)** では実世界の文書分布下で高精度な構造化出力を専門化するために OCR データセット(テキスト認識・数式トランスクリプション・表構造復元・KIE)でファインチューニング。 **Stage 4(RL)** では GRPO を用いてタスク固有の精度と構造出力の信頼性を向上させる。タスク別の報酬関数を設計し: - テキスト認識: 正規化編集距離 + 繰り返しペナルティ - 数式認識: CDM スコア + 構造妥当性チェック - 表認識: TEDS スコア + タグ閉じ検証・構造パース - KIE: フィールドレベル F1 + JSON パース検証・欠落/重複フィールドペナルティ グローバル正則化として繰り返し比率ペナルティと不正形構造ペナルティも導入する。 ### データパイプライン Stage 1 では数百億の画像テキストペアおよびグラウンディング/検索データを使用。Stage 3 SFT ではテキスト・数式・表認識・KIE をカバーするキュレーション OCR データセットを使用し、単一サブタスクへの過適合を防ぐためデータ混合はバランスされる。 ## 新規性 - **OCR に特化した MTP 実装**: MTP は DeepSeek-V3 で提案されたが、GLM-OCR はパラメータ共有ドラフトヘッドにより GPU メモリオーバーヘッドを抑えながら、OCR タスクの局所依存性が高い特性(表タグや Markdown 構文)に MTP が特に有効であることを示した。 - **2 ステージパイプラインと MTP の統合**: レイアウト解析で複雑レイアウトをサブ問題に分解し並列処理を可能にする設計は、従来 MLLM が苦手とする幻覚と繰り返し生成を抑制する。 - **タスク統一型生成フレームワーク**: 文書パースと KIE をプロンプト制御のみで統一し、アーキテクチャ的な複雑さを増やさない設計。 - **0.9B での SOTA 性能**: 数百 B パラメータの汎用 VLM を小規模専門モデルが超えることを実証。 ## 実験設定 ### ベンチマーク **公開ベンチマーク(文書パース)**: - OmniDocBench v1.5: 多様な PDF 文書パースを総合評価する主要ベンチマーク - OCRBench (Text): 大規模マルチモーダルモデルの OCR 能力評価 - UniMERNet: 実世界数式認識 - PubTabNet: 科学論文の表構造復元 - TEDS_TEST: 表構造評価 **公開ベンチマーク(KIE)**: - Nanonets-KIE / Handwritten-Forms (IDP Leaderboard) **社内ベンチマーク**(実世界 6 シナリオ): - コード文書パース、実世界表抽出、手書きテキスト認識、多言語テキスト処理(中・英・仏・西・露・独・日・韓)、印鑑認識、レシート KIE ### ベースライン - **パイプラインツール**: Marker-1.8.2, MinerU2-pipeline, PP-StructureV3 - **汎用 VLM**: GPT-4o, InternVL3-76B, InternVL3.5-241B, GPT-5.2, Qwen2.5-VL-72B, Gemini-2.5 Pro, Qwen3-VL-235B, Gemini-3 Pro - **特化型 OCR VLM**: Dolphin, OCRFlux-3B, Mistral OCR, POINTS-Reader, olmOCR-7B, Dolphin-1.5, MinerU2-VLM, Nanonets-OCR-s, MonkeyOCR-pro-1.2B, Deepseek-OCR, MonkeyOCR-3B, dots.ocr, MonkeyOCR-pro-3B, MinerU2.5, PaddleOCR-VL, PaddleOCR-VL-1.5 ## 実験結果 ### 公開ベンチマーク(Table 3, Table 4) | ベンチマーク | GLM-OCR | PaddleOCR-VL-1.5 | Deepseek-OCR2 | MinerU 2.5 | Gemini-3-Pro | |---|---|---|---|---|---| | OmniDocBench v1.5 | **94.62** | 94.50 | 91.07 | 90.67 | 90.33 | | OCRBench (Text) | **94.0** | 75.3 | 34.7 | 75.3 | 91.9 | | UniMERNet | 96.5 | **96.1** | 85.8 | 96.4 | 96.4 | | PubTabNet | 85.2 | 84.6 | - | **88.4** | 91.4 | | TEDS_TEST | **86.0** | 83.3 | - | 85.4 | 81.8 | | Nanonets-KIE | **93.7** | - | - | - | 95.2 | | Handwritten-KIE | **86.1** | - | - | - | 94.5 | OmniDocBench v1.5 の詳細分解(Table 4): GLM-OCR は Overall スコア 94.62 で全モデル中 1 位。表認識では TableTEDS 93.96・TableTEDS-S 96.39 でいずれも 1 位。テキスト編集距離(TextEdit)は 0.040 で PaddleOCR-VL-1.5(0.035)にわずかに劣り、数式 CDM は 93.90 で PaddleOCR-VL-1.5(94.21)にわずかに劣るが、総合 1 位を確保した。 ### 社内ベンチマーク(Table 5) | タスク | GLM-OCR | PaddleOCR-VL-1.5 | Deepseek-OCR2 | dots.ocr | Gemini-3-Pro | |---|---|---|---|---|---| | コード文書 | **84.7** | 75.8 | 82.1 | 80.8 | 86.9 | | 実世界表 | **91.5** | 86.1 | - | 81.8 | 90.6 | | 手書きテキスト | 87.0 | **87.4** | 73.8 | 71.7 | 90.0 | | 多言語テキスト | **69.3** | 54.8 | 56.1 | 65.1 | 86.2 | | 印鑑認識 | **90.5** | 42.2 | 40.4 | 63.0 | 91.3 | | レシート KIE | **94.5** | - | - | - | 97.3 | 6 カテゴリ中 5 カテゴリで open-weight モデル最高スコアを達成。印鑑認識では次点の dots.ocr(63.0)に対して 27.5 ポイント差の 90.5 を達成し、Gemini-3-Pro(91.3)にも迫る。 ### スループット(Table 6) | モデル | 画像入力 (pages/s) | PDF 入力 (pages/s) | |---|---|---| | GLM-OCR | **0.67** | **1.86** | | PaddleOCR-VL-1.5 | 0.39 | 1.22 | | Deepseek-OCR2 | 0.32 | - | | MinerU2.5 | 0.18 | 0.48 | | dots.ocr | 0.10 | - | MTP 効果でスループットが約 50% 向上し、同規模の競合を大きく上回る。 ## 考察 GLM-OCR の高性能は単一の革新によるものではなく、アーキテクチャ・デコード戦略・タスク構造の 3 層の慎重な整合から生まれる。特に以下の点が注目される: 1. **OCR の決定論的特性との整合**: OCR は強い局所依存性と明示的な構造的監視を持つ決定論的タスクであり、厳密な 1 トークン/ステップの自己回帰デコードは非効率である。MTP はこの特性を活用して高い受容率を実現する。 2. **レイアウト解析の役割**: 小規模モデルは複雑レイアウトの文書処理時に幻覚と繰り返し生成を起こしやすいが、明示的なレイアウト解析モジュールを事前に導入することで複雑なレイアウト構造を複数の単純サブ問題に分解し、性能と安定性を向上させる。 3. **スケールに依らない SOTA**: 0.9B という小規模モデルが Qwen3-VL-235B(261 倍大きい)や Gemini-3 Pro を上回ることは、タスク特化アーキテクチャ設計の有効性を強く示す。 印鑑認識での圧倒的優位(90.5 vs 63.0)は、RL フェーズでの構造的出力監視が印鑑の円形レイアウトや傾きに対するロバスト性を向上させた可能性がある。 ## 強み - 0.9B の小規模モデルで 235B 以上の汎用 VLM を凌駕する文書パース性能 - MTP パラメータ共有設計で GPU メモリオーバーヘッドを低減しつつ推論速度を向上 - 印鑑認識・レシート KIE・多言語テキストなど産業ニッチシナリオでの高い汎化性能 - vLLM / SGLang / Ollama 対応の多様な展開オプション - LLaMA-Factory によるファインチューニング対応で迅速なドメイン適応が可能 - MaaS API で 100 万トークンあたり 0.2 元という低コスト提供 ## 弱点 - **2 ステージ構造の誤差伝播**: レイアウト検知が不正確な場合、下流の認識性能が劣化するリスクがある。クロスページ依存や不規則なマルチカラム構造では読み取り順序復元が不完全になりうる。 - **データカバレッジの限界**: 極端に低解像度・高歪み文書、非常に複雑な数式、密または不規則な表構造、訓練コーパスで少ない言語での性能が低下しうる。 - **構造的出力の変動性**: 生成モデルとしての性質から、改行や空白処理に若干の確率的変動があり、厳密なフォーマット保証は完全には不可能。 - **KIE のプロンプト依存**: 複雑なフォームで暗黙または曖昧なフィールド境界がある場合、出力が不完全・重複になりうる。 - **手書きテキストで PaddleOCR-VL-1.5 に僅差で劣る**: Handwritten Text スコアが 87.0 vs 87.4 であり、手書きデータの多様性確保が課題の可能性。