# Partially matched shorter field takes precedence over completely matched larger field **URL:** \ **Category:** Elasticsearch\ **Created:** [November 21, 2017, 7:25am UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523 "2017-11-21T07:25:54Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![aniketkk](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aniketkk/32/96814_2.png) [@aniketkk](https://discuss.elastic.co/u/aniketkk)\ **Post date:** [November 21, 2017, 7:25am UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/1 "2017-11-21T07:25:54Z")
Hi, I have two fields in my index on which I am querying. One is the **title** and another is **content**. Content is a big field and contains entire content of an article. Both fields have the same analyzer with min\_gram as 3 and max\_gram as 20. Now the problem is when I search for a term and if the term completely matches the content field and partially matches the title field, title field takes precedence. For example, I was searching for a term called **hacking**. Now there is a document which **contains hacking in its content field**. And there are **multiple docs whose title contains tracking** (which is not hacking by any means). But when I do a query with hacking, all the tracking results come on top and hacking is in somewhere third or fourth page of results. This is not what I expect. Hacking result should come on top. When I check the score the one with tracking as title gets 0.6 as score and one with hacking in the content gets 0.08 as the score, even though I have queried with Hacking. My query looks like this ``` { "query": { "multi_match" : { "query": "hacking", "fields": ["title", "content"] } } } ``` I understand that shorter field always will be scored more. But that is not what is expected. Please help how to fix this. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [November 21, 2017, 7:51am UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/2 "2017-11-21T07:51:59Z")
You can boost the title field ``` “title^5” ``` For example ---
**Author:** ![aniketkk](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aniketkk/32/96814_2.png) [@aniketkk](https://discuss.elastic.co/u/aniketkk)\ **Post date:** [November 21, 2017, 10:08am UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/3 "2017-11-21T10:08:57Z")
@dadoonet You mean the content field because **content is a larger field**. Anyway even after I boost the content field, the results are not satisfactory though it is better than before. Can't we make exact match get the first precedence no matter in which field it is present and then partial matches can come in the search results? ---
**Author:** ![Mikhail\_Khludnev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mikhail_khludnev/32/59591_2.png) [@Mikhail\_Khludnev](https://discuss.elastic.co/u/Mikhail_Khludnev)\ **Post date:** [November 21, 2017, 10:25am UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/4 "2017-11-21T10:25:34Z")
You need to have a field without ngrams (see copy fields or multifields), include it search with high boost. It should resolve the problem. However, I suppose using ngramms is obviously bad idea. ---
**Author:** ![aniketkk](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aniketkk/32/96814_2.png) [@aniketkk](https://discuss.elastic.co/u/aniketkk)\ **Post date:** [November 21, 2017, 11:50am UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/5 "2017-11-21T11:50:18Z")
Why do you think using ngrams is a bad idea? Otherwise how can we do partial searching? ---
**Author:** ![Mikhail\_Khludnev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mikhail_khludnev/32/59591_2.png) [@Mikhail\_Khludnev](https://discuss.elastic.co/u/Mikhail_Khludnev)\ **Post date:** [November 21, 2017, 12:00pm UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/6 "2017-11-21T12:00:44Z")
> Why do you think using ngrams is a bad idea? They are darn expensive. Spoils results with overwhelming recall that you exactly fighting with. > Otherwise how can we do partial searching? you probably need to provide suggester/auto-complete/spellchecking functionality. Returning everything always (with ngramms) is not usually preferred. Nevertheless. It's not a point. Have you solved your relevancy problem? ---
**Author:** ![aniketkk](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aniketkk/32/96814_2.png) [@aniketkk](https://discuss.elastic.co/u/aniketkk)\ **Post date:** [November 22, 2017, 1:15pm UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/7 "2017-11-22T13:15:35Z")
Thanks @Mikhail_Khludnev. I am reconsidering the ngram and the configurations for it. And I solved by using the following answer in stackoverflow that I asked. > ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 20, 2017, 1:15pm UTC](https://discuss.elastic.co/t/partially-matched-shorter-field-takes-precedence-over-completely-matched-larger-field/108523/8 "2017-12-20T13:15:38Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.