Just flagging T377124 as similar in case there are any insights there that are helpful.

The raw results provided directly by the articlecountry: feature are a good starting point for our recommendation API to provide appropriate translation suggestions. On a first look, the raw results can seem a bit odd:

Yet those raw results from articlecountry: are accurate in the sense that the evaluation criteria for the model itself, as I understand, is based on accuracy: the results have something to do with the country in query. The raw results we get with a basic query are sorted by popularity by default, so we see popular articles with a minor connection to the country populating the top results.

In order to get a more appropriate set of recommendations, there are a couple of actions we can take. First in our recommendation API we can query with gsrqiprofile=classic_noboostlinks to get results not sorted by popularity as this gives us more general results that are closer to what we expect (popular articles can add some distortion to our results). Likewise we can pair with gsrqiprofile=classic_noboostlinks with gsrsort=random to randomize results.

In addition, we could also do an extra query for a set of results to look at the weighted_tags ( as offered by this internal module). The weight value provided goes from 0 to 1000, so looking at these values we can choose items that are closer to 1000 to increase our confidence on of the recommendations. See the same results from table above with weighted_tag value for more context:

We could discard Albert Einstein or James Joyce or Richard Scarry, for example, in favor of ones with higher scores. This additional query would add an extra cost which would have to be considered during implementation to understand if it's really worth it.

All in all, it seems that querying with gsrqiprofile=classic_noboostlinks&gsrsort=random and filtering out items with lower weighted tag values can allow the recommendation API to provide appropriate suggestions.

A quick note on the cirrusdoc API prop, it's a debugging interface for the search team and should not be used in a production setting.

Thanks Stephane, indeed it's stated as such in the documentation. I believe even without the weighted_tags perspective we still have enough for T391230. If we all agree this is the case, we can move this ticket (T388942) to the next logical column