Solr возвращает наивысший ранг не точное соответствие для термина 101 возвращает S101

Question

У меня есть индексированные данные eCommerce с именем поля PartNumber (номера позиций), а данные ежедневно очищаются.

Тип поля в Solr является текстом, потому что поле может содержит цифры, символы или специальные символы, как тир.

Когда я поиск с термином, как:

192.168.xx: хх/Solr/ключевое слово/выберите д = (PartNumber: 101)^2,0 + или + (101) & старт = 0 & строки = 20 = & орфографии истинная & версия = 2.2 & отладки = истинная & фл = *, оценка

результат запроса возвращает: первые 20 строки:

• S101
• 101S
• 101U

Я Пытался PartNumber: "101" и 101 тот же результат всегда возвращается где 101 не занимает первое место.

Примечание: Если срок составляет 4 или более символов (5000,16400, K5125, .. и т.д.) верхний результат лучше, и, как правило, точное совпадение является первым один.

Некоторые из результатов отладки:

<lst name="debug"> 
<str name="rawquerystring">(PartNumber:101)^2.0 OR (101)</str><str name="querystring">(PartNumber:101)^2.0 OR (101)</str> 
<str name="parsedquery">PhraseQuery(PartNumber:"1 10 101"^2.0) PhraseQuery(text:"1 10 101")</str> 
<str name="parsedquery_toString">PartNumber:"1 10 101"^2.0 text:"1 10 101"</str><lst name="explain"> 
<str name="40541432"> 
6.7604995 = (MATCH) sum of: 
    5.1748066 = (MATCH) weight(PartNumber:"1 10 101"^2.0 in 492450) [DefaultSimilarity], result of: 
    5.1748066 = score(doc=492450,freq=1.0 = phraseFreq=1.0 
), product of: 
     0.91124594 = queryWeight, product of: 
     2.0 = boost 
     11.357651 = idf(), sum of: 
      1.5469646 = idf(docFreq=797168, maxDocs=1377508) 
      3.6602204 = idf(docFreq=96332, maxDocs=1377508) 
      6.1504664 = idf(docFreq=7984, maxDocs=1377508) 
     0.040115952 = queryNorm 
     5.6788254 = fieldWeight in 492450, product of: 
     1.0 = tf(freq=1.0), with freq of: 
      1.0 = phraseFreq=1.0 
     11.357651 = idf(), sum of: 
      1.5469646 = idf(docFreq=797168, maxDocs=1377508) 
      3.6602204 = idf(docFreq=96332, maxDocs=1377508) 
      6.1504664 = idf(docFreq=7984, maxDocs=1377508) 
     0.5 = fieldNorm(doc=492450) 
    1.5856929 = (MATCH) weight(text:"1 10 101" in 492450) [DefaultSimilarity], result of: 
    1.5856929 = score(doc=492450,freq=4.0 = phraseFreq=4.0 
), product of: 
     0.4118627 = queryWeight, product of: 
     10.266806 = idf(), sum of: 
      1.407141 = idf(docFreq=916800, maxDocs=1377508) 
      3.1487658 = idf(docFreq=160655, maxDocs=1377508) 
      5.7108994 = idf(docFreq=12392, maxDocs=1377508) 
     0.040115952 = queryNorm 
     3.850052 = fieldWeight in 492450, product of: 
     2.0 = tf(freq=4.0), with freq of: 
      4.0 = phraseFreq=4.0 
     10.266806 = idf(), sum of: 
      1.407141 = idf(docFreq=916800, maxDocs=1377508) 
      3.1487658 = idf(docFreq=160655, maxDocs=1377508) 
      5.7108994 = idf(docFreq=12392, maxDocs=1377508) 
     0.1875 = fieldNorm(doc=492450) 
</str> 

Answer 1

Без знать ваше определение поля для PARTNUMBER мой спекулятивный ответ, что это выглядит как будто вы индексирование и запросы на основе Ngram вида анализа. Если вам нужно использовать ngram, это нормально, сделайте это во время индексации. Но во время анализа времени запроса ngram может дать такие результаты, в этом случае части 101 отлично сочетаются и совпадают с 101S, если вы думаете об этом в своих частях.

Посмотрев на свое определение поля, я не уверен, нужен ли вам PorterStemFilterFactory во время запроса, может быть, он отбрасывает 101 с 101? используйте страницу анализа с панели администратора, чтобы проверить, как обрабатываются данные индекса и запроса для ваших нужд.