- はじめに
- アクセス制御と管理
- ソースとデータセットを管理する
- モデルのトレーニングと保守
- データ要件を理解する
- トレーニング
- 一般フィールドを使用する
- 生成 AI による抽出
- 分析と監視を使用する
- オートメーションと Communications Mining™
- 開発者
- 機械が単語を理解する方法:NLPに埋め込むためのガイド
- トランスフォーマーによるプロンプトベースの学習
- 効率的な変圧器II:知識蒸留と微調整
- 効率的な変圧器I:注意メカニズム
- 階層的な教師なしインテントモデリング:トレーニングデータなしで価値を得る
- Communications Mining™ でアノテーションの偏りを修正する
- アクティブ ラーニング: より優れた ML モデルを短時間で実現
- それはすべて数字にあります-メトリックを使用してモデルのパフォーマンスを評価します
- モデルの検証が重要な理由
- 対話データ分析 AI としての Communications Mining™ と Google AutoML を比較する
- ライセンス
- よくある質問など

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 個のアノテーション済みの例が必要です。したがって、利用可能なデータから少なくともこの数の例を取得できることを確認してください。
以下の推奨事項は、データ量は少ないものの、価値が高いか複雑さが低いユース ケース、あるいはその両方のユース ケースに関係します。
一般に、ユース ケースの複雑さがメッセージ データの量に見合っている場合、ユース ケースは期待どおりに機能します。非常に量が少ないユース ケースは非常にシンプルである一方、量が多いユース ケースはより複雑になる可能性があります。
In some instances, synchronizing more than one year of relevant data can help source sufficient quality examples for training. This also provides the benefit of greater analytics in terms of trends and alerts.
- Data that is not too old, for example, over two years old.
- Data that is relevant to your use case. For example, if outbound emails are not relevant to you, the system should not count them.
Use cases with fewer than 20,000 messages, in terms of historical volumes or annual throughout, should be carefully considered in terms of complexity, ROI, and the effort required to support and enable the use case. While there is a chance that such use cases may be disqualified based on these considerations, they can still provide sufficient business value to proceed with.
ユース ケースの複雑さのガイドライン
すべてのユース ケースは固有であるため、あらゆる複雑さのシナリオに合致する単一のガイドラインはありません。ラベルとフィールド自体は、理解と抽出の点で非常に単純なものから複雑なものまで多岐にわたります。
次の表は、ユース ケースの複雑さに関する大まかなガイドラインをまとめたものです。
| 複雑さ | ラベル | 抽出フィールド | 一般フィールド |
|---|---|---|---|
| 非常に低い | 約 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 未満 |
| 次の目的にのみ使用することをお勧めします。
|
| 2048 - 20,000 |
|
主に次の目的に使用することをお勧めします。
|
| 20,000 - 50,000 |
|
主に次の目的に使用することをお勧めします。
|
*relevant data volumes from which training examples will be sourced typically have only a small proportion of total volumes annotated. This proportion is usually higher on lower volume and higher complexity use cases.