予測 ML またはジェネレーティブ AI のアプローチを使用して問題が最適に解決されることを確認したら、問題を ML の用語で捉える準備が整います。ML 用語で問題を定義するには、次のタスクを完了します。
- 理想的な結果とモデルの目標を定義します。
- モデルの出力を特定します。
- 成功指標を定義する。
理想的な結果とモデルの目標を定義する
ML モデルから独立した理想的な結果とはつまり、プロダクトまたは機能に実行させたい正確なタスクは何か。これは、以前に目標を設定するセクションで定義したステートメントと同じです。
モデルに求めることを明示的に定義することで、モデルの目標を理想的な結果に関連付けます。次の表に、架空のアプリに対する理想的な結果とモデルの目標を示します。
アプリ | 理想的な結果 | モデルの目標 |
---|---|---|
天気アプリ | 特定の地域における降水量を 6 時間単位で計算します。 | 特定の地域における 6 時間の降水量を予測します。 |
ファッション アプリ | さまざまなデザインのシャツを生成する。 | テキストと画像から 3 種類のシャツデザインを生成します。テキストにはスタイルと色が、画像はシャツの種類(T シャツ、ボタンアップ、ポロ)です。 |
動画アプリ | 役に立つ動画をおすすめします。 | ユーザーが動画をクリックするかどうかを予測します。 |
メールアプリ | スパムを検出する。 | メールが迷惑メールかどうかを予測します。 |
金融アプリ | 複数のニュース提供元の財務情報を要約します。 | 過去 7 日間の主要な財務動向を 50 語で要約する。 |
地図アプリ | 移動時間を計算する。 | 2 地点間の移動にかかる時間を予測します。 |
バンキング アプリ | 不正な取引を特定する。 | カード所有者による取引の有無を予測します。 |
食事アプリ | レストランのメニューで料理を識別する。 | レストランの種類を予測します。 |
e コマースアプリ | 会社の製品に関するカスタマー サポートからの返信を生成する。 | 感情分析と組織のナレッジベースを使用して返信を生成します。 |
必要な出力を特定する
どのモデルタイプを選択するかは、問題の具体的なコンテキストと制約によって異なります。モデルの出力は、理想的な結果で定義されたタスクを実行する必要があります。したがって、最初の問いは「問題を解決するためにどのような種類の出力が必要か」です。
何かの分類や数値予測を行う必要がある場合は、予測 ML がよく使用されます。新しいコンテンツを生成したり、自然言語理解に関連する出力を生成したりする必要がある場合は、ジェネレーティブ AI を使用するのが一般的です。
次の表に、予測 ML とジェネレーティブ AI の出力を示します。
ML システム | 出力例 | |
---|---|---|
分類 | バイナリ | メールを迷惑メールまたは迷惑メールではないものとして分類します。 |
マルチクラス単一ラベル | 画像内の動物を分類します。 | |
マルチクラス マルチラベル | 画像内のすべての動物を分類します。 | |
数値 | 一次元回帰 | 動画の視聴回数を予測します。 |
多次元回帰 | 個人の血圧、心拍数、コレステロール値を予測します。 |
モデルタイプ | 出力例 |
---|---|
テキスト |
記事を要約する。 顧客のクチコミに返信する。 ドキュメントを英語から標準中国語に翻訳します。 商品説明を書く。 法的文書を分析する。
|
画像 |
マーケティング画像を制作する。 写真にビジュアル エフェクトを適用できます。 プロダクトのデザインのバリエーションを作成する。
|
オーディオ |
特定のアクセントで会話を生成します。
特定のジャンル(ジャズなど)の短い楽曲を作成します。
|
動画 |
リアルな動画を作成する。
動画映像を分析し、視覚効果を適用します。
|
マルチモーダル | テキスト キャプション付きの動画など、複数の種類の出力を生成します。 |
分類
分類モデルは、入力データが属するカテゴリ(入力を A、B、C に分類すべきかどうかなど)を予測します。
図 1. 予測を行う分類モデル。
モデルの予測に基づいて、アプリが決定を行う場合があります。たとえば、予測がカテゴリ A の場合は X を実行します。予測がカテゴリ B の場合は Y を実行します。予測がカテゴリ C の場合は Z を実行します。場合によっては、予測がアプリの出力であることもあります。
図 2. 決定を行うために、製品コードで使用される分類モデルの出力。
回帰
回帰モデルは数値を予測します。
図 3. 数値予測を行う回帰モデル。
モデルの予測に基づいて、アプリが決定を行う場合があります。たとえば、予測が範囲 A 内にある場合は X を実行します。予測が範囲 B 内にある場合は Y を実行します。予測が範囲 C 内にある場合は Z を実行します。場合によっては、予測がアプリの出力になります。
図 4. 決定を下すためにプロダクト コードで使用される回帰モデルの出力。
次のシナリオを考えてみます。
予測される人気度に基づいて動画をキャッシュに保存します。つまり、モデルによって動画が人気になると予測された場合、その動画をユーザーに迅速に配信する必要があります。そのためには、より効果的でコストの高いキャッシュを使用します。他の動画では 別のキャッシュを使用しますキャッシュ基準は次のとおりです。
- 動画の視聴回数が 50 以上になると予測される場合は、高額な費用のキャッシュを使用します。
- 動画の視聴回数が 30 ~ 50 回になると予測される場合は、安いキャッシュを使用します。
- 視聴回数が 30 回未満であると予測される場合、その動画はキャッシュに保存されません。
数値(視聴回数)を予測する回帰モデルが正しいアプローチであると考えているとします。ただし、回帰モデルをトレーニングすると、視聴回数 30 回の動画に対して 28 と 32 の予測で同じ損失が発生することがわかります。つまり、予測が 28 と 32 の場合、アプリの動作は大きく異なりますが、モデルは両方の予測を同等に良好とみなします。
図 5. 回帰モデルのトレーニング
回帰モデルでは、プロダクトで定義されたしきい値は認識されません。したがって、回帰モデルの予測のわずかな違いが原因でアプリの動作が大幅に変化した場合は、代わりに分類モデルの実装を検討する必要があります。
このシナリオでは、分類モデルによる予測で 32 よりも 28 の場合に損失が高くなるため、分類モデルは正しい動作を生成します。ある意味で、分類モデルはデフォルトでしきい値を生成します。
このシナリオでは、2 つの重要なポイントを強調しています。
判定を予測します。可能であれば、アプリの決定を予測します。動画の例では、分類モデルは、動画を分類したカテゴリが「キャッシュなし」、「低価格のキャッシュ」、「高コストのキャッシュ」である場合の決定を予測します。アプリの動作をモデルから隠すと、アプリが誤った動作を発生させる可能性があります。
問題の制約を理解します。しきい値ごとに異なるアクションを実行するアプリの場合は、しきい値が固定か動的かを判断します。
- 動的しきい値: しきい値が動的な場合は、回帰モデルを使用して、アプリのコードでしきい値の上限を設定します。これにより、モデルに合理的な予測を行わせながら、しきい値を簡単に更新できます。
- 固定しきい値: しきい値が固定されている場合は、分類モデルを使用し、しきい値の上限に基づいてデータセットにラベルを付けます。
一般に、ほとんどのキャッシュ プロビジョニングは動的であり、しきい値は時間とともに変化します。したがって、これは特にキャッシュの問題であるため、回帰モデルが最適です。ただし、多くの問題ではしきい値が固定されるため、分類モデルが最適な解決策になります。
別の例を見てみましょう。今後 6 時間の降水量をユーザーに伝えることが理想的な天気アプリを作成する場合は、ラベル precipitation_amount.
を予測する回帰モデルを使用できます。
理想的な結果 | 理想的なラベル |
---|---|
今後 6 時間のお住まいの地域における雨量をユーザーに伝えます。 | precipitation_amount
|
天気アプリの例では、ラベルは理想的な結果に直接言及しています。ただし、理想的な結果とラベルの間に 1 対 1 の関係が明らかでない場合もあります。たとえば動画アプリでは、有用な動画をおすすめすることが理想的です。しかし、useful_to_user.
というデータセットにはラベルがありません。
理想的な結果 | 理想的なラベル |
---|---|
役に立つ動画をおすすめする。 | ? |
そのため、プロキシラベルを見つける必要があります。
プロキシラベル
プロキシラベルは、データセット内にないラベルの代わりになります。プロキシラベルは、予測対象を直接測定できない場合に必要です。動画アプリでは、動画の有用性をユーザーが直接測定することはできませんデータセットに useful
機能があり、ユーザーが役に立った動画をすべてマークできれば便利ですが、データセットにはないので、有用性の代わりにプロキシラベルが必要になります。
有用性を示すプロキシラベルは、ユーザーが動画を共有または高く評価するかどうかです。
理想的な結果 | プロキシラベル |
---|---|
役に立つ動画をおすすめする。 | shared OR liked |
プロキシラベルは予測対象を直接測定しないため、十分に注意してください。たとえば、次の表は、有用な動画をおすすめするの潜在的なプロキシラベルに関する問題の概要を示しています。
プロキシラベル | 問題 |
---|---|
ユーザーが [高評価] ボタンをクリックするかどうかを予測します。 | ほとんどのユーザーは [高評価] をクリックしません。 |
動画が人気になるかどうかを予測する。 | カスタマイズされていません。人気の動画を好まないユーザーもいます。 |
ユーザーが動画を共有するかどうかを予測します。 | 動画を共有しないユーザーがいる。動画が気に入らないという理由で共有されることがあります。 |
ユーザーが再生をクリックするかどうかを予測します。 | クリックベイトを最大化します。 |
動画の視聴時間を予測する。 | 短い動画よりも長い動画を優先する。 |
ユーザーが動画を繰り返し視聴する回数を予測する。 | 何度も見てもらえる動画のジャンルよりも、「再視聴したくなる」動画を優先します。 |
プロキシラベルは理想的な結果の代わりになるものではありません。どのシステムにも潜在的な問題があります。ユースケースにとって問題が最も少ないものを選択してください。
理解度チェック
生成
ほとんどの場合、独自の生成モデルをトレーニングするには大量のトレーニング データとコンピューティング リソースが必要になるため、トレーニングは行いません。代わりに、事前トレーニング済みの生成モデルをカスタマイズします。生成モデルで目的の出力を生成するには、次の方法を 1 つ以上使用する必要があります。
精製。大規模なモデルの小規模なバージョンを作成するには、小規模なモデルのトレーニングに使用する、大規模なモデルから合成ラベル付きデータセットを生成します。生成モデルは通常巨大で、大量のリソース(メモリや電力など)を消費します。抽出することで、より小さくリソース消費量が少ないモデルで、より大きなモデルのパフォーマンスに近づけることができます。
微調整またはパラメータ効率の良い調整。特定のタスクにおけるモデルのパフォーマンスを向上させるには、生成する出力タイプの例を含むデータセットでモデルをさらにトレーニングする必要があります。
プロンプト エンジニアリング。モデルに特定のタスクを実行するか、特定の形式で出力を生成するには、実行するタスクをモデルに指示するか、出力の形式を指定します。つまり、プロンプトには、タスクの実行方法に関する自然言語による手順や、必要な出力を使用した例示的な例を含めることができます。
たとえば、記事の短い要約が必要な場合は、次のように入力します。
Produce 100-word summaries for each article.
モデルで特定の読解レベルのテキストを生成するには、次のように入力します。
All the output should be at a reading level for a 12-year-old.
モデルに特定の形式で出力を提供する場合は、出力の形式を指定する(「結果をテーブルにフォーマットする」など)か、例を示してタスクのデモを行うことができます。たとえば、次のように入力します。
Translate words from English to Spanish. English: Car Spanish: Auto English: Airplane Spanish: Avión English: Home Spanish:______
抽出と微調整により、モデルのパラメータが更新されます。プロンプト エンジニアリングでは、モデルのパラメータは更新されません。代わりに、プロンプト エンジニアリングにより、プロンプトのコンテキストから目的の出力を生成する方法をモデルが学習できるようになります。
場合によっては、生成モデルの出力を既知の値に照らして評価するために、テスト データセットも必要です。たとえば、モデルの要約が人間が生成したものと類似しているか、人間がモデルの要約を「良い」と評価するかどうかを確認します。
ジェネレーティブ AI は、分類や回帰などの予測 ML ソリューションの実装にも使用できます。たとえば、大規模言語モデル(LLM)は、自然言語の深い知識により、特定のタスク用にトレーニングされた予測 ML よりもテキスト分類タスクを頻繁に実行できます。
成功指標を定義する
ML の実装が成功したかどうかの判断に使用する指標を定義します。成功指標では、エンゲージメントや、ユーザーが役に立った動画の視聴などの適切な行動を取れるようにサポートなど、何を重視するかを定義します。成功指標は、モデルの評価指標(精度、精度、再現率、AUC など)とは異なります。
たとえば、天気アプリの成功指標と失敗指標は次のように定義できます。
成功 | ユーザーが「雨が降る?」機能を開く頻度が以前よりも 50% 増加しています。 |
---|---|
失敗 | ユーザーが「雨が降る?」機能を開く頻度は以前より少ない。 |
動画アプリの指標は次のように定義できます。
成功 | サイトでの滞在時間が平均 20% 増加 |
---|---|
失敗 | ユーザーのサイト滞在時間が平均で以前より増えていない。 |
野心的な成功指標を定義することをおすすめします。しかし、大きな野心を抱いていると、成功と失敗の間にギャップが生じることがあります。たとえば、ユーザーがサイトに費やす時間が以前よりも平均 10% 増えても、成功も失敗も変わりません。 定義されていないギャップは重要ではありません。
重要なのは、成功の定義に近づく、または上回るモデルの能力です。たとえば、モデルのパフォーマンスを分析するときは、「モデルを改善することで、定義した成功基準に近づくか」を検討してください。たとえば、優れた評価指標があるモデルでも、成功基準に近づくことはできません。これは、完璧なモデルであっても定義した成功基準を満たさないことを示します。一方、モデルの評価指標が低い場合でも、成功基準に近づくことができます。これは、モデルを改善することで成功に近づくことを示します。
モデルを改善する価値があるかどうかを判断する際に考慮すべき項目は次のとおりです。
不十分ですが、続行してください。このモデルは本番環境では使用しないでくださいが、時間の経過とともに大幅に改善される場合があります。
以上です。続行してください。このモデルは本番環境で使用でき、さらに改善される可能性があります。
これで十分ですが、改善はできません。モデルは本番環境に存在しますが、可能な限り改善されています。
十分に良くない、今後もない。このモデルは本番環境で使用しないでください。また、トレーニング量を抑えても本番環境では利用できません。
モデルの改善を決定するときは、エンジニアリング時間やコンピューティング費用などのリソースの増加が、モデルの改善予測を正当化するかどうかを再評価します。
成功指標と失敗指標を定義したら、指標を測定する頻度を決定する必要があります。たとえば、システム実装から 6 日、6 週間、6 か月後に成功指標を測定できます。
失敗の指標を分析するときは、システムが失敗した理由を特定してみます。たとえば、ユーザーがどの動画をクリックするのかをモデルが予測していても、ユーザー エンゲージメントを低下させるクリックベイト タイトルのレコメンデーションが始まっているとします。天気アプリの例では、このモデルは、雨が降るタイミングを正確に予測するかもしれませんが、地理的な範囲が広すぎます。
理解度チェック
あるファッション会社が、より多くの洋服を販売したいと考えています。誰かが ML を使用して、企業がどの衣類を製造すべきか決定することを提案しています。このチームは、どのような種類の服がファッションであるかを判断するモデルをトレーニングできると考えています。モデルをトレーニングした後、それをカタログに適用して、どのような服を作るかを決定します。
問題を ML の観点からどのように捉えればよいでしょうか。
理想的な結果: 製造する製品を決定する。
モデルの目標: どの衣料品がファッションであるかを予測します。
モデル出力: バイナリ分類、in_fashion
、not_in_fashion
成功指標: 製造された衣類の 70% 以上を売り上げること。
理想的な結果: 注文する生地と消耗品の量を決定します。
モデルの目標: 製造する各品目の量を予測します。
モデル出力: バイナリ分類、make
、do_not_make
成功指標: 製造された衣類の 70% 以上を売り上げること。