Oct 3, 2026 · paperjuice · 25 min read · 4946 words advanced

GenRec: Generative Recommendation at JD.com, Explained.

paperjuice recommendation generative-retrieval reinforcement-learning

Summary: GenRec (arXiv 2604.14878, Zou et al., SIGIR 2026) replaces the usual retrieve and rank pipeline with one decoder only language model that writes item identifiers directly. It is deployed on the JD App homepage feed. Three ideas make it work at that scale: supervise a whole page of interactions at once, compress the input during prefill only, and align the model to real clicks and purchases with a reinforcement learning method that has a relevance gate against reward hacking. The online A/B test over one month reports 9.5% more clicks and 8.7% more transactions.

+9.5%clicks in one month of online A/B testing
+8.7%transactions in the same test
560Muser interaction sequences in the training data
~2xshorter prompt from the token merger

1. Why this paper matters

Most large scale recommenders still follow a multi stage pipeline: candidate retrieval narrows millions of items to hundreds, then ranking models score those hundreds. Each stage is trained separately, with its own features and its own failure modes. Generative recommendation tries to collapse those stages into one model that directly generates the items a user is likely to interact with, the same way a language model generates the next word.

That idea has a practical problem. A language model is comfortable generating words. Generating items at industrial scale means dealing with three things that do not show up in toy demos:

  • Pagination. A user scrolls through pages of results, and the same history can produce several valid positive items. A point wise training label cannot capture that.
  • Input length. Long behavior histories, where each item is represented by several tokens, make prompts expensive and slow to serve.
  • Alignment. A model trained only to imitate past behavior reproduces popularity bias and past habits. Optimizing a reward directly invites reward hacking, where the model finds outputs that score well on the reward model without matching what users actually want.

GenRec addresses each of these with a specific, testable component, and it reports results from a production system rather than a benchmark alone.

2. Problem setup and notation

The model receives a user history \(S_u\) and must produce a page of items. Each item \(v\) is represented not by a single ID but by a hierarchical Semantic ID (SID) of three tokens. Generation then means writing a sequence of SID tokens, with a separator token between items.

The objective the paper targets is the probability of the next token given the history and the tokens written so far:

\[ \mathcal{L}_{\text{SFT}} = -\sum_{t=1}^{|Y_{\text{page}}|} \log P_\theta\left(y_t \mid S_u, y_{Everything else in the paper is about what goes into \(Y_{\text{page}}\), how the input \(S_u\) is compressed, and how the policy is pushed beyond imitation afterward.

3. Semantic IDs: turning items into tokens

An item needs a discrete identity the model can generate. GenRec builds it in three steps:

  1. Multimodal encoding. A multimodal model, Qwen2.5-VL, encodes each item's image and text into one embedding, so visual appearance and description both count.
  2. Domain fine tuning. The embeddings are refined using collaborative pairs, items that users interact with together, so the space reflects recommendation similarity rather than only visual or textual similarity.
  3. Residual quantization with K means. RQ K means repeatedly clusters the residual of each vector. The result is a hierarchical tuple of cluster indices, \(\text{SID}(v_i) = \{s_i^1, s_i^2, s_i^3\}\). Coarse clusters come first, finer ones after.

The result is three tokens per item. That is the number the rest of the paper has to work with, and it is the reason input compression matters: a history of 100 items becomes 300 tokens before any separators.

4. Architecture and model sizes

GenRec is a decoder only transformer built on the Qwen2.5 family. The authors tested three sizes:

ModelLayersHidden sizeRole
1.5B362048Smallest variant
3B362048Primary model, used for the production results
7B283584Largest variant, almost no extra gain over 3B

The 3B model is deeper and narrower than the 7B model, and the paper reads that as evidence that depth matters more than width for this domain. Going from 1.5B to 3B gives 8.6% relative HR@10. Going from 3B to 7B, with 2.3 times the parameters, gives only 0.6%. For a team deciding how big to make a production model, that curve is the practical takeaway: the extra parameters past 3B buy very little here.

5. Page wise next token prediction

Standard next token training treats each item as its own example. The paper's observation is that the same user history can be followed by several valid positives, because a page of results contains several things the user clicks or buys. Point wise labels force the model to treat one of those as correct and the others as wrong, which blurs the gradient.

The fix is to supervise the whole page as one target sequence. The target contains the items the user ordered, the items clicked, and the items exposed, ordered by interaction intensity. That gives the model a denser signal from each forward pass, since one page supplies many correct tokens instead of one.

Training objectiveHit rate at 10Hallucination rate
TIGER (point wise)0.166015.46%
LC-Rec (point wise)0.36697.80%
GenRec, page wise0.44564.96%

Against the point wise LC-Rec baseline, page wise training gives a 21% relative improvement in HR@10 and a 36% reduction in hallucination rate. Hallucination here means the model generates an item identifier that does not correspond to a real item in the catalog, which is a concrete failure mode for generative retrieval and the reason the paper tracks it separately.

GENREC PIPELINE, END TO END Item Qwen2.5-VL embedding + collaborative tuning Semantic ID RQ K means 3 tokens per item Token merger prefill only, ~2x shorter decode stays full length Decoder LM Qwen2.5, 3B primary 36 layers, 2048 hidden Page wise next token training one page of ordered, clicked and exposed items as the target GRPO-SR alignment Beam search point wise decoding writes candidate pages served to the feed

Fig. 1: The GenRec pipeline from raw item to served page. Orange boxes are the paper's three main contributions: the token merger, page wise training, and GRPO-SR alignment.

6. Asymmetric linear token merger

Three tokens per item means long histories get expensive. The token merger shortens the prompt, but only on the prefill side. Its job is to take each item's three SID embeddings and combine them into one vector with a single linear projection:

\[ \mathbf{h}_{v_i} = \text{Linear}\left(\text{Concat}\left(\mathbf{e}(s_i^1), \mathbf{e}(s_i^2), \mathbf{e}(s_i^3)\right)\right) \]

The word asymmetric is doing real work here. Only the input history gets merged. Special structural tokens such as the separator are left alone, so the model can still see where items begin and end. And decoding is untouched: the model still generates the full three token SID for every output item, at full resolution, using the original generative objective.

The cost of this design is that the merged input is a lossy summary. The paper's ablation shows that in this setting the loss is negligible. Removing the merger changes HR@10 from 0.4456 to 0.4467, a difference inside noise, while halving the prompt length. That is the central trade: the model keeps its accuracy with about half the input tokens.

Why asymmetric matters: merging the output side as well would make the model generate in a shorter code, which is a different and harder task. Restricting the change to prefill keeps the generative target identical to training, so nothing about what the model is learning to produce has to change.

7. GRPO-SR: aligning the model to real preferences

Supervised training teaches the model to imitate what users did. It does not teach it what they would prefer. The paper uses reinforcement learning on top of supervised training, based on Group Relative Policy Optimization (GRPO), with two additions the authors call GRPO-SR.

7.1 The objective

GRPO samples a group of candidate outputs for each user, scores them, and updates the policy toward the better candidates within the group, using the group average as the baseline. The full GRPO-SR loss has two parts:

\[ \mathcal{L}_{\text{GRPO-SR}}(\theta) = -\mathbb{E}\left[\sum_{i=1}^{G} \frac{\pi_\theta(o_{i,t} \mid S_u, o_{i,The first term is the policy gradient with importance sampling, which keeps the update stable in a single step. The second term is a negative log likelihood regularizer on real positive items, weighted by \(\alpha\). The authors state its purpose directly: it anchors the policy to real user behavior, so optimizing the reward cannot drift the model far from what actually happens on the platform.

7.2 The reward: dense, gated, and calibrated

The reward for each candidate has three parts, and each one addresses a specific failure:

  • Dense preference score. A SIM based preference model gives every candidate a score between 0 and 1, rather than a binary hit or miss. Dense rewards carry more information per sample.
  • Relevance gate. A gate \(\mathcal{G}_i = \mathbb{I}(s_i > \tau)\) multiplies the score. If a candidate is not a syntactically valid combination of semantic ID tokens, its reward is zeroed. The gate is the paper's answer to reward hacking: without it, the policy learns to emit combinations that the preference model happily scores but that do not correspond to real items.
  • Calibration to the group maximum. Positive items from the training data are anchored to the highest reward in the group, so the model is pushed toward the best candidates rather than merely away from the worst.

Written compactly, each candidate's reward is \(r_i = \mathcal{G}_i \cdot r_i^{\text{pref}}\), and the calibrated version replaces positive items' rewards with \(r_{\max}\) of the group.

7.3 What RL changes

ModelHR@50R@1R@10Hallucination rate
Base SFT0.71920.10270.15194.96%
Plain GRPO (no gate, no NLL anchor)0.72480.11770.16506.03%
GRPO-SR (full)0.74380.12120.16792.68%
GRPO-SR without the gate0.70160.10670.15981.96%

Three details in this table matter more than the headline. First, plain GRPO raises the accuracy metrics but also raises the hallucination rate, from 4.96% to 6.03%. That is the reward hacking signature: better scores paired with more invalid outputs. Second, GRPO-SR cuts hallucinations to 2.68%, 46% below the base model, while also improving every accuracy metric. Third, removing only the gate drops HR@50 from 0.7438 to 0.7016, which the authors read as clear evidence of reward hacking. The one number that looks better without the gate, hallucination at 1.96%, is the gate's own kind of artifact: fewer outputs, many of them safe but less useful.

The relative gain in R@1 over base SFT is 18%, from 0.1027 to 0.1212.

8. Data, training, and infrastructure

  • Source: interaction logs from JD.com's recommendation platform, about 560 million user interaction sequences collected over one month.
  • Split: the last day is held out for testing, the rest is used for training.
  • Hardware: distributed training on 8 NVIDIA H100 GPUs.
  • Optimizer: AdamW with a linear warmup over the first 1% of steps, followed by cosine decay.
  • Inference: point wise beam search, generating a beam of candidate items for each query.

The paper does not publish training time, total GPU hours, or per request latency numbers, so the efficiency claims rest on the 2x prompt compression and the production deployment rather than on a latency table.

9. Online A/B test

The strongest evidence in the paper is not a benchmark. The authors deployed the base SFT model and the RL aligned model on the JD homepage feed, each receiving 10% of traffic, for one month, with a two sided significance test at p below 0.05.

ModelExposure rateClick countTransaction count
GenRec SFT (versus control)48.7%+8.5%+7.3%
GenRec with GRPO-SR (versus control)57.3%+9.5%+8.7%

The RL step adds about one point of clicks and 1.4 points of transactions on top of supervised training. The exposure rate rises from 48.7% to 57.3%, which is consistent with the authors' claim that RL resolves a click conversion misalignment: the supervised model shows items people click but do not buy, and the aligned model shifts toward items that convert.

Long tail items, the ones rarely shown, do better: the paper reports a 10% increase in exposure rate, 16% more clicks, and 13% more transactions for that group. A recommender that only imitates history tends to concentrate exposure on popular items, so a gain specifically on long tail items is the more interesting result.

How to read these numbers: the A/B test runs on one platform, one feed, and one month. The control is the team's own production system, not a published baseline. The results are statistically significant by the paper's test, but they do not establish that the same gains would appear on another platform, or that the improvement holds beyond the period tested.

10. Limitations, as the paper and the setup imply

The paper's own discussion of limitations is brief. The authors say they will investigate the reasoning ability of such frameworks in future work, which points to a real gap: the model predicts what a user will engage with, but it does not reason explicitly about why. Beyond that, the following constraints follow from the design:

LimitWhy it matters
No explicit reasoningThe model imitates and optimizes engagement. It cannot explain a recommendation or handle a user intent that never appeared in logs.
Scaling flattens past 3BThe 7B model adds almost nothing, so bigger is not automatically better for this task.
Dependence on page level logsThe page wise objective needs the page structure, meaning which items were shown together. Platforms without that logging cannot reproduce the training target.
Reward model biasThe preference score comes from a learned model. Calibration and the gate reduce the risk of exploitation, but do not eliminate the bias of the reward model itself.
Single platform evidenceAll production results come from JD. Transferability to other catalogs, languages, or user populations is untested in the paper.
No released code or modelThe paper does not state a public release. Reproduction depends on re implementing the SID pipeline, the merger, and the reward model.

11. What a practitioner can take from it

  • Supervise sets, not single items, when a context has several valid outputs. Page wise targets reduced ambiguity and gave a 21% lift in HR@10 over point wise training.
  • Compress only where it is safe. Prefill compression halved the prompt with no measurable loss, because the output side and the training target stayed unchanged.
  • Gate the reward, always. Without the relevance gate, RL optimizes a proxy that the model learns to game. Validity checks belong inside the reward.
  • Keep a likelihood anchor during RL. The NLL term stops the policy drifting away from real behavior while it chases the reward.
  • Measure hallucination separately. In generative retrieval, a generated ID that maps to no real item is a distinct failure from a wrong but valid item, and it needs its own metric.
  • Judge scale by the curve, not the headline. The step from 1.5B to 3B mattered. The step from 3B to 7B did not.

12. One request, step by step

Abstract descriptions hide what actually happens when a user opens the app. This section follows one request through the system, using only the components and numbers the paper reports, so you can see where each contribution sits in time.

  1. The user opens the homepage. The serving system gathers the user's recent behavior: items viewed, clicked, and ordered. Each item in that history is already stored as its three token Semantic ID, so no image or text model runs at request time.
  2. The prompt is assembled. The history is laid out as a sequence of item triples, with separator tokens between items. For a history of 100 items, that is roughly 300 item tokens before separators.
  3. Prefill with the token merger. The asymmetric merger combines each item's three embeddings into one vector through a linear layer, halving the prompt length the decoder must process. Separator tokens pass through unchanged so item boundaries stay visible.
  4. Decoding at full resolution. The decoder now generates output items. Each output item is written as three full resolution tokens, exactly as during training. The merger has no effect on this step, which is why the training target and the served output stay the same.
  5. Beam search. The paper uses point wise beam search, generating a beam of candidate items per query. Candidates that are not valid combinations of semantic ID tokens are the ones the relevance gate was trained to avoid producing in the first place.
  6. The page is returned. The candidate items form the feed. Impressions and interactions are logged, and those logs become the next day's training data, which closes the loop the reward model and the A/B test measure.

Two properties of this flow matter for anyone trying to adapt it. First, the expensive parts that depend on the item catalog, the multimodal encoder and the quantizer, run offline when items are added. Second, the online cost is dominated by prefill and decoding of a single decoder. There is no separate candidate retrieval index to keep fresh, which is one of the operational arguments for the generative design. The paper does not measure serving cost against the previous pipeline, so that argument should be read as a design rationale, not a benchmarked result.

13. How GenRec differs from the baselines it names

The paper compares against two generative baselines, TIGER and LC-Rec, and the differences between them are the clearest way to see what GenRec changes.

AspectTIGERLC-RecGenRec
Training targetSingle next item, point wiseSingle next item, point wise, with language alignmentWhole page of ordered, clicked and exposed items
Input length handlingFull token sequenceFull token sequencePrefill merger, about 2x shorter
Post training alignmentNone reportedNone reportedGRPO-SR with dense reward, gate and NLL anchor
HR@10 (paper's table)0.16600.36690.4456
Hallucination rate (paper's table)15.46%7.80%4.96%

Reading the table carefully: TIGER and LC-Rec differ from GenRec in more than one way at once. The gap between LC-Rec and GenRec is therefore not attributable to a single change. The paper's ablations are what separate the effects, and they are discussed in the next section. The honest summary is that the page wise objective is the component with a direct ablation in the paper that shows it working against a point wise baseline, while the RL component has its own ablation on top of the supervised model.

14. Reading the ablations table by table

14.1 The token merger

The merger ablation removes the merge step and compares the two directly. HR@10 is 0.4456 with the merger and 0.4467 without, while N@10 moves from 0.2635 to 0.2653 without it. Both differences are very small. The sensible reading is that, in this setting, the merged prefill representation carries essentially the same information as the full three token representation, at half the input length. The paper's claim of negligible accuracy loss is supported by this table.

One caution. The ablation is run on the offline test set. Whether the same is true under the distribution shift of a live feed, where the catalog and user mix change over time, is not tested in the paper.

14.2 Scaling

SizeHR@1HR@10N@10HR@50Hallucination rate
1.5B0.10770.41030.24840.65275.34%
3B0.11890.44560.26350.71924.96%
7B0.12210.44830.26490.72165.42%

The step from 1.5B to 3B is the one that matters. HR@10 rises by about 8.6% relative, and hallucination falls slightly. The step from 3B to 7B adds 0.6% relative HR@10 and actually raises hallucination from 4.96% to 5.42%. A team choosing a production size would stop at 3B on these numbers, and would spend the compute saved on RL alignment or data instead. The paper's depth over width explanation, that the 3B model is deeper and narrower while the 7B model is shallower and wider, is consistent with the table but is a hypothesis the authors support with this one comparison, not a controlled study of depth versus width.

14.3 Reinforcement learning

The RL table is the most informative in the paper because it isolates each design choice. Moving from base SFT to plain GRPO raises HR@50 from 0.7192 to 0.7248 and R@1 from 0.1027 to 0.1177, but raises hallucination from 4.96% to 6.03%. Adding the gate and the NLL anchor, the full GRPO-SR, raises HR@50 to 0.7438 and R@1 to 0.1212 while lowering hallucination to 2.68%. Removing only the gate from GRPO-SR drops HR@50 back to 0.7016 and gives a hallucination rate of 1.96%.

The last row needs careful interpretation. A lower hallucination rate is not automatically better. The gate-free model emits fewer invalid identifiers, but it also loses 5.7% of its HR@50 relative to the full model. The authors read the combination as reward hacking suppressed by the gate: without the gate the policy finds a region of outputs that the preference model scores well, while the real target, the items users interact with, is not improved as much. A useful practical rule follows. When a metric improves only in one direction and another metric falls, check whether a constraint in the objective is being traded away.

Step from base SFTChange in HR@50Change in R@1Change in hallucination
Plain GRPO+0.8% relative+14.6% relative+1.07 points, worse
GRPO-SR (full)+3.4% relative+18.0% relative-2.28 points, better
GRPO-SR without gate-2.4% relative+3.9% relative-3.00 points, better

These percentages are computed directly from the paper's Table 3 values, not reported by the paper in this form, so they are a presentation of the paper's numbers rather than a new result.

14.4 Page wise training against point wise

Page wise training improves HR@10 by 21% relative over the point wise LC-Rec baseline and cuts hallucination by 36% relative. The paper attributes the gain to denser gradient signal, since one page contributes many correct tokens rather than one, and to removing the ambiguity of one input having several valid labels. The authors also state that page wise training reduces hallucination by over 50% compared with vanilla next token prediction, a comparison whose exact baseline is described in less detail than the LC-Rec comparison, so readers should treat that specific figure with the same caution as the rest of the offline numbers.

15. Failure modes worth designing for

Generative recommenders fail in ways that retrieval pipelines do not, and the paper's own measurements point at several of them. A team adapting this approach should plan for each one before deployment.

Failure modeWhy it happens hereWhat to monitor or build
Invalid item identifiersThe decoder can generate a token combination that maps to no real item. The paper tracks this as hallucination rate, which ranges from 2.68% to 6.03% across its variants.Track the hallucination rate per deployment. Enforce validity with a gate in training and a constrained decoder or fallback at serving time.
Reward hackingA learned preference model can be exploited by outputs that score well but do not match real interactions. The gate ablation shows a 5.7% HR@50 drop when the gate is removed.Keep a likelihood anchor on real positives and monitor the gap between reward and held out interaction metrics.
Popularity concentrationA model trained on history favors frequent items. The paper reports long tail gains from RL, which suggests the baseline does concentrate exposure.Track exposure share of long tail items and set a floor if the business needs variety.
Staleness of semantic IDsItem embeddings and the quantizer are fitted on a snapshot. New items or shifting content can drift away from the learned codebook.Refit or extend the codebook on a schedule and test how many new items fall into poorly populated clusters.
Distribution shift in the testThe offline test uses the last day of logs. A month long A/B test is the stronger signal, and the paper's offline numbers may not predict live results exactly.Use a live experiment as the decision point, and keep an offline metric as an early filter only.
Note on the offline metrics: HR and N metrics are computed on the held out day of logs. They measure agreement with recorded behavior, which is a proxy. The one month online test is the outcome the paper actually reports as a business result, and that is where the decision should be anchored.

16. What it would take to reproduce the core idea

The paper gives enough detail to reconstruct the design, though not enough to reproduce the numbers. A reasonable reproduction on public data would proceed in stages, each with its own check.

  1. Choose a public interaction dataset with page structure. The method needs logs where items were shown together, not only isolated click pairs. Several public recommendation datasets record impressions, which is the closest substitute.
  2. Build semantic IDs. Embed items with any available multimodal encoder, refine with collaborative pairs, then apply residual quantization to get three levels per item. Check that the codebook uses its clusters: a codebook where most items fall into a few clusters defeats the purpose.
  3. Train the supervised baseline first. Use a small decoder, compare page wise targets against point wise targets, and reproduce the direction of the HR@10 gap before attempting anything more elaborate.
  4. Add the merger and measure the cost. Halve the prefill input and confirm the accuracy change is within noise on your data. If it is not, the claim does not transfer to your setting.
  5. Add GRPO-SR last. Implement the dense reward, the gate, and the NLL anchor as separate switches so each ablation is one flip away. Watch hallucination and the held out metric together, not one at a time.

Expect the absolute numbers to differ. The paper's values come from JD's catalog, JD's logs, and JD's preference model. The reproduction is successful if it reproduces the direction of each effect: page wise beats point wise, the merger is roughly neutral, and the gate matters for hallucination and reward hacking.

17. Open questions the paper leaves

  • Does the reasoning gap matter? The authors plan to study reasoning ability in future work. A model that predicts engagement without explaining it may be fine for a feed, but it limits use cases such as conversational recommendation or justifying a choice to a user.
  • How well does the merger scale with history length? The 2x compression is reported for the setting used. The paper does not show a sweep over history length, so the compression benefit at very long histories is unknown.
  • How sensitive is the gate threshold? The gate uses a threshold \(\tau\) on the validity score. The paper does not report a sweep over \(\tau\), so the stability of the gate under threshold changes is an open question.
  • Does the gain persist? A one month A/B test is a strong result, but it does not show whether the gain holds over quarters, as users and catalog change.
  • What happens on other platforms? The paper's evidence comes from a single large e-commerce platform. Catalogs with different structure, such as news, video, or small inventories, would stress the semantic ID design differently.

18. Glossary

TermMeaning here
Generative retrievalProducing item identifiers directly with a language model, instead of scoring a fixed candidate list.
Semantic ID (SID)A short, hierarchical token sequence that represents an item, built by clustering its embedding.
RQ K meansResidual quantization: cluster a vector, then cluster the leftover residual, repeatedly, to get coarse to fine codes.
HR@K, hit rateThe fraction of test cases where the true item appears in the top K generated results.
NDCG, N@KA ranking metric that rewards placing relevant items higher in the list.
GRPOGroup Relative Policy Optimization: a policy gradient method that uses the average reward of a sampled group as the baseline.
Reward hackingWhen a policy improves its reward score without improving the real objective, often by exploiting flaws in the reward model.

FAQ

Does GenRec replace the whole recommendation stack?

The paper presents it as a single generative model for the homepage feed, which collapses retrieval and ranking into one generation step. Whether a production system should fully remove the old stack is a separate engineering decision that the paper does not settle.

Why three tokens per item?

Three levels of residual quantization give a hierarchical identity: the first token captures a coarse cluster, the next two refine it. The paper uses three levels, and that choice is what makes the token merger's 2x compression relevant.

Is the RL step worth its cost?

The paper's A/B result says it adds about one point of clicks and 1.4 points of transactions over supervised training, and it cuts hallucinations by 46% relative to the base model. Whether that is worth the extra training pipeline depends on the value of those points on your platform.

Can I reproduce this?

Not directly. No code or model release is stated in the paper, and the training data is proprietary JD logs. The ideas are reproducible on public data: semantic IDs from any multimodal embedding, page wise targets from any logged feed, and a GRPO style update with a validity gate. The specific numbers are JD specific.

Takeaways

  • GenRec is a decoder only generative recommender with three items of tokens per product, deployed on the JD homepage feed.
  • Page wise next token training gives a 21% relative HR@10 gain over point wise training and a 36% cut in hallucination rate.
  • The asymmetric token merger halves prompt length during prefill with a negligible accuracy change, because decoding is left at full resolution.
  • GRPO-SR combines a dense preference reward, a relevance gate and an NLL anchor. The gate is what prevents reward hacking.
  • The one month A/B test reports +9.5% clicks and +8.7% transactions, with bigger gains on long tail items. It is one platform, one feed, one period.

References

← Paper Juice index