0

Amazonの「これを購入したお客様はこちらも購入済み」のような機能を構築しています。私はこのデータをマイニングするために約 6 年間の注文を受けており、明らかに新しい注文からのデータで更新を続けています。

いくつかの質問が思い浮かびます:

  1. これらの関係を保存するにはどうすればよいですか? 私は、productA、productB、およびカウント (またはランク) を含む単純なテーブルを考えています。これで十分ですか？
  2. 古いデータが新しいデータほど関連性があるとは思いません。新しいデータに優先順位を付けるにはどうすればよいですか?

編集: このサイトは 1 種類の商品しか販売していないため、ほとんどすべての商品に関連性があり、フィルタリングする必要はありません。また、これをできるだけ単純にしたいと思います。データはすでにデータベースにあるので、計算して保存する最も簡単な方法を探しています。

4

4 に答える 4

1

タスクにはeasyrecを使用できます。リレーションは次の形式で保存されます。

CREATE TABLE `itemassoc` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `tenantId` int(11) NOT NULL DEFAULT '0',
  `itemFromId` int(11) NOT NULL DEFAULT '0',
  `itemFromTypeId` int(11) unsigned NOT NULL DEFAULT '0',
  `assocTypeId` int(11) unsigned NOT NULL DEFAULT '0',
  `assocValue` double NOT NULL DEFAULT '0',
  `itemToId` int(11) NOT NULL DEFAULT '0',
  `itemToTypeId` int(11) unsigned NOT NULL DEFAULT '0',
  `sourceTypeId` int(11) NOT NULL DEFAULT '0',
  `sourceInfo` varchar(250) DEFAULT '0',
  `viewTypeId` int(11) unsigned NOT NULL DEFAULT '0',
  `active` tinyint(1) NOT NULL DEFAULT '1',
  `changeDate` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique_itemassoc` (`tenantId`,`itemFromId`,`itemFromTypeId`,`itemToId`,`itemToTypeId`,`assocTypeId`,`sourceTypeId`),
  KEY `idFrom_assoc` (`itemFromId`,`itemFromTypeId`,`assocTypeId`,`tenantId`),
  KEY `recommender` (`itemFromId`,`itemFromTypeId`,`itemToTypeId`,`assocTypeId`,`tenantId`,`active`)
) ENGINE=InnoDB AUTO_INCREMENT=38480 DEFAULT CHARSET=latin1 COMMENT='Table containing item associations'

基本的には

  1. イテマ
  2. ASSOCTYPE (例: BOUGHT_TOGETHER)
  3. アイテム
  4. ASSOC VALUE（推奨の強さ）

easyrecは、「BUY ACTIONS」をインポートして、そこからルールを計算できます。

于 2011-10-12T12:34:36.027 に答える
0

個人的には、このデータを保存しません。提案する製品を動的に選択するビューを作成します。

簡単な実装の 1 つとして、次のようなものがあります。

  1. 同じ商品を購入した人の代表的な人数を選択してください (EG 1000)
  2. それらのユーザーに基づいて、彼ら全員が購入した上位 N 個の製品は何ですか。
  3. それらの製品をユーザーに提案します。

ステップ 2 を省略して、人気に関係なく購入された他の製品のみを表示することで、単純化できます。

サイモン マークが提案しているように、商品を基準でフィルタリングすることで、これをより洗練させることができます。

古いデータに関しては、アイテムに使用期限日または冗長フラグが設定されている可能性があります。これは、アイテムが選択から除外されることを意味します。

于 2011-01-16T19:59:20.630 に答える
0

http://taste.sourceforge.net/を見てください

Taste は、Java 用の柔軟で高速な協調フィルタリング エンジンです。このエンジンは、アイテムに対するユーザーの好み (「味」) を取得し、他のアイテムについて推定された好みを返します。たとえば、本や CD を販売するサイトでは、Taste を使用して過去の購入データから、顧客がどの CD に関心を持っているかを簡単に把握できます。

Google には、ユースケースに合わせて調整できる予測 API もあります。ここで彼らのシナリオをチェックしてください

于 2011-01-14T05:00:06.467 に答える
0

「これらの関係をどのように保存すればよいでしょうか? 私は、productA、productB、およびカウント (またはランク) を含む単純なテーブルを考えています。これで十分ですか?」

これでは十分ではありません。最良の方法は、オブジェクトのセマンティックを使用することです

したがって、オブジェクトに関連するデータを取得し (本の場合: xxx によって書かれた本であるという事実、文体、本の種類など)、別のオブジェクトに移動する他のデータとの関係を確認します (この種類の本はこの種類に関連付けられているか、このアーティストはこのアーティストに関連付けられているか、またはその両方です...)。それは本当に大変な作業です。

自分で行うことを選択できますが、必要なほど関連性がない場合があります。

すでに存在するもの (たとえば、sourceforge や github など) を確認する必要があると思います。

于 2011-01-14T05:10:04.897 に答える