Searching People’s Names

Searching for people’s names is hard. Names aren’t like other text; when the algorithm finds a match on a person’s name, it’s a much stronger signal of relevance than matching on a normal word.

For example, if you searched “doctor singh cardiology”, the word “singh” matters a lot more than the word “cardiology” or “doctor”. This user is asking about a specific person, not all cardiologists.

The best way to handle this in Answers is to use a combination of our new phraseMatch algorithm along with textSearch. Specifically, we recommend using phraseMatch first names and last names and textSearch on the full name, like so:

Or in JSON, if you prefer:

{
  "verticals": {
    "people": {
      "searchableFields": {
        "name": {"textSearch": true},
        "firstName": {"phraseMatch": true},
        "lastName": {"phraseMatch": true}
      }
    }
  }
}

In general, this will work better than using textSearch alone because it will prioritize matches on first and last name over matches on other fields and boost those results to the top. It will also work better than using nlpFilters since they can be too exclusionary.

For example, if a name is both someone’s first name and last name - like Lincoln Riley and Abraham Lincoln - then the algorithm will get confused when someone searches for “what is lincoln’s phone number”.

You can learn more about phraseMatch and other searchable fields in the Vertical Searchable Fields unit.

6 Likes

Hey Max! Should this impact Answers ability to surface direct answer results? When I have first name and last name fields set up for textSearch: true, I can get this Answers result:


But, when I set the first and last name fields to phraseMatch: true, I do not get the direct answer card:


Thanks!

1 Like

Hi @Sarah_Dougherty,

Thanks for surfacing this! Our engineering team is looking into this and will circle back as soon as we have a resolve here for you.

Let us know if you have any questions in the meantime.

Best,
Alyssa

Hey @Max_Davish & @Alyssa_Hubbard - one other minor thing I wanted to raise:

This also makes it difficult when there is a conflicting Location match vs Name match. For example “Sanders” is a place and a name. Typically I have resolved these issues by including NlpFilter order, but if I don’t have nlpFilters set I cannot use this solution.

Does that make sense? Thank you both for your support!

Hey Jesse - great question. This is where BERT Entity Recognition comes in. BERT helps to disambiguate words like “Sanders” that could refer to multiple different things. For example, if the query is “doctors in sanders, kentucky” then the algorithm will interpret “sanders” as a location. But if the query is “doctor sanders phone number”, the algorithm will interpret it as a name and not perform a location search. You can read more about this here.

In practice, this should mitigate the problem you’re talking about, but it isn’t 100% perfect, and sometimes the algorithm doesn’t have enough context to know what the user is asking for. For example, if the user simply searches for “sanders”, it’s hard to know whether they’re referring to the location or the person. If you want a little more control of the algorithm’s behavior in these situations then using nlpFilterOrder is a good solution; it’s up to you!

Hey Max, what about middle names? When a person entity’s name field contains “John Robert Doe” and their first name field is “John” and their Last Name field is “Doe”, in my configuration that matches the above they will not show up. if you search for “John Doe.”

Hey Ben - as we discussed, it looks like you were experiencing this problem because of the NLP filter on the full name field. In general, this approach should work just fine with middle names. If a match is identified on the first or last name, the result should still be boosted to the top.

Hey @Sarah_Dougherty - sorry about the delay, but I wanted to follow-up on your question from last month.

The reason that this method might produce fewer direct answers is because today, we use a heuristic to decide whether to show a direct answer based on 1) the number of entities returned and 2) the text of the query. If more entities are returned - which will often be the case with this less restrictive approach - the algorithm takes this as a signal that it shouldn’t return a direct answer.

In the upcoming release, however, we will begin using a BERT-based machine learning approach to decide whether or not to show direct answers, so queries like this one will show direct answers, even if they don’t pass the heuristic.

Hello! I am trying to understand the expected behavior of text search and phrase match in the backend Answers configuration. For one of my clients who has professionals in their search experience, searching for names only shows exact name matches instead of partial matches. As an example, if you were to search “Van”, someone with the name “Van Dam” will populate instead of all providers with “van” in the name like “Sullivan”. Is there a different configuration for searchable fields that I should be using for first name, last name, and name than what is described above or is this expected behavior?