Solr - японские и длинные гласные - PullRequest
Новая
       35

Solr - японские и длинные гласные

0 голосов
/ 13 декабря 2018

Итак, я столкнулся с интересной проблемой.Я пытаюсь оптимизировать свои индексы solr в Японии для японских символов.

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

Но если вы ищите ビ ー ム エ キ ス パ ン ダ ン, это то же самое слово, но минус длинная отметка в конце, что оно не возвращает никаких результатов.Наш индексированный контент содержит все данные, но мы хотим, чтобы по сути, было решено включить контент, даже если вы не выполняете поиск по длинной метке, чтобы включить контент с длинной меткой.

Это то, как выглядит наша японская схемадля полей, на которые я смотрю. 

  <fieldType name="text_general" class="solr.TextField" positionIncrementGap="100" multiValued="true">
    <analyzer type="index">
    <tokenizer class="solr.JapaneseTokenizerFactory" mode="search" userDictionary="lang/userdict_ja.txt"/>
    <filter class="solr.SynonymGraphFilterFactory" expand="true" ignoreCase="true" synonyms="synonyms.txt" />
    <filter class="solr.JapaneseBaseFormFilterFactory"/>
    <filter class="solr.JapanesePartOfSpeechStopFilterFactory" tags="lang/stoptags_ja.txt"/>
    <filter class="solr.CJKWidthFilterFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_ja.txt"/>
    <filter class="solr.JapaneseKatakanaStemFilterFactory" minimumLength="4"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.WordDelimiterGraphFilterFactory" preserveOriginal="1" catenateWords="1"/>
    </analyzer>
    <analyzer type="query">
    <tokenizer class="solr.JapaneseTokenizerFactory" mode="search" userDictionary="lang/userdict_ja.txt"/>
    <filter class="solr.SynonymGraphFilterFactory" expand="true" ignoreCase="true" synonyms="synonyms.txt"/>
    <filter class="solr.JapaneseBaseFormFilterFactory"/>
    <filter class="solr.JapanesePartOfSpeechStopFilterFactory" tags="lang/stoptags_ja.txt"/>
    <filter class="solr.CJKWidthFilterFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_ja.txt"/>
    <filter class="solr.JapaneseKatakanaStemFilterFactory" minimumLength="4"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.WordDelimiterGraphFilterFactory" preserveOriginal="1" catenateWords="1"/>
    </analyzer>
  </fieldType>

Когда я ищу ビ ー ム エ キ ス パ ン ダ, без длинной метки, это то, как он анализируется. 

    "querystring":"ビームエキスパンダ",
    "parsedquery":"+DisjunctionMaxQuery((((((+CategoryName_txt:ビーム +CategoryName_txt:エキス +CategoryName_txt:パンダ) CategoryName_txt:ビームエキスパンダ))~1)))",
    "parsedquery_toString":"+(((((+CategoryName_txt:ビーム +CategoryName_txt:エキス +CategoryName_txt:パンダ) CategoryName_txt:ビームエキスパンダ))~1))",

Когда я ищу ビ ー ム エ キ ス パ ン ダ ー ー сдлинная отметка в конце, вот как она анализируется. 

    "querystring":"ビームエキスパンダー",
    "parsedquery":"+DisjunctionMaxQuery((((CategoryName_txt:ビーム CategoryName_txt:エキスパンダ)~2)))",
    "parsedquery_toString":"+(((CategoryName_txt:ビーム CategoryName_txt:エキスパンダ)~2))",

Любая помощь с этим будет принята с благодарностью.

-Paul

ОБНОВЛЕНИЕ По запросу яПрикрепил скриншоты из моего анализа solr для этих терминов.

With-Out long dash with out long dash

With long dash with long dash

По-видимому, здесь речь идет о данном термине, который является расширителем луча.Он анализируется с приборной панелью, как Beam Expander, что идеально.Без черты, это анализируется как три отдельных слова.

ビ ー ム, который является лучом.Это правильно.Но расширитель анализируется на термины エ キ ス и パ ン ダ, что, согласно Google Translate, означает «Извлечение и Панда».

Ответы [ 2 ]

0 голосов
/ 13 декабря 2018

Я понял эту проблему.Я не японский эксперт, но из того, что я могу сказать одну интересную вещь о японском языке, они не используют пробелы, чтобы обозначить конец слов.Фраза BeamSplitter и BeamExtractPanda на японском языке, по сути, одно и то же слово, и solr просто пытается сделать это, лучше всего определить, где разбить слова.

Вот где появляются пользовательские словари. Этот файл для менянаходится в расположении по умолчанию, lang / userdict_ja.txt.

Я добавил строку ниже .. ビ ー ム エ キ ス パ ダ ビоб этом, но из того, что я могу сказать, первый столбец здесь должен быть искомым словом, второе и третье должны быть тем же словом, но с пробелом, указывающим, где оно должно быть сегментировано токенизатором.

Я полагаю, что подобные случаи необычны, поэтому я согласен с этим в качестве исправления и предпочел бы сохранить JapaneseTokenizerFactory и поместить его в крайние случаи, чем использовать standardTokenizerFactory и быть менее оптимизированным.

Спасибовсе для вашей помощи.

-Paul

0 голосов
/ 13 декабря 2018

Интересно, нужно ли вам использовать solr.CJKBigramFilterFactory в ваших индексах и анализаторах запросов.В простом ванильном Solr 7 я получаю ожидаемые результаты в поле text_cjk (т.е. оно находит совпадение с длинной меткой или без нее).См. Рисунок ниже:

Solr Analysis

Ниже показано, как поле text_cjk определено в этом Solr: 

$ curl  http://localhost:8983/solr/cjktest/schema/fieldtypes/text_cjk
{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "fieldType":{
    "name":"text_cjk",
    "class":"solr.TextField",
    "positionIncrementGap":"100",
    "analyzer":{
      "tokenizer":{
        "class":"solr.StandardTokenizerFactory"},
      "filters":[{
          "class":"solr.CJKWidthFilterFactory"},
        {
          "class":"solr.LowerCaseFilterFactory"},
        {
          "class":"solr.CJKBigramFilterFactory"}]}}}
...