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 にインポートできます。ラベル信頼度スコアの削除または維持が推奨される場合については、「 分析のためのラベル」をご覧ください。

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

注:

モデル変更管理

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

新しいモデル バージョンにアップグレードするには、そのモデル バージョンを使用する新しいストリームを作成し、新しいストリームを使用するようにコードを更新する必要があります。(このため、コードでストリーム名を構成可能にすることをお勧めします)。予測を使用した分析で一貫性を保つには、更新されたモデル バージョンを使用して履歴データの予測を再度取り込む必要があります。そのためには、最も古いコメントの前のタイムスタンプにストリームを送信し、データを最初から再度取り込みます。

データを Kibana で可視化する

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

タイムリオン

次の式を使用して、時間の経過に伴う最も一般的な上位 5 つのラベルのプロットを生成できます。 これにより、最上位のカテゴリ ラベルとサブカテゴリ ラベルの両方が表示されます。

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

図 1. 時間の経過と共にプロットされたデータセット内の上位 5 つのラベル。

棒グラフ

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

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

円グラフ

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

図 3. クレームラベルのサブカテゴリ。