#community-help

Addressing Issues with Address Search Synonyms in Typesense

TLDR chase noted issues with typesense address synonyms on their platform. Jason suggested altering the synonym settings and later to upgrade to a later version. Despite resolving the initial issue, the upgrade spiked latency times. Further investigation is ongoing.

Powered by Struct AI

1

1

Aug 04, 2023 (2 months ago)
chase
Photo of md5-051f535431ff484f44f165e9a0b696a5
chase
11:33 PM
hi all! hoping this question can fit into a slack thread, but let me know if i should move it into an email conversation 🙂

we’re having some issues with the way that typesense is handling synonyms on our platform, leading to less than desirable first, second and third results for a given search. our records are address records, and here’s an example of the issue:

for the address 1370 S Ocean BLVD APT 405 Pompano Beach FL 33062, some users might like to input UNIT instead of APT - but having a synonym between these two doesn’t seem to work. even just not having that unit/apt/# there all together seems to work, but having something like UNIT there instead of APT will cause other random addresses with different numbers to rank first, even though none have “unit” anywhere in the record. any ideas? happy to clarify further if needed - thanks in advance!
Image 1 for hi all! hoping this question can fit into a slack thread, but let me know if i should move it into an email conversation :slightly_smiling_face:

we’re having some issues with the way that typesense is handling synonyms on our platform, leading to less than desirable first, second and third results for a given search. our records are *address* records, and here’s an example of the issue:

for the address *1370 S Ocean BLVD APT 405 Pompano Beach FL 33062*, some users might like to input *UNIT* instead of *APT -* but having a synonym between these two doesn’t seem to work. even just not having that unit/apt/# there all together seems to work, but having something like *UNIT* there instead of APT will cause other random addresses with different numbers to rank first, even though none have “unit” anywhere in the record. any ideas? happy to clarify further if needed - thanks in advance!Image 2 for hi all! hoping this question can fit into a slack thread, but let me know if i should move it into an email conversation :slightly_smiling_face:

we’re having some issues with the way that typesense is handling synonyms on our platform, leading to less than desirable first, second and third results for a given search. our records are *address* records, and here’s an example of the issue:

for the address *1370 S Ocean BLVD APT 405 Pompano Beach FL 33062*, some users might like to input *UNIT* instead of *APT -* but having a synonym between these two doesn’t seem to work. even just not having that unit/apt/# there all together seems to work, but having something like *UNIT* there instead of APT will cause other random addresses with different numbers to rank first, even though none have “unit” anywhere in the record. any ideas? happy to clarify further if needed - thanks in advance!Image 3 for hi all! hoping this question can fit into a slack thread, but let me know if i should move it into an email conversation :slightly_smiling_face:

we’re having some issues with the way that typesense is handling synonyms on our platform, leading to less than desirable first, second and third results for a given search. our records are *address* records, and here’s an example of the issue:

for the address *1370 S Ocean BLVD APT 405 Pompano Beach FL 33062*, some users might like to input *UNIT* instead of *APT -* but having a synonym between these two doesn’t seem to work. even just not having that unit/apt/# there all together seems to work, but having something like *UNIT* there instead of APT will cause other random addresses with different numbers to rank first, even though none have “unit” anywhere in the record. any ideas? happy to clarify further if needed - thanks in advance!
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
11:42 PM
If I’m looking at the right cluster, I see a one-way synonym setup for APT (root) -> UNIT… this will only kick in when the user types in apt.

You want to set that up as a multi-way synonym. So leave the root field empty, and add “APT, UNIT” in the synonyms field
11:43
Jason
11:43 PM
Or if you only want Unit to map to apt, and not the other way around, you want to swap the root and synonym in the setup
chase
Photo of md5-051f535431ff484f44f165e9a0b696a5
chase
11:45 PM
thanks for the reply - i was testing with that earlier. unfortunately, i get the same type of result with that setup
11:46
chase
11:46 PM
Image 1 for Image 2 for Image 3 for
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
11:47 PM
Could you try setting the synonyms all lower-case? There’s a bug in 0.24.1 that makes synonyms and overrides case-sensitive only during synonym resolution when they shouldn’t be… since during query parsing we lower-case all strings
chase
Photo of md5-051f535431ff484f44f165e9a0b696a5
chase
11:49 PM
interesting, good to know. unfortunately seems like the same result still:
Image 1 for interesting, good to know. unfortunately seems like the same result still:
11:49
chase
11:49 PM
shouldn’t it still be matching the “101” after unit though?
11:50
chase
11:50 PM
if i don’t include unit/apt at all, it matches properly:
Image 1 for if i don’t include unit/apt at all, it matches properly:
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
11:52 PM
Could we try upgrading you to the latest RC build to see if some of the tangentially related issues we’ve fixed around synonym resolution addresses this use-case?
chase
Photo of md5-051f535431ff484f44f165e9a0b696a5
chase
11:52 PM
sure! we’ve got a production one in there that i’d rather not touch, do you need the ID of the cluster i’d want to upgrade?
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
11:53 PM
You can actually do the upgrade from Cluster Configuration > Modify. You want to pick 0.25.0.rc60 as the version

1

chase
Photo of md5-051f535431ff484f44f165e9a0b696a5
chase
11:53 PM
will try and report back, thanks

1

Aug 09, 2023 (1 month ago)
chase
Photo of md5-051f535431ff484f44f165e9a0b696a5
chase
06:55 PM
Jason updating resolved the issue - but unfortunately now our latency times are dramatically increased on this build (avg of 10 seconds instead of 300-400ms) any ideas? should i try rebuilding the cluster?
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
06:57 PM
Hmmm, that’s not good. Could you open the network tab in the browser dev console, do the search query, look for a request to multi_search, copy as curl and DM it to me? We can then take a closer look