Cold Start
User cold start vs item cold start — content features and exploration
Collaborative filtering — the engine of most recommenders — learns from interaction history: "users who liked X also liked Y." That engine has a structural blind spot: it can say nothing about an entity it has never seen interact. This is the cold-start problem, and it has two distinct faces that need different fixes.
User cold start: a brand-new user has no history to collaborate on. You can't retrieve "items similar to what they liked" because they've liked nothing. The fixes ladder from cheap to smart:
- Fall back to popularity / trending (globally or by segment) as a floor. - Use whatever context you do have — device, language, location, time of day, referral source. - Run a lightweight onboarding (pick a few interests) to seed a profile. - Update a real-time user embedding aggressively from the first few interactions, so the system personalizes within the session rather than waiting for a nightly retrain. TikTok's fast first-session personalization is this last move done well.
Item cold start: a brand-new item has no interactions, so collaborative signal can't place it. A pure two-tower model trained on interaction IDs literally has no embedding for an item nobody has touched. The fix is to build the item tower on content features (text, image, audio, category, creator) rather than a learned per-item ID embedding — so a new item gets a reasonable embedding *from its content* on day one, before any interactions exist. This is why content features aren't just a nice-to-have; they're what makes new items recommendable at all.
Exploration is the bridge that turns cold items warm. Even with content features, the system's estimate of a new item is uncertain, and a pure-exploitation ranker (always show the current best predicted item) will rarely surface it — so it never gathers the interaction data that would improve the estimate, a self-reinforcing starvation. Exploration (ε-greedy, or better, uncertainty-aware bandits like Thompson sampling / UCB) deliberately shows uncertain items to gather signal. It trades a little short-term engagement to break that starvation loop — and it's the explicit cost that keeps the long tail and new content alive.
Key points
- Two distinct problems, two fixes. User cold start (no history for a new user) is solved with popularity fallbacks, context, onboarding, and aggressive real-time embedding updates. Item cold start (no interactions for a new item) is solved by building the item tower on content features rather than a learned per-item ID embedding.
- Content features are what make a new item recommendable at all. An ID-embedding two-tower has no vector for an unseen item; content features (text/image/audio/category/creator) give it a reasonable embedding on day one before any interaction exists.
- Exploration is non-optional for cold items. A pure-exploitation ranker rarely surfaces uncertain new items, so they never accumulate the data that would improve their estimate — a self-reinforcing starvation. Uncertainty-aware exploration (Thompson sampling/UCB, or ε-greedy) deliberately gathers signal, trading short-term engagement to keep the tail and new content alive.
- Real-time personalization narrows the user cold-start window. Updating the user embedding from the first few in-session signals personalizes within the session instead of waiting for a nightly retrain — the difference between a good and a generic first session.
Cold start has two faces: a new *user* (no history → popularity, context, onboarding, and fast real-time embedding updates) and a new *item* (no interactions → build the item tower on content features so it's embeddable on day one). Exploration is the bridge that turns cold items warm — deliberately surfacing uncertain items so they gather the signal a pure-exploitation ranker would never let them earn.
Recap
- Cold start = collaborative filtering's structural blind spot: it learns from interaction history, so it can say nothing about an entity it has never seen interact. Two distinct faces need different fixes.
- User cold start (new user, no history): ladder of fixes — popularity/segment fallback (floor) → available context (device, language, location, time) → lightweight onboarding → aggressive real-time embedding updates from the first few signals so personalization happens within the session, not after a nightly retrain.
- Item cold start (new item, no interactions): a pure ID-embedding two-tower has *no vector* for an unseen item. Build the item tower on content features (text/image/audio/category/creator) so a new item is embeddable on day one — content features are what make new items recommendable at all.
- Exploration bridges cold → warm: even with content features, a new item's estimate is uncertain and a pure-exploitation ranker rarely surfaces it, so it never gathers improving signal (self-reinforcing starvation). Uncertainty-aware exploration (Thompson/UCB, or ε-greedy) trades a little engagement to break that starvation loop and keep the tail alive.
Check your understanding
Q1. A pure ID-embedding two-tower recommender cannot recommend items uploaded in the last hour at all. What is the root cause and the correct architectural fix?
- A) The ANN index (HNSW) hasn't rebuilt its graph since the new upload; forcing an hourly rebuild job (instead of the current nightly one) will make new items appear in results.
- B) Item cold start — a learned per-item ID embedding requires interactions; fix by building the item tower on content features instead.
- C) The user tower's cached embeddings are stale relative to the item catalog; retrain the user tower nightly so it learns to score newly uploaded items.
- D) Nothing is architecturally wrong — new items should simply be excluded from retrieval until they accumulate 100+ logged interactions, at which point the ID embedding becomes trainable.
Q2. Your platform adds content features so new items *can* be embedded, yet new items still almost never get shown. Why, and what's the fix?
- A) The content features are low quality — the image/text encoder was trained on a mismatched domain; fine-tune it end-to-end on in-catalog product photos and descriptions for roughly 3 epochs and the problem resolves on its own.
- B) A pure-exploitation ranker always shows its best-predicted item, so a new item's uncertain estimate never wins; add exploration (Thompson sampling/UCB, ε-greedy) to surface it.
- C) The ranking model's MLP needs roughly 2-3x more layers to properly weight content embeddings against interaction-based ones; deepen the tower and retrain the whole stack from scratch.
- D) New items should be hard-coded into the top 3 slots of every user's session for their first 48 hours after upload, regardless of predicted relevance, purely to guarantee visibility.
Q3. Select the *two* approaches that best handle a brand-new *user* who has zero interaction history.
- A) Combine a popularity/segment fallback as a floor with available context (device, language, location, time of day) to seed a reasonable ranking before any interaction exists.
- B) Update a real-time user embedding aggressively from the first few in-session interactions, so personalization improves within the session rather than waiting on a nightly retrain.
- C) Refuse to personalize at all and show a fixed editorial list until the next scheduled nightly retrain incorporates whatever history the user has accumulated by then.
- D) Train a dedicated neural network per new user via online gradient descent triggered by their very first click, discarding the shared collaborative-filtering model entirely.
Try it interactively
ML Systems Lab is a free interview-prep platform for ML engineers — work through the full interactive module, quizzes, and drills.
Open ML Systems Lab →