Sorry, I don't know what you mean by "mimic input boxes". My assumption is your app is like most search apps - there's a single search input box into which people type one or more words.
If so, then it sounds like what you have been asking for is based on the following principles:
- We have a favourite field we always want to boost regardless of what a user typed.
- We make no attempt to favour which field each individual search term naturally belongs to
- We like to think some of the search words in a query are more important than others
If you didn't want rule 3) then you could wrap each search term in a
constant_score query to dispense with IDF completely - because your app knows best (see rule 1)
However, I assume you want rule 3 because users can type a mix of terms in a query eg (
rareWord, commonWord) and given the choice you prefer docs to match
rareWord rather than only match
commonWord. To have this preference you need to know which of these words is rarer - using IDF. The key question is which field do you use to obtain this IDF? The sensible answer is "the most likely one" which is what cross-fields does (other search types typically favour the least likely).
So, bringing this all together - you propose a system that prefers
commonWord based on an understanding of "correct" context (thanks to cross fields) but your rule 1 will just boost "hits in field X" because you think that's a generally good thing to do for all queries, regardless of the context of each search term.