Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
В этой статье представлен обзор векторного поиска в виде мозаики ИИ, включая то, что это и как это работает.
Что такое Mosaic AI Vector Search?
Векторный поиск Mosaic AI — это решение для векторного поиска, встроенное в платформу управления данными Databricks и интегрированное с ее инструментами управления и повышения производительности. Векторный поиск — это тип поиска, оптимизированный для получения векторных представлений. Внедрение — это математические представления семантического содержимого данных, обычно текстовые или изображения. Внедрение создается большой языковой моделью и является ключевым компонентом многих создаваемых приложений ИИ, которые зависят от поиска документов или изображений, похожих друг на друга. Примерами являются системы RAG, системы рекомендаций, а также распознавание изображений и видео.
С помощью Mosaic AI Vector Search вы создаете векторный поисковый индекс из таблицы Delta. Индекс включает встроенные данные с метаданными. Затем можно запросить индекс с помощью REST API, чтобы определить наиболее похожие векторы и вернуть связанные документы. Индекс можно структурировать для автоматической синхронизации при обновлении базовой таблицы Delta.
Векторный поиск Mosaic AI поддерживает следующее:
- Гибридный поиск по подобию ключевых слов.
- Фильтрация.
- Повторная настройка.
- Списки управления доступом (ACL) для управления конечными точками поиска векторов.
- Синхронизация только выбранных столбцов.
- Сохранить и синхронизировать созданные эмбеддинги.
Как работает поиск векторов с помощью Mosaic AI?
Поиск векторного поиска в Mosaic AI использует алгоритм иерархически навигационного малого мира (HNSW) для поиска ближайшего соседа (ANN) и метрику расстояния L2 для измерения сходства векторов. Если вы хотите использовать сходство косинуса, необходимо нормализовать внедрение точек данных, прежде чем передавать их в векторный поиск. Когда точки данных нормализуются, ранжирование, созданное на расстоянии L2, совпадает с ранжированием, генерируемым косинусом сходства.
Поиск векторов Mosaic AI также поддерживает гибридный поиск с учетом схожести ключевых слов, который объединяет векторный поиск с традиционными технологиями поиска на основе ключевых слов. Этот подход соответствует точным словам в запросе, а также использует поиск сходства на основе векторов для отслеживания семантических связей и контекста запроса.
Интегрируя эти два метода, гибридный поиск по аналогии с ключевыми словами извлекает документы, содержащие не только точные ключевые слова, но и те, которые концептуально похожи, предоставляя более полные и соответствующие результаты поиска. Этот метод особенно полезен в приложениях RAG, где исходные данные имеют уникальные ключевые слова, такие как номера SKU или идентификаторы, которые не подходят для чистого поиска сходства.
Дополнительные сведения об API см. в справочнике по пакету SDK для Python и запросе индекса векторного поиска.
Вычисление поиска сходства
Вычисление сходства использует следующую формулу:
где dist — это расстояние между q запроса и записью индекса x:
Алгоритм поиска ключевых слов
Оценки релевантности вычисляются с помощью Okapi BM25. Все текстовые или строковые столбцы, включая встраивание исходного текста и столбцы метаданных в текстовом или строковом формате, подвергаются поиску. Функция маркеризации разделяется по границам слова, удаляет знаки препинания и преобразует весь текст в нижний регистр.
Как объединяются поиск по подобия и поиск ключевых слов
Результаты поиска по подобию и поиска ключевых слов объединяются с помощью функции Reciprocal Rank Fusion (RRF).
RRF пересчитывает каждую оценку документов из каждого метода, используя новую оценку.
В приведенном выше уравнении ранг начинается с 0, суммирует оценки для каждого документа и возвращает документы с наивысшими оценками.
rrf_param определяет относительную важность более ранжированных и низкоранговых документов. Согласно литературе, rrf_param установлено равным 60.
Оценки нормализуются таким образом, чтобы самый высокий показатель равен 1, а наименьший показатель равен 0, используя следующее уравнение:
Варианты предоставления векторных вложений
Чтобы создать индекс векторного поиска в Databricks, необходимо сначала решить, как предоставить векторные представления. Databricks поддерживает три варианта:
Вариант 1: Индекс разностной синхронизации с встраиваниями, вычисленными Databricks Вы предоставляете исходную таблицу Delta, содержащую данные в текстовом формате. Databricks вычисляет встраиваемые представления с использованием заданной вами модели и при необходимости сохраняет их в таблицу в Unity Catalog. По мере обновления таблицы Delta индекс остается синхронизированным с таблицей Delta.
На схеме ниже показан соответствующий процесс:
- Вычисление векторных представлений запросов. Запрос может включать фильтры метаданных.
- Выполните поиск сходства, чтобы определить наиболее релевантные документы.
- Верните наиболее релевантные документы и добавьте их в запрос.
Вариант 2. Индекс разностной синхронизации с самостоятельными встраиваниями Вы предоставляете исходную таблицу Delta, содержащую предварительно рассчитанные встраивания. По мере обновления таблицы Delta индекс остается синхронизированным с таблицей Delta.
На схеме ниже показан соответствующий процесс:
- Запрос состоит из эмбеддингов и может содержать фильтры для метаданных.
- Выполните поиск сходства, чтобы определить наиболее релевантные документы. Верните наиболее релевантные документы и добавьте их в запрос.
Вариант 3. Индекс прямого векторного доступа При изменении таблицы внедрения необходимо вручную обновить индекс с помощью REST API.
На схеме ниже показан соответствующий процесс:
Параметры конечной точки
Поиск по вектору AI Mosaic предлагает следующие параметры, чтобы выбрать конфигурацию конечной точки, которая соответствует потребностям вашего приложения.
Замечание
Оптимизированные для хранения конечные точки находятся в общедоступной предварительной версии.
- Стандартные конечные точки имеют емкость 320 миллионов векторов в измерении 768.
- Оптимизированные для хранения конечные точки имеют большую емкость (более одного миллиарда векторов в измерении 768) и обеспечивают более быстрое индексирование 10–20x. Запросы к оптимизированным для хранения конечным точкам имеют слегка увеличенную задержку примерно в 250 миллисекунд. Цены на этот параметр оптимизированы для большего количества векторов. Сведения о ценах см. на странице цен на векторный поиск. Сведения об управлении затратами на поиск векторов см. в руководстве по управлению затратами на поиск векторов в мозаике ИИ.
При создании конечной точки укажите тип конечной точки.
См. также ограничения конечных точек, оптимизированных для хранения.
Настройка векторного поиска в Mosaic AI
Чтобы использовать Mosaic AI Vector Search, необходимо создать следующее:
Конечная точка векторного поиска. Эта конечная точка служит индексу векторного поиска. Вы можете запрашивать и обновлять конечную точку с помощью REST API или пакета SDK. См. инструкции по созданию конечной точки поиска вектора.
Конечные точки автоматически масштабируются, чтобы поддерживать размер индекса или количество одновременных запросов. Оптимизированные для хранения конечные точки автоматически уменьшаются при удалении индекса. Стандартные конечные точки не уменьшают масштаб автоматически.
Индекс векторного поиска. Индекс векторного поиска создается из таблицы Delta и оптимизирован для предоставления приблизительных поисков ближайших соседей (ANN) в режиме реального времени. Цель поиска — определить документы, аналогичные запросу. Индексы векторного поиска отображаются и управляются каталогом Unity. Инструкции см . в статье "Создание индекса векторного поиска ".
Кроме того, если вы решите вычислить векторные представления с помощью Databricks, можно использовать предварительно настроенную конечную точку API Foundation Model или создать конечную точку сервиса модели для сервиса модели векторных представлений по вашему выбору. Инструкции см. в API-интерфейсах базовой модели с оплатой за токен или создании конечных точек для обслуживания базовых моделей.
Чтобы запросить конечную точку обслуживания модели, используйте REST API или пакет SDK для Python. Запрос может определять фильтры на основе любого столбца в таблице Delta. Дополнительные сведения см. в разделе "Использование фильтров по запросам", справочнику по API или справочнику по пакету SDK для Python.
Требования
- Рабочая область с включенной поддержкой каталога Unity.
- Бессерверные вычисления включены. Инструкции см. в разделе "Подключение к бессерверным вычислениям".
- Для стандартных конечных точек исходная таблица должна иметь включенный фид изменений данных. См. Использование канала изменений данных Delta Lake в Azure Databricks.
- Чтобы создать индекс векторного поиска, необходимо иметь CREATE TABLE привилегии в схеме каталога, в которой будет создан индекс.
Разрешение на создание конечных точек поиска векторов и управление ими настраивается с помощью списков управления доступом. См. списки ACL для конечных точек векторного поиска.
защита данных и проверка подлинности
Databricks реализует следующие элементы управления безопасностью для защиты данных:
- Каждый запрос клиента к поиску векторов ИИ Мозаики логически изолирован, аутентифицирован и авторизован.
- Поиск вектора мозаики шифрует все данные в состоянии покоя (AES-256) и во время передачи (TLS 1.2+).
Поиск вектора Mosaic AI поддерживает два режима проверки подлинности: сервисные учетные записи и личные токены доступа (PATs). Для рабочих приложений Databricks рекомендует использовать сервисные учетные записи, которые могут обеспечивать производительность каждого запроса на 100 мс быстрее по сравнению с личными токенами доступа.
Токен учетной записи службы. Администратор может создать токен служебного принципала и использовать его в SDK или API. См. использование служебных принципалов. Для производственных сценариев использования Databricks рекомендует использовать токен служебного принципала.
# Pass in a service principal vsc = VectorSearchClient(workspace_url="...", service_principal_client_id="...", service_principal_client_secret="..." )Личный маркер доступа. Вы можете использовать персональный токен доступа для аутентификации с помощью векторного поиска Mosaic AI. См. маркер проверки подлинности личного доступа. Если вы используете пакет SDK в среде записной книжки, пакет SDK автоматически создает маркер PAT для проверки подлинности.
# Pass in the PAT token client = VectorSearchClient(workspace_url="...", personal_access_token="...")
Управляемые клиентом ключи (CMK) поддерживаются в конечных точках, созданных 8 мая 2024 г. или после 8 мая 2024 г.
Отслеживание использования и затрат
Оплачиваемая система использования позволяет отслеживать использование и затраты, связанные с индексами и конечными точками векторного поиска. Вот пример запроса:
WITH all_vector_search_usage (
SELECT *,
CASE WHEN usage_metadata.endpoint_name IS NULL THEN 'ingest'
WHEN usage_type = "STORAGE_SPACE" THEN 'storage'
ELSE 'serving'
END as workload_type
FROM system.billing.usage
WHERE billing_origin_product = 'VECTOR_SEARCH'
),
daily_dbus AS (
SELECT workspace_id,
cloud,
usage_date,
workload_type,
usage_metadata.endpoint_name as vector_search_endpoint,
CASE WHEN workload_type = 'serving' THEN SUM(usage_quantity)
WHEN workload_type = 'ingest' THEN SUM(usage_quantity)
ELSE null
END as dbus,
CASE WHEN workload_type = 'storage' THEN SUM(usage_quantity)
ELSE null
END as dsus
FROM all_vector_search_usage
GROUP BY all
ORDER BY 1,2,3,4,5 DESC
)
SELECT * FROM daily_dbus
Вы также можете запросить использование согласно бюджетной политике. См. векторный поиск Mosaic AI: бюджетная политика.
Дополнительные сведения о содержимом таблицы использования выставляемых счетов см. в справочнике по системным таблицам . Дополнительные запросы приведены в следующем примере записной книжки.
Векторный поиск системных таблиц запрашивает записную книжку
Ограничения размера ресурсов и данных
В следующей таблице перечислены ограничения размера ресурсов и данных для конечных точек и индексов векторного поиска:
| Resource | Степень детализации | Лимит |
|---|---|---|
| Конечные точки поиска векторов | В расчете на рабочую область | 100 |
| Встраивания (индекс Delta Sync) | На стандартную конечную точку | ~ 320 000 000 при размерности внедрения 768 ~ 160 000 000 при размерности встраивания 1536 ~ 80 000 000 при размере встраивания 3072 (масштабирование приблизительно линейно) |
| Встраивания (индекс прямого векторного доступа) | На стандартную конечную точку | ~ 2 000 000 при размерности встраивания 768 |
| Встраивание (оптимизированная для хранения данных конечная точка) | Для каждой оптимизированной для хранения конечной точки | ~ 1 000 000 000 при размерности встраивания 768 |
| Измерение внедрения | По индексу | 4096 |
| Indexes | Для каждой конечной точки | 50 |
| Колонны | По индексу | 50 |
| Колонны | Поддерживаемые типы: Байт, короткое, целое число, длинное, плавающее, двойное, логическое значение, строка, метка времени, дата | |
| Поля метаданных | По индексу | 50 |
| Имя индекса | По индексу | 128 символов |
Следующие ограничения применяются к созданию и обновлению индексов векторного поиска:
| Resource | Степень детализации | Лимит |
|---|---|---|
| Размер строки для индекса Дельта-синхронизации | По индексу | 100 КБ |
| Внедрение размера исходного столбца для индекса Delta Sync | По индексу | 32764 байта |
| Ограничение на размер запроса массового upsert для индекса Direct Vector | По индексу | 10 МБ |
| Ограничение размера запроса массового удаления для индекса Direct Vector | По индексу | 10 МБ |
Следующие ограничения применяются к API запросов.
| Resource | Степень детализации | Лимит |
|---|---|---|
| Длина текста запроса | За каждый запрос | 32764 символов |
| Маркеры при использовании гибридного поиска | За каждый запрос | 1024 слова или 2-байтовые символы |
| Условия фильтрации | Предложение фильтра | 1024 элемента |
| Максимальное количество возвращенных результатов (приблизительный поиск ближайших соседей) | За каждый запрос | 10 000 |
| Максимальное количество возвращаемых результатов (поиск по аналогии с гибридными ключевыми словами) | За каждый запрос | 200 |
Ограничения
- Имя столбца
_idзарезервировано. Если в исходной таблице есть столбец с именем_id, переименуйте его перед созданием векторного индекса поиска. - Разрешения на уровне строк и столбцов не поддерживаются. Однако вы можете реализовать собственные списки управления доступом на уровне приложения с помощью API фильтра.
Ограничения конечных точек, оптимизированных для хранения
Ограничения в этом разделе применяются только к оптимизированным для хранения конечным точкам. Оптимизированные для хранения конечные точки находятся в общедоступной предварительной версии.
- Режим непрерывной синхронизации не поддерживается.
- Синхронизация столбцов не поддерживается.
- Измерение внедрения должно быть разделено на 16.
- Добавочное обновление частично поддерживается. Каждая синхронизация должна восстанавливать части индекса векторного поиска.
- Для управляемых индексов все встраиваемые ранее вычисления используются повторно, если исходная строка не изменилась.
- Следует ожидать значительного сокращения времени выполнения синхронизации от начала до конца по сравнению со стандартными конечными точками. Наборы данных с 1 миллиардом эмбеддингов должны завершить синхронизацию менее чем за 8 часов. Для синхронизации небольших наборов данных потребуется меньше времени.
- Рабочие области, совместимые с FedRAMP, не поддерживаются.
- Управляемые клиентом ключи (CMK) не поддерживаются.
- Чтобы использовать пользовательскую модель внедрения для управляемого индекса delta Sync, необходимо включить запрос ИИ для пользовательских моделей и внешних моделей . Сведения о включении предварительных версий см. в статье "Управление предварительными версиями Azure Databricks ".
- Оптимизированные для хранения конечные точки поддерживают до 1 млрд векторов размерностью 768. Если у вас есть более крупный случай использования, обратитесь к вашей команде аккаунт-менеджеров.