はじめに
最近、社内に検証用のハイスペックGPUマシンが導入されました。 このマシンを実際に触ってみると、想像以上に大きなモデルをローカル環境で動作させることができ、 「これまで実現が難しかったことでも実現していけそうだ」という手応えがありました。
これまでAI関連のタスクとしては、書類からの特定項目の読み取りに取り組んできました。 この領域では、学習データを用意してトレーニングした特定タスク特化型のOCRモデルをサーバーに配置し実運用してきた実績があります。
一方で、近年のLLMの進化を見るにつけ、「汎用LLMでもうまく使えば、特化型モデルに近い性能が出せるのではないか」という疑問も湧いてきます。 もしそれが可能であれば、
- 学習データを大量に用意する
- モデルを個別に学習させる
といった、これまで当たり前だったモデル開発の考え方そのものが変わってくるかもしれません。 オープンソースのLLMであれば、実行毎にAPIの料金がかかることもありません。
そこで今回は、オープンソースのLLM(→ローカルLLM)を用いた書類の項目読み取りを実際に試し、従来の特化型モデルと性能を比較する検証を行いました。
GPUマシンとAIモデルの概要
GPUマシン構成
検証に使用したGPUマシンは、次の構成です。
- NVIDIA GB10 搭載デスクトップPC
ローカル環境とはいえ、LLMを動かすにはそれなりの計算資源が必要になりますが、このマシンであれば比較的大きなモデルも動かせました。
ローカルLLMの概要
今回利用したローカルLLMは googleのgemma3です。
- テキストと画像を入力できるマルチモーダルLLM
- パラメータサイズは 27B
- Hugging Face からモデルをダウンロードして利用
- 量子化は行わず、フル精度モデルを使用
ロードには Hugging Face の pipeline を用いました。
pipe = pipeline(
"image-text-to-text",
model="google/gemma-3-27b-it",
device="cuda",
)
最新のGPT系モデルと比べると性能は控えめですが、gemma3-27Bモデルはローカルで動かせるモデルとしては高性能な方だと思います。
特化型AIモデルの概要
比較対象として用いたのは、これまで実運用してきた従来型の特化モデルです。
- LLMではない、いわゆる従来型のAIモデル
- 書類を入力すると、あらかじめ定義した項目を読み取る
- 特定タスク向けのデータで学習済
- 他タスクへの転用はほぼ不可
特定タスク向けに学習を行っており、プロダクト水準の高精度を出せる点が強みです。
ローカルLLM（gemma3）の挙動と与えた指示
gemma3を実際に使ってみると、以下のような特徴が見えてきました。
- 推論能力や指示理解力はそれなりに高い
- 一方で画像からの文字認識精度はそこまで高くない (キリル文字が出現したりします)
そのため、比較的精度の良いOCRの結果を別途用意し、LLMに補助情報として与える 形を取りました。 今回は、以下の理由から easy-ocr を利用しました。
- pipインストールだけで手軽に使える
- オープンソースで、追加コストがかからない
- ローカルマシン上で処理を実行できる
Google Vision API など高精度な有料OCRを使う選択肢もありましたが、 今回は、
- API利用コストが発生しない
- 一連のOCR処理を完全にローカルで完結させられる
という条件を重視して、オープンソースOCRを採用しました。
プロンプト設計の工夫
汎用的なシステムプロンプトに加えて、読み取りたい項目ごとに専用のプロンプトが与えられるよう、ソースコードを作成しました。 複数項目をまとめて読み取らせるプロンプトも試しましたが、その場合は精度が安定せず、1項目ずつ質問する方式が最も結果が良さそうでした。
プロンプト例
system_message = "You are a helpful assistant who analyzes images and answers questions about their content." task_message = """ You will be given an image and a question. Your task is to analyze the image and provide an answer to the following question based on the content of the image. Do not include any information that is not explicitly present in the image. You can refer to the OCR results from the image to help answer the question. Instructions: * You should be careful to use the OCR results as the OCR results may not be accurate. * Do not use the OCR results when the OCR results do not seem to be correct and rely on your visual analysis of the image instead. ... """
※ OCR結果はあくまで参考情報として扱わせ、OCR結果が誤っていると思わしき場合はgemma3自身の読み取り結果を優先するよう指示しています。
項目毎の質問は、次のように追加指示を与えています。
q_message_issue_date = "When is the issue date of this document?" \ "\nExtra instructions:" \ "\n* The issue date must be in a format like 'YYYY-MM-DD'."
コストについて
今回の検証で発生したコストは、主に以下の通りです。
- 機器代：約70万円〜
- OCR：オープンソースモデルを利用しているため、実行毎のコストはなし
gemma3をプロダクトレベルでデプロイすることを考えると、
- GB10マシンを複数台用意する
- もしくは EC2 の「p5.48xlarge」などのハイスペックなGPUインスタンスを利用する (p5.48xlargeの場合、1年間継続で利用すると1月あたり31,641ドルくらいかかりそうです)
といった構成が必要になりそうですが、このあたりはまだ詳しい調査が必要そうです。
精度比較結果
gemma3 と特化型モデルについて、同一書類から 4項目を読み取るタスクで精度を比較しました。
特化型モデルの精度(正解率)を 1 とした場合、gemma3 の結果は次の通りです。
| 項目1 | 項目2 | 項目3 | 項目4 |
|---|---|---|---|
| 0.83 | 0.91 | 0.78 | 0.7 |
書類読み取りに特化していない汎用モデルでありながら、特化型モデルの7〜9割程度の精度が出ているのは、なかなか健闘していると言えそうです。 ただし、特化型モデルがプロダクト水準の精度を実現しているのに対し、gemma3はこのままではプロダクト利用には厳しい印象です。
処理時間の違い
1書類あたりの処理時間にも大きな差がありました。
- 特化型モデル：1〜2秒程度
- gemma3：3〜4分程度
精度だけでなく、処理時間の面でも現状ではプロダクト利用は難しいというのが現状です。
改善案
gemma3はオープンソースのモデルのため、ローカル環境で精度改善を行う余地があります。 とはいえ、27Bクラスのモデルをフル精度でファインチューニングするのは、計算リソース的に厳しいです。 次のようなアプローチで精度改善を検討するのが現実的だと思います。
- LoRA などのアダプター学習
- プロンプト設計のさらなる改善
- OCRとの連携方法の工夫
このように現状でそこそこの精度があり、精度改善の余地も残されています。 「学習データを大量に集めて専用モデルを作る」以外の選択肢が、少しずつ現実味を帯びてきているのを実感できた検証でした。
おわりに
今回の検証を通じて、ローカルLLMでも工夫次第で、従来の特化型モデルに迫る精度が実現できるとわかりました。 現状ではローカルLLMで特化型モデルを代替するような段階ではありませんが、将来のモデル設計やシステム構成を考えるうえで、大きなヒントになる結果だったと思います。
ローカルで大きなLLMを動かせる環境が整いつつある今、 「まずはLLMで試してみる」 そんな選択肢が、これから少しずつ現実的になっていくのかもしれません。
