AIと連携するDatacap

 こんにちは、Intelligent Content Servicesの清水です。
さて、前回に続いてOCRシリーズ第２話です。


https://qiita.com/Akira_Shimizu/items/3295bc8d611d4efcd37a


いよいよ、AIとの連携について見ていきましょう。

## 1 : 従来のOCRの課題

では、初めに、前回お話しした現状のOCRの課題を振り返りましょう。
 
主に３つありました。
 
- a: ロングテール出現頻度とテンプレート
- b: 文字だけを認識し文脈が読めないOCR
- c: 複数ページの文書から必要なページの項目だけを抽出する
 
### a: ロングテール出現頻度とテンプレート
各種形式の文書から必要な項目を抽出するには、どの位置に何の情報が記載されているかを把握するための、テンプレートが有効でした。
しかし、受発注などの業務では、取引先企業の数が膨大で、また帳票種類数も膨大で、それらを掛け合わせた数だけテンプレートを作るのは、非常に負担が高いとお伝えしました。
出現頻度の高いところだけ準備したいのですが、Amazonで有名になったロングテールの出現頻度で、どの企業の何の帳票までテンプレートを用意すればいいのかという線引きは、大きな悩みでした。一年に１回しか処理しない帳票までテンプレートを作るのは工数に見合わないですよね。
 
### b: 文字だけを認識して文脈が読めないOCR
テンプレートが準備できなかった書類にOCRシステムが直面すると、従来のOCRシステムは、全ての文字を識字してテキストに変換し、そこからどうにか必要な情報を抽出しようと試行錯誤していました。
たとえば、何かの申込書なら、「氏名」の右に「山田太郎」という文字列が出現していれば、これは申込者の名前が山田太郎なのだなと判別すると言った具合です。しかし、保険の申込書類なら、単なる「氏名」の右は、申込者の名前なのか、それとも、保険金を受け取る人の名前なのか、わからない場合もあります。また、書面の形式によっては、氏名の右に記入する場合もあれば、下に記入する場合もあります。このように意味を理解する、つまり文脈を理解することは従来のOCR技術だけでは困難でした。
 
### c: 複数ページの文書から必要なページの項目だけを抽出する
例えば、受発注に用いられる100ページのPDFがあったとします。１ページ目が表紙で、２ページ目に、見積書のコピー、３ページ目に請求書の概要、４ページ目から95ページ目までが、対象品目の明細がずらっと並んでおり、96ページ目から、約款など契約文言が記載してあるとします。
行いたい処理が請求金額の総額の抽出だとすると、３ページ目の請求書の概要から（小計を除いた）総額だけを抽出する必要があります。人間であれば、全体を見渡した上で判断できそうですが、従来のOCRには高いハードルとなっていました。
 
 
これらの３つの課題に加えて、前回お伝えしなかった、別な課題として、「名寄せ」と、「変幻自在な表」があるので追加でご紹介させてください。
 
### d: 名寄せ
通常OCRしたデータは、既存のシステムに連携されます。その際には、多くの場合、既存システムのマスタに記載されている文字列などに名寄せする必要があります。
たとえば、慶應義塾大学という大学名を既存システムに連携したいとします。しかし、慶應義塾大学は、慶大、慶応大学、慶應大学（難しい「應」の方です）、慶応義塾大学（簡単な「応」の方に義塾がついてます）など、記載に表記ゆれが存在します。これらを一つの同じ意味であると名寄せした上で、既存システムに連携する必要があります。
この課題に対応するには、業務分野に特化した辞書が必要になります。
 
### e: 変幻自在な表
 
多くのビジネス文書に出現して、OCR処理にとって厄介なのが表です。
表に対してテンプレートを作るにも、列数は一緒でも列の幅（文字数）が文書ごとに微妙に違っていたり、複数のセルが一部だけマージされていたりします。
また、行数も20行などと固定な行数の形式であれば良いのですが、25行に増えたり、逆に10行で終わって、その短くなった表の直下に、別な抽出が必要な情報が記載されており、縦方向の座標だけでは判断できないことがよくあります。
 
また、表が１ページに収まらず、次のページまで伸びていく場合もあれば、その表が分割されて２ページ目の冒頭に表のヘッダ（項目名）がついていたり、つかなかったりと言った具合です。表の扱いはOCRの中でも難易度の高いものとなっています。
 
改めて、２つを加えてまとめると、既存のOCRには以下の５つの課題がありました。
 
- a: ロングテール出現頻度とテンプレート
- b: 文字だけを認識し文脈が読めないOCR
- c: 複数ページの文書から必要なページの項目だけを抽出する
- d: 名寄せ
- e: 変幻自在な表
 
## 2 ：AIによる解決
 
前置きが長くなりましたが、これらの課題を大幅に改善させるのがAIとの連携となります。
AI（特にLarge Language Model : LLM）の登場で効果を発揮するのが、人間の常識をコンピュータが持つようになった点です。
LLMをバッサリ解説すると、特定の文字の次にくる文字の確率が高いものをひたすら計算するものです。これが、つまり人間の常識なのです。LLMの詳細については他の記事を読んでいただくとして、OCR業務からすると何が嬉しいのでしょうか。

今まで困難だった常識、例えば、「山田太郎」は日本人の男性の名前であるという情報が判断に使えるようになります。また、保険の申込書の上部の氏名の次に「山田太郎」と記載があれば申込者の確率が高く、それより下に出現する氏名は、受取人の氏名である可能性が高いと言った、明文化されていない常識が、文脈を考慮した文字認識の判断に使われるようになります。
 
AIは、いいことばかりではない、つまり、AIの負の面でよく使われる、ハルシネーションが発生することもあります。
みなさん、これで躊躇されることも多いのですが、通常OCR業務は人間による再鑑が原則となっていますので、再鑑で直せばよいというビジネス判断ができる場面が多いのも事実です。つまり、従来では、担当者と再鑑者の２段階で人間が担当していたものが、再鑑だけの１段階で処理できることになり、大幅な工数削減が期待できると言った具体です。
 
 
では、次にそれぞれの課題についてAI（LLM）がどのように解決するのか見ていきましょう。

 
### a: ロングテール出現頻度とテンプレート
 
  この、テンプレートの準備が不要になる可能性があるところがAI（LLM）の最大のメリットだと考えられます。無限とも思える取引先と帳票種別ごとのテンプレートの作成が不要になる可能性もあります。
ただし、先程のハルシネーションも考慮すると、出現頻度の高い帳票はテンプレートを作成した方が安定した識字が可能であると考えられます。既知の帳票であれば、この場所には、必ず申込者の名前が記載されているハズであると判断できる方が、精度が高いと考えられるためです。
とはいえ、お伝えしている通り、無限にテンプレートを用意することは現実的ではありません。
 
  テンプレートがない帳票でも、文面から人間の持つ常識を使って必要となる文字列を抽出する精度が大幅に向上されてテンプレートがある状態と大差ないレベルまで引き上げられれば、再鑑の工数も大幅に下げされることが期待できます。
 
  では、実際にAIにどのように依頼するのでしょうか。
 
  多くの方々にイメージしやすい免許証の例をあげると、「氏名、生年月日、住所、有効期限、番号」という抽出したい項目をLLMにプロンプトに入れて抽出するように依頼するだけです。
つまり、プロンプトに項目名をいれるだけで、テンプレートを用意しなくとも一定の精度で項目が抽出できるようになりつつあります。


### b: 文字だけを認識し文脈が読めないOCR
この課題は、a:のテンプレートが不要になる点と同じです。表裏一体とお考えください。常識をもったLLMが文脈を理解できれば、全文をテキスト化してLLMに必要な項目を抽出するように依頼するだけです。これにより、テンプレートの重要性が相対的に低下していくと考えられます。


### c: 複数ページの文書から必要なページの項目だけを抽出する
この課題は、複数のページの帳票の、各ページの意味を正しく見分けるというものになります。帳票分類です。帳票分類にも常識を兼ね備えたLLMは効果を発揮します。このページは「見積書、発注書、請求書、受注書のうち、どれに該当しますか？」とLLMに問いかけるのです。いうまでもなく、帳票種類が正しく分類できれば、そのページの中から必要な項目を正確に取得することに繋がります。

 
### d: 名寄せ
慶大、慶応大学、慶應塾大学の呼び方のバリエーション課題です。この課題は、LLMだけでは解決できません。LLMがどうして対象項目を抽出したのか、どうして全文の長い文字列から、その部分だけを切り抜いたのかは、システムを作成したプログラマーにも説明できないためです。「LLMがそのように返答したから」としか言いようがありません。
このため、実際のプロジェクトでは、名寄せをするために業界やユースケースごとの辞書を作成し、名寄せ処理を行うことになります。これは、LLMというより従来の辞書を用いるAI（ルールベースのAI）と考えられます。

### e: 変幻自在な表
表については、LLMの高い効率性の効果が確認されています。
 
  従来の座標ベースのテンプレート方式では、どの位置から何の列が開始される、何行目まで何の意味を持つものが記載されており、最終行は総計の値が入っている、など細かく指定をする必要がありました。
また、第１回で書いたように、セルの中の文字数が長いなどの理由で、列の幅がテンプレートでしていたものからズレると、横の行の文字列を読み込んでしまうと言った不具合が多発していました。
 
  一方、LLMでは個別の帳票の個別の表のヘッダ（タイトル）を識字し、LLMの持つモデルに照合することで、数多くのバリエーションがある表を、構造化された状態で（端的に表現するとヘッダ付きCSVの状態で）抽出することが可能となっています。
 
  変幻自在な表を構造化した状態で抽出することは従来のOCRシステムには困難だった点ですので、この点は大きな進歩と考えられます。
 
## 3. まとめ
 
以上５つの課題に対して、AIがどのように効果を発揮するか見てきましたが、いかがでしょうか。OCR業務においてAIが効果発揮できそうということが、少しご理解いいただけたのではないでしょうか。
 
IBMは、2024年8月にリリースされた Datacapのwatsonx.ai機能を用いることで上記の５つの課題を解決するソリューションを提供しています。

また、Datacapでは、IBMのLLMであるGraniteをはじめ、Open Source LLMを広くサポートしています。これらのLLMを自由に組み合わせて情報抽出ができるのもDatacapの強みの一つかなと思っています。

参考：


https://community.ibm.com/community/user/automation/blogs/shintaro-hase/2024/09/08/datacapwatsonxai

使用するLLMの設定方法

https://www.ibm.com/docs/ja/datacap/9.1.9?topic=actions-setmodel

使用できるLLM一覧

https://dataplatform.cloud.ibm.com/docs/content/wsj/analyze-data/fm-api-model-ids.html?context=wx#model-ids

https://www.ibm.com/products/watsonx-ai/foundation-models

---


さてさて、いかがだったでしょうか？

最近のOCRを使うと、色々便利なことができそうな感触を持っていただけたのではないでしょうか。便利って、素敵、Welcomeですよね。

これをきっかけにAI OCRに興味を持っていただけたら幸いです。