Add explanation to runtime field query #63429
Conversation
This adds a `detail` to the output of `explain` for runtime fields queries that makes it clear that their score is entirely based on their boost. We don't have any tf/idf/norms/whatever to do any scoring - we just score `boost`.
nik9000
added
>bug
:Search/Search
|
Pinging @elastic/es-search (:Search/Search) |
| - match: {hits.hits.0._explanation.details.0.value: 1.0} | ||
| - match: {hits.hits.0._explanation.details.0.description: 'runtime field query scoring boost'} | ||
| - match: {hits.hits.0._explanation.details.0.details: []} | ||
|
|
There was a problem hiding this comment.
I went with fairly simple integration tests for this instead of unit tests because it felt easier. I could go either way, but I think this gets the job done.
There was a problem hiding this comment.
thats fine with me, maybe a small unit test for the lucene query would be also useful?
| day_of_week: Monday | ||
| - match: {hits.hits.0._explanation.description: day_of_week:Monday} | ||
| - match: {hits.hits.0._explanation.details.0.value: 1.0} | ||
| - match: {hits.hits.0._explanation.details.0.description: 'runtime field query scoring boost'} |
There was a problem hiding this comment.
I am being picky about the description: the boost is provided with a query right? I am wondering if the boost itself has anything special, specifically related to runtime fields. It feels to me that the boost is just a boost, what is special is that with runtime fields it's the only factor in scoring calculation. What I am getting to is that we could make the detail even clearer, probably. Thinking out loud: should we have two items in details, one that is a constant, that explains that the field is a runtime fields, and the other one that is the actual query boost?
Maybe we should have a couple more tests around providing a boost with the query, and customizing the score with a script?
There was a problem hiding this comment.
Your proposal for the details makes sense to me. I'll make that change. I'll add a test with a boost certainly. What are you thinking as far as scripting changing the score? I think we usually do that by wrapping the query in a script score, right?
There was a problem hiding this comment.
I think we usually do that by wrapping the query in a script score, right?
yes that is what I meant
| - match: {hits.hits.0._explanation.details.0.value: 1.0} | ||
| - match: {hits.hits.0._explanation.details.0.description: 'runtime field query scoring boost'} | ||
| - match: {hits.hits.0._explanation.details.0.details: []} | ||
|
|
There was a problem hiding this comment.
thats fine with me, maybe a small unit test for the lucene query would be also useful?
This adds a `detail` to the output of `explain` for runtime fields queries that makes it clear that their score is entirely based on their boost. We don't have any tf/idf/norms/whatever to do any scoring - we just score `boost`.
This adds a `detail` to the output of `explain` for runtime fields queries that makes it clear that their score is entirely based on their boost. We don't have any tf/idf/norms/whatever to do any scoring - we just score `boost`.
This adds a
detailto the output ofexplainfor runtime fieldsqueries that makes it clear that their score is entirely based on their
boost. We don't have any tf/idf/norms/whatever to do any scoring - we
just score
boost.