Page MenuHomePhabricator

Investigate current MLR models for Search and identify improvements
Closed, ResolvedPublic8 Estimated Story Points

Description

Current MLR on Search could probably be improved significantly by reviewing the current training process.

Problem statement

MLR models are trained regularly but have not been deployed recently. While offline evaluation metrics indicate potential improvements through redeploying these models, we must ensure that the current training data is free from bias.

Our working assumption is that a large number of queries in the training set is "easy" for the model to predict an interaction for (and might cause overfit). Experimental results across large wikis show that,
depending on the heuristic used to define "easy," roughly 20% of the queries can be classified as such.

Our hypothesis is that MLR can be improved by learning from more complex queries.

The goal of this task is to evaluate potential improvements by training models that incorporate knowledge of query complexity, including establishing a meaningful definition of a "easy query".

Approach

We train a model with knowledge of easy queries and evaluate its performance (offline) compared to the baseline. Our approach can be broken down into three steps:

  1. Create a dataset of (query, page) pairs to compute heuristics for labelling "easy queries".
  1. Implement heuristics to estimate whether a query is easy or not.
    • A query is considered easy if there is high similarity between the query and the page title. Additionally, we can train a mixture of experts to classify easy queries and use their predictions to normalize label assignments (e.g., how confident we are that a query is easy).
    • We compare several heuristics for (query, title) similarity, including exact match, cosine, Jaccard, and Levenshtein metrics. The assumption that "we have a lot of easy queries" seems valid, although the value of "a lot" depends on the similarity metric applied. We follow a data-driven approach to identify cutoff values for labeling a query as easy.
  2. Train XGBoost models with knowledge of easy queries and compare the results with baseline models.
    • MLR models are trained on a dataset consisting (among other features) of queries performed by users and the resulting page interactions. Our approach involves adding a new dimension to the training data to label a query as "easy" and using this information during training for instance weighting in the construction of the training DMatrix (e.g. we want to "penalize" easy queries). Other methods can be explored (e.g. cost sensitive learning), if the general approach proves to be viable.
    • This step requires reproducing (locally, on a stat host) Mjolnir's training logic.

Note that steps 2–3 are iterative. "Easy query" is a hyperparameter that we may need to tune to find an optimal value after several training and evaluation rounds.

Next Steps

This work aims to determine whether there are immediate performance gains with models tuned to account for easy queries.
Team consultation on the outcomes of offline model evaluation will decide whether we should proceed to implement these changes in Mjolnir.
If results are positive, we will move to an A/B testing phase and further testing to identify potential regressions
(e.g., improved performance on complex queries at the cost of poor performance on easy queries).

AC

  • documented understanding of the current limitation and potential improvements to MLR training
  • hypothesis describing the user impact of potential improvements

Event Timeline

TJones set the point value for this task to 8.Jan 6 2025, 4:54 PM
TJones moved this task from Incoming to In Progress on the Discovery-Search (Current work) board.
gmodena updated the task description. (Show Details)

I've been experimenting with a e2e training and evaluation pipeline, using heuristics to label ane "penalize" easy queries at training time.

tlldr: Initial result show no significant difference when training with instance re-weighting vs a vanilla baseline.

Here's some metrics, computed on enwiki. I trained xgboost without parameter tuning and these settings:

params = {
    "objective": "rank:pairwise", 
    "eta": 0.1,                   
    "gamma": 1.0,                 
    "min_child_weight": 0.1,
    "max_depth": 3,
    "eval_metric": "ndcg",
}

To goal was to build a simple model as possible, and measure the impact of re-weighting training instances to account for easy queries.

Data was collected in January 2025. Training and evaluation on 792548 queries was performed with 5 fold grouped cross validation. Group assignment si determined by cluster id (as generated by the label propagation DBN). ~3% of the queries are exact matches with the page title that was clicked on.

Results below are averages accorss the 5 folds.

Baseline

Metrics for easy queries:

  • mean_ndcg 0.999760
  • count 182944.000000
  • average_predicted_score 0.886580
  • average_relevance 0.832375

Metrics for hard queries:

  • mean_ndcg 0.987442
  • count 609604.000000
  • average_predicted_score 0.430186
  • average_relevance 0.670501
With query weighting (easy queries are penalized)

Metrics for easy queries:

  • mean_ndcg 0.999736
  • count 182944.000000
  • average_predicted_score 0.887819
  • average_relevance 0.832375

Metrics for hard queries:

  • mean_ndcg 0.987407
  • count 609604.000000
  • average_predicted_score 0.430755
  • average_relevance 0.670501

Results seems consistend across wiki and sample sizes. Changing "easy query" heuristic did not seem to impact the overall results.

Follow-up from a discussion we had at the offsite. As reported in the notebook (see linked MR),
there is no apparent benefit in trying to model easy vs. hard queries. Mjolnir models already perform well for both classes.
The results seem to agree with the A/B test that @EBernhardson carried out last quarter.

We decided to proceed as follows:

  • Deploy a recent Mjolnir model.
  • Run an A/B test for a week.
  • Document what would be required to automate deployments.

In terms of model improvement, a research area to explore would be investigating abandoned queries. This work, however, is orthogonal to model deployments.