On Tue, Sep 8, 2009 at 10:11 PM, Ted Dunning<ted.dunning@gmail.com> wrote:
> In this case, the interaction matrix A is turned into a recommendation
> matrix using matrix multiplication: A' A. To implement recommendation given
> a user history u, we recommend the items that have the largest values in (A'
> A) u.
One initial comment I'd make is that it's not generally true that you
want to compute all recs at once, which is the direction you're going?
I think reducing it to a matrix multiplication problem is tidy, and
works I am sure. I don't know if, practically, it affords the tweaks
and hooks and modifications that let some of these stock algos
actually produce good results. It can probably be made to work too.
My gut is that it is not the most efficient way to do it  if only
because it definitely is not efficient to compute this to produce
*one* set of recs, or, to answer many of the questions one asks of a
recommender, which is not just to produce recs.
And yeah my world view is not centered around big offline
computations. In that world, yes I bet this is a good way to compute
all recommendations at once. I still maintain that interesting use
cases involve roughly realtime updates and recommendations.
I must disclaim that I simply don't understand this approach enough,
and haven't tried it at all, so have not much basis for reasoning
about it.
But, rest assured that even if the implications for this issue in your
picture of how this might be implemented implies that someone didn't
really think through data structures, I don't think it carries the
same implication for how it's implemented now. I do think the current
implementation is roughly right for the questions that need to be
answered. This is really a case of 'cheating' by relaxing an
assumption to gain performance  but one that is obviously worth it
 rather than fixing a fundamental flaw of some sort.
