Allow wildcards in proximity searches with multiple words

Question

I am using ElasticSearch 5.6 on Ubuntu 16.04. My problem is when i try to use wildcards inside a proximity search with multiple words.

Examples:

"hell* worl*"~3

Basically, I would like to get all the words that starts with "hell" and "worl" that are close to each other with a max distance of 3.

I do not get any error but it does not find the documents. It seems that wildcards are not analyzed. I also have set analyze_wildcard: true

The DOC says:

By default, wildcards terms in a query string are not analyzed. By setting this value to true, a best effort will be made to analyze those as well.

But, only the following query works:

"hello world"~3 # this works

This is my query:

{  
   "size":15,
   "from":0,
   "query":{  
      "bool":{  
         "must":[  
            {  
               "query_string":{  
                  "query":"\"hell* worl*\"~3",
                  "analyze_wildcard":true
               }
            }
         ]
      }
   }
}

Reference:

• Proximity Searches
• Wildcards

Answer 1

You can use span queries to achive what you want, though be careful cause the terms are not analyzed here.

{
  "size": 15,
  "from": 0,
  "query": {
    "span_near": {
      "clauses": [
        {
          "span_multi": {
            "match": {
              "wildcard": {
                "t": "hell*"
              }
            }
          }
        },
        {
          "span_multi": {
            "match": {
              "wildcard": {
                "t": "worl*"
              }
            }
          }
        }
      ],
      "slop": 3,
      "in_order": true
    }
  }
}

The problem in your query_string is that * character is not treated as wildcard within quotes. What you get is simple slop phrase similar to "hell# worl#"~3 cause special characters have no meaning within quotes.

Be careful though, cause span queries have much slower performance than simple phrase search (though it seems that it still is faster than slop phrases which actually surprised me).

Better option if you can still prepare your data for the scenario is to use ngrams. With ngrams simple "hell worl"~3 would match what you want.