Often, for small numbers of distinct types people use grouping and have the app layer mingle them or whatever is pleasing. I think this is different than post-processing you mention. Grouping (aka "field collapsing") can be expensive if there are a large number of groups but for small numbers it's not bad.
The general problem is rather "interesting" in that just relaxing the score doesn't really handle massively different kinds of documents, think of "songs", "albums", and "reviews in rolling stone". You'd probably see a bazillion song entries before the first review entry.... Best, Erick On Fri, Apr 24, 2015 at 2:36 AM, Paul Libbrecht <p...@hoplahup.net> wrote: > Hello list, > > I'm wondering if there could extra parameters or query operators that > where I could impose that sorting by relevance should be relaxed so that > there's a minimum diversity in some fields in the first page of results. > > For example, I'd like the search results to contain at least three > possible type of resources in the first page, fetching things from below > if needed. > I know that could be done as a search result post-processor but I think > that this is generally a bad idea for performance. > > Any other idea? > > thanks > > Paul >
