Индексы поиска в поиске ИИ Azure

В Службе поиска ИИ Azure индекс — это содержимое, доступное для поиска, доступное поисковой системе для индексирования, полнотекстового поиска, векторного поиска, гибридного поиска и отфильтрованных запросов. Индекс определяется схемой и сохраняется в службе поиска с импортом данных следующим шагом. Это содержимое существует в службе поиска, помимо основных хранилищ данных, необходимых для времени отклика миллисекунда, ожидаемого в современных приложениях поиска. За исключением сценариев индексирования на основе индексатора служба поиска никогда не подключается или запрашивает исходные данные.

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

• Содержимое (документы и схема)
• Структура физических данных
• Базовые операции

Предпочитаете быть практическими сразу? Вместо этого см. статью "Создание индекса поиска".

Схема индекса поиска

В службе "Поиск ИИ Azure" индексы содержат документы поиска. Документ представляет собой единый блок доступных для поиска данных в индексе. Например, у розничной торговли может быть документ для каждого продукта, у новостной организации может быть документ для каждой статьи, у сайта путешествия может быть документ для каждого отеля и назначения, и т. д. Можно сравнить эти понятия с более знакомыми эквивалентными понятиями баз данных: индекс поиска напоминает таблицу, а документы — строки в ней.

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

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

Другие элементы свернуты для краткости, но следующие ссылки содержат сведения:

• предлагающие поддерживают запросы типа вперед, такие как автозавершение.
• ОценкиProfiles используются для настройки релевантности.
• анализаторы используются для обработки строк в маркеры в соответствии с лингвистическими правилами или другими характеристиками, поддерживаемыми анализатором.
• corsOptions или удаленное скриптирование между источниками (CORS) используется для приложений, которые выдает запросы из разных доменов.
• encryptionKey настраивает двойное шифрование конфиденциального содержимого в индексе.
• семантика настраивает семантические повторения в полнотекстовом и гибридном поиске.
• VectorSearch настраивает векторные поля и запросы.

Определения полей

Документ поиска определяется коллекцией "поля" в тексте запроса create Index. Вам нужны поля для идентификации документов (ключей), хранения текста с возможностью поиска и полей для поддержки фильтров, аспектов и сортировки. Кроме того, могут потребоваться поля для данных, которые пользователь никогда не видит. Например, может потребоваться, чтобы поля для прибыли или маркетинговых рекламных акций, которые можно использовать в профиле оценки для повышения оценки.

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

Атрибуты поля

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

Строковые поля часто отмечены как searchable (доступные для поиска) и retrievable (доступные для получения). Для сужения результатов поиска используются поля sortable (сортируемое), filterable (фильтруемое) и facetable (аспектируемое).

Атрибут	Description
searchable (доступное для поиска)	Полнотекстовый или векторный поиск. Текстовые поля подвергаются лексическому анализу, например критическому слову во время индексирования. Если задать для поиска значение, например "солнечный день", то внутренне оно разделено на отдельные маркеры "солнечный" и "день". Дополнительные сведения см. в статье Как работает полнотекстовый поиск в службе поиска Azure.
filterable (фильтруемое)	Указывается в запросах $filter. Фильтруемые поля типа Edm.String или Collection(Edm.String) не проходят разбиение слов, поэтому сравнения предназначены только для точных совпадений. Например, если задать для такого поля значение "солнечный день", $filter=f eq 'sunny' не находит совпадений, но $filter=f eq 'sunny day' будет.
sortable (сортируемое)	По умолчанию система сортирует результаты по их оценке, однако можно настроить сортировку на основе полей в документах. Поля типа Collection(Edm.String) не могут быть "сортируемыми".
facetable (аспектируемое)	Обычно используется в представлении результатов поиска, включающих количество обращений по категориям (например, отелей в определенном городе). Этот параметр нельзя использовать с полями типа Edm.GeographyPoint. Поля типа Edm.String, которые имеют атрибуты filterable, sortable или facetable, могут иметь длину не более 32 КБ. Дополнительные сведения см. в статье Create Index (Azure Search Service REST API) (Создание индекса в REST API службы Поиска Azure).
"key"	Уникальный идентификатор для документов в индексе. Только одно поле должно быть выбрано ключевым и оно должно иметь тип Edm.String.
retrievable (доступное для получения)	Определяет, включается ли поле в возвращаемые поиском результаты. Это полезно, если вы хотите использовать поле (например , прибыль) в качестве фильтра, сортировки или механизма оценки, но не хотите, чтобы поле отображалось для конечного пользователя. У полей с установленным свойством true for key .

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

Примечание.

API, используемые для создания индекса, имеют различные поведения по умолчанию. Для REST API по умолчанию включено большинство атрибутов (например, для строковых полей используются searchable (доступное для поиска) и retrievable (доступное для получения)), и часто их нужно настраивать только в том случае, если их необходимо отключить. В пакете SDK для .NET все наоборот. Для каждого свойства, не заданного явным образом, по умолчанию соответствующее поведение поиска отключено, если не включить его специально.

Физическая структура и размер

В поиске ИИ Azure физическая структура индекса в значительной степени является внутренней реализацией. Вы можете получить доступ к своей схеме, запрашивать его содержимое, отслеживать его размер и управлять емкостью, но сами кластеры (индексы, сегменты и другие файлы и папки) управляются корпорацией Майкрософт.

Размер индекса можно отслеживать на вкладке "Индексы" в портал Azure или путем выдачи запроса GET INDEX в службе поиска. Вы также можете отправить запрос статистики служб и проверка значение размера хранилища.

Размер индекса определяется следующими значениями:

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

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

Атрибуты полей определяют поведение. Для поддержки этих действий процесс индексирования создает необходимые структуры данных. Например, для поля типа Edm.String"поиск" вызывается полнотекстовый поиск, который сканирует инвертированные индексы для маркеризованного термина. Напротив, атрибут "фильтруемый" или "сортируемый" поддерживает итерацию по немодифицированным строкам. В примере в следующем разделе показаны варианты размера индекса на основе выбранных атрибутов.

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

Пример демонстрации последствий хранения атрибутов и предлагаемых средств

На следующем снимке экрана показаны шаблоны хранения индекса, полученные в результате различных сочетаний атрибутов. Индекс основан на примере индекса недвижимости, который можно легко создать с помощью мастера импорта данных и встроенных примеров данных. Хотя схемы индекса не отображаются, вы можете определить атрибуты на основе имени индекса. Например, для индекса realestate-searchable выбран только атрибут searchable, для индекса realestate-retrievable выбран только атрибут retrievable и т. д.

Хотя эти варианты индекса несколько искусственны, мы можем ссылаться на них для широкого сравнения того, как атрибуты влияют на хранилище:

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

Кроме того, в предыдущей таблице не отражено влияние анализаторов. Если вы используете токенизатор edgeNgram для хранения подробных последовательностей символов (a, ab, abc, abcd), индекс больше, чем при использовании стандартного анализатора.

Основные операции и взаимодействие

Теперь, когда у вас есть лучшее представление о том, что такое индекс, в этом разделе приводятся операции времени выполнения индекса, включая подключение к одному индексу и защиту одного индекса.

Примечание.

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

Изоляция индекса

В службе "Поиск ИИ Azure" вы работаете с одним индексом одновременно, где все операции, связанные с индексом, предназначены для одного индекса. Нет концепции связанных индексов или присоединения независимых индексов для индексирования или запроса.

Непрерывная доступность

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

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

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

Чтобы избежать перестроения индекса, некоторые клиенты, которые вносят небольшие изменения, выбирают поле "версия", создавая новый, который сосуществует вместе с предыдущей версией. Со временем это приводит к потерянным содержимому в виде устаревших полей или устаревших определений пользовательских анализаторов, особенно в производственном индексе, который является дорогостоящим для реплика te. Эти проблемы можно устранить при запланированных обновлениях индекса в рамках управления жизненным циклом индекса.

Подключение к конечной точке и безопасность

Все запросы индексирования и запроса предназначены для индекса. Конечные точки обычно являются одним из следующих:

Конечная точка	Подключение и управление доступом
<your-service>.search.windows.net/indexes	Предназначено для коллекции индексов. Используется при создании, перечислении или удалении индекса. Администратор права требуются для этих операций, доступные через администратора Ключи API или роль участника поиска.
<your-service>.search.windows.net/indexes/<your-index>/docs	Предназначено для коллекции документов одного индекса. Используется при запросе индекса или обновления данных. Для запросов достаточно прав на чтение и доступны ключи API запросов или роль чтения данных. Для обновления данных требуются права администратора.

Как подключиться к службе "Поиск ИИ Azure"

1. Начните с портал Azure. Подписчики Azure или пользователь, создавший службу поиска, может управлять службой поиска в портал Azure. Для подписки Azure требуются разрешения участника или более поздней версии для создания или удаления служб. Этот уровень разрешений достаточно для полного управления службой поиска в портал Azure.

2. Попробуйте использовать другие клиенты для программного доступа. Мы рекомендуем краткие руководства для первых шагов:

   • Краткое руководство. REST
   • Краткое руководство. Пакеты SDK Azure

Следующие шаги

Вы можете получить практический опыт создания индекса с помощью практически любого примера или пошагового руководства для поиска ИИ Azure. Для начала можно выбрать любое краткое руководство в содержании.

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

• Создание индекса поиска
• Создание хранилища векторов
• Создание псевдонима индекса
• Общие сведения об импорте данных
• Загрузка индекса