Duh! Thanks:) I can't feed a rescorer to the evaluator, but I can work
around that: I am already creating my own recommender class by
subclassing the ItemBasedRecommender, so I can just overload the
recommend(..) to super.recommend(.., IDRescorer). It seems like a more
elegant solution than adding the rescorer to the evaluator.
On 11/15/2011 03:38 PM, Sean Owen wrote:
This is exactly what Rescorer is for in the recommend() method. Does that
suit?
On Nov 15, 2011 11:37 AM, "Anatoliy Kats"<a.k...@rambler-co.ru> wrote:
Hi all,
I have a use case for Taste where we should use all available items for
computation of user similarity, but only some items are eligible to be
recommended. The reason is that items expire: goods get discontinued, for
example. The fact that a user bought something now discontinued is
important for finding similar users, but we cannot recommend it. One way
of solving this is using mahout to generate recommendations, and then
post-process it to remove ineligible items. But this can run into
performance issues if the set of ineligible items is large. Also, the
evaluation framework is not designed to handle this kind of a restriction.
I can contribute a patch, but since I am new to the project, I need some
help with the software engineering from the regular contributors. How
would I design the necessary classes? One idea I considered was using the
existing tools for candidate item strategy. This has two downsides: you
can only use one candidate item strategy at a time, so having an eligible
set would make it impossible to have a candidate item strategy. Also, the
evaluator doesn't take the candidate item strategy into account. So, I
suppose I could try writing an EligibleSetCandidateItemStrate**gy that
takes another CandidateItemStrategy and applies it as well, and I can add a
new evaluator that takes eligible sets into account. I don't know the
thinking behind the design, so I don't know if this is a good idea or not.
Can we agree on a design before I get started?
Cheers,
Anatoliy
