Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Используйте интегрированную базу данных векторов в Azure DocumentDB, чтобы легко подключать приложения на основе ИИ с данными, хранящимися в Azure DocumentDB. Эта интеграция может включать приложения, созданные с помощью внедрения Azure OpenAI. Встроенная векторная база данных позволяет эффективно хранить, индексировать и запрашивать высокомерные векторные данные, хранящиеся непосредственно в Azure DocumentDB, а также исходные данные, из которых создаются векторные данные. Это устраняет необходимость передачи ваших данных в альтернативные векторные хранилища и понести дополнительные расходы.
Что такое хранилище векторов?
Векторное хранилище или векторная база данных — это база данных, предназначенная для хранения векторных встраиваний и управления ими, которые являются математическими представлениями данных в высокоразмерном пространстве. В этом пространстве каждое измерение соответствует признаку данных, а для представления сложных данных можно использовать десятки тысяч измерений. Позиция вектора в этом пространстве представляет свои характеристики. Слова, фразы или целые документы, изображения, аудио и другие типы данных могут быть векторизированы.
Как работает векторное хранилище?
В векторном хранилище алгоритмы поиска векторов используются для индексирования и обработки эмбеддингов запросов. Некоторые известные алгоритмы поиска векторов включают иерархический навигационно-малый мир (HNSW), инвертированные файлы (IVF) и DiskANN. Векторный поиск — это метод, который помогает находить аналогичные элементы на основе их характеристик данных, а не по точным совпадениям в поле свойства. Этот метод полезен в таких приложениях, как поиск аналогичного текста, поиск связанных изображений, рекомендации или даже обнаружение аномалий. Он используется для поиска векторов вложений (списков чисел) данных, которые вы создали с помощью модели машинного обучения, используя API для вложений. Примерами API встраивания являются Azure OpenAI embeddings или Hugging Face на Azure. Векторный поиск измеряет расстояние между векторами данных и вектором запроса. Векторы данных, близкие к вектору запросов, являются наиболее похожими семантикой.
В интегрированной базе данных векторов в Azure DocumentDB можно хранить, индексировать и запрашивать внедрение вместе с исходными данными. Этот подход устраняет дополнительные затраты на репликацию данных в отдельной базе данных чистого вектора. Кроме того, эта архитектура сохраняет векторные внедрения и исходные данные вместе, что упрощает операции с многомодальными данными и обеспечивает более высокую согласованность данных, масштабирование и производительность.
Варианты использования векторной базы данных
Векторные базы данных используются во многих областях анализа ИИ и данных. Они помогают с такими задачами, как понимание естественного языка, распознавание изображений и видео, создание систем рекомендаций и возможности поиска. Их можно найти как в аналитических приложениях ИИ, так и в приложениях для создания искусственного интеллекта.
Например, можно использовать векторную базу данных для:
- Определите похожие изображения, документы и песни на основе их содержимого, тем, тональности и стилей.
- Определите аналогичные продукты на основе их характеристик, функций и групп пользователей.
- Рекомендуйте контент, продукты или услуги на основе предпочтений отдельных лиц.
- Рекомендуется использовать содержимое, продукты или службы на основе сходств групп пользователей.
- Определите оптимальные возможные варианты из большого пула вариантов для удовлетворения сложных требований.
- Определите аномалии данных или мошеннические действия, которые отличаются от преобладающих или нормальных шаблонов.
- Реализуйте постоянную память для агентов ИИ.
- Включите поддержку технологии Retrieval-Augmented Generation (RAG).
Интегрированная векторная база данных и чистая векторная база данных
Существуют два распространенных типа реализаций векторной базы данных: чистая векторная база данных и интегрированная векторная база данных в NoSQL или реляционная база данных.
Чистая векторная база данных эффективно хранит векторные внедрения и управляет ими с небольшим количеством метаданных. Он отделен от источника данных, от которого производные внедрения.
Векторная база данных, которая интегрируется в высокопроизводительную базу данных NoSQL или реляционную базу данных, предоставляет дополнительные возможности. Интегрированная векторная база данных в NoSQL или реляционной базе данных может хранить, индексировать и выполнять запросы к векторным представлениям вместе с соответствующими исходными данными. Этот подход устраняет дополнительные затраты на репликацию данных в отдельной базе данных чистого вектора. Кроме того, сохранение векторных внедрения и исходных данных лучше упрощает операции с многомодальными данными и обеспечивает более высокую согласованность данных, масштабирование и производительность.
Базы данных векторов с открытым исходным кодом
Когда разработчики выбирают векторные базы данных, варианты с открытым исходным кодом предоставляют множество преимуществ. Открытый исходный код означает, что исходный код программного обеспечения доступен бесплатно, что позволяет пользователям настраивать базу данных в соответствии с конкретными потребностями. Эта гибкость полезна для организаций, которые подвергаются уникальным нормативным требованиям к данным, таким как компании в отрасли финансовых услуг.
Еще одним преимуществом баз данных векторов с открытым кодом является сильная поддержка сообщества, которой они пользуются. Активные сообщества пользователей часто способствуют разработке этих баз данных, обеспечивают поддержку и совместное использование рекомендаций, продвижение инноваций.
Некоторые пользователи выбирают векторные базы данных с открытым исходным кодом, потому что они "бесплатны", то есть нет затрат на приобретение или использование программного обеспечения. Альтернативой является использование бесплатных уровней, предлагаемых службами управляемых векторных баз данных. Эти управляемые службы предоставляют не только бесплатный доступ к определенному ограничению использования, но и упрощают рабочее бремя, обрабатывая обслуживание, обновления и масштабируемость. Таким образом, используя бесплатный уровень управляемых служб баз данных векторов, вы можете сократить затраты на управление. Этот подход позволяет сосредоточиться больше на основных действиях, а не на администрировании баз данных.
Выберите лучшую базу данных вектора с открытым исходным кодом
Выбор лучшей векторной базы данных с открытым исходным кодом требует рассмотрения нескольких факторов. Производительность и масштабируемость базы данных имеют решающее значение, так как они влияют на то, может ли база данных обрабатывать определенные требования к рабочей нагрузке. Базы данных с эффективными возможностями индексирования и запросов обычно обеспечивают оптимальную производительность. Другим фактором является поддержка сообщества и документация, доступная для базы данных. Надежное сообщество и обширная документация могут оказать ценную помощь. Например, DocumentDB — это популярная векторная база данных с открытым кодом:
Самый популярный вариант может быть не лучшим вариантом для вас. Таким образом, следует сравнить различные параметры на основе функций, поддерживаемых типов данных и совместимости с существующими инструментами и платформами, которые вы используете. Также следует помнить о проблемах баз данных векторов с открытым исходным кодом.
Проблемы баз данных векторов с открытым исходным кодом
Большинство баз данных векторов с открытым исходным кодом, включая перечисленные ранее, являются чистыми векторными базами данных. Другими словами, они предназначены только для хранения и управления векторными встраиваниями, а также небольшим количеством метаданных. Так как они работают отдельно от исходных данных, необходимо переместить данные между различными службами. Эта сложность добавляет дополнительные затраты, делает вещи более сложными и может замедлить работу производственных систем.
Они также представляют проблемы, типичные для баз данных с открытым кодом:
- Настройка. Для установки, настройки и эксплуатации базы данных требуется глубокое знание, особенно для сложных развертываний. Оптимизация ресурсов и конфигурации при масштабировании операций требует тесного мониторинга и корректировки.
- Обслуживание. Необходимо управлять собственными обновлениями, исправлениями и обслуживанием. Опыт машинного обучения недостаточно; У вас также должен быть широкий опыт администрирования базы данных.
- Поддержка: официальная поддержка может быть ограничена по сравнению с управляемыми службами, опираясь больше на помощь сообщества.
Поэтому, хотя изначально они бесплатны, векторные базы данных с открытым исходным кодом несут значительные затраты при увеличении масштаба. Расширение операций требует больше оборудования, квалифицированных ИТ-сотрудников и расширенного управления инфраструктурой, что приводит к более высоким затратам на оборудование, персонал и операционные расходы. Масштабирование баз данных векторов с открытым исходным кодом может быть финансово требующим, несмотря на отсутствие сборов за лицензирование.
Решение проблем баз данных векторов с открытым исходным кодом
Полностью управляемая база данных векторов, которая интегрируется в высокопроизводительную базу данных NoSQL или реляционную базу данных, позволяет избежать дополнительных затрат и сложности баз данных векторов с открытым исходным кодом. Такие базы данных хранят, индексируют и запрашивают векторы вместе с соответствующими исходными данными. Этот подход устраняет дополнительные затраты на репликацию данных в отдельной базе данных чистого вектора. Кроме того, сохранение векторных внедрений и исходных данных лучше упрощает операции с многомодальными данными и обеспечивает более высокую согласованность данных, масштабирование и производительность. Между тем, полностью управляемая служба помогает разработчикам избежать проблем от настройки, обслуживания и использования помощи сообщества для базы данных векторов с открытым исходным кодом. Кроме того, некоторые службы управляемых векторных баз данных предлагают пожизненный бесплатный уровень обслуживания.
Примером является интегрированная векторная база данных в Azure DocumentDB. Эта настройка позволяет разработчикам сэкономить деньги так же, как при использовании векторных баз данных с открытым кодом. Но в отличие от вариантов с открытым исходным кодом, поставщик услуг заботится о обслуживании, обновлениях и масштабировании. Обновление быстро и легко, сохраняя низкую общую стоимость владения (TCO), когда пришло время увеличить масштаб операций. Эту службу можно также использовать для удобного масштабирования приложений MongoDB, которые уже находятся в рабочей среде.
Выполнение поиска сходства векторов
Azure DocumentDB предоставляет надежные возможности поиска векторов, что позволяет выполнять высокоскоростные поиски сходства в сложных наборах данных. Чтобы выполнить векторный поиск в Azure DocumentDB, сначала необходимо создать векторный индекс. Хотя Azure DocumentDB предлагает несколько вариантов, ниже приведены некоторые общие рекомендации, которые помогут вам приступить к работе на основе размера набора данных:
| IVF | HNSW | DiskANN (рекомендуется) | |
|---|---|---|---|
| Описание | Индекс IVFlat делит векторы на списки, а затем выполняет поиск подмножества, ближайшего к вектору запроса. | Индекс HNSW создает многоуровневый граф. | DiskANN — это приблизительный ближайший алгоритм поиска соседей, предназначенный для эффективного векторного поиска в любом масштабе. |
| Важные компромиссы |
Плюсы: Более быстрое время сборки, снижение использования памяти. Минусы: Низкая производительность запросов (с точки зрения компромисса со скоростью отзыва). |
Плюсы: Более высокую производительность запросов (с точки зрения компромисса со скоростью отзыва) можно создать в пустой таблице. Минусы: Более медленное время сборки, более высокая скорость использования памяти. |
Плюсы: Эффективная в любом масштабе, высокая память, высокая пропускная способность, низкая задержка. |
| Число векторов | До 10 000 | До 50 000 | До 500 000+ |
| Рекомендуемый уровень кластера | M10 или M20 | M30 и выше | M30 и выше |
Индексы DiskANN можно использовать на M30 и более поздних уровнях. Чтобы создать индекс DiskANN, задайте параметр "kind" равным "vector-diskann" по следующему шаблону:
{
"createIndexes": "<collection_name>",
"indexes": [
{
"name": "<index_name>",
"key": {
"<path_to_property>": "cosmosSearch"
},
"cosmosSearchOptions": {
"kind": "vector-diskann",
"dimensions": <integer_value>,
"similarity": <string_value>,
"maxDegree" : <integer_value>,
"lBuild" : <integer_value>,
}
}
]
}
| Поле | Тип | Description |
|---|---|---|
index_name |
струна | Уникальное имя индекса. |
path_to_property |
струна | Путь к свойству, содержащему вектор. Этот путь может быть свойством верхнего уровня или путем точечной нотации к свойству. Векторы должны быть в формате number[], чтобы быть индексированными и использоваться в результатах векторного поиска. Вектор, использующий другой тип, например double[], предотвращает индексирование документа. Неиндексированные документы не возвращаются в результате векторного поиска. |
kind |
струна | Тип создаваемого векторного индекса. Параметры: vector-ivf, vector-hnswи vector-diskann. |
dimensions |
целое число | Число измерений для сходства векторов. DiskANN поддерживает до 16 000 измерений (с продуктовым квантованием), и в будущем планируется поддержка для 40 000 и более. |
similarity |
струна | Метрика сходства, используемая с индексом. Возможные варианты: COS (косинус расстояние), L2 (Евклидеан расстояние) и IP (внутренний продукт). |
maxDegree |
целое число | Максимальное количество ребер на узел в графе. Этот параметр варьируется от 20 до 2048 (по умолчанию — 32). Более maxDegree высокий метод подходит для наборов данных с высокой размерностью и/или высокими требованиями к точности. |
lBuild |
целое число | Задает количество потенциальных соседей, вычисляемых во время построения индекса DiskANN. Этот параметр, который варьируется от 10 до 500 (по умолчанию — 50), балансирует точность и вычислительные затраты: более высокие значения повышают качество индекса и точность, но увеличивают время сборки. |
Выполнение векторного поиска с помощью DiskANN
Чтобы выполнить векторный поиск, используйте стадию конвейера агрегирования $search и выполните запрос с оператором cosmosSearch. DiskANN обеспечивает высокопроизводительный поиск в массивных наборах данных с дополнительными фильтрами, такими как геопространственные или текстовые фильтры.
{
"$search": {
"cosmosSearch": {
"path": "<path_to_property>",
"query": "<query_vector>",
"k": <num_results_to_return>,
"filter": {"$and": [
{ "<attribute_1>": { "$eq": <value> } },
{"<location_attribute>": {"$geoWithin": {"$centerSphere":[[<longitude_integer_value>, <latitude_integer_value>], <radius>]}}}
]}
}
}
},
| Поле | Тип | Description |
|---|---|---|
lSearch |
целое число | Задает размер динамического списка кандидатов для поиска. Значение по умолчанию — 40, с настраиваемым диапазоном от 10 до 1000. Увеличение значения улучшает отзыв, но может снизить скорость поиска. |
k |
целое число | Определяет количество возвращаемых результатов поиска. Значение k должно быть меньше или равно lSearch. |
Пример использования индекса DiskANN с фильтрацией
Добавление векторов в базу данных
Чтобы использовать векторный поиск с геопространственными фильтрами, добавьте документы, которые включают как векторные представления, так и координаты местоположения. Можно создать эмбеддинги при помощи собственной модели, эмбеддингов Azure OpenAI, или API, например, Hugging Face на Azure.
from pymongo import MongoClient
client = MongoClient("<your_connection_string>")
db = client["test"]
collection = db["testCollection"]
documents = [
{"name": "Eugenia Lopez", "bio": "CEO of AdventureWorks", "is_open": 1, "location": [-118.9865, 34.0145], "contentVector": [0.52, 0.20, 0.23]},
{"name": "Cameron Baker", "bio": "CFO of AdventureWorks", "is_open": 1, "location": [-0.1278, 51.5074], "contentVector": [0.55, 0.89, 0.44]},
{"name": "Jessie Irwin", "bio": "Director of Our Planet initiative", "is_open": 0, "location": [-118.9865, 33.9855], "contentVector": [0.13, 0.92, 0.85]},
{"name": "Rory Nguyen", "bio": "President of Our Planet initiative", "is_open": 1, "location": [-119.0000, 33.9855], "contentVector": [0.91, 0.76, 0.83]}
]
collection.insert_many(documents)
Создание векторного индекса DiskANN
В следующем примере показано, как настроить векторный индекс DiskANN с возможностями фильтрации. В этом примере включается создание векторного индекса для поиска сходства, добавление документов с векторными и геопространственных свойств, а также поля индексирования для дополнительной фильтрации.
db.command({
"createIndexes": "testCollection",
"indexes": [
{
"name": "DiskANNVectorIndex",
"key": {
"contentVector": "cosmosSearch"
},
"cosmosSearchOptions": {
"kind": "vector-diskann",
"dimensions": 3,
"similarity": "COS",
"maxDegree": 32,
"lBuild": 64
}
},
{
"name": "is_open",
"key": {
"is_open": 1
}
},
{
"name": "locationIndex",
"key": {
"location": 1
}
}
]
})
Эта команда создает векторный индекс DiskANN в поле contentVector в exampleCollection, что позволяет выполнять поиск сходства. Он также добавляет:
- Индекс в
is_openполе, поэтому можно фильтровать результаты на основе того, открыты ли предприятия. - Геопространственный индекс в поле
locationдля фильтрации по географической близости.
Выполнение векторного поиска
Чтобы найти документы с аналогичными векторами в пределах определенного географического радиуса, укажите queryVector поиск сходства и включите геопространственный фильтр.
query_vector = [0.52, 0.28, 0.12]
pipeline = [
{
"$search": {
"cosmosSearch": {
"path": "contentVector",
"vector": query_vector,
"k": 5,
"filter": {
"$and": [
{"is_open": {"$eq": 1}},
{"location": {"$geoWithin": {"$centerSphere": [[-119.7192861804, 34.4102485028], 100 / 3963.2]}}}
]
}
}
}
}
]
results = list(collection.aggregate(pipeline))
for result in results:
print(result)
В этом примере поиск сходства векторов возвращает самые k близкие векторы на основе указанной COS метрики сходства, а фильтрация результатов включает только открытые предприятия в радиусе 100 миль.
[
{
similarityScore: 0.9745354109084544,
document: {
_id: ObjectId("645acb54413be5502badff94"),
name: 'Eugenia Lopez',
bio: 'CEO of AdventureWorks',
is_open: 1,
location: [-118.9865, 34.0145],
contentVector: [0.52, 0.20, 0.23]
}
},
{
similarityScore: 0.9006955671333992,
document: {
_id: ObjectId("645acb54413be5502badff97"),
name: 'Rory Nguyen',
bio: 'President of Our Planet initiative',
is_open: 1,
location: [-119.7302, 34.4005],
contentVector: [0.91, 0.76, 0.83]
}
}
]
В этом результате показаны наиболее похожие документы на queryVector, ограниченные по радиусу 100 миль и работающими предприятиями. Каждый результат включает оценку сходства и метаданные, демонстрируя, как DiskANN в Azure DocumentDB поддерживает объединенные векторные и геопространственные запросы для обогащенных поисковых запросов с учетом местоположения.
Получение определений векторного индекса
Чтобы получить определение векторного индекса из коллекции, используйте listIndexes команду:
db.exampleCollection.getIndexes();
В этом примере возвращаются все параметры vectorIndex, которые использовались для создания индекса cosmosSearch:
[
{ v: 2, key: { _id: 1 }, name: '_id_', ns: 'test.exampleCollection' },
{
v: 2,
key: { vectorContent: 'cosmosSearch' },
name: 'vectorSearchIndex',
cosmosSearch: {
kind: <index_type>, // options are `vector-ivf`, `vector-hnsw`, and `vector-diskann`
numLists: 3,
similarity: 'COS',
dimensions: 3
},
ns: 'test.exampleCollection'
}
]
Отфильтрованный векторный поиск
Теперь можно выполнять векторные поиски с помощью любого поддерживаемого фильтра запросов, например $lt, , $lte$eq, $neq, $gte, $gt$in$ninи .$regex
Чтобы использовать префильтровку, сначала необходимо определить стандартный индекс для свойства, по которому необходимо отфильтровать, в дополнение к индексу вектора. Ниже приведен пример создания индекса фильтра:
db.runCommand({
"createIndexes": "<collection_name>",
"indexes": [ {
"key": {
"<property_to_filter>": 1
},
"name": "<name_of_filter_index>"
}
]
});
После того как индекс фильтра будет установлен, вы можете добавить "filter" предложение непосредственно в векторный поисковый запрос. В этом примере показано, как фильтровать результаты, в которых "title" значение свойства отсутствует в указанном списке:
db.exampleCollection.aggregate([
{
'$search': {
"cosmosSearch": {
"vector": "<query_vector>",
"path": <path_to_vector>,
"k": num_results,
"filter": {<property_to_filter>: {"$nin": ["not in this text", "or this text"]}}
},
"returnStoredSource": True }},
{'$project': { 'similarityScore': { '$meta': 'searchScore' }, 'document' : '$$ROOT' }
}
]);
Это важно
Чтобы оптимизировать производительность и точность префильтрованного векторного поиска, рассмотрите возможность настройки параметров индекса вектора. Для индексов DiskANN увеличение maxDegree или lBuild может привести к улучшению результатов. Для индексов HNSW экспериментируйте с более высокими значениями для m, efConstructionили efSearch может повысить производительность. Аналогичным образом, для индексов IVF , настройки numLists или nProbes может привести к более удовлетворительными результатами. Важно протестировать определенную конфигурацию с данными, чтобы результаты соответствовали вашим требованиям. Эти параметры влияют на структуру индекса и поведение поиска, а оптимальные значения могут отличаться в зависимости от характеристик данных и шаблонов запросов.
Использование средств оркестрации больших языковых моделей (LLM)
Использование векторной базы данных с семантическим ядром
Используйте семантическое ядро для координации извлечения информации из Azure DocumentDB и вашей модели LLM. Дополнительные сведения см. в репозитории GitHub.
Использование векторной базы данных с LangChain
Используйте LangChain для оркестрации получения информации из Azure DocumentDB и LLM. Дополнительные сведения см. в статье об интеграции LangChain для Azure DocumentDB.
Использование в качестве семантического кэша с LangChain
Используйте LangChain и Azure DocumentDB для управления семантическим кэшированием, используя ранее записанные ответы LLM, которые могут сэкономить затраты на API LLM и уменьшить задержку ответов. Дополнительные сведения см. в статье об интеграции LangChain с Azure DocumentDB.
Возможности и ограничения
- Поддерживаемые метрики расстояния: L2 (Euclidean), внутренний продукт и косинус.
- Поддерживаемые методы индексирования: IVFFLAT, HNSW и DiskANN.
- С помощью DiskANN и квантизации продуктов можно индексировать векторы до 16 000 измерений.
- Использование HNSW или IVF с половинной точностью позволяет индексировать векторы до 4000 измерений.
- Без сжатия максимальный размер вектора по умолчанию для индексирования составляет 2000.
- Индексирование применяется только к одному вектору на путь.
- Вы можете создать только один индекс на векторный путь.
Сводка
В этом руководстве показано, как создать векторный индекс, добавить документы, имеющие векторные данные, выполнить поиск сходства и получить определение индекса. Используя интегрированную базу данных векторов, вы можете эффективно хранить, индексировать и запрашивать высокомерные векторные данные непосредственно в Azure DocumentDB. Это позволяет раскрыть весь потенциал данных через векторные встраивания и дает возможность создавать более точные, эффективные и мощные приложения.
Связанный контент
- Эталонное решение .NET для розничной торговли, использующее формат RAG
- Шаблон RAG C# — интеграция служб OpenAI со Cosmos
- Шаблон Python RAG — чат-бот продукта Azure
- Руководство по записной книжке Python. Интеграция векторной базы данных с помощью LangChain
- Руководство по тетради Python — интеграция кэширования LLM через LangChain
- Python — интеграция LlamaIndex
- Python — интеграция семантической памяти ядра