人間参加型の検証

概要

Communications Mining の人間参加型 (HITL) は、モデルの信頼度が不十分な場合に、モデル トレーニング データの整合性を維持しながら、運用上の意思決定をサポートするように設計されています。

運用中のオートメーションでは、このモデルを使用して、受信コミュニケーションをリアルタイムで分類します。モデルが正しいラベルを確実に予測できない場合、業務プロセスを中断なしに続行できるよう、一時的に人間のユーザーが予測を検証または修正します。

次のものを区別することが重要です。

• エンド ユーザーが Action Center で実行する操作検証。
• モデルのトレーナーが後から実行するモデルのトレーニングと保守。

HITL 検証により、次のことが保証されます。

• 修正されたラベルを使用してオートメーションをすぐに進めることができます。
• コミュニケーションは、ビジネスの観点から正しく処理されます。

ただし、HITL 検証では、モデルの再トレーニングや更新は直接行われません。人間の介入が必要なコミュニケーションは明示的に例外としてマークされます。これにより、モデル トレーナーは後から、継続的なモデル メンテナンス プロセス (例外トレーニング) の一環として、制御された方法でコミュニケーションを確認してアノテーションを行うことができます。

この分離により、次のことが保証されます。

• 高品質で一貫性のあるトレーニング データ。
• 不完全または偏ったアノテーションに対する保護。
• ライブ オートメーションのパフォーマンスに影響を与えることなく、モデルを継続的に改善する。

ワークフロー

1. ロボットがストリームから通信を受信します。
2. ロボットはモデルの信頼度を評価します。
3. 信頼度がしきい値を下回っている場合は、検証が必要です。
4. Action Center に検証タスクが作成されます。詳しくは、「 フォーム タスクを作成する」をご覧ください。
5. コミュニケーションの内容と予測されたラベルは、人間のユーザーに提示されます。
6. 人間が Action Center でラベルを検証または修正します。
7. これらの修正は、モデルのトレーニングではなく、ダウンストリーム処理にのみ使用されます。
8. ロボットは、API を介して通信を例外としてタグ付けします。これにより、モデル トレーナーが後で確認できるようにメッセージにフラグが付けられます。詳しくは、「 例外にタグを付ける」をご覧ください。
9. ロボットはすぐに処理を続行します。通信はストリームを介して再処理されません。
10. 修正されたラベルは、Communications Mining や下流のシステムへのアップロードなどの運用目的で適用されます。
11. 後で、モデル トレーナーが例外を確認します。トレーナーが Communications Mining でメッセージに正しくアノテーションを行っている。これらのアノテーションは、今後のトレーニング サイクルに含まれる可能性があります。

注:

Action Center での検証の修正では、モデルは自動的には再トレーニングも更新もされません。