AIでケース解決を加速させる
Task Intelligenceは、ケースのライフサイクル全体でエージェントのワークフローを自動化する一連のAI機能を提供します。
これは、定義されたユースケースに対してソリューションファーストのアプローチを使用しています。
Task Intelligenceの標準モデルの1つに、「Predict case field choices to reduce handle time」モデルがあります。このモデルは、新規ケースのケースフィールドを予測し、ケース解決時間を短縮するためのモデルの作成をガイドします。
注記： この記事ではCustomer Service Managementワークフローの例を使用していますが、これらの原則はITSMにも非常にうまく適用できます。
🎥 ビデオ: https://www.youtube.com/watch?v=k1bE1HHATak
ケースのメタデータが正確で整理されている場合、ケースを適切なグループまたはエージェントにルーティングすることは簡単です。例えば、影響を受ける製品またはサービス、優先度、言語、カテゴリ、およびサブカテゴリが分かっていれば、ServiceNowインスタンスでルールを適用し、ケースを迅速に解決するのに最も適格なアサインメントグループとエージェントを導き出すことができます。
しかし、私たちのユーザーは自然言語でコミュニケーションを取ります。そして通常、問題の説明を記入します。この非構造化データは、情報を読み取り、それに応じてケースを分類するために、人間の介入（レベル1サポート）を必要とします。このプロセスは時間がかかり、人件費がかさみ、エラーが発生しやすく、過去のケースに蓄積された豊富なナレッジを活用できていません。
Task Intelligenceは、過去のデータを活用することで、非構造化データから構造化データへの移行というこの課題を解決します。
このガイドでは、ドキュメントで概要が説明されているモデル作成プロセスの詳細について説明します。ストリーミングサービスケースの例を使用して、ケースが作成されたらすぐに適切なエージェントにルーティングすることを目標とします。
ケースのレビュー（データセットとも呼ばれます）
まず、現状を理解するためにデータを調査します。
Caseテーブルを確認しています。解決済みのケースでフィルタリングし、ケース数を評価しています。レコード数は1万件を少し超える程度です。良い知らせです。モデルのトレーニングには少なくとも1万件のレコードが必要です。
カテゴリ別にグループ化することで、レコードがカテゴリ間でどのようにバランスが取れているかを確認できます。
データはかなりバランスが取れているようですが、Feedbackカテゴリはレコード数が少ないため、このカテゴリはスキップされます。
機械学習は、履歴データからパターンを学習することで機能します。特定のカテゴリのケース数が少ない場合、モデルはパターンを学習できず、予測をスキップする可能性が高いです。新しいフィールドが追加されたり、既存のフィールドに新しい値が追加されたりする場合も同様です。
例えば、新しいカテゴリを追加した場合、モデルがどのケースがそのカテゴリに属するかを学習するのに時間がかかります。これらは、モデルが再トレーニングされる準備が整うまで、最初はスキップされます。
詳細については、最初のAIモデルを構築する前に従うべきベストプラクティスであるデータ品質分析の「クラス不均衡」セクションを確認してください。
モデルの作成
モデルを作成するには、Task Intelligence Admin Consoleに移動します:Task Intelligence for CSM > Setup。 「Predict case field choices to reduce handle time」モデルを使用します。
まず、EmailsとCasesのどちらかを選択します。
メールかケースか？
受信メールからケースを作成する場合、どちらかを選択できますが、どのデータがケースにコピーされるかを考慮する必要があります。メールレコードに、件名や受信者リストのように、より良い予測を行うために使用できるデータが含まれている場合は、Emailを使用することをお勧めします。
ここでは、Caseを選択します：「Predict case fields when a case is created」。
保存後、モデルのパラメータを定義します。
モデル名を指定します。テーブルを選択します。これはCustomer Service Caseテーブル、またはその拡張（ケースタイプ）のいずれかです。
条件
条件は2つの目的で使用されます。まず、レコードセット（選択したテーブル上）にフィルターを適用し、それをトレーニングに使用します。次に、デプロイ後、モデルはこれらの条件に一致するケースに対して予測を行います。唯一の例外はStateフィールドです。
StateがOpenまたはIn Progressのケースはまだ作業中であるため、含まれる情報は不正確であり、トレーニングに悪影響を与える可能性があります。これらは除外されるべきであるため、（プロセスに基づいて）ClosedまたはResolvedのケースを選択します。しかし、モデルが予測を行う際には、この条件は適用されません。
条件の一部として、特定の時間枠内に作成または解決されたケースのみを選択するためのフィルターを適用できます。
適切な時間枠の選び方
組織は時間とともに進化します。2年前に扱っていたケースの種類は、今日扱っているものとは異なります。モデルが最新の情報から学習していることを確認したいものです。役立つ経験則として、過去3か月分のデータを使用してモデルをトレーニングすることが挙げられます。 季節性に対応する組織で、毎年同じ時期に同じケースが繰り返し発生する場合は、過去13か月分のデータを含める必要があります。そうすることで、モデルが前年のデータを認識し、今年同じサイクルが発生したときにその学習を適用できるようになります。
予測したいフィールド、つまり出力フィールドとしてCategoryを定義します。この例では、Categoryフィールドがビジネス目標を達成するのに十分であると評価しましたが、ユースケースに応じてフィールドを追加できます。
入力フィールドの選び方
入力フィールドは、出力フィールドを予測するためにモデルがどのフィールドを考慮すべきかを伝えます。 選択する入力フィールドは、ケース作成時に予測が行われる時点で利用可能であり、値を持っている必要があります。例えば、Categoryを予測している場合、アサインメントグループは関連する入力フィールドではありません。なぜなら、その値はCategoryが決定されるまで利用できないため、モデルが役立つパターンを学習するのに役立たないからです。
また、入力フィールドを選択する際には、人間の視点から考えることが役立ちます。エージェントの立場になって考えてみてください。カテゴリを予測しようとしている場合、どのフィールドに注目して、どのカテゴリが関連しているかを判断しますか？Short description、description、および添付ファイルには役立つ情報が含まれるでしょう。一方で、priorityはカテゴリを特定するのに役立たないでしょうから、priorityは選択しません。
まとめると、入力フィールドを選択する際には、予測時に利用可能なデータを考慮し、人間の視点から考えてください。
モデルのトレーニング
テーブル、条件、出力フィールド、および入力フィールドが選択された後、レコード数を確認できます。データセットに十分なレコードが含まれている場合、モデルをトレーニングできます。
モデルのトレーニングには数分かかる場合があります。データセット内のレコードとフィールドが多いほど、トレーニングに時間がかかります。
モデルの評価
モデルがトレーニングされた後、いくつのフィールドが予測されたかについてのインサイトが得られます。 エージェントと比較した結果のパーセンテージサンプルも得られます。「View sample results」ボタンをクリックすると、確認するためのレコードのリストが開きます。
注記：「Different」とは、モデルがケースに含まれる値（エージェントが選択した値）とは異なる値を予測したことを意味します。それはより適切またはより悪い値である可能性があります。
そこで、次のように尋ねるかもしれません。「十分なレベルとは何か？」20%、50%、80%を目指すべきでしょうか？ 多くの人にとって残念なことかもしれませんが、実のところ、魔法の数字はありません。
「十分なレベル」はいくつかの変数によって決定されます。例えば、誤分類のコストはどのくらいか？予測フィールドにはいくつのオプションがあるか？現在の状況はどの程度ですか？
誤分類のコストとは何ですか？
安全衛生上の問題など、場合によっては、正確な分類と迅速な解決が不可欠です。このような状況では、誤分類のコストは非常に高く、したがって、「十分なレベル」のベンチマークは非常に高くなります。
予測フィールドにはいくつのオプションがありますか？
5つのオプションの中から正しい値を選択する方が、50万個のオプションの中から正しい値を選択するよりもはるかに簡単です。 priorityフィールド（値が5つしかありません）を予測している場合、モデルはその作業を非常にうまくこなすでしょう。 一方で、50万個の製品リストから適切な製品を選択するようにモデルに要求している場合、精度が低くなることが予想されます。
現在の状況はどの程度ですか？
エージェントが70%の確率でケースを正確に分類している場合、その機械学習モデルはエージェントの行動から学習しているため、70%というスコアは驚異的です。70%の精度を達成できれば、他のKPIに影響を与えることなく、エージェントのそのタスクを自動化できます。これは素晴らしい結果となるでしょう。
比較できるよう、ベンチマーク設定が役立ちます。
精度のベンチマーク
データはプラットフォーム上に存在するため、簡単な方法でインサイトを簡単に得ることができます。例えば、最初の割り当てがどの程度正確かを知りたい場合、再割り当て数の値を確認できます。再割り当て数が1であるケースの割合を計算します。それを現在の「正しい予測」率と見なすことができます。
以前、オートメーションのターゲットは？ – 機械学習を用いたデータドリブンアプローチによるインサイト生成と…という記事を書きました。「フェーズ1 – 戦略に対する構造化データのレビュー」を確認することをお勧めします。
カテゴリのような他のフィールドについては、それほど単純ではありません。カテゴリが誤って入力された場合でも、ケースがクローズされたときに常に修正されるわけではありませんでした。そのようなシナリオでは、人手によるレビューを行う必要があります。 リソースがある場合は、SMEに最後の500件の解決済みケースをレビューしてもらい、データ品質を評価してもらいましょう。その後、それをベンチマークとして使用できます。
AIはデータ（良いものも悪いものも）から学習します。したがって、モデルに入力されるデータ品質を理解することで、期待できる精度レベルを理解するのに役立ちます。
このトピックの詳細については、Task Intelligenceで「ケースフィールド予測」モデルをテストするの記事をご覧ください。さらに多くの情報があります！
環境設定とデプロイ
モデルの結果に満足したら、デプロイする準備ができています。予測が[USERNAME: user: we]にどのように提供されるかに関していくつかのオプションがあります。予測をケースに表示するか、バックグラウンドのみで実行するかを選択できます。 予測がケースに表示される場合、推奨として表示するか、値を自動入力できます。 モデルをバックグラウンドで実行することは、モデルをさらに評価するのに役立ちます。
モデルがサブプロダクション環境で作成された場合、メニューからエクスポートできます。
この点に関して、サブプロダクション環境で作業する場合、データが本番インスタンスを反映していること、更新されていること、すべてのフィールドが存在することを確認してください。データがモデルのトレーニングに使用されるため、そのプロセスにおいて入力は重要であることに留意してください。
ルーティングルールの適用
以前のフローを思い出すと、データが構造化されればルールを定義するのは簡単です。カテゴリに基づいてケースを適切なサポートグループにディスパッチするルールを作成できます。
このためには、Advanced Work Assignmentを使用します。Advanced Work Assignment > Settings > Queuesに移動します。AWAキューを作成し、フィルターと割り当てを適用します。
フィルターの一部として、「Prediction Status is not In Progress」を含める必要があります。これは、割り当てをトリガーする前にTask Intelligenceからの予測を待っていることを示します。
Advanced Work Assignmentの詳細については、クイックスタートガイドをご覧ください。
参考資料
ドキュメント
Task Intelligence ---|--- 
その他の関連記事
Data Quality Analysis a best practice you should follow before you build your first AI Model Where to target automation? – a data-driven approach with Machine Learning to generate insights and ... Testing a “Case Field Prediction” model in Task Intelligence 
よくある質問
免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。
この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/ai-intelligence-articles/task-intelligence-case-field-predictio...
