One aspect of FAST Search for SharePoint that needs to be considered is how to effectively “tune” the search engine to increase recall and relevancy. Out of the box, FAST includes a default configuration that while handling most situations, is not meant to be left in its default state. Since each business scenario carries a different set of requirements, it is most useful to configure the engine to produce results that are of high value to one’s organization.
A search application needs to be able to show document-specific search results sorted in such a way that the most relevant items are displayed first. To do this, it is necessary to look beyond the out-of-the-box configuration settings and start tuning FAST to produce valuable results.
Search result sorting is actually impacted by a number of different factors. One of those is the out-of-the-box search web part configuration. This configuration does not affect the search results obtained through the web service API. The configuration as done through PowerShell scripts on the FAST Search Server, UI settings changes in Central Administration, and Site Collection Settings all have an effect on search results obtained through the web services API. Below is a diagram that shows the latter FAST configuration options:
Figure 1
Please refer to the following TechNet articles for a more detailed explanation of these concepts:
This diagram shows the various ways FAST can both rank indexed content and sort search query results. It also shows the advantages and disadvantages of each area of rank configuration. The overall goal of the diagram, however, is to demonstrate that FAST relevancy configuration is orchestrated through many different mechanisms throughout the product. Hence, to get relevant search results, it is necessary to try different configuration options in a non-production environment first. Once the desired query results are obtained, the configuration settings can be moved into production.
An important note is that FAST index relevancy configuration applies to the entire SharePoint site collection in which it serves. This means that if, for example, PowerPoint presentations are configured to be boosted in the search results, this will be true across the entire site collection.
To mitigate this issue, it is necessary to consider creating a separate full-text index to be used only for a particular application.
Full-text indexes are based on managed properties which are in turn are made up of crawled properties. This is illustrated in the following diagram:
Figure 2
As can be seen, two separate full-text indexes have been created each with their own set of rank profiles. Queries can then be pointed to one index or the other depending on where the search is being executed. In addition, the rank profile can be tuned for each one without affecting the other.
Please refer to the following TechNet article for instructions on how to configure full-text indexes in FAST:
Options for Tuning Relevancy and Ranking
Given the multitude of places to “tune” relevancy and ranking, it is prudent to consider a few options to produce the desired result of a boost in rank for a particular piece of content.
| Option |
Advantage |
Disadvantage |
- Increase the rank for documents with a file extension of .ppt or .pptx through a change to the FAST Query Language (FQL) statement generated in the code.
|
- More control over query behavior
|
- More difficult to configure and maintain
- Query performance impacted
- Requires developer assistance
|
- Modify the Dynamic Ranking Component “Managed Property Field Boost” so that any search item with the managed property “fileextension” equal to .ppt or .pptx will have its rank score increased.
|
- Easier to configure and maintain
|
- Query performance impacted
- Requires FAST administrator to configure
|
- Add a new managed property static rank component that increases rank value at index time.
|
- Query performance not impacted
- Easier to configure and maintain
|
- Requires FAST administrator to configure
- Must re-index content to make change permanent
|
Conclusion
The configuration of the rank profile should be modified so that ideally at index-time the rank of a particular piece of content is boosted while minimizing query performance impact. With respect to the options as noted above, this means Option 3 is the ideal approach. But that option also means that the site collection will need to be re-indexed. The time to do so may make this option impractical if the size of the content is large (> 100 GB). In this case, Option 2 is the next recommended approach, followed by Option 3.
In all cases, the configuration changes should:
- Be tested in a non-production environment prior to implementing in production. Ideally, a backup and restore of the production SharePoint content database into the non-production environment would be done first. This will provide an environment as close as possible to production in which to test the configuration settings.
- Be done on a separate full-text index, configured only for Application mobile. This logical separation will keep configuration settings for Application mobile from affecting results on Application.