3

私は次の設定をしています：

ブールデータ: (userid, itemid)

次の引数を持つ Hadoop ベースの mahout itemSimilarityJob: --similarityClassname Similarity_Loglikelihood --maxSimilaritiesPerItem 50 & その他 (入力、出力..)

アイテムベースのブール推奨: -model MySqlBooleanPrefJDBCDataModel -similarity MySQLJDBCInMemoryItemSimilarity -candidatestrategy AllSimilarItemsCandidateItemsStrategy -mostSimilarItemsCandidateStrategy AllSimilarItemsCandidateItemsStrategy

  1. セットアップで類似性共起を使用して最終的な推奨事項を取得する方法はありますか? ジョブに SIMILARITY_COOCCURENCE をプラグインすると、MySqlJDBCInMemorySimilarity 前提条件チェックが失敗します。これは、カウントが 1 より大きくなるためです。事前計算された類似性に対して推奨ジョブを実行することで、最終的な推奨を取得できることがわかっています。MysqlInMemorySimilarity を使用して、類似度対数尤度 (および -1 と 1 の間の類似度値を持つ他の類似度メトリック) の場合のように、API を使用してこれをリアルタイムで行う方法はありますか?

  2. どうすれば最大数を制限できますか。アイテム類似性ジョブのアイテムごとの類似アイテムの数。ここで言いたいのは、 allsimilaritemscandidatestrategy は .allsimilaritems(item) を呼び出して、すべての可能な候補を取得するということです。API を使用して上位 10/20/50 の類似アイテムを取得する方法はありますか。--maxSimilaritiesPerItem をアイテムの類似度ジョブに渡すことができることは知っていますが、それが何を表し、どのように機能するかについては完全にはわかりません。これを 10/20/50 に設定すると、上記のことを達成できますか。また、APIを介してこれを達成する方法はありますか?

  3. 最終的な推奨事項をフィルタリングして再スコアリングするために、レスコーラーを使用しています。rescorer を使用すると、/recommend/userid?howMany=10&rescore={..} および /similar/itemid?howMany=10&rescore{..} への呼び出しが、(30-70ms) に比べて (300ms-400ms) 長くなります。スコアラーなしで。rescore データを取得するためのメモリ内ストアとして redis を使用しています。上記のように、rescorer は実行時データも受け取ります。rescorer で行われるチェックはほんのわずかです。問題は、いいえとしてそれです。特定のユーザーのアイテム嗜好の増加 (> 100)、いいえ。isFiltered() と rescore() の呼び出しが大幅に増加します。これは主に、すべてのユーザー設定について、candidateStrategy.getCandidatItems(item) への呼び出しが、それぞれについて約 (100 以上) の類似アイテムを返し、これらのアイテムごとに rescorer が呼び出されるという事実によるものです。したがって、ジョブ内のアイテムごとの類似アイテムの最大数を制限する必要があります。これは正しいですか、それともここで何か不足していますか? この場合、レスコーラーを最適化する最良の方法は何ですか?

MysqlJdbcInMemorySimilarity は、GenericItemSimilarity を使用してアイテムの類似性をメモリにロードし、その .allsimilaritems(item) は、mysql で事前に計算されたアイテムの類似性から、特定のアイテムのすべての可能な類似アイテムを返します。上位 10/20/50 の類似アイテムを返すために、独自のアイテム類似性クラスを実装する必要がありますか? ユーザーの場合はどうなりますか。の好みは増え続けていますか？

誰かが上記を達成する方法を教えてくれたら本当に素晴らしいでしょうか? ありがとうございます！

4

1 に答える 1

2

どの前提条件チェックについて言及していますか? 見えません。ItemSimilarity類似度が1以上禁止なのかどうかは分かりませんが、Hadoopでは使わないので、共起だけを返す類似度関数を作ってもらえないかという質問のようです。はい、できます。プロジェクトには存在しません。私はこれをお勧めしません。LogLikelihoodSimilarityはるかに賢くなるでしょう。

別CandidateItemStrategyの、特に、look atSamplingCandidateItemsStrategyとその javadoc が必要です。しかし、これはランタイム要素ではなく Hadoop とは関係なく、Hadoop ジョブへのフラグについて言及しています。それは同じことではありません。

再スコアリングが遅い場合、それはまあ、遅いことを意味しIDRescorerます。何度も呼び出されるため、検索データをメモリにキャッシュする必要があります。ただし、上記の候補の数を減らすと、これが呼び出される回数も減ります。

いいえ、独自の類似性を実装しないでください。あなたの問題は類似度ではなく、候補と見なされるアイテムの数です。

私はあなたが話しているコードの多くの作者です。大規模なアイテムベースの作品を作成しようとするときに、ほとんどの人が遭遇するのとまったく同じ種類の問題に取り組んでいると思います。十分なサンプリングとチューニングを行えば可能です。

しかし、私はMyrrixと呼ばれる別のプロジェクトと会社に新しい開発を入れています。これは、同じ API に基づいた一種の「次世代」レコメンダーを開発していますが、行列分解に基づいているため、これらの複雑さなしにスケーリングする必要があります。時間と興味があれば、Myrrix をご覧になることを強くお勧めします。同じ API、リアルタイム サービス層は無料/オープンであり、裏打ちされた Hadoop ベースの計算層もテストに利用できます。

于 2012-08-31T15:50:00.547 に答える