Elasticsearch との連携

Communications Mining™ には、豊富な分析ツールが組み込まれています。ただし、場合によっては、Communications Mining からの予測を、Communications Mining のコメントの一部としてアップロードできないデータと結合する必要があります。このような場合の一般的な解決策は、Communications Mining の予測と追加データを Elasticsearch にインデックス付けし、Kibana などのツールを使用して分析を実行することです。このチュートリアルでは、Communications Mining のデータを Elasticsearch にインポートし、Kibana で可視化する方法について説明します。

このチュートリアル全体の例で使用されるデータは、保険ドメインから生成されたダミーメールです。

Elasticsearch にデータを格納する

まず、Elasticsearch にインポートするデータを定義しましょう。Communications Mining™ API は、入れ子になった JSON オブジェクト内のコメント テキスト、コメント メタデータ、予測されたラベル、予測された一般フィールドを提供します。以下に、Communications Mining API で提供される未加工のコメントの例を示します。

注:

Communications Mining へのデータの取り込み方法に応じて、メタデータ フィールドが異なる場合があります。コメント オブジェクト フィールドについて詳しくは、「 コメント」をご覧ください。

{
  "comment": {
    "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "timestamp": "2021-03-29T08:36:25.607Z",
    "messages": [
      {
        "body": {
          "text": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL"
        },
        "subject": {
          "text": "Change of address - Policy SFG48807871"
        },
        "from": "[e-mail]",
        "to": ["[e-mail]"],
        "sent_at": "2021-03-29T08:36:25.607Z"
      }
    ]
    // (... more properties ...)
  },
  "labels": [
    {
      "name": ["Admin"],
      "probability": 0.9995054006576538
    },
    {
      "name": ["Admin", "Change of address"],
      "probability": 0.9995054006576538
    }
  ],
  "entities": [
    {
      "name": "address-line-1",
      "formatted_value": "19 Essex Gardens",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 63,
        "char_end": 79,
        "utf16_byte_start": 126,
        "utf16_byte_end": 158
      }
    },
    {
      "name": "post-code",
      "formatted_value": "SW17 2UL",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 81,
        "char_end": 89,
        "utf16_byte_start": 162,
        "utf16_byte_end": 178
      }
    },
    {
      "name": "policy-number",
      "formatted_value": "SFG48807871",
      "span": {
        "content_part": "subject",
        "message_index": 0,
        "char_start": 27,
        "char_end": 38,
        "utf16_byte_start": 54,
        "utf16_byte_end": 76
      }
    }
  ]
}

Communications Mining API によって返される生のコメントのスキーマは、Elasticsearch でこのデータをフィルター処理したりクエリしたりするには不便であるため、データを Elasticsearch に取り込む前にスキーマを変更する必要があります。以下は、使用できるフラット化されたスキーマの例です。ユースケースに必要なすべてのフィールドを追加する必要があります。

{
  "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "timestamp": "2021-03-29T08:36:25.607Z",
  "subject": "Change of address - Policy SFG48807871",
  "body": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL",
  // (... more fields ...)
  "labels": ["Admin", "Admin > Change of address"],
  "entities": {
    "policy_number": ["SFG48807871"],
    "address-line-1": ["19 Essex Gardens"],
    "post-code": ["SW17 2UL"]
  }
}

注:

コメントには 0 個、1 個、または複数のラベルを付けることができるため、 labels フィールドは配列である必要があります。また、データセットに 1 つ以上の一般フィールドの種類が設定されている場合、コメントには一般フィールドの種類ごとに 0 個、1 個、またはそれ以上の一般フィールドが含まれます。生の API 応答の階層ラベル名は、それ自体が配列 (["Admin", "Change of address"]) であり、文字列 ( ) に変換する必要があります ("Admin > Change of address")。

データのフェッチ

データを取得するには、データ マネージャーを使用することをお勧めします。利用可能なすべてのデータのダウンロード方法の概要は、「 データをダウンロードする」をご覧ください。ストリームを作成する際は、信頼度スコアがしきい値を下回るラベルが破棄されるように、各ラベルのしきい値を設定する必要があります。この操作は、Communications Mining™ の UI でデータセットの [ストリーム] ページに移動するのが最も簡単です。信頼度スコアを使用してラベルが適用されるかどうかを判断したら、ラベル名のみを Elasticsearch にインポートできます。ラベル信頼度スコアの削除または維持が推奨される場合については、「 分析のためのラベル」をご覧ください。

一般フィールドには信頼度スコアがないため、特別な処理は必要ありません。

注:

モデル変更管理 ストリームを作成するときは、ストリームからコメントを取得するときに予測を提供するために使用されるモデル バージョンを指定します。プラットフォームで新しいモデル バージョンのトレーニングを続行しても、ストリームでは指定したモデル バージョンが使用されるため、確定的な結果が得られます。

新しいモデル バージョンにアップグレードするには、そのモデル バージョンを使用する新しいストリームを作成し、新しいストリームを使用するようにコードを更新する必要があります。このため、コードでストリーム名を設定可能にすることをお勧めします。

予測を使用する分析の一貫性を確保するには、更新されたモデル バージョンを使用して履歴データの予測を再度取り込む必要があります。そのためには、最も古いコメントの前のタイムスタンプにストリームを送信し、データを最初から再度取り込みます。

データを Kibana で可視化する

Elasticsearch でデータのインデックスを作成したら、ビジュアリゼーションの構築を開始できます。 このセクションでは、Kibana の一般的な視覚化ツールの簡単な例を示します。

タイムリオン

次の式を使用すると、最も一般的な上位 5 個のラベルの経時的なプロットを生成できます。

注:

トップレベルのカテゴリ ラベルとサブカテゴリ ラベルの両方が表示されます。

.es(index=example-data,split=labels:5,timefield=@timestamp)
    .label("$1", "^.* > labels:(.+) > .*")

図 1.データセット内の上位 5 個のラベルを経時的にプロットした値です。

棒グラフ

この棒グラフには、データセット内の上位 20 個の送信者のメール アドレスが表示されます。送信者と受信者のメール アドレスは、メールベースのデータセットのコメント メタデータの一部です。

図 2.送信者のメール アドレス上位 20 位。

円グラフ

この円グラフでは、最上位の "クレーム" ラベルの下にサブカテゴリ ラベルが表示されます。 ラベル カテゴリは、モデルをトレーニングするユーザーによって定義されます。

図 3.[要求] ラベルのサブカテゴリ。