Two-stage recommender

Why two stages

Retrieval narrows the movie catalog to a candidate set. Ranking then applies additional user and movie signals to that shortlist, rather than scoring the entire catalog with the ranker.

This separation gives each stage a distinct job: retrieval determines which movies get considered, while learning-to-rank determines their order.

From rating history to recommendations

The embedding pipeline combines movie titles and genres into text, encodes it with a sentence-embedding model and normalizes the vectors. These vectors provide the representation used for candidate search.

At serving time, a user's ratings weight a combination of movie vectors into a user vector. That turns rating history into a query over the same embedding space.

OpenSearch retrieves candidates from that query. The API builds user and movie feature vectors for the candidates, then obtains scores from an XGBoost learning-to-rank model.

Score fusion can blend the ranker's score with the retrieval score before sorting. Its adjustable weighting controls how much each signal contributes to the final order.

For an unknown user, the API takes a popularity-based fallback path. This provides recommendations without treating missing rating history as evidence of personal taste.

Quality depends on both stages

Candidate recall sets the ceiling

Separating retrieval from ranking limits the second stage to the returned candidates, so the ranker can't recover a useful movie that retrieval missed.

Quality evaluation should therefore measure candidate recall separately from ordering quality. A strong ordering of an incomplete shortlist can still miss the movies that matter to a user.

Score fusion needs comparable scales

Retrieval and ranking scores come from different models. Their score scales affect the blend: changing a weight alone doesn't establish a balanced contribution from each signal.

The fusion choice needs validation against ranking alone on the same candidates. Score comparability remains an open evaluation question, rather than an assumed property of the blend.

Training and evaluation design

The training interface groups examples by user, so the ranker learns ordering within each user's group. XGBoost is configured with a pairwise learning objective and an NDCG evaluation metric: the objective guides training, while the metric monitors ordering quality.

A separate validation dataset can be supplied to monitor those grouped rankings. A useful evaluation would test candidate recall, reranking and score fusion under a consistent split and candidate-selection procedure.

That design still needs checks for evaluation leakage, including whether held-out ratings influence the user vector or training features. Accepting a validation dataset doesn't by itself establish a leakage-free split.

This is an ML prototype; recommendation quality, serving latency and user impact remain unmeasured here, and production deployment is outside its demonstrated scope.