一般的なフィールド抽出

Communications Mining™ は、非構造化テキストから以下の種類の出力を抽出します。

• ラベル
• 一般フィールド

ラベルはメッセージ全体を表します。たとえば、キャンセル、取引の失敗、緊急などです。一般フィールドは、メッセージの具体的な部分 (取引先名、顧客 ID、キャンセル日など) を参照します。

下流工程では、ラベルを使用して、アクションをトリアージして優先順位を付け、実行するアクションの種類を決定します。一般フィールドは、要求のフィールドに入力するために使用します。たとえば、下流工程でメッセージにフィルターを適用して、「キャンセル」というラベルが付いたメッセージに絞り込み、抽出された「顧客 ID」と「キャンセル日」の一般フィールドを使用して API を呼び出し、自動的にキャンセルを処理できます。

Communications Mining には、組織、通貨コード、日付など、一般的な概念に対応する組み込み一般フィールドが多数付属しています。Communications Mining の組み込み一般フィールドをカスタマイズして、特定のユース ケースに合わせて調整できます。たとえば、Communications Mining には、高度なトレーニングを受けた事前に構築された日付の一般フィールドがあり、更新日やキャンセル日など、よりカスタマイズされた一般フィールドの出発点として使用できます。または、ゼロから始めて、まったく新しいものを認識するように Communications Mining に教えることもできます。

一般フィールドの設定

例として保険のユースケースを使用します。 保険会社のメールボックスは、処理のために別のチームにトリアージする必要があるブローカーから電子メールを受信します。 この例では、データセットは既にトレーニングされており、タクソノミーは次のようになります。

図 1. タクソノミーの例

このメールボックスは、更新、キャンセル、管理の要求を受け取りますが、緊急の場合もあります。Communications Mining™ は、これらの各概念を認識するようにトレーニングされており、Communications Mining の予測を使用してサポート チケットを作成することで、メールを適切なチームにトリアージできます。

顧客に迅速に対応できるように、ダウンストリームチームがリクエストを処理するのに役立ついくつかの重要なデータポイントを抽出できます。 具体的には、電子メールから保険証券番号、被保険者組織名、ブローカー名を抽出します。 一般的なフィールド抽出を使用してこれを行うことができます。

図 2. 設定済みの一般フィールド

保険証券番号の形式はこの特定の保険会社に固有であるため、一般フィールドを最初からトレーニングできるように構成します。 一方、被保険者は組織の一種であるため、組み込みの組織全般フィールドに基づいてトレーニング可能になるように構成します。 最後に、ブローカーは常に自分の名前を電子メールに入れるとは限らないため、ブローカーの電子メールアドレス(コメントメタデータから利用可能)を使用して、一般的なフィールドとして抽出するのではなく、内部データベースで対応する名前を検索することにしました。

これらのアプローチの概要は以下の表でご確認ください。

構成	使用すべきタイミング	例
基本一般フィールドのないトレーニング可能な一般フィールド	さまざまな種類の内部 ID によく使用される場合や、Communications Mining に適切な基本汎用フィールドがない場合に使用されます。	保険証券番号、顧客 ID
基本一般フィールドを持つトレーニング可能な一般フィールド	Communications Mining の既存の構築済みの一般フィールドをカスタマイズするために使用します。	取消日 (基準日)、被保険者団体 (団体基準)
事前構築済みの一般フィールド (トレーニング不可)	定義されたとおりに正確に一致させる必要がある、トレーニングによって間違いを招くような一般的なフィールドに使用されます。	ISIN (ISIN コード)
一般フィールドの代わりにコメントメタデータを使用する	必要な情報がコメント メタデータに構造化された形式で既に存在する場合に使用されます。	Sender Address (送信者のアドレス)、Sender Domain (送信者のドメイン)

アプリケーションでの一般フィールドの使用

Communications Mining™ には、予測された一般フィールドを含め、予測を取得する方法が複数用意されています。データのダウンロードの概要を参照して、ユース ケースに最適な方法を理解してください。

どちらの方法を選択する場合でも、次のエッジケースを認識し、アプリケーションで処理する必要があります。

• 予期されるすべての一般フィールドが応答に存在するわけではありません
• 応答には、1 つ以上の一般フィールドに対する複数の一致が含まれます
• 応答に存在するすべての一般的なフィールドが正しいわけではありません

このセクションでは、これらのエッジケースのそれぞれについて詳しく説明します。

すべての一般フィールドが応答に存在するわけではありません

予期される一部の一般フィールドが存在しないケースも処理する必要があります。次の例では、メールには保険証券番号が含まれていますが、被保険者組織名はありません。アプリケーションは、このような部分的な情報を処理できる必要があります。

図 3. 行方不明の被保険者団体

応答には、1 つ以上の一般フィールドに対する複数の一致が含まれます

また、前のケースとは逆の場合、つまりコメントの一般フィールドが予想よりも多い場合も処理することも想定しておく必要があります。次の例では、E メールごとに 1 つの保険証券番号と被保険者組織名を予期しているにもかかわらず、E メールには複数の保険証券番号が含まれています。

図 4. 同じ一般フィールドに対する複数の一致

メタデータは、このような場合を処理する際に応答で使用できます。たとえば、メール本文に表示されるポリシー番号よりも、メールの件名に表示されるポリシー番号を優先的に選択できます。次の例は、メールの例に対して API が返す応答を示しています。

{
  "predictions": [
    {
      "uid": "aa05ba2250de48e3.7588b85f68f81c3b",
      "labels": [...],
      "entities": [
        {
          "id": "6a1d11118b60868e",
          "name": "policy-number",
          "span": {
            "content_part": "body",
            "message_index": 0,
            "utf16_byte_start": 200,
            "utf16_byte_end": 222,
            "char_start": 100,
            "char_end": 111
          },
          "kind": "policy-number",
          "formatted_value": "GHI-0204963"
        },
        {
          "id": "6a1d11118b60868e",
          "name": "policy-number",
          "span": {
            "content_part": "subject",
            "message_index": 0,
            "utf16_byte_start": 0,
            "utf16_byte_end": 22,
            "char_start": 0,
            "char_end": 11
          },
          "kind": "policy-number",
          "formatted_value": "GHI-0068448"
        },
        {...},
        {...},
        {...}
      ]
    }
  ],
  "model": {
    "version": 31,
    "time": "2021-07-14T15:00:57.608000Z"
  },
  "status": "ok"
}

応答に存在するすべての一般的なフィールドが正しいわけではありません

最後に、一般的なフィールドは機械学習を使用して抽出されるため、間違った一致が予想されることが予想されます。 間違った一致の数は、使用している一般的なフィールドによって異なります。 データセットの [検証] ページには、一般的なフィールドのパフォーマンスを理解するための検証統計が表示されます。

図 5. 一般フィールドの検証