3 ms·
The way TFA puts the matter, this looks like an Information Retrieval problem. That is, the author is looking for a data stream that can be used to inform sear
by saidajigumi 13y ago
The way TFA puts the matter, this looks like an Information Retrieval problem. That is, the author is looking for a data stream that can be used to inform search relevance. One might imagine collecting other active or passive metrics (e.g. "click through from thumbnail", "time on page", "times shared") to inform relevance as well.
Another question I'd pose: what's the real goal of a "like" in the various contexts it is used? In many Facebook applications (e.g. liking a photo, comment, etc.), it appears to be as much about filling in missing social cueing -- a one-bit emoticon, if you will -- than about informing relevance. In other contexts on Facebook, there's a definite notion of relevance (e.g. liking a page).
Given that, I suppose I must ask: how much additional value can really be added to this single low-information stream vs. simply using additional active or passive metrics to inform relevance? Is "like dilution" really such a big problem? If it is, there are other approaches to consider.
Instead of creating artificial scarcity it may be worth using another IR technique and inverse-weight a signal based on dilution criteria. I.e. if one user expends LOTS of "likes", they effectively place a lower value on each of those. If another user uses "likes" very infrequently, we can infer those carry more weight. A straw-man example: turning the proposed technique on its head, the summed value of a user's likes might be capped at 10 points each [week, etc.], with no limit on the number of likes. The value of any like within that window is 10/[number of likes this week]. Users can click the "recommend/like/etc" button as many times as they want, and the system will dutifully record and interpret that data according to the site's needs.
- robotmay 13y agoGreat feedback, thanks! Your last paragraph is something I've been considering as a next evolution of how it's implemented, but I'm waiting for more data (and time!) before I take a look at developing it further :)