User:EBernhardson (WMF)/Notes/Accept-Language

November 2015 - Questions and comments are welcome on the talk page


 * This is currently a work in progress and is not complete*

Hypothesis
Using the first non-English Accept-Language HTTP header will provide a good proxy for the language the query is in when the query returns no results against the wiki it was already run against. Further that this is a better proxy than the existing elasticsearch langdetect plugin.

Final Results
180,298 full text desktop queries to enwiki for the hour 28,929 filtered to those with a usable non-English accept-language header 2,015 number of those queries that give zero results 395 number of those queries which convert to non-zero results via accept-language 21% conversion rate of zero result with usable accept-language header to non-zero result

21,022 Estimated number of full text desktop queries to enwiki for the hour that have zero results 1.9% conversion rate from zero result to having result for full data set

Comparison to language detector: 2,015 number of zero result queries from above 1,429 number of those that detect to non-english 128 number of those which convert to non-zero results via language detection 9% conversation rate of zero result with usable accept-language header to non-zero result via lang-detect

Generally this looks to imply we should prefer the accept-language header over language detection for choosing a second wiki to query. We will still need to use language detection as only 16% of queries had a usable accept-language header.

Caveats
This only analyzed traffic to enwiki. It is likely if we ran this for traffic going to ruwiki or zhwiki we would get slightly different results. Additionally this only considers desktop search. Query rewriting for the API is not done by default, but is instead hidden behind a feature flag. As such even if we could have an effect on API requests most of them do not enable the rewrite flag and will not be affected. Note that the API makes up something like 75% of all search requests.

Additionally this data set, once filtered to queries with non-English accept headers, has a zero result rate of only 7%. This is 40% lower ((11.6-6.9)/11.6) than the overall zero result rate recorded in our CirrusSearchRequestSet logs for the same hour. Not sure if this means anything, but seems like a large variance.

Extract one hour worth of desktop full text searches from webrequest logs
Started by taking an hour worth of queries + accept language headers for enwiki from hive wmf.webrequests table using the following query. The specific day and hour to work with was arbitrarily chosen. This gives us a set of 180,298 queries to start with, which we will use to calculate the expected change to zero result rate. This feels much too low to be the total number of full text queries on enwiki for that hour, but is probably a reasonable number to run this test against.

Filter out requests with only English or invalid accept-language
The result of the above query was then run through the following php script to filter out queries that had an invalid accept-language header recorded, or only included English. Run against the above set of 180,298 queries we end up with 28,929 queries that could be affected. This means around 16% of our search queries to enwiki contain a non-English Accept-Language header.

Run the queries through enwiki to find which are zero result queries
These queries are then run against the enwiki index we have in the hypothesis-testing cluster to see which are zero result queries. This was done with the following command line:

The results of this were filtered down to only the zero result queries, giving only 2,015 queries to test our original hypothesis against. Note that 2,015 out of 28,929 means this set had a zero result rate of 6.9% which is much lower than expected. I queried the same hour from the CirrusSearchRequestSet in hive and came up with a ZRR of 11.7% (see appendix for the query used).

Sort zero result queries into a bucket per target wiki
For the next step I needed a map from the languages to their wikis. This was sourced from this gerrit patch.

These queries were then separated out into a file per wiki using the following php script.

A quick look at which wikis the queries were assigned to was done with

This gives the following top 20 targets of queries from enwiki in the analyzed hour: 545 zhwiki 329 kowiki 241 svwiki 220 eswiki 114 jawiki 53 dewiki 51 ruwiki 50 arwiki 45 thwiki 44 ptwiki 43 frwiki 33 hiwiki 32 idwiki 19 viwiki 17 mswiki 14 hewiki 13 plwiki 12 nlwiki 11 fiwiki 10 trwiki

I don't have the resources available to run the full 180k query set to calculate it's ZRR rate, but we can estimate using. This gives a ZRR of 11.7%, which suggests 21k of the 180k queries would have zero results. We were able to convert 395 of those 21k queries into results for a conversion rate of 1.9%

Search target wikis
Now that we have all the zero result queries that have a usable accept-language header broken out into files per wiki we can run them with the following:

These can then be processed to get the new zero result rate:

Which results in: zhwiki.results total: 545 non-zero percent: .216 kowiki.results total: 329 non-zero percent: .079 svwiki.results total: 241 non-zero percent: .522 eswiki.results total: 220 non-zero percent: .222 jawiki.results total: 114 non-zero percent: .140 dewiki.results total: 53 non-zero percent: .207 ruwiki.results total: 51 non-zero percent: .235 arwiki.results total: 50 non-zero percent: .120 thwiki.results total: 45 non-zero percent: .066 ptwiki.results total: 44 non-zero percent: .136 frwiki.results total: 43 non-zero percent: .162 hiwiki.results total: 33 non-zero percent: 0 idwiki.results total: 32 non-zero percent: .281 viwiki.results total: 19 non-zero percent: 0 mswiki.results total: 17 non-zero percent: .058 hewiki.results total: 14 non-zero percent: 0 plwiki.results total: 13 non-zero percent: .076 nlwiki.results total: 12 non-zero percent: .083 fiwiki.results total: 11 non-zero percent: .090 trwiki.results total: 10 non-zero percent: .200

Across the top 20 wikis there are 1896 queries, and 395 were able to find results. This gives an overall 20.8% conversion rate. Considering the full set of queries, including those against languages we did not run due to being in the long tail, we have 395/2011 = 19.6%.

Compare against language detection
To determine if language detection does a better job than the accept-language header we take the set of 1896 queries that were made above and re-bucket them based on language detection. That was done with the following code:

It was run as follows:

Re-running the same analysis as above for per-wiki ZRR we get: ptwiki.results total: 193 non-zero percent: .015 itwiki.results total: 149 non-zero percent: .120 rowiki.results total: 148 non-zero percent: .081 dewiki.results total: 143 non-zero percent: .118 tlwiki.results total: 87 non-zero percent: 0 frwiki.results total: 67 non-zero percent: .119 eswiki.results total: 65 non-zero percent: .307 sqwiki.results total: 57 non-zero percent: 0 idwiki.results total: 53 non-zero percent: .207 huwiki.results total: 47 non-zero percent: 0 svwiki.results total: 40 non-zero percent: .350 ltwiki.results total: 38 non-zero percent: 0 nowiki.results total: 36 non-zero percent: .138 zhwiki.results total: 31 non-zero percent: .129 dawiki.results total: 31 non-zero percent: .032 hrwiki.results total: 29 non-zero percent: .034 fiwiki.results total: 29 non-zero percent: .034 plwiki.results total: 28 non-zero percent: .071 etwiki.results total: 23 non-zero percent: 0 trwiki.results total: 22 non-zero percent: .045 nlwiki.results total: 20 non-zero percent: .250 viwiki.results total: 12 non-zero percent: 0 lvwiki.results total: 7 non-zero percent: 0 cswiki.results total: 7 non-zero percent: .142

This finds results for 124 queries out of 2015, for a conversion rate of 6.1%.

Calculate zero result rate from hive CirrusSearchRequestSet table
Result: non_zero zero   zero_result_rate 131003  17298   0.11664115548782539