| name | choose-recsys-approach |
| description | Choose the recommendation approach — popularity/heuristic baseline, collaborative filtering, content-based, hybrid, two-tower/embedding retrieval, or sequential — from data volume, sparsity, cold-start severity, latency, and interpretability. Use when starting a recsys or deciding whether to add model complexity. |
Skill: Choose Recsys Approach
Match the recommendation approach to the data and constraints, not to the newest paper. The wrong approach either wastes months on a model the data can't support or leaves easy wins on the table.
When to use
- Starting a recommender from scratch.
- Deciding whether a fancier model (matrix factorization, two-tower, sequential) is justified over what you have.
- Re-evaluating an approach that underperforms.
Steps
- Define the recommendation task. Top-N item recommendation, related-items, next-item (sequential), or personalized ranking of a fixed set? Different tasks favor different approaches.
- Measure the data. Interaction volume, user/item counts, sparsity, implicit vs explicit feedback, and how much side information (item content, user attributes) exists. Traverse
../../knowledge/recsys-approach-decision-tree.md.
- Establish the baseline to beat. Popularity / recently-popular / "customers who bought X" co-occurrence. This is the bar; ship it first and measure everything against it.
- Pick the approach:
- Content-based when cold-start is severe or interactions are thin but item features are rich.
- Collaborative filtering (item-item, matrix factorization) when interactions are dense enough and side info is weak.
- Hybrid when you have both signals (the common production answer).
- Two-tower / embedding retrieval at large catalog scale with enough interactions and a latency budget that needs ANN retrieval.
- Sequential when order/session matters (next-item, session-based).
- State what you are NOT building yet and why (e.g. "no two-tower until we have >X interactions and an ANN serving path").
- Set the latency and interpretability constraints — they can veto an approach before modeling starts.
Anti-patterns
- Reaching for a deep model on sparse data that can't support it.
- No popularity baseline, so no one can tell if the fancy model is actually better.
- Ignoring cold-start until launch, then discovering the model can't serve new users/items.
- Choosing an approach whose serving latency the product can't afford.
- Treating retrieval and ranking as one model instead of a two-stage problem.
Output
An approach recommendation: task → measured data → baseline → chosen approach (+ what's excluded and why) → latency/interpretability constraints → the two-stage pipeline sketch. Feed it to recsys-implementation-engineer and the recsys-design-doc.
