You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by lajkonik86 <th...@gmail.com> on 2008/11/16 15:36:43 UTC

Re: Solr Sorting, merging/weighting sort fields

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" <ho...@fucit.org> 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.