無制限OCR：ワンショット長距離パース解析

2026年6月23日原文(github.com)

概要

Unlimited-OCR は、Deepseek-OCRを進化させた最新の長文OCRモデル
Huggingface transformersやSGLang環境での推論・バッチ処理に対応
シングル画像・マルチページ・PDF解析をサポート
モデルとコードは ModelScope で公開中
arXivに論文掲載、各種OCRモデルへの謝辞あり

One-shot Long-horizon Parsing時代の到来

Unlimited-OCR は、長文・複数ページ文書のOCR解析に特化した新モデル
Deepseek-OCR の限界を突破するために開発
arXivに論文公開（2026年6月23日付）： https://arxiv.org/abs/2606.23050
ModelScopeコミュニティの協力を受け、 ModelScope 上でモデル配布中

推論環境と必要要件

Huggingface transformers を活用したNVIDIA GPU上での推論
動作確認済み環境：python 3.12.3 + CUDA12.9
- 必須パッケージ例：
  - torch==2.10.0
  - torchvision==0.25.0
  - transformers==4.57.1
  - Pillow==12.1.1
  - matplotlib==3.10.8
  - einops==0.8.2
  - addict==2.4.0
  - easydict==1.13
  - pymupdf==1.27.2.2
  - psutil==7.2.2

推論実行例（transformers）

モデル・トークナイザーの読み込み
- model_name = 'baidu/Unlimited-OCR'
推論設定（シングル画像の場合）
- gundamモード：base_size=1024, image_size=640, crop_mode=True
- baseモード：base_size=1024, image_size=1024, crop_mode=False
サンプルコードで画像・PDF解析に対応
- PDFはPyMuPDFで画像化し、multi-page推論に渡す

SGLangによるサーバー推論

uv-managed virtualenv 環境構築
- sgLangのwheelパッケージ導入と依存関係のインストール
サーバー起動コマンド例
- モデル指定やメモリ割当、カスタムロジットプロセッサ設定
OpenAI互換APIへのストリーミングリクエスト送信
- 画像エンコード・PDF画像化・リクエスト生成関数をサンプル提供
シングル/マルチ画像・PDFに応じてimage_modeやngram_windowを調整

バッチ推論・自動化

infer.pyによるディレクトリ・PDF一括推論
- 画像ディレクトリやPDFファイルを指定し、並列推論可能
- オプションでモデルID・GPU番号・サーバーログ出力先を指定

可視化・謝辞・引用情報

Deepseek-OCR, Deepseek-OCR-2, PaddleOCRなど既存モデル・アイディアへの謝意
論文引用形式（BibTeX）を明記
- @misc{yin2026unlimitedocrworks, ...}

Unlimited-OCRの特徴まとめ

超長文・複数ページ に特化した高性能OCR
Huggingface や SGLang など主要エコシステムと連携
PDF変換・バッチ処理など業務用途にも即応
最新の研究成果を arXiv で公開、コミュニティ貢献

Hackerたちの意見

とても興味深いね。私の理解では、研究者たちはAIが長い文書を読むときにメモリを無駄にしないための巧妙な建築的ハックを見つけたみたい。普通、AIが100ページのPDFを転写するとき、すでに取り込んだ単語を全部覚えようとするんだ。この短期記憶（KVキャッシュ）は、モデルがVRAMを使い果たしてクラッシュするまで線形に増えていく（または制限される）。それを避けるために、開発者たちはPDFを個々のページに分割して、一つずつ処理して、テキストを再結合するような雑なコードを作らざるを得ないんだ。Unlimited OCRは、Reference Sliding Window Attention（R-SWA）を使ってAIの焦点を二つのパスに分けるんだ。グローバルリファレンス：AIは元の文書画像を完全に把握して、文脈を失わないようにする。ローカル生成：AIは自分が入力したテキストの記憶を狭い移動ウィンドウ（例えば、最後の128単語）に制限して、残りを安全に忘れる。ローカルAIにとって非常に興味深いし、コミュニティがこれを使って何を作り出すのか楽しみだね！

└

ほら、LeetCodeは役に立つよ。LeetCodeをやっていると、技術が存在する理由や実際にどう使われているのかを考えるようになった。面白いことがたくさんあるね。

└

これ、会話にもいい感じだと思う。長い会話をまとめるのにずっと試行錯誤してるんだ。全体の文脈や、あまり変わらない事実があるよね。参加者の名前や背景とか。で、今役立つかもしれない細かい事実（今朝の朝食は何を食べたか）もあるけど、長期的には一般的なトレンド以外では関係ないことも多い。会話を再構築する時は、今まで話されたことを全部引っ張り出さずに、ちょうどいいバランスを見つけるのが大事だね。これはもっと調査する価値があるよ。

「Deepseek-OCR、Deepseek-OCR-2、PaddleOCRの貴重なモデルとアイデアに感謝します。」クラスアクトだね。

└

何か陰口を叩かれてるのかな？よくわからないんだけど？

Reductoはどうなったんだろう？12〜15ヶ月前はすごく期待できそうだったのに。

AIを使ってOCRを試みたけど、いつも発明されたアーティファクトが出てきて、実用的じゃないんだ。これも同じような問題があるのかな？例えば、他の言語の単語が自動的に英語に翻訳されてしまって、効果が台無しになることがあるんだよね。

└

100%の認識結果を達成したいなら、この方法を画像モデルと組み合わせて、書き起こしたテキストから元の文書を再現し、レイアウトを合わせるのがいいと思う。再現したい文書のページや段落を除いて、すべてを使うことができるから（テスト中の正確な部分を画像アーティファクトから直接再現しないように）。再構築した後は、特にずれている文字を一致させて、エラーを見つけるために光学的比較をすることができる。これを繰り返す感じ。高価だけど、100%の認識を保証するだろうね。

└

ほとんど[超]単語レベルの機械学習は望ましくないよね（つまり、単語ペア/フレーズ/文/文書/コーパスレベル）。トランスクリプションでは、ほぼ確実性が欲しいし、確実に読めなかった単語にはマークが必要だよね。確かに文脈があれば推測できるけど、OCRでは、単語を形成する文字の順番以外の理由で推測しているときは知りたい。例えば、familysearch.comの国勢調査文書で、トランスクリプターが名前をJosephに「修正」したんだ。手書きの文書の文字はJosepthと綴られていて…確かにそれは現地の変種のスペル（アイルランド）だよ。別の文書では、書き手が「Joh」を省略形として使っていて、[人間だと思うけど]トランスクリプターがそれをJohnとしたんだ…これは最も可能性が高いけど、実際には間違ってる。時には推測されたことが重要な場合もあるし、時にはただの最良の推測が欲しいこともある。

これをローカルで動かすための要件は何？

最近、楽譜用にタブレットを買ったんだ。主にジャズの「リアルブック」の山を置き換えるためにね。電話のカメラスキャンはまあまあだけど、サイズが固定されていてアーティファクトが多いんだ。BbやEb楽器用に即興で移調できたらいいんだけど、スキャンだから当然無理だよね。光学音楽認識の現状を調べてみたけど、どこを見ても音楽はAIにとって基本的に未開拓の分野だと思った。光学音楽認識はかなりひどいし、音楽理論のAI理解もひどい（実際に音楽を見ているわけではないけど；LLMは理論の概念をテキストで説明するのはまあまあできるけど、オンラインのテキストが役立つかもしれない）。問題は、ミュージシャンが読む紙の上の音符をエンコードするための優れたデジタルフォーマットがまだないことだと思う。音楽記譜はかなり複雑だし、MIDIは再生やパフォーマンスに関連する側面をキャプチャするために作られたから、象徴的理解に必要なすべてを捉えているわけじゃない。MusicXMLはミュージシャンが求める情報をエンコードするデジタルフォーマットとしては最も近いけど、MusicXMLの表現を楽譜画像や音声に結びつけるための良いトレーニングデータのコーパスがないんだと思う。MusicXMLは音楽を彫刻するために必要な情報を十分にエンコードできていないからだと思う。MuseScoreのようなツールは、MusicXMLにエンコードできないレイアウト情報を追跡する必要があるし、LilypondフォーマットはMusicXMLよりも冗長性が少なく、スコア作成者にとって有用な情報が少し多いけど、ほとんどの人はLilypondで楽譜を作らないんだよね。（余談だけど、Lilypondのジャズフォントの状態にはがっかりしてる。ジャズの文脈で「本格的」なスコアを見るのが嫌なんだ）。これはちょっと脱線してるけど、OCRで少しずつ進展しているのを見るたびに、OMRがどれだけひどいかを思い出すんだ。

└

楽譜のタイプセット形式について、https://abcnotation.com/ みたいなのはどう？

Hacker Newsで議論の続きを見る

ハクソク