Searchable Field Logic Issues - Phrase Match, Text Search, and Document Search

Hello!

I have a question regarding sorting logic - is there a way to dictate how Searchable Fields are prioritized?

I have three fields I am having issues with. The Name field, the Body field (set to Document Search), and a duplicate of the Body field that I created so that I could enable Phrase Match in addition to Document Search.

The Body field will always need to be set to Document Search so this feature is available.

The Duplicate Body field will always need to be set to Phrase Match as the client wants direct phrases to surface the most relevant entities first that have the exact phrase match in the body.

The issue I am having is that I also need the Name field to be searchable, and none of the Searchable Field settings seem to be suitable for what the client is expecting.

If I have the Name field set to Phrase Match, Document Search overrides the search and the most directly related Phrase Matched results for the Name field do not appear.

If I have the Name field set to Text Search, the Name field shows the best search results, but then the Duplicate Body field won’t show results based on the best Phrase Match.

If the Name field is set to Semantic Text Search or NLP filter, it also overrides the Duplicate Body field in its Phrase Matching, which is very important to the client.

I am looking for a solution where Document Search works to surface relevant featured snippets, and then in the results below, when a search term is Phrase matched with content in the Duplicate Body, that entity surfaces first, and when a search term is Phrase matched with the name of an entity, that result is surfaced first. With the current versions of the configuration I have tried, I can’t accomplish this.

Could anyone please advise on if there is a workaround here? I am happy to send more details offline as well.

Thank you so much!

Hey Sonia,

I have a few clarifying questions for ya!

There’s no reason you’d need to duplicate a field in order to use multiple searchable field types on it. You can just activate documentSearch and phraseMatch at the same time.

That being said, using phraseMatch on a long text field doesn’t really make any sense. Phrase match only works if the ENTIRE field from the KG also appears in the user’s query, which is extremely unlikely for a body-type field. For that reason you wouldn’t want to activate phrase match on the body field, why do you want something more than just documentSearch?

I’m not sure I understand the issue you’re having with the name field, I would maybe recommend using textSearch + phraseMatch on the name field here?

Let me know if after making those changes you’re still seeing search result logic that doesn’t suffice for your client.

Best,

Daniel

Hi Daniel,

Thank you! See below for the error message that appears when trying to enable Document Search and other fields:

However, I was able to resolve the above issue, but am now running in to another similar issue on another account.

I need to set up the configuration so that if a service term such as “fund finance” is searched on the News vertical, the results that show are only those that have the full string “fund finance” either in the Name or the Body. Is there a way to accomplish this?

Per your explanation above, Phrase Match wouldn’t be the right setting. However I need to be able to set it so that results that have either “fund” or “finance” separately in the Body aren’t appearing over results that have the full string “fund finance” in either the name or body fields. Currently, if I set both Name and Body to Text Search, I get all the results with either fund OR finance in the name or body, and I don’t get returned the results that actually have “fund finance” in the body.

Any insight would be greatly appreciated! Thanks!

Yep as mentioned, you wouldn’t want to turn on another algorithm (especially not phrase match) for a field with document search turned on.

As far as your second question goes, we don’t currently have a good algorithm to handle that logic.
Does the name field value only contain the text “fund finance”? Or is “fund finance” only part of the name? If it’s the latter, then we want to avoid phrase match as users would have to type the exact name for that result to appear in the results. If it’s the former, than phrase match would be your best bet.

For the body field, we’d most likely want to use document search if it’s long unstructured content.

Having said all of this, we are actively working on adding your requested functionality to our platform! In the near future users should be able to wrap their query in quotes to designate that they want to receive only matches on the full phrase.

Will keep you updated with when that feature goes live!

Best,

Daniel