You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Anatoliy Kats <a....@rambler-co.ru> on 2011/11/15 12:36:35 UTC

New feature idea: Eligible Items for recommendations

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 
EligibleSetCandidateItemStrategy 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

Re: New feature idea: Eligible Items for recommendations

Posted by Sean Owen <sr...@gmail.com>.
Yes that is the intended usage pattern for the evaluator.
On Nov 15, 2011 11:56 AM, "Anatoliy Kats" <a....@rambler-co.ru> wrote:

> 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....@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
>>>
>>>
>

Re: New feature idea: Eligible Items for recommendations

Posted by Anatoliy Kats <a....@rambler-co.ru>.
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....@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
>>


Re: New feature idea: Eligible Items for recommendations

Posted by Sean Owen <sr...@gmail.com>.
This is exactly what Rescorer is for in the recommend() method. Does that
suit?
On Nov 15, 2011 11:37 AM, "Anatoliy Kats" <a....@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
>