Поиск числовых данных с помощью Solr

Я использую Solr для (необычного?) случая использования ранжированных результатов для числовых данных./

  1. Скажем, у меня есть набор записей набора объектов O {O1...On}, и для каждого из этих объектов у меня есть несколько измерений: например. Вязкость, пористость, проницаемость и т.д.

  2. Для объекта On+1 мне нужно выполнить поиск в приведенном выше наборе записей, чтобы найти наиболее «похожие» (по нескольким измерениям вязкости, пористости, проницаемости) и т. д.

  3. Поскольку набор записей O состоит из сотен миллионов записей, практически невозможно сопоставить каждую метрику сходства, такую ​​как косинус или Минковский. Мне нужно сократить набор результатов до примерно 100 лучших кандидатов, и я использую Solr для запуска запроса.

Я запускаю запрос диапазона, используя параметры объекта On+1, например. Пористость между [9,5 ДО 10,5], т. е. +/- 5% от значения, и логический запрос связывает их, чтобы получить ранжированный список совпадений.

Мои вопросы:

  1. Есть ли лучший способ сделать это и получить оценку от Solr, которую я мог бы использовать, возможно, для порога. Текущая оценка метода запроса диапазона, похоже, следует ступенчатой ​​​​функции и бесполезна.

  2. Могу ли я сохранить числа в формате text_general и выполнить поиск, используя номера запросов? Поскольку строки quert могут работать очень долго, я не знаю, как к этому подойти, возможно, используя MLT?

Есть идеи? или предложения для других наборов инструментов, чтобы помочь с вышеизложенным?


database search solr numerical-methods search-engine
person Mikos    schedule 19.12.2013    source источник
comment
Как это сходство должно работать для конечного пользователя? Могут ли они искать похожие результаты только в самих результатах (например, выбрать документ с результатами и получить сходство), или они также должны предоставить входные данные, которые будут использоваться в качестве основы для сходства, или и то, и другое?   -  person rchukh    schedule 19.12.2013
comment
На самом деле это будет и то, и другое, т.е. пользователь загружает значения объектов, и мы представляем набор результатов, из которого они также могут искать похожие.   -  person Mikos    schedule 20.12.2013

Ответы (1)


arrow_upward
2
arrow_downward

Теория

Как вы сказали, запрос диапазона не будет работать здесь для подсчета очков... но это все же хороший способ отфильтровать исходный индекс.

После того, как индекс отфильтрован (или нет) с помощью некоторого базового запроса, мы можем применить пользовательскую оценку.

Вот некоторый общий пример того, как реализовать пользовательскую оценку: http://spykem.blogspot.com/2013/06/plug-in-external-score-to-solr.html

При реализации пользовательской сортировки — CustomScoreProvider может получить следующие параметры:

  • Шаг значения - шаг для снижения оценки
  • Шаг оценки - снижайте оценку на это значение всякий раз, когда происходит «шаг значения».
  • Максимальная дополнительная оценка — «идеальное совпадение» будет иметь эту оценку в дополнение к собственной оценке (из регулярного поискового запроса), неидеальные совпадения будут иметь пониженное (неотрицательное) значение.

Дополнительный балл будет снижаться на «Шаг оценки» каждый раз, когда расстояние между значением поля и значением запроса будет увеличиваться на «Шаг значения», начиная с «Максимального дополнительного балла» и до тех пор, пока не достигнет нуля.

Дополнительная формула подсчета очков будет выглядеть примерно так (пока не достигнет нуля):

Max additional score - ((|fieldValue - queryValue| / Value Step ) * Score Step)

Пример

Так, например, имея следующие настройки:

  • Шаг значения = 0,1
  • Шаг оценки = 0,01
  • Максимальный дополнительный балл = 1

со следующими значениями индекса для некоторого поля (например, проницаемость):

  • 3 (для документа 1)
  • 5 (для документа 2)
  • 6 (для документа 3)
  • 7 (для документа 4)
  • 99999999 (для документа 5)

и если исходный поисковый запрос выглядит так:

q={!nearestParser valueStep=0.1 scoreStep=0.01 maxStep=1}permeability:5

Затем результат будет выглядеть так (при условии, что начальная оценка одинакова (1) для всех документов)

  • doc2 (с оценкой - 2,0)
  • doc3 (с оценкой - 1,9)
  • doc1 (с оценкой - 1,8)
  • doc4 (с оценкой - 1,8)
  • doc5 (с оценкой - 1)

Заключение:

  • Doc2 будет иметь лучший результат, так как это идеальное совпадение
  • Doc3 будет вторым, так как он максимально близок (без идеального совпадения) к предпочитаемому входу (и в пределах досягаемости)
  • Doc1 и doc4 будут иметь одинаковую оценку, так как они оба находятся на одинаковом расстоянии от исходного поискового запроса.
  • Doc5 будет иметь первоначальный балл, так как он выходит за рамки диапазона, чтобы считаться «похожим».

Я постараюсь привести какой-нибудь практический пример, но, поскольку это займет некоторое время, я думаю, что сейчас будет лучше ответить с идеей.

Другое возможное решение

Прочитав о NumericRangeQuery, я также идея об использовании структуры поля Trie * (точнее, использовать ее способность эффективно обрабатывать числовой диапазон поиска), чтобы найти самое ближайшее значение из индекса... но пока не понял, как это сделать.

Это потенциально может быть намного более производительным, хотя и намного более сложным... и все еще есть шанс, что структура Trie* не сможет справиться с такой операцией...

person rchukh    schedule 19.12.2013