Поделиться через


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

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

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

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

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

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

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

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

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

Индекс поиска имеет два требования: он должен иметь имя и ключ документа.

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

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

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

Контрольный список схемы

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

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

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

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

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

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

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

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

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

    • Фильтры можно использовать в векторных и невекторных запросах, но сам фильтр применяется буквенно-цифровые (невекторы) в индексе.

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

    • Добавление индекса, внедренного редактора для указания схемы индекса
    • Мастеры импорта

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

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

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

Совет

После создания индекса на портале можно скопировать представление 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
Атрибут поля (извлекаемый) Да
Хранимый (применяется к векторам) No
Анализатор В индексе можно добавлять и изменять пользовательские анализаторы. В отношении назначений анализаторов в строковых полях можно изменять searchAnalyzerтолько . Для всех остальных назначений и изменений требуется перестроение.
Профили повышения Да
Средства подбора No
общий доступ к ресурсам между источниками (CORS) Да
Шифрование Да

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

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