Индексы поиска в Поиск с использованием ИИ Azure

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

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

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

Tip

Краткая сводка:

  • Индекс хранит содержимое, доступное для поиска
  • Схема определяет поля и их поведение
  • Документы — это отдельные элементы, доступные для поиска (аналогичные строкам в базе данных)
  • Переход к созданию индекса →

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

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

Ниже приведен пример того, как выглядит схема индекса.

{
  "name": "name_of_index, unique across the service",
  "description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees.",
  "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 (only Edm.String fields can be keys) | false (default where applicable),
      "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 embedding models" (applies to vector fields of type Collection(Edm.Single)),
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations but 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){ }
}

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

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

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

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

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

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

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

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

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

Note

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

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

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

Размер индекса можно отслеживать на странице Search management > Indexes на портале Azure. Кроме того, вы можете отправить запрос GET INDEX в службу поиска или запрос статистики служб , чтобы проверить значение размера хранилища.

Note

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

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

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

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

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

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

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

Подключение к индексу

  1. Начните с портала Azure и панели управления службы поиска.

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

Дальнейшие шаги

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

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

  • Last updated on