Проблема повышения поля запроса в solr, когда повышенный термин присутствует более чем в 1 поле

У меня есть 4 поля в solr. Например Field1, Field2, Field3 and Field4.

Моя последовательность повышения похожа на field1^10, field2^8, field3^7 field4^6.

Теперь, если я ищу маркетинг по ключевому слову, скажем, q=(Field1:("marketing")^10 OR Field2:("marketing")^8 OR Field3:("marketing")^7 OR Field4:("marketing")^6).

Требование: теперь, согласно требованию, маркетинг, представленный в field1, должен отображаться первым и так далее, что работает нормально.

Проблема: но есть одна запись, в которой маркетинг появляется в Field3 и Field4, и он появляется на втором месте в результате, в то время как запись, содержащая маркетинг в поле 2, появляется на третьем месте в результате, что, вероятно, связано с механизмом подсчета очков.

Решение, которое мне нужно: я хочу показывать записи в порядке повышения, примененного в этом поле, независимо от того, найдено ли оно в нескольких полях, т. е. запись с маркетингом в поле 2 всегда должна отображаться второй в результате.


person lalit S. joshi    schedule 25.03.2019    source источник
comment
Возможно, вам придется изменить стратегию продвижения, так как все поисковые запросы в конечном итоге являются суммой.   -  person Oyeme    schedule 25.03.2019
comment
@Oyeme извините за орфографическую ошибку. это только техника повышения, которую я могу придумать. Более того, поисковый запрос останется одинаковым для всех полей. Нашему клиенту просто нужно заказать в вышеупомянутых полях и в сценарии, упомянутом выше. Пожалуйста, дайте мне знать, если у вас есть какие-либо решения для этого. Спасибо за ответ.   -  person lalit S. joshi    schedule 25.03.2019
comment
Имейте в виду, что на баллы будет влиять не только повышение (например, количество вхождений и т. д.). Однако вы можете попытаться увеличить свои повышения, чтобы иметь гораздо большую разницу между различными уровнями — поле 1 ^ 100 000, поле 2 ^ 10 000, поле 3 ^ 1000 поле 4 ^ 100 — таким образом, при одинаковом содержании два последующих поля не будут суммироваться. больший импульс, чем те, что были до него.   -  person MatsLindh    schedule 25.03.2019
comment
@MatsLindh большое спасибо за ответ. Это сработало для меня очень хорошо. моя проблема решена.   -  person lalit S. joshi    schedule 26.03.2019


Ответы (2)


Ответ, данный @MatsLindh в комментариях, является правильным решением:

Однако вы можете попытаться увеличить свои повышения, чтобы иметь гораздо большую разницу между различными уровнями - field1^100000, field2^10000, field3^1000 field4^100 - таким образом, при одинаковом содержании два последующих поля не будут в сумме давать большее усиление, чем предыдущие.

Примечание. Имейте в виду, что на баллы влияет не только усиление (например, количество вхождений и т. д.).

person lalit S. joshi    schedule 26.03.2019

Я могу думать о двух способах решения этой проблемы:

  1. Используйте параметр запроса qf - если вы передаете поля и загружаетесь в параметре qf вместо q, чтобы ваш запрос выглядел примерно так: q=marketing&qf="field1^10 field2^8, field3^7 field4^6", тогда проанализированный запрос будет примерно таким: max(field1:marketing^10,field2:marketing^8,field3:marketing^7 OR , field4:marketing^6), поэтому не имеет значения, в скольких полях они появляются. это займет только макс.

  2. Измените усиления так, чтобы каждое значение повышения было выше, чем сумма повышений перед ним. например: field4^1, field3^2, field2^4, field1^8, таким образом никакая комбинация полей не может повлиять на порядок.

person Tomer Arazy    schedule 26.03.2019
comment
Спасибо за ответ. Но я думаю, что не смогу использовать параметр qf, так как мы используем SiteCore Content Search Linq для запроса solr, и, насколько мне известно, я могу использовать только q и fq, но для qf нет возможности. Но я буду признателен за ваше объяснение, и это расширит мои знания о повышении solr. - person lalit S. joshi; 26.03.2019
comment
будет приниматься только предположение max.. false, если только не используется анализатор запросов dismax/edismax со связью 0. - person EricLavault; 15.04.2019