Поиск частично введенных слов и шаблоны со специальными символами (дефисы, подстановочные знаки, регулярные выражения, шаблоны)

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

Частичные термины и специальные символы могут быть проблематичными, если индекс не имеет маркера, представляющего фрагмент текста, который требуется найти. Во время этапа лексического анализа индексирования ключевых слов (при условии стандартного анализатора по умолчанию) специальные символы удаляются, составные слова разбиваются, а пробелы удаляются. Если вы ищете фрагмент текста, измененный во время лексического анализа, запрос завершается ошибкой, так как совпадение не найдено. Рассмотрим этот пример: номер телефона, например +1 (425) 703-6214 (токенизованный как "1", "425", "703", "6214") не отображается в "3-62" запросе, так как такое содержимое на самом деле не существует в индексе.

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

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

Информация о поиске частично введенных слов

Поиск Azure AI сканирует целые токенизованные термины в индексе и не находит совпадение по частичному термину, если вы не используете операторы подстановочных знаков-заполнителей (* и ?) или форматируете запрос в формате регулярного выражения.

Частичные термины задаются с помощью следующих методов:

• Запросы регулярных выражений могут быть любым регулярным выражением, допустимым в Apache Lucene.

• Подстановочные символы с сопоставлением по префиксу относятся к общепризнанному шаблону, который включает начало термина, после чего следует оператор суффикса * или ?, такие как search=cap* для совпадения в "Cap'n Jack's Waterfront Inn" или "Highline Capital". Поддержка поиска с префиксом осуществляется как в простом, так и в расширенном синтаксисе запроса Lucene.

• Подстановочный знак с инфиксным и суффиксным сопоставлением помещает операторы * и ? внутрь или в начало термина и требует использования синтаксиса регулярного выражения (где выражение заключено в слэши). Например, строка запроса (search=/.*numeric.*/) возвращает результаты по буквенным и буквенно-цифровым символам в виде суффикса и инфикса.

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

Поскольку сам термин запроса не анализируется, он сопоставляется с индексом буквально, поэтому такой запрос, как Contoso*, может не вернуть ни одного результата, если анализатор приводит индексируемое содержимое к нижнему регистру. Дополнительные сведения см. в статье "Влияние анализатора на запросы с подстановочными знаками".

Решение проблем частичного поиска и поиска по шаблону

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

Такой подход выглядит следующим образом:

1. Определите второе поле для хранения нетронутой версии строки (если требуется проанализировать и неанализируемый текст во время запроса)
2. Оцените и выберите один из различных анализаторов, которые выдают маркеры с нужной степенью детализации.
3. Назначьте анализатор полю
4. Создание и тестирование индекса

1. Создание выделенного поля

Анализаторы определяют, как слова размечены в индексе. Поскольку анализаторы назначаются для каждого поля, можно создавать поля в индексе для оптимизации различных сценариев. Например, можно определить “featureCode” и “featureCodeRegex” для поддержки обычного полнотекстового поиска в первом и расширенного сопоставления шаблонов во втором. Анализаторы, назначенные каждому полю, определяют, как содержимое каждого поля размечено в индексе.

{
  "name": "featureCode",
  "type": "Edm.String",
  "retrievable": true,
  "searchable": true,
  "analyzer": null
},
{
  "name": "featureCodeRegex",
  "type": "Edm.String",
  "retrievable": true,
  "searchable": true,
  "analyzer": "my_custom_analyzer"
},

2. Установка анализатора

При выборе анализатора, создающего маркеры полного слова, распространенными вариантами являются следующие анализаторы.

С помощью клиента REST можно добавить вызов REST анализатора тестирования для проверки маркеризованных выходных данных.

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

1. Сначала попробуйте стандартный анализатор, чтобы увидеть, как слова размечены по умолчанию.

   {
   "text": "SVP10-NOR-00",
   "analyzer": "standard"
   }
   

2. Оцените ответ, чтобы увидеть, как текст размечен в индексе. Обратите внимание, что все слова имеют низкий регистр, дефисы удалены, а подстроки разбиты на отдельные маркеры. Только те запросы, которые соответствуют этим маркерам, будут возвращать этот документ в результатах. Запрос, содержащий “10-NOR”, приведет к сбою.

   {
       "tokens": [
           {
               "token": "svp10",
               "startOffset": 0,
               "endOffset": 5,
               "position": 0
           },
           {
               "token": "nor",
               "startOffset": 6,
               "endOffset": 9,
               "position": 1
           },
           {
               "token": "00",
               "startOffset": 10,
               "endOffset": 12,
               "position": 2
           }
       ]
   }
   

3. Теперь измените запрос, чтобы использовать анализатор whitespace или keyword.

   {
   "text": "SVP10-NOR-00",
   "analyzer": "keyword"
   }
   

4. На этот раз ответ состоит из одного токена, в верхнем регистре, с дефисами, сохранившимися как часть строки. Если необходимо выполнить поиск по шаблону или частично введенному слову, например “10-NOR”, механизм запросов теперь имеет базу для поиска соответствия.

   {
   
       "tokens": [
           {
               "token": "SVP10-NOR-00",
               "startOffset": 0,
               "endOffset": 12,
               "position": 0
           }
       ]
   }
   

3. Настройка анализатора

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

Использование встроенных анализаторов

Встроенные анализаторы можно указать по названию в analyzer свойстве определения поля без дополнительной конфигурации в индексе. В следующем примере показано, как установить анализатор whitespace в поле.

Другие сценарии и дополнительные сведения о других встроенных анализаторах см. в разделе Встроенные анализаторы.

    {
      "name": "phoneNumber",
      "type": "Edm.String",
      "key": false,
      "retrievable": true,
      "searchable": true,
      "analyzer": "whitespace"
    }

Используйте пользовательские анализаторы

Если вы используете пользовательский анализатор, определите его в индексе с пользовательским сочетанием токенизатора, фильтра для токенов и возможными настройками конфигурации. Затем дайте ссылку на определение поля так же, как при использовании встроенного анализатора.

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

• Создатель маркеров ключевых слов создает один маркер для всего содержимого поля.
• Фильтр маркеров нижнего регистра преобразует прописные буквы в строчные. Синтаксические анализаторы запросов обычно преобразуют любые вводимые данные в верхнем регистре в нижний. Приведение к нижнему регистру унифицирует ввод с токенизированными терминами.

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

{
"fields": [
  {
    "name": "accountNumber",
    "analyzer":"myCustomAnalyzer",
    "type": "Edm.String",
    "searchable": true,
    "filterable": true,
    "retrievable": true,
    "sortable": false,
    "facetable": false
  }
],

"analyzers": [
  {
    "@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
    "name":"myCustomAnalyzer",
    "charFilters":[],
    "tokenizer":"keyword_v2",
    "tokenFilters":["lowercase"]
  }
],
"tokenizers":[],
"charFilters": [],
"tokenFilters": []
}

4. Сборка и тестирование

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

Используйте клиент REST для запроса частичных терминов и специальных символов, описанных в этой статье.

В предыдущих разделах была объяснена логика. В этом разделе поэтапно рассматриваются все API, которые следует вызывать при тестировании вашего решения.

• Удаление индекса: удаляет существующий индекс с тем же именем, чтобы его можно было повторно создать.

• Создание индекса: создает структуру индекса в службе поиска, включая определения анализаторов и поля с указанием анализатора.

• Загрузка документов: импортирует документы, имеющие ту же структуру, что и индекс, а также содержимое, доступное для поиска. После выполнения этого шага индекс будет готов к выполнению запроса или тестированию.

• Анализатор тестов был введён в разделе Настройка анализатора. Проверьте некоторые строки в индексе с помощью различных анализаторов, чтобы понять, как токенизированы термины.

• В разделе Документация по поиску объясняется, как создать запрос, используя простой синтаксис или полный синтаксис Lucene для подстановочных знаков и регулярных выражений.

  Для запросов с частичными выражениями, таких как запрос "3-6214" для поиска совпадения в "+ 1 (425) 703-6214", можно использовать простой синтаксис: search=3-6214&queryType=simple.

  Для запросов инфиксов и суффиксов, таких как запрос “num” или “numeric” для поиска совпадений с “alphanumeric”, используйте полный синтаксис Lucene и регулярное выражение: search=/.*num.*/&queryType=full

Оптимизация префиксных и суффиксных запросов

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

В следующем примере добавляется EdgeNGramTokenFilter, чтобы ускорить совпадение префиксов или суффиксов. Маркеры создаются в сочетаниях символов 2–25, включающих символы. Ниже приведен пример прогрессии от двух до семи маркеров: MS, MSF, MSFT, MSFT/, MSFT/S, MSFT/SQ, MSFT/SQL. EdgeNGramTokenFilter требуется параметр, определяющий side , из какой стороны создаются сочетания строковых символов. Используется front для запросов префикса и back запросов суффикса.

Дополнительная маркеризация приводит к более крупному индексу. Если у вас достаточно емкости для размещения более крупного индекса, этот подход с более быстрым временем отклика может быть лучшим решением.

{
"fields": [
  {
    "name": "accountNumber_prefix",
    "indexAnalyzer": "ngram_front_analyzer",
    "searchAnalyzer": "keyword",
    "type": "Edm.String",
    "searchable": true,
    "filterable": false,
    "retrievable": true,
    "sortable": false,
    "facetable": false
  },
  {
    "name": "accountNumber_suffix",
    "indexAnalyzer": "ngram_back_analyzer",
    "searchAnalyzer": "keyword",
    "type": "Edm.String",
    "searchable": true,
    "filterable": false,
    "retrievable": true,
    "sortable": false,
    "facetable": false
  }
],

"analyzers": [
  {
    "@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
    "name":"ngram_front_analyzer",
    "charFilters":[],
    "tokenizer":"keyword_v2",
    "tokenFilters":["lowercase", "front_edgeNGram"]
  },
  {
    "@odata.type":"#Microsoft.Azure.Search.CustomAnalyzer",
    "name":"ngram_back_analyzer",
    "charFilters":[],
    "tokenizer":"keyword_v2",
    "tokenFilters":["lowercase", "back_edgeNGram"]
  }
],
"tokenizers":[],
"charFilters": [],
"tokenFilters": [
  {
    "@odata.type":"#Microsoft.Azure.Search.EdgeNGramTokenFilterV2",
    "name":"front_edgeNGram",
    "minGram": 2,
    "maxGram": 25,
    "side": "front"
  },
  {
    "@odata.type":"#Microsoft.Azure.Search.EdgeNGramTokenFilterV2",
    "name":"back_edgeNGram",
    "minGram": 2,
    "maxGram": 25,
    "side": "back"
  }
]
}

Для поиска номеров учетных записей, начинающихся с 123, можно использовать следующий запрос:

{
  "search": "123",
  "searchFields": "accountNumber_prefix"
}

Чтобы найти номера учетных записей, которые заканчиваются 456, можно использовать следующий запрос:

{
  "search": "456",
  "searchFields": "accountNumber_suffix"
}

Связанный контент

• Руководство: создание пользовательского анализатора для номеров телефонов
• Создание индекса для нескольких языков в Поиск с использованием ИИ Azure
• Анализаторы для обработки текста в поиске ИИ Azure
• Анализ API (REST)
• Полнотекстовый поиск в Поиск с использованием ИИ Azure