I believe there are two main lines of work derived from this task: (1) Improve the model per-se (2) Improve how often and quickly can the model be re-trained based on some input. Expanding on these two below.

(1) Improve the model

Potential approaches (1), (2) & probably (3) require the model to be re-trained based on new input. All types of new input we are exploring for the model require code changes on it: new hard-coded rule, Wikidata entity deemed useful, or "Never link" word. Research folks feedback would be appreciated to make sure the new rules or wikidata entities we want to introduce make sense across wikis/languages. Aside from that the changes seem simple enough to be handled between Growth/Research. The "Never link" work input is a bit more tricky as it needs to be applied on a per language-model basis. I believe that's currently possible as we have 1 model per language but I'm unsure where in the model that should be done. In any case we would need to make the wiki configuration available to the model training process which is not currently the case.

Note on the "Never link" words approach: we could filter these words downstream in the mwaddlink API call or in GrowthExperiments. This seems not very efficient but it's cheap to implement.

(2) Improve how often and quickly can the model be re-trained based on some input

Whatever changes we make to the model it will need re-training and deployment (there's a good summary of steps that involves in T388258#10707714). The main problem is that it is currently a manual operation which has to be done per language, and some languages produce errors (see T387556). In my opinion this is a blocker for allowing the model to be re-trained on whatever "dynamic" data, eg: "Never link" words community configured or rejection data. The relevant task to unblock this would be T388258: Make airflow-dag for addalink training pipeline output compatible with deployed model. Once that's resolved we can consider allowing such kinds of inputs into the model.

Last, even with an airflow-dag driven model, we would need to think about how to invalidate and re-populate the recommendations pool, as things are now, it can take time for the changes made in the model to be visible in the recommendations feed. More details on this coming.

Posting some thoughts from a review we had with @Sgs around the spike suggestions.

(1) Improve the model

This approach would be suitable for getting the Add Link improvements out to enwiki faster but wouldn't scale across other wikis since the for the reasons posted in the findings and mostly because the model has to be manually ran every time some other "Never Link" criteria is defined on a wiki. We could move a head with this approach and improve the model for enwiki to allow us to offer Add a Link to more enwiki users but decide not to use this approach to scale for other wikis because of the degree of manual labour involved.

(2) Improve how often and quickly can the model be re-trained based on some input

This approach of automating training across different wikis is definitely the most ideal, but would consume some of time in rolling out the Add Link improvements within the hypothesis time frame, as it relies on training automation work in T388258: Make airflow-dag for addalink training pipeline output compatible with deployed model, as well as reworking how we intend to serve recommendations since training output would now be served differently. Rather than try to tackle this within a sprint or two. This approach would be better served as it's own hypothesis around optimising link recommendation training and serving for scale to other Wikis with little to no manual involvement.