0

仕事では、Mahout の Item ベースの CF パッケージに基づいて Item ベースのレコメンデーション システムを構築しようとしています。私たちが扱っている問題は次のとおりです。

ユーザー数: 6,000,000 アイテム数: 200,000 プリファレンス: 10,000,000,000

Hadoop クラスターに数百台のマシンがある場合、数時間以内に RecommenderJob を完了できる可能性があります。ただし、問題は、私たちは小規模なスタートアップであるため、この段階で Hadoop クラスターに約 10 台のマシンしかないことです。理想的には、推奨ジョブを数日に 1 回実行したいと考えています。

問題の規模を理解するために、Mahout の Item ベースの CF をデータの小さなサブセットに適用しました。

ユーザー数: 100,000 アイテム数: 80,000 プリファレンス: 3,000,000

RecommenderJob にかかる時間は、Hadoop クラスターで約 10 分です。

私の質問は、ハードウェアの制限 (短期的に変更される可能性は低い) を考えると、Mahout のアイテムベースの CF を高速化するにはどうすればよいですか?

4

1 に答える 1

0

レコメンデーション システムの標準的なスケーリングの問題があるようです。あなたの場合、分析を複数の部分に分割する必要があります。

  1. アイテム間類似度計算部分。
  2. アイテム間の類似度値を使用したユーザーアイテムのレコメンデーション部分。

ポイントは、多くの評価を持つアイテム間の類似性はあまり変わらないということです。そして、まさにこれがコストのかかる部分です。これは、それらの類似度を 1 回だけ計算し、長い時間 (数週間、数か月?) 後に再度計算できることを意味します。1週間後、2週間後などにどれだけ変化したかを評価できます。その後、毎日評価が少ないアイテムのアイテム間の類似性を計算するだけで済みます-もちろん、新しい評価がある場合です! レコメンデーション エンジンの分野では、評価が少なすぎること自体が問題です。今はこれには立ち入りません。

したがって、常に最新のアイテム - アイテム - 類似性リストがあれば、それらに基づいてユーザー - アイテムの推奨を行うことができます。アイテムの量がそれほど変わらない場合、これは一定時間の操作です。これは、ユーザーがアプリにアクセスするときにリアルタイムで実行できます。したがって、二度と戻ってこないユーザーの推奨事項を計算する必要はありません。ユーザー アイテムの予測される評価は、基本的に、そのユーザーによって評価されたすべてのアイテムの合計であり、アイテムの類似性スコアによって加重されます。mahout が提供しているかどうかを確認する必要があります

于 2014-01-07T17:26:50.347 に答える