Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of solr@elyograg.org designates
 166.70.79.219 as permitted sender)
Message-ID: <5123A775.8030205@elyograg.org>
Date: Tue, 19 Feb 2013 09:25:25 -0700
From: Shawn Heisey <solr@elyograg.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: solr-user@lucene.apache.org
Subject: Re: Edismax odd results
References: 
 <9D6DF5D879D6EB47A67AD09E19EAD2F701F90D9C@SHAREEXC001.svw01.serverworld.net.uk>
 <558EDC8FE6FD46C086B461715161885C@JackKrupansky>
 <9D6DF5D879D6EB47A67AD09E19EAD2F701F90D9D@SHAREEXC001.svw01.serverworld.net.uk>
In-Reply-To: 
 <9D6DF5D879D6EB47A67AD09E19EAD2F701F90D9D@SHAREEXC001.svw01.serverworld.net.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I do not see the word engineer (or any other similar word) in the score 
calculation, only boots.  A test on my own index shows both words in the 
calculations.  I would use the analysis admin page on the 
prodnameplurals field to see what happens to the input of "engineer 
boots" on both index and query - see what part of your analysis chain 
removes it.

If you don't see any problem there, then the Solr log (assuming you 
haven't changed the default log level of INFO) should have a record of 
what parameters were actually received when the query was made.

Thanks,
Shawn


On 2/19/2013 9:14 AM, David Quarterman wrote:
> Hi Jack,
>
> Here's q test query we've been using:
>
> select?q=+engineer+boots&defType=edismax&fl=prodname&qf=prodnameplurals&pf2=prodnameplurals^2.0
>
> This still produces a result set where the first 'engineer boot' is way down the list and subsequent ones are interspersed with other boots. They're all in there, just not at the top. Below is the debug on the first item that is an engineer boot.
>
> <str name="ITEM_3333">
> 0.23492618 = (MATCH) sum of:
>    0.23492618 = (MATCH) product of:
>      0.46985236 = (MATCH) sum of:
>        0.46985236 = (MATCH) weight(prodnameplurals:boot in 48270) [DefaultSimilarity], result of:
>          0.46985236 = score(doc=48270,freq=1.0 = termFreq=1.0
> ), product of:
>            0.22236869 = queryWeight, product of:
>              4.8295836 = idf(docFreq=1867, maxDocs=86009)
>              0.046043035 = queryNorm
>            2.112943 = fieldWeight in 48270, product of:
>              1.0 = tf(freq=1.0), with freq of:
>                1.0 = termFreq=1.0
>              4.8295836 = idf(docFreq=1867, maxDocs=86009)
>              0.4375 = fieldNorm(doc=48270)
>      0.5 = coord(1/2)
> </str>
>
> Regards,
>
> DQ
>
> -----Original Message-----
> From: Jack Krupansky [mailto:jack@basetechnology.com]
> Sent: 19 February 2013 15:31
> To: solr-user@lucene.apache.org
> Subject: Re: Edismax odd results
>
> Show us your qf and pf params. Do you have PF2 set? That's the key for getting the phrase "engineer boots" boosted higher than just boots. You may also simply have to give a higher PF2 boost since "boots" probably has a much higher term frequency than "engineer" or even the natural Lucene score for "engineer boot".
>
> Also check the &debugQuery=true "explain" scoring to see how engineer, boot, and "engineer boot" are being scored - you may have to add some specific query phrases to force "engineer boot" into the top results to comparing the scoring.
>
> -- Jack Krupansky
>
> -----Original Message-----
> From: David Quarterman
> Sent: Tuesday, February 19, 2013 6:21 AM
> To: solr-user@lucene.apache.org
> Subject: Edismax odd results
>
> Hi all,
>
> We have an index of boots which contains harness boots, engineer boots , ankle boots, etc. An edismax search on the index for 'harness boots' brings back 2,175 boots with 'harness' results at the top. 'Searching 'engineer boots' brings back everything but 'engineer boots', same for 'ankle boots' - in fact, same result set of 1,873 mostly boots but a few other products mixed in.
>
> We're on SOLR 4.0 and the field we're querying is stemmed (snowball), lowercased on WhiteSpaceTokenizer. Any ideas?