問題タブ [mahout-recommender]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
1040 参照

mahout - Recommendation Engine のファイル入力形式とは何ですか?

この形式で入力ファイルを提供しているときに、Hadoop クラスターでジョブを実行している Ubuntu12.04、Hadoop-1.0.4、Mahout-0.7 を使用しています。

tataRecommend100.txt (ユーザー ID - 製品 ID - 設定)

指図 :-bin/hadoop jar /home/hadoop/apacheC/mahout-distribution-0.7/mahout-core-0.7-job.jar
org.apache.mahout.cf.taste.hadoop.item.RecommenderJob -s SIMILARITY_COOCCURRENCE --input /tataDocomo/recommend/tataRecommend100.txt --output /tataDocomo/recommend/tataRecommendOutput

0 投票する
2 に答える
125 参照

machine-learning - この種の「ネストされた」レコメンデーションに使用するモデルまたはアプローチは何ですか?

非常に具体的な推奨事項の問題があります。

アイテム、プロパティ、値の 3 種類の値/エンティティがあるとします。N 個のアイテム、A プロパティ、および B 値があります。各アイテムには、いくつかのプロパティと値のペアがあります。例:

アイテム#1
2374-23783
8455-5783
744-2438

アイテム#2
5435-23783
8455-54654
544-9778

...

ここで、上記のような 3 ~ 4 個のサンプル プロパティ値のペアを持つ Item#x などの「匿名」アイテムが与えられた場合、特定のプロパティの推奨事項を取得したいと考えています。例:

アイテム番号 x
5435-23783
544-9778
744-2438

8455-?? (推薦を受ける)

ここで、直観 - Item#x のプロパティ 8455 の推奨値は 54654 である可能性があります。プロパティ 5435 と 744 は、Item#2 と Item#x の値が同じであることがわかります。したがって、8455 の値は、項目 2 の 8455 の値と同様になる可能性が高くなります。

質問:

  1. この問題にはどのようなモデルが最適だと思いますか? どのようなアプローチを使用する必要がありますか? 協調フィルタリング - しかし、どのように? すべてのプロパティと値のペアをデータセットにダンプし、推奨事項をフェッチするだけでは、明らかに私のニーズは満たされません。

  2. 実装固有の詳細も追加できますか? マハウト?ミリックス?機械学習/推奨ライブラリ?

0 投票する
1 に答える
225 参照

multithreading - Mahout の最適化: TopItems.getTopUsers() および TopItems.getTopItems() のマルチスレッド化

次のシステムを導入してい
ます: ユーザー数: ~500k
アイテム数: ~100k

上記のレコメンダーを使用すると、400 の近傍サイズで平均 600 ミリ秒の応答時間が得られました。

これを 100 ミリ秒未満 (オンライン エンジン) にしようとしましたが、カスタムの TopItems.getTopUsers()およびTopItems.getTopItems()マルチスレッド (コア数に等しい) 関数を使用してこれを達成しました。関数の平均所要時間
TopUsers(): ~ 30-40 ms
TopItems(): ~ 50-60 ms

ただし、多くの同時リクエスト (25 のオーダーまで) を試みた場合、応答時間は数秒に短縮されます。

各ユーザーの近隣などを事前に計算する余裕はありますが、TopItems() は依然として同時リクエストの明確なボトルネックです。

マルチスレッドによる同時リクエストの応答時間を改善する方法はありますか?

フォールバック オプションは、事前計算された推奨事項を一部の NoSql DB に保存することです。それほどアクティブでないユーザーに対しても定期的に事前計算を行うため、これは少しコストがかかります。おそらく、アクティブなユーザーを選択し、あまりアクティブでないユーザーよりも頻繁に推奨事項を事前計算することができます。

何かご意見は?

0 投票する
1 に答える
87 参照

java - mahout 0.7 の mahout 0.5 の VectorWritable.addTo と同等のメソッドは何ですか?

実行中のブック マーハウトのコードにメソッドがありません。Mahout 0.7 には addTo がないようです。同等のものは何ですか?ありがとう!

0 投票する
1 に答える
633 参照

categories - Mahout: 特定の製品カテゴリでユーザーにアイテムをレコメンドする

現在、私たちは何を持っていますか?・MahoutのGenericItemBasedRecommenderを使って、TanimotoCoefficientSimilarityをItemSimilarityとして使用しているユーザーのおすすめ商品一覧を取得しています。

ここからどこへ行きたいですか?- 製品カテゴリを気にしない場合、上記は問題なく機能しますが、知りたいのは製品カテゴリ固有の推奨事項です。つまり、ユーザーが購入、閲覧、好みなどを行っているとします。具体的には、メンズとガジェットのカテゴリであるとします。次に、このユーザーの推奨事項をその特定のカテゴリに表示して、[X] であなたに推奨されていることを示します。この場合、X は Mens または Gadgets に置き換えられます。これを達成するために、以下のいくつかのオプションを検討しています。正しい方向に進んでいることを確認するために、いくつかのリード/意見/フィードバックなどが必要です. オプション:

  1. まず、アイテムの類似度を計算するために、タニモト以外のバージョンに移行する必要があります。これにより、データの表示/閲覧だけでなく、ユーザーの購入、好みなども考慮することができます。
  2. 特定のユーザー向けの製品カテゴリの把握 (ここで方向性が必要です) - 製品カテゴリ階層は基本的にツリーであり、ユーザーに表示するツリーの上位 4 つのノード (最適な推奨事項) を知る必要があります。また、ノード X がユーザーに表示するカテゴリであり、ノード Y がノード X の親である場合、カテゴリ Y またはその親のユーザー製品を表示したくありません。これを達成するいくつかの方法:

    • すべてのユーザーについて、リーフ レベルでノードの項目の類似性スコア値の SUM を計算し、ルートまで親ノードを再帰的に計算します。これで、各ノードに A = 類似度スコアの合計 & B = 推奨されるアイテムの数があるため、各ノードに A/B= 値 (V) もあります。次に、ツリーから上位 4 つの V 値を選択し、それをユーザーに推奨します。ここでの課題は、リクエスト中にこれをオンラインで計算しようとすると、リクエスト全体でこれを 150 ミリ秒未満に制限するのが難しいことです。例:

      カテゴリ 1 の推奨製品: アイテム 1 (スコア = 2)、アイテム 2 (スコア = 4)
      カテゴリ 2 の推奨製品: アイテム 3 (スコア = 1)、アイテム 4 (スコア = 4)

    • 2 番目のオプション: カテゴリごとに、ユーザーの行動 (いいね、購入、閲覧など) に基づいてユーザーのクラスターを作成し、ユーザーが属する上位 4 つのカテゴリを見つけます。Mahout でクラスタリングを使用してこれを達成できるかどうかはわかりませんが、オフラインで実行できると思います。

フィードバック/提案/リード/考えを提供してください。

前もって感謝します!

0 投票する
0 に答える
962 参照

mahout - Mahout コンテンツベースの類似性

製品分類に基づいてコンテンツ ベースの類似性をシミュレートするカスタム アイテムの類似性を作成しました。次の 2 つのアイテムだけを気に入っているユーザーがいます。

私のカスタムitemSimilarityは [-1,1] の値を返します。ここで、1 は強い類似性を意味し、-1 は強い非類似性を意味します。ユーザーが気に入った 2 つのアイテムには、分類ツリー内で最も低い共通の祖先がないため、値が 1 ではありません。ただし、一部のアイテムでは 0、0.20、および 0.25 の値になります。

私は次の方法で推奨事項を作成します。

私は次の結果を得ています:

一見誰かが言うだろう、それはレコメンデーションを生成します。ペアごとのアイテム間の比較を行うため、 から値を出力しようとしましたitemSimilarityが、次の驚くべき結果が得られました。

そして、さらにいくつかあります。それらは製造オーダーにはありません。要点を言いたかっただけです。-1 の非常に強い非類似性を持つアイテムはすべて推奨され、0.0、0.2、および 0.25 の類似性を持つアイテムはまったく推奨されません。これはどのように可能ですか?itemSimilarityインターフェイスのメソッドにItemSimilarityは、次の説明があります。

このインターフェースの実装は、2 つのアイテム間の類似性の概念を定義します。実装は、-1.0 から 1.0 の範囲の値を返す必要があります。1.0 は完全な類似性を表します。

[0,1] 間の類似性を使用すると、次の推奨事項が得られます。

ペアごとの類似度は次のとおりです (それらのツリーのみ、他のツリーは 0):

EDIT1449133, 18886199 : with:に最もよく似たアイテムも印刷しました(GenericItemBasedRecommender)delegate).mostSimilarItems(new long[]{1449133, 18886199}, 10)[RecommendedItem[item:228964, value:0.125], RecommendedItem[item:950062, value:0.125], RecommendedItem[item:899573, value:0.1]]

アイテム 18886199 のみ、(GenericItemBasedRecommender)delegate).mostSimilarItems(new long[]{18886199}, 10)を入手し[RecommendedItem[item:228964, value:0.25]]ました。似たような商品は1449133ありません。

なぜそれが強い相違点で機能しないのかわかりませんか?もう 1 つの疑問は、予測された選好値がすべて8.0またはである理由4.5です。18886199おすすめ商品と商品だけが類似しているのがわかりますが、 の場合の類似度に 8.0 の値を掛けて、 の代わりに の0.25値を求める方法はありますか?これは、ユーザーがまだわからないため、類似度を計算している間は実行できませんが、推奨段階で実行する必要があると思います。これはレコメンダーがどのように機能するべきか、またはカスタムのレコメンダーを作成してカスタムの方法でジョブを実行する必要があるのではないでしょうか?2.08.0

Mahout コミュニティの誰かが私に指示を与えることができれば、本当に感謝しています。