Создание индекса в службе "Поиск ИИ Azure"

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

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

Необходимые компоненты

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

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

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

  • Стабильное расположение индекса. Перемещение существующего индекса в другую службу поиска не поддерживается вне поля. Вернитесь к требованиям приложения и убедитесь, что существующая служба поиска, ее емкость и расположение достаточно для ваших потребностей.

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

Ключи документов

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

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

Список проверка схемы

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

  1. Просмотрите соглашения об именовании, чтобы имена индексов и полей соответствовали правилам именования.

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

  3. Определите ключ документа. Ключ документа — это требование индекса. Это одно строковое поле, которое заполняется из исходного поля данных, содержащего уникальные значения. Например, если индексировать из BLOB-объектов служба хранилища, путь к хранилищу метаданных часто используется в качестве ключа документа, так как он однозначно идентифицирует каждый большой двоичный объект в контейнере.

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

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

  5. Определите, какие исходные поля можно использовать в качестве фильтров. Числовое содержимое и короткие текстовые поля, особенно с повторяющимися значениями, являются хорошим выбором. При работе с фильтрами помните:

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

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

  6. Определите, следует ли использовать анализатор по умолчанию ("analyzer": null) или другой анализатор. Анализаторы используются для маркеризации текстовых полей во время индексирования и выполнения запросов.

    Для многоязычных строк рассмотрим анализатор языка.

    Для дефисированных строк или специальных символов рассмотрим специализированные анализаторы. Например, анализатор keyword ("ключевое слово") обрабатывает все содержимое поля, как один токен. Это поведение полезно для таких данных, как zip-коды, идентификаторы и некоторые имена продуктов. Дополнительные сведения см. в разделе Поиск частично введенных слов и шаблоны со специальными символами.

Примечание.

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

Создание индекса

Когда вы будете готовы создать индекс, используйте клиент поиска, который может отправить запрос. Вы можете использовать портал Azure или REST API для раннего разработки и проверки концепции.

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

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

  1. Войдите на портал Azure.

  2. На странице обзора службы поиска выберите любой вариант для создания индекса поиска:

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

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

Команда добавления индекса

Совет

После создания индекса на портале можно скопировать представление JSON и добавить его в код приложения.

Установка corsOptions для запросов между источниками

Схемы индексов включают раздел для настройки corsOptions. По умолчанию клиентский JavaScript не может вызывать интерфейсы API, так как браузеры предотвращают все запросы между источниками. Чтобы разрешить перекрестные запросы к индексу, включите CORS (совместное использование ресурсов между источниками), задав атрибут corsOptions . По соображениям безопасности только API запросов поддерживают CORS.

"corsOptions": {
  "allowedOrigins": [
    "*"
  ],
  "maxAgeInSeconds": 300

Для CORS можно задать следующие свойства:

  • allowedOrigins (обязательно): это список источников, которым разрешен доступ к индексу. Код JavaScript, обслуживающийся из этих источников, может запрашивать индекс (если вызывающий объект предоставляет допустимый ключ или имеет разрешения). Источники здесь обычно задаются в формате protocol://<fully-qualified-domain-name>:<port>, хотя <port> часто опускается. Дополнительные сведения см. в разделе общего доступа к ресурсам между источниками (Википедия).

    Если вы хотите разрешить доступ всем источникам, добавьте в массив allowedOrigins единственный элемент *. Это не рекомендуется для рабочих служб поиска, но часто полезно для разработки и отладки.

  • maxAgeInSeconds (необязательный): с помощью этого значения браузеры определяют длительность (в секундах) кэширования предварительных ответов CORS. Это значение должно быть целой неотрицательной величиной. Более длительный период кэша обеспечивает более высокую производительность, но увеличивает время, необходимое для принятия политики CORS. Если это значение не задано, используется значение по умолчанию в течение пяти минут.

Разрешенные обновления существующих индексов

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

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

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

Элемент Можно ли обновить?
Имя. No
Ключ No
Имена полей и типы No
Атрибуты полей (доступные для поиска, фильтруемые, фасетные, сортируемые) No
Атрибут поля (извлекаемый) Да
Анализатор В индексе можно добавлять и изменять пользовательские анализаторы. В отношении назначений анализаторов в строковых полях можно изменять searchAnalyzerтолько . Для всех остальных назначений и изменений требуется перестроение.
Профили повышения Да
Средства подбора No
общий доступ к ресурсам между источниками (CORS) Да
Шифрование Да

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

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