Процессор обновления обнаружения языка Solr для денормализованных документов на разных языках - PullRequest
Новая
       36

Процессор обновления обнаружения языка Solr для денормализованных документов на разных языках

3 голосов
/ 17 февраля 2012

У меня есть база данных вещей, каждая из которых может иметь несколько имен на разных языках.В настоящее время это нормализуется к вещь с множеством имен схема: 

things
------
id
...

names
-----
id
thing_id
language
name

Я индексирую это с помощью Solr и пытаюсь найти лучший способ денормализовать это в схему Lucene,Этот работает нормально: 

<fields>
    <field name="id" type="uuid" indexed="true" stored="true" required="true" />
    ...
    <field name="name_eng" type="text_eng" indexed="true" stored="true" />
    <field name="name_jpn" type="text_cjk" indexed="true" stored="true" />
    <field name="name_kor" type="text_cjk" indexed="true" stored="true" />
</fields>

Проблема в том, что мне нужно указать поле и тип поля для каждого поддерживаемого языка в отдельности, и их может быть много.Поскольку я также использую SQL DataImportHandler, это означает, что мне нужно продублировать большой объем кода, чтобы указать запросы SQL для импорта их из базы данных в эту схему.Кроме того, поле language имен не всегда корректно, поскольку оно основано на пользовательском вводе.

Я рассматривал возможности обнаружения языка Solr, которые выглядят очень хорошо.Но, похоже, они работают только с документами в целом, что, как мне кажется, не сильно поможет.Есть ли способ указать одно поле multiValued в схеме, в котором я могу хранить имена, язык которых будет автоматически определен и соответствующим образом проиндексирован?Или другие способы, которыми средства обнаружения языка могли бы облегчить мою жизнь здесь?

1 Ответ

0 голосов
/ 03 мая 2012

Возможно, вы могли бы написать преобразователь, который бы делал это на стороне индекса, но на стороне запроса не получала бы такую ​​же цепочку анализа, так что это не сработало бы.

Что означает текст для них "«как выглядит?»

Если он содержит менее 200 символов, идентификатор языка будет работать не очень хорошо.Думайте об этом как "угадывание языка" со статистическим подходом.С небольшими объемами данных догадки плохи.«Мобильный» английский или датский?И то и другое.«Die» - это английский, немецкий и т. Д.Для хорошего предположения было бы полезно тысяча символов.

Есть ли в тексте торговые марки?«LaserJet» и «Linux» одинаковы на всех языках и редко встречаются, поэтому лингвистическая обработка ничего не делает.Может быть, вы можете обойтись без специфического языка.

Наконец, вы можете рассмотреть n-граммы вместо лингвистической обработки.Это совершенно отличная модель от чувствительного к языку соответствия, но она могла бы работать лучше для этого.В некотором смысле, он выполняет тот же тип статистического сопоставления с идентификатором языка, но во время запроса, а не во время индекса.Он будет брать короткие последовательности шаблонов из запроса и искать их в тексте.Это займет больше времени и места, но стоит попробовать.

...