#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.

1mo

Join the chat

Aug 04, 2023 (2 months ago)

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!

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

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

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

11:49 PM

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:

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

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

11:53 PM

You can actually do the upgrade from Cluster Configuration > Modify. You want to pick 0.25.0.rc60 as the version

chase

11:53 PM

will try and report back, thanks

Aug 09, 2023 (1 month ago)

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

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

Typesense

Lightning-fast, open source search engine for everyone | Knowledge Base powered by Struct.AI

Indexed 2779 threads (79% resolved)

Join Our Community Manage subscription

Similar Threads

Resolving Multilingual Search Function in Typesense Software

Bill is having difficulty with multilingual search functionality in Typesense software. Developer Kishore Nallan suggested setting a language locale and provided a demo build. The build solution had some issues, and after multiple rounds of software updates and troubleshooting, the problem still persists.

23mo

Optimizing Typesense Implementation for Large Collections

Oskar faced performance issues with his document collection in Typesense due to filter additions. Jason suggested trying a newer Typesense build and potentially partitioning the data into country-wise collections. They also discussed reducing network latency with CDN solutions.

8mo

Phrase Search Relevancy and Weights Fix

Jan reported an issue with phrase search relevancy using Typesense Instantsearch Adapter. The problem occurred when searching phrases with double quotes. The team identified the issue to be related to weights and implemented a fix, improving the search results.

111

6mo

Resolving Issues with Infix and Prefix in Query Searches

Daren struggled with searches missing values in production. Jason and Kishore Nallan offered insights and created new features to help solve the problem, which was then tested and deployed by Daren.

3mo

Querying Issues with Newly Created Collection

User Dima reported issues with missed search results in a new collection he created. User Kishore Nallan offered solutions but the problem persists. Dima cannot share the data, which makes it harder to resolve the issue.

2mo