#solr #scoring
#solr #оценка
Вопрос:
У меня есть следующие записи и оценки по ним, когда я ищу «iphone» —
Запись 1: имя_поля — Имя_дисПлея: «Iphone» Имя_поля: «Iphone»
11.654595 = (MATCH) sum of:
11.654595 = (MATCH) max plus 0.01 times others of:
7.718274 = (MATCH) weight(DisplayName:iphone^10.0 in 915195), product of:
0.6654692 = queryWeight(DisplayName:iphone^10.0), product of:
10.0 = boost
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.0057376726 = queryNorm
11.598244 = (MATCH) fieldWeight(DisplayName:iphone in 915195), product of:
1.0 = tf(termFreq(DisplayName:iphone)=1)
11.598244 = idf(docFreq=484, maxDocs=19431244)
1.0 = fieldNorm(field=DisplayName, doc=915195)
11.577413 = (MATCH) weight(Name:iphone^15.0 in 915195), product of:
0.99820393 = queryWeight(Name:iphone^15.0), product of:
15.0 = boost
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.0057376726 = queryNorm
11.598244 = (MATCH) fieldWeight(Name:iphone in 915195), product of:
1.0 = tf(termFreq(Name:iphone)=1)
11.598244 = idf(docFreq=484, maxDocs=19431244)
1.0 = fieldNorm(field=Name, doc=915195)
Запись 2:
Имя_поля — Имя_дисПлея: «Книга для iPhone»
FieldName — Название: «Книга для Iphone»
7.284122 = (MATCH) sum of:
7.284122 = (MATCH) max plus 0.01 times others of:
4.823921 = (MATCH) weight(DisplayName:iphone^10.0 in 453681), product of:
0.6654692 = queryWeight(DisplayName:iphone^10.0), product of:
10.0 = boost
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.0057376726 = queryNorm
7.2489023 = (MATCH) fieldWeight(DisplayName:iphone in 453681), product of:
1.0 = tf(termFreq(DisplayName:iphone)=1)
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.625 = fieldNorm(field=DisplayName, doc=453681)
7.2358828 = (MATCH) weight(Name:iphone^15.0 in 453681), product of:
0.99820393 = queryWeight(Name:iphone^15.0), product of:
15.0 = boost
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.0057376726 = queryNorm
7.2489023 = (MATCH) fieldWeight(Name:iphone in 453681), product of:
1.0 = tf(termFreq(Name:iphone)=1)
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.625 = fieldNorm(field=Name, doc=453681)
Запись 3:
Имя_поля — Имя_дисПлея: «iPhone»
FieldName — Имя поля: «iPhone»
7.284122 = (MATCH) sum of:
7.284122 = (MATCH) max plus 0.01 times others of:
4.823921 = (MATCH) weight(DisplayName:iphone^10.0 in 5737775), product of:
0.6654692 = queryWeight(DisplayName:iphone^10.0), product of:
10.0 = boost
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.0057376726 = queryNorm
7.2489023 = (MATCH) fieldWeight(DisplayName:iphone in 5737775), product of:
1.0 = tf(termFreq(DisplayName:iphone)=1)
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.625 = fieldNorm(field=DisplayName, doc=5737775)
7.2358828 = (MATCH) weight(Name:iphone^15.0 in 5737775), product of:
0.99820393 = queryWeight(Name:iphone^15.0), product of:
15.0 = boost
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.0057376726 = queryNorm
7.2489023 = (MATCH) fieldWeight(Name:iphone in 5737775), product of:
1.0 = tf(termFreq(Name:iphone)=1)
11.598244 = idf(docFreq=484, maxDocs=19431244)
0.625 = fieldNorm(field=Name, doc=5737775)
Почему Record2 и Record3 имеют одинаковую оценку, когда record2 содержит 3 слова, а record3 — только одно слово. Таким образом, запись 3 должна иметь более высокую релевантность, чем запись 2. Почему нормы полей для записей Record2 и Record3 одинаковы?
Анализатор запросов: Dismax FieldType: тип текстового поля по умолчанию в solrconfig.xml
Добавление потока данных:
Запись 1: Iphone
{
"ListPrice":1184.526,
"ShipsTo":1,
"OID":"190502",
"EAN":"9780596804299",
"ISBN":"0596804296",
"Author":"Pogue, David",
"product_type_fq":"Books",
"ShipmentDurationDays":"21",
"CurrencyValue":"24.9900",
"ShipmentDurationText":"NORMALLY SHIPS IN 21 BUSINESS DAYS",
"Availability":0,
"COD":0,
"PublicationDate":"2009-08-07 00:00:00.0",
"Discount":"25",
"SubCategory_fq":"Hardware",
"Binding":"Paperback",
"Category_fq":"Non Classifiable",
"ShippingCharges":"0",
"OIDType":8,
"Pages":"397",
"CallOrder":"0",
"TrackInventory":"Ingram",
"Author_fq":"Pogue, David",
"DisplayName":"Iphone",
"url":"/iphone-pogue-david/books/9780596804299.htm",
"CurrencyType":"USD",
"SubSubCategory":"Handheld Devices",
"Mask":0,
"Publisher":"Oreilly amp; Associates Inc",
"Name":"Iphone",
"Language":"English",
"DisplayPriority":"999",
"rowid":"books_9780596804299"
}
Запись 2: Книга для Iphone
{
"ListPrice":1184.526,
"ShipsTo":1,
"OID":"94694",
"EAN":"9780321534101",
"ISBN":"0321534107",
"Author":"Kelby, Scott/ White, Terry",
"product_type_fq":"Books",
"ShipmentDurationDays":"21",
"CurrencyValue":"24.9900",
"ShipmentDurationText":"NORMALLY SHIPS IN 21 BUSINESS DAYS",
"Availability":1,
"COD":0,
"PublicationDate":"2007-08-13 00:00:00.0",
"Discount":"25",
"SubCategory_fq":"Handheld Devices",
"Binding":"Paperback",
"BAMcategory_src":"Computers",
"Category_fq":"Computers",
"ShippingCharges":"0",
"OIDType":8,
"Pages":"219",
"CallOrder":"0",
"TrackInventory":"Ingram",
"Author_fq":"Kelby, Scott/ White, Terry",
"DisplayName":"The Iphone Book",
"url":"/iphone-book-kelby-scott-white-terry/books/9780321534101.htm",
"CurrencyType":"USD",
"SubSubCategory":" Handheld Devices",
"BAMcategory_fq":"Computers",
"Mask":0,
"Publisher":"Pearson P T R",
"Name":"The Iphone Book",
"Language":"English",
"DisplayPriority":"999",
"rowid":"books_9780321534101"
}
Запись 3: iPhone
{
"ListPrice":278.46,
"ShipsTo":1,
"OID":"694715",
"EAN":"9781411423527",
"ISBN":"1411423526",
"Author":"Quamut (COR)",
"product_type_fq":"Books",
"ShipmentDurationDays":"21",
"CurrencyValue":"5.9500",
"ShipmentDurationText":"NORMALLY SHIPS IN 21 BUSINESS DAYS",
"Availability":0,
"COD":0,
"PublicationDate":"2010-08-03 00:00:00.0",
"Discount":"25",
"SubCategory_fq":"Hardware",
"Binding":"Paperback",
"Category_fq":"Non Classifiable",
"ShippingCharges":"0",
"OIDType":8,
"CallOrder":"0",
"TrackInventory":"BNT",
"Author_fq":"Quamut (COR)",
"DisplayName":"iPhone",
"url":"/iphone-quamut-cor/books/9781411423527.htm",
"CurrencyType":"USD",
"SubSubCategory":"Handheld Devices",
"Mask":0,
"Publisher":"Sterling Pub Co Inc",
"Name":"iPhone",
"Language":"English",
"DisplayPriority":"999",
"rowid":"books_9781411423527"
}
Комментарии:
1. Не вижу никакой разницы между записью 1 и записью 3, поэтому я не вижу причин, по которым результаты будут отличаться. Можете ли вы подтвердить, что оценки принадлежат записи 3, и предоставить дополнительную информацию о анализаторе запросов, типах полей и введенных данных?
2. Привет, я использую анализатор запросов dismax, и оценки принадлежат записи 3. Я перепроверил, и оценка всех 3 записей соответствует указанной мной. Типы полей являются типом поля «текст» по умолчанию, определенным в solrconfig.xml .
3. можете ли вы также предоставить поток данных?
4. Привет, Джайендра.. Я отредактировал свой вопрос с помощью ленты.. Спасибо..
Ответ №1:
норма полей учитывает длину поля, то есть количество терминов.
Используемый тип поля — это текст для отображаемого имени полей и name, который должен содержать фильтры стоп-слов и разделителей слов.
Запись 1 — Iphone
Сгенерировал бы один токен — IPhone
Запись 2 — The Iphone Book
Сгенерировал бы 2 токена — Iphone, Book
Это было бы удалено стоп-словами.
Запись 3 — iPhone
Также будет генерироваться 2 токена — i,phone
Поскольку в iPhone изменен регистр, фильтр-разделитель слов с помощью splitOnCaseChange теперь разделил бы iPhone на 2 токена i, Phone и создал бы норму поля, такую же, как в записи 2
Комментарии:
1. Привет, Джайендра, спасибо.. Имеет смысл. Но для другого набора данных я получаю неправильную релевантность. Запись 1: «Настоящий Код Да Винчи» и запись 2: «Код да Винчи». Когда я ищу «Код да Винчи», я получаю одинаковые оценки для обеих записей, потому что полевая норма одинакова. Он использует тот же тип поля «текст». Используя SolrAnalysis, я вижу, что запись 1 заменена на «реальный код да Винчи», а запись 2 — на «код да Винчи» (время индексации). Тогда почему две оценки одинаковы.
2. можете ли вы предоставить поле данных и оценку отладки?
3. Привет, Джайендра, поле данных — «текст». Я добавил оценку отладки как часть ответа.
Ответ №2:
Это ответ на последующий вопрос пользователя 1021590 в примере поиска «Код да Винчи».
Причина, по которой все документы получают одинаковую оценку, связана с тонкой детализацией реализации lengthNorm. В документе Lucence TFIDFSimilarity говорится следующее о norm(t, d) :
полученное значение нормы кодируется как один байт перед сохранением. Во время поиска значение в нормальном байте считывается из индексного каталога и декодируется обратно в нормальное значение с плавающей точкой. Это кодирование / декодирование, хотя и уменьшает размер индекса, сопряжено с потерей точности — не гарантируется, что decode(encode(x)) = x . Например, decode(encode(0.89)) = 0.75.
Если вы покопаетесь в коде, вы увидите, что это кодирование с плавающей запятой в байтах реализовано следующим образом:
public static byte floatToByte315(float f)
{
int bits = Float.floatToRawIntBits(f);
int smallfloat = bits >> (24 - 3);
if (smallfloat <= ((63 - 15) << 3))
{
return (bits <= 0) ? (byte) 0 : (byte) 1;
}
if (smallfloat >= ((63 - 15) << 3) 0x100)
{
return -1;
}
return (byte) (smallfloat - ((63 - 15) << 3));
}
и декодирование этого байта в float выполняется как:
public static float byte315ToFloat(byte b)
{
if (b == 0)
return 0.0f;
int bits = (b amp; 0xff) << (24 - 3);
bits = (63 - 15) << 24;
return Float.intBitsToFloat(bits);
}
lengthNorm вычисляется как 1 / sqrt( number of terms in field ) . Затем это кодируется для хранения с использованием floatToByte315 . Для поля с 3 терминами мы получаем:
floatToByte315( 1/sqrt(3.0) ) = 120
и для поля с 4 терминами мы получаем:
floatToByte315( 1/sqrt(4.0) ) = 120
таким образом, оба они декодируются в:
byte315ToFloat(120) = 0.5 .
В документе также указано это:
Обоснование, поддерживающее такое сжатие значений нормы с потерями, заключается в том, что, учитывая сложность (и неточность) пользователей выразить свою истинную потребность в информации с помощью запроса, имеют значение только большие различия.
ОБНОВЛЕНИЕ: Начиная с версии Solr 4.10, эта реализация и соответствующие инструкции являются частью DefaultSimilarity.
Комментарии:
1. привет, я сталкиваюсь с той же проблемой .. для документов с 3 и 4 терминами fieldNorm одинакова и, таким образом, влияет на результаты поиска. Есть ли какое-либо решение для этого?
2. Я буду использовать метод класса lengthNorm и попытаюсь обработать его специально для документов длиной 3 и 4..