You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Sean Owen <sr...@gmail.com> on 2011/11/15 12:38:39 UTC
Re: New feature idea: Eligible Items for recommendations
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>.
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
>>