資料の画像を渡せば、見出しや本文、表の配置までまとめて読み取ってくれます。これがDotsシリーズ追跡の今回の主役、文書解析AI「dots.ocr」です。前回は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種類の取得元に対応します。既定では決められた名前のフォルダに保存します[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