【geek-terminalニュース】Baidu Unlimited OCRの最新情報

【事象の全貌と背景】
BaiduのUnlimited OCRは、実務AIのいちばん泥臭く、しかし最も失敗すると全体が崩れる入力層に刺さるニュースです。LLM活用というと、RAG、エージェント、ベクトルDB、プロンプト設計に話題が寄りがちですが、現場でまず詰まるのは「そのPDF、本当に読めているのか？」です。契約書、請求書、医療帳票、社内規程、スキャン済み資料、複雑な表を含む報告書。これらをLLMに渡す前には、ページ画像化、OCR、レイアウト解析、表抽出、Markdown化、JSON化、チャンク分割、再結合という地味な前処理が山ほどあります。ここで1桁違う金額を読み間違えたり、表の列をズラしたり、ページ境界で文脈を切ったりすると、後段の高性能LLMは自信満々に間違った答えを生成します。

Unlimited OCRが狙うのは、この前処理の定番だった「ページごとにfor-loopでOCRして、あとから外部スケジューラや自前ロジックで束ねる」設計そのものです。公式リポジトリでは、DeepSeek OCRをベースラインにしつつ、長いOCRデコード時の注意計算とKVキャッシュ増大を抑える構成が説明されています。ポイントは、標準的な32K級コンテキストの範囲で、数十ページ規模の文書を単一の前向き推論で転写するという方向性です。つまり、RAGの前段で「文書を細切れにしてから理解する」のではなく、まず入力層で長い文書をまとまった構造として扱う発想です。

【技術的ディープダイブ】
公式情報上の中核は、Reference Sliding Window Attention、略してR-SWAです。Unlimited OCRはDeepSeek OCRを土台にし、デコーダの全注意層をR-SWAへ置き換えることで、長いOCRデコードでもKVキャッシュを全過程で一定に保つ設計だと説明されています。通常、長い系列を自己回帰的に吐かせると、過去トークンのキー・バリューが積み上がり、メモリ使用量が伸びます。長文PDFをページ単位ではなく一括で処理したい場合、このKVキャッシュ肥大化がかなり現実的な壁になります。R-SWAはここに手を入れ、長いデコードでもメモリが暴れにくい形にしている、というのが公開説明から読み取れるポイントです。

もう一つの重要点は、DeepSeek OCR系の高圧縮エンコーダと、一定KVキャッシュ設計の組み合わせです。LLMデコーダを使うエンドツーエンドOCRには、単なる文字認識だけでなく、言語の事前分布を使って読みを補える利点があります。一方で、その利点は「もっともらしい文字列に寄せる」危うさも持っています。Unlimited OCRは、そこに長文書対応のメモリ設計を合わせ、32K最大長で数十ページの文書を一括転写できることを狙います。公式コード例では、PDFをPyMuPDFなどでページ画像へ変換し、複数画像入力に対して「Multi page parsing.」というプロンプトを与える流れが示されています。単一画像では「gundam」または「base」設定が使え、複数ページやPDFではbase設定、つまりimage_size=1024を使う形が示されています。

モデル規模については、AI Weeklyが3Bパラメータ、MITライセンスのモデルとして紹介しています。また、Transformers、vLLM、SGLang、Ollama、llama.cppなど複数の実行環境に対応すると報じられており、ローカル推論や自前サービングへ組み込みやすい方向に寄せている点も大きいです。ただし、性能数値は慎重に扱う必要があります。36Krや网易系記事は、OmniDocBench v1.5で93.23%の総合スコアを出し、DeepSeek OCRを約6ポイント上回ったと報じています。一方でAI Weeklyは、公開リリースにはベンチマーク結果、学習データ、対応言語範囲が明記されていないと指摘しています。したがって、公式に断定できるのは「長文書OCR向けの設計・コード・利用手順が公開された」ことです。93.23%という数字や500M活性化といった説明は、現時点では報道上の性能主張として分けて見るべきです。

【コミュニティの生々しい熱量と議論】
今回、提供されたコミュニティ反応データには、Reddit、Hacker News、lobste.rsの具体的なコメント本文は含まれていません。したがって、誰かがこう罵倒した、HNでこう盛り上がった、といった生の発言を捏造して引用することはできません。ただし、提示された反応テキストには、現場のOCR派とLLM派の緊張感がかなりはっきり出ています。要するに「LLMはOCRエンジンではない」という論点です。

現場目線で見ると、この議論はかなり切実です。LLMに画像やPDFを直接投げれば、たしかに多くの場合は読めます。ですが、帳票の長い番号、紛らわしいIと1、0とO、小さい注記、密な表、変則的なレイアウトでは、LLMはしばしば「最もありそうな文字列」を返します。問題は、その推測に文字単位の信頼度が付かないことです。従来OCRなら、座標、信頼度、レイアウト情報を出して、危ない箇所を検査できます。LLMだけに任せると、出力は自然で読みやすいのに、どこで自信がなかったのか分かりません。これは業務利用ではかなり怖い。

だからUnlimited OCRへの注目は、単に「OCRが速くなる」ではありません。専用OCRエンジンの信頼性と、LLMデコーダの文脈利用能力を、長文書処理の形でどこまで折り合わせられるか、という話です。コミュニティ反応として提示されたテキストも、OCRとLLMは目的が違う、ビジネスクリティカルな処理ではLLM単独より専用OCRとLLM解釈の分業が安全、という立場を強く示しています。Unlimited OCRはこの分業を壊すというより、OCR側がLLM時代の入力形式に寄ってくる動きと見るのが自然です。

【今後の展望とエコシステムへの影響】
もしUnlimited OCRの方向性が実運用で強ければ、まずオワコン化するのは、雑にページごとOCRして、あとから正規表現と人力ルールで帳尻を合わせるだけの前処理パイプラインです。RAGの精度改善というと検索器や埋め込みモデルに手を入れがちですが、入力のMarkdownやJSONが最初から壊れていれば、どれだけ後段を磨いても限界があります。長文PDFを一括で構造化できるOCRが実用域に入るなら、RAG以前の「文書取り込み層」が競争領域になります。

一方で、過剰な期待も危険です。学習データ、対応言語、公式ベンチマークが明確に開示されていない点は、導入前に必ず検証すべきです。日本語帳票、縦書き、手書き、FAX劣化、印影、複雑な罫線、会計表、医療系の小さい文字などでどこまで粘るかは、公式の設計説明だけでは判断できません。さらに、LLMデコーダを使うOCRである以上、「もっともらしく補う」挙動をどう監査するかも重要です。座標、信頼度、差分検査、重要フィールドの二重OCR、サンプリング監査といったガードレールは引き続き必要でしょう。

それでも、このニュースがギークに刺さる理由は明確です。LLMアプリの勝負所は、派手なチャットUIではなく、PDF、画像、帳票、表をどれだけ壊さずモデルに食わせるかにあります。Unlimited OCRは、その入力層をページ分割の寄せ集めから、長期ホライズンの単一推論へ寄せようとするOSSです。RAGや業務エージェントの精度を本気で上げたい開発者にとって、これは「またOCRモデルが出た」ではなく、文書AIスタックの最下層が再設計されるかもしれないシグナルです。