Product

Unveiling the search algorithm: how Algolia improved search
facebooklinkedintwittermail

Most search engines basically boil down to counting the number of times a query word appears in a document. Some of the more sophisticated ones use some algorithm to give each document a unique but vaguely-defined float value. That makes it hard to improve the relevance of search results or use any other data format.

Algolia works differently. We designed it mainly for database search, so the query-counting approach doesn’t work anymore. Instead, our ranking algorithm rates each matching record on several criteria (like the typo count or geo-distance), to which we individually assign an integer value score. You can even apply your own criteria to model your business logic directly inside the search engine. You get to pick the order of the criteria used, and then going down the list of criteria, all results which are currently tied are sorted.

A record’s score on each criterion is explicitly listed in the search results (see _rankingInfo  below for the query “the rains”), so you can understand how one record can rank higher than another one. We will explain each of these criteria in this article.

{
"hits": [
     {
          "name": "The Rains Came",
          "url": "/title/tt0031835/",
          "rating": 6.8,
          "year": "(1939)",
          "nb_voters": 881,
          "rank": 16232,
          "objectID": "24324",
          "_highlightResult": {
               "name": {
                    "value": "The Rains Came",
                    "matchLevel": "full"
                },
                "year": {
                     "value": "(1939)",
                     "matchLevel": "none"
                }
          },
          "_rankingInfo": {
               "nbTypos": 0,
               "firstMatchedWord": 0,
               "proximityDistance": 1,
               "userScore": 2379657,
               "geoDistance": 0,
               "geoPrecision": 1,
               "nbExactWords": 2
          }
},
...
}

Search-as-you-type

Before diving in, you first need to understand that Algolia searches for matching prefixes, not matching whole-words. For example, if you are searching for “Joe B”, we would consider all the following records as matches:

  • Joe Black
  • Joe Benson
  • Joe Bolick

Prefix matching is what enables us to return relevant results even when a user has only typed a single letter. When Google introduced instant search, they claimed that showing results before you finish typing can save 2-5 seconds per search.

Note: By default, when the query contains multiple terms, Algolia only uses the last term as a prefix. This is because when searching, say, for a person by name, it’s quite normal to type their entire first name but not their last (like George Cloo). Not so for the reverse (like Geo Clooney). You can override this behavior by setting queryType=prefixAll.

Ranking algorithm criteria

By default, Algolia ranks every matching record by using the following criteria, in the order listed below. The higher up the criterion on the list, the more importance it has on ranking. You can easily change this order if you want, but we have found that this default order is the best one in 90% of the use cases.

  1. Typos
  2. Geo-location (if applicable)
  3. Proximity
  4. Attributes
  5. Exact
  6. Custom

Let’s understand each one of these criteria by applying them to an example:

[
  {
    "objectID": 1,
    "name": "Jo Blak",
    "company": "Utility Trailer Sales",
    "nbCalls": 4
  },
  {
    "objectID": 2,
    "name": "Jo T. Black",
    "company": "Steritek Inc",
    "nbCalls": 45
  },
  {
    "objectID": 3,
    "name": "Joe Black",
    "company": "Pip Printing",
    "nbCalls": 9
  },
  {
    "objectID": 4,
    "name": "Joe Thompson",
    "company": "Black Birds inc",
    "nbCalls": 9
  },
  {
    "objectID": 5,
    "name": "Deanna Gerbi",
    "company": "Thompson, Joey & Blackburn ltd",
    "nbCalls": 7
  }
]

1. Typos

Are there words that start (that is, are prefixed) with a term typed by the user? And if so, do they match exactly the query?

  • 0 points means there are prefixes that exactly match all the terms in the query.
  • 1 point means there is a 1-character discrepancy between the matching prefixes and the query terms.
  • 2 points means there is a 2-character discrepancy, and so on.

Example: for the query “joe black”, here is how each result would rank for typos only (joey is considered as a typo as only the last word of the query is searched as a prefix):

Rank

Record

Score

Why

1

record 3

0

joe black

1

record 4

0

joe thompson black birds inc 

1

record 5

1

thompson, joe_ & blackburn ltd

2

record 2

1

jo_ t. black

3

record 1

2

jo_ bla_k

 

Note: By default, Algolia accepts 1 typo for words having at least 3 characters and 2 typos for words having at least 7 characters (this behavior can be configured withminWordSizefor1Typo  andminWordSizefor2Typos  query parameters). This means that the query “ab” only matches words starting with “ab”, while the query “abc” matches words starting by “abc” but also “aba”, “abb”, “aac”, etc.  A typo is defined by an insertion, deletion, or substitution of a single character, or a transposition of two adjacent characters (Damerau–Levenshtein distance). As it is extremely unusual to mistype the first character of a word, a typo on the first character counts for 2 points instead of 1.

2. Geo-location (if using)

How far is the record’s physical location from a central, predefined point? This criterion lets us rank by geoDistance score, which is that distance in meters.

We can even use the aroundPrecision query parameter to consider similar results as equal (for example, we can set this parameter to 10 so that a result 100 meters from our central point and a result 109 meters from our central point will be considered equally relevant).

We don’t use geo-location in our example, but you can find a dedicated guide in our documentation.

3. Proximity

For a query that contains two or more words, how physically near are those words in the matching record? Algolia adds 1 point for each word in between query words, with a maximum of 8 points.

  • 0 points means no proximity: there was only one word in the query
  • 1 point means the best possible match: the words are next to each other
  • 2 points means there is one word between the matched query words
  • and so on.

When words are in different attributes they get automatically the maximum of 8 points per new attribute. So if three query words are in three different attributes, the score is 16. If three words are in two different attributes, the score is 8.

In our example, we have a 3-way tie between records 1, 3 and 5 (‘&’ is considered as a separator and is not taken into account). Record 2 has a word in between the matched query words (Jo T. Black), while record 4 matches in two different attributes:

Rank

Record

Score

1

record 1

1

1

record 3

1

1

record 5

1

1

record 2

2

2

record 4

8

4. Attributes

This is the order of the attributes that Algolia will follow to search inside a record. Records where there is a match in the first listed attribute rank higher (that is, gets fewer points) than records with a match in an attribute that’s lower on the list. The exact number of points are determined by the position of the first matching word in the attribute.

In our example, say we consider the name as more important than the company. We would then use the setting attributesToIndex:[“name”, “company”] to indicate that we want to index, or search in, the attributes “name”, and then “company”, in this order of importance.

Lastly, matching text at the beginning of a given attribute will be considered more important than matching text further in this attribute. You can disable this behavior if you add your attribute inside unordered(AttributeName). If we considered the position of the match not relevant for the attribute “company”, we would use the setting attributesToIndex:[“name”, “unordered(company)”]. 

With “a” being the numerical index of the first matched attribute, and “w” being the numerical index of the first matched word within that attribute, the amount of points a result gets is determined by the formula: ((a – 1) * 1000) + w – 1. This ranks the results by the priority of the attribute they match, and if they tie, by the location of the match within the attribute.

Rank

Record

Score

1

record 1

0

1

record 2

0

1

record 3

0

1

record 4

0

2

record 5

1001

5. Exact

Records with words (not just prefixes) that exactly match the query terms rank higher. A record gets 1 point for every word that is exactly matched.

Here is how our records would rank based on exact-matching alone for the query “joe black”:

Rank

Record

Score

Why

1

record 3

2

joe black

1

record 4

2

joe tompson black bird inc

2

record 2

1

jo t. black

3

record 1

0

3

record 5

0

 

6. Custom / Business metrics

By this point, we’ve figured out how relevant a result is given the user’s query. But now, you can specify additional criteria, like custom business metrics that express a record’s popularity. 

With other search engines, you have to choose between sorting the results according to their relevance to the user’s query or according to their popularity (number of visits, ratings, sales, etc), but you can’t do both. This means users may get results that are outrageously popular, but completely irrelevant to their search. With Algolia, you can integrate popularity (or anything else, like population, or the last date of update) into the relevance calculation. To us, it is just an additional criterion, so it will support – rather than outweigh – classic relevance criteria.

In our example, we may consider people with whom we had many calls more popular than others. For people having the same number of calls, we can just order them by alphabetical order. We would then use the setting:  customRanking:[“desc(nbCalls)”, “asc(name)”]

For this criterion alone, here’s how our example records rank:

Rank

Record

Score

Why

1

record 2

4

nbCalls=45

2

record 3

3

nbCalls=9, “Joe B”  < “Joe T”

3

record 4

2

nbCalls=9

4

record 5

1

nbCalls=7

5

record 1

0

nbCalls=4

The score is actually the order of entries in the index (biggest score being first). There is never equal scores for this criterion. Therefore, custom should always be the last criterion of your ranking as no subsequent criterion would ever be checked.

Note: Custom ranking is computed at index time (for performance reasons) and cannot be changed dynamically with each query. If you need to change the ranking depending on context, you need to create one index per desired ranking formula. We recommend using the primary/replica feature to make it easier to keep several indices in sync. You only need to push your updates to the primary and they are automatically replicated to the replica indices (see the replica parameter in index settings).

Determining the overall rank

So what is the exact ranking of our query “joe black”?

1. Typos: After looking at typos, we can already rank record 1 as last. Since record 3 and 4, as well as record 2 and 5, are tied, we need to compare them to the next criterion.

Typos

Record 3

0

Record 4

0

Record 2

1

Record 5

1

Record 1

2

2. Geo:  Not applicable. All records have a score of 0. Next!

Typos

Geo-distance

Record 3

0

0

Record 4

0

0

Record 2

1

0

Record 5

1

0

Record 1

2

3. Proximity: Record 4 matches in two distinct attributes is thus scored less than record 3. Record 2 has a word (T.) between query terms and thus scores less than record 5.

Typos

Geo-distance

Proximity

Record 3

0

0

1

Record 4

0

0

8

Record 5

1

0

1

Record 2

1

0

2

Record 1

2

Since each record now has a distinct rank, in this example there’s no need to go through another round and compare scores for the Attributes, Exact and Custom criteria.

A second example

Before jumping to our conclusion, let’s now look at what would be the result for the query composed of the single character ‘j’:

Typo

Geo-distance

Proximity

Attributes

Exact

Custom

Record 2

0

0

0

0

0

4

Record 3

0

0

0

0

0

3

Record 4

0

0

0

0

0

2

Record 1

0

0

0

0

0

1

Record 5

0

0

0

1001

With such a simple query, we obtain a 4-way tie before checking the custom score that will finally consider record 2 as the best one because of the important number of calls it received.

Isn’t that cool? Algolia is examining already-relevant results and getting closer to the mark each time the user types an additional letter, all thanks to prefix-matching and this flexible, customizable algorithm. And that’s just the out-of-the-box configuration! If you’d like to take this a step further, check out this article here.

About the authorNicolas Dessaigne

Nicolas Dessaigne

Co-founder & board member at Algolia

Recommended Articles

Powered by Algolia AI Recommendations

Inside the Algolia Engine Part 4 — Textual Relevance
Engineering

Inside the Algolia Engine Part 4 — Textual Relevance

Julien Lemoine

Julien Lemoine

Co-founder & former CTO at Algolia
Best webpage structure & indexing for document search: the Laravel Example
Engineering

Best webpage structure & indexing for document search: the Laravel Example

Julien Lemoine

Julien Lemoine

Co-founder & former CTO at Algolia
Inside the Algolia Engine Part 5 – Highlighting, a Cornerstone of Search UX
Engineering

Inside the Algolia Engine Part 5 – Highlighting, a Cornerstone of Search UX

Julien Lemoine

Julien Lemoine

Co-founder & former CTO at Algolia