Improve default sort on advanced search

[kenkunz]

Problem

On the advanced search page, we now sort by liquidity:desc by default. The downside of this is that pairs are always sorted to the top if any pairs match the query (even if their text_match rank is substantially lower).

Previously, we tried sorting by relevance, defined as: [ "text_match:desc", "liquidity:desc" ]. The benefit of this is you get results across all trading entity types, and entities with higher text_match appear towards the top. The downside is that low quality trading pairs sometimes score highest on text_match. We have disabled the relevance sort option for now.

Possible solutions

Solving this may require a combination of one or more of the ideas below.

1. Improve text_match accuracy

There are various Typesense schema definition and/or search parameter changes we could make to optimize the accuracy of text_match. In some cases, it's not obvious why one record receives higher text_match than others. We could discuss this with Typesense to get their guidance.

2. Decrease text_match precision

The text_match values are quite high – e.g., 2819156387428446. Some values are off by very small percentages. We could decrease the text_match precision – e.g.,: Math.round(2819156387428446 / 1e10) = 281916. This would allow records that are close in text_match to be treated as equal so the liquidity secondary sort criteria is used.

As far as I know, this can't be done in Typesense – we would need to map the values and re-sort client-side.

3. Add quality field to trading entity records

We could flag pair records with low liquidity with a lower quality value.

For example, set quality equal to:

• 1 on all exchange and token records
• 1 on pair records with liquidity >= THRESHOLD
• 0 on pair records with liquidity < THRESHOLD

We could reintroduce a relevance sort based on: [ "quality:desc", "text_match:desc", "liquidity:desc" ]. This still gives weight to text_match but de-prioritizes low quality pairs.

A common value of 1 is used for all "good" records so that the quality sort doesn't overwhelm other desired sort-by fields – e.g, this enables you to get a mix of exchange, token and pair records in your results.

4. Other?

Something else we haven't thought of yet.