- 基本情報
- 管理
- ソースとデータセットを管理する
- モデルのトレーニングと保守
- 分析と監視を使用する
- オートメーションと Communications Mining
- よくある質問など
ラベルの階層とベスト プラクティス
モデルのトレーニングを開始する前に、ラベルの命名と構成や、そのラベルで実際に何をキャプチャするのかなど、タクソノミーの作成へのアプローチ方法を理解しておくことが非常に重要です。この記事では、ラベルの命名から始めて、これらの各トピックについて説明します。
ビジネスの目標を達成するためにタクソノミーを適切に構成することがなぜこれほど重要であるかについては、こちらの記事で説明します。
ラベルの名前を決めるのは、非常に困難か、時間がかかりそうに思えるかもしれませんが、そうする必要はありません。
まず、ラベルの名前が何であるかは重要ではありません。UiPath のモデルにとっては、ラベル名自体は単なる数字です。重要なのは、ラベル名がビジネスの目的を果たし、ラベルがキャプチャする特定の概念の説明として有用であることです。
ラベル名はいつでも変更可能であり (方法についてはこちらを参照)、必要であれば階層のレベルを追加できるので、初めてモデルを構築するときに完璧な名前を考えようとして時間をかけすぎないでください。
ラベルに名前を付ける際には、タクソノミー内でのラベルの階層も決定します。あるラベルの概念が、より広範な親概念のサブセットである場合にキャプチャするには、階層の複数のレベルを「>」で区切ってラベルに設定できます。
したがって、次のようなラベル構造にすることができます。(以下の画像の例もご覧ください)。
- [親ラベル]
- [親ラベル] > [子ラベル]
- [親ラベル] > [ブランチ ラベル] > [子ラベル]
3 レベルを超える階層を追加することはできますが、トレーニングがいっそう複雑になるため、頻繁に行うことはお勧めしません。場合によっては必要になることもありますが、ベスト プラクティスとは考えないでください。
概念的には、あるラベルを別のラベルの下に入れ子にする場合、入れ子にしたすべてのラベルが、その上にあるラベルのサブセットであることが重要です。この入れ子 (階層のレベル) は、ラベル名を入力するときに「>」を使用して作成します。
次の図に、この点をベン図で説明します。
繰り返しますが、後でモデルのトレーニング プロセスでラベルの名前を変更することで、階層のレベルを追加できます。
これを理解するために、上の図の「子ラベル X」を例として使用しましょう。
「子ラベル X」がメッセージに適用されると予測する場合、モデルは同時に「ブランチ ラベル C」と「親ラベル 1」も予測します。これは、「子ラベル X」がこれらのサブセットであるためです。
ただし、階層のレベルごとに特異性のレベルが上がるため、モデルは、より具体的な子ラベルよりも親ラベルまたはブランチ ラベルが適用されると確信を持って判断できます。つまり、そのモデルは、同じ階層内でラベルの予測ごとに異なる確率を割り当てることができます。
したがって、ある特定のメッセージの場合、モデルは次のようになります。
- 99% の信頼度で「親ラベル 1」が適用される
- 88% の信頼度で「ブランチ ラベル C」が適用される
- 75% の信頼度で「子ラベル X」が適用される
あるメッセージに対して子ラベルが予測される場合、モデルは常に親ラベル (および該当する場合はブランチ ラベル) を予測する必要があります。その際の信頼度は少なくとも子ラベルと同じで、超えることはありません。
モデルは各ラベルを個別に予測するため、親ラベルでは、抽象的なトピックや概念ではなく本当のトピックや概念をキャプチャすることが重要です。
たとえば、特定のプロセスに関連する子ラベルをグループ化する場合に、「プロセス」のような親ラベルを使用するのは、親ラベルとして適切な選択肢ではありません。「プロセス」自体は抽象的な概念であり、モデルが単独で適切に予測するものではありません。ビジネスのコンテキストでは、何かと関係がある具体的なプロセスの名前であれば (また、メッセージのテキストから識別可能な名前であれば)、有用な親ラベルになります。こうすることで、有用なブランチ ラベルと子ラベルを、メインの親プロセスと関係があるサブプロセスにすることができます。
親ラベルにする概念と子ラベルにする概念を選択する方法
タクソノミーの構造に関して難しい選択をしなければならない場合もあります。たとえば、ラベルを親ラベルにすべきか、子ラベルにすべきかを選ぶのに悩む場合があります。論理的には、広範な親カテゴリとそれ専用のサブカテゴリにすることも、別の広範な親カテゴリの具体的なサブカテゴリにすることもできるためです。
たとえば、ホテルのレビューで構成されるデータセットを想像してください。休暇とホテルのさまざまな側面 (レストラン、バー、客室、アクティビティなど) の価格について論じたレビューが多数あります。
論理的には、「価格設定」を親ラベルとして設定し、価格設定の具体的な側面 (例: レストラン) を子ラベルとして設定できます。
その一方で、「レストラン」「客室」のような具体的な側面に関連する親ラベルを設定し、そのそれぞれの下に「価格」を子ラベルとして設定することもできます。
どちらを選ぶべきか
決定にあたっては、いくつかの点を考慮すると役に立ちます。
- この広範なトピックに関連する、キャプチャしたい概念がほかにも多数ある可能性があるか。「はい」の場合は、親ラベルにすることをお勧めします。
- MI またはレポートの観点から追跡すべき最も重要なことは何か。前述の例を考慮し、価格設定とそのサブカテゴリを話題にしている正確な人数を Communications Mining の分析で明確に確認できるほうが役に立つか。それとも、客室、レストラン、アクティビティなどについてのフィードバックの全体的な統計情報を、価格設定をその 1 つの側面として確認できるほうが役に立つか。
こうした状況では必ずしも正解や不正解があるわけではありません。結局は、自分と自分のビジネスにとって何がより重要かということです。
ここまでは、ラベルに名前を付けて階層状に構成する方法について説明してきましたが、正確に何をラベルでキャプチャすべきなのか、まだ疑問に思っているかもしれません。
Communications Mining は自然言語処理ツールであることを覚えておくことが重要です。ラベルが割り当てられたメッセージをそれぞれ読み取って解釈し、どうすれば、主にメッセージ内のテキストに基づいてそのラベルの概念を識別できるかについての理解を形成し始めます。
各ラベルに多様で一貫性のある例を追加すると、モデルはそのラベルの概念についての理解を改善します。ただし、モデルのパフォーマンスが良好になった後に、さらにラベルを追加していくと、効果は徐々に薄れていきます。ラベルについての信頼度の高い予測を大量に承認しても、モデルに新しい情報は提供されません。このような方法は避ける必要があります。
Communications Mining は、メッセージの言語を使用して、何がラベルの概念を構成しているのかを理解・識別するので、ラベルが適用されるメッセージのテキスト (つまり言語) からラベルを明確に識別できる必要があります。メール メッセージの場合は、メールの件名および本文がこれにあたります。
以下のメールの例を見てみましょう。ここには「Cancellation > Confirmation > Termination」というラベルが適用されています。このラベルは、メールの件名と本文から明確に推測可能です。
このモデルでは、トレーニング時に特定のメタデータ プロパティ、特に感情の理解に役立つ NPS スコア (顧客のフィードバックのデータセットの場合) などを実際に考慮に入れることができますが、Communications Mining モデルが考慮する最も重要なデータはメッセージのテキストです。
このモデルでは、メールの送信者や受信者の具体的なアドレスは考慮されないため、メールのメッセージに適用するラベルを決める際には、一切使用しないでください。
つまり、各ラベルがキャプチャしようとしている内容が具体的であることが重要です。具体的でないと、モデルはラベルの概念を予測するのに役立つ傾向やパターンをその言語で識別できません。
「一般的な問い合わせ」や「その他すべて」のようにきわめて広範なラベルを使用して、さまざまな個別のトピックを大量にグループ化する場合、モデルに提供する例の間に明確なパターンや共通性がないと、ラベルがまったく役に立たない可能性があります。
モデルでラベルを適切に予測するには、ラベルでキャプチャする各概念について、異なる表現の類似する例が複数必要です。したがって、極めて広範なラベルで適切に予測するには、大量の例が必要になります。
通常は、広範なラベルを分割して明確なラベルに分けるほうがはるかに効率的な方法です。これは「[その他すべて] > [さまざまな子ラベル]」がある場合にもあてはまります。
(非常に広範な親カテゴリと比較して) 子ラベルのほうがより具体的で明確に識別可能であるため、モデルが子ラベルをより適切に識別できる場合、親ラベルを予測する能力も実際に大幅に向上できます。
