LoginSignup
0
2

AI-102 HandsOn Azure AI Document Intelligenceを勉強する

Last updated at Posted at 2024-04-17

AI-102の試験のため、以下のGitHubのHandsOnの勉強を実施します。

https://github.com/MicrosoftLearning/mslearn-ai-services
https://github.com/MicrosoftLearning/mslearn-ai-vision
https://github.com/MicrosoftLearning/mslearn-ai-language
https://github.com/MicrosoftLearning/mslearn-ai-document-intelligence ← 本記事はこれ
https://github.com/MicrosoftLearning/mslearn-knowledge-mining
https://github.com/MicrosoftLearning/mslearn-openai

MSLearnのドキュメントはこちら。
 
Azure AI Document Intelligence ソリューションを計画する

AI Visionとの違い

Azure AI は画像分析も提供している、文字を抜き出すだけの単純なものならOCRの方がよい。

テキストを抽出するだけで、コンテキスト情報が必要ない場合は、Azure AI Vision OCR サービスを検討するのが適切です。
Azure AI Document Intelligence には、より洗練されたドキュメント分析が含まれています。 たとえば、キーと値のペア、テーブル、コンテキスト固有のフィールドを識別できます。

モデルの種類

モデルには種類がある。

  • ドキュメントの分析を抜き出したい → Document Analysis
  • よくある形式のデータから情報をキーバリュー形式で抜き出したい → 事前構築済みモデル
  • 固有のフォーマットのファイルから情報を抜き出したい → カスタムモデル

Document analysis

OCR機能を利用。

Read

一番単純、ドキュメントから単語と行を抜き出す。

Layout ... 構造化されたデータ

フォームからテキスト、テーブル、表等の情報を抽出する。

General Documents

一般的なドキュメントからキーバリューを抜き出す。

事前構築済みモデル

  • 請求書

  • 領収書

  • 名刺
    等に対して以下を実施。
     

  • テキストの抽出

  • キーと値のペア抽出

  • エンティティ、種類としては、人、場所、日付など

  • 選択マーク、 ラジオ ボタンやチェック ボックスなど

  • テーブル、フォームのテーブルを抽出

  • フィールド

image.png

カスタムモデル

固有のフォームに対しての分析、抽出。
フォームの書式が若干揺れがある場合、複数のパターンから自動的に判別させるようなことも可能。

可能性のあるすべての入力の例がトレーニング フォームに含まれるようにします。たとえば、手書き入力と印刷入力の両方を想定している場合は、両方をトレーニングに含めます。

カスタム テンプレート モデル。

比較的単純な一貫性のあるテンプレートに沿ったドキュメントの分析。

カスタム ニューラル モデル。

構造が定義されていないドキュメントの場合ニューラルモデルを利用する。

構成済みモデル

複数のモデルのを1つのEndpointにまとめるような機能。

複数のカスタム モデルで構成されるものです。... ユーザーが構成済みモデルにフォームを送信すると、Document Intelligence はそれを自動的に分類し、その分析においてどのカスタム モデルを使用するべきかを決定します。

HandsOn

事前構築済みモデルを使う

Read

image.png

Document Intelligenct Dashboardを開くと以下の様にドキュメントをドラッグドロップして分析できる。
image.png

Jsonはこんな感じで返ってくる。
analyzeResult.contentに抽出された文章が入る。パラグラフごとの抽出とかも可能ぽい。

すごいのはpages > wordsの中に一つ一つの単語に対して画像の位置をpolygonとしてもっていること。これのせいでデータ量が半端なく多くなっている。

{
	"status": "succeeded",
	"createdDateTime": "2024-04-17T04:40:10Z",
	"lastUpdatedDateTime": "2024-04-17T04:40:12Z",
	"analyzeResult": {
		"apiVersion": "2023-07-31",
		"modelId": "prebuilt-read",
		"stringIndexType": "utf16CodeUnit",
       "content": "ここにデータ本文が入る",
		"pages": [
			{
				"pageNumber": 1,
				"angle": 0,
				"width": 458,
				"height": 595,
				"unit": "pixel",
				"words": [
					{
						"content": "While",
						"polygon": [
							129,
							27,
							153,
							27,
							153,
							39,
							129,
							39
						],
						"confidence": 0.98,
						"span": {
							"offset": 0,
							"length": 5
						}
					},
                    // これが延々と続く
		],
				"spans": [
					{
						"offset": 0,
						"length": 4682
					}
				]
			}
		],
		"styles": [
			{
				"confidence": 0.1,
				"spans": [
					{
						"offset": 4588,
						"length": 28
					}
				],
				"isHandwritten": true
			}
		]
	}
}

カスタムモデル

いわゆる教師あり機械学習。
トレーニング用サンプルは最低限5,6個必要。Storage Accountにアップし、読み込ませる。

トレーニング

スタジオからCustom Extraction Modelを選択。
image.png

以降はStorage Accountにjpgファイルのトレーニングデータを配置している前提。
image.png

Storage Accountをひもづける。(この辺キーとか何もないけど裏の認証どうなっているんだろう?)
image.png

フィールドを追加して、手動でマッピングしていく。
image.png

表やサイン、チェックボックスをラベリングする専用の機能もある。
image.png

表形式は固定、動的を選べる。
image.png

image.png

ある程度一般的な形式であれば自動的にラベリングする機能もある。
image.png

トレーニングはTemplateとNeuralを選べる。
image.png

トレーニングが完了するとStorage Accountにトレーニングするために必要な情報がファイルとして出力されている。(ちなみにこれらのファイルを別環境に持っていき、再度トレーニングをするだけで、環境を再現できるのでラベリング作業を繰り返す手間が省ける。)

image.png

この画像のLayoutとかFieldとかがStorage Accountに保存される。
image.png

  • fields.json → ラベル情報(これは全体で1つ)
{
    "fields": [
        {
            "fieldKey": "Merchant",
            "fieldType": "string",
            "fieldFormat": "not-specified"
        },
        {
            "fieldKey": "PhoneNumber",
            "fieldType": "string",
            "fieldFormat": "not-specified"
        },
  • {ファイル名}.jpg.labels.json → 手動でラベリングした結果(座標とか)が入っている
{
    "document": "Form_1.jpg",
    "labels": [
        {
            "label": "Merchant",
            "key": null,
            "value": [
                {
                    "page": 1,
                    "text": "Hero",
                    "boundingBoxes": [
                        [
                            0.3658823529411765,
                            0.09409090909090909,
                            0.46352941176470586,
                            0.09272727272727273,
                            0.46294117647058824,
                            0.12090909090909091,
                            0.3652941176470588,
                            0.12090909090909091
                        ]
                    ]
                },
  • Form_1.jpg.ocr.json → 実際にトレーニングで読み取れた値かな?

モデルの確認

トレーニングが完了するとモデルができる。
image.png

テスト

Responseは通常のDocument Analysisと似ているが、analyzeResultにModelIDやConfidenceが入るようになる。

{
	"status": "succeeded",
	"createdDateTime": "2023-10-18T23:39:50Z",
	"lastUpdatedDateTime": "2023-10-18T23:39:54Z",
	"analyzeResult": {
		"apiVersion": "2022-08-31",
		"modelId": "DocIntelModel",
		"stringIndexType": "utf16CodeUnit",
		"content": "本文",
		"pages": [
			{
				"pageNumber": 1,
				"angle": 0,
				"width": 1159,
				"height": 1486,
				"unit": "pixel",
				"words": [
					{
						"content": "Purchase",
						"polygon": [
							89,
							90,
							174,
							91,
							174,
							112,
							88,
							112
						],
						"confidence": 0.996,
						"span": {
							"offset": 0,
							"length": 8
						}
					},
                    ...

複合モデル

例えばある調査でフォームの形式が複数から選べて、読み取りにカスタムモデルを複数作った場合、どのモデルが最適かを自動的に選択させることができる。

通常はどのモデルを利用するかを以下の様にModelIDで明示的に定義する。

string modelId = "<modelId>";
Uri fileUri = new Uri("<fileUri>");
AnalyzeDocumentOperation operation = 
    await client.StartAnalyzeDocumentFromUriAsync(modelId, fileUri);

複合モデルを作ってみる。
GUIからやる場合はもう一つ同じようなProjectを作成する。
モデルを2つ選択してComposeをクリック。
image.png

たったこれで普通に複合モデルができた。
image.png

ちゃんと調べられていないが、このやりかただと、Taxや保険証等のPredefined Modelは複合モデルに入れることはできないみたい?

構成済みモデルはコードで開発することもできる。

// モデルのリストを渡す
List<string> modelIds = new List<string>()
{
    firstCustomModel.ModelId,
    secondCustomModel.ModelId,
    thirdCustomModel.ModelId,
};

BuildModelOperation operation = await client.StartCreateComposedModelAsync(modelIds, modelDescription: "Composed model example");
Response<DocumentModel> operationResponse = await operation.WaitForCompletionAsync();

構成済みモデル専用のモデルIDができるので、普通のモデルを呼ぶのと同じ方法で呼び出せる。

// 複合モデルの場合、doctypeにどのモデルを使ったががコロン区切りで出ている。
		"documents": [
			{
				"docType": "composedmodel:testmodel",
				"boundingRegions": [
					{
						"pageNumber": 1,
						"polygon": [
							0,
							0,
							8.5,
							0,
							8.5,
							11,
							0,
							11
						]
					},

裏はどういうロジックになっているのかはもう少し後で調べる。

Azure AI SearchとDocument Intelligenctの統合

Skillsetを使う。

AI SearchのSkillsetについては以前以下で書いたので詳しくはそちらで。

基本的にはAzure Functionを経由して、Storage AccountのファイルデータをDocuement IntelligenceのModelに対して投げて、Azure AI SearchのIndexをEnrichする感じになる。

要注意?Storage Accountのセキュリティ設定について

Storage Accountに事前にCORSを設定しろという情報も見かけたが、実際には自動的に追加されていた。
image.png

また、ContainerもPrivateのままでもいけた。この辺Azure OpenAIのOn Your DataとかだとPrivate Containerだとエラーになる。Document IntelligenceはStorage Accountにどうやってアクセスしているのだろう?
image.png

Document IntelligenceではManaged IDはOffのままで、Storage Account側でRBAC設定されている形跡もない。Document Intelligence Studio側でもStorage Account設定時にキーを入力する箇所はなく、設定を見てもキーやSASTokenを保持しているような箇所はない。。。

、、、と思ったら何気なしにStorage AccountのPrimary KeyをRotateしてみたらDocument Intelligence Studio側で認証エラーになった。どうやらStudioの裏でキーを実は保持しているらしい。再トレーニングもできなくなった。

image.png

これは面倒だ。StudioからはStorage Accountのキーを設定しなおすこともできないぽい。
Storage Accountのキーを変更したら、新しくDocument Intelligence Studio側でProjectを作り直すしかないんだろうか。モデル名やEndpointが変わるとすると中々影響が大きい気がする。

Azure AIのサービスは他にもLanguage StudioとかいろんなStudioがあるけど、やることは大体同じで、テストデータアップロード、トレーニング、モデル作成、テスト、Endpointの管理等大体似た作りになっている。
ただStorage Accountへの接続の管理はどうも一貫していないようだ?

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
2