The news rec queue is kind

[hayj]

After the first demo we will implement a kind news rec queue. No hard time constraint. Moreover the rec list can be updated to enhance recommendations.

For a particular user, a recsys can pre-send a list of recommendations before it receives a "rec request". Because it know which user is assigned to it. Or it can send the list of recommendations directly when it receive the "rec request". We don't care on our side. It means the recsys can update periodically a rec list so it can be more accurate with time (because algorithm can enhance their user model iteratively... don't know). Or it can pre-send because the developer know the recsys cannot answer the request in less than 10 sec... The Renewal backend will just take the most recent rec list.

When the backend send a "rec request", it will wait x seconds (like 2 or 1). Why? Because we wait for a more recent list of recommendations if a list already exists. Or we wait for a rec list if no one exists. After x seconds the backend replace the system with a baseline randomly choosed.

The user will not wait so much because we will preload recommendations before he reaches the end of his rec list when he scroll down... If he refresh up, we'll see... maybe a smart heuristic...

[embray]

I always thought this would make more sense to do in the first place. It would likely be much more efficient if recommendation systems are constantly generating new recommendations for users, rather than on-demand with each request. But you told me at one point it should be on-demand.

When the backend send a "rec request", it will wait x seconds (like 2 or 1). Why? Because we wait for a more recent list of recommendations if a list already exists. Or we wait for a rec list if no one exists. After x seconds the backend replace the system with a baseline randomly choosed.

This already needs to be part of the design. The API service will need to have a timeout on requests it sends to recommendation systems before responding to the user.

[hayj]

Hum yes it was not clear in requirements that it can be on-demand or async (researcher teams can choose the way they implement their recsys...). But this mechanism is very important to release constraint in Renewal contest for some reasons... So you say we need to implement this mechanism now and not to stay on a only on-demand mechanism? I agree, it shouldn't be so complicated to implement because we just need to erase old "rec lists" in the queue and wait 2 seconds before picking a "rec list"... Then proceeding to a merge and calling baselines if needed...

[embray]

In terms of "on-demand", recsystems are also of course free to do any amount of background number crunching they wish, and pre-prepare recommendations for users. So when the backend requests recommendations from it, it is up to the recsystem to create recommendations on-the-fly, or return pre-computed recommendations. From the perspective of the backend it is the same interface either way, so leaving this up to the recsystem is probably the best approach. At most, perhaps there should be a well-documented time limit for recsystems to respond to the requests (in fact, the request can even include the time limit in its payload, e.g. if we want to experiment with giving different time limits for requests).

[hayj]

it is up to the recsystem to create recommendations on-the-fly, or return pre-computed recommendations

Yes but keeping pre-computed list on our side can be a way to be robust to recsys crashes. And also, by keeping pre-computed lists on our side in a queue, it is more easy to implement for students for example, because they can just push rec list in a while true loop. But actually I agree you can let recsys handle it for now.

At most, perhaps there should be a well-documented time limit for recsystems to respond to the requests (in fact, the request can even include the time limit in its payload, e.g. if we want to experiment with giving different time limits for requests).

Yes good idea! But let's implement a basic mecanism with a 2-seconds limit and an on-demand mechanism as you said. So actually if the "News rec" queue is only "on-demand", we won't need queues anymore but only "rec requests" and direct responses...