資料の画像を渡せば、見出しや本文、表の配置までまとめて読み取ってくれる――そんな文書解析AI「dots.ocr」が、Dotsシリーズ追跡の今回の主役です。前回は142BのMoEモデル「dots.llm1」の技術報告とローカル推論を取り上げました。今回は同じrednote-hilabが公開している別モデルに照準を合わせます。GitHubでは多言語の文書レイアウト解析(Multilingual Document Layout Parsing)を掲げています[3]。レイアウト解析とは「紙面のどこに何が書かれているか」という構造を読み解く処理です。前回が「大きいモデルをどう動かすか」だったのに対し、今回は「資料をどう読み込ませるか」という入口の部分がテーマになります。
dots.ocrの推論環境は、大きく二つの方式が用意されています[1]。一つはvLLMで、OpenAI互換のAPIを持つ高性能な推論サーバーを立てる方式です。本番環境ではこちらが推奨されており、サーバーはvllm serveコマンドで起動します。Dockerによるコンテナ化やクラウドへの展開もドキュメントで扱われており、構築例ではリソースを効率よく使うためのパラメータがあらかじめ設定されています[1]。もう一つはHuggingFace Transformersで、開発やテスト、CPUだけの環境向けのシンプルな方式です[1]。高速な処理が要らない場合や、vLLMが動かない環境での選択肢になります。
注目したいのは、ベンチマークとエンジンの関係です。dots.ocrの公表ベンチマークは、すべてvLLM 0.9.1上でモデルを後から登録する形で測定されてきました[1]。その後、vLLM 0.11.0からはdots.ocrがvLLM本体に公式統合されています[1]。つまり、これまでの数値は特定バージョンの独自登録によるものであり、現在は導入方法が変わっています。公式統合で、利用者側の登録作業は減ったようです。
vLLMサーバーとのやり取りも具体的です。クライアント側の関数は、画像を文字列に変換するbase64形式で送り、テキストの指示と一緒にOpenAI互換のチャット completionsエンドポイントに投げます[1]。OpenAIのAPIと同じ形で呼べるため、既存のコードを流用しやすい構成です。導入の流れは「環境準備→モデルの取得→デプロイ設定」の三段階で整理されています[2]。重みのダウンロードスクリプトは2種類の取得元に対応し、既定ではweights/DotsMOCRというフォルダに保存します[2]。解析そのものはCLIのparser.pyが入口で、パース処理の全体を取り仕切ります[2]。
しかし、素材からは地味な落とし穴も見えてきます。重みを置くフォルダ名には「.(ピリオド)を含めてはいけない」という注意があり[2]、これは独自のモデル登録コードとの互換性を保つためです。vLLMとTransformersの両方でパス解決の問題を避けるため、決まったディレクトリ構造を守る必要があるとも説明されています[2]。また、Transformers側でローカル推論する例では、Flash Attention 2という計算を高速化する仕組みの設定にも触れられています[1]。Flash Attentionは「注目すべき部分だけを効率よく計算する」ことで処理を速くする技術で、長い文書の解析と相性がよさそうです。
一方で、前回の主役dots.llm1側の新しい動きは、今回の素材からは追えませんでした。性能評価やスペック・料金をまとめたベンチマーク関連ページの検索結果は[4][5][5]、タイトルだけが確認でき、中身の数値までは届いていません。Transformers経由での実測速度についても素材には数値がなく、ベンチマークがvLLM前提で測られている以上[1]、別エンジンでの速度は未知数です。この点は「素材には実測値が見つかりませんでした」と、正直に記しておきます。
Dotsシリーズは、汎用のMoE言語モデルに加えて、文書解析という実務寄りのモデルも公開しています。推論エンジンの選択肢が明示され、vLLMへの公式統合も済んだ今、ローカルで文書を読み込む環境づくりの敷居は下がったと言えそうです。次に注目したいのは、dots.ocrで読み取った文書をdots.llm1のような大規模モデルにつなぐ、一連の流れが共有されるかどうかです。
RECENT COMMENTS