For the recipe app I want to do something slightly different, showing the absolute search result quality for each result. In other words: If the best search result in a result set is not very good, make it smaller than if it has higher value, thus showing an absolute value for each result. The dialogue equivalent comparing i.e. two movies would be to define the best of them better than the other, but not the best you’d seen.

Absolute search result quality

aka. Absolute visual relevance hierarchy

How do we then measure absolute quality? In an earlier post I described what would be our relevancy hierarchy. The more in-season ingredients in a recipe, the better quality.

I’ve defined three quality groups for absolute search result quality so far (number of ingredients: n):

1. n >= 4
2. 1 < n < 4
3. n = 1

Here are three different examples on search results set. First has two results with four or more in-season ingredients and second has only one. Third has none, typically something that would happen during the winter months in Norway:

The recipe app is work in progress. Check back every now and then for new blog posts on the subject.

Composite field context weight sums
Weights are not relative to its containing element. I.e. the field-weights within the context part of a composite-rank do not sum up to a 100% which most people find intuitive. If you have two fields weighted 100 and 100 and get a hit in both fields, then hit in the composite becomes 200, instead of 100 as one could expect from a “100% hit”.

The single-field-composite warning
A search on non-composite fields do not generate dynamic rank. For this you will need to wrap it in a composite field, which is perfectly ok. However, when you bliss (upload) an index profile, ESP will spew out warnings. These can be ignored. (But remember to add the composite field reference to the rank profile, as usual, or it will have no effect.)

The context/occurence oddity
An often encountered problem is a composite with fields that have values contain the same tokens (words). A search will then get context hits in multiple fields and get rank contributions from each. However, in most cases you would only like to have a rank contribution from the hit in the highest weighted field. I have tried to turn off whatever I could find in config files, but not been able to solve this problem. There are however a few ways around this.

One involves ripping out duplicate words from the lower weighted fields during document processing, but that makes those fields useless for other purposes.

Another solution involves splitting the fields into singular composite fields and rewriting the query to contain a lot of parts searching each field with the same words, and joining them with the ANY operator.

A third solution is join the fields in question in a field-ref-group in the composite field. This will count multiple field hits as a hit the one group and assign a rank contribution according to the field-ref-group’s weight. But you will no longer be able to assign individual weights to each field.

The default oddity
One composite field must be tagged with

default="yes"

If you have no default composite field, ESP can start to act funny, such as swapping int32 and string types in the result(!)

The quality oddity
This refers to the static boost contribution to the result defined by the “quality” element of the rank-profile.

If the quality element is not present, the default weight is 50, and the default quality field is “hwboost”. This is a magic field that is hard coded and not defined in the index profile. However, try to specify

<quality weight="50" field-ref="hwboost"/>

and you will get an error that the field is not defined. This can seemingly safely be explicitly defined in the index profile as

<field name="hwboost" type="uint32" index="yes" sort="yes"/>

The default start value of hwboost is 10000, and this can be added to or subtracted from during document processing.

The quality weight is limited to steps of 50 (0, 50, 100, 150, …). These values are actually transformed to multipliers 0, 1, 2, … So a weight value of “50″ does not mean half or 50%. With a default hwboost, a weight of “50″ transforms to multiplier 1, i.e. 1*10000=10000.

You can specify your own quality field. It must be of type uint32 (not int32!), index and sorting set to “yes”.

After changing the values, run

bliss-core -C index-profile.xml
view-admin -m refresh

and then wait a minute or so for the views to refresh.