- API ドキュメント
- CLI
- 連携ガイド
- ブログ
- 機械が単語を理解する方法:NLPに埋め込むためのガイド
- トランスフォーマーによるプロンプトベースの学習
- 効率的な変圧器II:知識蒸留と微調整
- 効率的な変圧器I:注意メカニズム
- 階層的な教師なしインテントモデリング:トレーニングデータなしで価値を得る
- Communications Mining による注釈バイアスの修正
- アクティブ ラーニング: より優れた ML モデルを短時間で実現
- それはすべて数字にあります-メトリックを使用してモデルのパフォーマンスを評価します
- モデルの検証が重要な理由
- 会話型データ インテリジェンスのための Communications Mining と Google AutoML の比較
それはすべて数字にあります-メトリックを使用してモデルのパフォーマンスを評価します
機械学習モデルを構築してトレーニングするときは、パフォーマンスを理解することが不可欠です。 トレーニング データとタスクによっては、最も高度なモデルであっても誤った予測が生成される可能性があり、その結果、誤解を招く分析や誤った自動化フローが発生する可能性があります。
例を手動で確認することは、特に数百万のデータポイントを持つデータセットでは実用的ではありません。 代わりに、Communications Mining は、モデルの分析と障害の特定に役立つ複数のメトリックを継続的に計算および表示します。
ただし、状況によっては、メトリックが予期しない動作をすることがあります。 このブログ投稿では、メトリックの使用時に発生するいくつかの問題と、プロセスを簡素化するために Communications Mining が使用するいくつかのソリューションについて説明します。
Communications Mining を使用すると、ユーザーは通信データのカスタム マシン ラーニング モデルを構築できます。このプロセスでメトリクスをどのように使用するかを理解するには、特定のユースケースを想像すると便利です。
毎日何千もの電子メールを受信する可能性のある銀行の共有メールボックスを考えてみましょう。 Communications Mining を使用してこれらのメールを自動的にトリアージし、メールボックスを使用する従業員がより効率的に作業できるようにします。
実際のユース ケースでは、メールボックスの対象分野の専門家は、さまざまなワークフローを追跡および自動化するために何百ものラベルを作成します。 ここでは、単純化されたケースを検討します
-
緊急メール。 これらは、従業員の電子メールクライアントで検出され、フラグが立てられる必要があります。
-
自動生成されたメール。これらを検出してアーカイブフォルダに移動し、受信トレイをクリアに保つ必要があります。
Urgent
ラベルと Auto Generated
ラベルを作成し、いくつかのサンプルメールに注釈を付けます。 Communications Mining は、メールに適用されるラベルを予測する ML モデルを自動的にトレーニングします。 このモデルは、ライブ データの電子メールのトリアージ タスクを自動化するために使用されます。
最も低いレベルでは、メトリックは、ユーザーが作成した Yes/No ラベル注釈の形式で、ラベル予測と正解を比較します。
Communications Mining のモデルでは、ラベルの存在に関するバイナリ (はい/いいえ) 予測は提供されません。 代わりに、00 から 11 までの数値を返します。 これは、ラベルが適用されるというモデルの 信頼度 を表します。
モデルの信頼度の値は、しきい値を使用してバイナリ ラベル予測に変換されます。 これは単に 00 から 11 までの数値で、ラベルの信頼度の値を分割します。
-
しきい値を超えると、ラベルが適用されると予測されます(「肯定的な」例)。
-
しきい値を下回ると、ラベルが適用されると予測されません(「否定的な」例)。
注釈、ラベル予測、およびしきい値を使用して、一連の例を 4 つの異なるグループに分割できます
-
真陽性 (TP)。モデルによってラベルが予測され、そのラベルが適用されます。
-
誤検知 (FP)。モデルはラベルを予測しますが、ラベルは適用されません。
-
偽陰性(FN)。モデルはラベルを予測せず、ラベルが適用されます。
-
真陰性(TN)。モデルはラベルを予測せず、ラベルは適用されません。
ラベルのしきい値を変更すると、どのメールがこれら 4 つのグループのそれぞれに分類されるかに影響し、多くのメトリックの開始点として機能します。
精度
モデルの精度を見たくなるかもしれません。
すべてのモデル予測のうち、どの部分が正しいか。
これは合理的であるように思われ、精度はAIパフォーマンスの頼りになる指標と見なされることがよくあります。 ただし、場合によっては、精度が欺瞞的になることがあります。
Urgent
ラベルを予測しない不適切なモデルの場合、精度スコアは次のようになります。
このスコアは高いですが、モデルのパフォーマンスは実際には低くなっています。 精度は、 Urgent
や Auto Generated
などのまれなラベルを持つタスクのパフォーマンスを過大評価する可能性があります。
適合率と再現率
Urgent
ラベルの同じ例を使用すると、モデルは精度と再現率の値を00に取得します。 これは、このモデルのパフォーマンスがいかに低いかを示しています。
これらの指標は、クラスの不均衡と呼ばれる、異なる頻度で発生するラベルでより優れたパフォーマンスを発揮します。 通信データのトピックが同じレートで発生することはめったにないため、Communications Mining のメトリックでこれを考慮することが重要です。
特定のしきい値について、精度と再現率の値を計算できます。ただし、実際には、これら 2 つのメトリックの間にはトレードオフがあります
-
高精度。 誤検知はほとんど必要ありません。 これは閾値が高いことを意味し、モデルの信頼度が 1 に近い例のみが「陽性」となります。
-
高い想起。 偽陰性はほとんど必要ありません。 これは、閾値が低いことを意味するため、モデルの信頼度が 0 に近い例のみが「否定的」となります。
精度 または 再現率について良いスコアを取得するのは簡単です (それぞれ 00 に近いしきい値または 11 に近いしきい値を設定することによって)。 しきい値の設定は 2 つの間のバランスを表し、最適なトレードオフはラベルの使用目的によって異なります。
コストのバランスを取る
Auto Generated
ラベルの精度を高くする必要があります (誤検知はほとんどありません)。
Urgent
ラベルの再現率が高い(偽陰性が少ない)必要があることを意味します。
ラベルの最適なしきい値は、モデルが間違いを犯した場合のコストを最小限に抑えます。
議論のために、銀行が緊急の電子メールを見逃すたびに5ポンド(偽陰性)、誤って自動生成としてマークされた電子メール(誤検知)ごとに10ポンドかかると仮定します。 銀行はまた、従業員に時給20ポンドを支払い、誤った緊急および見逃された自動生成された電子メールを1時間あたり100の割合で削除します。
1 日に 1000 通の電子メールを受信するメールボックスの場合、しきい値を調整して、1 日あたりの予想されるコストを最小限に抑えることができます。
精度と再現率には、各ラベルのしきい値が必要です。これらのしきい値の設定は、特に数百のラベルを持つ可能性がある大規模なデータセットの場合、時間がかかります。 最適なしきい値なしで機能するメトリックの方が便利です。
完璧なモデル
すべてのラベルを正しく予測する架空の「完璧な」モデルを考えてみましょう。 このモデルの精度と再現率が 100% のしきい値があります。
このしきい値を超えると、一部の陽性が誤って陰性として識別されます。 これにより精度は低下しますが、再現率は 100% に保たれます。 同様に、しきい値を下げると、ネガティブが誤ってポジティブとしてタグ付けされます。 これにより、再現率は低下しますが、精度は 100% に保たれます。
このロジックにより、完全モデルの精度/再現率曲線は、角が点(100%,100%)(100%,100%)にあるボックス形状になります。 不完全なモデルは、この完全なモデルの下に曲線を持ちます。
つまり、モデルの改善は、精度/再現率曲線の下の 面積 を増やすことと同じです。
平均適合率
ユーザーがしきい値を選択し、精度と再現率のトレードオフを調べることはできますが、平均精度は、Communications Mining でモデルをスコアリングするために使用する主要なメトリックです。 これは、特に偽陽性と偽陰性のコストが同様の場合に、平均してうまく機能します。 精度と再現率を使用するため、クラスの不均衡に対して堅牢ですが、ユーザーはそれを計算するためにしきい値を設定する必要はありません。
この指標は、次の 2 つの方法で [検証] ページで報告します
-
平均精度。 各ラベルについて報告される個々のラベルのパフォーマンス。
-
平均平均精度。 すべてのラベルの平均化された各ラベルの平均精度。 これにより、データセット内のすべてのラベルのパフォーマンスが測定されます。
メトリックを使用してモデルのパフォーマンスを推定しますが、この推定値は、計算に使用するデータによってのみ有効です。トレーニングされたテスト セットとは別のテスト セットでモデルを評価しても、そのテスト セットはユーザーが注釈を付けた例から取得されます。 そのデータがターゲット タスクを反映していない場合、メトリックは誤解を招く可能性があります。
銀行の例では、月曜日に送信された緊急メールと金曜日に送信された自動生成されたメールにのみ注釈を付けるとします。 これらの例でトレーニングされたモデルは、メールが送信された日からラベルを完全に予測できます。
モデルの平均精度は、ユーザーが注釈を付けたデータに対して常に機能するパターンを識別するため、高くなります。 ただし、緊急および自動生成された電子メールはいつでも送信できます。 ライブメールでは、パターンは機能せず、モデルのパフォーマンスが低下します。
そのため、Communications Mining でモデルをスコアリングするときには、精度、再現率、平均値だけが返されるわけではありません。 代わりに、 モデル評価を計算します。
モデルの評価では、平均精度だけでなく、さまざまなパフォーマンス要因が考慮されます。 この全体的なビューにより、単一のメトリックを使用することの落とし穴が軽減され、明確なモデルフィードバックが提供されます。 今後の投稿では、モデルの評価についてさらに詳しく説明し、より短い時間でより良いモデルを構築するためにそれらがどのように使用されているかについて説明します。