- 基本情報
- 管理
- ソースとデータセットを管理する
- モデルのトレーニングと保守
- データ要件を理解する
- トレーニング
- 一般フィールドを使用する
- 生成 AI による抽出
- 分析と監視を使用する
- オートメーションと Communications Mining
- ライセンス情報
- よくある質問など
Communications Mining ガイド
データ要件を理解する
このページでは、トレーニング エクスペリエンスを最適化し、分析と自動化によって提供される価値を最大化するために必要なコミュニケーション データの量のガイドラインを示します。
- 投資利益率 (ROI)
- 複雑さ
- 技術的な制限
Communications Mining™ の実装を最大限に活用するには、大量のユース ケースから開始することをお勧めします。このようなケースでは、履歴分析、ライブ監視、自動化のいずれにおいても、大量のメッセージ データを効率的に処理できる Communications Mining の能力を活かすことができます。
メッセージの量が増えても、ユース ケースをデプロイするのに必要な労力が大幅に増加することはありません。したがって、大量のユース ケースのほうが、少量のユース ケースと比較して実装の労力の点で投資利益率が高い傾向があります。リソースに限りがある組織や、実装に外部のサポートが必要な組織にとって、この点は重要です。
ただし、ビジネス価値が高い少量のシナリオがある場合は、そのユース ケースも検討する必要があります。少量のユース ケースの多くは技術的に実現可能であり、無視すべきではありません。
多くのユース ケースには、ラベルおよび抽出するフィールドの数や複雑さの点で一定レベルの複雑さがあり、非常に少量のメッセージにはあまり適しません。その理由は、多様で複雑な概念やフィールドから成るデータセットでは例が十分になく、Communications Mining の専門化されたモデルを効果的に微調整および検証できない可能性があるためです。これは、生成 AI によるアノテーションで提供される自動トレーニングと、モデル トレーナーがアノテーションを行う追加の例のどちらにも当てはまります。
ユース ケースによっては技術的に実現可能で十分な例が含まれることもありますが、量が少ないと、モデル トレーナーのアノテーション エクスペリエンスが低下することがあります。Communications Mining のアクティブ ラーニング モードでは、データ プールが大きいほど、アノテーションを行う有用な例を簡単に特定して明らかにすることができます。データ プールが小さいと、タクソノミー全体を網羅する質の高い例を十分に作成できない可能性があります。質の高い例が少ないと、ユーザーはわかりにくい例や複雑な例にアノテーションを行わざるを得なくなります。
複雑さと ROI に基づく考慮事項を踏まえてユース ケースを評価および実装する前に、Communications Mining の技術的な制限について検討することが重要です。
Communications Mining でクラスターを生成するには、1 つのデータセット内に 2048 個以上のメッセージが必要です (データセットは複数の類似するソースで構成できます)。メッセージ数が 2048 個未満のデータセットでは、クラスターと、クラスターに対して生成されるラベルの提案を除き、Communications Mining のすべての機能を使用できます。
メッセージが 2048 個未満のユース ケースは、ラベル/フィールドの数と複雑さの点で非常にシンプルである必要があります。また、大量のユース ケースと比較して、微調整や検証のためにアノテーションを行う必要がある合計メッセージ数の割合がはるかに高くなることも予想されます。一部のラベルやフィールドの発生頻度が高くない場合、例が不十分であるためラベルやフィールドにアノテーションを行うことができない可能性があります。
検証データを意味のあるものにするには、Communications Mining では、ラベルとフィールドにつき少なくとも 25 個のアノテーション済みの例が必要です。したがって、利用可能なデータから少なくともこの数の例を取得できることが重要です。
以下の推奨事項は、データ量は少ないものの、価値が高い/複雑さが低いユース ケースに関係します。
一般に、ユース ケースの複雑さがメッセージ データの量に見合っている場合、ユース ケースは期待どおりに機能します。通常、非常に量が少ないユース ケースは非常にシンプルである一方、量が多いユース ケースはより複雑になる可能性があります。
場合によっては、1 年分を超える履歴データを同期すると、トレーニングに十分な、質の高い例を取得できます。これには、傾向とアラートの点で分析が向上するという利点もあります。
メッセージ数が 20,000 個未満 (履歴の量または年間のスループットで換算) のユース ケースは、複雑さ、ROI、およびユース ケースをサポートおよび有効化するために必要な労力の観点から慎重に検討する必要があります。このようなユース ケースは、これらの考慮事項に基づくて不適格になる可能性がありますが、それでも作業を進めるのに十分なビジネス価値を提供できます。
すべてのユース ケースは固有であるため、あらゆる複雑さのシナリオに合致する単一のガイドラインはありません。ラベルとフィールド自体は、理解と抽出の点で非常に単純なものから複雑なものまで多岐にわたります。
次の表は、ユース ケースの複雑さに関する大まかなガイドラインをまとめたものです。
複雑さ | ラベル | 抽出フィールド | 一般フィールド |
---|---|---|---|
非常に低い | ~ 2 - 5 | N/A | 1 - 2 |
低 (Low) | ~ 5 - 15 | 1 - 2 (ラベルが少ない場合) | 1 - 3 |
中 | 15 - 50 | 1 - 5 (ラベルが複数ある場合) | 1 - 5 * |
高 (High) | 50 以上 | 1 - 8+ (ラベルの割合が高い場合) | 1 - 5 * |
* 抽出フィールドを使用するユース ケースでは、一般フィールドではなく抽出フィールドを利用する必要があります。抽出フィールドを使用しない場合は、一般フィールドが増えることが予期できますが、同等の値は付加されない可能性があります。
メッセージ数 * | 制限事項 | 推奨 |
---|---|---|
次の値より小さい |
| 次の目的にのみ使用することをお勧めします。
|
2048 - 20,000 |
|
主に次の目的に使用することをお勧めします。
|
20,000 - 50,000 |
|
主に次の目的に使用することをお勧めします。
|
通常、トレーニング例の取得元にする履歴データの量において、アノテーションが行われている合計量の割合はごくわずかです。この割合は通常、量が少なく複雑さが高いユース ケースほど高くなります。