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


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

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

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

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

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

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

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

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

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

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

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

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

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

Важные моменты о ключах документов:

  • Максимальная длина значений в поле ключа составляет 1024 символов.
  • В каждом индексе должно быть выбрано ровно одно поле верхнего уровня, и оно должно быть типом Edm.String.
  • Значение по умолчанию key атрибута равно false для простых полей и null для сложных полей.

Ключевые поля можно использовать для поиска документов напрямую и обновления или удаления определенных документов. Значения ключевых полей обрабатываются с учетом регистра при поиске или индексировании документов. Дополнительные сведения см. в разделе GET Document (REST) и Index Documents (REST).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

Настройка определений полей

Коллекция полей определяет структуру документа поиска. Все поля имеют имя, тип данных и атрибуты.

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

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

ИНТЕРФЕЙСы REST API имеют присвоение по умолчанию на основе типов данных, которые также используются мастерами импорта в портал Azure. У пакетов SDK Azure нет стандартных значений, но они имеют подклассы полей, которые включают свойства и поведение, такие как SearchableField для строк и SimpleField для примитивов.

Значения по умолчанию для ИНТЕРФЕЙСов REST API приведены в следующей таблице.

Тип данных Возможность поиска Возможно извлечение Доступно для фильтрации Аспектируемый Сортируемый Запасенный
Edm.String
Collection(Edm.String)
Edm.Boolean
Edm.Int32, , Edm.Int64Edm.Double
Edm.DateTimeOffset
Edm.GeographyPoint
Edm.ComplexType
Collection(Edm.Single) и все другие типы полей векторов ✅ или ❌

Строковые поля также могут быть связаны с анализаторами и картами синонимов. Поля типа Edm.String , которые могут быть фильтруемыми, сортируемыми или фасетными, могут иметь длину не более 32 килобайтов. Это связано с тем, что значения таких полей рассматриваются как один поисковый термин, а максимальная длина термина в поиске ИИ Azure составляет 32 килобайта. Если необходимо сохранить больше текста, чем в одном строковом поле, необходимо явно задать фильтруемые, сортируемые и аспекты false в определении индекса.

Поля векторов должны быть связаны с измерениями и профилями векторов. Возвращается значение по умолчанию true, если вы добавляете поле вектора с помощью мастера импорта и векторизации на портале, в противном случае значение false, если используется REST API.

Атрибуты полей описаны в следующей таблице.

Атрибут Описание
name Необходимые. Задает имя поля, которое должно быть уникальным в коллекции полей индекса или родительского поля.
type Необходимые. Задает тип данных для поля. Поля могут быть простыми или сложными. Простые поля являются примитивными типами, например Edm.String для текста или Edm.Int32 целых чисел. Сложные поля могут иметь вложенные поля , которые сами являются простыми или сложными. Это позволяет моделировать объекты и массивы объектов, что, в свою очередь, позволяет отправлять большинство структур объектов JSON в индекс. Полный список поддерживаемых типов см. в разделе "Поддерживаемые типы данных".
key Обязательный. Задайте для этого атрибута значение true, чтобы указать, что значения поля однозначно идентифицируют документы в индексе. Дополнительные сведения см . в разделах "Ключи документов" в этой статье.
retrievable Указывает, можно ли возвращать поле в результатах поиска. Задайте для этого атрибута false значение, если вы хотите использовать поле в качестве фильтра, сортировки или механизма оценки, но не хотите, чтобы поле отображалось для конечного пользователя. Этот атрибут должен быть для ключевых полей, и он должен быть true null для сложных полей. Этот атрибут можно изменить в существующих полях. Параметр, который можно получить, не приводит к увеличению true требований к хранилищу индексов. Значение по умолчанию — true для простых полей и null для сложных полей.
searchable Указывает, доступно ли поле для полнотекстового поиска и можно ли ссылаться на запросы поиска. Это означает, что он проходит лексический анализ , например критические слова во время индексирования. Если задать для поиска значение, например "Солнечный день", оно нормализуется в отдельные маркеры "солнечный" и "день". В результате эти слова смогут участвовать в полнотекстовом поиске. Поля типа Edm.String или Collection(Edm.String) доступны для поиска по умолчанию. Этот атрибут должен быть false для простых полей других нестроковых типов данных, и он должен быть null для сложных полей.

Поле, доступное для поиска, использует дополнительное пространство в индексе, так как поиск Azure AI обрабатывает содержимое этих полей и упорядочивает их в вспомогательных структурах данных для выполнения поиска. Если вы хотите сэкономить место в индексе и не требуется, чтобы поле было включено в поиск, задайте для поиска значение false. Дополнительные сведения см. в статье о работе полнотекстового поиска в службе "Поиск ИИ Azure".
Фильтруемый Указывает, следует ли включить ссылку на поле в $filter запросах. Фильтрация отличается от способа обработки строк, доступных для поиска. Поля типа Edm.String или Collection(Edm.String) фильтруемые не проходят лексический анализ, поэтому сравнения предназначены только для точных совпадений. Например, если для такого поля задано значение f "Солнечный день", $filter=f eq 'sunny' не находит совпадений, но $filter=f eq 'Sunny day' будет. Этот атрибут должен быть null для сложных полей. Значение по умолчанию — true для простых полей и null для сложных полей. Чтобы уменьшить размер индекса, задайте этот атрибут false в полях, в которые вы не будете фильтроваться.
Сортируемый Указывает, следует ли включить ссылку на поле в $orderby выражениях. По умолчанию поиск Azure AI сортирует результаты по оценке, но во многих интерфейсах пользователи хотят сортировать по полям в документах. Простое поле может быть сортировано только в том случае, если оно имеет одно значение в области родительского документа.

Простые поля коллекции не могут быть сортируемыми, так как они многозначны. Простые подфилды сложных коллекций также являются многозначными и поэтому не могут быть отсортированы. Это верно, является ли это немедленное родительское поле или поле предка, это сложная коллекция. Сложные поля не могут быть сортируемыми, а атрибут сортировки должен быть null для таких полей. Значение по умолчанию для сортировки — true для однозначных простых полей, false для многозначных простых полей и null для сложных полей.
Аспектируемый Указывает, следует ли включить ссылку на поле в запросах аспектов. Обычно используется в презентации результатов поиска, включающих количество попаданий по категориям (например, поиск цифровых камер и просмотр хитов по бренду, по мегапикселям, по цене и т. д.). Этот атрибут должен быть null для сложных полей. Поля типа Edm.GeographyPoint или Collection(Edm.GeographyPoint) не могут быть фасетными. Значение по умолчанию — true для всех остальных простых полей. Чтобы уменьшить размер индекса, задайте этот атрибут false в полях, на которые вы не будете сталкиваться.
анализатор Задает лексический анализатор для маркеризации строк во время индексирования и операций запроса. Допустимые значения этого свойства включают анализаторы языка, встроенные анализаторы и пользовательские анализаторы. Значение по умолчанию — standard.lucene. Этот атрибут можно использовать только с полями строк, доступными для поиска, и его нельзя задать вместе с searchAnalyzer или indexAnalyzer. После выбора анализатора и создания поля в индексе его нельзя изменить. Должно быть null для сложных полей.
searchAnalyzer Задайте это свойство вместе с indexAnalyzer, чтобы указать различные лексические анализаторы для индексирования и запросов. Если вы используете это свойство, задайте для анализатора null значение и убедитесь, что indexAnalyzer имеет допустимое значение. Допустимые значения для этого свойства включают встроенные анализаторы и пользовательские анализаторы. Этот атрибут можно использовать только с полями, доступными для поиска. Анализатор поиска можно обновить в существующем поле, так как он используется только во время запроса. Должно быть null для сложных полей].
indexAnalyzer Задайте это свойство вместе с searchAnalyzer, чтобы указать различные лексические анализаторы для индексирования и запросов. Если вы используете это свойство, задайте для анализатора null значение и убедитесь, что searchAnalyzer имеет допустимое значение. Допустимые значения для этого свойства включают встроенные анализаторы и пользовательские анализаторы. Этот атрибут можно использовать только с полями, доступными для поиска. После выбора анализатора индекса его нельзя изменить для поля. Должно быть null для сложных полей.
сопоставления синонимов Список имен синонимов сопоставляется с этим полем. Этот атрибут можно использовать только с полями, доступными для поиска. В настоящее время поддерживается только одна карта синонимов на поле. Назначение сопоставления синонимов полю гарантирует, что условия запроса, предназначенные для этого поля, развертываются во время запроса с помощью правил в карте синонимов. Этот атрибут можно изменить в существующих полях. Должен быть null или пустой коллекцией для сложных полей.
столбцов Список подфилдов, если это поле типа Edm.ComplexType или Collection(Edm.ComplexType). Должно быть null или пусто для простых полей. См. сведения о том, как моделировать сложные типы данных в службе "Поиск ИИ Azure" для получения дополнительных сведений о том, как и когда следует использовать подполя.

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

Когда вы будете готовы создать индекс, используйте клиент поиска, который может отправить запрос. Вы можете использовать портал 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) Да
Шифрование Да
Карты синонимов Да
Семантическая конфигурация Да

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

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

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