Используя Solr, как правильно «добавить бусты» вместо «максимального» буста? - PullRequest
Новая
       35

Используя Solr, как правильно «добавить бусты» вместо «максимального» буста?

0 голосов
/ 17 ноября 2018

Используя функцию запроса отладки и взглянув на раздел «объяснение», я понял, что использованные мной повышения: https://stackoverflow.com/a/7701758/7096114 используют сравнение «max of», основанное на результате запроса, сопоставленного с каждым поле. В моей системе у меня есть 10 полей, которые увеличиваются на основе определенных значений. Затем я сортирую результаты по счету в порядке убывания, но я думал, что этот результат будет зависеть от того, сколько очков ему было присуждено за любые поля, которым он соответствовал (всего). Я не осознавал, что счет был установлен на максимальное значение, рассчитанное для любого из повышенных полей. Если бы я хотел расставить приоритеты по результату, который соответствовал бы всем 10 моим полям и имел бы общий балл (например, 500), который выше, чем один результат по результату, который соответствует только 1 из моих полей (например, 100), я не совсем уверен, как бы я справился с этим.

Пример объяснения: 

    320.3237 = sum of:
  0.0069028055 = weight(custom_app:test in 7918) [SchemaSimilarity], result of:
    0.0069028055 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
      0.006641347 = idf(docFreq=48698, docCount=49022)
      1.0393683 = tfNorm, computed from:
        1.0 = termFreq=1.0
        1.2 = parameter k1
        0.75 = parameter b
        1.1020359 = avgFieldLength
        1.0 = fieldLength
  320.3168 = max of:
    73.23891 = weight(name_autocomplete:james in 7918) [SchemaSimilarity], result of:
      73.23891 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
        6.066 = boost
        7.8911004 = idf(docFreq=32, docCount=86884)
        1.5300368 = tfNorm, computed from:
          1.0 = termFreq=1.0
          1.2 = parameter k1
          0.75 = parameter b
          6.527704 = avgFieldLength
          1.0 = fieldLength
    51.871056 = weight(name_partial_match:colin in 7918) [SchemaSimilarity], result of:
      51.871056 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
        4.05 = boost
        7.8603234 = idf(docFreq=33, docCount=86843)
        1.6294072 = tfNorm, computed from:
          1.0 = termFreq=1.0
          1.2 = parameter k1
          0.75 = parameter b
          17.933905 = avgFieldLength
          1.0 = fieldLength
    9.736896 = weight(custom_name_phonetic_en:KLN in 7918) [SchemaSimilarity], result of:
      9.736896 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
        1.6875 = boost
        5.4820786 = idf(docFreq=361, docCount=86884)
        1.0525228 = tfNorm, computed from:
          1.0 = termFreq=1.0
          1.2 = parameter k1
          0.75 = parameter b
          2.9156578 = avgFieldLength
          2.56 = fieldLength
    61.69854 = weight(custom_display_name_partial_match:colin in 7918) [SchemaSimilarity], result of:
      61.69854 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
        5.0625 = boost
        7.532877 = idf(docFreq=46, docCount=86883)
        1.61789 = tfNorm, computed from:
          1.0 = termFreq=1.0
          1.2 = parameter k1
          0.75 = parameter b
          38.531185 = avgFieldLength
          2.56 = fieldLength
    86.66015 = weight(custom_name_autocomplete:colin in 7918) [SchemaSimilarity], result of:
      86.66015 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
        7.5825 = boost
        7.6228366 = idf(docFreq=42, docCount=86884)
        1.4993064 = tfNorm, computed from:
          1.0 = termFreq=1.0
          1.2 = parameter k1
          0.75 = parameter b
          13.767955 = avgFieldLength
          2.56 = fieldLength
    9.267912 = weight(name_phonetic_en:KLN in 7918) [SchemaSimilarity], result of:
      9.267912 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
        1.35 = boost
        6.1070633 = idf(docFreq=193, docCount=86884)
        1.1241279 = tfNorm, computed from:
          1.0 = termFreq=1.0
          1.2 = parameter k1
          0.75 = parameter b
          1.3697113 = avgFieldLength
          1.0 = fieldLength
    320.3168 = weight(name_lowercase:colin in 7918) [SchemaSimilarity], result of:
      320.3168 = score(doc=7918,freq=1.0 = termFreq=1.0
), product of:
        40.1 = boost
        7.9879503 = idf(docFreq=29, docCount=86884)
        1.0 = tfNorm, computed from:
          1.0 = termFreq=1.0
          1.2 = parameter k1
          0.75 = parameter b
          1.0 = avgFieldLength
          1.0 = fieldLength

1 Ответ

0 голосов
/ 20 ноября 2018

Если вы хотите включить части других оценок - за исключением запроса о максимальной оценке - , вы можете использовать параметр tie .

Этот параметр сообщает Solr, сколько из других полей , которые также генерируют попадания, включаются в итоговый счет. Обычно это низкое значение, например 0.1.

Параметр tie указывает значение с плавающей запятой (которое должно быть намного меньше 1) для использования в качестве разрыва связи в запросах DisMax.

Когда термин из пользовательского ввода тестируется для нескольких полей, может совпадать более одного поля. Если это так, каждое поле будет генерировать различную оценку, основанную на том, насколько часто это слово находится в этом поле (для каждого документа относительно всех других документов). Параметр связывания позволяет вам контролировать, насколько на итоговую оценку запроса будут влиять оценки более низких полей оценки по сравнению с самой высокой оценкой поля.

Значение «0.0» - значение по умолчанию - делает запрос чистым «запросом максимального дизъюнкции»: то есть только максимальный подзапрос скоринга вносит свой вклад в итоговую оценку. Значение «1.0» делает запрос чистым «запросом суммы дизъюнкции», где не имеет значения, каков максимальный подзапрос скоринга, потому что окончательный результат будет суммой результатов подзапроса. Обычно полезно низкое значение, такое как 0,1.

...