LayerX エンジニアブログ

LayerX の エンジニアブログです。

Document AIを巡る技術とLayerXにおける可能性

初めまして。機械学習エンジニアの島越@nt_4o54です。現在はMLチームで日々、バクラクシリーズで用いられているAI-OCR機能の改善や新規機能の開発などを行なっています。 7月はLayerXエンジニアブログを活発にしよう月間ということで、自分からは表題にもある通り、「Document AI」と呼ばれる技術についての紹介と、またLayerXにおいてどういう応用先があるのかというお話をさせていただこうと思います。

※ 同名のDocument AIというGCPのサービスがありますが、今回は一般的なDocument AIの話になります。

Document AIとは

ビジネスにおいては、多くの企業が日々さまざまなドキュメントを扱っています。例えば、請求書や領収書、契約書などがその代表的なものです。しかし、これらのドキュメントは、十分に活用されていないというのが現状です。その理由としては、そのほとんどが非構造化データであるテキストデータや画像データであることが挙げられます。これらのドキュメントから情報を抽出するには、人間が認識しやすい形で構造化する必要があります。しかし、これは非常に手間のかかる作業であり、かつ労力を必要とすることが多いため、活用されていないというのが現状です。

そこで、注目されているのが「Document AI」と呼ばれる技術です。この技術を使うことで、非構造化のデータから重要な情報やインサイトを抽出することができます。この技術は、現在の国際学会でも多くの論文が投稿されており、それらは注目を集めています。

そこで、今回の記事では、Document AIに焦点を当てて、どのような技術が使われているのか、LayerXにおいてどのような応用先があるのかについて紹介したいと思います。

Document AIに用いられる技術

まず、Document AIで解かれる問題がどのようなものがあるかを紹介します。 Hugging Face[1]の記事によると、一般的には主に以下の6つの問題に分類されると書かれています。

  1. Optical Character Recognition (OCR)
  2. Document Classification
  3. Layout Analysis
  4. Document Parsing
  5. Table detection, extraction, and table structure recognition
  6. Document question answering (DocVQA)

これらについて[1]の記事を参考に一つずつ簡単に紹介していきます。

Optical Character Recognition (OCR)

OCRは日本語で文字認識と言われるタスクで、画像や手書き文書から文字の位置と内容を抽出するタスクです。Document AIの根幹となる技術で、pdfや画像などからテキスト情報を抽出し、コンピュータが認識できる形に変換を行います。OCRは既存のクラウドサービスなどでも提供されていて、OSSではEasyOCRやPaddleOCRなどが有名です。 最近では、TrOCR[2]などのTransformerベースのOCRも登場してきています。

Document Classification

Document Classificationはその名の通り、請求書なのか、メールなのか、契約書なのかといった文書分類を行うタスクです。 従来は、OCRした結果のテキストに対してBERTなどのモデルが使用されてきましたが、最近ではレイアウト情報を考慮するための新しい手法であるLayoutLM[3]やDonut[4]などが登場しています。 これにより、ただ単にテキスト情報を利用するのではなく、画像やレイアウト情報を使うことが精度向上につながるということが分かりました。 RVL-CDIPというデータセットで比較した結果によると、BERTベースのモデルで89%程度の正解率だったものが、画像ベースのモデルで92%の正解率、画像 + テキストベースのモデルで95%の正解率になったと報告されています。 このように、最近のDocument AI界隈ではテキストだけでなくマルチモーダルな情報を利用することが主流となってきています。

Layout Analysis

Layout Analysisは文書内の構造を検出するタスクです。例えば、PubLayNet[6]というデータセットでは、文書がテキスト部分、タイトル部分、図、表、リストなどにアノテーションされています。Layout AnalysisはObject DetectionかSegmentationの問題として解かれることが多く、出力値としては該当するクラスのBounding boxやSegmentation maskになります。例えば、以下の図がMask R-CNNで予測した例になります。

PubLayNetデータセットに対してMask R-CNNで予測した結果の例[6]

この問題に対して現在で性能が最も高いと報告されているのは、画像とテキストデータ、2次元情報を用いたLayoutLMv3[7]というモデルです。他にも画像ベースのDiT[5]といった手法も用いられています。

Document Parsing

Document Parsingは、文書から重要な情報を抽出するタスクです。例えば、請求書から請求日、取引先名や振込先などを抽出するバクラクのAI-OCR機能もこの技術が使われています。この分野は、古くはBi-LSTMとCRF(Conditional Random Field)を組み合わせたような手法が使われていましたが、前述したLayoutLM[3]が登場してから既存のベンチマークが大きく改善され、企業でのユースケースも多いことから研究が盛んに行われています。例えば、Donut[4]のようなOCRが無くても画像からのみで情報抽出ができるモデルや、事前学習タスクを改善したERNIE-Layout[8]、多言語に対応したLiLT[9]やLayoutXLM[10]といった手法などが提案されています。最近の学会でもUDOP[12]というモデルがSoTAを達成したと報告されています。また、StrucTexT[14]などの論文ではただ単にtextにラベル付をするのではなく、Entitiy Linkingという考え方でKey-Valueペアを抽出するというタスクを解いています。

StruncText内で分類されているDocument Parsingのタスクの例[14]

Table detection, extraction, and table structure recognition

既存のOCRツールは、テーブルデータに対しては適切に動作しないため、テーブル検出、テーブル抽出、テーブル構造認識などのテーブル認識に関する新しい手法が登場しています。例えば、Table detectionではテーブルがどこにあるかを検出し、Table extractionでは検出されたテーブルから更に行や列、セル、ヘッダーなどの構造化された表現を抽出などを行い、文書から表形式のデータを抽出するようなことが可能となっています。裏で使われている技術は、基本的にObject Detectionを利用しているものが多く、Table Transformer[4]というモデルが提案された論文では、まずはテーブルを検出するモデルと、検出されたテーブルから行・列・セルなどを識別するモデルの二つが別々に構築されています。Table Transformerでは、DETRと呼ばれる一般的なTransformerを用いた物体検出手法が用いられています。

Table Transformerで用いられるサブタスクの例 [11]

Document question answering (DocVQA)

最後に、DocVQAというタスクについて紹介します。これは画像に対しての質問を投げてそれに対しての答えを推論するというタスクです。最近だとGPT-4などのマルチモーダルなモデルで画像に対して質疑応答ができるようになるという話もありますが、少し前までは上述したLayout AnalysisやOCRなどをした結果を用いて答えを生成するという方法が主流でした。最近になり、LayoutLMv3[7]やDonut[4]などのモデルが登場したことによってEnd-to-Endでの推論が可能になっています。しかし、LLMを使う際などにも問題になりますが、DocVQAのモデルを使う際にもハルシネーションが発生することに注意が必要です。また、E2Eな手法はなぜそのような推論をしたのかといったエラー分析をしづらくなる部分もあるので、実際にプロダクトに使う際にはメリットデメリットを踏まえた上でのモデル選択が重要です。

DocVQAの例[13]

OSSやクラウドサービス

ここまで紹介してきたいくつかのモデルはモデルの重みやコードが公開されているものも多くあるので、とりあえず試すことは可能です。 ただし、実際に業務に使う際にはライセンスには注意が必要です。例えば、Hugging Faceに登録されているモデルは以下のようなものがあります。

モデル ライセンス
Donut MIT
LayoutLM MIT
LayoutXLM CC BY-NC-SA 4.0
LayoutLMv2 CC BY-NC-SA 4.0
LayoutLMv3 CC BY-NC-SA 4.0
DiT CC BY-NC-SA 4.0
TrOCR MIT
Table Transformer MIT
LiLT MIT

例えば、v2以降のLayoutLMの重みは商用利用不可なので、いざプロダクトに使おうとすると自分達のデータで事前学習を行う必要があります。ただし、このようなマルチモーダルなモデルは大量の文書が必要となる場合が多く、実際LayoutLMv3では110万枚の文書で事前学習を行っており、多くのリソースと時間が必要になることは留意しなければいけません。過去に弊社でも事前学習を試した記事もありますので、そちらも興味あればご参照ください。

tech.layerx.co.jp

また、日本語に対応しているかも注意が必要です。Table Transformerなどのテーブル検出モデルはそこまで言語に依存しないかもしれませんが、テキスト情報を使うモデルの場合は、tokenizerがそもそも日本語に対応していない場合もあるので、日本語に適用する場合は言語対応もチェックが必要です。

もう一つの選択肢として、クラウドサービスを活用するという方法も考えられます。 以下の表のように、各社がOCRやテーブル検出など、様々なサービスを行なっており日本語対応も進んでいます。 なので、自社データが事前学習するほどなかったり、まずはスモールスタートしたい場合はこのようなサービスを使うのも選択肢に入ってくるでしょう。

クラウド サービス名 URL
GCP Document AI https://cloud.google.com/document-ai?hl=ja
AWS Amazon Comprehend https://aws.amazon.com/jp/comprehend/
Azure Document Inteligence https://azure.microsoft.com/en-us/products/ai-services/ai-document-intelligence

LayerXにおける可能性

ここまで、Document AIで実現できる技術がどういうものかという話を続けてきましたが、我々が行なっているバクラク事業にはどのような活かし方があるでしょうか。

AI-OCR機能の改善

まずは、Document ParsingにおけるAI-OCR機能の単純な改善や拡張が考えられます。現在、MLチームではバクラク請求書などのサービスで、取引先名や支払い期日、支払い金額、振込先などを検出して自動的にフォームに入力するAI-OCR機能を提供しています 。しかし、現状では一部の書類種別や項目に対してはルールベースに頼っている部分もあり、請求書以外の書類にもMLモデルを適用していく必要があります。また、過去にLayoutLMの事前学習を試した際には数十万件ほどしかデータがなかったのですが、現状はデータが十分に溜まってきているため再度マルチモーダルなモデルも試すことも精度改善のために重要と考えています。

speakerdeck.com

明細OCR

現状は、上述の通り最低限の項目のみを読み取っていますが、Layout AnalysisやTable Detectionといった技術を使って、文書から明細単位で項目名と金額を抽出することが可能になります。これにより、単純な表データとして出力できるだけでも多くのお客様にとって価値がある機能となるのですが、このようなデータが溜まってくると更に価値が引き出されてきます。例えば、Entity Linkingなどでどのような項目がどのような金額で購入されているかといったデータを取得できると、そのような値を特徴量としてどのような勘定項目が選択されやすいのかといった推薦モデルを作成するということも可能になります。実際、一つの請求書で複数の仕訳を行うお客様も多いので、このような機能も重要になります。また、勘定科目だけでなく、税率毎の金額抽出なども可能になったりと夢が広がります。

その他

もちろん文書から自動的に構造化データを抽出するというAI-OCRや明細OCRといった機能も重要なのですが、お客さまに入力していただいたデータを活用するということも(Document AIの枠組みからは外れてしまうかもですが)重要です。例えば、MLチームでは証憑マッチングという機能をリリースしており、経費精算で提出された領収書のOCR結果と法人カードで決済された明細を自動的に紐づけることで、従業員の経費精算業務と経理の方の証憑回収・紐付け業務をバクラクにしています。これも過去に紐付けられた経費精算データと法人カードデータを活用した技術になっています。興味のある方はこのリンクから体験してみてください。

note.com

他にも、経費精算をする際にどのような内訳 (接待交際費や図書費など)で申請をすればいいかは各社各々のルールがあり、特に初めて申請する従業員の方だと手間取ってしまう部分になりますが、この部分でも過去の他の従業員の方のデータを活用することで、こういう領収書であればこのような内訳を選択されることが多いということを教えてあげることが可能になります。

海外の企業では、企業の支出データから契約に関する価格のベンチマークを企業に提示したりと、企業のお金の節約といった部分でのデータ活用が進んできています[15]。

このように、バクラクに蓄積されているデータとDocument AI、それに加えて幾つかの機械学習技術を用いると、様々な顧客課題を解決できる部分が多く見えてきます。実際に見えているペインをデータと技術を用いて解決できるのは非常に面白い環境と私自身も感じています。

最後に

一緒に機械学習を活用して、バクラクに蓄積されているデータの価値を最大化する仲間を募集しております! 是非、少しでも興味を持っていただけた方はお話ししましょう!!

jobs.layerx.co.jp jobs.layerx.co.jp

参考文献