de:code 2019 [AI06] OCR 案件で Azure Computer Vision と他社サービス含めて徹底検証してみた

Microsoft de:code 2019に参加した内容を紹介します。

もし間違いなどあれば、ご指摘いただけますと助かります。

# [AI06] OCR 案件で Azure Computer Vision と他社サービス含めて徹底検証してみた / 2019年5月29日

# TL;DR（要約）

- 図面管理システムとしての検索に利用。テキストはOCRとして、AI-OCRでキーワード抽出し、図面部分は、画像判別して特徴量を抽出した。
- 「テキスト認識モデルを使用して、画像内のテキストらしきものを検出し」というのが、AI-OCRの特徴となる。
- 認識精度、サービスのプライバシー問題を考慮し、AI-OCRとして、Tesseract-OCRを選択した。

# リソース

- [セッション詳細](https://www.microsoft.com/ja-jp/events/decode/2019session/detail.aspx?sid=AI06&kw=AI06)

# セッションの目的

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/487b11f7-3f45-368b-ee1c-c44f1557b2a4.png)

- 適切なツールを選べるようになる

# 同じ図面を何度も検索したくない！

- 業務上で図面を検索することがあるが、何度も同じ図面を検索したくない！
- この仕様は、以前やったことがあるのではないか

という課題が頻出したため、解決策を探すことになった

# 図面管理システムを導入しよう！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/24142bcf-4f84-b426-123e-52b328967865.png)

ということで、図面管理システムを導入してみた。

## 検索の問題は解決しなかった。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/1be23b9e-34f2-312e-ea71-28f56db8f0cd.png)

確かに図面を管理することができるが、結局検索タグを設定するのが手作業であるため、人によってつけるタグがバラバラになる。

特に、特注品だとタグが属人的になってしまう。

タグ名がバラバラだと検索できなくて、図面検索の効率化にはつながらなかった。

## AIで解決できないか？

そもそもどうやればよいのかということを検証していった。

AIをどのように適用すれば図面検索ができるのか。クラウドが提供しているAIの中に、都合がいい機能がそもそも存在するのか。

# 事例による説明

## 事例内容

### 課題

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/0aa753e2-1f25-4629-fef7-5135454e8d89.png)

過去に、同じような部品使用を製造したかの検索に時間がかかり、見つからずに新規に図面作成している現状。
過去10年分の図面データを有効活用できていない。

### アプローチ

Aを活用した類似図面検索システムを作ろう！

## システム概要

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/6bd286b8-cd3e-ba08-edfe-3a75eb18d5bc.png)

1. 一つの書類の中からテキストと図面部分を抽出する
2. テキスト部分と図面部分について抜き出す
3. テキストはOCRとして、AI-OCRで**キーワード**抽出
4. 図面部分は、画像判別して**特徴量**を抽出
5. 抜き出したキーワードと特徴量から、自動タグ付けする

自動タグづけすることで属人性が解除され、検索しやすいシステムとなる

## AI-OCRとはなにか？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/87601871-9161-be40-4e60-ca355b81ebf9.png)

**テキスト認識モデルを使用して、画像内のテキストらしきものを検出し**、どの文字若しくは英数字に当てはまるかを判断した結果を文字データに変換するもの

この「**テキスト認識モデルを使用して、画像内のテキストらしきものを検出し**」というのが、AI-OCRの特徴となる。

### OCRとAI-OCRは何がちがうのか

OCRにはテキスト認識モデルがないので、認識率が下がる傾向がある。

## クラウドでのAI-OCR
### Azureでは？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/68d97892-f26f-a3a5-1abd-15942c034793.png)

#### 画像認識の中の「コンピューター画像（Azure Computer Vision）」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/60c6b8e9-f9d3-9d6a-7c25-9d59d2425001.png)

背景や顔なども認識できる。画像からの文字データの読み取りについては、25か国語に対応している。

### Azure以外では？ 

#### Google

- 言語自動判別があることが、一番の特徴

#### Tesseract-OCR

- オープンソース。Apacheライセンスとなっている。
- バージョン4.0からは、光学文字認識に加え、AIによる認識エンジンも追加された。
- フォントの追加学習も可能（精度向上につながる）

## 機能による比較

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/9f29ce3e-9d9b-b2b8-49d5-fe15a5ca38d4.png)

- 対応言語
    - Googleの対応言語は多い。56か国語
    - Tesseractは、161か国語
- 費用面
    - AzureとGoogleは同等
    - Tesseractは、無償だが、構築、サーバー運用は自分で行う必要がある

## 検証

### データ

データとしては、実際の図面を使用して行った。

## 検証結果

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/50f937e4-8efb-22bf-da03-c2f3a3dc1149.png)

### 認識結果

- Azureは、英数字しか読めなかった。1人負け...

### 考察

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/f2b5dd86-a215-4e6a-5769-6dc0d9755f5c.png)

#### Azureは、なぜダメだったのか

- 自動認識がない
    - ということは、英語＋日本語の混在ができない
- Azureは顧客データの2次利用を行わない
    - プライバシー面では利点となるが、学習が足りていないという面がある
    - Googleはおそらくデータの**2次利用をしている可能性がある**
- 今回のフォントは縦横サイズを変更しているものだった
  - CADの特徴で定型のフォントを使用していないため、ご認識しやすいものだった。

#### GoogleとTesseractは、なぜよかったのか

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/5084a1e9-38ad-c0bf-760b-65a2eea189e6.png)

##### Googleは

Googleは、2次利用をしているのではないか、ということは、業務上での使用は場合のよっては怖い点となる（明記されてはいないが）

## AI-OCRについての結論

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/b6896706-5ff7-b3dd-58dc-0a2795af1fa1.png)

今回の図面が要保護情報であることを考えると、AzureかTesseract
認識精度としては、GoogleかTesseract

結論、**Tesseractを採用する**


## 画像の特徴量検出

### 画像の特徴量をどのようにして抽出するか

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/1b1cab4d-219a-cf56-15dc-70e9d202093a.png)

- 対象の部品と検索の部品がどの程度近いか、ということを比較する
- 例での文字間の線は、どことどこを比較しているのか、ということを表している
- 類似点の距離から、画像の類似度を算出する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/67ed0922-23a9-4270-4104-543dbe147fae.png)


### どのように実装するか

残念ながら、AzureやGoogleにはありません、ということで独自開発を行った。


## 画像の特徴良検出の実装方法

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/144da37a-64ba-b47c-4115-f7990aa9f569.png)

1. OpenCVRのORB特徴量算出機能を使用して、ORB特徴量を算出。ORBを選択した理由は、は処理速度重視
2. 算出した特徴量を比較する。この値が低いと似ている、ということになる。
3. クラスタリングでどのグループに属するのかを算出する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/69c90d1f-8aac-fe23-54e2-651da5c3a284.png)


# AI-OCR実用化のためのポイント

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/0a298303-cb56-5cec-62ab-678e303f875c.png)

## サービスがあれば積極的に採用する

スピード感重視ということが大事である。

## 投げるデータ条件を変えて試す

固定の条件で試すのではなく、サービスに渡すデータ（条件）を変えて格納して試したほうが効率的である

## サービスがなければ独自開発（OSS推奨）

どうしてもサービスがない場合に限り、独自開発する。

その場合でも、ライセンスには注意したうえで、OSSの利用を考慮したほうが良い。完全な独自開発ということを考えてもよいが、ビジネスではスピード感が大事

## 独自開発は目的に合ったチューニング

### 認識精度を上げるために

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/c4035f45-83c7-7124-e3e1-5e27ee78413d.png)

今回は、速度もだが、認識精度を重視している。

#### 前処理を行おう

事前にノイズ除去を行うことで、紙スキャン時の汚れを除く、ということが認識精度向上につながる。実際のデータに応じた色調補正処理が必要になる


#### フォント学習をする

今回採用したTesseractが追加フォント学習が可能であった。JIS第一水準の文字一覧を与えることで、認識率が82%まで向上した。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/aa6fb1ff-239a-0383-4b3f-acd7968153fc.png)


#### 後処理を行う

認識結果について、ルールベースの変換を実施している。
つまり、認識結果が明らかに間違っているものについては、AIではないルールベースでの変換による処理が、有効である。**AIのみに頼らない**ことが大事。

- ルールベースに変換
- 辞書による補正処理


# 最終的な構成

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204150/92f1749a-961e-a981-ec4a-fb0e7e9f64cb.png)

最終的には、各種Azureのサービス（Azure Virtual Machine、Cosmos DB、Web AppsAzure Search）を使用して図面検索を行うシステムを構築している。