一般的なフィールド抽出

Communications Mining™ extracts the following types of output from unstructured text:

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

Labels describe the entire message, for example, Cancellation, Trade failure, or Urgent. General fields refer to specific parts of the message, for example, Counterparty name, Customer ID, or Cancellation date.

In a downstream process, labels are used to triage, prioritize, and decide what kind of action should be taken. General fields are used to fill in fields of requests. For example, a downstream process may filter messages to those that have the Cancellation label, and then use the extracted Customer ID and Cancellation date general fields to call an API to automatically process the cancellation.

Communications Mining comes with a number of built-in general fields for common concepts, such as Organization, Currency Code, or Date. You can customize the built-in general fields of Communications Mining so that they are tailored to your specific use case. For example, Communications Mining has a highly trained pre-built Date general field which you can use as a starting point for a more customized general field such as Renewal Date or Cancellation Date. Alternatively, you can start from scratch and teach Communications Mining to recognize something completely new.

一般フィールドの設定

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

図 1. タクソノミーの例

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

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

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

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

The following table summarizes these approaches.

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

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

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

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

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

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

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

You should expect to handle cases where not all expected general fields are present. In the following example, the email has the policy number, but doesn't have the insured organization name. Your application should be able to handle such partial information.

Figure 3. Missing Insured Organization

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

You should also expect to handle the opposite of the previous case, namely cases where a comment has more general fields than expected. In the following example, even though we expect one policy number and insured organization name per email, the email has multiple policy numbers.

Figure 4. Multiple matches for the same general field

Note that you can use the metadata in the response when handling such cases. For example, we can choose to preferentially pick policy numbers that appear in the email subject over those that appear in the email body. The following example shows the response that the API will return for our example email.

{
  "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"
}

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

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

Figure 5. General field validation