Sequential recommenders predict the next item from a user's time-ordered history; the usual approach stacks the same number of encoding layers for every historical behavior. Diagnosing a trained three-layer SASRec, the authors find 76.1% of behaviors already converge after one layer of representation, while 6.7% need all three layers to stabilize—and both kinds often sit in the same sequence. A uniform depth wastes compute on already-converged behaviors and still under-computes the few hard ones. LoopRec lets each historical behavior choose how many layers to stack; depth is allocated per behavior, not per request. The core change is turning “how many layers” from a global hyperparameter into a property of each historical behavior: hard behaviors can take more rounds, already-converged ones stop early.
The structure has three steps. First run the whole history through a shared encoding block—one Transformer block with reused parameters; then at each recursion boundary a gate (a light network that reads the current state and outputs an exit probability; the paper also calls it a router) decides per position whether to exit or continue, and only continuing positions run the same block again; finally read out the representation at each position's chosen depth and predict the next item. The only supervision is next-item cross-entropy; training also adds two gate regularizers and a warmup. On three Amazon datasets and four backbone families, with a SASRec backbone on Amazon Software, NDCG@20 rises 5.68% relatively.
1. Motivation: why should every behavior pay the same depth
Almost every sequential encoder—attention, convolution, or linear recurrence—gives every historical behavior the same number of layers. Something casually opened three months ago and something repeatedly viewed yesterday cost the same compute.
Before proposing a method the authors run two diagnoses. The opening numbers come from the first: in SASRec (a classic self-attention sequential recommender), stop updating one position at a time and take the shallowest layer after which the recommendation set no longer changes as that position's saturation depth. Shallow- and deep-saturating positions mix in the same sequence, so no fixed depth covers all of them.
The second is more direct: only vary the depth of the latest five behaviors and let an offline searcher that sees the true target pick the best depth assignment. That searcher sees the answer and is only an analysis tool—the online router never sees the future target. It asks: if each behavior's depth can be chosen separately, can metrics beat a uniform depth? Yes—and the searcher's assignments often use less total compute. These two diagnoses are more persuasive than the method itself because they show, before any new model, that per-behavior depth allocation has real headroom.
2. Method: one block reused, ask each round whether to continue
Why share parameters? If every layer had different parameters, positions that exit at layer 2 and layer 4 would live in different representation spaces and could not be scored together. LoopRec's answer is one encoding block, called repeatedly, so no matter which round a position exits, the representation comes from the same parameters. The paper writes structures as LxRy: is layers in the shared block, is max recursions—e.g. L2R3 is a two-layer block used up to three times.
Shared-block recursion is a looped Transformer; Universal Transformer already combined shared recursion with per-position halting, and MoR (Mixture-of-Recursions) does token-level recursive depth on LMs. The decision style differs: MoR either assigns each token a total depth up front or picks a fixed-capacity top-k to continue each step; LoopRec re-judges every round from the current context with a binary stop/continue and needs no top-k. For recommendation, per-round binary decisions fit better than fixed capacity because user sequences vary a lot in length and information density, and a fixed top-k capacity is hard to set.
Concretely, an initial pass encodes the full history once. At each recursion boundary the gate reads each active position's current state and recursion index and outputs a scalar, turned by sigmoid into an exit probability:
is history position, current recursion depth, that position's state, a depth encoding, a light gate network, sigmoid. Above a threshold the position stops; otherwise it continues. Judging after every position has absorbed one round of context is more reasonable than fixing depth up front, because each position's state already carries full-sequence information.
Only continuing positions form the next input, keeping relative order under a causal mask so each position sees only earlier behaviors. Stopped positions freeze their state. At max recursion, remaining positions are forced to stop.
Implementation has an easy-to-miss pitfall. The next round only processes continuing positions, so both length and content of the sequence change; active-position indices and order must be maintained carefully, or the same request yields different results across batches. How well dynamic position compression is done also decides whether speed gains materialize.
Readout combines each position's input vector with the state at its chosen depth. Forward uses hard depth; depth-related weights still backprop through routing probabilities, so the gate learns directly from the recommendation objective with no depth labels. The shared block keeps parameter count from growing with depth; depth-aware readout links the stop decision to the final prediction.
The biggest training hazard is routing collapse: if every position exits in the same round, the model degenerates to fixed depth. A depth-usage regularizer combines the hard-routing share with soft probability mass to keep depths from bunching.
Another regularizer stops the gate from emitting extreme scores too early. Once probabilities saturate early, stop choices freeze and immature early states lock the training trajectory. The authors borrow MoE's router z-loss to penalize a large log-partition of the binary gate.
The full objective:
is next-item cross-entropy, the depth-usage regularizer, the gate stabilizer; and scale the two regularizers. The last two only constrain routing; item-prediction supervision is still only the target item.
There is also a warmup: during warmup every valid position runs to max depth with routing regularizers off, so the shared trunk learns usable states before the gate turns on. Ablating warmup drops all three datasets, most on Software, so it is not optional. The knobs to watch are shared-block depth, max recursions, and warmup length—they jointly decide whether training works and how large the compute budget is.
A walk-through of one request (illustration). The user recently saw A, B, C, D, E; the candidate is F. Initial encoding lets all five exchange context. The first gate exits A and B; C, D, E continue; next round C exits; D and E run to the budget. The model reads out at each chosen state and scores F. Exit trajectories and letters are examples; online the router never uses the true next item.
3. Core contribution: how compute is allocated is part of modeling
Past sequential-model gains usually lengthen or deepen the whole sequence uniformly. This paper lets the model learn from data which behaviors need more stacked layers, and decides round by round from updated context—more flexible than assigning depth once.
Learned patterns also make sense. Newer behaviors and colder items are more often assigned deep layers. Cold items have weak statistics, so their representations need more stacked rounds to converge; recent behaviors are closer to current intent, so spending more compute is reasonable. Heuristics by position or frequency underperform learned routing on average—so rules cannot simply replace learning.
A Seq-level Loop control shares recursion but loops the whole sequence together with no per-position exit. Pure shared recursion already captures part of the gain; per-position depth adds more on top, by how much depending on the dataset. This ablation separates the contributions of parameter reuse and compute allocation—the experiment that matters most for interpreting the method.
Sharing the trunk also makes the method backbone-agnostic; the paper tests convolutional and linear-recurrent models too. They aggregate sequences differently but can all reuse an encoding block and let a gate decide which positions continue.
4. Results: quality and latency must be read separately
Experiments use Amazon Reviews 2023 Software, Office Products, and Patio. Each user's last interaction is the test; validation NDCG@20 selects models. NDCG is rank-discounted quality; MRR is the mean reciprocal rank of the true target. Main tables report five-run means.
NextItNet is a causal-convolution sequential model; LRURec is linear-recurrent; the four main backbones also include BSARec (SASRec plus a frequency-domain bias). Relative gains use the authors' reported values because absolute table metrics keep only four decimals.
Office Products gains are small. The fair reading: under matched fixed-depth controls, all four backbone families improve, with large amplitude differences.
Speed needs a clear scope. Tests are on one A6000 GPU for the encoder only, without full-candidate scoring. L2R4 versus a fixed model at the same max depth cuts encode time from 91.230 ms to 79.273 ms; L2R2 barely changes even when executed compute already fell.
Deeper structures leave more room for early exit; but dynamic branching, index maintenance, and many small matmuls eat part of the gain. The authors acknowledge that only part of the skipped compute becomes wall-clock time. To judge online value, put encoding and candidate scoring into a full request together.
5. Limitations: speed gains depend on the runtime
Speed is only single-GPU encoder time; improvement amplitude varies a lot across recursive structures, and the authors state skipped compute only partly becomes wall-clock. They list sparsity-aware kernels and a learned max-recursion budget as future work; max recursion is still fixed before training.
Eval is on three same-source public datasets with hot-start history items. Industrial ultra-long behavior sequences, feature crosses, and candidate scoring have different cost structures that the paper does not cover.
6. Industrial takeaway: first see where the router spends compute
If you have a user-sequence backbone, the cheapest first step is to log position, item frequency, and chosen depth beside it and check whether extra compute lands on recent or sparse behaviors.
Before shipping, compare speed against a fixed trunk at the same max effective depth—encoder latency and full-request latency separately. Add an ablation that keeps shared parameters but drops the adaptive gate to separate gains from parameter reuse versus compute allocation. For systems that personalize ranking from user history, these experiments map directly onto the quality–serving-cost trade-off. Longer sequences and deeper trunks are more worth trying, because more positions can exit early and more compute can be saved—provided the serving stack handles dynamic-length batches efficiently.