Why watch time resists a retrieval query
A typical recommendation system retrieves a few hundred candidates from a corpus of tens of millions, then ranks them against multiple objectives. Retrieval usually runs on a two-tower model: a user encoder and an item encoder are trained with a classification objective, item embeddings are computed in advance, and each request needs only a fresh user embedding plus a nearest neighbor search. To serve several objectives, systems often run several retrieval routes, each trained for a different target, and merge their candidates before ranking.
Continuous outcomes such as watch time break this pattern. Expected watch time depends on both the user and the specific video, but the user tower computes its representation before any candidate is selected. The paper also notes there is no single watch-time threshold that captures a good outcome across users and videos. That is why the ranking stage's watch-time objective is difficult to translate into a retrieval query.
Conditioning the user tower on watch time
CRM adds watch time as an input to the user tower. In the DNN-based version, the observed watch time of the next video, together with the user features, produces a conditioned user embedding, and training uses the same two-tower loss as before. The item tower and the retrieval procedure are unchanged.
The split between training and inference is the key design choice. During training the model learns to predict the next item given its observed watch time; at inference the desired watch time is supplied instead. The condition can therefore be changed without retraining, and because item embeddings do not depend on it, they can still be indexed for approximate nearest neighbor search.
A Decision Transformer with condition tokens
The second implementation borrows the Decision Transformer's sequence formulation. In offline reinforcement learning, that model interleaves return-to-go, state, and action tokens so it can predict actions for a specified reward target. CRM replaces the reward with watch time: the input alternates watch-time-to-go condition tokens with item tokens, ending with the condition for the next item, and a causal attention mask keeps the prediction causal.
During training the watch-time-to-go values are computed from observed watch times; at inference the final condition is set to the desired watch time for the next item, acting as a numerical prompt for next-item prediction. The paper states that the Transformer version is the one used in production.
Choosing average or maximum per request
At inference the target watch time comes from the user's recent history, either the average or the maximum over the last n videos. The average reflects recent viewing behavior, while the maximum sets a higher target to encourage longer viewing. The history length matters for both: a large window can make the maximum sensitive to an old outlier, while a small window may not represent viewing habits. Production uses n = 32.
The two conditions behaved differently online. The average condition increased video views and interaction metrics such as comments and likes, but brought little improvement in total watch time. The maximum condition increased watch time but tended to retrieve longer videos and could reduce video views and interactions. CRM therefore uses time-division multiplexing: each request takes the maximum condition with probability p and the average condition with probability 1 − p.
What the online A/B tests measured
CRM was deployed in Kuaishou's largest short-video recommendation scenario, which the paper describes as serving over 400 million users and generating 50 billion logs per day. The online A/B tests report video watch time improvements of 0.372% in Kuaishou and 0.457% in Kuaishou Lite. Total app usage time rose 0.175% and 0.196% respectively, with gains in usage time per user in both applications.
Video views, likes, follows, and comments also increased in both applications. In Kuaishou Lite, video views increased by 0.324% and follows by 0.828%. These are relative changes from online tests, not absolute watch-time values, and they describe the deployed system rather than a controlled offline benchmark.
Where the gains come from and where they stop
The paper's own explanation is that making the desired watch time an input to retrieval, while keeping precomputed item embeddings and ANN search, is what produces the online gains. That mechanism is implemented twice: as a watch-time feature in the DNN user tower and as condition tokens in the Transformer. The reported evidence covers watch time, total app usage time, video views, likes, follows, and comments in two Kuaishou applications.
The results do not establish that a single condition value works across users and videos; the paper explicitly says no such threshold exists, which is why the condition is chosen per request from recent history. The comparison between average and maximum also shows the trade-off is real: the condition that raised views and interactions was not the one that raised total watch time. Future work named in the paper is other outcome conditions and how to choose them for each request.
The serving choice that matters most
For practitioners, the decision-relevant result is not the conditioning mechanism alone but the per-request mix. Average watch time bought views and interactions with little total watch-time gain; maximum watch time bought watch time at the cost of views and interactions and a tendency toward longer videos. CRM's time-division multiplexing with probability p is the paper's answer to that split, and the reported 0.372% and 0.457% watch-time gains come from that combined serving strategy rather than from either condition used alone.
Sources used in this answer
CRM: Retrieval Model with Controllable Condition
Adding a desired watch time to the user tower lets retrieval be steered at inference without retraining, while item embeddings stay precomputed for ANN search; online A/B tests raised video watch time by 0.372% in Kuaishou and 0.457% in Kuaishou Lite.