技術 約6分で読めます

GLM-OCR（0.9B）が文書解析SOTAを更新したので段組・縦書き・数式対応を調べた

AI OCR VLM GLM

PaddleOCR-VL-1.5の記事を書いたのが1月で、そこから2か月も経たないうちに同じ0.9Bパラメータ帯でSOTAが更新された。智谱AI（Zhipu AI）と清華大学のTHUDMグループが公開したGLM-OCRがそれで、OmniDocBench v1.5で94.62%を記録している。

このブログではこれまでNDLOCR、Tesseract.js、PaddleOCR、DeepSeek-OCRとさまざまなOCR手法を試してきた（OCR関連記事の一覧）。今回は特に段落わけ、縦書き横書き、数式という「OCRが苦手としがちな領域」にフォーカスしてGLM-OCRの実力を調べた。

GLM-OCRの概要

2026年3月11日に技術レポート（arXiv:2603.10910）が公開された。

項目内容
パラメータ数0.9B（CogViT 0.4B + GLM-0.5B）
開発元智谱AI + 清華大学THUDM
ライセンスコード: Apache 2.0、モデル重み: MIT
対応言語100以上（日本語含む）
出力形式Markdown、JSON（座標付き）、LaTeX
利用方法vLLM、SGLang、Ollama、HuggingFace Transformers、pip install glmocr

アーキテクチャは3つのコンポーネントで構成される。

CogViT（視覚エンコーダ 0.4B）
  → クロスモーダルコネクタ（トークンダウンサンプリング）
    → GLM-0.5B（言語デコーダ）

特徴的なのはMulti-Token Prediction（MTP）で、ステップあたり平均5.2トークンを生成する。標準的なオートリグレッシブデコードと比較してスループットが約50%向上する。

訓練は4段階で行われる。

  1. 視覚エンコーダの事前学習（数百億の画像テキストペア）
  2. マルチモーダル事前学習 + MTP適応
  3. OCR特化タスクでのSFT（テキスト認識、数式、テーブル、KIE）
  4. GRPO（Group Relative Policy Optimization）による強化学習

4段階目が面白い。タスクごとに異なる報酬関数を使う。テキスト認識にはNormalized Edit Distance、数式にはCDMスコア、テーブルにはTEDSスコア、KIEにはField-level F1。さらに繰り返しやJSON不正構造へのペナルティも含まれる。

ベンチマーク比較

OmniDocBench v1.5での比較。PaddleOCR-VL-1.5の記事で紹介したモデルとの差を見る。

モデルパラメータOverall
GLM-OCR0.9B94.62
PaddleOCR-VL-1.50.9B94.50
MinerU2.51.2B90.67
Gemini-3 Pro非公開90.33
Qwen3-VL235B89.15

0.9Bのモデルが235Bのモデルを5ポイント以上上回るという結果。パラメータ数が260倍あっても文書解析特化モデルには勝てない。

サブメトリクスを見ると得意不得意がある。

指標GLM-OCRPaddleOCR-VL-1.5
Text Edit（低いほど良い）0.0400.035
Formula CDM93.9094.21
Table TEDS93.96—
Table TEDS-S96.39—
Reading Order Edit（低いほど良い）0.044—

テキスト認識と数式はPaddleOCR-VL-1.5がわずかに上回る。テーブル認識でGLM-OCRが圧倒的に強く、それが総合スコアの差になっている。

段落わけ・レイアウト解析

OCRで最も厄介な問題のひとつがレイアウト解析で、NDLOCRのヒストグラム解析記事では4段組縦書き書籍のLayout Parserが機能せず、PyMuPDFとヒストグラムで力技解決した経験がある。

GLM-OCRは2段階パイプラインを採用している。

graph TD
    A[入力画像] --> B[PP-DocLayout-V3<br/>レイアウト解析]
    B --> C1[段落]
    B --> C2[テーブル]
    B --> C3[数式]
    B --> C4[図]
    B --> C5[ヘッダー<br/>フッター]
    C1 --> D[GLM-OCR Core<br/>並列認識]
    C2 --> D
    C3 --> D
    C4 --> D
    C5 --> D
    D --> E[Merge & Post Process<br/>読み順復元]
    E --> F[構造化出力<br/>Markdown/JSON]

1段階目でPP-DocLayout-V3がページをセマンティック領域（段落、テーブル、数式、図、ヘッダー、フッター、キャプションなど）に分割する。2段階目でGLM-OCR本体が各領域を並列に認識し、最後にMerge & Post Processが読み順を復元して構造化出力を生成する。

各領域を独立に処理するためハルシネーションが起きにくい。一方で、1段階目のレイアウト検出が間違うとエラーがそのまま伝播する。技術レポートでも known limitation として挙げられている。

Reading Order Editスコアは0.044（低いほど良い）で、読み順の復元精度は高い。ただし、NDLOCRで苦労したような複雑な段組レイアウト（4段組縦書きなど）に対する詳細な検証結果は技術レポートに含まれていない。

縦書き・横書きの対応

技術レポートには縦書き（vertical text）に特化した議論がほぼない。

HuggingFaceのモデルカードには「diverse text orientations」のサポートが記載されている。また、レイアウト解析に使われるPP-DocLayout-V3 / PaddleOCRパイプラインにはuse_doc_orientation_classifyとuse_textline_orientationというオプションがあり、文書やテキスト行の向きを検出する機能が存在する。日本語と中国語は対応言語に含まれる。

ただし、Real-World Scenarioの内部評価でMultilingual（多言語）スコアが69.3と他のカテゴリ（Receipt KIE: 94.5、テーブル: 91.5など）と比べて明らかに低い。CJK言語や縦書きを含むシナリオが弱い可能性がある。

比較対象として、NDLOCRシリーズは国立国会図書館が開発しただけあって縦書き日本語に特化した強みがあった。VLMベースのモデルは構造理解力は高いが、縦書きという特殊なレイアウトに対するきめ細かい対応は従来型OCRに分がありそうだ。

数式認識

数式認識はGLM-OCRが最も得意とする分野のひとつ。

ベンチマークスコア
UniMERNet96.5（SOTA）
Formula CDM（OmniDocBench）93.90
OlmOCR-Bench Arxiv Math80.7%

数式をLaTeX形式で出力する。分数、上付き・下付き文字、行列、行列式、多段の添字構造など、2次元的な空間配置を持つ数式記法を高精度で変換する。"Formula Recognition:"というプロンプトで数式特化モードに切り替わる。

VLMベースOCRの記事で書いたように、従来のパターンマッチング型OCRは数式のような2次元構造の認識が苦手だった。VLMベースのアプローチは画像全体をコンテキストとして捉えるため、数式認識に本質的に向いている。GLM-OCRはその傾向を裏付ける結果になっている。

ただし、技術レポートでは「highly complex mathematical expressions can still fail」とも書かれており、極端に複雑な数式では失敗するケースがある。

その他の認識能力

数式以外の特殊ケースもカバーしている。

カテゴリスコア
テーブル認識（TEDS-S）96.39
ヘッダー・フッター95.8%
レシートKIE94.5
印鑑認識90.5
ベースライン98.8%
長い細かいテキスト86.9%
手書き文字87.0
コード文書84.7
多段組76.7%
古いスキャン37.6%

古いスキャン（Old Scans）が37.6%と極端に弱い。劣化した紙やかすれた印刷への対応は課題。NDLOCRが国会図書館の古い蔵書を対象に開発されたことを考えると、用途によってはNDLOCRのほうが適している場面がありそうだ。

導入方法

Ollamaで試すのが最も手軽。

ollama run glm-ocr

PythonのSDKも提供されている。

pip install glmocr

vLLM、SGLang、HuggingFace Transformersでも動作する。iOSやMacでの軽量デプロイはMLXも使える。NDLOCR-LiteをiOSに載せた記事と同じように、エッジデバイスでの推論も視野に入るサイズ感（0.9B）ではある。

従来型OCRとVLM-OCRの使い分け

このブログで試してきたOCR手法を整理すると、用途別の使い分けが見えてくる。

用途推奨
高精度な文書解析（テーブル・数式）GLM-OCR / PaddleOCR-VL-1.5
縦書き日本語（古い書籍）NDLOCR / NDLOCR-Lite
ブラウザ上でのリアルタイムOCRTesseract.js（現時点で唯一の選択肢）
OCR結果の後処理・校正エンコーダモデル + LLM（校正パイプライン）
大量PDFの一括処理DeepSeek-OCR-2（コスト効率重視）
モバイルでのオンデバイスOCRNDLOCR-Lite + ONNX Runtime

VLM-OCRは構造理解とマルチタスク性能で圧倒的だが、特定のニッチ（縦書き、古文書、ブラウザ実行）では従来型が依然として有効。「全部VLMに置き換えればいい」というフェーズにはまだなっていない。

Multilingual 69.3というスコアが引っかかる。日本語縦書き文書で実際どの程度使えるかはOllamaで手元のデータを流してみないとわからない。近いうちに試す。