複数LLMを束ねてもAI-OCRの精度は上がらなかった話

はじめに

今年（2026年）のECUでは、手書きも混ざった紙やPDFの帳票や書類などをLLMを用いて文字起こしする開発プロジェクトを複数実施、リリースしています。きれいなデジタルPDFなら、今回試したどのモデルでも概ね読み取れるのですが、手書きの修正、紙をスキャンしたもの、固有名詞などはモデルによって読み取り精度にバラつきが大きく変わります。

色々と試行錯誤した結果、結論としては、複数のモデルを組み合わせて読み取りをするよりも単一の優秀なモデルにタスクを任せたほうが読み取り精度が高かったのですが、この記事ではどのようなことをどのように検証して、何が上手く行かなかったかを紹介します。

どうやって精度を測ったか

「良くなった気がする」という感覚で判断しないように、先に評価の仕組みを作りました。まず、実際の帳票（マスキング済み）と、人手で作った正解データ（項目ごとの正しい値）のペアを用意します。次に、プロンプト・モデル・処理方式の組み合わせを「パターン」として登録し、全パターンを同じテスト帳票に対して一括実行して自動採点します。比較の指標は、項目の一致率と、人手の修正なしで通った帳票の割合の2つです。

試したこと①：複数モデルの組み合わせ（アンサンブル）

モデルごとに得意・不得意があるなら、同じ帳票を複数のモデルに読ませて結果を突き合わせれば、単体モデルの読み落としを補えるのではないか。そう考えて試したのですが、一致率は最良の単体モデルとほぼ同じで、出力の集約に失敗してむしろ悪化するケースもありました。呼び出し回数が増える分コストはかさむのに、見合う改善がありません。なぜ補完し合わなかったのかは後で誤答を見ながら考えることにして、まずは他の手も一通り試しました。

試したこと②：同一モデルの複数回実行（多数決）

生成には揺らぎがあるので、複数回読ませて多数決を取れば「たまたまの読み間違い」を打ち消せるだろうと期待していました（テキスト生成でいうself-consistencyに近い考え方です）。多数決が効くなら、実行ごとの間違いはある程度ばらけているはずです。

ところが実際には、正しいときは同じ正解に揃い、間違えるときも同じ誤答に揃う傾向がありました。回数を増やしても答えが正解の方向に散らばるわけではなく、間違えるときは何度読ませても同じように間違えます。この時点で、単なる生成の揺らぎが主な原因ではなさそうだと感じ始めました。

試したこと③：文字起こし専用のOCRを前に挟む

モデルや実行回数を増やしても改善しなかったので、今度は前段の文字認識そのものを強くする方向を試しました。文字起こしに特化したOCRを前段に置き、抽出したテキストをLLMで構造化する二段構えです（OCR結果を画像と一緒にLLMへ渡すパターンも試しています）。

帳票によって勝ち負けはあったものの、全体では、画像をそのままLLMに読ませる直接方式を置き換えるほどの差になりませんでした。難しい帳票は、どちらの方式でも難しいままです。処理が一段増える分のコストと待ち時間も、地味に効いてきます。

なぜ効かなかったのか

3つとも空振りに終わったので、読み間違えたケースを個別に見直しました。そこで気づいたのは、モデルごとの間違い方が思ったほどバラバラではなかったことです。

アンサンブルが効くには、あるモデルが間違えた箇所を別のモデルが正しく読めている必要があります。多数決も同じで、実行ごとの間違いがある程度ばらけていなければ、数を集めても正解側には寄っていきません。たとえばコードレビューなら、どのモデルにも同じコードが欠けなく渡るので、セキュリティや性能など観点を変えて読ませれば互いの見落としを補えます。今回もそれと同じことを期待していました。

しかし実際の誤答は、印字のかすれ、崩れた手書き、複雑な表のレイアウトといった難しい箇所に集中していて、モデルを変えても実行回数を増やしても、そうした難所では同じように間違えるケースがほとんどでした。同じ画像を渡しても、あるモデルには「5」、別のモデルには「6」と見えることはあります。ただ今回重要だったのは、そうした認識のずれが互いを補う方向には十分ばらけなかったことです。間違いに多様性がなければ、結果をいくら突き合わせても最良の単体モデルは超えられません。

集約のやり方で挽回できないかも考えました。出力が割れたとき、表記ゆれなら機械的に揃えられます。しかし「5」と「6」のような読み違いは、出力だけを見てもどちらが正しいか決められません。判定役のモデルに画像をもう一度読ませても、同じ難所を改めて読むことになります。今回のケースでは、後段で安定して訂正することはできませんでした。

専用OCRを前段に置いても難しい帳票では同じように不合格になったことも、同じ話だと考えています。問題は、複数の出力をどう集約するかだけでなく、そもそも難しい入力を安定して読む部分にありました。

最終的にどうしたか

一般的なベンチマークで評価の高い有名モデルが、このケースで一番だったわけではありません。実際の帳票で比較すると、手書き混じりでも印字中心でも、種類を問わず一貫して精度の高いモデルが1つありました。決め手は手書きの読み取りで、ここだけ頭ひとつ抜けていました。最終的には、このモデルに画像を直接読ませるシンプルな構成に落ち着いています。今回効いたのは、モデルを増やして間違いを打ち消すことではなく、そもそも間違いの少ないモデルを選ぶことでした。

まとめ

当初は、モデルごとの得意・不得意を組み合わせれば互いの弱点を補えると考えていました。しかし実際の誤答はモデル間でも実行間でも十分にばらけず、難所では同じような間違いばかりでした。アンサンブルに必要な「間違いの多様性」が小さかったことが、改善しなかった一番の理由だと考えています。

一般的な評価の高さだけでモデルを決めず、実際の用途とデータで比較して、最も安定して読めるモデルを選ぶことが、今回の検証で得た一番の教訓でした。