Using ts_weight to impact search relevancy in Knowledge

[servicenowkevin]

Did you know that you can impact search relevancy by field weight in Knowledge? The Controlling Match Relevance by Field section of our documentation takes you through the basics of configuring your search relevancy at the field level. If you're interested in understanding search relevancy from an overall perspective, see Document Scoring.

The default field weighting is:

• kb_knowledge.number = 50
• kb_knowledge.short_description = 10
• kb_knowledge.meta = 10
• Every other field has a weight of 1 per occurrence and weighting increases exponentially for sequence matches.

At ServiceNow, we're using a weighting of:

• kb_knowledge.number = 50
• kb_knowledge.short_description = 15
• kb_knowledge.meta = 10
• Every other field has a weight of 1 per occurrence and weighting increases exponentially for sequence matches.

The difference for us is in the short description weighting (short description = article title). We find our result set improves with a greater focus on the short description. With strong titling standards, our titles are written to contain a quick overview of the issue, which should match the users search frequently.

We have been considering using a new field to allow certain articles to always appear at the top as "best bet" or "top suggestion" articles. For example, if a customer is searching on something related to LDAP issues, we may want this LDAP troubleshooting article to appear at the top of each result set because it provides the most comprehensive LDAP troubleshooting information in the knowledge base. To allow for this, we've considered using a custom SuperMeta field and providing a significant weight to that field. That would ensure that select content always appears at the top of results. We've played around with this in our personal test environments and it seems to work, but we haven't taken the idea any further. If we implemented this, we'd have to be very selective about what terms to use and how often the field would be used. If you were to over use that kind of feature, you'd ruin the overall search experience.

Have you changed the weighting for fields in Knowledge? What's working for you?

Let me know if you have search weight questions and I'll try to help you out.

[servicenowkevin]

Scott Ferguson You're right about the data being different in the Super Meta field. The meta field would use a wider range of related terms or synonyms. For example, if we have a few articles for troubleshooting a failed import, the meta field might have something like "can't import" or "import not working", etc. Where as the Super Meta field would have "Import" because we want the main troubleshooting import article (it references the other import troubleshooting articles) to always appear at the top of any search with the word "import"

[Mark Laucus]

Thanks all for the guidance.   I think I will just adjust the meta and short description results.

[StephLindorff]

I've also adjusted the weighting but I made Meta my most important field and SD the 2nd most important field.   We also have strong titling standards but Meta allows a bit more flexibility.   For instance, if we learn that one group of users refers to the topic differently than other groups, we can throw their search terms in the Meta field while still keeping the SD tidy and meaningful for the rest of the users.   We can also throw special phrases in to create a list of search results that meet ad hoc operational needs.   Of course, the much more usabile tagging functionality in Eureka removed the need for that last point.

I've been wanting the ability to do Boosts and Blocks in Search.   @servicenowkevin's Super Meta field sound like what I needed to boost a certain article to the top of the list for certain search terms but I'd also like to reduce search results clutter by preventing less useful articles from competing with more useful articles for placement in that 30 item search results list.   The articles I'd want to block add value or I'd Retire them.   But they're not the article I want the Help Desk to start with on a given topic.

[servicenowkevin]

Stephanie Lindorff, our development team has been working on a way to do this a little more gracefully. I can't promise what release it'll be in, but it's a feature I'm keenly looking forward to.

[paulmcdonald]

StephLindorff, Do you only use two fields for the weights such as in a 60/40 split? I was thinking about using five fields (KB Number, Meta, Short Description, Configuration Item and Body Text) but I then end up micromanaging the weight values to get a "perfect" balance.

Do you find that putting the Configuration Item value in the Meta field helps product better search results or do you leave it as the third weight field? Or is the Body Text in the weights even necessary? I thinking that a server name in the Body Text may need to be found in a search.