How LLMs Are Changing Recommender Systems: Recommenders That Read Product Descriptions

Why LLMs came into recommendation

Recommender systems have long learned patterns of the form 'people who bought this product also bought that one.' Such patterns are called collaborative signals. Products are usually represented only by unique numbers (IDs), and the model infers preferences from how often the numbers appear together. This works well with plenty of data, but a number does not capture 'why' someone liked the product.

CURec paper calls this problem the 'semantic-collaborative gap.' ID-based representations or item-side attribute information alone cannot capture meaning tied to user preferences, such as the reason to recommend that product. IADSR paper shows the same weakness from another angle. It reports that relying only on collaborative information when filtering out noise, such as accidental clicks, removes too much, and that the problem is especially severe for products with little history (cold items).

LLMs (large language models) can read product descriptions and understand their meaning using knowledge about the world. As the position bias study paper points out, LLMs drew attention as general-purpose recommendation tools because they can attempt recommendations from instructions alone, without task-specific training (zero-shot). The same study, however, warns that using an LLM for recommendation as-is has an important pitfall. That pitfall is covered later.

Core idea: the clerk who reads records and the clerk who reads descriptions

As an analogy, a traditional recommendation model is a store clerk who only looks at the checkout records. Its statistics, such as 'people like this customer bought a lot of this,' are accurate, but it cannot suggest new products that just arrived because they have no records. An LLM is a clerk who has read every product description. It can look at a new product's description and say 'if you like hiking, this should suit you too,' but it does not really know what this store's customers actually buy together.

So the core design question is 'how do you get the two clerks to work together?' There are two broad approaches. One puts the LLM in a supporting role. The LLM produces features such as embeddings (numeric vectors) that capture a product's meaning, or reasons for recommendation, and the existing recommendation model makes the final decision. The other puts the LLM in the lead role. The user's history and the candidates go into a prompt, and the LLM directly chooses or generates the next product.

The two make different trade-offs. The supporting approach adds meaning while keeping the existing system's speed and collaborative signals, but it does not use the LLM's reasoning ability to the full. The lead approach uses the LLM's reasoning directly in the decision, but it captures collaborative signals poorly, costs more, and can produce unstable outputs. Much of the recent research looks for a point somewhere between the two.

How it works

Start with the supporting approach. IADSR paper works in two steps. First, for the same product, it separately obtains a collaborative embedding produced by an existing sequential recommendation model and a semantic embedding produced by an LLM. Next, it aligns the two (Alignment) and then identifies noise in the user's behavior history by checking it against long-term and short-term interests. In this structure, semantic information protects cold items that would have been deleted if the decision relied on records alone.

CURec paper goes a step further. It first uses post-training to teach the LLM the recommendation objective, so that it follows instructions and reasons with CoT (Chain-of-Thought, step-by-step reasoning). The features the LLM produces are used to train a recommendation model, and the user-item prediction scores from that recommendation model are then used as rewards to refine the LLM with reinforcement learning. It is a loop in which the clerk who reads records grades the answers of the clerk who reads descriptions.

In the lead approach, the first hurdle is how to represent products in the LLM's language. According to the PauseRec study paper, LLM-based generative recommendation often represents products as Semantic IDs (products turned into short bundles of code tokens). The LLM never saw these tokens during pre-training, so they interfere with its natural-language reasoning pathway. DICE paper does not generate text at all. Instead, it scores each of the given candidates and picks the highest-scoring one along with a confidence value.

How the field developed: what each study added

The position bias study paper exposed a basic weakness of LLM recommendation using real data. Merely changing the order of candidates in the prompt changed the recommendation results substantially. The authors proposed a prompting strategy called RISE (Ranking via Iterative SElection) and reported that it reduced sensitivity to input order and improved stability without fine-tuning or post-processing.

CURec paper and IADSR paper refined the supporting approach. CURec used the recommendation model's scores as rewards to improve the quality of the reasons the LLM generates. IADSR complemented denoising with semantic embeddings and confirmed on four public datasets that it can be used with multiple sequential recommendation models. On the cost side, OD-LLM paper combined low-rank compression using singular value decomposition (SVD), tokenization normalization, and progressive layer-wise alignment, and reported no loss in effectiveness compared with the original recommendation model even after halving the model size. The work targets on-device recommendation, where latency, privacy and unstable internet connections are concerns.

PauseRec paper re-examined explicit reasoning. Breaking down the multi-stage training that makes the model generate reasoning text revealed three limitations: weaker representation of world knowledge, a mismatch between the embedding spaces of Semantic IDs and natural-language tokens, and sensitivity to the quality of the reasoning text. It therefore proposed implicit reasoning that does not write out thoughts as text, and reported up to 6.22% better performance than explicit CoT, up to 65% less training GPU time, and up to 71.3% faster inference.

DICE paper targeted three problems of generative recommendation at once: it may fail to identify a single candidate, it depends on the order of candidates, and it gives no confidence. Inspired by Jev, a decision model that makes fast choices and outputs explicit confidence, it proposed 'decision-native' recommendation. Tree-structured attention lets all candidate branches share the computation over the user's history, producing order-invariant scores in a single forward pass. It reported higher top-1 accuracy than all compared baselines on three datasets, unchanged choices under the order permutations tested, and up to about 6 times faster speed than generative methods.

Where the field is heading

The first trend is bringing collaborative signals directly into the LLM. GALLM paper argues that because LLMs are pre-trained mainly on language, they capture the collaborative signals in user-item interactions poorly, so it builds a graph over text tokens and item tokens. It converts text-text, item-text, and item-item relations derived from item co-occurrence into lightweight attention biases, letting the LLM see collaborative signals without a separate graph encoder. It reported an average HR@5 improvement of 9.76% over the strongest baseline on four benchmarks. In effect, it shows the checkout records directly to the 'clerk who reads descriptions.'

The second trend is avoiding repeated expensive reasoning on every request. rEDMRec paper Distills the reasoning of a Teacher LLM into four editable experience memories: long-term preferences, short-term context, item awareness, and counterfactual comparison with wrong answers. Afterward, a lightweight Student LLM ranks candidates by drawing only on these memories, without calling the Teacher again. The design decouples online inference cost from reasoning depth, and another advantage is that people can inspect and edit the memories. It reported up to 13.3% improvement over the second-best baseline on ML-1M.

The third trend is auditing LLM recommendation from the perspective of social impact. A physician recommendation audit study paper analyzed 40,068 responses from an experiment in which seven models were asked to choose one of five fictional doctors. Reputation signals had the largest effect: raising the rating from 3.9 to 4.7 increased the probability of being chosen by 31.4 percentage points. However, there were also skews by gender and race as signaled by names, and simply being placed first, with no other content, had an effect equivalent to $11 in consultation fees. Gender or race was mentioned in at most 0.03% of the reasons the models gave, so these effects were not visible in the models' own explanations.

Limitations, open issues and practical criteria

The first issue to address is order and format. As the position bias study paper and the physician recommendation audit paper show, the order in which candidates are listed alone changes the result. Generative output may name products that are not among the candidates or give no confidence paper. In practice, the minimum check is to shuffle the candidate order, run several times, and see whether the result holds; the fundamental fix is to use a structure that is not swayed by order (such as per-candidate scoring, as in DICE).

The second issue is cost. If the LLM runs inference on every request, latency and cost grow. Compression paper, implicit reasoning paper, and storing reasoning results in memory paper are all answers to this problem. Rather than handing the LLM even the first stage of filtering millions of candidates in real time, the common judgment is to use it to rank after the candidates have been narrowed, or to generate semantic features in advance.

The third issue is the reliability of explanations. One appeal of LLM recommendation is that it 'tells you why,' but the physician recommendation audit paper showed that the factors that actually drove the decisions hardly appeared in the reasons the models gave. The authors note that transparency requirements relying on models' self-explanations may miss such effects. For recommendations with a large impact on people, such as in healthcare and finance, bias should be measured not from explanation text but through audits that systematically vary attributes, and a structure with human involvement in the final decision is needed.

To sum up when to use it: LLMs add the most value when product text is rich, when there are many new products with little history, and when recommendation reasons need to be shown. Conversely, for large-scale ranking with ample interaction data and strict latency requirements, it is safer to keep the LLM in a supporting role and put a collaborative-signal-based model at the center. Common mistakes are judging quality from a single run, evaluating with a fixed candidate order, and showing generated explanations to users as-is without verification.

Further study

To grasp the problem first, start with the position bias study paper. It shows most intuitively what becomes unstable when you leave recommendation to an LLM as-is. Reading DICE paper next shows how to solve that problem with model architecture rather than prompting tricks.

If you are curious about the supporting approach, read IADSR paper and CURec paper together. The former is a simple form that attaches semantic embeddings to an existing model; the latter is a loop in which the LLM and the recommendation model teach each other. PauseRec paper gives a good summary of generative recommendation and the limits of Semantic IDs.

For recent directions, see GALLM paper for injecting collaborative signals and rEDMRec paper for reducing reasoning cost. Before putting this into a real service, we recommend reading the physician recommendation audit paper and first thinking about how you will measure whom your service's recommendations make visible and whom they hide.