Type “backpack” into a shop, and two buyers can mean completely different things. One wants a laptop bag. The other wants a hiking pack. That’s the example Shopify Engineering used when it published the work behind SID-LLM, the system it uses to generate product identifiers for search and recommendations.
Shuying Sun, Juhana Kangaspunta and Khalil Hajji wrote the 11 November engineering post. A companion technical report on arXiv fills in the methods and the numbers. The two documents show Shopify training search and recommendations on one product language, then serving each task with its own production model. The catalogue, in Shopify’s telling, runs to billions of products, and the retrieval still has to fit a live request.
A three-token language for products
A raw catalogue number will get you a database row, and that’s about it. The digits don’t describe the product. SID-LLM gives each item a Semantic ID instead: three tokens drawn from three codebooks of 8,192 entries each. Shopify fitted those codebooks with residual-quantised k-means on its own 768-dimensional product embeddings, using the top 25 million products by gross merchandise volume.
Related products tend to share early tokens and split later. A laptop backpack and a hiking pack can start with the same prefix and still finish on different codes. The engineering post walks through a real catalogue sample: vests and gilets share the prefix 6001; one branch groups padded gilets and then grey padded designs, while another groups workwear-style gilets and indigo denim vests. Those codes come from embeddings. They aren’t hand-assigned category or colour labels.
Joint training, then two production stacks
Search and recommendations were jointly pretrained on that shared ID language. In production they go their own ways. Search uses a multi-token prediction model plus a lightweight ranker. Recommendations use an autoregressive 2.6 billion-parameter LFM2 model from Liquid AI, then resolve an ID to a product by scoring the joint probability of the code and the item. When Shopify picked that backbone, it compared LFM2-2.6B with Qwen3 models at 1.7 billion and 14 billion parameters.
A single distilled student that would cover both tasks is still experimental.
What Shopify reports on the Shop home feed
The paper’s Shop-app home-feed A/B test is the one with published online lifts. After a Dunnett correction, SID-LLM showed statistically significant relative gains:
| Metric | Relative lift |
|---|---|
| Orders | +7.95% |
| Converters | +8.60% |
| Conversion rate | +9.85% |
Offline, the engineering post says the model adds 2.65 percentage points of Incremental Pool Recall when it’s added to the recommendation production system, and that it’s also Shopify’s strongest standalone candidate generator. In the paper, that standalone result is 2.65 points. A recent-engagement baseline sits at 1.64, so SID-LLM is 61% higher, and an HSTU baseline sits at 0.78.
Search quality offline
Search results are reported as offline OneDCG@10, a variant of NDCG that always normalises against a perfect ten. With the generative model added to the current production system, the overall score moves from 30.6 to 32.7, and the personalised-query score from 33.0 to 35.7. About a quarter of queries improved on net in the top 10. Run by itself, the generative model scores 28.5 overall and 33.6 on personalised queries.
| Search configuration | Overall | Personalised |
|---|---|---|
| Production system without the generative model | 30.6 | 33.0 |
| Production system with the generative model | 32.7 | 35.7 |
| Generative model only | 28.5 | 33.6 |
A/B tests, the paper says, were strong enough to put SID-LLM into the search stack. It still doesn’t publish an online percentage lift for search of the kind it gives for the home feed. The engineering post does add that a later reinforcement-learning stage on the search model was worth 1.5 points of OneDCG@10. And when the team upsampled discovery events in training and compressed long purchase histories, discovery recall rose by about 10 to 15% relative, with overall recall up about 2%.
Collisions and constraint checks
A generated code still isn’t a listing. The paper says 78.9% of predicted IDs were shared by more than one product. Decoding with the joint probability of ID and product improved Recall@50 by 15.8% against a baseline that just picked one product per ID.
The model also has to emit codes that map to eligible products. Shopify constrains decoding with an index of valid Semantic ID paths, held as a GPU representation of the catalogue’s prefix tree. The engineering post says that constraint overhead fell from more than 50 milliseconds to about one millisecond. The paper starts from a range of 18 to 33 milliseconds and lands on the same one-millisecond figure after the change. Requests can also carry their own eligibility filters, such as the buyer’s market, and Shopify says it will describe that metadata routing in a follow-up piece.
Where the system runs
Shopify says SID-LLM already serves merchant storefronts, the Shop app, and a Catalog API aimed at conversational commerce and AI agents. “Respecting the buyer’s privacy choices” appears in the paper as a future direction, not as a practice measured in this work.
The equal-contribution authors of the technical report are Juhana Kangaspunta, Khalil Hajji and Darshan Fofadiya, writing with colleagues at Shopify and Liquid AI. Shopify Engineering introduced the work with the backpack example:
Two buyers search for “backpack.” One needs a laptop bag. The other needs a hiking pack. How do you retrieve the right products for each, across a catalog of billions, and make it fast enough for a live request?
— Shopify Engineering (@ShopifyEng) November 11, 2026
Here’s how we trained search and recommendation together.
Discover more from Sulat AI & Tech News
Subscribe to get the latest posts sent to your email.
