「Apache CassandraとApache Pulsarを使用した製品推薦エンジンの構築」
「Apache CassandraとApache Pulsarを使用した製品推薦エンジンの構築」
人工知能（AI）と機械学習（ML）ソリューションを実装する旅は、デジタルシステムで頻繁に発生する共通の課題を解決することを要します：レガシーシステムの更新、バッチ処理の削除、そして数年前にはまるでSFのように思えた方法で顧客体験を向上させるためにAI/MLに基づいた革新的な技術を使用します。
この進化を具体的に示すために、仮想の契約業者が大型小売業者でAI/MLソリューションを実装する手助けをするために雇われたとします。これはAI/MLへの旅の重要な側面を詳細に説明する一連の記事の最初のものです。
問題
「インフラストラクチャ」チームの一員としてBigBoxCoでの最初の日です。人事手続きを終えた後、私は契約業者のバッジを受け取り、新しいワークスペースに移動しました。チームとの会合の後、今朝は「推奨」チームとの会議があると伝えられました。私のシステムアクセスはまだうまくいっていないので、会議中にITがそれを解決してくれることを期待します。
会議室では、私たち数人だけです：私のマネージャーと新しいチームの他の2人のエンジニア、そして推奨チームのエンジニア1人です。まずは自己紹介から始め、それから先週の問題について話し合います。どうやら先週、何らかのバッチの障害があったようで、その影響がまだ残っているようです。
現在の商品の推奨は、顧客の注文から収集されたデータに基づいています。各注文ごとに、注文された商品間の新しい関連が記録されます。顧客が商品ページを閲覧すると、現在の商品と他の商品を一緒に購入した他の顧客の数に基づいて推奨が表示されます。
商品の推奨は、bigboxco.com上のユーザーにマイクロサービスレイヤーを介して提供されます。マイクロサービスレイヤーは、結果を提供するためにApache Cassandraのローカル（クラウド）データセンターデプロイメントを使用します。
ただし、結果の収集と提供方法はまったく別の話です。基本的に、商品間（一緒に購入されたもの）の関連の結果は、MapReduceジョブ中にコンパイルされます。これが先週失敗したバッチ処理です。このバッチ処理は以前から高速ではありませんでしたが、時間が経つにつれて遅くなり、もろくなりました。実際、プロセスが2日、または3日かかることもあります。
体験の向上
会議の後、私はコンピュータをチェックし、ようやくログインできるようになったようです。周りを見回していると、主任エンジニア（PE）がやってきて自己紹介します。私は推奨チームとの会議について話し、彼は推奨サービスの背後にある歴史についてもう少し話してくれました。
10年ほど前からそのバッチ処理が存在しているようです。設計したエンジニアは去っており、組織内でそれを本当に理解している人はほとんどいませんし、誰もそれに触れたがりません。
もう1つの問題は、私が説明し始めたところですが、各推奨を駆動するデータセットはほとんど常に数日前のものです。これが大した問題ではないかもしれませんが、推奨データをより最新のものにすると、マーケティングが行う短期的なプロモーションに利益をもたらすでしょう。
彼は同意し、システムの改善に関する提案を歓迎すると言います。
グラフの問題かもしれませんか？
最初にこれを聞いたとき、これは私にとってグラフの問題のように思えます。私たちはサイトにログインして商品を購入する顧客を持っています。その前に、商品を見たりカートに追加するときに、「Xを購入した顧客はYも購入しました」という形で推奨を表示することができます。このサイトでは、推奨サービスがまさにこれを行っており、頻繁に一緒に購入される上位4つの追加商品が返されます。
ただし、商品ごとに他のすべての商品とのマッピングは、2億人の顧客のどれかが同時に購入した同じ時間帯の商品ごとに大きくなる可能性がありますので、それらを「ランク付け」する方法が必要です。注文で表示される回数によってそれらをランク付けすることができます。
顧客と購入商品との関係を示す商品推奨グラフ。
これをモデル化し、実際のデータのボリュームでグラフデータベース上で実行した後、私はすぐにこれはうまくいかないことに気付きました。1つの商品から近くの顧客に移動し、それらの商品を計算し、最も頻繁に表示される商品を取得するためには、おおよそ10秒かかります。基本的には、私たちは2日間のバッチの問題を各ルックアップに「放り投げて」しまっており、トラバーサルのレイテンシをまさに顧客の前に置いてしまっています。
しかし、おそらくそのグラフモデルはここで行う必要があることからはあまり遠くないかもしれません。実際、上述のアプローチは、コラボラティブフィルタリングとして知られる機械学習（ML）の手法です。基本的には、コラボラティブフィルタリングは、他のユーザーとの活動に基づいて特定のデータオブジェクトの類似性を調べ、そのデータに基づいて予測を行うアプローチです。私たちの場合、顧客ベースからカート/注文データを暗黙的に収集し、それを使用してオンライン販売を増やすためのより良い製品の推奨を行います。
実装
まず、データの収集を見てみましょう。ショッピングの「注文する」機能に追加のサービスコールをすることはそれほど大きな問題ではありません。実際、既に存在しています。ただし、データはデータベースに保存され、後で処理されます。誤解しないでください：バッチ処理も含めたいと思っています。ただし、カートデータをリアルタイムで処理してオンラインデータセットに直接フィードバックできるようにしたいと思います。
まず、Apache Pulsarのようなイベントストリーミングソリューションを導入します。これにより、すべての新しいカートのアクティビティがPulsarのトピックに置かれ、バッチデータベースとリアルタイムMLモデルの学習の両方に消費されます。
後者については、Pulsarのコンシューマは、単純に注文内の各製品のエントリを保持するために設計されたCassandraテーブルに書き込みます（図2に示されています）。その製品には、その他の注文のすべての製品用に行があります。
既存のバッチフィード型の推奨システムにApache PulsarおよびApache Cassandraを組み込む方法。
次に、このテーブルから特定の製品（この例では「DSH915」）をクエリできます。
その後、上位4つの結果を取り出して、`product_id`でクエリを行うための製品の推奨テーブルに入れることができます。
このようにして、新しい推奨データは常に最新の状態に保たれます。また、上記で説明したすべてのインフラアセットは、ローカルデータセンターに配置されています。したがって、注文から製品の関係を取得し、それらをPulsarのトピックを介して送信し、Cassandraに格納された推奨に処理するプロセスは、1秒未満で行われます。このシンプルなデータモデルにより、Cassandraは要求された推奨を一桁のミリ秒で提供することができます。
結論と次のステップ
長期的には、Cassandraテーブルにデータがどのように書き込まれているかを確認する必要があります。これにより、行の増加やインプレース更新などの潜在的な問題に先んじて対処できます。
また、特定の製品に対する「おすすめしない」リストなどの追加のヒューリスティックフィルターを追加する必要があるかもしれません。これは、お客様が一度またはまれに購入する商品があり、それらを推奨することで他の商品からスペースを奪うだけであり、衝動買いする可能性がはるかに高い他の商品からスペースを奪う可能性があるためです。例えば、洗濯機などの家電部門の製品を購入を推奨することは、おそらく「衝動買い」にはつながらないでしょう。
また、将来的な改善策として、KaskadaのようなリアルタイムAI/MLプラットフォームを導入して、製品関連のストリーミングと推奨データのサービスへの提供を両方処理することが考えられます。
幸いなことに、Pulsarを使用してカート追加イベントをリアルタイムで処理する方法を考案することができました。このシステムが長期的にどのように実行されるかを把握した後は、従来のバッチプロセスを終了することを検討する必要があります。PEは新しいソリューションで良い進展を遂げ、さらにはいくつかの技術的負債を解消する基盤を築き始めたことを認めました。結果として、すべての人が良い気分になっています。
次回の記事では、ベクトル検索による製品プロモーションの改善について見ていきます。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
