Amazon Kendraを使用して保険請求をインテリジェントに処理するために、Amazon Comprehendで作成されたカスタムメタデータを使用します

Amazon Kendraを使って保険請求をインテリジェントに処理！Amazon Comprehendで生成されたカスタムメタデータを活用しよう！

構造化データとは、データベース内の列に格納される情報のような固定パターンに従ったデータであり、非構造化データはテキスト、画像、またはソーシャルメディアの投稿のような特定の形式やパターンを持たないデータです。両方のデータは、さまざまな組織で生産され、消費されることにより、増加し続けます。たとえば、International Data Corporation（IDC）によると、2025年までに世界のデータボリュームは10倍に増加する見込みであり、非構造化データが大部分を占めます。企業は、文書の摂取中にファイルタイプ、作成日時、サイズなどの標準メタデータに加えて、文書タイプ（W-2フォームや給与明細書）や名前、組織、住所などのさまざまなエンティティタイプのカスタムメタデータを追加して、インテリジェントな検索を拡張することがあります。カスタムメタデータは、組織や企業が情報を好みに応じて分類するのに役立ちます。たとえば、メタデータはフィルタリングや検索に使用できます。顧客は、Amazon Comprehendを使用してカスタムメタデータを作成し、文書のコンテンツに関する洞察を抽出するためのAWSが管理する自然言語処理（NLP）サービスであるAmazon Kendraにデータとともにインデックスに組み込むことができます。 Amazon Kendraは、機械学習（AWS）によって強化された高精度で使いやすい企業向け検索サービスです。カスタムメタデータは、さらなるフィルタリングおよびファセット機能の向上のためにコンテンツを豊かにするために使用することができます。 Amazon Kendraでは、ファセットは一連の検索結果のスコープ付きビューです。たとえば、特定の都市と関連付けられているドキュメントで都市ごとにフィルタリングされた検索結果を提供することができます。また、特定の著者による結果を表示するためのファセットも作成できます。

保険会社は、処理する必要がある請求件数が増加しています。さらに、請求処理の複雑さも増しており、それは関与する保険ドキュメントの多様なタイプと各ドキュメントのカスタムエンティティのためです。この記事では、保険会社向けのカスタムコンテンツエンリッチメントの使用事例について説明します。保険会社は、自社のビジネスドメインに固有のカスタムエンティティとクラスに基づいてコンテンツをKendraでフィルタリングしたいと考えています。この記事では、Amazon Comprehendのカスタムモデルを使用してメタデータ生成を自動化および簡素化する方法を説明しています。生成されたメタデータはAmazon KendraのCustom Document Enrichment（CDE）カスタムロジックを使用してインジェスションプロセス中にカスタマイズすることができます。

以下は、Amazon Kendraのフィルタリングおよびファセット機能を使用した検索のいくつかの例です。

以下のスクリーンショットでは、Amazon Kendraが検索結果を提供していますが、任意のフィルタを使用して検索結果をさらに絞り込むオプションはありません。

• 「Protopia AIによる企業LLMアクセラレーションの基盤データの保護」
• 「Amazon SageMakerデータパラレルライブラリを使用して、トレーニングを高速化します」
• エグゼクティブアーキテクトのFinOpsへのアプローチ：AIと自動化がデータ管理を効率化する方法

以下のスクリーンショットでは、さまざまなファセット（Law Firm、Policy Numbers）を使用してAmazon Kendraの検索結果をフィルタリングすることができます。

この記事で説明されているソリューションは、医療、製造、研究など、他のビジネス/ユースケースにも簡単に適用できます。

ソリューション概要

この提案されたソリューションでは、1）保険請求書をさまざまなクラスに分類し、2）それらのドキュメントから保険特定のエンティティを取得します。これが完了すると、ドキュメントは適切な部門またはダウンストリームプロセスにルーティングされます。

以下の図は、提案されたソリューションアーキテクチャを概説しています。

Amazon Comprehend カスタム分類 APIは、定義したカテゴリ（クラス）にドキュメントを整理するために使用されます。カスタム分類は二段階のプロセスです。まず、興味のあるクラスを認識するために、カスタム分類モデル（または分類器とも呼ばれます）をトレーニングします。次に、モデルを使用して任意の数の文書セットを分類します。

Amazon Comprehend カスタムエンティティ認識 機能は、デフォルトで利用可能な一般的なエンティティタイプを超える特定のエンティティタイプ（保険会社名、保険会社名、ポリシー番号など）を識別するために使用されます。カスタムエンティティ認識モデルを構築することは、文字列の一致や正規表現を使用してドキュメントからエンティティを抽出するよりも効果的なアプローチです。カスタムエンティティ認識モデルは、それらの名前が出現する可能性のある文脈を学習することができます。さらに、文字列の一致では、誤字や新しい命名規則に従うエンティティを検出することはできませんが、カスタムモデルでは可能です。

さらに掘り下げる前に、Amazon Kendraを探ってみましょう。Amazon Kendraは、機械学習によって強力で使いやすいエンタープライズ検索サービスです。このサービスを使用すると、ウェブサイトやデータベースからイントラネットサイトまで、組織全体にまたがる膨大なコンテンツから必要な情報を見つけることができます。まず、Amazon Kendraインデックスを作成してドキュメントをインジェストします。データをインジェストする際には、カスタムデータエンリッチメント（CDE）の概念を考慮することが重要です。CDEを使用すると、外部の知識を検索インデックスに取り込むことで、検索機能を強化することができます。詳細については、ドキュメントインジェスト中のエンリッチメントを参照してください。このポストでは、CDEロジックがAmazon ComprehendのカスタムAPIを呼び出して、識別されたクラスとエンティティでドキュメントを豊かにします。最後に、Amazon Kendraの検索ページを使用して、メタデータがファセット付けやフィルタリングの機能を追加することで、検索機能が向上したことを示します。

このソリューションを実装するための概要的な手順は次のとおりです：

1. 訓練データを使用してAmazon Comprehendのカスタム分類モデルをトレーニングする
2. 訓練データを使用してAmazon Comprehendのカスタムエンティティ認識をトレーニングする
3. Amazon Comprehendのカスタム分類器とカスタムエンティティ認識エンドポイントを作成する
4. 抽出後のエンリッチメントのためのLambda関数を作成してデプロイする
5. Amazon Kendraインデックスを作成してポピュレートする
6. Amazon Kendraで抽出されたエンティティを使用して検索をフィルタリングする

参考のために、GitHubリポジトリにサンプルアプリケーションも提供されています。

データセキュリティとIAMの考慮事項

セキュリティを最優先事項として、このソリューションでは使用するサービスと機能に対して最小限の特権アクセスを原則としています。Amazon Comprehendのカスタム分類およびカスタムエンティティ認識に使用されるIAMロールは、テストバケットからデータセットにアクセスするための権限を持っています。Amazon Kendraサービスは特定のS3バケットおよびLambda関数にアクセスできます。Lambda関数はAmazon ComprehendのAPIのみを呼び出す権限を持っています。詳細については、ノートブックのセクション1.2および1.3を参照してください。

このソリューションを本番環境に実装する前に、非本番環境で以下のことを行うことをおすすめします。

Comprehendのカスタム分類モデルを訓練する

Amazon Comprehendのカスタム分類は、注釈ファイルの2つのデータ形式タイプをサポートしています：

• CSVオプションを使用する
• Augmentマニフェストファイルオプションを使用してSageMaker Ground Truthを使用したデータのラベル付け

私たちのデータは既にラベルが付けられてCSVファイルに保存されているため、注釈ファイルのフォーマットとしてCSVファイル形式を使用します。ラベル付きのトレーニングデータをUTF-8エンコードされたテキストとしてCSVファイルに提供する必要があります。CSVファイルにヘッダ行を含めないでください。ヘッダ行をファイルに含めると、ランタイムエラーが発生する可能性があります。トレーニングデータCSVファイルの例は次のとおりです：

クラス, ドキュメント1のテキスト
クラス, ドキュメント2のテキスト

クラシファイアのトレーニングデータを準備するには、クラシファイアのトレーニングデータの準備を参照してください。CSVファイルの各行には、最初の列に1つ以上のクラスラベルが含まれています。クラスラベルは、任意の有効なUTF-8文字列であることができます。意味が重複しない明確なクラス名を使用することをおすすめします。名前には空白を含めることができ、アンダースコアやハイフンで接続された複数の単語で構成することができます。行内の値を区切るコンマの前後にスペース文字を残さないでください。

次に、マルチクラスモードまたはマルチラベルモードのどちらかを使用してトレーニングを行います。具体的には、マルチクラスモードでは、各ドキュメントに1つのクラスが割り当てられますが、マルチラベルモードでは、個々のクラスが互いに排他的ではない異なるカテゴリを表します。私たちの場合、テキストモデルにはマルチクラスモードを使用します。

Amazon Comprehendのカスタムクラシファイアのトレーニングデータとモデルの評価のために、別々のトレーニングデータセットとテストデータセットを準備することもできます。または、トレーニングとテストの両方に同じデータセットを提供することもできます。Comprehendは、提供されたデータセットの中から自動的にテストデータとして10%を選択します。この例では、別々のトレーニングデータセットとテストデータセットを提供しています。

以下の例は、さまざまなドキュメントに関連付けられたクラス名を含むCSVファイルの例です。

ドキュメントの形式 – 保険の種類、ドキュメント1の内容

カスタムクラシフィケーションモデルがトレーニングされると、ドキュメントの異なるクラス（ホーム保険、自動車保険、または生命保険）をキャプチャすることができます。

Amazon Comprehendカスタムエンティティ認識機能（NER）をトレーニングデータを使用してトレーニングする

Amazon Comprehendカスタムエンティティ認識機能（NER）のトレーニングデータは、2つの異なる方法で準備することができます：

• 注釈 – モードのトレーニング用に注釈付きエンティティを含むデータセットを提供します
• エンティティリスト（プレーンテキストのみ） – エンティティのリストとそのラベルタイプ（「保険会社名」など）と、これらのエンティティを含む注釈のないドキュメントのセットを提供します

詳細については、エンティティ認識機能のトレーニングデータの準備を参照してください。

エンティティリストを使用してモデルをトレーニングする場合、2つの情報を提供する必要があります。関連するカスタムエンティティタイプを持つエンティティ名のリストと、それらのエンティティが現れる注釈のないドキュメントのコレクションです。

自動トレーニングには、サンプルドキュメントとエンティティリストまたは注釈の2つのタイプの情報が必要です。認識機能がトレーニングされると、ドキュメント内のカスタムエンティティを検出するために使用できます。リアルタイムで小規模なテキストの分析を迅速に行うこともできますし、非同期ジョブで大量のドキュメントの分析を行うこともできます。

Amazon Comprehendカスタムエンティティ認識機能のトレーニングデータとモデルの評価のために、別々のトレーニングデータセットとテストデータセットを準備することもできます。または、トレーニングとテストの両方に同じデータセットを提供することもできます。Amazon Comprehendは、提供されたデータセットの中から自動的にテストデータとして10%を選択します。以下の例では、トレーニングデータセットをDocuments.S3Uriの配下に指定しました。

以下の例は、エンティティの内容を含むCSVファイルの例です。

カスタムエンティティ（NER）モデルがトレーニングされたら、「PAYOUT」、「INSURANCE_COMPANY」、「LAW_FIRM」、「POLICY_HOLDER_NAME」、「POLICY_NUMBER」などのさまざまなエンティティを抽出することができるようになります。

Amazon Comprehendのカスタム分類器とカスタムエンティティ（NER）エンドポイントの作成

Amazon Comprehendのエンドポイントを使用すると、カスタムモデルをリアルタイムの分類に利用できます。エンドポイントを作成した後は、ビジネスのニーズに応じて変更を加えることができます。たとえば、エンドポイントの利用状況をモニタリングし、自動スケーリングを適用して容量のニーズに合わせてエンドポイントのプロビジョニングを自動的に設定することができます。すべてのエンドポイントを単一のビューから管理できますし、不要なエンドポイントは削除してコストを節約することもできます。Amazon Comprehendは同期および非同期のオプションの両方をサポートしており、リアルタイムの分類が必要ない場合は、非同期データ分類用にバッチジョブをAmazon Comprehendに送信することができます。

このユースケースでは、カスタムモデルをリアルタイムで分析できるようにエンドポイントを作成します。

テキスト処理のニーズに応じて、エンドポイントに推論ユニットを割り当てます。各ユニットによって、1秒あたり100文字のスループットが可能になります。その後、スループットを上下に調整できます。

ポスト抽出のエンリッチメントのためのLambda関数の作成とデプロイ

ポスト抽出のLambda関数を使用すると、Amazon Kendraから取り込まれたドキュメントから抽出されたテキストを処理するためのロジックを実装できます。構成したポスト抽出関数では、Amazon Kendraから抽出したテキストを使用してAmazon Comprehendを呼び出し、カスタムエンティティを検出し、ドキュメントのメタデータを更新し、そのメタデータをAmazon Kendraの検索結果として表示します。関数コードはノートブックに埋め込まれています。PostExtractionLambdaコードの動作は次のようになります：

• コンプリヘンドのdetect_entities APIの最大バイト長制限を超えないセクションにページのテキストを分割します。（制限事項を参照）。単純化のために、このスクリプトではナイーブな文字数ベースの分割アルゴリズムを使用していますが、本番環境ではUTF8バイト長に基づいてオーバーラップまたは文境界の分割を実装する必要があります。
• テキストの各セクションに対して、カスタムエンティティとカスタム分類器のためのコンプリヘンドリアルタイムエンドポイントを呼び出して、次のエンティティタイプを検出します：[“PAYOUT“, “INSURANCE_COMPANY“, “LAW_FIRM“, “POLICY_HOLDER_NAME“, “POLICY_NUMBER“, “INSURANCE_TYPE“]。
• 信頼スコアの閾値を下回る検出されたエンティティをフィルタリングします。この例では、信頼度が50％以上のエンティティのみが使用されます。この値はユースケースと要件に合わせて調整することができます。
• 各エンティティの出現回数をカウントします。
• ページごとに、発生頻度に基づいて上位N（10）個の一意のエンティティのみを選択します。
• ドキュメント分類では、マルチクラス分類器は各ドキュメントに対して1つのクラスのみを割り当てます。このLambda関数では、ドキュメントを自動保険、家庭保険、または生命保険として分類します。

# Comprehendを使用して、入力テキストを読み取り、エンティティを検出する関数def entity_detector(doc_text):    # エンティティを保存するためのJSONオブジェクトのリスト    entity_data = dict()    # カテゴリとして認識されたテキスト文字列のリスト    category_text = dict()    # 各テキスト文字列の出現頻度    text_frequency = dict()    for et in categories:        entity_data[et] = []        category_text[et] = []        text_frequency[et] = dict()        # テキスト制限の範囲内でdetect_entities_v2をループで呼び出す    for i in range(0, len(doc_text), compre_text_size):        try:            entities = compre.detect_entities(Text=doc_text[i:i+compre_text_size], LanguageCode='en', EndpointArn=endpoint_custom_entity)                    except Exception as e:            logger.info("終了 - detect_entities_v2は例外で終了しました")            return []        for e in entities["Entities"]:            # 信頼スコアがmin_scoreを超え、印刷可能で、クオートを含まず、以前に見たことのないエンティティのみを取得             if((e["Score"] > min_score) and (e["Text"].isprintable()) and (not '\"' in e["Text"]) and (not e["Text"].upper() in category_text[e["Type"]])):                # Kendraカスタム属性に使用するために、テキストをentity_dataに追加                entity_data[e["Type"]].append(e["Text"])                # 同じテキストを大文字と小文字で区別せずに扱うために、テキストを大文字に変換してcategory_textに追加                category_text[e["Type"]].append(e["Text"].upper())                # 出現頻度を追跡して、最も頻度の高いテキストを取得するために使用                text_frequency[e["Type"]][e["Text"].upper()] = 1            elif (e["Text"].upper() in category_text[e["Type"]]):                # 出現頻度を追跡して、最も頻度の高いテキストを取得するために使用                text_frequency[e["Type"]][e["Text"].upper()] += 1    # Kendra属性のメタデータとして使用するJSONオブジェクトを作成    metadata = dict()    for et in categories:        metadata[et] = []        # 出現頻度の高いテキスト文字列をelimit個まで取得        el = [pair[0] for pair in sorted(text_frequency[et].items(), key=lambda item: item[1], reverse=True)][0:elimit]        for d in entity_data[et]:            if (d.upper() in el):                metadata[et].append(d)    for md in metadata:        metaUL.append({            "name": md,            "value": {                "stringListValue": metadata[md]            }        })    return metaUL

この執筆時点では、CDEは同期呼び出しのみをサポートしています。非同期にする場合は、明示的な待ちループが必要です。ポスト抽出のLambdaでは、最大実行時間は1分です。Lambdaのカスタムロジックは、使用ケースに合わせて要件に基づいて変更することができます。

Amazon Kendraインデックスの作成とポピュレーション

このステップでは、データをAmazon Kendraインデックスに取り込み、ユーザーが検索できるようにします。インポート中には、前のステップで作成したLambda関数をポスト抽出ステップとして使用し、Lambda関数はカスタム分類とカスタムエンティティ認識(NER)のエンドポイントを呼び出してカスタムメタデータフィールドを作成します。

このソリューションを実装するための手順は次のとおりです：

1. Amazon Kendraインデックスの作成
2. Amazon Kendraデータソースの作成 – インポートするために使用できるさまざまなデータソースがあります。このポストでは、S3バケットを使用しています。
3. Facetsの作成 – Law_Firm、Payout、Insurance_Company、Policy_Number、Policy_Holder_Name、Insurance_Typeを’STRING_LIST_VALUE’として文字列型で作成します。
4. Kendra CDEの作成と、以前に作成したポスト抽出Lambda関数へのポインティング
5. データセットの取り込みのための同期プロセスを実行します。

完了したら、Kendra CDEを使用して保険データでインデックスをポピュレートし、カスタムエンティティタイプとカスタム分類に基づいて検索をフィルタリングすることができます。

Kendraでの検索をフィルタリングするために抽出したエンティティを使用する

インデックスがポピュレートされ、使用準備ができました。Amazon Kendraコンソールでデータ管理の下の検索されたコンテンツを検索を選択し、次の手順を実行します。

以下をクエリする：遅れて提出されたために保険が失敗した一覧？

結果はポリシータイプからの回答です- HOME INSURANCEおよびトップ結果としてtext_18とtext_14を表示します。

左側で「検索結果をフィルタリング」を選択します。すると、Amazon Comprehendを使用して抽出されたエンティティタイプと分類値が表示され、個々のエンティティ値と分類ごとに一致するドキュメントの数が表示されます。

INSURANCE_TYPEの下で「Auto-Insurance」を選択すると、text_25ファイルから回答が得られます。

結果はスクリーンショットで示されている結果と若干異なる場合があることに注意してください。

独自のクエリで検索して、Amazon Comprehendが特定するエンティティとドキュメント分類がどのように迅速に検索結果を次のように提供するかを観察してください：

• 検索結果がカテゴリに分散している方法を確認する
• エンティティ/分類のいずれかをフィルタリングして検索を絞り込む

クリーンアップ

検索を試し、Githubリポジトリで提供されるノートブックを使用した後、不要な料金を避けるために、AWSアカウントにプロビジョニングされたインフラストラクチャを削除してください。ノートブックでクリーンアップセルを実行できます。または、次のAWSコンソールからリソースを手動で削除することもできます：

• Amazon Kendraインデックス
• Comprehendカスタム分類子とカスタムエンティティ認識(NER)エンドポイント
• Comprehendカスタム分類子とカスタムエンティティ認識(NER)カスタムモデル
• Lambda関数
• S3バケット
• IAMロールとポリシー

結論

この記事では、Amazon Comprehendのカスタムエンティティとカスタム分類器がAmazon KendraのCDE機能による検索の改善にどのように役立つかを示しました。Amazon Comprehendのカスタムエンティティとカスタム分類器は、さまざまなユースケースと特定のドメインのデータに非常に有用です。Amazon Comprehendの使用方法についての詳細は、Amazon Comprehendの開発者リソースを参照し、Amazon KendraについてはAmazon Kendraの開発者リソースを参照してください。

このソリューションをお試しください。コメントセクションにフィードバックをお寄せいただければ幸いです。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!