Как реализовать пользовательскую проверку орфографии в API поиска GAE

Question

В моем приложении GAE для python я разрешаю пользователям запрашивать элементы, используя api для поиска, где я изначально помещал документы с точными тегами, но хиты не так много, учитывая исправление заклинаний, которое должно присутствовать. То, что я нашел, это внедрение символьных ngrams через datastore, поскольку это гарантирует, что пользователь набирает по крайней мере часть слова правильно. В хранилище данных это занимает много времени. Например,

"hello" (разбивается) ["hello", "ello", "hell", "hel", "elo", "llo", "he", "el", "ll", "lo"]

и когда я искать "helo" tags -["hel", "elo", "he", "el", "lo"] (дать положительный матч)

я ранжировать их по длине тегов совпавших от слова.

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

Есть ли способ выполнить аналогичную операцию, используя поиск api. Учитывает ли MatchScore несколько полей «ИЛИ»? Ищете способы разработки поисковых документов и выполнения нескольких исправленных заклинаний запросов при минимальных операциях.

Если у меня есть несколько полей для языков в одном документе, как для eg.-

([tags - "hello world"] [rank - 2300] [partial tags - "hel", "ell", "llo", "wor", "orl", "rld", "hell", "ello", "worl", "orld"] [english - 1] [Spanish - 0] [French - 0] [German - 0]

Могу ли я выполнить операцию MatchScore вместе с рода на языковых полях? (каждый документ относится только к одному языку)

Answer 1

Search API - хороший сервис для этого и гораздо лучше подходит, чем хранилище данных. Если ваши поисковые документы имеют правильный языковой набор, Search API будет охватывать определенные языковые варианты (например, единственное/множественное число). Но API поиска работает только для слов (обычно разделенных пробелами, дефисами, точками и т. Д.).

UPDATE: Язык определяется либо в language свойства поля, или в language свойства всего документа. В любом случае это значение составляет двухбуквенный код языка ISO 693-1, например 'de' for German.

Для точного определения условий поиска («hel», «elo», ...), вы можете использовать шаблон из этого ответа: https://stackoverflow.com/a/13171181/1549523 Также см. Мой комментарий к этому ответу. Если вы хотите использовать минимальную длину токенов (например, только буквы 3+), чтобы избежать размера хранилища и времени экземпляра интерфейса, вы можете использовать код, который я там связал.

MatchScorer помогает взвешивать частоту данного термина в документе. Поскольку теги обычно встречаются только один раз для каждого документа, это не поможет вам в этом. Но, например, если ваш поиск посвящен поиску в исследовательских работах термина «сжигание», MatchScorer оценит результаты, показывая первые документы, в которых этот термин включен чаще всего.

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

Если вы хотите предложить пользователям правильно написанный поисковый запрос, возможно, имеет смысл использовать два индекса. Один индекс, первичный индекс, для ваших фактических поисковых документов (например, описания продуктов с тегами) и второй индекс только для тегов или категорий (обозначенных и, в конечном итоге, синонимами). Если ваш пользователь вводит в поле поиска, ваше приложение сначала запрашивает индекс тега, предлагая соответствующие теги. Если пользователь выбирает один из них, тег используется для запроса первичного индекса поиска. Это поможет пользователям подобрать правильные теги.

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