Почему CloudSearch не находит совпадения подстрок в текстовом поле имени файла?

У меня есть домен CloudSearch с текстовым полем filename. Моя проблема в том, что текстовый запрос не будет соответствовать (некоторым) документам с именами файлов, которые, по моему мнению, должны (логически). Если у меня есть документы с этими именами файлов:

  1. 'легковые автомобили'
  2. 'Тачки Кино.jpg'
  3. 'автомобили.pdf'
  4. 'автомобили#.jpg'

и я выполняю простой текстовый запрос «cars», я получаю файлы № 1, № 2 и № 4, но не № 3. Если я ищу «автомобили*» (или выполняю структурированный запрос с использованием префикса), я могу сопоставить № 3. Для меня это не имеет смысла, особенно если № 4 соответствует, а № 3 — нет.


person Shawn Aten    schedule 08.12.2017    source источник


Ответы (1)


TL;DR Это связано с тем, как алгоритм токенизации обрабатывает периоды.

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

документация содержит обзор того, как обрабатывается текст. :

Во время индексирования Amazon CloudSearch обрабатывает текстовые поля и поля текстового массива в соответствии со схемой анализа, настроенной для поля, чтобы определить, какие термины следует добавить в индекс. Перед применением параметров анализа текст токенизируется и нормализуется.

Часть процесса, которая в конечном итоге вызывает такое поведение, — это токенизация:

Во время токенизации поток текста в поле разбивается на отдельные токены на обнаруживаемых границах с использованием правил разрыва слов, определенных в алгоритме сегментации текста Unicode.

В соответствии с правилами разрыва слов строки, разделенные пробелами, такими как пробелы и символы табуляции, рассматриваются как отдельные токены. Во многих случаях знаки препинания опускаются и рассматриваются как пробелы. Например, строки разделяются дефисом (-) и символом @. Однако точки, за которыми не следуют пробелы, считаются частью маркера.

Причина, по которой я видел совпадения, описанные в вопросе, заключается в том, что расширения файлов включаются во все, что предшествует им, как один токен. Если мы вернемся к примеру и построим индекс в соответствии с этими правилами, станет понятно, почему поиск по запросу «автомобили» возвращает документы № 1, № 2 и № 4, но не № 3.

#    Text                Index

1    'cars'              ['cars']
2    'Cars Movie.jpg'    ['cars', 'movie.jpg']
3    'cars.pdf'.         ['cars.pdf']
4    'cars#.jpg'         ['cars', '.jpg']

Возможные решения

Может показаться, что настройка пользовательской схемы анализа может решить эту проблему, но ни один из вариантов (стоп-слова, основа, синонимы) не поможет вам решить проблему токенизации. Я думаю, что единственным возможным решением для получения желаемого поведения является токенизация имени файла (с использованием пользовательского алгоритма) перед загрузкой, а затем сохранение токенов в поле текстового массива. Хотя разработка собственного алгоритма токенизации, поддерживающего несколько языков, является большой проблемой.

person Shawn Aten    schedule 15.12.2017
comment
+1 за полезный ответ. У меня аналогичная проблема с дефисами в текстовых полях. Токенизация разделяет мой термин на дефис и предотвращает частичные совпадения при поиске. Я думаю, что мне придется настроить токенизацию при загрузке данных, как вы упомянули. Мне нужно поддерживать только один язык, поэтому я думаю, что это будет управляемо. - person Brad Cunningham; 18.05.2018