タクソノミーの構造を構築する

モデルのパフォーマンスがどの程度良好で、ビジネスの目的をどの程度達成しているかを決定する最も基本的な要因の 1 つが、タクソノミーの構造です (そのタクソノミー内の各ラベルでキャプチャされるものも含みます)。

したがって、モデルのトレーニングの前に、目標とするタクソノミーの構造を考慮することが重要です。一方で、トレーニングの進捗に従って、必要に応じてタクソノミーを適応、拡張、強化できる柔軟性もある程度必要です。これをデータ主導トレーニング アプローチと呼んでいます。

最終的には、タクソノミー内のラベルと、各ラベルに提供されたトレーニング例が、データセット全体を正確かつバランスよく反映する必要があります。一方で、すべてのラベルが、そのラベルが予測されたメッセージを何らかの形で明確に表していて有益である必要もあります。

ラベルを使用して非常に広範な概念、曖昧な概念、混乱した概念をキャプチャすると、ラベルのパフォーマンスが低下する可能性が高くなるだけでなく、ビジネス価値を提供する可能性も低くなります。ビジネス価値とは、その概念に関する有用な洞察を提供したり、プロセスを下流で完全または部分的に自動化するのに役立ったりすることです。

タクソノミーの構造の例

以下は、さまざまなユース ケース/業界に適用できる代表的なラベルを使用したタクソノミーの概要の例です。このすべてをご自身のモデルに適用できるわけではありません。

実際のユース ケースの例

ある会社では、さまざまな問題、問い合わせ、提案、苦情などについて、クライアントから毎年何百万通ものメールを複数の受信トレイで受信しています。

この会社は、顧客からのこのようなメールをワークフロー チケットに自動的に変換して、業務効率、プロセスの標準化、ビジネスの状況についての可視性を向上させることを決定します。これにより、指定されたプロセスを使用して所定のタイムライン内にメールを追跡して対処できるようになります。

これを実現するために、このプラットフォームを使用して、前述の構造化されていない受信コミュニケーションを解釈し、メールが関連するプロセスとサブプロセスに関する分類を提供することにします。この分類を使用することで、自動化サービスを使用して自動的に作成されるワークフロー チケットを更新し、チケットが確実に正しいチームや個人にルーティングされるようにします。

このユース ケースが可能な限り成功するようにし、例外 (間違った分類や、プラットフォームが確信を持って分類できないメール) の数を最小限に抑えるために、すべての受信メールを親ラベルと子ラベル (つまり [プロセス X] > [サブプロセス Y]) によって確実に予測する必要があります。

タクソノミーを構成する

すべての受信メールを [プロセス] と [サブプロセス] で分類することが目的である場合、タクソノミー内のすべてのラベルが次の形式に従う必要があります。

キャプチャするラベル

このユース ケースの場合、親ラベルと子ラベルの両方に対して信頼できる予測がないメールは例外として処理し、手動で確認してチケットを作成するために送信することができます。また、信頼度できる親ラベルの予測はあるものの、信頼できる子ラベルの予測がない場合でも、これを使用して、メールを部分的にルーティングするかチケットを作成し、手動で追加の作業を行って関連するサブプロセスを追加できます。

この前者にあてはまる場合を考えてみましょう。[プロセス] > [サブプロセス] の形式の信頼度の高い予測がないメールはすべて手動で処理する例外にする場合、モデルのトレーニング時に各ラベルに提供する例すべてに、この形式が反映されていることを確認する必要があります。

タクソノミー内の各親ラベルは、メールの内容に関連する広範なプロセスと関係がある必要があります。たとえば、「請求」です。各子ラベルは、親ラベルの下に存在する、より具体的なサブプロセスである必要があります。たとえば、「請求 > ステータス リクエスト」です。

注:

各ラベルでキャプチャしようとしている内容を具体的に指定する必要があります。

「一般的な問い合わせ」や「その他すべて」のようにきわめて広範なラベルを使用して、さまざまな個別のトピックを大量にグループ化する場合、ピン留めされた例の間に明確なパターンや共通性がないと、ラベルがまったく役に立たない可能性があります。

このユース ケースでは、ワークフロー チケットを作成して「一般的な問い合わせ」や「その他すべて」として分類した場合、ビジネス価値もあまり得られません。依然として、チケットに対応する前に誰かがチケットを注意深く読み、どういう内容で、自分のチームに関係があるかどうかを理解する必要があります。

これでは時間の節約のメリットがなくなり、会社はチームの実際の作業に関する有用な MI を得られません。

注:

これは単に、特定のユース ケースにおいてタクソノミーをどのように構築するかを示した例であり、万能のアプローチではありません。どのプロジェクトにもラベルの固有のタクソノミーが必要であり、タクソノミーは具体的なユース ケース、データセット、目的に大きく依存します。