Создание индекса в службе "Поиск ИИ Azure"
Из этой статьи вы узнаете, как определить схему индекса поиска и отправить ее в службу поиска. Создание индекса устанавливает структуры физических данных в службе поиска. После того как индекс существует, загрузите индекс в виде отдельной задачи.
Необходимые компоненты
Разрешения на запись в качестве участника службы поиска или ключа API администратора для проверки подлинности на основе ключей.
Понимание данных, которые требуется индексировать. Индекс поиска основан на внешнем содержимом, которое требуется выполнить поиск. Содержимое, доступное для поиска, хранится в виде полей в индексе. У вас должно быть четкое представление о том, какие исходные поля вы хотите сделать доступным для поиска, извлекаемым, фильтруемым, фасетным и сортируемым в службе поиска ИИ Azure. Ознакомьтесь с контрольным списком схемы для получения рекомендаций.
Кроме того, необходимо иметь уникальное поле в исходных данных, которые можно использовать в качестве ключа документа (или идентификатора) в индексе.
Стабильное расположение индекса. Перемещение существующего индекса в другую службу поиска не поддерживается вне поля. Вернитесь к требованиям приложения и убедитесь, что существующая служба поиска (емкость и регион) достаточно для ваших потребностей. Если вы используете зависимость от служб ИИ Azure или Azure OpenAI, выберите регион , предоставляющий все необходимые ресурсы.
Наконец, все уровни служб имеют ограничения на количество создаваемых объектов. Например, если у вас бесплатный уровень, то вы можете иметь только три индекса одновременно. В самом индексе существуют ограничения на векторы и ограничения индекса на количество простых и сложных полей.
Ключи документов
Создание индекса поиска имеет два требования: индекс должен иметь уникальное имя в службе поиска, и он должен иметь ключ документа. Логический key атрибут в поле может иметь значение true, чтобы указать, какое поле предоставляет ключ документа.
Ключ документа — это уникальный идентификатор документа поиска, а документ поиска — это коллекция полей, которые полностью описывают что-то. Например, если вы индексируете набор данных фильмов, то в документе поиска содержится название, жанр и длительность одного фильма. Имена фильмов уникальны в этом наборе данных, поэтому в качестве ключа документа можно использовать имя фильма.
В поиске ИИ Azure ключ документа является строкой, и он должен исходить из уникальных значений в источнике данных, который предоставляет содержимое для индексирования. Как правило, служба поиска не создает ключевые значения, но в некоторых сценариях (например , индексатор таблиц Azure) синтезирует существующие значения для создания уникального ключа для индексированных документов. Другой сценарий — это индексирование по одному ко многим для блокированных или секционированных данных, в этом случае ключи документов создаются для каждого блока.
Во время добавочного индексирования, где индексируется новое и обновленное содержимое, добавляются входящие документы с новыми ключами, а входящие документы с существующими ключами объединяются или перезаписываются в зависимости от того, являются ли поля индекса пустыми или заполнены.
Важные моменты о ключах документов:
- Максимальная длина значений в поле ключа составляет 1024 символов.
- В каждом индексе должно быть выбрано ровно одно поле верхнего уровня, и оно должно быть типом
Edm.String. - Значение по умолчанию
keyатрибута равно false для простых полей и null для сложных полей.
Ключевые поля можно использовать для поиска документов напрямую и обновления или удаления определенных документов. Значения ключевых полей обрабатываются с учетом регистра при поиске или индексировании документов. Дополнительные сведения см. в разделе GET Document (REST) и Index Documents (REST).
Контрольный список схемы
Этот контрольный список поможет вам в принятии решений о дизайне индекса поиска.
Прочтите соглашения об именовании, чтобы имена индексов и полей соответствовали правилам именования.
Ознакомьтесь с поддерживаемыми типами данных. Тип данных влияет на то, как используется поле. Например, по отношению к числовому содержимому допускается фильтрация, но не полнотекстовый поиск. Наиболее распространенный тип данных —
Edm.Stringв случае доступного для поиска текста, который токенизирован и запрашивается с помощью полнотекстовой поисковой системы. Наиболее распространенный тип данных для поля вектора ,Edm.Singleно также можно использовать другие типы.Определите ключ документа. Ключ документа требуется для индекса. Это одно строковое поле, заполненное из поля исходных данных, которое содержит уникальные значения. Например, если индексация выполняется из хранилища BLOB-объектов, путь к хранилищу метаданных часто служит в качестве ключа документа, так как он однозначно идентифицирует каждый BLOB-объект в контейнере.
Определите поля в источнике данных, добавляющие в индекс доступный для поиска контент.
Содержимое невектора с возможностью поиска включает короткие или длинные строки, запрашиваемые с помощью полнотекстовой поисковой системы. Если речь идет о подробном контенте (краткие фразы или большие фрагменты), поэкспериментируйте с различными анализаторами, чтобы узнать, как токенизирован текст.
Векторное содержимое с возможностью поиска может быть изображениями или текстами (на любом языке), которые существуют в виде математического представления. Для уменьшения векторных полей можно использовать узкие типы данных или сжатие векторов.
Атрибуты, заданные в полях, например
retrievableилиfilterable, определяют поведение поиска и физическое представление индекса в службе поиска. Определение того, как следует использовать поля, является итеративным процессом для многих разработчиков. Чтобы ускорить повторение операций, начните с примера данных, которые можно легко удалить, перестроив индекс.Определите, какие исходные поля можно использовать в качестве фильтров. Удачными вариантами являются числовое содержимое и короткие текстовые поля, особенно поля с повторяющимися значениями. При работе с фильтрами помните о следующем:
Фильтры можно использовать в векторных и невекторных запросах, но сам фильтр применяется к полям буквенно-цифровых (невекторов) в индексе.
Фильтруемые поля можно использовать по желанию при аспектной навигации.
Фильтруемые поля возвращаются в произвольном порядке и не проходят оценку релевантности, поэтому рассмотрите возможность их сортировки.
Для полей векторов укажите конфигурацию векторного поиска и алгоритмы, используемые для создания путей навигации и заполнения пространства внедрения. Дополнительные сведения см. в разделе "Добавление векторных полей".
Векторные поля имеют дополнительные свойства, не имеющие полей невектора, например алгоритмы для использования и сжатия векторов.
Векторные поля опустят атрибуты, которые не полезны для векторных данных, таких как сортировка, фильтрация и фасетирование.
Для полей невектора определите, следует ли использовать анализатор по умолчанию (
"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.
Приготовьтесь к частому перестроению во время разработки. Так как физические структуры создаются в службе, удаление и повторное создание индексов необходимо для многих изменений. Можно рассмотреть возможность использования подмножества данных, чтобы ускорить перестроение.
При проектировании индекса на портале принудительно применяются требования и правила схемы для отдельных типов данных, например запрет возможности полнотекстового поиска в числовых полях.
Войдите на портал Azure.
Проверьте место. служба подвержены максимальному количеству индексов, изменяющихся по уровню служб. Убедитесь, что у вас есть место для второго индекса.
На странице обзора службы поиска выберите любой вариант для создания индекса поиска:
- Добавление индекса, внедренного редактора для указания схемы индекса
- Мастеры импорта
Мастер — это комплексный рабочий процесс, который создает индексатор, источник данных и готовый индекс. Он также загружает данные. Если это больше, чем нужно, используйте вместо этого индекс .
На следующем снимках экрана показано, как добавить индекс, импортировать и векторизировать данные на панели команд.
После создания индекса его снова можно найти на странице индексов в левой области навигации .
Совет
После создания индекса на портале можно скопировать представление 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) | Да |
| Шифрование | Да |
| Карты синонимов | Да |
| Семантическая конфигурация | Да |
Следующие шаги
Используйте следующие ссылки, чтобы узнать о специализированных функциях, которые можно добавить в индекс:
- Добавление векторных полей и профилей векторов
- Добавление профилей оценки
- Добавление семантического ранжирования
- Добавление предложения
- Добавление карт синонимов
- Добавление анализаторов
- Добавление шифрования
Используйте следующие ссылки для загрузки или обновления индекса: