Хранилище векторов в поиске ИИ Azure

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

Векторы хранятся в индексе поиска. Используйте REST API создания индекса или эквивалентный метод Azure SDK для создания векторного хранилища.

Рекомендации по хранилищу векторов включают следующие моменты:

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

Шаблоны извлечения векторов

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

• Генерированный поиск. Языковые модели сформулируют ответ на запрос пользователя с помощью данных из службы "Поиск ИИ Azure". Этот шаблон включает слой оркестрации для координации запросов и поддержания контекста. В этом шаблоне результаты поиска передаются в потоки запросов, полученные моделями чата, такими как GPT и Text-Davinci. Этот подход основан на архитектуре расширенного создания (RAG), где индекс поиска предоставляет данные о заземления.

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

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

Схема векторного хранилища

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

Базовая конфигурация поля вектора

Поля векторов различаются по их типу данных и свойствам вектора. Вот как выглядит векторное поле в коллекции полей:

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

Векторные поля имеют тип Collection(Edm.Single).

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

Поля векторов должны иметь dimensions значение числа внедрения, созданных моделью внедрения. Например, text-embedding-ada-002 создает 1536 внедрения для каждого блока текста.

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

Коллекция полей для базовых рабочих нагрузок векторов

Векторные хранилища требуют больше полей, кроме векторных полей. Например, ключевое поле ("id" в этом примере) является требованием к индексу.

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

Другие поля, такие как "content" поле, предоставляют читаемый человеком эквивалент "content_vector" поля. Если вы используете языковые модели исключительно для формулировки ответа, можно опустить поля содержимого невектора, но решения, которые помещают результаты поиска непосредственно в клиентские приложения, должны иметь невекторное содержимое.

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

Схема, созданная мастером импорта и векторизации данных

Мы рекомендуем мастер импорта и векторизации данных для оценки и проверки концепции. Мастер создает пример схемы в этом разделе.

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

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

В следующем примере для каждого документа поиска есть один идентификатор блока, блок, заголовок и векторное поле. Блок-код и родительский идентификатор заполняются мастером, используя кодировку base 64 метаданных BLOB-объектов (путь). Блоки и заголовок являются производными от содержимого BLOB-объектов и имени большого двоичного объекта. Только поле вектора создается полностью. Это векторная версия поля блока. Внедрение создается путем вызова предоставленной модели внедрения Azure OpenAI.

"name": "example-index-from-import-wizard",
"fields": [
  {"name": "chunk_id",  "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

Схема для приложений в стиле чата и RAG

Если вы разрабатываете хранилище для создания поиска, можно создать отдельные индексы для статического содержимого, индексированного и векторизованного, а также второй индекс для бесед, которые можно использовать в потоках запросов. Следующие индексы создаются из акселератора chat-with-your-data-solution-accelerator.

Поля из индекса чата, поддерживающие создание интерфейса поиска:

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

Поля из индекса бесед, поддерживающего журнал оркестрации и чата:

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

Ниже показан снимок экрана с результатами поиска в Обозреватель поиска для индекса бесед. Оценка поиска составляет 1,00, так как поиск был неквалифицирован. Обратите внимание на поля, которые существуют для поддержки оркестрации и потоков запросов. Идентификатор беседы определяет определенный чат. "type"указывает, является ли содержимое от пользователя или помощник. Даты используются для возрастных чатов из истории.

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

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

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

• Количество и композиция документов
• Атрибуты для отдельных полей. Например, для фильтруемых полей требуется больше хранилища.
• Конфигурация индекса, включая векторную конфигурацию, указывающую, как создаются внутренние структуры навигации на основе выбора HNSW или исчерпывающего KNN для поиска сходства.

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

На следующем снимку экрана показана служба S1, настроенная с одной секцией и одной реплика. Эта конкретная служба имеет 24 небольших индексов с одним полем вектора в среднем, каждое поле, состоящее из 1536 внедрения. На второй плитке показана квота и использование векторных индексов. Векторный индекс — это внутренняя структура данных, созданная для каждого поля вектора. Таким образом, хранилище для векторных индексов всегда является частью хранилища, используемого индексом в целом. Другие невекторные поля и структуры данных используют остальные.

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

• Проверьте дату развертывания службы поиска. Если она была создана до 3 апреля 2024 г., рассмотрите возможность создания новой службы поиска для повышения емкости.

• Выберите масштабируемый уровень , если вы ожидаете колебания требований к хранилищу векторов. Уровень "Базовый" фиксирован на одной секции в более старых службах поиска. Рассмотрим стандарт 1 (S1) и выше для повышения гибкости и более быстрой производительности или создайте новую службу поиска, которая использует более высокие ограничения и дополнительные секции на каждом уровне.

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

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

Примечание.

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

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

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

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

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

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

Подключение к конечной точке

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

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

Как подключиться к службе "Поиск ИИ Azure"

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

2. Начните с портал Azure. Пользователь, создавший службу поиска, может просматривать и управлять службой поиска, включая предоставление доступа другим пользователям на странице управления доступом (IAM).

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

   • Краткое руководство. REST
   • Примеры векторов

Безопасный доступ к векторным данным

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

Управление хранилищами векторов

Azure предоставляет платформу мониторинга, включающую ведение журнала диагностики и оповещения. Рекомендуется использовать следующие рекомендации:

• Включить ведение журнала диагностики
• Настройка оповещений
• Анализ производительности запросов и индексов

См. также

• Создание векторного хранилища с помощью REST API (краткое руководство)
• Создание хранилища векторов
• Запрос векторного индекса