Thank you for the response. Would this pattern be appropriate for something like ML inference if I’m looking for sub 200ms response time and the results objects are small? The polling interval would need to be very short, and would that become an issue?
Apologies for the noob question but how would FastAPI/Flask know that the job has been successfully completed? Would the worker have to persist ml inference results somewhere and the FastAPI server poll it periodically?
How are they going to address the problem of connection creep? (Over time the number of people you add to your friends network increase and cause context collapse)
“ Piki selects music from a database of roughly 5 million songs and incentivizes users by giving them $1 for every 25 songs they rate. The Piki interface plays a song, and then gives the listener the ability to rate it after different amounts of time. Specifically, the user can “dislike” the song after 3 seconds, “like” the song after 6 seconds and “superlike” it after 12 seconds.”
These people are training on a completely different set of features than what Spotify is using. For example, listen time is likely to be a important feature where a short time or a skip will be a pretty good proxy for a dislike.
In other words, the authors conclusions are conditioned on only using the features outlined in the article, like, dislike, and super like. And I’m not sure it will generalize for Spotify.
Cuz when u have as much market power as Apple, you don’t really have a choice in granting someone market access to your platform. A refusal is potential grounds for a antitrust case. Assuming ofcourse, epic stays within the lines of apple’s other rules which hasn’t been challenged in court.
Last time this was discussed here one of news reports mentioned internally executives pushed for this style of report to be released so they can massage the metrics how ever they like and own the narrative.