Amazon のインテリジェント ドキュメント処理 (IDP) は、ビジネス上の意思決定サイクルをスピードアップし、コストを削減するのに役立ちます。 複数の業界で、顧客はビジネスの過程で年間数百万のドキュメントを処理する必要があります。 何百万ものドキュメントを処理する顧客にとって、これはエンド ユーザー エクスペリエンスにとって重要な側面であり、デジタル トランスフォーメーションの最優先事項です。 さまざまな形式があるため、ほとんどの企業は、W2、請求、ID ドキュメント、請求書、法的契約などのドキュメントを手動で処理するか、時間がかかり、エラーが発生しやすく、コストのかかる従来の OCR (光学式文字認識) ソリューションを使用しています。 AWS AI サービスを使用した IDP パイプラインにより、OCR を超えて、より正確で用途の広い情報を抽出し、ドキュメントをより迅速に処理し、コストを節約し、リソースをより価値の高いタスクにシフトできます。

このシリーズでは、IDP パイプラインの概要を説明して、ドキュメントを取り込み、重要な情報をダウンストリーム システムに取得するのにかかる時間と労力を削減します。 次の図は、通常 IDP ワークフローの一部であるステージを示しています。

この XNUMX 部構成のシリーズでは、AWS AI サービスを使用してドキュメントを大規模に自動化し、インテリジェントに処理する方法について説明します。 の 一部1では、IDP ワークフローの最初の XNUMX つのフェーズについて説明しました。 この投稿では、残りのワークフロー フェーズについて説明します。

ソリューションの概要

次の参照アーキテクチャは、次のような AWS AI サービスを使用する方法を示しています アマゾンテキストラック & Amazon Comprehend、他の AWS サービスと一緒に IDP ワークフローを実装します。 パート 1 では、銀行取引明細書、請求書、領収書などのドキュメントを分類してタグ付けする、データ キャプチャとドキュメント分類の段階について説明しました。 また、ドキュメントから意味のあるビジネス情報を抽出できる抽出段階についても説明しました。 この投稿では、抽出フェーズで Amazon Comprehend のデフォルト エンティティとカスタム エンティティを調べて IDP パイプラインを拡張し、ドキュメントの強化を実行し、 Amazon拡張AI (Amazon A2I) レビューおよび検証段階に人間のレビュー要員を含める。

私達はまた使用します アマゾンコンプリヘンドメディカル このソリューションの一部として、構造化されていない医療テキストから情報を正確かつ迅速に抽出し、抽出された健康情報間の関係を特定し、ICD-10-CM、RxNorm、SNOMED CT などの医療オントロジーにリンクするサービスです。

Amazon A2I は、人間によるレビューに必要なワークフローの構築を容易にする機械学習 (ML) サービスです。 Amazon A2I はすべての開発者に人間によるレビューをもたらし、AWS で実行されているかどうかに関係なく、人間によるレビュー システムの構築や多数の人間によるレビュー担当者の管理に関連する差別化されていない重労働を取り除きます。 Amazon A2I との統合 アマゾンテキストラック & Amazon Comprehend IDP ワークフロー内に人によるレビュー手順を導入する機能を提供します。

前提条件

始める前に、以下を参照してください。 一部1 IDP の概要と、データのキャプチャ、分類、および抽出の段階に関する詳細については、 を参照してください。

抽出段階

このシリーズのパート 1 では、Amazon Textract の機能を使用して、あらゆるタイプのドキュメントから正確なデータを抽出する方法について説明しました。 このフェーズを拡張するために、Amazon Comprehend の事前トレーニング済みエンティティと Amazon Comprehend カスタム エンティティ レコグナイザーを使用して、さらにドキュメントを抽出します。 カスタム エンティティ レコグナイザーの目的は、特定のエンティティを識別し、ドキュメントに関するカスタム メタデータを CSV または人間が判読できる形式で生成し、後でビジネス ユーザーが分析できるようにすることです。

名前付きエンティティの認識

Named Entity Recognition (NER) は自然言語処理 (NLP) のサブタスクであり、テキスト データをふるいにかけて名前付きエンティティと呼ばれる名詞句を見つけ、それぞれをブランド、日付、イベント、場所、組織などのラベルで分類します。 、人、数量、またはタイトル。 たとえば、「最近 Amazon プライムに登録しました」という文では、Amazon プライムは名前付きエンティティであり、ブランドとして分類できます。

Amazon Comprehend を使用すると、ドキュメント内のそのようなカスタム エンティティを検出できます。 各エンティティには、エンティティ タイプごとに Amazon Comprehend が返す信頼レベル スコアもあります。 次の図は、エンティティ認識プロセスを示しています。

テキスト ドキュメントからエンティティを取得するには、 comprehend.detect_entities() メソッドを開き、言語コードとテキストを入力パラメーターとして構成します。

def get_entities(text):
    try:
        #detect entities
        entities = comprehend.detect_entities(LanguageCode="en", Text=text)  
        df = pd.DataFrame(entities["Entities"], columns = ['Text', 'Type'])
        display(HTML(df.to_html(index=False)))
    except Exception as e:
        print(e)

実行します get_entities() メソッドを銀行ドキュメントで実行し、結果のエンティティ リストを取得します。

エンティティ抽出は、銀行ドキュメント内のすべてのデフォルトのエンティティ タイプを識別するのにかなりうまく機能しましたが、ユース ケースでは特定のエンティティを認識したいと考えています。 具体的には、銀行取引明細書で顧客の普通預金口座と当座預金口座の番号を特定する必要があります。 Amazon Comprehend カスタムエンティティ認識を使用して、これらの主要なビジネス用語を抽出できます。

AmazonComprehendカスタムエンティティ認識モデルをトレーニングする

顧客の銀行取引明細書から関心のある特定のエンティティを検出するために、次の XNUMX つのカスタム エンティティを使用してカスタム エンティティ レコグナイザーをトレーニングします。 SAVINGS_AC & CHECKING_AC.

次に、カスタム エンティティ認識モデルをトレーニングします。 Amazon Comprehend にデータを提供するには、アノテーションまたはエンティティ リストの XNUMX つの方法のいずれかを選択できます。

注釈メソッドは、ドキュメントと共に注釈としてより正確なコンテキストを送信することでモデルをトレーニングするため、画像ファイル、PDF、または Word ドキュメントのより洗練された結果につながることがよくあります。 ただし、注釈メソッドは時間がかかり、作業が集中する可能性があります。 このブログ投稿を簡単にするために、プレーン テキスト ドキュメントにのみ使用できるエンティティ リスト メソッドを使用します。 このメソッドは、前の例に示すように、プレーン テキストとそれに対応するエンティティ タイプを含む CSV ファイルを提供します。 このファイル内のエンティティは、ビジネス ニーズ (普通預金口座番号と当座預金口座番号) に固有のものになります。

注釈またはエンティティ リスト メソッドを使用してさまざまなユース ケースのトレーニング データを準備する方法の詳細については、次を参照してください。 トレーニングデータの準備.

次のスクリーンショットは、エンティティ リストの例を示しています。

Amazon Comprehend カスタム NER リアルタイム エンドポイントを作成する

次に、トレーニングしたモデルを使用してカスタム エンティティ認識リアルタイム エンドポイントを作成します。 私たちは、 エンドポイントの作成 経由のAPI comprehend.create_endpoint() リアルタイム エンドポイントを作成するメソッド:

#create comprehend endpoint
model_arn = entity_recognizer_arn
ep_name = 'idp-er-endpoint'

try:
    endpoint_response = comprehend.create_endpoint(
        EndpointName=ep_name,
        ModelArn=model_arn,
        DesiredInferenceUnits=1,    
        DataAccessRoleArn=role
    )
    ER_ENDPOINT_ARN=endpoint_response['EndpointArn']
    print(f'Endpoint created with ARN: {ER_ENDPOINT_ARN}')
    %store ER_ENDPOINT_ARN
except Exception as error:
    if error.response['Error']['Code'] == 'ResourceInUseException':
        print(f'An endpoint with the name "{ep_name}" already exists.')
        ER_ENDPOINT_ARN = f'arn:aws:comprehend:{region}:{account_id}:entity-recognizer-endpoint/{ep_name}'
        print(f'The classifier endpoint ARN is: "{ER_ENDPOINT_ARN}"')
        %store ER_ENDPOINT_ARN
    else:
        print(error)

カスタム エンティティ レコグナイザーをトレーニングした後、カスタム リアルタイム エンドポイントを使用してドキュメントから強化された情報を抽出し、Amazon Comprehend によって認識されるカスタム エンティティと Amazon Textract からのバウンディング ボックス情報を利用してドキュメントのリダクションを実行します。

濃縮段階

ドキュメント エンリッチメント ステージでは、個人を特定できる情報 (PII) データの編集、カスタム ビジネス用語の抽出などにより、ドキュメント エンリッチメントを実行できます。 前のサンプル ドキュメント (銀行取引明細書) には、編集したい顧客の普通預金口座番号と当座預金口座番号が含まれています。 これらのカスタム エンティティは Amazon Comprehend カスタム NER モデルによって既にわかっているため、Amazon Textract ジオメトリ データ型を使用して、これらの PII エンティティがドキュメントに表示される場所であればどこでも簡単に編集できます。 次のアーキテクチャでは、銀行取引明細書ドキュメントから主要なビジネス用語 (普通預金口座と当座預金口座) を編集します。

次の例でわかるように、現在、当座預金口座と普通預金口座の番号は銀行取引明細書に隠されています。

従来の OCR ソリューションでは、ほとんどの非構造化ドキュメントや半構造化ドキュメントからデータを正確に抽出するのに苦労していました。これは、これらのドキュメントの複数のバージョンやフォーマット間でデータがどのように配置されるかが大きく異なるためです。 その後、カスタムの前処理ロジックを実装するか、これらのドキュメントから情報を手動で抽出する必要がある場合があります。 この場合、IDP パイプラインは、Amazon Comprehend カスタム NER と Amazon Textract クエリという XNUMX つの機能をサポートしています。 これらのサービスはどちらも NLP を使用して、ドキュメントのコンテンツに関する洞察を抽出します。

Amazon Textract クエリによる抽出

Amazon Textract でドキュメントを処理する場合、新しいクエリ機能を分析に追加して、必要な情報を指定できます。 これには、「顧客の社会保障番号は?」などの NLP 質問を渡すことが含まれます。 Amazon Textract に。 Amazon Textract は、その質問に対するドキュメント内の情報を見つけ、ドキュメントの残りの情報とは別の応答構造で返します。 クエリは単独で処理することも、他のクエリと組み合わせて処理することもできます FeatureType、 といった Tables or Forms.

Amazon Textract クエリを使用すると、データがフォーム、テーブル、チェックボックスなどのドキュメント構造にどのように配置されているか、またはドキュメント内のネストされたセクションに格納されているかに関係なく、高精度で情報を抽出できます。

クエリ機能を実証するために、COVID-19 ワクチン接種カードなどのドキュメントから、患者の姓名、投与量メーカーなどの貴重な情報を抽出します。

私たちは、使用 textract.analyze_document() 関数を指定し、 FeatureType as QUERIES クエリを自然言語の質問の形式で追加するだけでなく、 QueriesConfig.

次のコードは、簡略化のために削除されています。 完全なコードについては、GitHub を参照してください サンプルコード for analyze_document().

response = None
with open(image_filename, 'rb') as document:
    imageBytes = bytearray(document.read())

# Call Textract
response = textract.analyze_document(
    Document={'Bytes': imageBytes},
    FeatureTypes=["QUERIES"],
    QueriesConfig={
            "Queries": [{
                "Text": "What is the date for the 1st dose covid-19?",
                "Alias": "COVID_VACCINATION_FIRST_DOSE_DATE"
            },
# code trimmed down for simplification
#..
]
}) 

クエリ機能については、 textract.analyze_document() 関数は、すべての OCR WORDS と LINES、ジオメトリ情報、および信頼スコアを応答 JSON で出力します。 ただし、照会した情報を印刷することはできます。

Document API からの JSON 応答を解析するために使用されるラッパー関数です。 高レベルの抽象化を提供し、API 出力を反復可能にし、情報を簡単に取得できるようにします。 詳細については、 Textract 応答パーサー & テキストトラクター GitHub リポジトリ。 応答を処理した後、スクリーンショットに示すように次の情報を取得します。

import trp.trp2 as t2
from tabulate import tabulate

d = t2.TDocumentSchema().load(response)
page = d.pages[0]

query_answers = d.get_query_answers(page=page)

print(tabulate(query_answers, tablefmt="github"))

レビューと検証フェーズ

これは、IDP パイプラインの最終段階です。 この段階では、ビジネス ルールを使用してドキュメントの完全性を確認できます。 たとえば、保険金請求ドキュメントから、請求 ID が正確かつ正常に抽出されます。 次のような AWS サーバーレス技術を使用できます。 AWSラムダ これらのビジネス ルールをさらに自動化します。 さらに、予測が正確であることを確認するために、文書レビューのために人間の労働力を含めることができます。 Amazon A2I は、ML 予測の人間によるレビューに必要なワークフローの構築を加速します。

Amazon A2I を使用すると、モデルが信頼性の高い予測を行うことができない場合や、その予測を継続的に監査できない場合に、人間のレビュー担当者が介入できるようになります。 IDP パイプラインの目標は、正確な情報を意思決定システムに取り込むために必要な人的入力の量を減らすことです。 IDP を使用すると、ドキュメント プロセスに対する人的入力の量と、ドキュメント処理の総コストを削減できます。

ドキュメントから正確な情報をすべて抽出したら、Lambda 関数を使用してビジネス固有のルールをさらに追加し、最終的にソリューションをダウンストリーム データベースまたはアプリケーションと統合できます。

Amazon A2I ワークフローの作成方法の詳細については、 モジュール 4 の準備 最後のステップ 03-idp-document-enrichment.ipynb 私たちの中で GitHubレポ.

クリーンアップ

今後 AWS アカウントに料金が発生しないようにするには、リポジトリのセットアップでプロビジョニングしたリソースを削除します。 クリーンアップセクション 私たちのレポで。

まとめ

この 2 部構成の投稿では、ML の経験がほとんどまたはまったくなくても、エンドツーエンドの IDP パイプラインを構築する方法を見てきました。 パイプラインのさまざまな段階と、業界固有のユースケースを設計および構築するための Amazon Textract、Amazon Comprehend、Amazon Comprehend Medical、Amazon AXNUMXI などの AWS AI サービスを使用した実践的なソリューションについて説明しました。 の中に 最初の投稿 このシリーズでは、Amazon Textract と Amazon Comprehend を使用してさまざまなドキュメントから情報を抽出する方法を示しました。 この投稿では、Amazon Comprehend カスタム エンティティ認識エンジンをトレーニングして、ドキュメントからカスタム エンティティを抽出する方法について詳しく説明しました。 また、Amazon Textract や Amazon Comprehend のエンティティ リストを使用したリダクションなどのドキュメント エンリッチメント手法も実行しました。 最後に、プライベート作業チームを含めることで、Amazon Textract の Amazon A2I ヒューマン レビュー ワークフローを使用する方法について説明しました。

この投稿の完全なコード サンプルの詳細については、 GitHubレポ.

のセキュリティ セクションを確認することをお勧めします。 アマゾンテキストラック, Amazon Comprehend, アマゾンA2I ドキュメンテーションを参照し、提供されたガイドラインに従ってください。 また、価格を確認して理解するために少し時間を取ってください アマゾンテキストラック, Amazon Comprehend, アマゾンA2I.

著者について

チン・レーン アマゾン ウェブ サービスの AI/ML スペシャリスト ソリューション アーキテクトです。 彼女は応用数学と機械学習に情熱を注いでいます。 彼女は、AWS の顧客向けのインテリジェントなドキュメント処理ソリューションの設計に重点を置いています。 仕事以外では、サルサとバチャータ ダンスを楽しんでいます。

ソナリ・サフ アマゾン ウェブ サービスのインテリジェント ドキュメント処理 AI/ML ソリューション アーキテクト チームを率いています。 彼女は情熱的な技術愛好家であり、イノベーションを使用して複雑な問題を解決するために顧客と協力することを楽しんでいます。 彼女が重点的に取り組んでいる分野は、インテリジェントなドキュメント処理のための人工知能と機械学習です。

アンジャンビスワス AI/ML スペシャリストのシニア ソリューション アーキテクトです。 Anjan は企業のお客様と協力しており、AI/ML、データ分析、ビッグデータ ソリューションの開発、展開、説明に情熱を注いでいます。 Anjan は、グローバルなサプライ チェーン、製造、および小売組織で 14 年以上の経験があり、お客様が AWS を開始してスケールするのを積極的に支援しています。

スプラカシュ・ダッタ アマゾン ウェブ サービスのソリューション アーキテクトです。 彼は、デジタル トランスフォーメーション戦略、アプリケーションのモダナイゼーションと移行、データ分析、機械学習に重点を置いています。 彼は AWS の AI/ML コミュニティの一員であり、インテリジェントなドキュメント処理ソリューションを設計しています。