検証の仕組み

必要なユーザー権限:「ソースの表示」および「ラベルの表示」

検証では、データセットに関連付けられているラベル モデルとエンティティ モデルの両方のパフォーマンスが評価されます。

特にラベル モデルについては、次のようなさまざまなパフォーマンス要因をテストして、全体的な「モデルの評価」が計算されます。

• モデルが、データセット内のトレーニング データのサブセットを使用して、タクソノミー内の各ラベルをどの程度適切に予測できるか

• データセット全体が有益なラベル予測によってどの程度網羅されているか

• トレーニング データがどのように割り当てられているか、およびデータセット全体をどの程度適切に代表しているかという観点から、トレーニング データのバランスがどの程度取れているか

ラベルのパフォーマンスの評価方法

各ラベルをどの程度適切に予測できるかを評価するため、最初に、データセット内の確認済みの (ラベル付けされた) メッセージが 2 つのグループに分割されます。トレーニング データの多数派のセットと、テスト データの少数派のセットです。

次の図では、色付きのドットは、データセット内のラベル付けされたメッセージを表しています。この分割は、眼セージがデータセットに追加されるときにメッセージの ID によって決定され、データセットの存続期間を通して一貫性が維持されます。

その後、プラットフォームはトレーニング セットのみをトレーニング データとして使用して自身をトレーニングします。

続いて、このトレーニングに基づいて、テスト セット内のメッセージに適用すべきラベルを予測しようと試みます。また、適合率と再現率の両方について、人間のユーザーが適用した実際のラベルに照らしてその結果を評価します。

このプロセスに加えて、プラットフォームは、ラベルがどのように割り当てられたか (つまり、ラベルを適用するときにどのトレーニング モードが使用されたか) も考慮して、偏った方法でラベル付けされているか、それともバランスのとれた方法でラベル付けされているかを理解します。

その後、最新のモデル バージョンのラベルのパフォーマンスに関するライブ統計情報が [検証] で公開されますが、以前にピン留めされたモデル バージョンの過去のパフォーマンス統計情報も表示できます。

カバレッジの評価方法

モデルがどの程度十分にデータを網羅しているかを理解するために、データセット内にあるすべての未確認のデータと、その未確認のメッセージそれぞれに対して行われた予測が調べられます。

次に、有益なラベルが少なくとも 1 つ予測されているメッセージの合計の割合を評価します。

有益なラベルとは、他のラベルと一緒に割り当てられている頻度を調べることで、スタンドアロンのラベルとして有用であるとプラットフォームが理解したラベルのことです。常に別のラベルとともに割り当てられているラベル (単独で割り当てられることのない親ラベルや、常に別のラベルとともに割り当てられている場合の「緊急」) は、スコアの計算時に重み付けが下げられます。

バランスの評価方法

プラットフォームによるモデルの バランスの評価では、基本的に、トレーニング データとデータセット全体との間にアンバランスの原因となり得るラベル付けの偏りがないかを探します。

このために、ラベル付けの偏りモデルを使用して、確認済みのデータと未確認のデータを比較し、ラベル付けされたデータがデータセット全体を代表していることが確認されます。データが代表的ではない場合、モデルのパフォーマンス指標は誤解を招くものになり、信頼できない可能性があります。

ラベル付けの偏りは通常、ラベルの割り当てに使用したトレーニング モードのバランスがとれていなかった結果です。特に、[テキスト検索] を使用しすぎて「シャッフル」モードを十分に使用していない場合にあてはまります。

「リバランス」トレーニング モードは、確認済みのセット内の代表性の低いメッセージを示します。このモードで例にラベル付けすると、データセット内のアンバランスにすばやく対処できます。

検証プロセスが実行されるタイミング

データセット内で何らかのトレーニングを完了するたびにモデルが更新され、すべてのメッセージで新しい予測を提供します。これと並行して、モデルのパフォーマンスも再評価します。つまり、新しい予測が準備できるころには、最新のものを含め、新しい検証の統計情報も利用可能になります (ただし、一方のプロセスに他方よりも時間がかかる場合もあります)。

注: 既定では常に、計算が完了した最新の検証統計が表示され、新しい統計情報の計算がまだ完了していない場合は通知されます。