The difference seems due to the fact that default similarity in solr 7 is BM25 while it used to be TF-IDF in solr 4. As you realised, BM25 function is smoother. You can configure schema.xml to use ClassicSimilarity, for instance https://lucene.apache.org/solr/guide/6_6/major-changes-from-solr-5-to-solr-6.html#default-similarity-changes https://lucene.apache.org/solr/guide/6_6/field-type-definitions-and-properties.html#FieldTypeDefinitionsandProperties-FieldTypeSimilarity
But as said before, maybe you are using properties that are not guaranteed so it would be better to change score function or sorting (rather than coming back to ClassicSimilarity) 2018-02-22 18:39 GMT+01:00 Shawn Heisey <elyog...@elyograg.org>: > On 2/22/2018 9:50 AM, Hodder, Rick wrote: > >> I am migrating from SOLR 4.10.2 to SOLR 7.1. >> >> All seems to be going well, except for one thing: the score that is >> coming back for the resulting documents is giving different scores. >> > > The absolute score has no meaning when you change something -- the index, > the query, the software version, etc. You can't compare absolute scores. > > What matters is the relative score of one document to another *in the same > query*. The amount of difference is almost irrelevant -- the goal of > Lucene's score calculation gymnastics is to have one document score higher > than another, so the *order* is reasonably correct. > > Assuming you're using the default relevancy sort, does the order of your > search results change dramatically from one version to the other? If it > does, is the order generally better from a relevance standpoint, or > generally worse? If you are specifying an explicit sort, then the scores > will likely be ignored. > > What I am describing is also why it's strongly recommended that you never > try to convert scores to percentages: > > https://wiki.apache.org/lucene-java/ScoresAsPercentages > > Thanks, > Shawn > >
