# Are there case studies about using intermediate queries in a search?

**URL:** <https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018>\
**Category:** Elasticsearch\
**Created:** [December 16, 2018, 9:33am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018 "2018-12-16T09:33:00Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![AlexisWilke](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alexiswilke/32/38600_2.png) [@AlexisWilke](https://discuss.elastic.co/u/AlexisWilke)\
**Post date:** [December 16, 2018, 9:33am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/1 "2018-12-16T09:33:00Z")

</div>

I want to allow my users to filter their search results by various tags.

Imagine a WordPress like website where each blog post has a set of tags.

When my users go to the advanced search page, they can select a number of tags to filter the results by. Pages that are not assigned those tags will not be returned in the results.

Right now I have two tables and two indexes:

Table A — the page content (blog post in plain text)

Table B — the tag name and a reference back to Table A (i.e. many to many)

When I do a search (I have preliminary code that already works with Elassandra), I first search Table B for the tags. This is really fast since I can use a `term { ... }` search. I get a set of references to pages in Table A. (say one UUID per page)

Next, I do a second search against Table A. This time I use two types of searches:

1. A query string with the text the user entered.
2. One `term { ... }` per result I found in the first search.

I think that all of that works as expected as it is. I could not see how to do a join otherwise (there are some problems with Elassandra, maybe it will become possible one day with my schema...)

Now, when I search Table B, I get results and each result has a `{ _score: ... }`, which are ignored when I do the next search. Reading the documentation, I saw that we could use the `{ boost: ... }` parameter to tweak scores "manually".

What I'm wondering is whether there is a standard way to handle this scenario? I would be interested by existing research documents in that realm if you know of such. Or maybe just a good ol' blog post about filtering in a similar way as mine.

My current idea would be to change the `term` by adding the `boost` parameter in there:

`"term": { "<field-name>": { "value": "<some-UUID", "boost": "<Table B Search _score>" } }`

At the same time, I know of the `filter` from the `bool` query and if I were to add my `term` queries in there, I know that the score would be ignored. There may be a reason why it was done that way, i.e. to help with cases like mine?

Thank you.  
Alexis

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [December 16, 2018, 9:40am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/2 "2018-12-16T09:40:59Z")

</div>

The only way you can do this is by tracking the score in your client and then passing that to the second query. Elasticsearch cannot do this for you.

---

<div class="post-metadata">

**Author:** ![AlexisWilke](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alexiswilke/32/38600_2.png) [@AlexisWilke](https://discuss.elastic.co/u/AlexisWilke)\
**Post date:** [December 16, 2018, 9:47am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/3 "2018-12-16T09:47:01Z")

</div>

Okay, that's what I was thinking. Thank you for the fast answer!

Is the `_score` result a one to one equivalent to the `boost` parameters?

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [December 16, 2018, 9:49am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/4 "2018-12-16T09:49:24Z")

</div>

Well they are both numbers, so you can just use that as the boost, sure. That's where it ends.

Thing is though, unless your index _never_ changes, then your scores will never be static.

---

<div class="post-metadata">

**Author:** ![AlexisWilke](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alexiswilke/32/38600_2.png) [@AlexisWilke](https://discuss.elastic.co/u/AlexisWilke)\
**Post date:** [December 16, 2018, 9:56am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/5 "2018-12-16T09:56:46Z")

</div>

Do you know of any document/discussion about how the `_score` gets calculated?

Thank you.  
Alexis

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [December 16, 2018, 9:58am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/6 "2018-12-16T09:58:02Z")

</div>

We use the BM25 algorithm for scoring (at least, if you run 6.X). There's tonnes out there on that, but I am not sure what you're expecting so it's hard to suggest something.

---

<div class="post-metadata">

**Author:** ![AlexisWilke](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alexiswilke/32/38600_2.png) [@AlexisWilke](https://discuss.elastic.co/u/AlexisWilke)\
**Post date:** [December 16, 2018, 10:03am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/7 "2018-12-16T10:03:42Z")

</div>

That looks great. I'll be checking into this further to see that I use the data correctly. For those interested there is the Wikipedia article:

> **[Okapi BM25](https://en.wikipedia.org/wiki/Okapi_BM25)**
>
> In information retrieval, Okapi BM25 (BM stands for Best Matching) is a ranking function used by search engines to rank matching documents according to their relevance to a given search query. It is based on the probabilistic retrieval framework developed in the 1970s and 1980s by Stephen E. Robertson, Karen Spärck Jones, and others.
> The name of the actual ranking function is BM25. To set the right context, however, it is usually referred to as "Okapi BM25", since the Okapi information retrieval...

---

<div class="post-metadata">

**Author:** ![AlexisWilke](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alexiswilke/32/38600_2.png) [@AlexisWilke](https://discuss.elastic.co/u/AlexisWilke)\
**Post date:** [December 18, 2018, 6:14am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/8 "2018-12-18T06:14:47Z")

</div>

I also found a page about boosting by popularity on [Elastic.co](http://Elastic.co) which may be of interest. This shows how one can use a vote score to boost the scores of results within reason. A similar solution could be used to modify the scores of the second query from the scores of the first query, opposed to using the boost parameter which is quite linear used on its own and may not be appropriate in your situation.

[https://www.elastic.co/guide/en/elasticsearch/guide/master/boosting-by-popularity.html](https://www.elastic.co/guide/en/elasticsearch/guide/master/boosting-by-popularity.html)

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 15, 2019, 6:14am UTC](https://discuss.elastic.co/t/are-there-case-studies-about-using-intermediate-queries-in-a-search/161018/9 "2019-01-15T06:14:51Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
