was talking with Ken Krugler off list about the Mahout + Solr
recommender and he had an interesting request.
When calculating the indicator/item similarity matrix using
ItemSimilarityJob there is a --threshold option. Wouldn’t it be
better to
have an option that specified
more useful than
—threshold as it is today but maybe I’m missing some use cases? Is there
really a need for a hard score threshold?
On Tue, May 27, 2014 at 8:08 AM, Pat Ferrel pat.fer...@gmail.com
wrote:
I was talking with Ken Krugler off list about the Mahout + Solr
recommender and he
? Is there
really a need for a hard score threshold?
On Tue, May 27, 2014 at 8:08 AM, Pat Ferrel pat.fer...@gmail.com
wrote:
I was talking with Ken Krugler off list about the Mahout + Solr
recommender and he had an interesting request.
When calculating the indicator/item similarity matrix using
some use cases? Is there really a need for a hard
score threshold?
On Tue, May 27, 2014 at 8:08 AM, Pat Ferrel pat.fer...@gmail.com wrote:
I was talking with Ken Krugler off list about the Mahout + Solr
recommender and he had an interesting request.
When calculating the indicator
I was talking with Ken Krugler off list about the Mahout + Solr recommender and
he had an interesting request.
When calculating the indicator/item similarity matrix using ItemSimilarityJob
there is a --threshold option. Wouldn’t it be better to have an option that
specified the fraction
are pretty consistent across different uses (50-100 are reasonable values
for most needs larger values are quite plausible).
On Tue, May 27, 2014 at 8:08 AM, Pat Ferrel pat.fer...@gmail.com wrote:
I was talking with Ken Krugler off list about the Mahout + Solr
recommender and he had
threshold?
On Tue, May 27, 2014 at 8:08 AM, Pat Ferrel pat.fer...@gmail.com wrote:
I was talking with Ken Krugler off list about the Mahout + Solr
recommender and he had an interesting request.
When calculating the indicator/item similarity matrix using
ItemSimilarityJob
about the Mahout + Solr
recommender and he had an interesting request.
When calculating the indicator/item similarity matrix using
ItemSimilarityJob there is a --threshold option. Wouldn’t it be better to
have an option that specified the fraction of values kept in the entire
matrix based
Begin forwarded message:
From: Pat Ferrel pat.fer...@gmail.com
Subject: Re: Solr recommender
Date: April 26, 2014 at 9:07:57 AM PDT
To: d...@mahout.apache.org
Yes, it already does. It’s not named well, all it really does is create an
indicator matrix (item-item similarity using LLR) in a form
it brings.
On Apr 26, 2014, at 8:25 AM, Saikat Kanjilal sxk1...@hotmail.com wrote:
Pat,
I was wondering if you'd given any thought to genericizing the Solr
recommender to work with both Solr and elasticsearch, namely are there
pieces of the recommender that could plug into or be lifted above
flexibility and convenience it brings.
On Apr 26, 2014, at 8:25 AM, Saikat Kanjilal sxk1...@hotmail.com wrote:
Pat,
I was wondering if you'd given any thought to genericizing the Solr
recommender to work with both Solr and elasticsearch, namely are there
pieces of the recommender that could
sxk1...@hotmail.com wrote:
Pat,
I was wondering if you'd given any thought to genericizing the Solr
recommender to work with both Solr and elasticsearch, namely are there
pieces of the recommender that could plug into or be lifted above a search
engine ( or in the case of elasticsearch
:
Pat,
I was wondering if you'd given any thought to genericizing the Solr
recommender to work with both Solr and elasticsearch, namely are there
pieces of the recommender that could plug into or be lifted above a search
engine ( or in the case of elasticsearch a set of rest APIs). I would
of the text files just
for the amazing flexibility and convenience it brings.
On Apr 26, 2014, at 8:25 AM, Saikat Kanjilal sxk1...@hotmail.com wrote:
Pat,
I was wondering if you'd given any thought to genericizing the Solr
recommender to work with both Solr and elasticsearch, namely
@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are
sorted by Mahout strength so the first id is the most similar to the row
key and so forth. But the query is ordered buy recency. In both cases the
first id is in some
Eventually I’d like to get MAP built into the solr-recommender. Used it at a
client who had good data. It was very helpful for exploring what data was
useful and what wasn’t. We’d run map with and without detail-view data for
instance and take the MAP as a measure of how predictive the data
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are
sorted by Mahout strength so the first id is the most similar to the row
key and so forth. But the query is ordered buy recency. In both cases the
first id is in some sense
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Thursday, November 07, 2013 1:46 PM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are
sorted by Mahout strength
Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Thursday, November 07, 2013 1:46 PM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are sorted
by Mahout strength so the first id is the most
Group
(615) 213-4311
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Thursday, November 07, 2013 1:46 PM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids
, November 07, 2013 1:46 PM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are
sorted by Mahout strength so the first id is the most similar to the row
key and so forth. But the query is ordered buy recency
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are sorted
by Mahout strength so the first id is the most similar to the row key and so
forth. But the query is ordered buy recency. In both cases the first id is in
some sense
position+100, etc.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Thursday, November 07, 2013 1:46 PM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Wednesday, November 06, 2013 5:53 PM
To: s...@apache.org Schelter; user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Done,
BTW I have the thing running on a demo site but am getting very poor results
that I
(615) 213-4311
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Wednesday, November 06, 2013 5:53 PM
To: s...@apache.org Schelter; user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Done,
BTW I have the thing running on a demo site but am getting
.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Wednesday, November 06, 2013 5:53 PM
To: s...@apache.org Schelter; user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Done,
BTW I have
: Solr-recommender for Mahout 0.9
Done,
BTW I have the thing running on a demo site but am getting very poor results
that I think are related to the Solr setup. I'd appreciate any ideas.
The sample data has 27,000 items and something like 4000 users. The
preference data is fairly dense
]
Sent: Wednesday, November 06, 2013 5:53 PM
To: s...@apache.org Schelter; user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Done,
BTW I have the thing running on a demo site but am getting very poor
results that I think are related to the Solr setup. I'd appreciate any
ideas
.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Wednesday, November 06, 2013 5:53 PM
To: s...@apache.org Schelter; user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Done,
BTW I have
fields,
which is convienent when writing a UI.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Dominik Hübner [mailto:cont...@dhuebner.com]
Sent: Thursday, November 07, 2013 11:23 AM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Does
[mailto:pat.fer...@gmail.com]
Sent: Thursday, November 07, 2013 1:46 PM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are sorted
by Mahout strength so the first id is the most similar to the row key and so
forth
(615) 213-4311
-Original Message-
From: Pat Ferrel [mailto:pat.fer...@gmail.com]
Sent: Thursday, November 07, 2013 1:46 PM
To: user@mahout.apache.org
Subject: Re: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are sorted
by Mahout
: Solr-recommender for Mahout 0.9
Interesting to think about ordering and adjacentness. The index ids are
sorted by Mahout strength so the first id is the most similar to the row key
and so forth. But the query is ordered buy recency. In both cases the first
id is in some sense the most
the project and rely on
the default implementations in Mahout 0.9. #3 is a longer term issue related to
the creation of a CrossRowSimilarityJob.
I have dropped the modified code from the Solr-recommender project and have a
modified build of the current Mahout 0.9 snapshot. If the following changes
.
I have dropped the modified code from the Solr-recommender project and have a
modified build of the current Mahout 0.9 snapshot. If the following changes
are made to Mahout I can test and release a Mahout 0.9 version of the
Solr-recommender.
1. Option to change RecommenderJob output
of the preparePreferenceMatrix directory. If
#1 and #2 are addressed I can remove the modified Mahout code from the
project and rely on the default implementations in Mahout 0.9. #3 is a longer
term issue related to the creation of a CrossRowSimilarityJob.
I have dropped the modified code from the Solr-recommender
://github.com/pferrel/solr-recommender
Am 25.10.2013 um 01:55 schrieb Dominik Hübner:
Having seen Ted presenting recommendation as search at the Munich Hadoop
meetup, I remembered the new Solr recommender implemented by Pat. Are there
any chances to contribute? I currently have same spare
tests,
if not then using them is better than a random choice. Take this result with a
grain of salt though and get ready to A/B test later challengers when or if you
have time.
In the case of the Solr recommender it is extremely flexible and online
(realtime results). These features for me
obvious. For the demo site the
recommender API will be prototyped in a bunch of ways using models and
controllers in Rails. If I'm the one to do the a Java Solr-recommender query
API it will be after experimenting a bit.
Can someone introduce me to Ellen and Tim?
On Sep 28, 2013, at 10:59 AM, Ted
the a Java Solr-recommender query API it will be after experimenting a bit.
Can someone introduce me to Ellen and Tim?
On Sep 28, 2013, at 10:59 AM, Ted Dunning ted.dunn...@gmail.com wrote:
The one large-ish feature that I think would find general use would be a
high performance classifier
the output of the Solr-recommender where Solr
can index it. Our web app framework then allows very flexible queries against
Solr, using simple user history, producing the typical user-history based
recommendations, or mixing/boosting based on metadata or contextual data. If we
leave the recommender
not at the moment considering user-user similarity measures.
You bring up a point that we're finding. I'm not so sure we need or want a
recommender query API that is separate from the Solr query API. What we are
doing on our demo site is putting the output of the Solr-recommender where Solr
can index
is putting the output of the Solr-recommender where
Solr can index it. Our web app framework then allows very flexible queries
against Solr, using simple user history, producing the typical user-history
based recommendations, or mixing/boosting based on metadata or contextual
data. If we leave
On Wed, Oct 9, 2013 at 12:54 PM, Michael Sokolov
msoko...@safaribooksonline.com wrote:
On 10/9/13 3:08 PM, Pat Ferrel wrote:
Solr uses cosine similarity for it's queries. The implementation on
github uses Mahout LLR for calculating the item-item similarity matrix but
when you do the
On Wed, Oct 9, 2013 at 2:07 PM, Pat Ferrel p...@occamsmachete.com wrote:
2) What you are doing is something else that I was calling a shopping-cart
recommender. You are using the item-set in the current cart and finding
similar, what, items? A different way to tackle this is to store all other
On Wed, Oct 9, 2013 at 12:54 PM, Michael Sokolov
msoko...@safaribooksonline.com wrote:
It sounds like you are doing item-item similarities for recommendations,
not actually calculating user-history based recs, is that true?
Yes that's true so far. Our recommender system has the ability to
API is not so obvious. For the demo site the
recommender API will be prototyped in a bunch of ways using models and
controllers in Rails. If I'm the one to do the a Java Solr-recommender query
API it will be after experimenting a bit.
Can someone introduce me to Ellen and Tim?
On Sep 28, 2013
. Combining that allows you to recommend for people who have
only
one kind of behavior. Of course, our viewing behavior will be very
sparse
to start.
Yes, that's why I'm not convinced it will be useful but an interesting
experiment now that we have the online Solr recommender. Soon we'll
On Fri, Sep 6, 2013 at 9:33 AM, Pat Ferrel pat.fer...@gmail.com wrote:
One of the unique things about the Solr recommender is online recs. Two
scenarios come to mind:
1) ask the user to pick from among a list of videos, taking the picks as
preferences and making recs. Make more and see
On Sep 7, 2013, at 10:36 AM, Ted Dunning ted.dunn...@gmail.com wrote:
On Fri, Sep 6, 2013 at 9:33 AM, Pat Ferrel pat.fer...@gmail.com wrote:
One of the unique things about the Solr recommender is online recs. Two
scenarios come to mind:
1) ask the user to pick from among a list
viewing behavior will be very
sparse
to start.
Yes, that's why I'm not convinced it will be useful but an interesting
experiment now that we have the online Solr recommender. Soon we'll have
category and description metadata from the crawler. We can experiment with
things like category boosting
Been building the scaffold for demonstrating the Solr + Mahout recommenders.
Have mined rotten tomatoes for reviews and movies. Browsing, simple search, and
item-item similarities are working in the UX.
One of the unique things about the Solr recommender is online recs. Two
scenarios come
the Solr recommender is online recs. Two
scenarios come to mind:
1) ask the user to pick from among a list of videos, taking the picks as
preferences and making recs. Make more and see if recs improve.
2) watch the users' detail views during a browsing session and make recs
based on those
A good way to find differing clumps of opinion based on user ids. Probably also
want to consider number of reviews or we may get too many semi-obscure
un-ratable videos. I wonder if filtering by some popularity percentile before
clustering would solve that problem?
On Sep 6, 2013, at 10:33
) on project solr-recommender: Compilation failure:
Compilation failure:
[ERROR]
/Users/bradflyon/Documents/solr-recommender/src/main/java/finderbots/recommenders/hadoop/PrepareActionMatrixesJob.java:[120,71]
cannot find symbol
[ERROR] symbol : variable SAMPLE_SIZE
[ERROR] location: class
I've got something else misconfigured somehow, although I don't
see how it would compile if it's looking for that static field that's removed.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile)
on project solr-recommender: Compilation
I've got something else misconfigured somehow,
although I don't see how it would compile if it's looking for that static
field that's removed.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
(default-compile) on project solr-recommender
to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
(default-compile) on project solr-recommender: Compilation failure:
Compilation failure:
[ERROR]
/Users/bradflyon/Documents/solr-recommender/src/main/java/finderbots/recommenders/hadoop
don't see how it would compile if it's looking for that static
field that's removed.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
(default-compile) on project solr-recommender: Compilation failure:
Compilation failure:
[ERROR]
/Users/bradflyon
-compile) on project solr-recommender: Compilation failure:
Compilation failure:
[ERROR]
/Users/bradflyon/Documents/solr-recommender/src/main/java/finderbots/recommenders/hadoop/PrepareActionMatrixesJob.java:[120,71]
cannot find symbol
[ERROR] symbol : variable SAMPLE_SIZE
[ERROR] location
I don't
see how it would compile if it's looking for that static field that's removed.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile)
on project solr-recommender: Compilation failure: Compilation failure:
[ERROR]
/Users/bradflyon
(default-compile) on project solr-recommender: Compilation failure:
Compilation failure:
[ERROR]
/Users/bradflyon/Documents/solr-recommender/src/main/java/finderbots/recommenders/hadoop/PrepareActionMatrixesJob.java:[120,71]
cannot find symbol
[ERROR] symbol : variable SAMPLE_SIZE
) With Solr TFIDF is used I believe so items that are very popular will be
down-weighted as a side effect rather than downsampled. This is probably a good
thing.
6) The Solr recommender will downsample the training data using Mahout
preferences per user limit. It can truncate the query vector
On Sun, Aug 4, 2013 at 9:35 AM, Pat Ferrel pat.fer...@gmail.com wrote:
2) This is not ideal way to downsample if I understand the code. It keeps
the first items ingested which has nothing to do with their timestamp.
You'd ideally want to truncate based on the order the actions were taken by
It does bring up a nice way to order the items in the A and B docs, by
timestamp if available. That way when you get an h_b doc from B for the query:
recommend based on behavior with regard to B items and actions h_b
query is [b-b-links: h_b]
the h_b items are ordered by recency. You can
+1 on vector properties
On Aug 4, 2013, at 5:34 PM, Pat Ferrel p...@occamsmachete.com wrote:
It does bring up a nice way to order the items in the A and B docs, by
timestamp if available. That way when you get an h_b doc from B for the query:
recommend based on behavior with regard to B
On Sun, Aug 4, 2013 at 5:34 PM, Pat Ferrel p...@occamsmachete.com wrote:
Actually this brings up another point that I've harped on before. It sure
would be nice to have a vector representation where you could attache
arbitrary data to items or vectors. Not so memory efficient but it makes
Just updated to today's Mahout trunk and everything works for me.
Can you send me the error?
Sebastian, do we really want this limit in RowSimilairty? It will not be
applied to [B'A] unless you also do a mod to give us RowSimilairty on two
matrices. Now that would be very nice indeed…
On Aug
On Aug 4, 2013, at 5:54 PM, Ted Dunning ted.dunn...@gmail.com wrote:
On Sun, Aug 4, 2013 at 5:34 PM, Pat Ferrel p...@occamsmachete.com wrote:
Actually this brings up another point that I've harped on before. It sure
would be nice to have a vector representation where you could attache
69 matches
Mail list logo
