@missinglink it might be useful to expose fuzziness as a parameter to autocomplete. E.g. maybe someone is OK with more CPU usage for correcting more input strings?

Hi @mihneadb, I think it's better to leave it as configurable on startup.

Having it variable per-request could cause quality-of-service issues for cloud providers like ourselves as there would be huge variability in the CPU usage of each request. I think it's important that operations engineers can control this setting.

You can adjust the settings for your docker installation without generating a new docker image by copying the autocomplete_defaults file to your local machine, editing it and then bind-mounting your local copy as a replacement for the file in the container.

If you're not familiar with docker-compose you can look in the docker-compose.yml file and you'll see that we bind-mount the local file pelias.json and make it available in the container using the same method.

You'll then need to bring the API service down and up again to apply that configuration.

Makes sense, thanks!

Hi @missinglink,

I'm testing this PR, and I found something for the parameters prefix_length.
I'm trying to found this address : 40 Rue De L'arsenal, Bordeaux, France with autocomplete.
When I type 40 Rue De L Arsenal Bordeaux (without ') or 40 Rue De Arsenal, Bordeaux (without L' or 40 Rue Arsenal, Bordeaux (without De L'), I have no results with prefix_length = 1 (but works with prefix_length = 0).
This is common in french to omit determiners and can be a bit strange when we have no results.

We may need some benchmarks to weigh the pros and cons 🤔

Thanks @Joxit, interesting feedback, that's certainly unexpected behaviour.

So I tested this out a bit yesterday, and it's quite good! I do think max_expansions needs to be a bit higher than 10, since that's not enough to even support all the possible replacements of a single character (there would be 36 if we are assuming only [a-z0-9]).

@Joxit your example makes sense. With prefix_length = 1, changing/insertion of the first character is supported, so larsenal would be one of the generated possibilities when you type arsenal. However with prefix_length = 0, it would not be. The underlying token for L'arsenal is in fact larsenal, and indeed the following queries don't currently work:

/v1/autocomplete?text=40 Rue De l arsenal, Bordeaux, France
/v1/autocomplete?text=40 Rue De arsenal, Bordeaux, France

So I think we should try increasing the max_expansions to at least 100 or so, and do a bit of performance testing, as well as look for possible issues where the fuzzy searching causes otherwise working queries to now fail. If neither of those end up being a huge concern I really think this is surprisingly close to 🚢.

I just rebased this branch against the latest in master, and updated some newly added fixtures to take fuzziness parameters into account. The tests should pass again!

Hi there,
I'm experimenting this PR (with some changes) on our production server.

Here are the changes I've made.

-  'fuzzy:prefix_length': 1,
-  'fuzzy:max_expansions': 10,
+  'fuzzy:prefix_length': 0,
+  'fuzzy:max_expansions': 25,

Source: Joxit/pelias-api jawg/v3.63.0-fuzzy.

I will see if we have some performance issues or incorrect responses 😄.

I just found something than can be weird when we use fuzzy, perfect matches may not be in first positions.
Some work will be required in ES scoring for this.

(This is completely random)

{
  "function_score":{
    "query":{
      "match":{
        "name.default":{
          "analyzer":"peliasQueryPartialToken",
          "query":"vannes",
          "operator":"and"
        }
      }
    },
    "max_boost":20,
    "functions":[
      {
        "weight":1
      }
    ],
    "score_mode":"first",
    "boost_mode":"replace"
  }
}

Hi @missinglink, is there a way I could help with this PR?

Yes, please build a docker project from pelias/docker and compare the differences in result quality between pelias/api:master and pelias/api:fuzzy_autocomplete.

https://hub.docker.com/layers/pelias/api/fuzzy_autocomplete/images/sha256-9da0db501c473a7079e1df26569657d0bca89a3c97e0976f01a183a92b7a4f9d

Let us know what's better/worse

This branch also needs to rebase master, I had a quick look at it and it's not a trivial task.

The issue is that I already migrated to the version with Elastic 7, so testing it out won't be a quick one either..

I'm not sure if follow, why would that be an issue? Are you saying the queries are not compatible with ES7?

I get this error when running a query:

[parsing_exception] [constant_score] query does not support [query], with { line=1 & col=54 }

Hi, any progress with this PR?. I believe is a very interesting functionality

Any news on this? Would love to see this implemented. Any issues preventing it to be merged?

The technical answer is that fuzziness increases recall at the cost of precision, and this alone does not increase relevance.

The main issue is the way Lucene implements edit-distance queries (what they call fuzziness), these alternative terms are given an equal score as exact matches. This is obviously not ideal since you can spell a word perfectly and have spelling mistakes ranked higher due to other properties influencing the score.

This is further complicated by the complexity of our queries, often a single query contains multiple sub-queries each of which targets a different field of the document.

So if you set an edit-distance of 2 (for instance) then it's not clear how many total edits will be made to the input text. For instance if the parser detected 4 different classifications (eg. number, street, locality, country) in the input then the text may be mutated up to 8 times!

I believe that the result of these two issues will only serve to slow down existing queries while also reducing precision, so it's lose-lose.

I'd be happy to find a solution which provides the increased recall without the ranking issues.

Hello..
Any update on this Pelias Fuzziness
Is anybody using Pelias Fuzziness? =)