I have trouble balancing between popularity and search relevance.
The trouble is combining boost factors and a mm(minimum match) of less than
100%.
The mm leads the search to return also less relevant items.
Two conflicting main scenarios exist:
- generic category search (say something like tft) mainly i just want to
list the most popular ones
- product specific search eos 400d for instance
If i set a low boost on popularity the category search doesn't attach enough
significance to popularity
If i set a high boost on popularity the search for eos 400d ends you with
the more popular eos 450d
Anything higher than ^5 messes up the second scenario and anything below
^500 messes up the first scenario.
There are two problems in solving this:
- seemingly equally matching items return strongly different relevancy
scores, based on string length
- the effect of popularity and relevancy seems to be addition instead of a
multiplying effect.
Any tips on how to better understand these effects?
Two examples:
<str name="qf">
name^1.0 category^1.1 description^0.2 color^0.2
</str>
<str name="bf">
popularity^5.0
</str>
<str name="mm">1</str>
and
popularity^1500
mm set to default
Walter Underwood wrote:
>
> The boost is a way to adjust the weight of that field, just like you
> adjust the weight of any other field. If the boost is dominating the
> score, reduce the weight and vice versa.
>
> wunder
>
> On 5/10/07 9:22 PM, "Chris Hostetter" <[EMAIL PROTECTED]> wrote:
>
>>
>> : Is this correct? bf is a boosting function, so a function is needed
>> there,
>> no?
>>
>> : If I'm not missing someting, the ^0.5 is just a boost, and "popularity"
>> : is just a (numeric) field. So boosting a numeric field wouldn't make
>> : sense, but appying it to a function would. Am I missing something?
>>
>> the function parser "does the right thing" when you give it a bare field
>> name, from the javadocs...
>>
>> http://lucene.apache.org/solr/api/org/apache/solr/search/QueryParsing.html#par
>> seFunction(java.lang.String,%20org.apache.solr.schema.IndexSchema)
>> // Numeric fields default to correct type
>> // (ie: IntFieldSource or FloatFieldSource)
>> // Others use implicit ord(...) to generate numeric field value
>> myfield
>>
>> you are correct about 0.5 being the boost, using either the _val_ hack on
>> the SolrQueryParser or using he bf param of dismax the ^0.5 will be used
>> as a boost on the resulting function query...
>>
>> qt=standard&q=%2Bfoo%20_val_:popularity^0.5
>> qt=dismax&q=foo&bf=popularity^0.5
>>
>>
>> -Hoss
>>
>
>
>
--
View this message in context:
http://www.nabble.com/Solr-Sorting%2C-merging-weighting-sort-fields-tp10405022p20525893.html
Sent from the Solr - User mailing list archive at Nabble.com.
