GENERATIVE · 2026-11-05
Generative — Paper Daily, 2026-11-05
Today's generative track is about running generative recommendation in production, and running it cheaply. ReuseGR has a large model generate code prefixes per query offline and leaves only a small model online for personalized completion; ZeroGR switches constrained decoding to filter first and score second, skipping a large amount of wasted work on candidates. OneTrans-GSR moves one step downstream, using a single model to generate the whole screen for reranking and mix-ranking, while SPADE builds query suggestion for local services as one generative model that handles location and diversity. Another group of papers probes the weak spots of LLM recommendation agents: τ-Rec-Books finds that agents fail to ask about needs, and another paper shows that one fabricated safety-hazard review is enough to make an agent switch to the attacker's target.
4.90
LEAD STORY ·
Alibaba /
Xidian University
Teams putting generative retrieval into production should read this: it shows how to reuse large-model compute per query while leaving personalization to a small online model, and it is backed by an online A/B test.
4.50
Engineering teams serving generative recommenders should read this: it shows that most constrained-decoding compute goes to candidates that will be discarded, and gives a filter-first system implementation.
4.46
Teams working on reranking and mix-ranking should read this: it turns two stages that have long run on rules into a generation problem that improves with more compute, and the system is fully deployed.
4.45
LLM-based recommenders often give the user a written profile, but items get no matching description; the user profile only goes into the reranker prompt, where it competes for length; and once written, the profile is never corrected. HARP trains no parameters and fills all three gaps. It gives each item a profile with the same four fields as the user profile (preference, quality, context and audience), filled from metadata and reviews by rules, with no LLM calls. Before reranking, the system picks similar users and items as collaborative neighbours, whose memories, text records kept for each user and item, are pooled into the reranker prompt. HARP rescores candidate neighbours by how closely their profiles match the user's: the worse the match, the bigger the discount, and the less likely they are picked. During warmup, it tries one recommendation on the user's most recent past interaction, and the LLM checks whether it was right, reflects and rewrites the profile. On four public datasets, Hit@1 beats the strongest published baseline by 6.9% to 24.0%, and ablations show that weighting neighbours by profile match contributes the most.
4.45
The hard part of conversational recommendation is that users rarely state all their requirements up front. τ-Rec-Books keeps each book request fixed and changes only when the user reveals requirements: all at the start, one at the start and the rest only when asked, or some never. A requirement that is never stated can only be inferred by proposing books and watching whether the user accepts or rejects them. Across four agents, average success falls from 0.975 when everything is stated, to 0.756 when requirements come only on request, to 0.283 with hidden requirements. Ask-only tasks fail mainly because agents never ask; told to ask, they recover almost fully. On hidden tasks, agents often give as the answer a book they never showed the user. Evaluating a recommendation agent means checking whether it asks, and whether it uses rejections to rule out possible requirements.
4.30
MeituanQuery suggestions on the homepage of a local-services app must generate a few queries out of millions of possibilities. They have to fit personal taste, match the current time and location, cover long-tail needs, and not repeat each other. Earlier methods handle one of these at a time. SPADE does them together in one generative model. For example, when BPE tokenization counts character sequences, SPADE weights each query by its business value, computed from platform engagement and conversion signals, so valuable long-tail queries are merged into fewer tokens and become easier to generate. For preferences, it aligns directly on production impression and click data with DPO. Offline, HR@5 is 5.6% higher than the strongest generative baseline; in a one-week online A/B test, module CTR rose 1.88%.
4.20
Flow-based collaborative filtering has an easily missed weakness: the training starting point has nothing to do with the user. These models learn to move step by step from a random starting point to a user's real interaction record, and existing methods sample that starting point from global item popularity, so the model gets no personal clue. SourceFlow changes the starting point itself. It replaces some items in the user's history with items that the same users often interacted with but this user never touched, so training, like inference, fills in missing interactions from a record that carries collaborative signal. Across five datasets, Recall@10 is on average 15.7% higher than the strongest flow-based method. Shuffling the same starting points across users reverses the gain, showing that what matters is pairing each starting point with its user.
3.90
Traditional recommenders give each item an arbitrary integer ID that carries no meaning, so models must learn embeddings purely from interactions, cold-start items suffer, and embedding tables keep growing. This hands-on tutorial traces the move from plain IDs to Semantic IDs and their use in multimodal, cold-start and cross-domain recommendation, with exercises for building and evaluating SIDs, training models, and transferring across domains. It closes with open problems such as keeping SIDs up to date as content changes. Engineers who want a structured start with SIDs can use the exercises directly as learning material.
3.65
Sellers rewrite product descriptions hoping an LLM will recommend them more often in its answers; this is called generative engine optimization. But one description serves users with different needs: some are still vague about what they want, others are ready to decide. The authors re-test existing methods across four domains and ten user intents and find the gains vary widely by intent; prompts optimized automatically by a model even do worse on average than the handwritten prompt they started from. Tracing the updates shows the prompts gradually drop explicit recommendation instructions and drift into generic marketing language. Their AMO keeps the recommendation instructions as a fixed core and learns only strategies appended after it, and the average improvement in where the target item is cited in the LLM's answer is 35% larger than with the strongest learning-based method. This kind of optimization should be evaluated separately for each user intent.
3.25
Steering an AI agent does not require writing commands into a web page. The authors show that a single fabricated safety hazard, posted as an ordinary review, makes the agent drop the legitimate options out of its trained harm-avoidance and pick the attacker's target instead. The payload contains no command, so deployed injection detectors score it as benign. With no filter, it redirects the agent's choice about as often as instruction injection; behind a detector it is far more effective than instruction injection. Production browser agents fall for it too. Adding one rule to the agent's instructions, that a hazard claim needs corroboration from another source before it counts, cuts the attack success rate from 68.4% to 3.6%.