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. クレームラベルのサブカテゴリ。