OCRモデルがある印刷された連立方程式を処理する場面を考えてみよう。論文で示された実例の一つでは、本来 $\nabla^2$ を含むべき項が、モデルのLaTeX出力では添え字付きの演算子 \vec{\nabla}_{2} として出力されてしまっている。指数が下付きのインデックスへと潰れてしまったのだ。文字列としては依然として数式のマークアップとして認識できるものの、レンダリングされた構造はもはや元の画像と一致しない。

ここで別の数式 $T \ge 0$ を考えてみる。リファレンスが T \ge 0 となっているのに対し、モデルはこれを T \geq 0 と文字起こししたとする。単純な文字列比較を行えば両者に差異が検出される。しかし、どちらの表現もレンダリング結果はまったく同一である。この差異を認識エラーとして扱ってしまうと、実際には存在しない誤りに対してペナルティを科すことになってしまう。

この二重の厄介な問題は、ドキュメント解析が抱える本質的な課題を浮き彫りにしている。一方では、OCRの予測結果において内容の欠落や記号の誤認識、あるいは根拠のない構造の混入が生じうる。もう一方では、マークアップがエイリアス（別名表記）や等価な表現を用いているというだけで、文字列ベースの評価が妥当な出力を不当に減点してしまう。

TencentのWeChat Vision研究チームは、これら双方の課題を解決するアプローチを提案している。彼らが2026年9月3日に発表した論文『OCR-EDR: Rendering-Aware Diagnosis and Repair for Closed-Loop OCR Improvement』では、診断・修復フレームワークを定義し、Qwen3.5-9Bをベースに構築されたモデル「DocEDR」を導入している。元画像のクロップ、編集可能なOCR予測結果、そしてそのレンダリング画像の3つが与えられると、DocEDRは整合性を評価し、必要に応じて修正を加え、さらに新たなレンダリングを要求して修正結果を確認することができる。

報告された実験結果は目覚ましい。新たに構築されたベンチマーク「OCRErrBench」において、DocEDRは94.78%の診断精度を達成し、Qwen3.5-397B-A17B(FP8)を上回った。また、DOCRcaseBenchにおける数式のゼロショット診断では、DOCR-Inspector-7Bと比べてCase-F1を30.99パーセンテージポイント向上させている。さらに、OCRErrBenchの誤った入力のうち86.23%を修復し、リファレンスとの視覚的な一致を達成した。その貢献は、エラー検出、実行可能な編集、そしてレンダリングに基づく再評価を接続するクローズドループを実現した点にある。

複雑な数学の原稿

文字列の罠：なぜ従来のOCR評価は適切なコードを過小評価してしまうのか

研究チームがなぜDocEDRを開発したのかを理解するには、文字列ベースのOCR評価指標が何を測定しているかを考える必要がある。編集距離は、予測とリファレンス間の差異の文字数をカウントする。しかしそれ自体では、異なる2つの文字列が同じ視覚的内容と構造を維持しているかどうかを判断することはできない。

この違いは数式のマークアップにおいて極めて重要となる。論文では以下のような例が挙げられている：

\to と \rightarrow
{\bf x} と \textbf{x}
T \ge 0 と T \geq 0

これらのペアは異なるソースコードを用いながらも、まったく同じレンダリング結果を生成する。論文ではさらに、ギリシャ文字の表現、区切り文字（デリミタ）のサイズ指定、組版上の軽微な差異などを含む妥当な実例も提示されている。こうしたバリエーションは文脈に応じて確認されなければならない。例えば、区切り文字のコマンドなどは、いかなる場合でも自由に置き換えられるわけではないからだ。

著者らは、コードは異なるが正当な表現のことを「レンダリング等価陽性（rendering-equivalent positives）」と呼んでいる。Table 3で報告された境界診断サブセットにおいて、正規化編集距離の閾値を0.1に設定した場合、レンダリング等価なテキスト予測の57.14%が誤りとして棄却されてしまった。また、同テーブルで評価されたDOCR-Inspector-7Bは、等価な陽性例の75.81%を棄却した。なお、DOCR-Inspector-7Bは公式の単一画像プロトコルを維持して評価されており、この比較は同モデルが生の文字列のみを検査していると証明するものではない。

それとは正反対の問題も生じる。ソースコード上のわずかな変更が、重大な視覚的関係を変えてしまうことがあるのだ。\nabla^2 を \nabla_2 に変更することは、わずか1文字の置換にすぎないが、記号を上付き文字から下付き文字へと変えてしまう。したがって、全体の編集距離が小さい場合であっても、本質的な構造エラーが潜んでいる可能性がある。

論文では、この境界の両側面をテストしている。リファレンスに基づく数式基準である「CDM 0.9未満」は、選定されたサブセットにおいて等価な数式の2.94%しか棄却しないものの、その適用範囲内で評価された局所的なエラーをすべて見逃してしまった。同様に、テキストの編集距離基準もその適用範囲内の局所エラーを見逃している。これらは選定された事例と閾値における結果であり、いずれの指標も一様に無効であると示す証拠ではない。

テキストのみによる後補正（ポストコレクション）にも同様の限界がある。言語的パターンを利用してOCR文字列を改善することはできるが、修正された出力が元の画像の視覚的内容を再現できているかを直接確認することはできない。OCR-EDRは、その視覚的証拠を補正プロセスに組み込むのである。

コアアーキテクチャ：ドキュメント補正をステートマシンへと再構成する

DocEDRは、OCRの補正処理をエージェント的なステートマシン（状態遷移機械）として再定義している。初期の予測を固定された出力として扱うのではなく、モデルは編集可能な候補を保持し、以下の3つの入力を統合的に評価する：

元画像 ($I$): 元のドキュメントから切り出された視覚的なクロップであり、外部の根拠を提供する。
現在のOCR予測 ($p$): 数式のマークアップやテキストなど、編集可能な記号列。
レンダリング画像 ($R(p)$): 現在の予測をレンダリングした視覚的結果。

モデルは記号情報と視覚情報の双方を活用する。OCR文字列は正確な位置特定と編集を可能にし、そのレンダリング画像はその文字列が視覚的にもたらす結果を明らかにする。代替となるコマンドが元の画像の内容と構造を保持している場合、予測を受け入れて処理を停止（stop）することが期待される動作となる。

予測が元画像と一致しない場合、モデルはそれを診断して修復することができる。著者らは、相互排他的な5つのアトミックなエラーカテゴリを定義している：

Invalid Output（グローバル）： 要求される表現形式において、空である、不正な形式である、構文解析不能である、またはレンダリングできない出力。
Global Mismatch（グローバル）： 異なる領域の内容を読み取っているなど、元画像全体と整合しない予測。
Completeness（ローカル）： 単語の抜け落ち、項の欠落、あるいは冗長な内容。
Content（ローカル）： ラテン文字の $k$ をギリシャ文字の $\kappa$ と誤認するなど、個々の文字や記号の誤り。
Structure（ローカル）： 読み取り順序、グループ化、階層構造、あるいは上付き文字の平坦化や分数の崩れを含む、空間的・マークアップ的な関係の誤り。

予測の中に複数のエラーが含まれる場合もあるが、個々のアトミックエラーには1つのカテゴリが割り当てられる。局所的な編集が不適切なグローバルな失敗に対しては global_rewrite 操作が用いられる。局所的な修復には insert、delete、あるいは replace が使用される。

決定的な点として、DocEDRは編集を行うたびに自動的に再レンダリングを行うわけではない。そのポリシーレベルの行動空間には、inspect、diagnose_scope、localize、patch、global_patch、request_render、そして stop が含まれる。これらのアクションはプロセス全体を制御するものであり、OCR文字列に適用されるテキスト操作とは明確に区別される。

編集後、それまでのレンダリング画像は「stale（期限切れ／古い）」としてマークされる。モデルは再度の視覚的チェックを行わずにそのまま終了することもできるし、request_render を呼び出して更新された候補を確認することもできる。レンダリングの失敗には、staleな画像とは別に専用の明示的な状態が用意されている。したがって、このフレームワークは視覚的フィードバックが最新なのか、期限切れなのか、あるいはレンダリング失敗によって利用不可なのかを記録・管理する。

DocEDRの内部構造：より大規模なベースラインを打破するための9Bモデルの訓練法

DocEDRはQwen3.5-9Bを初期重みとして使用している。著者らは、診断のための教師あり微調整（SFT）、3段階の修復カリキュラム、そして強化学習を通じてモデルをトレーニングした。これらの段階を経て、妥当性の評価、編集、そして修復ループの制御が段階的に結び付けられていく。

フェーズ1：検証器の教師あり微調整（Verifier SFT）

モデルはまず、視覚的一貫性の検証を学習する。元画像、OCRテキスト、レンダリング画像が与えられ、妥当性と構造化されたエラー情報を予測するために1エポック訓練される。誤りのある予測に対しては、エラー分類、発生位置、そして提案される修正内容がその情報に含まれる。

この診断チェックポイントは、その後2つのルートに分岐する。1つのコピーは凍結され、報酬の検証器（Verifier）として機能する。もう1つのコピーは、インタラクティブな修復ポリシーとして継続して訓練される。これにより、修復モデルが新たな振る舞いを学習する間も、安定した診断シグナルが維持される。

フェーズ2：カリキュラム修復SFT

次に、エージェントは3段階の連続した教師あり微調整を受ける：

Stage 1（単一ターン修復）： 修復プロセス中にレンダリングを行わず、直接的な修正を学習する。
Stage 2（ツール選択）： すべての修正でツール呼び出しが必要とみなすのではなく、更新されたレンダリングを要求するか、そのまま終了するかを選択することを学習する。
Stage 3（マルチターン視覚的回復）： 編集後の実際のレンダリングフィードバックを受け取る。残存するエラーを認識し、効果のなかった編集から回復して、必要に応じて修復を継続することを学習する。

Stage 1は1エポック、Stage 2およびStage 3はそれぞれ2エポック実行される。ベンチマークのデータは、元ドキュメントのレベルでこれらの訓練段階から厳密に隔離されている。

フェーズ3：GRPOによる強化学習

最終的なポリシーは、Group Relative Policy Optimization（GRPO）を用い、400ステップのアップデートにわたって最適化される。プロンプトごとに、訓練では8つの軌跡（トラジェクトリ）のグループをサンプリングし、ラベル条件付き報酬を用いてそれらをスコアリングする。

報酬設計では、妥当な入力と誤った入力が区別される：

妥当な入力の場合（$y_0 = \text{good}$）： 正規化された初期予測を維持することに対して報酬が与えられる。不要な変更、余分なターン、レンダリング呼び出しにはペナルティが科される。
誤った入力の場合（$y_0 = \text{bad}$）： 最終的な品質（Terminal quality）は、正規化編集類似度、リファレンスとの完全一致、凍結されたVerifierによる視覚的一貫性の判定、および出力フォーマットの妥当性を組み合わせて評価される。また、プロセスタームにより、評価された候補状態間の回復に報酬を与え、後退にはペナルティを科す。

この最適化はまた、繰り返しの編集、過度なレンダリング、そして最終結果が誤ったまま対話バジェット（上限回数）を使い果たすことを抑制する。等価な陽性例は保持ブランチにとどまるため、好ましいとされる標準的な表記へと無理に書き換えることを訓練で要求することはない。

このフェーズは、効率性の面でも測定可能な成果をもたらした。Stage 3 SFTから最終的なGRPOにかけて、全事例における平均軌跡長は2.594ターンから2.313ターンへと10.8%短縮された。誤りのある事例における平均レンダリング呼び出し回数は2.104回から1.598回へと24.0%減少した。それと同時に、修復スコアおよび保持スコアも向上している。

検証されるグラウンドトゥルース：OCRErrBenchの構築

このフレームワークを評価するため、研究者らは保持（preservation）、診断（diagnosis）、局所化（localization）、そして修復（repair）を軸に「OCRErrBench」を構築した。妥当な代替表現が含まれていることにより、厳格なテキスト一致では見失われがちな境界線を直接検証することができる。

このベンチマークには、OmniDocBenchおよびPureDocBenchを対象にDeepSeek-OCR、PaddleOCR-VL-1.5、Qwen3.5-27Bから収集された900件の実際のOCR予測が含まれている。テキストのクロップと数式のクロップが均等に分割されており、それぞれ450件ずつとなっている。

内訳は、妥当な入力が457件、誤りのある入力が443件である。妥当な事例のうち、141件は正規化後にリファレンスと一致し、316件はレンダリング等価陽性である。著者らは、これら2つのソースベンチマークに由来するデータを、診断SFT、修復SFT、およびGRPOの訓練から除外している。

アノテーションは、独立したモデルによるレビューと専門家によるフォールバックを組み合わせている。GPT-5.6 Sol、Claude Opus 4.8、Gemini 3.1 Proが、元画像のクロップ、予測、およびレンダリングフィードバックを個別に評価する。自動承認されるためには、アノテーションの完全な一致と、レンダリング検証済みの修正案への収束が必要となる。これは合意の要件であり、ラベルに誤りがないことを保証するものではない。

難解なケースや不一致が生じたケースは、3人の独立したドメイン専門家に委ねられる。全員一致のアノテーションはそのまま採用され、意見が分かれた事例については、調整後の修復結果が割り当てられたエラータイプと合致し、かつリファレンスを再現できている場合にのみ保持される。

すべてのレンダリング等価陽性例には、追加の手動監査が実施されている。等価性のチェックには、KaTeX 0.16.11、Markdownパーサー、固定された表示設定、およびFandolフォントを含む固定フォントセットを備えた、凍結されたローカルのPlaywright/Chromium環境が用いられる。レンダリングの失敗が等価性の証拠として認められることは決してない。

印刷された技術研究論文

スコアカード：4つの外部OCRエンジンにわたる実質的な成果

OCRErrBenchの全900事例におけるエンドツーエンドの診断において、DocEDRは精度94.78%、バランス精度94.75%、Bad-F1 94.59%を達成した。ベースとなるQwen3.5-9Bの精度は81.44%、DOCR-Inspector-7Bは78.78%であった。Qwen3.5-397B-A17B(FP8)は87.78%に達したものの、DocEDRより7パーセンテージポイント低い結果となった。

局所化（ローカリゼーション）において、DocEDRはテキストスパンで92.72%、数式トークンスパンで73.26%のイベントレベルmicro-F1を記録した。これらのスコアは、正規化された3文字または3トークンの境界許容誤差を設けた1対1のエラーマッチングを用いている。同ベンチマークのプロトコル下において、数式の局所化でGLM-4.6V-Flashは0.61%、InternVL3.5-8Bは1.23%のスコアにとどまった。

修復と保持は個別に評価されている：

Visual Fix（VisFix）： 443件の誤った入力に対し、DocEDRは86.23%を達成した。これには、同一の凍結されたコンパイラ環境下で、修復後のレンダリングとターゲットのレンダリングがピクセルレベルで完全に一致することが求められる。
Exact String Fix： 同じ443件の誤った入力に対し、正規化ターゲット一致率82.17%を達成した。
Preservation Rate（保持率）： 457件の妥当な入力に対し、93.44%を達成した。

直接的な1ステップのQwen3.5-397Bは、VisFixで72.23%、ExactFixで26.19%にとどまった。また、DOCR-Inspector-7Bの誘導のもとQwen3.5-9Bが1パスの修正を行う構成では、65.46%のVisFixとなった。これらのベースラインはオンラインでの再レンダリングを使用していない。なお、より大規模な直接モデルは保持スコアにおいてDocEDRを上回っており、DocEDRの93.44%に対して94.75%であった。

ゼロショット診断は、互換性のあるDOCRcaseBenchの637事例（テキスト445件、数式192件）でテストされた。数式のCase-F1は、DOCR-Inspector-7Bの56.69%からDocEDRの87.68%へと30.99パーセンテージポイント上昇した。論文ではさらに、正しく分類された数式が61件増加したことも個別に報告されている。なお、これらは診断の結果であり、数式の修復率ではない。

最後に、著者らはUniMER-TestのSimpleおよびComplex Printed Expressionサブセットからパーサーごとに12,683件の数式を抽出し、リファインメント（改良）のテストを行っている。DocEDRは、正しいと判断した予測を保持し、誤りと判断した予測を修復する。報告された向上幅は、モデルによってBadと特定され修正された各パーティションに適用される：

MinerU2.5: 32.50%をBadと特定し、そのパーティションのCharacter Detection Matching（CDM）を2.93パーセンテージポイント改善。
PaddleOCR-VL-1.5: 22.19%をBadと特定し、そのパーティションのCDMを2.24ポイント改善。
InternVL3.5-8B: 25.92%をBadと特定し、そのパーティションのCDMを3.72ポイント改善。
GLM-4.6V-Flash: 37.18%をBadと特定し、そのパーティションのCDMを4.62ポイント改善。

修復前の各パーサーの全体的なCDMスコアは65.59%から94.12%の範囲にある。特定されたすべてのBadパーティションで改善が見られた。しかし、DocEDRがGoodと判定したからといって、リファレンスレベルで正しいことが保証されるわけではない。InternVL3.5-8BおよびGLM-4.6V-FlashにおいてGoodと判定されたパーティションの修復前CDMスコアは、それぞれ66.97%および78.65%であった。

ドキュメントエンジニアリングとLLMパイプラインにとってなぜ重要なのか

ドキュメントエンジニアリングの観点において、本論文の最も強力な実践的教訓は、評価されたタスクにおいて特化した診断・修復訓練が、はるかに大規模なモデルへの直接プロンプティングを凌駕しうるという点である。これは専用の補正ステージを検討する強い根拠となる。ただし、シングルパスOCRがスケーリングの限界に達したことや、あらゆるドキュメントパイプラインに実行ループが必要であることを示すものではない。なお、本研究の評価は英語と数式が中心であり、日本語読者にとっては、OCRやVLMにとって最難関となる漢字・仮名の混植や縦書きレイアウトが対象外である点に留意が必要である。

第二に、認識処理が行われた後も元画像は有用であり続けるという点である。OCR-EDRは編集可能なテキストやそのレンダリング画像と並んで、補正プロセスの全般にわたり元画像を根拠として保持する。これにより、提案された修正案が表示上の内容や構造を復元できているかをポリシーが確認できるようになる。なお、本論文では検索、RAG、数学の質問応答などの下流タスクは評価していないため、そうしたシステムにおける改善効果は未検証のままである。

第三に、表記上の違いと認識エラーとを区別することが評価において極めて有益であるという点である。OCRErrBenchには、真のエラーと並んで、完全一致の陽性例とレンダリング等価な陽性例の双方が明示的に含まれている。その結果は、ベンチマークが修復だけでなく保持についてもテストすべき理由を示している。破損した予測を多数修復できるモデルであっても、妥当な予測を不必要に変更してしまう可能性があるからだ。

アブレーション実験はその教訓をさらに裏付けている。条件を揃えた比較実験において、更新されたレンダリングを伴わない反復は、編集後フィードバックのない1ステップ設定と比べてExactFixを72.46%から66.82%へと低下させた。一方で、反復に更新されたレンダリングを組み合わせることで、ExactFixは82.17%、VisFixは86.23%へと跳ね上がる。ターン数が増えたことだけではこの向上は説明できない。モデルには自身の編集に関する有用な視覚的根拠が必要なのである。

最後に、外部パーサーを用いた実験は、既存のOCR予測を入力として受け取り、診断し、保持または修復して結果を測定するという具体的な統合パターンを示している。ドキュメントの選択された領域をこのようなステージにルーティングすることは、実運用における現実的な拡張案となる。ただし論文では、信頼度に基づくルーティングのテストや、その運用コストの検証は行われていない。

エンジニアリング上のトレードオフと未解決の難問

結果は魅力的であるものの、報告された実験は実運用に向けた幾つかの課題を残している。

その一つがレイテンシ（遅延）である。DocEDRはOCRErrBenchの全事例を通じて平均2.313回の対話ターンを要し、誤りのある入力に対しては平均1.598回のレンダリング呼び出しを行っている。これらの数値は対話の効率性を示すものであり、実際の処理所要時間を示すものではない。論文では実測レイテンシ（wall-clock latency）、スループット、運用コストが報告されていないため、このシステムがインタラクティブなスキャンや大規模なバッチ処理に適しているかどうかは判断できない。

もう一つの課題はレンダリング環境である。ベンチマークにおける等価性チェックおよび視覚的修復の判定基準は、固定されたコンパイラとフォント環境に依存している。これにより、選択された環境内での再現性は担保されるものの、任意のマークアップ、フォント、あるいは多様なドキュメント形式への対応までは保証されない。フレームワークはレンダリングの失敗を明示的に状態として保持するが、サポートされていない正当な構文に対する汎用的な解決策は論文では示されていない。

また、それぞれの指標において数式の局所化性能はテキストの局所化に比べて依然として劣っており、F1スコアで73.26%対92.72%にとどまっている。入力のアブレーション実験は有益な限定条件を示している。元画像とOCRテキストの組み合わせは完全な3つ組（元画像・テキスト・レンダリング画像）よりも高い局所化スコアを記録する一方で、レンダリングを追加することで妥当性判定とエラータイプ分類で最も優れた結果が得られる。レンダリングは有用であるものの、測定されたすべての能力を一様に向上させるわけではない。

等価な陽性例に関する結果にも注意が必要である。Table 3の境界診断分析において、DOCR-Inspector-7Bの偽陽性率75.81%に対し、DocEDRは25.81%の偽陽性率を記録したと報告されている。一方でTable E1では、完全な入力を与えたモデルにおいて4.75%の等価陽性偽陽性率が別途報告されている。論文中ではこれら2つの数値の整合性が明確に説明されていないため、25.81%という数値を妥当なコードバリエーション全般に対する一般的な率として提示すべきではない。また、診断上の偽陽性があったとしても、それだけで実際に編集が行われたことにはならない。

妥当な入力に対する93.44%という結果が示すように、保持性能も依然として完全ではない。また、すべての修正が新たな視覚的チェックを受けるわけでもない。追加のレンダリングを要求するかどうかはポリシーの判断に委ねられており、モデルは編集後にそのまま終了することもある。修復スコアはベンチマークの評価手順下での性能を示すものであり、あらゆる出力に対する保証ではない。

そうした留意点はあるものの、『OCR-EDR: Rendering-Aware Diagnosis and Repair for Closed-Loop OCR Improvement』は具体的な前進を示している。元画像に基づく診断、実行可能な修正、そして任意の視覚的再評価を単一のポリシーに統合し、修復の成功と妥当な予測の保持の双方を定量的に測定可能にしたのである。

コンパイラ・イン・ザ・ループ：TencentのDocEDRはいかにレンダリングを用いてOCRを検証・修復するか