サーバーレス機械学習モデルの構築

この記事では、Google Cloud Platform(GCP)でサーバーレスのカスタム機械学習(ML)タスクを作成する方法について説明します。また、Perception API と比較した ML Engine の利点についても説明します。この記事のトピックは次のとおりです。

  • ML モデルの構築手順について
  • モデルの品質向上
  • 単純な問題からスケーラブルな環境への移行

この記事ではサーバーレス機械学習モデルのアーキテクチャに従い、Firebase、Cloud Functions、Natural Language API、Cloud Machine Learning Engine を使用してヘルプデスク チケットをサーバーレスに拡張する方法について説明します。

構築手順について

GCP で機械学習タスクを実行する主な方法には、次の 2 つがあります。

  • Cloud Vision APICloud Speech API など、あらかじめ用意されているトレーニング済み RESTful Perception API を使用する。これらの事前トレーニングされたモデルを使用して、このソリューションの前半で述べる感情分析と自動タグ設定を行います。
  • モデルを構築または再利用する。TensorFlow と ML Engine を使用して、これらの機械学習モデルをカスタムデータでトレーニングできます。このソリューションの前半で説明するように、解決時間と優先度の予測にはこの手法が推奨されます。

次の図は 2 つ目の方法を表しています。ここでは、データセットの収集と保管、データの整理、モデルの設計、トレーニング、デプロイを行っています。

機械学習のタスク

データの収集と保管

強力なモデルを生成するには、データが鍵となります。データが妥当で、クリーニングされている限り、モデルのトレーニングに利用できるデータが多ければ多いほど、予測の精度が向上します。詳細については、モデルの品質向上のセクションをご覧ください。

データを簡単に取得できることもありますが、データセットが 200~300 個のサンプルに限られている場合は、データを取得するのが困難です。サポート チケットについては、数千個ほどのサンプル履歴データを取得できるはずです。これだけあれば、妥当なモデルをトレーニングできます。

顧客関係管理(CRM)システムなど、チケット発行を処理するシステムを使用している場合は、エクスポートするかクエリを実行することで、サービス開始以来作成されたすべてのチケットにアクセスできるでしょう。ここでの目標は、チケット フィールドにアクセスすることです。チケットのフィールドには通常、チケット ID、顧客 ID、カテゴリ、優先度、解決時間、エージェント ID、顧客のサービス エクスペリエンスなどの情報が格納されています。これらの情報をエクスポートする一般的な出力形式は、次のような CSV ファイルです。

t0,Patrick Blevins,12,3-Advanced,Performance,Request,4-Critical,P1,5
t1,Kaitlyn Ruiz,3,2-Experienced,Technical,Issue,1-Minor,P4,6
t2,Chelsea Martin,11,2-Experienced,Technical,Request,4-Critical,P1,2
t3,Richard Arnold,8,2-Experienced,Performance,Request,1-Minor,P3,5
...

データを収集する際には、以下の点に注意してください。

  • バイナリ分類を行う場合は、ポジティブなサンプルだけを収集するのではなく、ネガティブなサンプルも収集する必要があります。
  • より一般的には、クラスごとのサンプル数をできるだけバランスさせ、それが不可能ならサンプル数の不均衡をコードで補正する必要があります。
  • 外れ値について、より多くのサンプルを探してください。外れ値は現実世界でのケースなので、システムが予測できるようにする必要があります。

このチュートリアルでは、あらかじめ履歴データを収集して単一の CSV ファイルとして Cloud Storage 上に用意してあります。

データの前処理

モデルをトレーニングする前にデータの前処理を行うことが非常に重要です。作業量と使用するテクノロジーは、主に以下の 2 つの要因によって決まります。

  • 品質: データに関連性のないフィールドが含まれている場合や、データのクリーニングまたは特徴関連付けが必要な場合は、その問題を解決してからトレーニング用データとして送信することが重要です。
  • サイズ: データのサイズが大きすぎる場合、あるいは one-of-k エンコードによって過剰なサイズになる可能性がある場合は、単一インスタンスでは処理できないことが考えられます。

前処理のベスト プラクティスについて詳しくは、単純な例題からスケーラブルな環境への移行をご覧ください。

Cloud Datalab は、その UI から gcloud コマンドを直接実行してマネージド環境で Jupyter ノートブックを実行できるため、データを前処理するのに最適なツールです。Cloud Datalab には、TensorFlow とのやり取りを単純化する ML Workbench というライブラリが付属しています。

また、Cloud Datalab は次のようにインタラクティブなオーケストレーターとしても機能します。

  • データのサイズが十分に小さければ、Pandas などのライブラリをインタラクティブに利用できます。
  • メモリに収まりきらないデータは、Cloud Datalab の外部で Apache Beam などのツールを利用して処理でき、その場合でも結果をインタラクティブに使用できます。

以下に、実行しなければならない可能性があるタスクをいくつか抜粋します。

  • 予測時に入力として利用できない列を除外します。 例: エージェント ID
  • ラベルが正しく変換されて利用できるようになることを確認します。 例: 空の値の削除
  • 例外を排除します。例外ではなく繰り返されるイベントの場合は、より多くのサンプルを探します。 例: 存在しないカテゴリのテキスト
  • データをトレーニング用、評価用、テスト用に分けます。 例: 80%、10%、10%
  • 入力とラベルを、使用可能な特徴に変換します。 例: 解決時間 =(クローズ時刻 - 作成時刻)
  • 重複する行を削除します。

以下の表に特定の入力をいくつか記載します。

フィールド名 保持 理由 タイプ
Ticket ID しない チケットごとに固有の値であり、予測アルゴリズムのトレーニングには役立ちません。 なし
Customer ID 場合による 何度も利用する顧客から学習します。 個別
Category する チケットの複雑さに影響する可能性があります。 カテゴリ
Agent ID しない この値は、ユーザーがチケットを送信する時点では不明です。

: 分類スキームからこの値を予測することが興味深い事例となる可能性があります。
なし
Years of product experience する チケットの複雑さに影響する可能性があります。 継続的

入力列を選択した後は、該当するデータを代表する、互いに重複しないデータセットを少なくとも 2 つ、できれば 3 つ作成する必要があります。

トレーニング セット
全データセットの約 80 パーセントを代表するデータセットです。モデルはこれを使用して、事実(つまりラベル)にできるだけ近づくようにさまざまなパラメータ(モデルの重み)を微調整します。そのために、モデルは損失関数を最小限にするという方法を取ります。損失関数は、モデルの予測が事実とどれだけ離れているか、つまり現在のエラーレベルを計算します。最終的な予測モデルには、最良の重み一式を使用します。
評価セット
通常は、全データセットの 10 パーセントから 20 パーセントです。評価セットは、モデルの過剰適合を防ぎます。過剰適合するモデルは、トレーニング セットでは有効に機能してわずかなエラーしか生成しないとしても、新しいデータや不明なデータでは適切に機能しません。つまり、モデル自体がデータに適合しすぎているということです。過剰にトレーニングされたモデルは、トレーニング セットで見つかった特定の特徴を抽出する方法だけを学習しますが、特定のタイプのデータから一般的な特徴を抽出しません。
テストセット
通常は、全データの 10 パーセントから 15 パーセントです。テストセットは、モデルの一般化能力を検証します。トレーニング中には評価セットが使用されるので、モデルに暗黙的なバイアスが含まれる可能性があります。モデルの有効性を評価するには、別のテストセットでモデルのパフォーマンスを測定する必要があります。

データを分けるには、以下のいずれかの手法を使用します。

  • データをランダムにシャッフルします。
  • ジェネレータ シードを使用してデータをシャッフルします。
  • 列のハッシュを使用して、サンプルがトレーニング セット、評価セット、テストセットのどれに属するかを決定します。

推奨される手法はハッシュを使用することです。これは、更新バージョンのデータセットを取得してもハッシュには影響がないためです。また、この手法により、時間が経過してもテストセットの整合性が維持されます。

モデルの設計

解決時間と優先度の予測は、教師付き機械学習のタスクです。つまり、入力データにラベルが付きます。該当するデータ フィールドは以下の 2 つのカテゴリに分類されます。

入力
チケット ID、序列、エクスペリエンス、カテゴリ、タイプ、影響
ラベル
解決時間と優先度

教師付き機械学習のコンテキストでは、ラベルに関連付けられた入力が有用なトレーニング サンプルになります。これらのタイプのラベルは、モデルによって検出される事実を表します。予測モデルの目標は、入力を使用して不明なラベルを予測することです。これを達成するために、有効なサンプルでモデルがトレーニングを行います。このユースケースでは、以下の項目が予測に含まれます。

解決時間
ヘルプデスク エージェントで高い値が見られる場合、不明な問題に対処するためにより多くのリソースが必要であることを示唆する可能性があります。
優先度
確立されたプロセスに沿って、エージェントがチケットとリソースに優先順位を決定するうえで役立ちます。

モデルを設計するには、どのモデルで予測を行うかを決定するために問題の骨組みを考える必要があります。このユースケースには、2 つの異なる教師付き機械学習の問題があります。

回帰
解決時間は、連続する数値です。連続する数値をモデルで予測する回帰問題としてこれを定義できます。
分類
優先度には、P1、P2、P3、P4 などの複数の値を設定できます。この問題に取り組む有効な方法は、マルチ分類です。モデルは優先度クラスごとに確率を出力し、すべての確率の合計は 1 になります。確率が割り当てられると、どの優先度をどのチケットに割り当てるかを決定できます。たとえば、P1 = 10%、P2 = 20%、P3 = 60%、P4 = 10% だとすると、サポート チケットを P3 優先度に割り当てます。

TensorFlow と ML Engine を使用する場合、上記のどちらの問題でもモデルの開発プロセスは同様であり、同じ特徴がいずれかの Estimator API にフィードされます。分類から回帰への切り替えは、数行のコードを変更するだけで簡単に行うことができます。

入力を把握し、作業データセットが用意できたら、データを TensorFlow グラフで使用できるエンティティ(数値以外の値を含む)に変換する必要があります。

フィールド名 タイプ 説明
Category カテゴリ 完全な語彙(可能なすべての値)が既知です。
Product experience 継続的 保持する必要がある数値。毎年の Product experience が重要です。

ML Workbench を使用すると、これらの入力を TensorFlow で使用可能なエンティティに簡単に変換できます。ML Workbench では、フィールドのタイプごとに TensorFlow 特徴列関数を使用します。

features:
  ticketid:
    transform: key
  seniority:
    transform: identity
  category:
    transform: one_hot
  [...]
  priority:
    transform: target

また、ML Workbench には、データを分析してモデル用に準備するための 1 つの関数があります。

%%ml analyze [--cloud]
output: [OUTPUT_ANALYSIS]
data: $[CREATED_DATASET]
features:
...

モデルの生成

この記事のユースケースに用意されているチケットの数は、妥当な予測を行うのに十分であると同時に、データサイズについて懸念するほどではないため、ローカル トレーナーを使用できます。ローカルからクラウド トレーニングに切り替えるには、単純な --cloud パラメータを使用できることに注意してください。

%%ml train [--cloud]
output: [OUTPUT_TRAIN]
analysis: [OUTPUT_ANALYSIS]
data: $[CREATED_DATASET]
  model_args:
    model: dnn_regression
    max-steps: 2000
    hidden-layer-size1: 32
    hidden-layer-size2: 8
    train-batch-size: 100
    eval-batch-size: 100
    learning-rate: 0.001

hidden-layer-sizeX パラメータと max-steps パラメータについて詳しくは、ハイパーパラメータの調整をご覧ください。

モデルのデプロイ

アプリケーションを開発する際に鍵となるのは、TensorFlow でグラフを作成し、それをトレーニング用に ML Engine に移植することです。ただし、強力な予測モデルでも、データ サイエンティスト以外に誰も使用できないとしたら意味がありません。現在のユースケースは、サポートデスクにリアルタイム予測を提供することを目的としています。そのためには、Node.js で作成された Cloud Functions からモデルにアクセスできる必要があります。このモデルは Python でビルドおよび作成されています。

ML Engine には、モデルを RESTful API としてデプロイするオプションが用意されています。これにより、ユーザーが 1 人でも百万人でも、その数に応じて予測をスケーリングできます。モデルをデプロイするには、以下の単純なコマンドを使用できます。[MODEL_NAME][BUCKET] は、該当するモデル名とバケットに置き換えてください。

gcloud ml-engine models create [MODEL_NAME]
DEPLOYMENT_SOURCE=[BUCKET]
gcloud ml-engine versions create "version_name" --model [MODEL_NAME] --origin $DEPLOYMENT_SOURCE

このモデルは、オンライン予測でもオフライン予測でも利用できます。次のセクションで、Cloud Functions を使用してサーバーレスでモデルを呼び出す方法を説明します。

サーバーレス拡張

デプロイされたモデルには、RESTful API を使用してアクセスできます。これは、ML Engine を使用する利点の 1 つです。この API により、Cloud Functions を含む、あらゆる類のクライアントでモデルを使用できるようになります。このソリューションのユースケースでは、Firebase データベースがチケットを記録した後、Cloud Function を起動してデータを拡充します。その際、Natural Language API とカスタムモデルの両方が使用されます。以下の図に、このモデルを示します。

サーバーレス拡張

以下に、Cloud Functions から Natural Language API とカスタムモデルを呼び出す 2 つの例を記載します。

  • Natural Language API:

    const text = ticket.description;
    const document = language.document({content: text});
    
    document.detectSentiment()
     .then((results) => {
        const sentiment = results[1].documentSentiment;
        admin.database().ref(`/tickets/${key}/pred_sentiment`).set(sentiment.score);
     })
     .catch((err) => {
        console.error('ERROR detectSentiment:', err);
     });
  • 解決時間の回帰モデル:

    ml.projects.predict({
      name: `projects/${MDL_PROJECT_NAME}/models/${RESOLUTION_TIME_MODEL_NAME}`,
      resource: {
        name: `projects/${MDL_PROJECT_NAME}/models/${RESOLUTION_TIME_MODEL_NAME}`,
        instances: [
          `${key},${ticket.seniority},${ticket.experience},${ticket.category},
          ${ticket.type},${ticket.impact}`
        ]
      }
    },

モデルの品質向上

このセクションでは、モデルの改善に役立つ追加の手順を概説します。

データの準備

モデルのトレーニングを開始する前に、データを準備する必要があります。

サンプルを収集する
データに外れ値があるかどうか、あるいは予測するクラスが複数あるかどうかにかかわらず、必ずすべてのクラスのサンプルを収集する必要があります。
データをクリーニングする
データのクリーニングは、単純な作業(たとえばトレーニング セットと評価セットの両方に同じサンプルが含まれないように重複データを削除すること)である場合もあれば、すべての値を意味のあるものにすること(たとえばゼロ未満の勤続年数の排除)である場合もあります。
人間の洞察を取り込む
適切な特徴を使用すると、機械学習モデルの有効性が高くなります。TensorFlow に用意されている cross_function を使用して特徴を関連付けるのがベスト プラクティスです。たとえばタクシーの運賃を予測する場合、この関数で緯度と経度を関連付けることで、モデルの品質を向上させることができるでしょう。また、ヘルプデスクの場合は、この関数で勤続年数と製品の経験を関連付けることができます。
データのバケットを作成する
特に多数の例がないような極端なケースでは、入力を離散させてパフォーマンスを改善するうえで TensorFlow bucketized_column などの関数が役立つことがあります。

ハイパーパラメータの調整

トレーニング パラメータ値の中には、見つけるのが難しいものの、有効なモデルを構築する鍵となるものがあります。それらを適切に組み合わせることで、モデルのパフォーマンスが大幅に向上する可能性があります。しばしば調整される値には、以下のものがあります。

  • 隠れ層のサイズ(ニューラル ネットワークの場合)
  • ニューロンの数(ニューラルネットワークの場合)
  • トレーニング ステップ
  • 完全な辞書がない場合のカテゴリ入力のバケットサイズ(例: 出身都市)

どのように選んでもハイパーパラメータになる可能性があります。適切な組み合わせを見つけるには、以下の方法があります。

  • 「For」ループを使用してグリッド検索を行います。

    複数の異なる値を設定して、すべての組み合わせをループ処理し、そのうちの最良の結果に焦点を定めることができます。ただし、ハイパーパラメータの数とその範囲の大きさによっては、かなりの時間と計算コストがかかることがあります。

  • 推奨されるアプローチは、ML Engine を使用してハイパーパラメータを調整することです。ML Engine は宣言型 YAML の設定に基づいて自動的にハイパーパラメータを調整します。これにより、システムはすべてのトレーニング ステップを実行する前に迅速に最良のパラメータの組み合わせにジャンプして停止するため、時間、コンピューティング能力、経費の節約になります。

サンプルの数を増やす

モデルがトレーニングで使用するデータが増え、認識するユースケースが多くなるほど、予測結果の精度も向上します。ローカルでトレーニングする場合、モデルに数百万個のサンプルをフィードするのは難しいかもしれません。その場合の 1 つのソリューションとして、ML Workbench を使用すると、以下の機能を利用できます。

  • TensorFlow を利用してトレーニング タスクを分散し、一括してステップを実行できます。
  • BigQuery を利用してトレーニング データを分析できます。
  • ML Engine を利用して、スケーラブルなオンデマンド インフラストラクチャに対するトレーニングと予測を実行できます。

以下の図に、ユースケースとトレーニング データの数が増えると予測の精度向上につながる仕組みを示します。

データとユースケース

ML トレーニングは、MapReduce のような驚異的並列問題ではありません。つまり、たとえば勾配降下最適化ではパラメータ サーバー上に共有メモリが必要になります。ML プラットフォームで、このような手法をサポートする必要があります。

単純な問題からスケーラブルな環境への移行

前のセクションでは、モデルの品質を向上させるためのベスト プラクティスについて説明しました。これらの作業のいくつかは、サンプリングされた、または限定的なデータセットを使って簡単に達成できそうに見えるでしょう。しかし大量のデータを使用すると難しくなる可能性があります(パフォーマンスに優れたモデルをトレーニングするには大量のデータを使用する必要があります)。

以下の図に、スケーラブルなアプローチの概要を示します。

サーバーレス拡張

BigQuery と Cloud Datalab を使用したデータの探索

BigQuery を使用してデータを保管し、クエリを実行する方法が推奨されます。BigQuery はビッグデータ用に作成された列形式データベースであり、ユーザーはテラバイト規模のデータに対するアドホック クエリをわずか数秒で実行できます。

Cloud Datalab と BigQuery を使用すると、以下の操作を行うことができます。

  • Cloud Datalab から BigQuery を使用して、テラバイト規模のデータを探索して視覚化できます。
  • 予測に大きな影響を及ぼさないと考えられる入力をフィルタリングできます。
  • 代表的なデータのサンプルセットを作成してモデルの作成を開始できます。
  • 場合によっては、データをトレーニング用、評価用、テスト用に分けることができます。

Cloud Dataprep と Cloud Dataflow を使用したデータの前処理

入力をそのままの状態ですぐに使用できる場合はめったにありません。通常は、使用可能な状態にするために、以下のような処理が必要になります。

  • 「不明」な結果になる値(None や Null など)のクリーンアップ
  • トレーニング用、評価用、テスト用データセットの分割
  • tfRecord ファイル(TensorFlow で使用する場合に推奨される形式)へのデータの変換

Cloud Dataprep は、わずかなプログラミングのオーバーヘッドで、大規模なデータを準備したりクリーニングしたりできる視覚的なツールです。Cloud Dataprep は背景で Apache Beam を使用しますが、その使いやすい UI のおかげで、多数のボイラープレート コードを節約できます。

Apache Beam は Cloud Dataflow 上で実行できます。Cloud Dataflow は、広範囲のデータ処理パターンを開発および実行するのに役立つ可能性があります。これらのパターンには、抽出-変換-読み込み(ETL)、バッチ コンピューティング、継続的な計算処理が含まれます。

tf.Transform と Dataflow による大規模なスキューの最小化

多くの場合、デベロッパーがトレーニング用の前処理コードを作成します。場合によっては、分散環境での実行用にこの前処理コードを調整することもありますが、予測のために受信データに関する同様の、しかし異なるコードを別途作成します。この手法が原因で、次の 2 つの主要な問題が発生することがあります。

  • 2 つのコードベースを(おそらく別々のチームで)保守する必要があります。
  • さらに重要な点として、トレーニングと推定との間でスキューが発生する可能性があります。

tf.Transform では、この両方の問題を解決するために、トレーニング用と予測用に共通のコードを作成できます。また、Apache Beam を使用して分散環境でコードを実行することもできます。

Google Cloud Platform 上の tf.Transform での TensorFlow の利用

前述の機能のいくつかは TensorFlow に含まれています(したがってオープンソースの一部となっています)が、ML Engine では TensorFlow を実行する際に次のような利点があります。

  • 機械学習タスクをサーバーレス環境で実行
  • ハイパーパラメータの調整を簡素化
  • (Python だけでなく)異種のクライアントからアクセスできる RESTful API としてモデルをホスティング

以下の図に、TensorFlow の利用方法を示します。

TensorFlow を活用する

tf.Transform(TensorFlow ライブラリ)を利用すると、同じコードベースを使用できるので、トレーニングと予測との間の潜在的スキューが制限されます。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...