概要
画像やPDFファイルから情報抽出を行う際にOCRモデルとマルチモーダルなLLMでは、どちらが良いのか比較していきます。
前置き
本番環境でGPUが調達できない、しかし、レスポンス速度は求められるという環境下で様々なOCR手法を試した経験に基づいて本記事を執筆しています。
注意事項
検証した画像ファイルは、すべて英語のものになります。日本語のものについては全く検証を行っていません。
評価指標について
OCR結果をそのまま使用すると出力フォーマットにズレがあるので、OCR結果をLLMでJSON形式にデータ整形してから、CERで比較しています。正解文字列については、今回の検証で一番性能の高いClaudeモデルの出力結果としています。
CER（文字誤り率）
0.0 <= CER <= 1.0の範囲で0に近似するほど精度が良いモデルとなります。
pythonの"editdistance"というライブラリで簡単に算出可能です。
# S = 置換された文字数、D = 削除された文字数、I = 挿入された文字数、N = 正解文字列の総文字数
# CER = (S + D + I) / N
import editdistance
ground_truth = "正解文字列"
prediction = "推論文字列"
# 編集距離（置換、挿入、削除の総数）を計算
distance = editdistance.eval(ground_truth, prediction)
# CERを計算
cer = distance / len(ground_truth)
検証モデル一覧
OCR
- Tesseract
- PaddleOCR
LLM
- Claude 3.5 Sonnet v1（正解データ作成用）
- granite3.2-vision
- gemma3:4b
- gemma3:12b
- qwen2.5vl:3b
- qwen2.5vl:7b
OCRモデル比較
単純にOCRの出力結果を整形して目視で精度を確かめました。結論としてはPaddleOCRの方がいいです。
様々な種類の画像ファイルを検証しましたが、PaddleOCRは画像が回転していたり、文字がかすれていたりしても、きちんと検出するなという印象でした。処理時間はTesseractが圧倒的に早いですね。
Tesseract
回転角度推定が機能としてあったので使ってみたのですが、回転する必要のない画像でも180度回転させたりとビミョーな感じです。。
やっぱり画像の傾きには弱いですね。。少しでも傾いていると精度が悪くなります。
PaddleOCR
こちらも回転角度推定があるのですが、あまり必要性を感じなかったのでオフにして検証を実施。やはりTesseractと比較すると精度はいいですね。強いて言えば、英単語の間のスペースが潰れてしまうのがネックかと。。（Tesseractはスペースはきちんと認識していました。）
| モデル | 長所 | 短所 | 処理時間 |
|---|---|---|---|
| Tesseract | 処理が早い | 画像の傾きに弱い | 1秒ほど |
| PaddleOCR | 画像の傾き、文字のかすれなどに強い | 単語のスペースがつぶれる | 10秒ほど |
LLMモデル比較
こちらの検証では各モデルごとにCERを算出して比較しました。（GPU搭載のEC2インスタンスで検証を行っております。）
| モデル | CER | GPU | 処理時間 |
|---|---|---|---|
| granite3.2-vision | 0.165... | なし | 16.52min |
| granite3.2-vision | 0.165... | 16GB | 14.6s |
| granite3.2-vision | 0.165... | 24GB | 1.75s |
| gemma3:4b | 0.677... | 16GB | 2.98s |
| gemma3:12b | 0.551... | 24GB | 3.57s |
| qwen2.5vl:3b | 0.798... | 16GB | 6.79s |
| qwen2.5vl:7b | 0.0 | 16GB | 12.8s |
| qwen2.5vl:7b | 0.0 | 24GB | 6.62s |
ある程度予想できた結果ですが、GPUは必須ですね。。
granite3.2-visionはモデルサイズは2Bほどとそこまで大きくないのですが、学習の際にVision EncoderにAnyRes手法を取り入れていたりとしているので、文書理解能力が高いのかと推察できます。
gemma3はモデルサイズが変わってもVision Encoderのサイズは変わらないので、精度が向上した理由としては言語モデルの推論能力が考えられます。
qwen2.5vlはモデルサイズが上がるとVision Encoderのサイズも上がるので、精度が向上しますね。
モデルごとのVision Encoderのアーキテクチャは下記のような感じになっています。
（ざっくりとなので、詳しくは論文を参照ください。）
- granite3.2-vision: "SigLIP"というVision Encoderを基に"AnyRes"という手法で学習
- gemma3: こちらも"SigLIP"というVision Encoderをファインチューニング
- qwen2.5vl: Vision Transformer(VIT)の設計を基にしたアーキテクチャ
OCR + α の検証
OCRモデルはPaddleOCRが安定して精度が高かったので、PaddleOCRを採用し、何らかのモデルで情報抽出を行い、前述のVLM（Vision Language Model）の精度に近似できるか検証。
（検証時点は、CPUオンリーの環境でレスポンス速度が求められるということで情報抽出を行うモデルはマルチモーダル対応ではない、小さめのLLMを使用）
LLMで情報抽出
OCR結果をLLMに投げて、JSON形式に情報抽出させてます。（請求書の宛先など）
| 手法 | CER |
|---|---|
| PaddleOCR + gemma3:1b | 0.569... |
| PaddleOCR + granite3.3:2b | 0.283... |
OCR結果を見た感じですと、人間でもパッと見は何が何を指しているのかはよく分からないテキストなので、LLMの推論能力が高ければ、ある程度推論してくれるのかなという印象です。
それでもOCRでは、テーブルとか表のフォーマットが崩れて、よく分からない出力がされると人間でもお手上げなので、そこの改善は難しいかと。。
逆にVLMに突っ込んだ方が、Vision EncoderのEncoding能力 + LLMの推論能力を密接に繋げられるので、変にOCRさせない方が精度は出そうです。
ただ、サイズの大きなVLMを使うとGPU必須になってくるので、CPUだけの環境ではOCR + 1B~2BほどのLLMがレスポンス速度を出す上で現実的になってきますね。
その他に試したこと
小さめのVLMでOCR
下記のVLMにOCRを指示してテキスト検出をやらせてみました。
| モデル | 結果 |
|---|---|
| gemma3:4b | 画像からは読み取りづらいというレスポンス + 断片的な抽出結果のみ |
| qwen2.5vl: 3b | ある程度は読み取ってくれるが、PaddleOCRには及ばず |
処理速度も30s~1minほどなので、PaddleOCRに軍配が上がります。
PP-StructureV3
PaddleOCRの機能でOCR結果をMarkdown, JSONに整形してくれる。（OCR -> 整形までがセットで１つの機能）
試してみたものの処理時間が1minほどかかってしまうので、VLMに突っ込んだ方がいいかなという評価。
LayoutLMv3
OCR結果の検出された文字と座標位置を入力として文書解析を行えるモデルらしいので、試してみましたが、どうやらファインチューニングが必要そうなのでボツ。
SmolDocling
PDF文書のパースモデルとして有名なモデルです。モデルサイズは256Mほど。画像も構造化データに整形可能ということで試してみたものの、精度は微妙でした。。（処理時間は1minほどでした。）後になって論文を読むと、OCRエンジンはEasyOCRかつ、PaddleOCRは非対応とのことでボツ。
まとめ
LLMだと勝手にテキストを変えたりなども行うことがあったので、ファクトチェック的にOCRは使えるのかなという印象です。ただ、複雑な図表が含まれるデータに対してはVLMの方が圧倒的に良いですね。まとめると、下記の点が重要になってくるかと思います。
- GPUを使えるか: 最重要ですね。これがあるのとないとでは使えるモデルの幅が全然違います。
- 処理速度: 非機能要件などでどのくらいを求められるかによっては、OCRモデルも選択肢に入ってきます。
参考文献
PaddleOCR 3.0 Technical Report
Granite Vision: a lightweight, open-source multimodal model for enterprise Intelligence
Gemma 3 Technical Report
Qwen2.5-VL Technical Report