https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23649 --- Comment #27 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- (In reply to Jason Robb from comment #24)
Thanks Pedro!
Applying the patch gets hung up on the first attachment still (146585 - [Do not push] - Experimental support for function_score) but if I skip it everything seems to be working -- does that need obsoleted?
I'm also still seeing an issue with boosts getting completely removed when other changes are made on the page.
To replicate, add some boosts, navigate away and back to the page, boosts are still there. Make changes to something else (i.e. rearrange facet order or add a search field weight on the first tab) then click the yellow "Save" button. Boosts get wiped out.
I'm still fiddling around with testing boosts and search weights but I wanted to make sure those things didn't get lost.
Hi Jason, thank you for this detailed feedback. Addressed in the last follow-up. (In reply to Jason Robb from comment #25)
In testing the searching with the JS from bug 42107 -- $(".search_score").toggle(); -- and adding some weights via the search field settings, things don't seem to be multiplying as I would expect in a way that would prioritize one facet over another.
For example, if I give: - title a Search field weight of 32 - itype a Search field weight of 20 - itype = MU a Relevance boost of 2 - itype = BK a Relevance boost of 0.5
A search for "sugar" will return 3 results. The first two get a score of 64 for a (title match 32 * boost 2). The third result does not have a title match but does have sugar in the record so it only gets a score of 2 (from boost 2). So the title weight is getting multiplied rather than the item type weight in those scenarios.
If I add a book with "sugar" in the title to the mix, it gets a score of 16 (title weight 32 * boost 0.5) so it lands above the third music item.
Could (facet weight * facet boost) be added to the existing search field weight instead? That would lead to results in order in this example of - Sugar music 1: 32 +(20*2) = 72 - Sugar music 2: 32 +(20*2) = 72 - Sugar-adjacent music: (20*2) = 40 - Sugar book: (32*0.5) = 16
I understand we sometimes want a category to outrank a weak text match, i.e. "always show music prominently for this search" is a reasonable thing to want. But we can already do that under multiply, no field weight needed. The boost's own weight is ours to set, we can just set it higher. You used 2 in your test, a mild nudge, exactly what the hint text promises. If we set MU's boost to 20 instead, the "Unconditional" bib record (i.e. 'sugar-adjacent record) scores 1 × 20 = 20, still proportional, still consistent across queries, and now beats the book's 16. Same outcome you wanted, existing knob, no side effects. It's not really multiply vs sum, it's whether the boost weight gives you enough range. It does, up to 999.99. Nothing stops us from setting a boost of 50 if we want something to basically always win. Where sum falls short: +40 only beat 16 because this search happened to produce small base scores (32, ~1). Run a search where scores naturally land in the hundreds, and that same +40 does nothing, buried under real relevance. Run one where scores are tiny, and +40 flattens every result to basically the same rank regardless of actual match quality. We can't predict which you'll get, so a boost of 2 doesn't have a consistent meaning. multiply doesn't have this problem, doubling always means doubling, no matter what search you run. I believe we should keep multiply, we can already get what we're after by raising the boost weight itself. -- You are receiving this mail because: You are watching all bug changes.