Content-Based Filtering for Recommendation Service (aka User-based Model)

Content-Based Filtering (CBF) recommends items whose attributes resemble items a user has already engaged with. Instead of learning from the behavior of other users, it builds a profile of the target user purely from the features of the items in that user’s history.

The core hypothesis: if you liked items with certain attributes, you will like other items that share those attributes. A user who watched several documentaries by a particular director is shown that director’s other films.

This makes CBF a per-user model: each user has an independent profile, and recommendations never depend on the existence of a user community.

How It Works (The Math)

CBF has three stages: item representation, profile construction, and scoring.

1. Item representation

Each item i is converted to a feature vector vᵢ. Common encodings:

• TF-IDF (Term Frequency–Inverse Document Frequency) over text (titles, descriptions, tags). For term t in document d:

  tfidf(t, d) = tf(t, d) · log(N / df(t))

  where N is the corpus size and df(t) the number of items containing t.

• One-hot / multi-hot for categorical metadata (genre, brand, language).
• Dense embeddings from a pretrained encoder (e.g., a text transformer for descriptions, a CNN — Convolutional Neural Network — or ViT — Vision Transformer — for images, audio embeddings for music).

2. User profile construction

The user profile pᵤ is an aggregate of the vectors of items the user interacted with, often weighted by rating or engagement:

pᵤ = ( Σ_{i ∈ Hᵤ} wᵤᵢ · vᵢ ) / ( Σ_{i ∈ Hᵤ} wᵤᵢ )

where Hᵤ is the user’s interaction history and wᵤᵢ the weight (rating, watch fraction, recency decay).

3. Scoring

Candidate items are ranked by similarity to the profile, typically cosine similarity:

score(u, i) = cos(pᵤ, vᵢ) = (pᵤ · vᵢ) / (‖pᵤ‖ · ‖vᵢ‖)

Alternatively, a supervised classifier/regressor (logistic regression, gradient-boosted trees) is trained per user or globally with the user profile as features, predicting the probability of a positive interaction.

Requirements

To deploy CBF you need:

• Rich, structured item features. The quality ceiling of CBF is set by feature quality. Sparse or missing metadata caps performance.
• A feature extraction pipeline. Text cleaning, tokenization, embedding inference, and normalization must run on every new item before it can be recommended.
• Per-user history storage. Even a short interaction history is enough to seed a profile.
• A similarity / retrieval index. For large catalogs, an Approximate Nearest Neighbor (ANN) index — e.g., FAISS (Facebook AI Similarity Search), ScaNN (Scalable Nearest Neighbors), or HNSW (Hierarchical Navigable Small World) — over item vectors enables sub-linear retrieval.
• No dependency on other users, which is why CBF is attractive for cold-start communities and privacy-sensitive contexts.

Simplified Architecture

Reference Architecture

Reference Architecture (with Technology Stack)

The same flow mapped onto common production technologies — Kafka for event streaming, Spark for batch feature jobs, Redis for the online profile store, and FAISS/Milvus for vector retrieval.

PRO

Signals & Features

The most common feature families are item text (titles, descriptions, transcripts), structured metadata (genre, category, brand, price band, language), media embeddings (image/audio/video), and provenance signals (creator, publication date). On the user side, the only required signal is the item-interaction history, optionally enriched with explicit ratings and per-interaction weights such as dwell time or watch fraction.

Training & Serving Considerations

CBF often has no global training step when using pure similarity — profiles are computed on the fly. When a supervised model is layered on top (e.g., logistic regression predicting click probability from profile-item interaction features), training is standard offline batch learning with periodic refresh.

Serving cost is dominated by ANN retrieval and feature freshness. New items become recommendable as soon as their vectors are indexed, which is why CBF handles item cold-start gracefully — a key contrast with collaborative filtering.

Evaluation

Offline, CBF (Content-Based Filtering) is evaluated with ranking metrics: precision@k, recall@k, MAP (Mean Average Precision), and NDCG (Normalized Discounted Cumulative Gain) on held-out interactions. Because over-specialization is the dominant failure mode, teams also track catalog coverage, intra-list diversity, and novelty to detect filter-bubble behavior. Online, the decisive signals are A/B-tested click-through rate, engagement depth, and long-term retention.

Strengths & Weaknesses

Strengths: works for new users with even a little history; no dependence on a user community (no user cold-start); naturally handles new items; transparent and explainable (“recommended because it shares X with something you liked”).

Weaknesses: prone to over-specialization / filter bubbles — it rarely surfaces genuinely novel interests; quality is bounded by feature richness and requires significant feature-engineering investment; it cannot capture “users like you also enjoyed…” signals that drive serendipity.

When to Use It

Reach for content-based filtering when item metadata is rich and well-structured, when the catalog turns over quickly (news, job postings, listings) so item cold-start matters, when you cannot rely on cross-user data for privacy reasons, or as the content arm of a hybrid system that compensates for collaborative filtering’s cold-start gap.