Hi Scott,
Try optimizing after reindexing and this should go away. Had to do with
updated/deleted docs participating in score computation.
Otis
> On Feb 13, 2015, at 18:29, Scott Johnson wrote:
>
> We are getting inconsistent scoring results in Solr. It works about 95% of
> the time, where
This was a common one when I was matching movie and song names. If
that is your project, also try boosting if it's the first word or on
shorter titles. Also try bigrams of stopwords: "Call of the Wild"
becomes "call", "of-the", "wild".
The bigrams trick is also good if you have people block-copyin
Thanks a lot. I had already implemented Walter's solution and was wondering
if this was the right way to deal with it. This has now given me the
confidence to go with the solution.
Many thanks.
On Fri, Apr 13, 2012 at 1:04 AM, Erick Erickson wrote:
> GAH! I had my head in "make this happen in on
another way is to use payload http://wiki.apache.org/solr/Payloads
the advantage of payload is that you only need one field and can make frq
file smaller than use two fields. but the disadvantage is payload is stored
in prx file, so I am not sure which one is fast. maybe you can try them
both.
On
GAH! I had my head in "make this happen in one field" when I wrote my
response, without being explicit. Of course Walter's solution is pretty
much the standard way to deal with this.
Best
Erick
On Thu, Apr 12, 2012 at 5:38 PM, Walter Underwood wrote:
> It is easy. Create two fields, text_exact a
It is easy. Create two fields, text_exact and text_stem. Don't use the stemmer
in the first chain, do use the stemmer in the second. Give the text_exact a
bigger weight than text_stem.
wunder
On Apr 12, 2012, at 4:34 PM, Erick Erickson wrote:
> No, I don't think there's an OOB way to make this
No, I don't think there's an OOB way to make this happen. It's
a recurring theme, "make exact matches score higher than
stemmed matches".
Best
Erick
On Thu, Apr 12, 2012 at 5:18 AM, Kissue Kissue wrote:
> Hi,
>
> I have a field in my index called itemDesc which i am applying
> EnglishMinimalStem
filter queries (fq) are not included for score calculation, just the
query in q parameter is used for this purpose. That's why although
you get the same results, lucene will just use q=*:* in your 1st query
and q=tag:car in your 2nd query to calculate the scores. As you can
see since both queries
hey,
On Thu, Jan 5, 2012 at 9:31 PM, Christopher Gross wrote:
> I'm getting different results running these queries:
>
> http://localhost:8080/solr/select?&q=*:*&fq=source:wiki&fq=tag:car&sort=score+desc,dateSubmitted+asc&fl=title,score,dateSubmitted&rows=100
>
> http://localhost:8080/solr/select
Indexes cannot be directly compared unless they have similar collection
statistics. That is the same terms occur with the same frequency
across all indexes and the average document lengths are about the same
(though the default similarity in Lucene may not care about average
document length--I
10 matches
Mail list logo
