小売およびeコマースにおけるMLプラットフォームの構築

'小売およびeコマースにおけるMLプラットフォームの構築' can be condensed to '小売とeコマースにおけるMLプラットフォーム構築'.

機械学習を使って組織内で最も困難な問題を解決することは素晴らしいことです。さらに、eコマース企業にはMLが役立つ多くのユースケースがあります。ただし、より多くのMLモデルとシステムが本番環境にある場合、信頼性のある管理のためにさらなるインフラを設定する必要があります。そのため、多くの企業がこの取り組みを内部のMLプラットフォームで一元化することを決めます。

しかし、どのようにして構築すればよいのでしょうか？

この記事では、eコマースにおける成功したMLプラットフォームの動作方法と、構築の過程でチームが従うべきベストプラクティスについて共有します。

しかし、まずは、MLプラットフォームがサポートできるべきコアな小売り/ eコマースの機械学習ユースケースについて話しましょう。

• MLモデルのトレーニングパイプラインの構築方法
• MLモデルの最適化とデバッグにSHAP値を使用する方法
• 高度なグラフニューラルネットワークを使用した交通予測

どのようなモデルタイプをeコマースのMLプラットフォームがサポートできるのでしょうか？

すべての内部MLプラットフォームに共通するものはありますが、特定のモデルタイプはeコマースにとってより意味があります。例えば：

• 1
  商品検索
• 2
  パーソナライゼーションとおすすめ
• 3
  価格最適化
• 4
  需要予測

商品検索

商品検索はeコマースビジネスの基盤です。顧客は検索プラットフォームを通じて自分の意図を共有します。商品検索プラットフォームが最適でない場合、多くの顧客の需要が満たされない可能性があります。

MLプラットフォームは、歴史的な顧客エンゲージメントデータ（「クリックストリームデータ」とも呼ばれる）を活用し、検索プラットフォームの成功に不可欠な特徴を作成できます。アルゴリズム的には、Learning To Rank（LeToR）やElastic Searchが、検索システムを構築するためによく使用されるアルゴリズムの一部です。

パーソナライゼーションとおすすめ

eコマースの商品おすすめは、顧客のニーズを満たすための関連性の高い価値ある提案を行うための入り口です。適切に実装されたeコマース商品おすすめシステムは、より良い顧客体験を提供し、顧客のエンゲージメントを高め、収益を向上させることができます。

ユーザー-商品の過去の相互作用データを収集し、そのデータを使用してパーソナライゼーションおよびおすすめシステムのアルゴリズムをトレーニングすることができます。従来の協調フィルタリングやニューラル協調フィルタリングアルゴリズムは、ユーザーの過去の商品との関わりに基づいてパーソナライゼーションおよびおすすめの問題を解決するために広く使用されています。

価格最適化

価格最適化は小売業の核心的な課題です。eコマース企業は、「在庫に未販売の商品を保持する」vs「魅力的な割引を提供して商品の販売を促進する」というトレードオフを見つける必要があります。

そのため、開発者は価格戦略を頻繁に最適化する必要があるかもしれません。モデルの増分開発をサポートするためには、CI/CD/CTのサポートを備えたMLプラットフォームを構築する必要があります。

需要予測

将来の需要の推定は、eコマース企業が調達および補充の意思決定をより良く行うために役立ちます。季節によって需要が変動する製品がいくつかあります。夏服、冬服、ホリデーデコレーション、ハロウィンの衣装、保湿剤などが例です。

SARIMAX、AIRMAなどの人気のある予測アルゴリズムを使用したMLモデルは、これらすべての要素を考慮に入れ、需要のより良い推定値を算出し、カタログと在庫に関するより良いeコマースの意思決定を支援することができます。

eコマースにMLプラットフォームを設定する方法

MLプラットフォームの目的は、データの準備からモデルの展開と監視までの繰り返しのタスクを自動化し、プロジェクトのライフサイクルを迅速化することです。

以下の図は、MLプラットフォームの主要なコンポーネントを示しています。

各コンポーネントには異なる名前が付けられるかもしれませんが、MLプラットフォームの主要なコンポーネントは次のとおりです。

• 1
  データプラットフォーム
• 2
  データ処理
• 3
  継続的インテグレーション/継続的デプロイメント/継続的トレーニング
• 4
  モデル提供
• 5
  パフォーマンス監視

これらはどのMLプラットフォームでも見つけることができるコンポーネントですが、小売業におけるMLプラットフォームの特徴は、これらの各コンポーネントをどのように設計するかにあります。次のセクションでは、これらの各コンポーネントが小売業のユースケースをサポートするためにどのように構築されるかについて説明します。

データプラットフォームの考慮事項

データプラットフォームを適切に設定することは、MLプラットフォームの成功に重要です。eコマースプラットフォームのエンドツーエンドのジャーニーを見ると、データが生成されるコンポーネントがたくさんあることがわかります。以下の図で示されているように、サプライヤから消費者への商品の配送には、サプライチェーンネットワークの複数のレイヤーを通過する必要があります。

これらの各レイヤーは大量のデータを生成し、これらのデータをキャプチャすることは最適化に重要です。複数のソースから来るこのようなデータのボリュームを管理することは、時には課題となることもあります。

データのソース

• クリックストリームデータ：お客様のジャーニーは、クエリを書いて商品を検索することから始まります。eコマースポータルとのインタラクションが続くと、クリックデータのストリームが生成されます。お客様のインタラクションはキャプチャされ、過去の行動を分析することで検索や推薦システムの改善に役立てられます。

• 製品カタログ：製品カタログデータは、製品に関する情報を知るための唯一の情報源です。eコマース企業は複数のベンダー、メーカー、サプライヤーから製品を調達しています。複数のチャンネルからのデータを統合し、豊かな製品カタログを維持するためには、課題があります。

• サプライチェーン管理データ：別のデータソースはサプライチェーン管理システムです。商品がサプライチェーンネットワークを通過すると、各レイヤーでデータが生成され、このデータを永続化することはサプライチェーンネットワークの最適化に重要です。

データプラットフォームの目的は、データを処理しやすくしてMLモデルの開発に活用することです。次のセクションでは、小売業向けのデータプラットフォームを設定する際のベストプラクティスについて説明します。

データの履歴の維持

eコマース向けのデータプラットフォームを構築する際には、顧客の過去のエンゲージメントデータの保存が重要です。推薦システムは過去の顧客のエンゲージメントデータを活用してより良いアルゴリズムを構築します。セッションレベルのデータの長い履歴を維持することは負担となる場合があります。以下の例で理解しましょう。

クリックストリームデータには通常、<セッションID、ユーザー、クエリ、アイテム、クリック、ATC、注文>が含まれています。長い履歴のセッションレベルのデータをすべてのユーザーについて維持することは過剰であり、MLモデルの開発には常にそのレベルの詳細なデータが必要とされるわけではありません。

したがって、より良いデータベースアーキテクチャは、1つのテーブルが過去3ヶ月の履歴をセッションレベルで詳細に保持し、他のテーブルには週次集計されたクリック、ATC、注文データが含まれるようにすることです。

データセットのバージョン管理

アルゴリズムの開発中には、データサイエンティストは複数の実験を実行する必要があります。データサイエンティストにとって、どのデータを使用して実験を実行したかを追跡することは時間がかかる場合があります。したがって、データのバージョン管理はデータの変更をより良く追跡するのに役立ちます。

例えば、eコマースでは、製品カタログのデータは時間の経過とともに変化します。新しい製品がカタログに追加されたり、非アクティブな製品が削除されたりすることがあります。したがって、モデルを構築する際には、モデルの構築に使用されたカタログデータのバージョンを追跡することが重要です。なぜなら、製品の追加や削除によって一貫性のない予測が生じる可能性があるからです。

適切なデータストレージプラットフォームの選択

eコマースでは、データサイエンティストは様々な種類のデータを扱います。データの種類とアプリケーションの種類に基づいて、適切なストレージプラットフォームを選択することが重要です。

• データプラットフォームは、BigQuery、クラウドファイルストレージプラットフォーム（Amazon S3、GCPバケットなど）との統合を備えている必要があります。

• 同時に複数のデータソースが存在し、画像、テキスト、表形式などの異なる形式で利用できる場合があります。異なるデータのバージョンを維持するために、市販のML Opsプラットフォームを利用したい場合もあります。

• 画像データを保存するためには、Amazon S3やGCPバケット、Azure Blob Storageなどのクラウドストレージが最適なオプションの一部です。一方、クリックストリームやその他のテキストや表形式のデータを保存する場合には、Hadoop + HiveやBigQueryを利用することが望ましいでしょう。

データ処理プラットフォームの設定方法

データの前処理は、MLプロジェクトのライフサイクルにおいて重要な役割を果たしています。デベロッパーはデータを正しい形式で準備するために、70%以上の時間を費やしています。このセクションでは、データ処理プラットフォームの構築に関するベストプラクティスについて説明します。

このプラットフォームの目的は、データを前処理し、準備し、変換してモデルのトレーニングに適した状態にすることです。これは、複数のソースからデータを結合し、データからノイズを取り除き、生データを整理し、モデルのトレーニングのために準備するETL（抽出、変換、ロード）レイヤーです。

データの検証

先ほど説明したように、eコマースではさまざまな性質のデータを扱うことがあり、データは複数のデータソースから流れてくる可能性があります。したがって、複数のソースから流れてくるデータを結合する前に、データの品質を検証する必要があります。

カタログデータの場合、製品名、主要な画像、栄養価などの必須フィールドがデータに存在するかどうかを確認することが重要です。そのため、データをモデルのトレーニングに準備する前に、一連のルールに基づいてデータを検証および確認するための検証レイヤーを構築する必要があります。

探索的データ分析

EDA（探索的データ分析）レイヤーの目的は、データに明らかなエラーや外れ値がないかを見つけることです。このレイヤーでは、データから統計的なパラメータを監視するための一連の可視化を設定する必要があります。

特徴量の処理

これはデータ処理ユニットの最後のレイヤーであり、データを特徴量に変換し、それらを特徴量ストアに保存します。特徴量ストアは、モデルのトレーニングに直接使用できる特徴量を保存するリポジトリです。

例えば、モデルがユーザーがアイテムを注文した回数を特徴量の1つとして使用する場合、生の形式で得られるクリックストリームデータにはユーザーのセッションレベルの製品とのやり取りのデータがあります。このクリックストリームデータをユーザーとアイテムのレベルで集計し、特徴量を作成し、それを中央の特徴量ストアに保存する必要があります。

このような特徴量ストアを構築することには、いくつかの利点があります：

• 1
  特徴量を複数のプロジェクトで簡単に再利用できるようにします。
• 2
  チーム間で特徴量の定義を標準化するのにも役立ちます。

CI/CD/CTプラットフォームの考慮事項

継続的な開発のためのプラットフォームの設定

これは、開発者が実験を実行し、最適なモデルアーキテクチャを見つけるプラットフォームです。開発者は、複数の実験を実行し、異なるモデルアーキテクチャを試し、適切な損失関数を見つけ、モデルのハイパーパラメータを試行するなど、実験のテストベッドとして使用します。

JupyterLabは、Pythonを使用したML開発において最も人気のある対話型ツールの1つです。したがって、このプラットフォームはJupyterLab環境を活用してコードを記述し、実行することができます。このプラットフォームはデータプラットフォームへのアクセスが必要であり、データソースからデータを取得するためのさまざまなタイプのデータコネクタに対応している必要があります。

継続的なトレーニングのためのプラットフォームの設定

eコマースのMLプラットフォームでは、予測、レコメンデーションシステム、ランキング学習、分類、回帰、オペレーションリサーチなど、さまざまなモデルが必要です。そのような多様なモデルの開発をサポートするために、最適なモデルを見つけるために複数のトレーニング実験を実行し、新しいデータが得られるたびに取得したモデルを再トレーニングする必要があります。したがって、MLプラットフォームは、CI/CDとともにCT（継続的トレーニング）をサポートする必要があります。

継続的トレーニングは、特徴量ストアからデータを取得し、継続的開発プラットフォームで事前に推定されたモデルアーキテクチャを使用してモデルをトレーニングし、評価指標を計算し、評価指標が適切な方向に進展している場合にモデルをモデルレジストリに登録するパイプラインを設定することで実現されます。新しいモデルがモデルレジストリに登録されると、新しいバージョンが作成され、展開時に同じバージョンがモデルを取得するために使用されます。

しかし、モデルレジストリとは何か、また評価指標とは何かについてはどうでしょうか？

モデルレジストリ

• モデルレジストリは、トレーニングされたMLモデルを保存し管理する集中型プラットフォームです。モデルの重みを保存し、モデルのバージョンの履歴を管理します。モデルレジストリは、異なるモデルバージョンを整理するための非常に便利なツールです。
• モデルの重みに加えて、モデルレジストリはデータとモデルに関するメタデータも保存します。
• モデルレジストリは、TensorFlowベースのモデル、sklearnベースのモデル、トランスフォーマーベースのモデルなど、さまざまなモデルタイプに対応している必要があります。
• neptune.aiのようなツールは、モデルレジストリを効率的に管理するための素晴らしいサポートを提供しています。
• モデルが登録されるたびに、そのモデルには一意のIDが生成され、デプロイ時にそのモデルを追跡するために使用されます。

neptune.aiを使用すると、中央集権化されたレジストリに準備が整ったモデルを保存できます。これにより、モデルと関連するメタデータをバージョン管理、レビュー、アクセスできるようになります。

• ドキュメントで完全なモデルレジストリの概要を確認

最適な評価指標の選択

評価指標は、アルゴリズムのバージョンのパフォーマンスを判断するのに役立ちます。eコマースでは、推薦システムや顧客体験に直接影響を与える他のアルゴリズムの場合、これらのモデルを評価するための2つの方法が存在します。「オフライン評価」と「オンライン評価」です。

「オフライン評価」の場合、モデルのパフォーマンスは、事前に定義されたデータセットで計算される一連の定義済みのメトリックに基づいて評価されます。この方法は速くて使いやすいですが、これらの結果は常に実際のユーザーの行動と相関しているわけではありません。なぜなら、これらの方法はユーザーのバイアスを捉えることができないためです。

さまざまな地理的位置に住む異なるユーザーは、選択バイアスと文化的バイアスをeコマースプラットフォームに導入します。ユーザーとプラットフォームとの直接のやり取りを通じてそのようなバイアスを捉えない限り、モデルの新しいバージョンを評価することは困難です。

そのため、A/Bテストやインターリービングなどの方法を使用して、プラットフォームにソリューションを展開し、ユーザーが古いシステムと新しいシステムとのやり取りをどのように捉えているかを評価します。

A/Bテスト

eコマースでは、A/Bテストを実行して、リコメンデーションシステムやアルゴリズムの2つのバージョンを比較します。旧アルゴリズムをコントロール、新しいバージョンのアルゴリズムを実験として考えます。

人口統計、興味、食事ニーズ、選択肢が似ているユーザーは2つのグループに分割され、選択バイアスを減らします。1つのグループのユーザーは古いシステムとやり取りし、もう1つのグループのユーザーは新しいシステムとやり取りします。

注文数、総商品価値（GMV）、ATC/注文などの一連の変換メトリックをキャプチャし、統計的有意性で仮説検定を行い、比較します。

統計的有意性を持つ確定的な証拠を得るためには、ABテスト実験を3〜4週間実行する必要があるかもしれません。時間は実験に参加するユーザーの数によって異なります。

インターリービング

インターリービングは、A/Bテストと同様の目的を達成する代替手段ですが、より短い時間で行います。インターリービングでは、ユーザーを2つのグループに分割する代わりに、リコメンデーションアルゴリズムの2つのバージョンからの結果を交互に混ぜ合わせた結果の組み合わせリストが作成されます。

推薦システムアルゴリズムを評価するには、オンライン評価とオフライン評価の両方が必要です。NDCG（正規化割引累積利得）、KendallのTau、適合率、再現率などのオフライン評価によって、開発者はアルゴリズムを素早く微調整してテストすることができます。オンライン評価はより現実的な評価を提供しますが、時間がかかります。

オフライン評価と/またはオンライン評価が完了すると、評価メトリックはテーブルに保存され、他のモデルと比較してモデルのパフォーマンスが判断されます。そうであれば、モデルはモデルレジストリに登録されます。

モデル提供フレームワーク

MLモデルが開発されると、次の課題はモデルを本番システムで提供することです。機械学習モデルの提供は、運用上の制約により、時には困難な場合があります。

主に、2つのタイプのモデル提供があります：

1. リアルタイム展開：この種のシステムでは、モデルがオンラインシステムに展開され、モデルの出力が非常に短時間で得られます。このセットのモデルはレイテンシに非常に敏感であり、レイテンシの要件を満たすために最適化が必要です。ほとんどの現実世界のビジネスクリティカルなシステムでは、リアルタイム処理が必要です。

1. バッチ展開：この種のシステムでは、モデルの出力はサンプルのバッチで推論されます。通常、ジョブをスケジュールしてモデルの出力を実行します。この種の展開では、レイテンシの問題に比較的少ない焦点が当てられます。

リアルタイムまたはミニバッチモードで低遅延を実現する必要があります。サービングと最適化のプロセスは、フレームワークの選択とモデルのタイプによって異なります。次のセクションでは、本番システムでMLモデルを提供するために低遅延を実現するのに役立つ人気のあるツールについて説明します。

オープンニューラルネットワークエクスチェンジ（ONNX）

Machine Learningモデルの推論時間の最適化は困難です。モデルのパラメータとアーキテクチャを最適化する必要があり、ハードウェア構成に合わせて調整する必要があります。GPU / CPUまたはクラウド/エッジでモデルを実行するかどうかによって、この問題は困難になります。さまざまな種類のハードウェアプラットフォームとソフトウェア環境に対してモデルを最適化して調整することは困難です。これがONNXの役割です。

ONNXは、Machine Learningモデルを表現するためのオープンな標準です。TensorFlow、Keras、PyTorch、scikit-learnなどで構築されたモデルは、標準のONNX形式に変換することができます。そのため、ONNXモデルはさまざまなプラットフォームとデバイスで実行できます。ONNXはDeep Neural NetworksとClassical Machine Learningモデルの両方をサポートしています。したがって、MLプラットフォームの一部としてONNXを使用すると、素早く反復できる時間が節約できます。

Triton推論サーバ

コンピュータビジョンモデルと言語モデルは、多くのパラメータを持つため、推論中に多くの時間を要します。モデルの推論時間を改善するために一連の最適化を実行する必要がある場合もあります。NVIDIA AI Platformによって開発されたTriton推論サーバは、訓練されたMLモデルを任意のインフラストラクチャで展開、実行、スケールすることができます。

Triton推論サーバはTensorFlow、NVIDIA® TensorRT™、PyTorch、MXNet、Python、ONNX、XGBoost、scikit-learn、RandomForest、OpenVINOなどをサポートしています。 Triton推論サーバは、大規模な言語モデルもサポートしており、大規模なモデルを複数のファイルに分割し、単一のGPUではなく複数のGPUで実行します。

これに関連する有用なリンクは次のとおりです – triton-inference、triton-serverのガイド。

モデルのモニタリング

MLモデルのパフォーマンスは、コンセプトの変化、データの変化、共変量のシフトなどの要因によって時間とともに悪化する場合があります。電子商取引の商品推薦システムの例を考えてみましょう。

前パンデミック時代のデータを使用してトレーニングされたモデルは、パンデミック後も同じようにうまく機能すると思いますか？このような予期しない事態のため、ユーザの行動は大きく変化しました。

• 1
  多くのユーザは、高価なガジェットではなく日常的な必需品の購入に焦点を当てています。
• 2
  それに加えて、供給チェーンの問題により、多くの商品が在庫切れになる可能性があります。
• 3
  電子商取引では、ユーザの買い物パターンはユーザの年齢とともに変化することを忘れてはいけません。

したがって、電子商取引の推薦システムは、そのような変化の後には関係なくなる可能性があります。

一部の人々は、モデルの監視は必要ではないと考えています。定期的なモデルの再トレーニングは、どのような形態のドリフトにも対応できるためです。これは正しいですが、この考え方はモデルがあまりにも大きくない場合にのみ有用です。徐々に私たちはより大きなモデルに移行しています。このようなモデルの再トレーニングは費用がかかる場合があり、巨額のコストがかかる可能性があります。したがって、モデルのモニタリングシステムを確立することで、このような困難を乗り越えるのに役立ちます。

小売業のためのMLOpsプラットフォームのベストプラクティス

小売業のMLチームは、予測から推奨システムまでさまざまな問題を解決しています。MLOpsプラットフォームを適切な方法で設定することは、チームの成功に不可欠です。以下は、効率的な電子商取引のMLOpsシステムを構築するために守る必要がある一部のベストプラクティスの一覧です。

モデルのバージョニング

電子商取引でMLモデルを開発する際、チームは多くの実験を実行する必要があります。その過程で、チームは複数のモデルを作成します。モデルのバージョンを管理することは困難になります。

ベストプラクティスは、モデルレジストリを維持することです。モデルは、パフォーマンスメトリックとモデル固有のメタデータと共に登録されます。したがって、新しいモデルが作成されるたびに、モデルにバージョンIDが付けられ、モデルレジストリに格納されます。

デプロイ中に、モデルはモデルレジストリから引き出され、ターゲットデバイスにデプロイされます。モデルレジストリを維持することにより、必要に応じて以前のモデルにフォールバックする選択肢を持つことができます。

フィーチャーストアの維持

データサイエンティストは、生データをフィーチャーに変換するために多くの時間を費やします。データサイエンティストの作業の約70%は、データセットの準備に費やされます。したがって、データの前処理と後処理のパイプラインを自動化してフィーチャーを作成することは、冗長な作業を減らすことになります。

フィーチャーストアは、フィーチャーを保存、管理、配布するための中央集権的なプラットフォームです。この中央レポジトリは、複数のチーム間でフィーチャーにアクセスするのを支援し、クロスコラボレーションを可能にし、モデル開発を迅速化します。

パフォーマンスメトリクスのトラッキング

eコマースの多くの機械学習モデルは、時間の経過とともに成熟していきます。反復的なプロセスを通じて、データの改善とより良いアーキテクチャの発見により、モデルのパフォーマンスは徐々に向上していきます。最良の手法の1つは、評価メトリクスの進捗状況を監視することです。したがって、アルゴリズムの評価メトリクスのダッシュボードを構築し、チームが正しい方向に進んでいるかどうかを監視することは良い慣行です。

CI/CDパイプラインの構築

CI/CDは、どのMLOpsシステムにおいても絶対に必要です。これにより、コードの変更をより迅速かつ効率的に本番環境にデリバリーすることが可能となります。CI/CDパイプラインは、コードのコミットからビルドの生成までのプロセスを効率化します。コードがコミットされるたびに一連の自動テストを実行し、開発者に変更に関するフィードバックを提供します。これにより、開発者は品質の高いコードを書く自信を得ることができます。

データドリフトとコンセプトドリフトのモニタリング

データ分布の重要な変化（データドリフトのキャプチャ）やモデルのパフォーマンスの重要な変化（コンセプトドリフトのキャプチャ）を特定するためのアラートの設定は、しばしば無視されがちですが、重要です。

頑健なA/Bテストプラットフォーム

A/Bテストは、顧客のエンゲージメントに基づいてアルゴリズムを評価する方法です。しかし、収束するまでには時間がかかることがよくあります。したがって、チームは交互に評価するなど、より速い評価方法を見つけるための時間を費やすべきです。

最終的な考え

この記事では、MLプラットフォームの主要なコンポーネントと、それをeコマースビジネス向けに構築する方法について説明しました。また、そのようなMLプラットフォームの必要性についても議論し、構築する際に従うべきベストプラクティスをまとめました。

MLの領域では頻繁に飛躍的な進歩があるため、将来、これらのコンポーネントやプラクティスの一部は変更が必要になるかもしれません。最新の動向について情報を得て、正しく進めるようにすることが重要です。この記事は同様の方向性を目指したものであり、読んだ後に、小売りビジネスに対してMLプラットフォームを準備することが少し楽になるでしょう。

参考文献

1. https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning 
2. https://learn.microsoft.com/en-us/azure/machine-learning/concept-onnx 
3. https://kreuks.github.io/machine%20learning/onnx-serving/ 
4. https://developer.nvidia.com/nvidia-triton-inference-server 
5. https://www.run.ai/guides/machine-learning-engineering/triton-inference-server

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!