Создание RAG с самостоятельно развернутой векторной базой данных Milvus и Snowpark Container Services
Jiang Chen, руководитель направления Ecosystem & AI Platform в Zilliz, недавно обсудил, как мы можем бесшовно интегрировать Milvus со Snowflake, в выступлении на Unstructured Data Meetup. В частности, он рассмотрел, как построить систему Retrieval Augmented Generation (RAG) с векторной базой данных Milvus и ее интеграцией с экосистемой Snowflake с использованием Snowpark Container Service (SPCS).
< Посмотрите выступление Jiang Chen на Youtube >
В этом посте мы кратко изложим ключевые тезисы Jiang и рассмотрим три важные темы.
Сначала мы обсудим использование Milvus для векторного поиска — важнейший шаг для построения системы RAG. Затем мы обсудим, как интегрировать Milvus в Snowflake с помощью SPCS. Наконец, мы также обсудим будущий ландшафт RAG. Прежде чем углубиться в темы, давайте рассмотрим, как ИИ преобразовал поиск информации.
Как ИИ революционизирует процесс поиска информации
Развитие и популярность ИИ быстро изменили весь ландшафт поиска информации. До появления ИИ поиск информации в значительной степени опирался на статистические модели и методы сопоставления ключевых слов, такие как тегирование. Например, владельцу интернет-магазина пришлось бы вручную вводить теги для каждого продукта в заранее определенные категории. Если у него огромный каталог продуктов, этот процесс был бы непрактичным.
Аналогично, нам как клиентам пришлось бы вводить подходящие теги, чтобы получить именно тот продукт, который мы хотим. Проблема в том, что если мы введем тег, который не является точным, но имеет похожее значение с нужным нам продуктом, поиск информации с помощью метода тегирования не сможет предоставить нам подходящие продукты. Другими словами, метод тегирования не учитывает семантическое значение запроса.
ИИ революционизирует то, как мы используем неструктурированные данные
ИИ революционизирует то, как мы используем неструктурированные данные
Появление моделей эмбеддингов полностью преобразило то, как мы извлекаем информацию. Большинство моделей эмбеддингов используют знаменитую архитектуру Transformer в качестве своей основы. Модель Transformer использует несколько блоков энкодер-декодер, каждый из которых содержит специализированный слой внимания. Этот слой позволяет модели улавливать семантическое значение каждого входного токена относительно всей входной последовательности, благодаря чему модели эмбеддингов способны выводить семантическое значение входных слов.
Архитектура Transformer
Архитектура Transformer
Модели эмбеддингов преобразуют запросы, изображения или текстовые описания в их числовые представления, называемые векторными эмбеддингами. Векторный эмбеддинг несет семантически богатое значение входных данных, которые он представляет, и мы можем сравнить сходство между двумя векторными эмбеддингами с помощью косинусного сходства или косинусного расстояния. Если сходство высокое, то два векторных эмбеддинга имеют схожее значение, и наоборот.
Исходные тексты в векторные эмбеддинги.png
Исходные тексты в векторные эмбеддинги
Благодаря этим мощным свойствам модели эмбеддингов делают реализацию концепции информационного поиска гораздо проще и гибче.
Генерация с дополненным поиском (RAG)
Быстрое развитие моделей эмбеддингов и появление больших языковых моделей (LLMs) привели к возникновению RAG, очень сложного метода информационного поиска. RAG предназначен для повышения качества ответов LLM путем предоставления LLM релевантного контекста из внутренней базы знаний вместе с запросом. Затем LLM использует предоставленный контекст, чтобы ответить на запрос.
Архитектура RAG
Архитектура RAG
В приложении RAG мы используем выбранные модели эмбеддингов, чтобы преобразовать наши данные и входной запрос в эмбеддинги. Затем мы вычисляем сходство между эмбеддингом нашего запроса и эмбеддингами наших собственных данных. Данные, наиболее похожие на наш запрос, затем будут переданы в LLM в качестве контекста вместе с нашим запросом. В конечном итоге наша LLM может сгенерировать ответ на запрос на основе предоставленного контекста. Таким образом, мы можем повысить точность ответов LLM без необходимости ее дообучения.
Интеграция векторной базы данных Milvus и Snowflake с Snowpark Container Service
Milvus — это векторная база данных с открытым исходным кодом, которая позволяет хранить огромное количество векторных эмбеддингов, полезных для приложений RAG, и выполнять по ним векторный поиск за доли секунды. Существует несколько вариантов установки и использования Milvus:
- Milvus Lite: Облегченная версия Milvus, подходящая для быстрого прототипирования. Milvus Lite не требует сервера; вы можете запускать ее на собственном устройстве. Процесс установки так же прост, как использование команды pip install.
!pip install "pymilvus>=2.4.2"
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")
- Milvus в Docker: Если вы хотите использовать свою векторную базу данных Milvus в продакшене и у вас есть лишь небольшой объем данных, вы можете запустить ее как контейнер Docker. Процесс также прост, поскольку вам нужно выполнить только эти команды в командной строке:
# Download the installation script
$ curl -sfL <https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh> -o standalone_embed.sh
# Start the Docker container
$ bash standalone_embed.sh start
# In your Python IDE
from pymilvus import MilvusClient
client = MilvusClient(
uri="<http://milvus:19530>",
)
- Milvus в Kubernetes: Этот вариант подходит, если у вас огромные объемы данных или у ваших приложений RAG огромное количество пользователей. С Kubernetes вы можете хранить до 100 миллиардов векторов. Процесс установки с Kubernetes немного сложнее, чем у Milvus Lite и Docker. Поэтому обратитесь к документации по установке для получения подробной информации.
Milvus предлагает бесшовную интеграцию с популярными наборами инструментов для ИИ, такими как OpenAI, HuggingFace, Cohere, LangChain, LlamaIndex и Snowflake. Эти интеграции упрощают создание собственных RAG-систем или других приложений GenAI. В этом разделе будет показано, как запускать Milvus внутри экосистемы Snowflake.
Milvus предлагает бесшовную интеграцию со всеми популярными наборами инструментов для ИИ
Milvus предлагает бесшовную интеграцию со всеми популярными наборами инструментов для ИИ
Snowflake — это платформа для хранилищ данных, которая позволяет эффективно и надежно хранить, обрабатывать и анализировать данные. С появлением Snowpark Container Service (SPCS) теперь можно запускать контейнеризированные приложения внутри среды Snowflake. Таким образом, ваше приложение может взаимодействовать с данными, хранящимися внутри Snowflake, что позволяет создавать широкий спектр приложений, включая RAG-систему.
В этом разделе мы сначала создадим приложение с Milvus, которое выполняет векторный поиск. Затем мы контейнеризируем приложение с помощью Docker и запустим контейнер внутри Snowflake с SPCS.
Чтобы начать, давайте создадим приложение Milvus для выполнения векторного поиска с помощью Jupyter Notebook. Если вы хотите следовать вместе с нами, обратитесь к этому репозиторию, где доступен полный notebook и скрипт для создания модели эмбеддингов.
from pymilvus import MilvusClient
from pymilvus import DataType
import os
import mode
# init client
client = MilvusClient(
uri="<http://milvus:19530>",
)
# init model
model = model.Onnx()
# Create a collection in quick setup mode
client.create_collection(
collection_name="quick_demo",
dimension=model.dimension,
)
print("Collection Created!")
В приведенном выше коде мы создали коллекцию под названием “quick_demo” внутри векторной базы данных Milvus и загрузили модель для преобразования текстов в эмбеддинги. Мы будем использовать ALBERT в качестве нашей модели эмбеддингов, которая отображает входной текст в 768-мерный векторный эмбеддинг.
Далее вставьте некоторые текстовые данные в нашу коллекцию “quick_demo”.
# Data from which embeddings are to be generated
docs=[
"Artificial intelligence was founded as an academic discipline in 1956.",
"Alan Turing was the first person to conduct substantial research in AI.",
"Born in Maida Vale, London, Turing was raised in southern England.",
]
# Insert data into the collection
data=[]
for i in range(len(docs)):
data.append({
'id': i,
'vector': model.to_embeddings(docs[i]),
'doc_str': docs[i]
})
res = client.insert(
collection_name="quick_demo",
data=data
)
В приведенном выше коде мы преобразуем входные тексты в эмбеддинги с помощью ALBERT и сохраняем их внутри коллекции вместе с их ID и исходными текстами.
Теперь, если у нас есть запрос, такой как “Who started AI research?”, и мы хотим получить релевантный контекст, который может содержать соответствующий ответ на наш запрос, мы можем легко выполнить векторный поиск с Milvus следующим образом:
# Search with a text query
query = "Who started AI research?"
query_embeddings = model.to_embeddings(query)
res = client.search(
collection_name="quick_demo",
data=[query_embeddings],
limit=1,
output_fields=["doc_str"],
)
print(res)
"""
Expected output:
"Alan Turing was the first person to conduct substantial research in AI."
"""
И на этом всё для нашего приложения Milvus.
На этом этапе у нас есть Jupyter Notebook для выполнения векторного поиска с Milvus. Допустим, мы хотим контейнеризировать этот notebook, чтобы запускать его в экосистеме Snowflake. Первое, что нам нужно сделать, — настроить роль и привилегии для создания и запуска сервиса, предоставляемого Snowflake.
Сначала загрузите SnowSQL, следуя инструкциям на странице документации Installing SnowSQL. Затем выполните следующую команду в терминале:
snowsql -a ${instance_name} -u ${user_name}
где формат ${instance_name} — ${org_name}-${acct_name}, а информацию об этих двух полях можно найти в вашем аккаунте Snowflake. Теперь мы можем настроить роль и привилегии с помощью следующих команд внутри оболочки SnowSQL:
USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION SNOWSERVICES_INGRESS_OAUTH
TYPE=oauth
OAUTH_CLIENT=snowservices_ingress
ENABLED=true;
USE ROLE ACCOUNTADMIN;
GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO ROLE SYSADMIN;
USE ROLE SECURITYADMIN;
CREATE ROLE MILVUS_ROLE;
USE ROLE USERADMIN;
CREATE USER milvus_user
PASSWORD='milvususerok'
DEFAULT_ROLE = MILVUS_ROLE
DEFAULT_SECONDARY_ROLES = ('ALL')
MUST_CHANGE_PASSWORD = FALSE;
USE ROLE SECURITYADMIN;
GRANT ROLE MILVUS_ROLE TO USER milvus_user;
Поскольку Snowflake — это платформа для хранения данных, мы взаимодействуем со всеми объектами внутри Snowflake с помощью команд, похожих на SQL-запросы, как вы можете видеть выше. Далее мы можем создать хранилище данных и базу данных внутри Snowflake с помощью следующих команд:
USE ROLE SYSADMIN;
CREATE OR REPLACE WAREHOUSE MILVUS_WAREHOUSE WITH
WAREHOUSE_SIZE='X-SMALL'
AUTO_SUSPEND = 180
AUTO_RESUME = true
INITIALLY_SUSPENDED=false;
USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS MILVUS_DEMO;
USE DATABASE MILVUS_DEMO;
CREATE IMAGE REPOSITORY MILVUS_DEMO.PUBLIC.MILVUS_REPO;
CREATE OR REPLACE STAGE YAML_STAGE;
CREATE OR REPLACE STAGE DATA ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
CREATE OR REPLACE STAGE FILES ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
--GRANT ROLE PRIVILEGES--
USE ROLE SECURITYADMIN;
GRANT ALL PRIVILEGES ON DATABASE MILVUS_DEMO TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON SCHEMA MILVUS_DEMO.PUBLIC TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON WAREHOUSE MILVUS_WAREHOUSE TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON STAGE MILVUS_DEMO.PUBLIC.FILES TO MILVUS_ROLE;
--CONFIGURE ACL--
USE ROLE ACCOUNTADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE NETWORK RULE allow_all_rule
TYPE = 'HOST_PORT'
MODE= 'EGRESS'
VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');
CREATE EXTERNAL ACCESS INTEGRATION allow_all_eai
ALLOWED_NETWORK_RULES=(allow_all_rule)
ENABLED=TRUE;
GRANT USAGE ON INTEGRATION allow_all_eai TO ROLE SYSADMIN;
Чтобы запустить контейнеризованное приложение внутри Snowflake, нам нужно собрать Docker-образ нашего приложения на локальном компьютере. В этом проекте нам нужно собрать два разных Docker-образа: один для создания экземпляра векторной базы данных Milvus, а другой — для запуска файла notebook, который мы создали выше.
Однако для сборки Docker-образа нам нужен Dockerfile. Чтобы упростить задачу, клонируйте следующий репозиторий. В этом репозитории вы найдете все необходимые файлы для сборки двух нужных нам образов. После клонирования репозитория вы можете собрать два Docker-образа с помощью следующих команд в локальном терминале:
cd ${repo_git_root_path}
docker build --rm --no-cache --platform linux/amd64 -t milvus ./images/milvus
docker build --rm --no-cache --platform linux/amd64 -t jupyter ./images/jupyter
Затем мы можем добавить соответствующие теги к двум недавно собранным образам с помощью следующих команд:
docker login ${instance_name}.registry.snowflakecomputing.com -u ${user_name}
docker tag milvus ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker tag jupyter ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
Наконец, мы можем отправить образы в SPCS с помощью следующих команд:
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
Теперь, когда мы отправили образы в SPCS, единственное, что нам нужно сделать, — это создать два вычислительных сервиса, по одному для каждого образа, как вы можете видеть в следующих командах внутри оболочки SnowSQL:
USE ROLE SYSADMIN;
CREATE COMPUTE POOL IF NOT EXISTS MILVUS_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
CREATE COMPUTE POOL IF NOT EXISTS JUPYTER_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
Внутри репозитория, который мы клонировали ранее, есть папка под названием “specs.” Внутри этой папки находятся два YAML-файла, по одному для каждого образа. Откройте каждый YAML-файл и измените ${org_name}-${acct_name} в поле image в соответствии с вашей учетной записью Snowflake.
Далее, используя SnowSQL, загрузите измененные YAML-файлы с помощью следующих команд:
PUT file://${path/to/jupyter.yaml} @yaml_stage overwrite=true auto_compress=false;
PUT file://${path/to/milvus.yaml} @yaml_stage overwrite=true auto_compress=false;
И наконец, мы можем создать сервисы для обоих образов следующим образом:
USE ROLE SYSADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE SERVICE MILVUS
IN COMPUTE POOL MILVUS_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='milvus.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
CREATE SERVICE JUPYTER
IN COMPUTE POOL JUPYTER_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='jupyter.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
Теперь, если вы введете команду SHOW SERVICE, вы должны увидеть следующий вывод:
SHOW SERVICES;
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| name | database_name | schema_name | owner | compute_pool | dns_name | ......
|---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| JUPYTER | MILVUS_DEMO | PUBLIC | SYSADMIN | JUPYTER_COMPUTE_POOL | jupyter.public.milvus-demo.snowflakecomputing.internal | ......
| MILVUS | MILVUS_DEMO | PUBLIC | SYSADMIN | MILVUS_COMPUTE_POOL | milvus.public.milvus-demo.snowflakecomputing.internal | ......
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
Теперь мы готовы запустить векторную базу данных Milvus и протестировать наш notebook внутри Snowflake. Сначала предоставьте разрешение роли, которую мы создали ранее, на доступ к контейнеризованному приложению.
USE ROLE SECURITYADMIN;
GRANT USAGE ON SERVICE MILVUS_DEMO.PUBLIC.JUPYTER TO ROLE MILVUS_ROLE;
Далее проверьте endpoint нашего контейнера notebook внутри Snowflake с помощью следующей команды:
USE ROLE SYSADMIN;
SHOW ENDPOINTS IN SERVICE MILVUS_DEMO.PUBLIC.JUPYTER;
Jupyter endpoint, as shown in ingress_url
Endpoint Jupyter, как показано в ingress_url
Если все работает гладко, вы увидите столбец под названием “ingress_url” в выводе. Откройте браузер, скопируйте и вставьте этот “ingress_url”, и вы должны увидеть запущенный Jupyter. Затем вы можете открыть файл notebook внутри контейнера и запускать каждую ячейку в notebook обычным образом.
Будущий ландшафт RAG
RAG — чрезвычайно популярная техника в наши дни. Однако ее текущее применение далеко от совершенства. По словам Jiang Chen, вот несколько прогнозов относительно будущего использования и улучшения приложений RAG.
Непрерывная оценка и наблюдаемость
Создание RAG стало проще благодаря доступности различных платформ или библиотек, которые упрощают и абстрагируют процесс разработки RAG. Например, мы можем создать прототип RAG за считанные минуты с помощью трех разных платформ: Milvus, LangChain и OpenAI.
Однако мы часто сталкиваемся с трудностями при переводе приложения на базе RAG из прототипа в продакшен. В продакшене нашим RAG-системам необходимо обрабатывать миллионы или даже миллиарды документов, поэтому крайне важно постоянно отслеживать качество ответов, генерируемых нашей LLM
Непрерывная оценка RAG-системы
Непрерывная оценка RAG-системы
Прежде чем внедрять улучшения для повышения качества нашего RAG, важно выстроить системный подход к его непрерывной оценке и совершенствованию.
Некоторые ключевые элементы этого системного подхода включают:
Создание специализированной инфраструктуры для улучшений: В этой инфраструктуре мы можем реализовывать различные методы повышения качества RAG, а затем сравнивать их ответы с помощью A/B-тестирования.
Планирование цикла релизов: Как только мы находим подход, который улучшает качество RAG в соответствии с нашим сценарием использования, нам нужно спланировать, как выпустить и интегрировать его в нашу систему, чтобы заменить старый подход без нарушения пользовательского опыта.
Внедрение системы наблюдаемости: Нам также необходимо построить систему для наблюдения за производительностью нашего RAG в продакшене и определения его эффективности. Если производительность неудовлетворительна, мы можем исследовать и внедрять улучшения через специализированную инфраструктуру для улучшений.
Мультимодальный RAG
До сих пор мы в основном использовали RAG в обработке естественного языка. Это означает, что мы используем текст в качестве промпта или запроса, а ответы нашей LLM также имеют текстовую форму.
Однако ландшафт RAG может измениться в будущем с появлением мультимодального RAG. Мультимодальный RAG стал возможен благодаря росту числа мультимодальных моделей эмбеддингов в последние годы. За последние несколько лет исследования показали, что Transformers могут обрабатывать на входе естественный язык и другие модальности, такие как изображения и звуки.
Модели Vision Transformers (ViT) и DETR продемонстрировали, что Transformers можно использовать как мощные модели для классификации изображений и обнаружения объектов. Основываясь на ViT, OpenAI представила мультимодальную модель под названием CLIP, которая может вычислять сходство между двумя входными данными из разных модальностей: текстом и изображением.
Мультимодальные возможности, продемонстрированные этими моделями на базе Transformer, могут стать основой для будущих мультимодальных приложений RAG. В такой системе мы можем использовать сочетание текста и изображения в качестве запроса, а LLM будет генерировать изображение на основе наших мультимодальных запросов.
Например, предположим, что мы хотим, чтобы наша LLM сгенерировала изображение, очень похожее на предоставленное изображение-запрос. Мы можем обогатить наше изображение-запрос текстовым описанием, чтобы дополнительно уточнить тип изображений, которые мы хотим, чтобы наша LLM генерировала, как вы можете видеть на визуализации ниже:
Мультимодальное приложение RAG, сочетание текстовых и графических запросов
Мультимодальное приложение RAG, сочетание текстовых и графических запросов
На приведенной выше визуализации мы попросили наши модели эмбеддингов вернуть изображения, похожие на изображение в верхнем левом углу, и добавили текстовый промпт, например "изображение горы во время золотого часа," рядом с изображением в верхнем левом углу. Результаты — это три другие изображения, сгенерированные на основе мультимодального запроса.
Такой мультимодальный подход к RAG открывает новые возможности для более интуитивного и выразительного поиска и генерации информации, сочетая сильные стороны как текстовых, так и визуальных модальностей.
Хороший RAG начинается с хороших данных
Качество нашей RAG-системы в значительной степени зависит от качества данных, которые есть в нашей базе данных. Поэтому, когда ответ, сгенерированный нашей RAG-системой, не является оптимальным, не следует спешить с выводом, что модель нужно улучшать. Сначала нам всегда нужно проверять качество наших данных.
Как вы, возможно, уже знаете, качество ответов RAG зависит от контекстов, передаваемых вместе с запросом. Если наша LLM не может найти подходящие ответы на запрос в предоставленных контекстах, то неудивительно, что качество ответа, сгенерированного нашей RAG-системой, будет низким.
Поэтому, прежде чем решать улучшать модели эмбеддингов и LLM в нашей RAG-системе, мы всегда должны задавать следующие вопросы:
Есть ли у нас правильные данные в нашей базе данных?
Собрали ли мы все доступные данные из источников данных в нашу базу данных?
Реализовали ли мы правильный процесс очистки данных перед передачей данных в модели эмбеддингов?
Реализовали ли мы подходящий подход chunking к нашим данным?
Реализовали ли мы корректные методы предварительной обработки данных (например, парсинг PDF, OCR-парсинг) для наших данных?
Решение проблем, связанных с данными, является важнейшим первым шагом в оптимизации производительности приложения на базе RAG. Только после проверки качества данных следует рассматривать возможность доработки моделей эмбеддингов, LLM или других компонентов RAG-системы.
Агенты: маршрутизация запросов с подзапросами
В настоящее время распространенная RAG-система извлекает релевантные контексты для заданного запроса из текстов и эмбеддингов, сохраненных во внутренней базе данных. Однако этот подход может развиваться, поскольку контекст может извлекаться из внутренних баз данных и внешних источников, таких как веб-поиск.
Визуализация агентов для маршрутизации запросов
Визуализация агентов для маршрутизации запросов
Исследования в этой области все еще продолжаются, но добавление так называемого «агента» в RAG-систему может помочь определить подходящий источник контекста для заданного запроса.
Например, при запросе вроде "Who started AI research?" агент может решить, нужен ли RAG для ответа на этот вопрос. Если нет, система может позволить LLM напрямую сгенерировать ответ на запрос без какого-либо дополнительного контекста.
Если RAG признан необходимым, agent должен определить источник контекста — внутреннюю базу данных или внешний источник. Другой подход заключается в том, чтобы агент агрегировал информацию из различных источников в единый, обобщенный контекст, который LLM может использовать для генерации подходящего ответа.
Заключение
Высокая эффективность LLM в генерации текстовых ответов, похожих на человеческие, изменила весь ландшафт информационного поиска. Введение RAG призвано повысить точность ответов LLM, предоставляя им релевантные контексты для заданного запроса. Эти контексты обычно хранятся как эмбеддинги, которые должны храниться в векторной базе данных, такой как Milvus.
Будучи векторной базой данных с открытым исходным кодом и расширенными возможностями векторного поиска, Milvus предлагает бесшовную интеграцию с популярными AI-инструментариями, такими как Snowflake. Благодаря Snowpark Container Service (SPCS) от Snowflake пользователи теперь могут запускать Milvus внутри экосистемы Snowflake, что позволяет им легко взаимодействовать с Milvus, используя данные, хранящиеся в Snowflake.
Читать далее
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
Zilliz Cloud Audit Logs Goes GA: Security, Compliance, and Transparency at Scale
Zilliz Cloud Audit Logs are now GA, giving enterprises real-time visibility, compliance-ready trails, and stronger security across AWS, GCP, and Azure.