Understanding SharePoint 2010 Search ranking model and tuning SharePoint People Search ranking

In search, relevance is about how closely the search results that are returned match the user’s  intent– or as outlined in About intent, recall, relevance and precision of search solutions – relevant results will help you achieve the goals that made you perform the search in the first place. It is therefore quite important that you don’t need to navigate through dozens of pages of search results and that you get the most relevant results listed on the top of your search results.

SharePoint 2010 search has standard 9 different relevancy ranking models defined, from which two are used by default. To get an overview of the different ranking models which are registered you can use the Get-SPEnterpriseSearchRankingModel PowerShell cmdlet.

Get-SPEnterpriseSearchRankingModel -SearchApplication "Search Service Application"

After running this command you will get an overview of the different available ranking models.

The two default ranking models that are used are MainResultsDefaultRankingModel and MainPeopleModel. You can see this by exporting the Core search results web part and the People search results webpart. For example when exporting the People search results webpart you will notice the following property

So let’s take a closer look at the MainPeopleModel – at first I thought that I could simply export a ranking model to XML in a similar fashion as outlined in Rank models in 2013 – Main differences

$peoplerankingmodel = Get-SPEnterpriseSearchRankingModel -SearchApplication $ssa -Owner $owner -Identity d9bfb1a1-9036-4627-83b2-bb9983ac8a1 
$peoplerankingmodel.RankingModelXML > peoplerankingmodel.xml

But unfortunately this XML returned seemed to be empty on my SharePoint 2010 environment – which seems to be behavior by design as explained in this blog post Accessing rank models in SharePoint 2010. But luckily you can also open the MSSRankingModels table in the Search Service Application database and take a look at the XML which is stored in the database.

Now let’s take a closer look at the XML which I copied out. As you see in the XML SharePoint Server 2010 also implements the BM25 ranking model which gives weights to certain fields (managed search properties) for dynamic ranking (This is a very simplistic explanation – for detailed explanation see Microsoft Cambridge at TREC-14: Enterprise track and Static Score Bucketing in Inverted Indexes )

You see a number of managed search properties which are being used – these actually map onto the following crawled properties.

Managed property	Mapped crawled property
RankingweightName	People:CombinedName,People:UserName,People:WorkEmail,People:AccountName,People:SPS-SipAddress
PreferredName	People:PreferredName
JobTitle	People:SPS-JobTitle,People:Title,ows_JobTitle,ows_Job_x0020_Title
Responsiblities	People:SPS-Responsibility (Ask me about)
RankingWeightLow	People:SPS-Skills, People:SPS-Interests
ContentsHidden	People:SPS-Location,People:Office,People:SPS-PastProjects,People:SPS-School, etc…
Memberships	People:Quicklinks
RankingWeightHigh	People:OrganizationNames,People:Department
Pronunciations	People:SPS-FirstName,People:SPS-LastName,People:SPS-PreferredName,People:SPS-PhoneticFirstName, etc …

So you will probably notice that the People search will not take your own custom created user profile properties into account when doing a search for people. You will also notice that the user profile properties skills and interests are assigned the same weight from a relevance perspective since they both map onto the RankingWeightLow property.

It is however also possible to create your own ranking model based on the Ranking Model Schema definition (MSDN). But Microsoft will only allow you to customize certain parts of the search engine ranking algorithm (For SharePoint 2013 there is a lot more in depth documentation of the ranking models – check out Customizing ranking models to improve relevance in SharePoint 2013 ).

In the next example XML schema I added my own custom managed property Certifications and kept all of the other properties and weights for the different querydependent features.

To get at the internal id of the property (called pid in the example above) – you will need to use the Get-SPEnterpriseSearchMetadataManagedProperty PowerShell cmdlet. Besides the weight you can also specify lengthnormalization – a good explanation of this is found in Evaluation and customizing search relevance in SharePoint 2007 :

Modifying the length normalization setting applies only to properties that contain text. For example, consider a scenario where relevance is calculated for two content items containing the query term within the body of the content item, within a book, and within a document containing only a short paragraph. The book is likely to contain more instances of the query term, so it might receive a higher rank value, even if the shorter document is just as relevant to the user's search. The length normalization setting addresses this issue, providing consistency in ranking calculations for text properties, regardless of the amount of text within that property.

Next we will need to import our XML with the custom ranking model – you do this using the New-SPEnterpriseSearchRankingModel cmdlet.

The easiest way to test your new custom ranking model is by using a querystring parameter rm – like this http://jopx/searchcenter/peopleresults.aspx?k=yammer&rm=[ID of your ranking model]. In the screenshot below the People search will also take into account my own custom profile property - Certifications allowing me to search on them.

To use this new model in production, you can export the Core Results webpart, modify the RankingModel parameter and reimport the web part.

References:

• Improve SharePoint Search Relevance – interesting sample code for building a console app which uses a custom ranking algorithm
• Microsoft Cambridge at TREC-14: Enterprise track
• Customizing ranking models to improve relevance in SharePoint 2013
• Ranking Model Schema definition (MSDN)
• Rank models in 2013 – Main differences
• Tuning SharePoint Search Relevance with Ranking Models