Взвешивание между полями не является проблемой, которой занимаются токенизаторы или фильтры - их задача состоит в том, чтобы взять некоторый входной текст, разбить его на токены (токенизаторы) и затем выполнить его через последовательность шагов обработки (фильтров).
парсеры запросов edismax и dismax имеют параметр с именем qf, который позволяет вам составить список полей, которые должны быть запрошены, и дать отдельный вес для каждого из них - что позволяет вамточно настроить, сколько веса придать каждому полю.qf=title^5 description будет взвешивать попадание в поле title в пять раз больше, чем поле в description - все остальное идентично (но обычно они не идентичны, так как вы не индексируете один и тот же контент в обоих полях)).
И по этой причине оценка не является точной наукой, поэтому, если вы хотите использовать какой-либо показатель релевантности (т. Е. Попадание разных слов даст разные оценки), вам придется настроитьэти веса соответствуют рангу, который вы ищете.Добавление debugQuery=true к запросу очень полезно при настройке скоринга, поскольку оно точно покажет вам, насколько каждый термин вносит вклад в конечную оценку документа.
Ваш первый критерий, title vs description решается с помощью TextField со StandardTokenizer и фильтром нижнего регистра (и в зависимости от того, что вы ищете, необязательно, от синонимов и т. д.).
Вы также (вероятно) захотите использовать фильтр нижнего регистра в примерах, приведенных ниже, но я опустил его, чтобы сохранить компактность примеров.
Ваш второй случай решается наличием второго полятип с EdgeNGramFilter , а затем с двумя новыми полями - title_edge и description_edge, использующими этот тип поля.
И для этого, и для примера NGramFilter ниже используется type="index"атрибут, так как обычно имеет смысл расширять ngrams при индексации.В противном случае любые два слова, начинающиеся с (или для фильтра NGram, содержащие) одинаковые буквы, дают совпадение.
<analyzer type="index">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="40" />
</analyzer>
<analyzer type="query">
<tokenizer class="solr.StandardTokenizerFactory"/>
</analyzer>
Третий критерий решается наличием третьего набора полей, title_ngram и description_ngramкоторый имеет NGramFilter в своей последовательности:
<analyzer type="index">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.NGramFilterFactory"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.StandardTokenizerFactory"/>
</analyzer>
Имейте в виду, что NGramFilter приведет к генерации большого количества токенов, потребует больше памяти и заставит поиск обрабатывать больше токенов при генерацииматч.Это может или не может иметь отношение к вашему случаю использования.
При этом, есть что сказать о сопоставлении внутренних терминов в словах - особенно очень коротких строк.Они могут давать результаты, когда пользователь не может понять, почему документ соответствует, поскольку это может быть небольшое совпадение (одна буква при вводе запроса) где-то.Кто-то, ищущий просто «c», чтобы найти что-то о языке программирования, получит каждый удар, в котором есть слово, содержащее c (но если вы правильно увеличили свои поля, то, к счастью, точное попадание должно быть вверху).