PinRec: Unified Generative Retrieval Model for Pinterest Recommender Systems

In recommender systems, the home feed, search and related recommendations usually each have their own retrieval model, because each wants something different: the home feed cares whether users save, search cares whether they click out to buy, and related recommendations care whether they keep browsing. This KDD 2026 paper from Pinterest replaces all three with a single generative retrieval model, PinRec: pretrain on site-wide behavior, fine-tune separately on each surface's impression logs, and at generation time tell the model whether to look for what the user will save or what they will click out to. What really works is this condition on the target behavior; the unified model itself contributes much less: removing the condition drops offline recall on the three surfaces by 7.5% to 12.6%, while removing surface fine-tuning drops it by only 2% to 4.5%. Plugged into search as one retrieval source online, it raised saves by 3.88%.

This is a rare industrial paper that actually rolls generative retrieval out across several surfaces and spells out the deployment details, and retrieval teams should read it closely. Two reasons. First, its core gain comes from a very cheap change, "generate for a target behavior": one learnable condition vector lets the same history produce candidates for different purposes. Second, it gives concrete numbers for latency, memory and serving architecture that you can use directly to estimate cost. But its comparison with baselines favors itself, and scaling the model up brought no gain, so when reading it you need to separate what transfers from what is specific to Pinterest.

One user, three surfaces

Start with an example (illustrative). A user recently searched for "camping gear", saved two tents, and then opened a picture of an outdoor coffee pot to see related recommendations:

Same person, same history, completely different candidates on each surface. The traditional approach trains a two-tower retrieval model per surface, each with its own query tower, objective and index. That is costly to maintain, and the surfaces can hardly borrow from each other's data. PinRec aims to cover all three with one model without losing the differences in each surface's goals.

The overall flow

The model itself is a 12-layer Transformer with about 100 million parameters, roughly the size of the smallest GPT-2. It outputs continuous embeddings that are then used for nearest-neighbor retrieval, instead of generating item IDs directly like TIGER (a generative retrieval model that generates item codes Semantic ID by Semantic ID). The paper's reason is practical: at Pinterest's scale, Semantic IDs end up with tens of thousands of items crowded onto the same code, and results are clearly worse. Generating an embedding and then retrieving also naturally avoids generating an item that does not exist.

Input: Pins, queries and time stitched into one sequence

Each element of the sequence is one behavior: what the user acted on, on which surface, when, and how. Pins use Pinterest's existing content embedding (OmniSage, which blends image, text and the Pin–board relationship) passed through two or three fully connected layers; queries use an existing query embedding with the same treatment. Time is encoded in two parts: absolute time uses sine and cosine periods for days, weeks and seasons, and relative time (how long since the last behavior) uses a log scale. Finally a surface embedding is added to mark whether the behavior happened on the home feed, search or related recommendations.

This design has a direct benefit: new Pins, new ads and new queries can enter the model as long as they have content features, without first accumulating interactions. The paper's zero-shot experiment later relies on exactly this.

Generating for a target behavior: same history, different condition, different candidates

This is the most important component in the paper. Ordinary generative retrieval only learns "what will be interacted with next", without distinguishing a click from a save. PinRec adds a condition to the output layer: each target behavior and each surface has a learnable vector, which is fed into the output layer together with the sequence's last hidden state to produce the embedding of "this user's next Pin under this condition".

In training, the condition is filled with the behavior that actually happened on the target. For example, if the next step in the sequence is the user saving a tent, the "save" condition vector is fed in and the output is aligned to that tent. At inference it works the other way: fill in whatever behavior you want. Back to the camping example: with the same history, filling in "save" may retrieve campsite inspiration, while filling in "click out" leans toward tents you can order.

An analogy: the same shop assistant remembers all your purchases. Ask "what is worth bookmarking?" and "what can I buy right now?", and you get two different lists. The condition vector is that question.

The loss is the usual sampled softmax: make the output's similarity to the target Pin higher than its similarity to a batch of negatives. Part of the negatives are other users' targets in the same batch. Popular Pins appear often in batches and would be over-used as negatives, so a correction term estimated from appearance frequency is subtracted when computing similarity. The frequency is estimated with a count-min sketch, a counting structure that approximates how often each of a huge number of Pins appears using very little memory.

Surface fine-tuning: shown-but-not-engaged Pins as negatives

Pretraining uses only records where the user acted, with no impressions. In fine-tuning, the model takes one session of the user on a surface, joins the full history before the session with the Pins acted on in the session, and continues next-behavior prediction; Pins that were only shown in the session without interaction are added to the negatives.

Why not treat impressions as positives? The paper tested it: recall dropped 6.8% on search and 3.0% on related recommendations. The reason is easy to see. An impression only shows that the system pushed the Pin, not that the user wanted it, so treating it as a positive rewards "being pushed" instead of "being needed".

Multi-step generation and deduplication

Generation proceeds one step after another: at each step the model outputs one embedding per target behavior; one of them is then picked at random and appended to the end of the sequence as "the user looked at this next", and the model generates the next step, with time moved forward a little (the paper uses 10 seconds). This lets later steps move along "how the user might browse next" instead of repeatedly predicting the same next step.

Multi-step generation produces many similar embeddings, and retrieving with all of them directly would bring back lots of duplicate Pins. So two things happen before retrieval. First, allocate slots: out of the N Pins to retrieve, split them across target behaviors by budget ratio, and the embeddings generated for the same behavior across steps split that share equally; for example, the home feed might give 70% to "save" and 30% to "click out" (illustrative). Then merge: in generation order, if a new embedding's cosine similarity to an earlier kept embedding exceeds a threshold (tuned online between 0.75 and 0.9, with 0.9 slightly better on search and related recommendations), it is merged into the earlier one, only the earlier one is used for retrieval, and their slots are added. Similar directions query the index only once, but the number of results stays the same.

Serving cost

The model runs on NVIDIA L40S GPUs with the Triton inference server, using CUDA Graphs and a KV cache (which caches the already processed sequence so later steps only compute the new part). Nearest-neighbor retrieval runs a Faiss index on CPUs. At 80 requests per second, the version that generates for target behaviors has a median latency of 40ms, with 90% of requests within 65ms, roughly 3 to 4 times a two-tower retriever. Because it runs in parallel with other retrieval sources, end-to-end latency rises by less than 1%. GPU memory is about 1.6GiB, of which the model itself is about 250MiB, similar to the old two-tower model.

What these numbers mean: the main cost of generative retrieval is latency, not memory, and as long as it does not run serially on the critical path, production can handle it.

Results

Offline evaluation uses "unordered recall": the model generates several embeddings at once, and a target counts as a hit if any one of them ranks it in the top 10 among 1 million random Pins. All models are trained only with the pretraining procedure, without fine-tuning:

TIGER comes last, consistent with the code-collision problem of Semantic IDs at this scale; HSTU is close to PinRec on the home feed and related recommendations, but only half as good on search.

The ablation is more informative (change relative to the best configuration):

Generating for target behaviors contributes two to five times as much as fine-tuning, and impression negatives barely matter. In multi-surface retrieval, then, "telling the model which behavior you want" is worth more than "adapting to each surface separately". The rarer the behavior, the stronger the condition's effect: for clicking out to buy products in search, recall evaluated on that behavior alone rises 16%.

Multi-step generation also pays off a lot. Compared with generating a single step, 16 steps raise recall by 71.4% on related recommendations, 8.8% on the home feed and 11.1% on search. Related recommendations gain the most, which makes sense: users there click from one item to the next, and their interest drifts as they browse.

In online A/B tests, PinRec is added as one retrieval source and ranking stays unchanged. On the home feed, the version generating for target behaviors raises home-feed grid clicks by 4.01%, against only 1.87% for the unconditioned version, which means the condition roughly doubles the online gain. Sessions with at least one action rise 0.21%.

In search, saves rise 3.88% and shares 5.30%. In related recommendations, time spent rises 0.38%; and without touching search, sessions in search with at least one positive action such as a save or long click also grow by 0.42%, showing that better related recommendations lead users into search. Using a user's output embedding to search the ad corpus directly, with no ad training at all, even lowers cost per ad conversion by 1.83%.

Where I think it falls short

First, the baseline comparison favors itself. In the offline table every model is trained with PinRec's pretraining procedure, and HSTU does not use its original sampling and ranking design; its 0.179 on search is hard to accept as HSTU's real level. Also, unordered recall counts a hit if any of several vectors hits, and PinRec generates several embeddings at once. If the baselines output just one vector, part of the gap between 0.625 and 0.461 comes from "taking more shots".

Second, scaling up does not help. Growing from 100 million parameters to GPT-2 medium and large sizes actually lowers recall slightly, by 0.8% and 0.9%; only at the roughly 1-billion-parameter XL (the largest GPT-2 tier) does it rise 2.2%, and that is too expensive to serve. This does not fit well with the claim that recommender models also follow scaling laws, and suggests the gains come mainly from the design of conditions and training data rather than model capacity.

Third, the absolute size of the online gains is small, and they are stacked on top of many existing retrieval sources. Home-feed sessions with at least one action rise only 0.21%. Latency is 3 to 4 times that of a two-tower model and requires GPUs; for systems without a parallel retrieval architecture, or where retrieval runs serially on the critical path, the math has to be redone.

How a recommendation team could try it

1. First add a condition vector to your existing sequential retrieval model; this is the cheapest step. In training, feed the target behavior type (click, bookmark, purchase) into the output layer as a learnable vector, and at inference fill it in according to the business goal. Compare offline recall evaluated per behavior, and check whether rare behaviors improve clearly.
2. If you have several surfaces, then try "site-wide pretraining plus surface fine-tuning", with shown-but-not-engaged items as negatives. Do not treat impressions as positives; in the paper this clearly lowers recall.
3. If you have capacity, add multi-step generation, together with embedding merging and slot allocation, or retrieval will be full of duplicates. Start with 4 steps; continuous-browsing surfaces like related recommendations gain the most.
4. Measure latency before launch: the version generating for target behaviors has a median latency of about 40ms, so make sure it runs in parallel with other retrieval sources rather than serially on the critical path.

Bottom line

The most valuable thing in multi-surface generative retrieval is not the unified model but a condition on the target behavior: with the same history, changing the condition produces candidates for different purposes.