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


Выбор службы Azure для поиска векторов

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

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

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

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

Выберите службу кандидатов

Этот раздел поможет выбрать наиболее вероятные службы для ваших потребностей. Чтобы сузить выбор, начните с рассмотрения требований к системе.

Основные требования

Блок-схема, которая помогает выбрать подходящую службу Azure для поиска по вектору.

Блок-диаграмма, направляюющая выбор службы поиска векторов Azure. Процесс начинается с определения частоты изменения векторов и немедленного отражения обновлений. Эти решения приводят к выбору соответствующих служб баз данных: Azure Cosmos DB для PostgreSQL, гибкого сервера базы данных Azure для PostgreSQL, базы данных Azure SQL, Azure Cosmos DB для NoSQL, Azure DocumentDB или управляемого Redis Azure, основываясь на таких факторах, как существующие навыки, предпочтения между реляционными и NoSQL базами данных, потребности в производительности при работе в памяти и потребности в индексировании. Если нет, он оценивает другие критерии, такие как затраты, повторное использование существующих систем, расширенные функции поиска и поддержку неструктурированного содержимого или встраиваний с высокими размерностями. Этот выбор приводит к поиску ИИ Azure для сценариев, которые определяют приоритет гибридного поиска, семантического ранжирования или неструктурированного индексирования. Побочный путь уточняет выбор базы данных на основе предпочтений реляционной системы управления базами данных (RDBMS), индексирования ближайших соседей (ANN), больших размеров или параллельной обработки. Управляемый Redis Azure — это надежный кандидат, если требуется ультранизкая задержка в векторном поиске в памяти или когда Redis уже используется для кэширования или для управления сеансами. Поток завершается группированием служб баз данных в решения, адаптированные к конкретным потребностям, таким как Azure Cosmos DB для PostgreSQL, гибкий сервер Azure Database для PostgreSQL, база данных SQL, Azure Cosmos DB для NoSQL, Azure DocumentDB, управляемый Azure Redis и поиск с ИИ.

Чтобы решить, использовать ли традиционное решение для базы данных или поиск Azure AI, оцените свои требования и возможность выполнения поиска в реальном времени или векторного поиска на ваших данных. Традиционная реляционная база данных или база данных NoSQL лучше всего подходит для вашего сценария, если вы часто изменяете значения в векторизованных полях и изменения должны быть доступны для поиска в режиме реального времени или практически в реальном времени. Аналогичным образом лучшее решение для удовлетворения целевого показателя производительности может быть использование существующей базы данных. Однако если ваша рабочая нагрузка не требует поиска векторов в реальном или почти реальном времени, и вы можете управлять их индексом, поиск с ИИ может стать хорошим выбором.

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

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

Если вы решили использовать традиционную базу данных вместо поиска ИИ, некоторые функции расширенного поиска по умолчанию недоступны. Например, если вы хотите выполнить переранжирование или гибридный поиск, включите эту функцию с помощью Transact-SQL (T-SQL) или другого кодирования.

Матрица возможностей

В таблицах в этом разделе приведены основные различия в возможностях.

Функции уровня "Базовый"

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

Возможность Служба Azure Cosmos DB для PostgreSQL База данных Azure Cosmos DB для NoSQL Azure DocumentDB Гибкий сервер Базы данных Azure для PostgreSQL Управляемый Redis в Azure Поиск ИИ База данных SQL Azure
Встроенный векторный поиск Да1 Да Да2 Да1 Да9 Да3 Да
Тип векторных данных Да Да Да Да Да Да Да8
Ограничения измерения5 16 0006 или 2 000 5057 или 4096 16,000 16 0006 или 2 000 32,768 4,096 1 998 (предварительная версия)4
Несколько векторных полей Да Да Нет Да Да Да Да
Несколько векторных индексов Да Да Нет Да Да Да Да
  1. Поддержка векторного поиска предоставляется pgvectorрасширением PostgreSQL.
  2. Векторный поиск по внедрениям поддерживается в Azure DocumentDB.
  3. Поиск ИИ поддерживает использование векторов.
  4. Векторы могут храниться в столбце или переменной VARBINARY(8000) в базе данных SQL.
  5. Модели встраивания от OpenAI включают 1536 измерений для text-embedding-ada-002 и text-embedding-3-small, а также 3072 измерения для text-embedding-3-large. В мультимодальных моделях встраивания Azure Vision в Foundry Tools имеется 1024 измерения как для изображений, так и для текста.
  6. Векторы могут иметь до 16 000 измерений. Однако индексирование с помощью инвертированных плоских файлов (IVFFlat) и иерархически-навигационной структуры малого мира (HNSW) поддерживает векторы с максимальным количеством 2000 измерений.
  7. Векторы, индексированные с помощью типа неструктурированного индекса, могут иметь не более 505 измерений. Векторы, индексированные с помощью типа индекса quantizedFlat или DiskANN, могут иметь не более 4096 измерений.
  8. База данных SQL поддерживает тип векторных данных.
  9. Векторный поиск предоставляется модулем RediSearch в Управляемом Redis Azure.

Методы поиска

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

Метод поиска Служба Azure Cosmos DB для PostgreSQL База данных Azure Cosmos DB для NoSQL Azure DocumentDB Гибкий сервер Базы данных Azure для PostgreSQL Управляемый Redis в Azure Поиск ИИ База данных SQL Azure
Полнотекстовый поиск Да1 Да9 Да2 Да1 Да12 Да3 Да4
Гибридный поиск Да5 Да11 Да6 Да5 Да13 Да7 Да8
Встроенное переподборка результатов Нет Да10 Нет Нет Нет Да9 Нет
  1. PostgreSQL поддерживает полнотекстовый поиск.
  2. Azure DocumentDB поддерживает поиск и запрос с помощью текстовых индексов.
  3. Полнотекстовый поиск поддерживается в SQL Server.
  4. SQL Server поддерживает векторные данные.
  5. Гибридный поиск не предоставляется в качестве функции первого класса, но доступны примеры кодов.
  6. Гибридный поиск, объединяющий полнотекстовый и векторный поиск с взаимной комбинацией рангов (RRF), изначально поддерживается в Azure DocumentDB.
  7. Гибридный поиск, который объединяет полнотекстовый поиск, векторный поиск и семантический ранжирование, предоставляется в качестве функции первого класса в службе "Поиск ИИ Azure".
  8. Доступен пример гибридного поиска базы данных SQL Azure и SQL Server.
  9. Семантическое ранжирование — это функция первого класса, которая переупорядочивает результаты полнотекстового и векторного поиска.
  10. Cosmos DB NoSQL поддерживает полнотекстовый поиск с полнотекстовой оценкой.
  11. Cosmos DB NoSQL поддерживает гибридный поиск.
  12. Управляемый Redis Azure поддерживает полнотекстовый поиск по модулю RediSearch, включая маркеризацию текста, стебливание и ранжирование.
  13. Управляемый Redis Azure поддерживает гибридный поиск путем объединения поиска сходства векторов с фильтрацией атрибутов по тексту, числовым, тегам и географическим полям.

Алгоритмы индексирования векторных данных

Индексирование векторных данных — это возможность эффективно хранить и извлекать векторы. Эта возможность важна, так как индексирование влияет на скорость и точность поиска сходства и запросов ближайших соседей в источниках данных.

Индексы обычно основаны на исчерпывающем алгоритме k-ближайших соседей (Ek-NN) или алгоритме искусственных нейронных сетей (ANN). Ek-NN выполняет исчерпывающий поиск по всем точкам данных и возвращает точные k ближайших соседей. Ek-NN работает с высокой скоростью на небольших объемах данных, но может вызывать задержки при обработке больших объемов данных.

DiskANN, HNSW и IVFlat — это индексы алгоритмов ANN. Выбор соответствующей стратегии индексирования требует тщательного рассмотрения различных факторов, таких как характер набора данных, конкретные требования запросов и доступные ресурсы. DiskANN может адаптироваться к изменению набора данных и сохранять вычислительные ресурсы. HNSW превосходно работает в системах, которые требуют быстрых ответов на запросы и могут адаптироваться к изменениям в наборе данных. IVFlat эффективен в средах, где аппаратные ресурсы ограничены или объемы запросов не высоки.

В следующей таблице показаны указанные типы индексирования векторных данных.

Подход к индексации Служба Azure Cosmos DB для PostgreSQL База данных Azure Cosmos DB для NoSQL Azure DocumentDB Гибкий сервер Базы данных Azure для PostgreSQL Управляемый Redis в Azure Поиск ИИ База данных SQL Azure
DiskANN Да Да Да2 Да1 Нет Нет Да3
E-kNN Да Да Да Да Да8 Да Да
HNSW Да Нет Да2 Да Да9 Да Нет
IVFFlat Да Нет Да Да Нет Нет Нет
Другие - Плоская, квантизованнаяПлоская4 Ограничение векторного поля5
Ограничение векторного индекса6
- - - Внешние библиотеки доступны7
  1. Дополнительные сведения см. в разделе DiskANN для гибкого сервера Базы данных Azure для PostgreSQL.
  2. Дополнительные сведения см. в статье Azure DocumentDB — обзор поиска векторов.
  3. Индексирование векторов на основе diskANN в настоящее время доступно в частной предварительной версии для SQL Azure.
  4. Дополнительные сведения см. в политиках индексирования векторов.
  5. Для каждого контейнера доступно только одно поле вектора.
  6. Для каждого контейнера доступно только один векторный индекс.
  7. Индекс можно создать с помощью внешних библиотек, таких как Scikit Learn или FAISS.
  8. Управляемый Redis Azure поддерживает исчерпывающий поиск k-ближайших соседей с помощью типа индекса FLAT (грубая сила).
  9. В Azure Managed Redis поддерживается HNSW для поиска приблизительных ближайших соседей. Дополнительные сведения см. в разделе "Поиск сходства векторов".

Возможности вычисления сходства и расстояния

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

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

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

Встроенное вычисление сравнения векторов Служба Azure Cosmos DB для PostgreSQL База данных Azure Cosmos DB для NoSQL Azure DocumentDB Гибкий сервер Базы данных Azure для PostgreSQL Управляемый Redis в Azure Поиск ИИ База данных SQL Azure
Косинусное сходство Да Да1 Да Да Да3 Да Да2
Евклидово расстояние (L2-норма) Да Да1 Да Да Да3 Да Да2
Dot product Да Да1 Да Да Да3 Да Да2
  1. Дополнительные сведения см. в разделе вычисления векторного расстояния для Azure Cosmos DB для NoSQL.
  2. Дополнительные сведения см. в примерах вычислений расстояния для базы данных SQL Azure и SQL Server.
  3. Управляемый Redis Azure поддерживает косинусное сходство, евклидово расстояние (L2) и метрики расстояния внутреннего произведения (IP). Дополнительные сведения см. в разделе "Поиск сходства векторов".

Интеграция с Azure OpenAI и другими компонентами

При реализации векторного поиска можно также рассмотреть возможность связывания с другими компонентами Майкрософт. Например, Azure OpenAI помогает создавать векторы для данных и входных запросов для поиска сходства векторов.

Возможность Служба Azure Cosmos DB для PostgreSQL База данных Azure Cosmos DB для NoSQL Azure DocumentDB Гибкий сервер Базы данных Azure для PostgreSQL Управляемый Redis в Azure Поиск ИИ База данных SQL Azure
Azure OpenAI — добавление собственных данных Нет Нет Да1 Нет Нет Да2 Нет
Внедрение вектора с помощью Azure OpenAI Нет Нет Нет Да3 Нет Да4 Да5
Интеграция с семантическим ядром Да6 Да7 Да8 Да6 Да11 Да9 Да10
  1. Azure DocumentDB поддерживается в качестве источника данных для Azure OpenAI в ваших данных.
  2. Поиск ИИ поддерживается в качестве источника данных для Azure OpenAI на ваших данных.
  3. Доступно расширение ИИ Azure .
  4. Поиск ИИ предоставляет навык для векторизации фрагментированного текста.
  5. Вы можете создать хранимую процедуру для развертывания вашей встраиваемой модели.
  6. Эта служба поддерживается как соединителем памяти, так и соединителем векторной базы данных. Дополнительные сведения см. в документации по C#.
  7. Эта служба поддерживается как соединителем памяти, так и соединителем векторной базы данных. Документация доступна как для C# , так и для Python.
  8. Эта служба поддерживается как соединитель векторной базы данных. Документация доступна как для C# , так и для Python.
  9. Эта служба поддерживается как соединителем памяти, так и соединителем векторной базы данных. Документация доступна как для C# , так и для Python.
  10. Эта служба поддерживается как соединитель памяти.
  11. Эта служба поддерживается как соединитель векторной базы данных. Дополнительные сведения см. в документации по соединителю Redis.

Это важно

Azure OpenAI On Your Data не рекомендуется.

Мы рекомендуем перенести рабочие нагрузки Azure OpenAI On Your Data в Службу агента Foundry с помощью Foundry IQ, чтобы извлекать содержимое и генерировать основанные на ваших данных ответы.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

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