Thanks Robert, The difference in scores is clear now so it shouldn't matter as queryNorm doesn't affect ranking but coord does. Can you explain why coord is left out now and why it is considered to skew results and why queryNorm skews results? And which specific new ranking algorithms they confuse, BM25F?
Also, i would expect the default SchemaSimilarityFactory to behave the same as DefaultSimilarity this might raise some further confusion down the line. I'll open an issue for the lack of Similarity impl. in the debug output when per-field similarity is enabled. Cheers! -----Original message----- > From:Robert Muir <rcm...@gmail.com> > Sent: Fri 01-Jun-2012 18:16 > To: solr-user@lucene.apache.org > Subject: Re: per-fieldtype similarity not working > > On Fri, Jun 1, 2012 at 11:39 AM, Markus Jelsma > <markus.jel...@openindex.io> wrote: > > Hi! > > > > > > Ah, it makes sense now! This global configured similarity knows returns a > > fieldType defined similarity if available and if not the standard Lucene > > similarity. This would, i assume, mean that the two defined similarities > > below without per fieldType declared similarities would always yield the > > same results? > > Not true: note that two methods (coord and querynorm) are not perfield > but global across the entire query tree. > > By default these are disabled in the wrapper, as they only skew or > confuse most modern scoring algorithms (eg all the new ranking > algorithms in lucene 4) respectively. > > So if you want to do per-field scoring where *all* of your sims are > vector-space, it could make sense to customize (e.g. subclass) > SchemaSimilarityFactory and do something useful for these methods. > > > -- > lucidimagination.com >
