リアルタイム自動化

このハンズオン チュートリアルでは、Communications Mining を使用して受信メールをリアルタイムで分類する簡単な自動トリアージ アプリケーションを構築します。 独自の Communications Mining オートメーションの開始点として使用できるエンドツーエンドのワークフローを構築し、リアルタイム Stream API の使用方法を詳しく見ていきます。

前提条件

Communications Mining の基本

このチュートリアルを開始する前に、Communications Mining の概念と用語 、および Communications Mining API の基本について理解しておいてください。

Communications Mining のアクセス権限

チュートリアルを実行するには、次の権限が必要です。 現在の権限は、[ アカウントの管理] ページで確認できます。

プロジェクト	説明	PERMISSIONS
reinfer-sandbox	このチュートリアルで使用する注釈付き reinfer-sandbox/integration-tutorial データセットが含まれています。	"ソースを表示"、"ラベルを表示"
開発プロジェクト	オンボード中に、開発環境として使用できるプロジェクトへのアクセス権を付与されている必要があります。	"ストリーム管理者"、"ストリームの使用"、"ソースの表示"、"ラベルの表示"

開発に使用できるプロジェクトが不明な場合や、reinfer-sandboxで [ソースの表示] 権限と [ラベルの表示] 権限が必要な場合は、サポートにお問い合わせください。

チュートリアル データ

このチュートリアルでは、事前に注釈が付けられたデータを使用します。 事前に注釈が付けられた reinfer-sandbox/integration-tutorial データセットのコピーを作成するには、[既存のタクソノミーをコピー] オプションを使用して、開発プロジェクトに新しいデータセットを作成します。 その手順については、 こちらをご覧ください。

新しいデータセットには注釈付きデータが含まれているため、モデルのトレーニングはすぐに開始されます。 モデルのトレーニング ステータスは、データセットのステータス バーで追跡できます。 完了すると、各ラベルのパフォーマンス メトリックが [検証] ページに表示され、新しいモデル バージョンが [モデル] ページに表示されます。

図 1. ラベルのパフォーマンスを示す検証ページ

図 2. 新しいモデルのバージョンが表示された [モデル] ページ

アプリケーションを設計する

前提条件を理解したので、エンドツーエンドのワークフローの構築を始めましょう。このセクションでは、単純な自動トリアージ アプリケーションの設計と、Communications Mining との統合について説明します。 次のセクションでは、自動化を推進する Stream API について説明します。 最後に、ここでの設計に基づいて アプリケーションを構築し 、事前に注釈が付けられたデータを使用してテストします。

ユースケースの概要

設計の開始点として、典型的な電子メールサポートのユースケースをターゲットにします。

• Outlook サポート メールボックスは、毎日多数の顧客メールを受信します。
• トリアージチームは、各メールをサポートチケットに変換します。 これには、電子メールからの情報(顧客IDなど)をチケットフィールドに入力する必要があります。 その後、各チケットが適切なワークフローキューに追加されます。
• ワークフローキュー内のチケットは、カスタマーサポートチームによって継続的に処理されます。
  図 3. シンプルなメールサポートのユースケース
  

  

  
  

自動化の機会には、トリアージ ステップと処理ステップの 2 つがあります。 このチュートリアルでは、Communications Mining を使用してメールから必須フィールドを抽出し、そのメールをワークフロー キューに割り当てることで、トリアージ手順を自動化する方法を説明します。

手記： このチュートリアルでは処理手順について説明しませんが、トリアージ手順で収集されたデータに依存するため、サンプル トリアージ アプリケーションのビルド後に追加することもできます。

エンドツーエンドの設計

以下の図は、これから構築するエンドツーエンドの設計をスケッチしたものです。

図 4. エンドツーエンドのオートメーション設計

Exchange サーバーと Communications Mining はライブ接続であるため、Communications Mining はアプリケーションのデータ ソースとして使用できます。 この方法では、アプリケーションと Exchange サーバーの間に別個の接続を用意する必要はありません。 アプリケーションは継続的に Communications Mining をポーリングして新しい電子メールを探し、予測されたラベルと一般的なフィールドと共に受信します。 (アプリケーションの実行と同時にメールボックスの受信トレイで直接作業しているユーザーはいないことを前提としています。それ以外の場合は、アプリケーションとメールボックス ユーザー間の競合を考慮する必要があります)。

アプリケーションは Communications Mining に対してクエリを実行し、各メールについて、必要なラベルと全般フィールドが API 応答に存在するかどうかを確認します。 「はい」の場合、適切なワークフローキューにチケットが作成されます。 そうでない場合は、Communications Mining に 2 つ目の API 要求を送信して、メールを「予測なし」例外としてマークします。 同様に、チケットを処理するユーザーが誤って分類されたチケットを報告し、対応するメールを Communications Mining で "間違った予測" 例外としてマークできるようにする方法も必要です。 (両方の例外タイプは、モデルのパフォーマンスを向上させるために、モデルメンテナによってレビューされ、注釈が付けられます)。

設計の一部 (図の点線のアウトラインを表示) は、このチュートリアルの範囲外です。 実際のシナリオでは、もちろんこれらの手順をスキップしないでください。

• ライブ EWS 接続を設定する代わりに、プラットフォームの既存のデータを使用します。
• データには事前に注釈が付けられているため、モデルをトレーニングする必要はありません。
• 「間違った予測」例外のフィードバックループは、チケットが処理されるシステムの機能に依存するため、設計しません。

データの取り込み

Communications Mining に電子メール データを取得するための推奨オプションは、Communications Mining EWS コネクタを使用することですが、他のオプションも使用できます。 プラットフォームに既に存在するデータを使用しているため、データ インジェストの設定はこのチュートリアルでは説明しません。 利用可能なすべてのデータ インジェスト オプションについて詳しくは、 こちらをご覧ください。

ビジネス ロジック

このプロセスを自動化したい:

トリアージチームは、各メールをサポートチケットに変換します。 これには、電子メールからの情報(顧客IDなど)をチケットフィールドに入力する必要があります。 その後、各チケットが適切なワークフローキューに追加されます。

このチュートリアルでは、ワークフロー キューが "更新"、"キャンセル"、"管理者"、および "緊急" であると仮定します。 更新、キャンセル、および管理タスクに関する電子メール(例: アドレスの変更)はそれぞれのキューに入ることになっていますが、すべての緊急の電子メールはトピックに関係なく「緊急」キューに入る必要があります。

また、各電子メールに顧客 ID (電子メールの件名または本文) を含めることができると仮定します。 顧客 ID を抽出し、メールからチケットを作成するときに使用できるようにする必要があります。 ただし、顧客は顧客 ID を含め忘れることがあるため、顧客 ID が存在しない場合でもチケットを作成できるように、このフィールドをオプションにする必要があります。

図 5. 「キャンセル」ラベルが割り当てられたコメントを確認し、「顧客ID」一般フィールドを抽出しました

メールを 4 つのワークフロー キューに分類できるように、モデルは「更新」、「キャンセル」、「管理者」、「緊急」のラベルを予測するようトレーニングされています。 顧客IDを抽出するために、「顧客ID」一般フィールドが設定されています。 (Communications Mining には、事前に構築された一般的なフィールドの種類が多数付属しています。特定の連携の必要に応じて、さらに一般的なフィールドの種類を追加できます。 現在利用可能な 全般フィールドのリストはこちらをご覧ください。新しい全般フィールドの種類のリクエストについては、 こちらをご覧ください)。

これで、Communications Mining から受け取る予測ラベルと、メールが格納されるワークフロー キューとのマッピングを思いつくことができます。

IF number of labels == 0 THEN put email into "Uncategorised" queue
IF one of labels is "Urgent" THEN put email into "Urgent" queue
ELSE
    IF number of labels == 1 THEN put email into the respective queue
    ELSE put email into "Uncategorised" queue

チュートリアルのためにいくつかの選択をしました。

• 既存の 4 つのワークフローキューに加えて、特別な「未分類」キューがあります。 モデルが予測を提供できない場合は、メールをそこに配置して手動で処理します。 または、「管理者」など、分類されていないすべての電子メールを処理する必要がある既存のキューを選択することもできます。
• メールに ["Renewal", "Cancellation", "Admin"]のセットから複数のラベルがある場合、それは複数の要求が含まれていることを意味します。 このようなメールを「未分類」キューに入れることを選択しますが、これはおそらく、それらの多くを取得する予定がないためです。 または、「複雑なリクエスト」キューを作成することもできます。

実際のシナリオでは、ユース ケースの特定の要件に基づいてこのような決定を行う必要があります。

モデルのトレーニング

モデルに予測のクエリを実行するには、トレーニング済みのモデルも必要です。 モデルは、取り込んだデータの一部に注釈を付けることでトレーニングされます。 優れたパフォーマンスを発揮するモデルを生成するには数時間の注釈付けが必要なため、このチュートリアルでは事前に注釈付けされたデータを使用して、独自のモデルをトレーニングする必要はありません。

実際のシナリオでは、モデル トレーナーはデータに関する十分なドメイン知識を持っている必要があります。 たとえば、サポート メールボックスのユーザーは、そのメールボックスからのデータにラベルを付けるのに適したモデル トレーナーになります。 パフォーマンスが高く、偏りのないモデルを生成するには、トレーニングを慎重に行う必要があります。 そのために、Communications Mining ではトレーニング リソース を提供し、実践的なトレーニング ワークショップを提供しています。

例外処理

パフォーマンスの高いモデルでも、ラベルの予測に失敗したり、間違ったラベルを予測したりして、誤った結果が得られることがあります。 モデルを改善する最適な方法の 1 つは、モデルのパフォーマンスが低いメールに注釈を付けることです。 このため、このようなメールにはフィードバックループが必要です。

電子メールごとに、アプリケーションは必須ラベルと一般フィールドが存在するかどうかを確認します。 「はい」の場合、適切なワークフローキューにチケットが作成されます。 そうでない場合は、Communications Mining に 2 つ目の API 要求を送信して、メールを「予測なし」例外としてマークします。 同様に、チケットを処理するユーザーが誤って分類されたチケットを報告し、対応するメールを Communications Mining で "間違った予測" 例外としてマークできるようにする方法も必要です。

この 設計 では、両方の種類の例外に対するフィードバック ループが示されています。

ダウンストリームシステム

この デザイン は、ワークフローキューを抽象的な方法で表示します。 実際には、電子メールをCRMプラットフォームに直接プッシュしたり、Kafkaなどのメッセージブローカーを使用したり、単に電子メールを受信トレイフォルダーからサブフォルダーに移動したりする場合があります。 このチュートリアルでは、キューのモックアップを行いますが、エンドツーエンドでテスト統合を開発することをお勧めします。

ストリーム API を理解する

受信メールを予測されたラベルおよび抽出された一般フィールドと共に取得するには、 Stream API を使用すると、データセット、ピン留めされたモデル バージョン、任意のコメント フィルターに基づいてコメントのストリームを定義し、ステートフルな方法で反復処理できます。

Stream 応答の各結果には、コメント、予測ラベルの一覧、および一般的なフィールドの一覧が含まれます。 これは、以下に示すように JSON 構造として渡されます。

{
"comment": {...},
"entities": [...],
"labels": [...],
    ...
}

次のセクションでは、各ストリーム応答で予測されたラベルを正しく解釈する方法について説明します。

信頼度しきい値スコア

信頼度スコア

Stream エンドポイントは、予測されたラベルと信頼度スコア (0 から 1 までの数値) を返します。 たとえば、以下のスニペットは、それぞれ約 0.84 と 0.02 の信頼度を持つ "キャンセル" と "管理者" の予測用です。

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

このような結果を正しく解釈するには、予測を「はい、ラベルが適用されます」として扱う最小信頼度スコアを決定する必要があります。 この数値を信頼度スコアのしきい値と呼びます。

適合率と再現率

信頼度のしきい値を理解するには、 精度 と 再現率という用語に精通している必要があります。 これらの用語の説明は、 サポートページにあります。 簡単に言えば、高い精度は低い偽陽性率(すなわち、 あなたの結果は正確である可能性が高くなります)、そして高い再現率は低い偽陰性率に関連しています(つまり、 関連する結果を見逃す可能性が低くなります)。

信頼度しきい値

ラベルの信頼度しきい値は、特定の精度と再現率のトレードオフに対応します。 モデルが完全に機能しない限り、精度を高くすると再現率がいくらか犠牲になり、逆に再現率が高いと精度がいくらか犠牲になります。 これらのトレードオフは、[ 検証] ページで各ラベルの精度-再現率-曲線として視覚化されます。

図 6. ラベルの精度-再現率曲線

インタラクティブなスライダーを使用すると、アプリケーションの要件に一致する精度と再現率が見つかるまで、スライダーを右に動かして精度を最適化するか、左に動かして再現率を最適化するなど、目的のしきい値をすばやく見つけることができます。 表示されるしきい値が目的のしきい値になります。 検証ページの機能の詳細については、 サポート ページをご覧ください。

注:

検証ページを見ると、精度-再現率-曲線の形状がラベルごとに異なることに気付くかもしれません。 これにより、しきい値を選択する方法に関するヒントが得られ、ラベルごとに個別のしきい値が選択されます。 これは、最高のパフォーマンスを確保する必要があるオートメーション アプリケーションでは特に重要です。

しきい値の例

サンプル アプリケーションでは、"更新"、"キャンセル"、および "管理者" ラベルに対して精度と再現率のバランスのとれたトレードオフを選択し、"緊急" ラベルの再現率を最適化します (緊急メールを見逃す可能性を低くします)。 (基になる ML パフォーマンスの継続的な改善により、このチュートリアルを実行するまでに、選択したしきい値での精度と再現率の値は、ここに示されているものとは若干異なる可能性があることに注意してください)。

図 7. 管理者ラベルの精度と再現率

図 8. キャンセルラベルの精度と再現率

図 9. リニューアルラベルの精度と再現率

図 10. 緊急のラベル精度と再現率

チュートリアルの残りの部分では、次のしきい値を使用します。

Admin: 0.898 (corresponds to 100% precision at 100% recall)
Cancellation: 0.619 (corresponds to 100% precision at 100% recall)
Renewal: 0.702 (corresponds to 100% precision at 100% recall)
Urgent: 0.179 (corresponds to 83% precision at 100% recall)

これで、例にしきい値を適用できます。 「キャンセル」ラベルは 0.8374786376953125 > 0.619から適用されます。 "Admin" ラベルは 0.0164003014564514 < 0.898以降適用されません。

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

このプロセスを簡単にするために、Streams API では Stream 構成でラベルのしきい値を指定できます。 指定した場合、しきい値を超える値を持つラベルのみが返されます。

実際のシナリオでは、目標の精度再現率のパフォーマンスは、ビジネス要件と履歴モデルのパフォーマンスの組み合わせによって決定されます。 たとえば、ラベルが歴史的に 55% の再現率で 85% の精度を達成した場合、55% の再現率で最大 90% の精度までトレーニングするために追加の時間を費やすことを決定できます。 次に、新しいモデル バージョンをピン留めし、新しいしきい値を選択して、アプリケーションの構成を更新します。

アプリケーションを構築する

設計が完成したら、アプリケーションの構築を開始する準備が整いました。

モデルをピン留めする

[モデル] ページに移動し、[保存] トグルをクリックしてモデルをピン留めします。 モデルをピン留めすると、API を使用してモデルへのアクセスを開始できます。

注:

別の注釈付きデータセットを使用してチュートリアルのこの部分に従う場合は、十分な注釈が付けられていることを確認する必要があります。 特に、注釈付きの例が少ないデータセットでは、大部分のコメントに対して予測が返されないモデルが生成されます。

図 11. 「保存」トグルをクリックしてモデルバージョンを固定します

ストリーム構成

ほとんどの場合は、ストリーム名、データセット名とモデル バージョン、および関心のあるラベルを指定するだけで十分です。 オプションの完全なリストについては、リファレンスを参照してください。

ラベルごとにしきい値を指定する必要があります。 ラベルのしきい値を選択する方法については、このチュートリアルで前述したセクションを参照してください。

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "stream": {
        "name": "<my-stream-name>",
        "model": {
          "version": <my-model-version>,
          "label_thresholds": [
            {
              "name": [
                "Parent Label",
                "Child Label"
              ],
              "threshold": <my-label-threshold>
            },
            {
              "name": [
                "Label Without Parent"
              ],
              "threshold": <my-label-threshold>
            }
          ]
        }
      }
    }'

フェッチアンドアドバンスループ

これで、ストリームを使用して Communications Mining からコメントを取得できるようになりました。 非常に低いバッチサイズ(1コメントのバッチでフェッチするなど)は、コメントがフェッチされる速度に影響を与えることに注意してください。

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/fetch' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "size": <my-stream-batch-size>
    }'

ストリームの初期位置は、作成時刻に設定されます。 開発目的では、ストリームの前に作成されたコメントを取得すると便利なことがよくあります。 これを行うには、ストリームを特定のタイムスタンプに設定できます。

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/reset' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "to_comment_created_at": "<YYYY-MM-DDTHH:MM:SS>"
    }'

ここで fetch 要求を再実行すると、同じ位置からフェッチされます。 コメントの次のバッチを取得するには、 advance 要求で前のバッチを確認する必要があります。 advance要求では、fetch応答に記載されているsequence_idを提供する必要があります。

フェッチアンドアドバンスループにより、処理中にアプリケーションに障害が発生した場合に誤ってコメントをスキップすることがなくなります。 アプリケーションは、コメントの処理に成功したが、事前ステップで失敗した場合に備えて、コメントを複数回表示することを処理できる必要があることに注意してください。

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/advance' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "sequence_id": "<my-sequence-id>"
    }'

ストリームを使用するすべての API 要求でデータセット名を指定する必要があります。これは、ストリームのスコープがデータセットの下で設定されるためです。

プロセスの結果

応答には、 コメント 、予測ラベル、および一般フィールド ページで説明されているように、予測ラベルと一般 フィールド が含まれます。 応答を解析する方法を理解するには、これらのページを参照してください。

例外処理

誤って予測された項目にユーザーがタグを付けることをアプリケーションに許可する場合は、例外エンドポイントを使用して、対応するコメントをプラットフォームで 例外 としてタグ付けできます。 例外名はデータセットのフィルターとして使用できるため、モデル トレーナーは例外を確認して注釈を付け、モデルを向上させることができます。

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/exceptions' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "exceptions": [
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        },
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        }
      ]
    }'

完成です！

これで、Communications Mining の自動化チュートリアルを完了しました。 もちろん、独自のオートメーション アプリケーションは、ここで説明する内容とは異なる場合があります。 ご不明な点がございましたら 、サポートにお問い合わせください 。