コンテンツベースのアイテム推奨のアプローチ

Question

私は現在、同様のアイテムをグループ化するアプリケーションを開発中です。アイテム（動画など）はユーザーが作成することができ、その属性も後で（新しいタグのように）変更または拡張することができます。ほとんどのコラボレーティブなフィルタリングの仕組みのようにユーザの嗜好に頼るのではなく、アイテムの属性（類似した長さ、類似の色、同様のタグのセットなど）に基づいてアイテムの類似性を比較したい。計算は、主に2つの目的で必要です。与えられたアイテムの類似アイテムを提案し、同様のアイテムのグループにクラスタリングする。

これまでのアプリケーションは、非同期設計であり、このクラスタリングコンポーネントを可能な限りデカップリングしたいと考えています。新しいアイテムの作成または既存のアイテムの新しい属性の追加は、コンポーネントが消費できるイベントを公開することによって宣伝されます。

計算は、ベストエフォートと「スナップショット」を提供することができます。つまり、ある時点で最良の結果が得られますが、最終的に結果の品質は向上します。

これで、類似のアイテムとクラスタの両方を計算する適切なアルゴリズムを探しています。重要な制約にはスケーラビリティがあります。当初、アプリケーションは数千のアイテムを処理する必要がありましたが、それ以降のアイテムも可能です。もちろん、追加のノードで計算が実行されますが、アルゴリズム自体はスケーリングされます。アルゴリズムがデータの部分的な変更に対して何らかの種類のインクリメンタル・モードをサポートしているなら、それはいいかもしれません。

私の最初の考えは、それぞれのアイテムをお互いに比較し、数字の類似性を保存することは少し原油を鳴らします。また、すべての類似点を格納するためにn*(n-1)/2のエントリが必要であり、変更または新しいアイテムは最終的にnの類似度計算を引き起こします。

ありがとうございます！

UPDATE TLは、DR

は、私が欲しいものを明確にするために、ここに私の目標とシナリオは次のとおりです。

• ユーザーのエントリ（書類を考える）
• ユーザー編集エントリのメタデータ（と思う生成のタグ

私のシステムで提供する必要があります：

勧告として与えられたアイテムのようなエントリの

• 一覧なエントリの
• クラスタ

両方の計算が基づくべきである：

• エントリのメタデータ/属性（すなわち
• したがって、2つのエントリの距離が適切なメトリックを使用して、同様のタグの使用は）
• ユーザvotings、好みや協調フィルタリングとは異なり、アクション（）に基づいていません。ユーザーはエントリを作成し属性を変更することができますが、アイテムとその属性のみを考慮し、関連するユーザーは考慮しないでください（アイテムとユーザーが存在しないシステムと同様）。

理想的には、アルゴリズムがサポートする必要があります：エントリ

の属性の

• 永続的な変更は、増分変更
• 規模
• 簡単な距離よりももっと良いものに類似したエントリ/クラスタを計算しますテーブル、（なぜならO（n²）空間の複雑さの）可能であれば

Answer 1

最初から書き込むのではなく、mahout.apache.orgをご覧ください。それはあなたが探しているクラスタリングアルゴリズムと推薦アルゴリズムを持っています。それはHadoopと一緒に働くので、簡単にscale it outすることができます。これはあなたがすることができますどのような

は、キーワードおよび/またはビデオの説明に基づいて、クラスタ内の類似した文書を決定しています。

https://cwiki.apache.org/MAHOUT/k-means-clustering.html

Reutersデータセットを使用して文書のクラスタリングについての簡単なチュートリアルを持っています。あなたが達成しようとしているものに非常に似ています。 Mahoutには、スロープ1、ユーザベース、アイテムベースなどの推奨アルゴリズムが含まれており、非常に簡単に拡張できます。また、次元削減機能をサポートするかなり有用なクラスタリングアルゴリズムもあります。これは、あなたの行列が疎である（つまり、利用統計が非常に少ないタグがたくさんある）場合に便利です。

はまた、クラスタタグや文書にそのTFIDFの機能を使用するにはLuceneを見てみましょう。 Solrもチェックしてください。どちらもApacheプロジェクトです。

Answer 2

Recommendation Algorithmは、あなたの目的に対処するための標準的なアルゴリズムをリストしているので、非常に役に立ちます。

更新日：

私はあなたが紙にCollaborative Quality Filteringなく協調フィルタリングだけで、私は、添付したリンクで探しているものを推測するが、このことができます願っています。

Answer 3

K-means clusteringは、あなたが望むかもしれません。

N.B .:

は、クラスタkの数は、入力パラメータである：Kの不適切な選択は悪い結果をもたらすことができる...他人に悲惨に失敗しながら、これは、いくつかのデータセットに対して非常にうまく機能します。

クラスタの数、タグの数、メトリックを考慮する必要があります。

も オーバーフローquestions/tagged/k-meansスタックを参照してください。

Answer 4

実装を開始する前に、既存のライブラリを調整または使用する前に、ドメインを知っていることを確認してください。 "Collective Intelligence in Action"のようなものを読むのがよいスタートです。

Answer 5

ユーザベースではなくアイテムベースのコラボレーションフィルタが必要です。これにはGoogle上でさまざまなアルゴリズムがあります。アイテムベースのソリューションは、ユーザーベースのソリューションよりも常に拡張されます。Item based collaborative filtering in PHPいくつかのわかりやすいサンプルコードを持っており、あなたが探しているものフィット：

Answer 6

​​

味 Javaのための柔軟な、速い 協調フィルタリングエンジンです。エンジンはユーザーの「 」の設定（「味」）を受け取り、 は の他の項目の推定設定を返します。たとえば、 で書籍やCDを販売するサイトでは、簡単に を使用することができます。 の購入データから、 のCDを購入することができます。

味はあなたが アルゴリズムの選択からカスタマイズされたレコメン システムを構築することができ、そこから コンポーネントの豊富なセットを提供します。 味はエンタープライズ対応の になるように設計されています。それは の性能、スケーラビリティと の柔軟性のために設計されています。 J2EEベースの アプリケーション用のEJBインタフェースをサポートしていますが、TasteはJavaの場合は ではありません。外部の サーバとして実行して、 のロジックをWebサービスのサービスとHTTP経由でアプリケーションに公開することができます。現在

http://savannah.nongnu.org/projects/cofi/

、 協調フィルタリングを使用するプログラマは に文学を読み、自分の のアルゴリズムを実装する必要があります。ほとんどの場合、 プログラマはおそらく独自の アルゴリズムを設計し、一般的には は最適以下のアルゴリズムを生成します。 は、既に のテスト済みアルゴリズムの基礎を構築し、 が研究から までの コンテキストの広い範囲で使用できることを文書化したいと考えています。指導原則 は、デザインが薄くなければならないということです。 すべての人にCofiがすべてのものになりたいとは思わない だから、 のコード行数は非常に少なくて済み、 であり、プログラマーには に必要な接着剤を提供することが義務付けられています。

さらにいくつかhere

Answer 7

あなたは、類似度メトリックが、ご使用の製品とあなたの良識の仕様に基づいているかを決定する必要があります。ビデオの長さは重要ですか？もしそうなら、それは高い体重に値する。