大規模な機械学習: データサイエンスを本番システムアーキテクチャに導入するための典型的なパターン

ここ数年、データサイエンスの概念は多くの業界で受け入れられてきました。データ サイエンス (科学的研究テーマから派生) は、もともと人間の知能を理解し、人工知能を作成しようとした科学者から生まれましたが、現在では実際のビジネス価値をもたらすことができることが証明されています。

たとえば、私の会社である Zalando (ヨーロッパ最大のファッション小売業者) です。ここでは、データ サイエンスと他のツールを組み合わせて、データに基づく推奨事項を提供します。推奨事項自体は、製品ページ、カテゴリページ、ニュースレターメール、リターゲティングなど、さまざまな場所でバックエンドサービスとして提供されます。

図1: ミキオ・ブラウン氏のプレゼンテーションページからの画像

データに基づく推奨事項

実際、データに基づいて推奨事項を生成する方法は数多くあります。たとえば、いわゆる「協調フィルタリング」では、すべてのユーザー行動（商品の閲覧、ウィッシュリストの操作、購入行動など）を推奨の根拠として収集し、分析してどの商品が類似したユーザー行動パターンを持っているかを調べることができます。このアプローチの優れた点は、コンピューターがアイテムが何であるかを知る必要がないことです。ただし、この方法が機能することを保証するためには、製品に十分なユーザー行動情報データが必要であるという欠点があります。

推奨事項を生成する別の方法は、製品の属性のみを確認することです。たとえば、同じブランドや同じ色の商品をおすすめします。もちろん、これらの方法の拡張や組み合わせは数多くあります。

図 2: 画像は Antonio Freno 氏の提供によるもので、許可を得て使用しています。 KDD 2015 カンファレンスで発表された論文「低レイテンシー製品推奨のためのワンパスランキングモデル」より引用

より簡単な方法は、カウントのみに基づいて推奨を行うことです。しかし、このアプローチは実際には多くの複雑なバリエーションを持つことになります。たとえば、パーソナライズされた推奨事項については、製品セットのパーソナライズされたランキングを実行する「ランク付けの学習」手法を使用しました。上の図は、この方法で最小化する必要のある損失関数を示しています。

ただし、ここでこの図を描く主な目的は、データ サイエンスがもたらす可能性のある複雑さを示すことです。関数自体は、正規化条件を持つペアワイズ重み付けメトリックを使用します。この関数の数学的表現は非常に単純化されており、当然ながら非常に抽象的です。このアプローチは、電子商取引の推奨シナリオだけでなく、アイテムに十分な機能がある場合のあらゆる種類のランキング問題にも役立ちます。

データサイエンスの手法を業界に導入

上記のような非常に複雑な数学アルゴリズムを実稼働システムに導入するには、何をする必要がありますか? データ サイエンスとソフトウェア エンジニアリングのインターフェイスはどのようになっているべきでしょうか? これらのデータ サイエンス手法を使用するのに最適な組織構造とチーム構造はどのようなものでしょうか? これらはすべて、非常に関連性が高く、合理的な質問です。これらの質問に対する答えによって、データ サイエンティストへの投資やデータ サイエンス チーム全体への投資が最終的に報われるかどうかが決まるからです。

以下では、機械学習の研究者として、また Zalando でデータ サイエンティストとエンジニアのチームを率いている私の経験に基づいて、これらの質問のいくつかについて検討します。

データサイエンス（システム）と生産システムの関係を理解する

まず、データ サイエンス システムとバックエンド プロダクション システムの関係を理解し​​、この 2 つを統合する方法を見てみましょう。

図3: ミキオ・ブラウン氏のプレゼンテーションページからの画像

典型的なデータ サイエンスのワークフロー (パイプライン) を上の図に示します。最初のステップは常に、問題の発見とデータ (データベースから、または運用システムのログから) の収集から始まります。組織のデータがどの程度適切に準備されているかに応じて、この手順は困難になる可能性があります。まず、必要なデータへのアクセスを誰が許可できるか、またそのデータを使用する許可を誰が許可できるかを把握する必要があります。データが利用可能になったら、特徴値を抽出するために再度処理する必要がある場合があります。これらの機能が問題解決に役立つ情報を提供してくれることを期待しています。これらの特徴は学習アルゴリズムに入力され、結果として得られたモデルはテスト データを使用して評価され、モデルが新しいデータの予測に適しているかどうかが判断されます。

上記の分析パイプラインは通常、短期間の 1 回限りのジョブです。通常、すべての手順はデータ サイエンティストによって手動で実行されます。データ サイエンティストは、データ分析や視覚化のための多くのライブラリを含む Python などのプログラミング言語を使用することがあります。データの量に応じて、データ サイエンティストは Spark や Hadoop などのコンピューティング フレームワークも使用することがあります。しかし、一般的には、最初の段階ではデータセット全体のごく一部だけを分析に使用します。

なぜデータのほんの一部から始めるのでしょうか?

データのごく一部から開始する主な理由は、分析パイプライン プロセス全体が 1 回限りの処理ではなく、非常に反復的なプロセスであるためです。データ サイエンス プロジェクトは本質的に探索的であり、ある程度はオープンエンドです。プロジェクトの目的は明確でしたが、当初はどのようなデータが利用可能になるのか、また利用可能なデータが分析に適しているかどうかは明らかではありませんでした。結局のところ、アプローチとして機械学習を選択するということは、コードを記述するだけでは問題を解決できないことを意味します。代わりに、データ主導のアプローチを採用してください。

これらの特性は、上記の分析パイプラインが反復的であり、複数の改善、さまざまな機能、さまざまな前処理モード、さまざまな学習方法の試行、さらには開始点に戻ってさらに多くのデータ ソースを見つけて実験する必要があることを意味します。

プロセス全体は本質的に反復的であり、多くの場合、非常に探索的です。モデルの全体的なパフォーマンスが良好であれば、データ サイエンティストは開発された分析パイプラインを実際のデータに適用します。この時点で、ビルド システムとの統合の問題に直面します。

図4: ミキオ・ブラウン氏のプレゼンテーションページからの画像

生産システムとデータサイエンスシステムの区別

運用システムとデータ サイエンス システムの主な違いは、運用システムはリアルタイムで継続的に実行されるシステムであるということです。データは処理する必要があり、モデルは頻繁に更新する必要があります。生成されたイベントは、クリックスルー率などの主要なビジネス パフォーマンス指標を計算するためにもよく使用されます。モデルは通常、数時間ごとに新しいデータで再トレーニングされ、その後、新しいデータ (たとえば、REST インターフェイス経由で送信されるデータ) を提供するために実稼働システムにインポートされます。

これらの生産システムは、一般的に、高いパフォーマンスと高い信頼性をサポートできる Java などのプログラミング言語で記述されています。

図5: ミキオ・ブラウン氏のプレゼンテーションページからの画像

運用システムとデータ サイエンス システムを並べて配置すると、上記のような状況になります。右上にはデータサイエンスのセクションがあります。その典型的な特徴は、Python のような言語または Spark システムを使用することですが、一般的には 1 回限りの手動でトリガーされるコンピューティング タスクであり、システム全体が反復を通じて最適化されます。その出力はモデルであり、基本的には学習した数値の集まりです。このモデルは生成システムにインポートされます。実動システムは、Java などの言語で記述され、継続的に実行される典型的なエンタープライズ アプリケーション システムです。

もちろん、上の図は少し簡略化されています。実際には、モデルを再トレーニングする必要があるため、データ処理パイプラインのいくつかのバージョンが運用システムに統合され、運用システム内のモデルが随時更新されます。

本番環境で実行されている A/B テストに注目してください。データサイエンス側の評価部分に相当します。しかし、これら 2 つの部分は完全に比較できるとは限りません。たとえば、オフラインの推奨結果を顧客に表示せずに推奨の効果をシミュレートすることは困難ですが、そうすることでパフォーマンスが向上する可能性があります。

最後に、このシステムはインストールして展開しただけでは「すべて準備完了」ではないことを認識することが重要です。データ サイエンス側の担当者がデータ分析パイプラインを最適化するために複数回反復する必要があるのと同様に、データ分布が変化するにつれて、リアルタイム システム全体も反復的に進化する必要があります。これにより、新しいデータ分析タスクが可能になります。私にとって、この「外部反復」を正しく行うことが、生産システムにとって最大の課題であり、最も重要なステップでもあります。これによって、生産システムを継続的に改善し、データ サイエンスへの初期投資が確実に報われるかどうかが決まります。

データ サイエンティストとプログラマー: コラボレーションのモデル

これまでは、システムが本番環境でどのように見えるかに主に焦点を当ててきました。もちろん、生産システムの安定性と効率性を確保する方法はたくさんあります。 Python で記述されたモデルを直接デプロイするだけで十分な場合もありますが、実稼働システムと探索的分析部分の間には確実に分離が存在します。

直面する最大の課題の 1 つは、データ サイエンティストとプログラマーのコラボレーションを調整することです。 「データサイエンティスト」はまだ新しい役割ですが、彼らが行う仕事は一般的なプログラマーの仕事とは大きく異なります。その結果生じる誤解やコミュニケーションの障壁は避けられません。

データ サイエンティストの仕事は多くの場合、探索的です。データ サイエンス プロジェクトは通常、漠然とした目標、利用可能なデータのアイデア、および可能なアルゴリズムから始まります。しかし、データ サイエンティストが複数のアイデアを試し、データから洞察を得る必要があることはよくあります。データ サイエンティストは大量のコードを書きますが、そのほとんどはアイデアをテストするために使用され、最終的なソリューションには使用されません。

図6: ミキオ・ブラウン氏のプレゼンテーションページからの画像

データ サイエンティストとは対照的に、プログラマーは通常、プログラミングに重点を置いています。彼らの目標は、必要な機能を実装するシステムを開発することです。プログラマーは、プロトタイプの構築、概念の証明、パフォーマンス ベンチマークのテストなどの探索的な作業を行うことがあります。しかし、彼らの仕事の主な目的は依然としてコードを書くことです。

それらの違いはコードの変更にも明確に反映されています。プログラマーは通常、非常に明確に定義されたコード開発プロセスに従います。これには通常、独自のワークフローのブランチを作成し、開発が完了した後にレビューを行い、ブランチをメイン ブランチにマージすることが含まれます。誰もが並行して開発できますが、ブランチをメイン ブランチにマージする前に交渉する必要があります。その後、このプロセスが繰り返されます。このプロセス全体により、メイン ブランチが秩序正しく進化することが保証されます。

図7: ミキオ・ブラウン氏のプレゼンテーションページからの画像

データ サイエンティストも大量のコードを書きます。しかし、前にも言ったように、このコードは通常、アイデアをテストするためのものです。したがって、データ サイエンティストはバージョン 1 を作成するかもしれませんが、要件は実装されません。その後、新しいアイデアでバージョン 2 を作成し、続いてバージョン 2.1、バージョン 2.2 を作成しましたが、それでも要件を満たせないことがわかったため、作成を中止しました。次に、更新されたアイデアに基づいてバージョン 3 と 3.1 を作成します。おそらくこの時点で、データ サイエンティストは、バージョン 2.1 のテクニックのいくつかをバージョン 3.1 のテクニックのいくつかと組み合わせると、より優れたソリューションが得られることに気付くでしょう。これによりバージョン 3.3 と 3.4 が生まれ、これが最終的な解決策となる可能性があります。

図8: ミキオ・ブラウン氏のスピーチページの画像

興味深いのは、データ サイエンティストが実際にはうまくいかなかったバージョンをすべて保存しておきたいと考えるかもしれないということです。なぜなら、将来のある時点で、新しいアイデアをテストするために使用される可能性があるからです。おそらく、いくつかのパーツを「ツールボックス」に入れて、データ サイエンティスト独自のプライベート機械学習ライブラリを徐々に形成できるでしょう。プログラマーは「デッドコード」を削除する傾向があります (デッドコードをすぐに復元する方法を知っているため)。一方、データ サイエンティストは、念のためコードを保持しておくことを好みます。

上記の 2 つの違いは、実際にはプログラマーとデータ サイエンティストが直接連携すると問題が発生する可能性があることを意味します。標準的なソフトウェア エンジニアリング プロセスは、データ サイエンティストの目標が異なるため、データ サイエンティストの探索的作業モードには適していません。コードレビューチェックや、ブランチの管理、レビュー、ブランチのマージといった整然としたワークフローを導入することは、データサイエンティストには適しておらず、作業の速度を低下させることになります。同様に、探索モデルを本番システム開発に導入しても成功しません。

そのためには、双方が生産的に働けるようにするコラボレーション モデルをどのように構築すればよいでしょうか。おそらく、最初に思いつくのは、両者が別々に働けるようにすることでしょう。たとえば、コード ベースを完全に分離し、データ サイエンティストが独立して作業して要件ドキュメントを作成し、それをプログラミング チームで実装します。このアプローチは機能しますが、通常、プロセスは非常に遅く、エラーが発生しやすくなります。特にプログラマーがデータ分析アルゴリズムに精通していない場合、再開発と実装によってエラーが発生する可能性があるためです。同時に、システムのパフォーマンスを向上させるために外部反復を実行できるかどうかは、プログラマーがデータ サイエンティストのニーズを満たすのに十分な能力を持っているかどうかによっても異なります。

図9: ミキオ・ブラウン氏のプレゼンテーションページからの画像

幸いなことに、多くのデータ サイエンティストは実際に優れたプログラマーになりたいと思っており、その逆もまた同様です。そこで私たちは、より直接的でプロセスをスピードアップできるいくつかのコラボレーション モデルの実験を始めました。

たとえば、データ サイエンティストとプログラマーのコード ベースは依然として分離されていますが、一部の運用システムでは、データ サイエンティストがシステムにメソッドを組み込みやすくするために、明確に定義されたインターフェイスが提供されています。これらの運用システムとインターフェースするコードは、厳格なソフトウェア開発手法を使用して記述する必要がありますが、これはデータ サイエンティストの仕事です。このようにして、データ サイエンス チームは独自のコードを迅速に反復処理できるだけでなく、運用システムでも反復処理を行うことができます。

図10: ミキオ・ブラウン氏のプレゼンテーションページからの画像

このアーキテクチャ パターンの具体的な実装の 1 つは、「マイクロサービス」アプローチを採用することです。つまり、本番システムがデータ サイエンティスト チームによって開発されたマイクロサービスを呼び出して推奨事項を取得するようにします。このように、データ サイエンティストが使用するオフライン分析パイプライン全体を A/B テスト用に調整したり、プログラマー チームが再開発して実装しなくても実稼働システムに追加したりすることもできます。このモデルでは、データ サイエンティストにさらなるソフトウェア エンジニアリング スキルが求められますが、すでにそのようなスキル セットを備えたデータ サイエンティストが増えています。実際、私たちはこの現実を反映して、Zalando のデータ サイエンティストの職名を「リサーチ エンジニア (データ サイエンス)」に変更しました。

このようなアプローチを使用すると、データ サイエンティストはすぐに作業を開始し、オフライン データに対して反復的な調査を実行し、実稼働システム環境で反復的に開発することができます。チーム全体が安定したデータ分析手法を継続的に本番システムに移行できます。

継続的に適応し、改善する

これまで、データ サイエンスを本番システムに導入できるアーキテクチャの典型的なパターンについて概説しました。理解すべき重要な概念は、このようなシステムは継続的に適応し、改善する必要があるということです (これは、実際のデータを扱うほぼすべてのデータ駆動型プロジェクトと同様です)。迅速に反復し、新しいアプローチを試し、A/B テストを使用して結果を検証できることは非常に重要です。

私の経験では、データ サイエンティスト チームとプログラマー チームを分離したままでは、これらの目標を達成することは不可能です。同時に、2 つのチームの目標が異なるため、2 つのチームの作業方法も異なることを認識することが重要です (データ サイエンティストの作業はより探索的であるのに対し、プログラマーはソフトウェアとシステムの開発に重点を置いています)。

各チームがそれぞれの目標に最適な方法で作業できるようにし、明確なインターフェースを定義することで、2 つのチームを統合し、新しいアプローチを迅速に試してテストできるようになります。これには、データ サイエンティスト チームにさらなるソフトウェア エンジニアリング スキル、または少なくとも 2 つの世界をつなぐソフトウェア エンジニアが必要になります。

著者について

Mikio Braun 氏は、Zalando の推奨および検索システムのデリバリー リーダーです。 Zalando はヨーロッパ最大のファッション プラットフォームの 1 つです。ミキオは機械学習の博士号を取得しており、長年研究を行った後、研究結果を業界への応用に活かすことに尽力しました。