Анонс Milvus 3.0: Lake-Native векторный поиск и более мощный механизм извлечения

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

• Milvus 3.0 вводит lake-native путь для индексирования векторных данных, которые находятся в объектном хранилище и открытых табличных форматах, включая Parquet, Lance, Iceberg и Vortex. Команды могут сделать данные, находящиеся в lake, доступными для поиска без поддержки еще одной копии в векторной базе данных.
• Этот релиз также расширяет Milvus за пределы первичного извлечения кандидатов. Серверная сортировка, агрегация, фасетный поиск, StructArray для вложенной структуры документ/фрагмент и векторов ColBERT, а также переработанный разреженный индекс переносят больше ранжирования, группировки и обработки результатов из кода приложения в движок извлечения.

В совокупности эти улучшения делают Milvus open-source основой для производственного AI-извлечения и архитектур Vector Lakebase, которые объединяют lake-native хранилище с высокопроизводительным векторным извлечением.

Краткий обзор набора возможностей Milvus 3.0

Область	Возможности	Почему это важно
Lake-native извлечение	External Collections поверх Parquet, Lance, Iceberg и Vortex	Поиск по данным, находящимся в lake, без поддержки второй обслуживающей копии
Хранилище на базе S3	Loon (Storage v3)	Снижает усиление точечных чтений для обслуживающего доступа и поддерживает эволюцию схемы
Офлайн/пакетные рабочие процессы и восстановление	Snapshots, Spark DataSource V2 и онлайн-эволюция схемы	Привносит стабильные представления коллекций в пайплайны оценки, дедупликации, кластеризации и признаков
Движок извлечения	ORDER BY, агрегация, фасеты, StructArray и улучшенное разреженное извлечение	Переносит больше обработки результатов и multi-vector скоринга в Milvus
Модель данных & операции	Nullable vectors, TEXT LOB, TTL, MinHash, Woodpecker и ForceMerge	Поддерживает более богатые модели данных и производственные операционные паттерны

Lake-native инфраструктура: индексируйте и обслуживайте данные там, где они уже находятся

Самое крупное архитектурное изменение в Milvus 3.0 касается того, где система может строить и обслуживать индексы. Векторные данные могут оставаться в открытых форматах в объектном хранилище, а Milvus при этом предоставляет индексирование, извлечение и API производственного уровня.

1. External Collections: индексирование напрямую по данным, находящимся в lake

Многие команды уже хранят эмбеддинги в data lake — таблицах Lance, таблицах Iceberg, файлах Parquet или других наборах данных открытого формата в S3, GCS или Azure Blob Storage. До Milvus 3.0 для поиска по этим данным обычно было два варианта.

• Скопировать эмбеддинги в векторную базу данных. Это обеспечивает поиск с низкой задержкой, но создает вторую копию и ETL-пайплайн, который должен оставаться синхронизированным.
• Запрашивать lake напрямую. Это позволяет избежать дублирования, но без ANN-индексов векторный поиск превращается в полный перебор, который не может обеспечить производственные задержки.

External Collections вводят третий путь. Вы определяете коллекцию Milvus поверх данных, которые остаются в объектном хранилище, сопоставляете внешние поля со схемой Milvus и используете те же API поиска и запросов, что и для нативной коллекции. Исходные файлы не перемещаются; Milvus строит и обслуживает векторные, BM25-инвертированные, JSON- и скалярные индексы поверх внешних данных.

External Collections доступны только для чтения и работают без копирования, что делает их полезными, когда требования управления, границы владения или операционные затраты требуют, чтобы исходный набор данных оставался в lake.

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

import json
import os
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(uri=“”)
# Register an Iceberg table as a zero-copy collection.
schema = client.create_schema(
external_source=“s3://lake/docs/metadata/v1.metadata.json”,
external_spec=json.dumps(
{
“format”: “iceberg-table”,
“snapshot_id”: 123456789,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“access_key_id”: os.environ[“AWS_ACCESS_KEY_ID”],
“access_key_value”: os.environ[“AWS_SECRET_ACCESS_KEY”],
},
}
),
)
schema.add_field(field_name=“id”, datatype=DataType.INT64, external_field=“doc_id”)
schema.add_field(field_name=“emb”, datatype=DataType.FLOAT_VECTOR, dim=1024, external_field=“embedding”)
schema.add_field(field_name=“title”, datatype=DataType.VARCHAR, max_length=1024, external_field=“title”)
client.create_collection(collection_name=“docs”, schema=schema)
# Import the external table snapshot.
job_id = client.refresh_external_collection(collection_name=“docs”)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(1)
index_params = client.prepare_index_params()
index_params.add_index(field_name=“emb”, index_type=“HNSW”, metric_type=“COSINE”)
client.create_index(collection_name=“docs”, index_params=index_params)
client.load_collection(collection_name=“docs”)

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

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

Подробнее см. Create an External Collection.

2. Loon (Storage v3): эффективные точечные чтения для lake-native извлечения

External Collections поднимают очевидный вопрос: объектное хранилище рассчитано на масштаб и надежность, но может ли оно поддерживать узкие точечные чтения, следующие за ANN-поиском?

Проблема заключается в усилении чтения. Векторный поиск обычно выполняется в два этапа: ANN-индекс возвращает ID кандидатов, а система извлекает выбранные поля для этих кандидатов. Форматы, оптимизированные для аналитических сканирований, могут превращать узкий логический lookup в гораздо более крупное физическое чтение.

Milvus 3.0 решает эту проблему с помощью Loon, также известного как Storage v3, — колоночного движка хранения на основе манифестов для S3-совместимого объектного хранилища. Loon организует поля в ColumnGroups с выровненными ID строк, позволяя скалярным полям отдавать приоритет фильтрации и сканированиям, а векторам и полям с интенсивными точечными чтениями использовать макеты, рассчитанные на более узкие lookup-запросы.

Loon хранит векторные и инвертированные индексы отдельно от формата файлов, а не встраивает их в него. Каждая версия набора данных описывается неизменяемым манифестом, который фиксирует ее ColumnGroups, позволяя одному и тому же движку индексирования работать с Lance, Parquet, Iceberg и Vortex.

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

Vortex — формат по умолчанию для этого пути. Это открытый, совместимый с Arrow колоночный формат с гибкими макетами и вложенными кодировками, которые лучше соответствуют AI-данным с высокой нагрузкой точечных запросов. В одном внутреннем бенчмарке с 3 миллионами строк, 128-мерными векторами, S3 и 256 параллельными читателями измеренный I/O на одно точечное чтение снизился примерно с 9,4 МБ для базового Parquet до 0,07 МБ для Vortex с Loon, то есть примерно в 135 раз.

Milvus 3.0 не заставляет объектное хранилище вести себя как локальная память. Он снижает усиление чтения, которое иначе делает объектное хранилище непрактичным для обслуживающих точечных lookup-запросов. Predicate pushdown в формат и локальный вариант Vortex — следующие пункты дорожной карты.

Подробнее см. наш блог: Why We Built Loon и проект Vortex.

3. Snapshots: представление на момент времени без копирования данных

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

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

То же замороженное представление может поддерживать оценку, дедупликацию, проверку backfill и изолированное тестирование, пока живая коллекция продолжает принимать записи. Snapshot стабилизирует логический вход, хотя рабочие нагрузки могут по-прежнему совместно использовать инфраструктуру, такую как объектное хранилище и пропускная способность сети.

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

Дополнительную информацию см. в Snapshots, Manage Snapshots и Snapshot Use Cases.

4. Spark connector: подключение Milvus к пакетным рабочим процессам

Стабильный snapshot полезен только в том случае, если пакетные движки могут его прочитать. Milvus 3.0 предоставляет Milvus как Spark DataSource V2, позволяя заданиям Spark, Databricks и EMR читать из Milvus и записывать в Milvus как часть стандартных пакетных пайплайнов.

Эта возможность важна, потому что рабочие процессы AI-данных итеративны: дедупликация питает повторное создание эмбеддингов, кластеризация питает оценку, а оценка создает курируемые наборы для обучения или обслуживания. Стабильный snapshot предоставляет этим заданиям согласованный вход, пока live-коллекция продолжает обслуживать запросы. С коннектором Spark результат одного задания становится источником следующего, без экспорта полной коллекции из Milvus каждый раз.

Milvus 3.0 также вводит vector-native пакетные операторы для задач вроде дедупликации, обнаружения аномалий и кластеризации, удерживая вычислительно тяжелую работу вне онлайн-пути запросов и работая напрямую с векторными данными.

5. Онлайн-изменения схемы и backfill

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

Добавление или удаление колонки не требует переписывания существующих данных. client.add_collection_field(...) добавляет новую nullable-колонку без вывода коллекции из эксплуатации, а client.drop_collection_field(...) удаляет устаревшее или экспериментальное поле во время выполнения. Ни одна из операций не переписывает существующие данные — каждая является изменением манифеста коллекции, а не файлов данных, поэтому перестроения не требуется.

Milvus 3.0 поддерживает два пути backfill:

• Inner backfill (в 3.0) предназначен для значений, производных от существующих полей. Milvus может сгенерировать разреженный BM25-вектор из текстовой колонки внутри ядра, устраняя необходимость в клиентском энкодере при построении гибридного dense-plus-sparse извлечения.
• External backfill(в дорожной карте) будет предназначен для значений, вычисляемых вне Milvus: создать snapshot, запустить Spark по согласованному представлению, вычислить новую колонку, записать значения обратно и позволить Milvus инкрементально обновить индекс. Это предполагаемый путь для крупных задач повторного создания эмбеддингов — например, добавления новой колонки эмбеддингов для сотен миллионов строк, пока записи продолжаются.

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

Более мощный движок для сквозного извлечения

Milvus уже давно поддерживает не только плотный ANN-поиск, включая разреженное извлечение на базе BM25 и гибридный поиск. Milvus 3.0 расширяет движок по другой оси: он переносит больше этапов многоступенчатого пайплайна извлечения в сам Milvus, уменьшая избыточное извлечение, дублирование логики приложения и зависимость от отдельных сервисов постобработки.

1. Серверный ORDER BY: сортировка внутри движка, по сегментам

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

Milvus 3.0 добавляет серверный ORDER BY, который позволяет query-нагрузкам сортировать отфильтрованные строки по скалярным полям, таким как рейтинг, цена, свежесть, наличие или временная метка.

• На пути query каждый сегмент сортирует свой отфильтрованный набор результатов, query nodes объединяют эти потоки, а proxy возвращает запрошенный срез.
• На пути search ORDER BY сортирует набор ANN-кандидатов внутри Milvus, уменьшая избыточное извлечение на стороне клиента и дублирующую постобработку. Он не меняет границу recall, установленную ANN-кандидатами.

client.query(
    collection_name="products",
    filter="category == 'shoes'",
    output_fields=["price", "rating"],
    limit=10,
    order_by=["rating:desc", "price:asc"],
)

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

Дополнительную информацию см. в Sort Search Results by Scalar Fields и Sort Query Results.

2. Агрегация и фасетный поиск

Milvus 3.0 добавляет агрегацию на стороне query с операциями вроде count, sum, average, minimum и maximum, сгруппированными по одному или нескольким скалярным полям. Это устраняет распространенный паттерн, когда команды вытягивают отфильтрованные строки в клиентский код только для подсчета, группировки или вычисления простой статистики.

client.query(
    collection_name="orders",
    filter="in_stock == true",
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)", "max(rating)"],
)

Milvus 3.0 также добавляет search aggregation для фасетного поиска. После ANN-поиска Milvus группирует найденные hits по полю и возвращает количества в бакетах, агрегированную статистику и top-N примеров hits на бакет — паттерн, лежащий в основе группировки по бренду, ценовому диапазону, цвету, tenant или типу документа. Один нюанс: search aggregation работает по набору результатов, извлеченных ANN, а не по всей коллекции, поэтому значения фасетов приблизительны. Когда нужны точные подсчеты, используйте агрегацию на стороне query.

Дополнительную информацию см. в Aggregate Query Results.

3. StructArray для вложенных векторов и модели late-interaction

Многие сущности естественно представляются несколькими векторами. Длинный документ — это серия фрагментов; видео — последовательность кадров, которые лучше хранить вместе в одной строке, а не разбрасывать по множеству; у продукта есть несколько изображений или ракурсов. Модели late-interaction развивают это еще дальше — ColBERT выдает один вектор на токен, ColPali — один на визуальный patch. В каждом случае единица, которую вы действительно хотите хранить и искать, — это вся сущность, а не каждый фрагмент сам по себе.

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

Milvus поддерживает две гранулярности поиска.

• Поиск на уровне элемента сопоставляет один вектор запроса с каждым элементом в списке и возвращает конкретный совпавший элемент с его offset. Это полезно, когда нужно знать, какой фрагмент, токен, patch или изображение совпали. Строка может появиться более одного раза, если совпадает несколько элементов.
• Поиск на уровне сущности сравнивает полный список векторов запроса со списком векторов строки, используя MAX_SIM с метрикой MAX_SIM_COSINE. Каждый токен запроса берет свое лучшее совпадение в документе, и эти лучшие оценки суммируются. Это дает Milvus нативную поддержку паттернов late-interaction извлечения, таких как ColBERT и ColPali, при сохранении одной строки на документ.

Индексирование каждого токен-вектора может быть дорогим; поэтому Milvus 3.0 добавляет несколько путей ускорения, включая TokenANN, Muvera и Lemur, которые обменивают размер индекса, стоимость обучения и recall.

Стратегия	Представление первого этапа	Профиль затрат	Лучше всего для
TokenANN	Индексируется каждый токен-вектор.	Самый высокий, точный	Моделей с высокой дискриминативностью и коротких документов
Muvera	Один вектор на документ с использованием random-projection FDE.	Средний, без обучения	Длинных документов
Lemur	Один вектор на документ с использованием обучаемого MLP-сжатия	Самый низкий, требует обучения	Моделей с низкой дискриминативностью и визуальных или patch-векторов

В наших бенчмарках Lemur соответствует или превосходит TokenANN по recall на большинстве наборов данных, сводя каждый документ к одному вектору; исключение — корпуса с высокой вариативностью длины, где TokenANN или другая стратегия безопаснее.

Для корпусов больше памяти Milvus также поддерживает индекс DISKANN, который хранит списки эмбеддингов на диске, чтобы снизить нагрузку на RAM.

Поиск на уровне элементов уже появился в Milvus 2.6. Фильтрация для Muvera, Lemur и StructList новая в 3.0.

4. Сжатие индекса BM25 и SINDI

Milvus поддерживал поиск по разреженным векторам в более ранних релизах. Milvus 3.0 снижает размер разреженного индекса с помощью блочно-сжатых postings (алгоритмы, связанные с VByte, плюс SIMD-декодирование) и квантизации (fp16 для внутренних произведений, u16 для BM25).

В одном наборе внутренних BM25-бенчмарков новая реализация была примерно в 3 раза меньше, чем разреженный индекс Milvus 2.6 при сопоставимом recall. Меньший индекс снижает нагрузку на память и пропускную способность и может повышать скорость в рабочих нагрузках, ограниченных перемещением данных.

Milvus 3.0 также вводит SINDI — новый алгоритм разреженного извлечения, оптимизированный для обученных разреженных эмбеддингов, таких как SPLADE. Поскольку эти эмбеддинги создают более плотные posting lists, чем BM25, алгоритмы поиска с интенсивным pruning могут тратить значительное CPU-время на решение, что пропустить. Вместо этого SINDI организует postings в компактные окна и использует дружественное к SIMD накопление score, чтобы эффективно их обрабатывать, сохраняя точность извлечения за счет lossless pruning.

Мы также расширили SINDI за пределы исходного дизайна, добавив нативную поддержку BM25, что позволяет Milvus использовать один и тот же оптимизированный путь разреженного извлечения как для обученных разреженных эмбеддингов, так и для традиционного полнотекстового поиска.

В наших бенчмарках на 4 наборах разреженных векторов SPLADE SINDI достигает примерно до 10x QPS по сравнению с MaxScore на learned-sparse векторах, а в худшем случае — около 5x.

SINDI используется по умолчанию для поиска по разреженным векторам с внутренним произведением в Milvus 3.0.

Другие улучшения

• TEXT LOB: Хранит длинный исходный текст рядом с векторами. Текст меньше 64 КБ остается inline; более крупные значения используют ссылку Vortex LOB.
• Расширенная поддержка плотных индексов: Добавляет больше вариантов индексов в семействе Faiss, включая SVS, Panorama, PQ, IVFPQ и ScaNN, для разных требований к масштабу, памяти и recall.
• MinHash и поиск почти дубликатов: Генерирует сигнатуры MinHash на стороне сервера и извлекает кандидатов почти дубликатов с помощью MINHASH_LSH.
• Nullable vectors и новые типы: Позволяет векторным полям быть NULL и добавляет TIMESTAMPTZ для time-aware фильтрации и политик хранения.
• Пользовательские полнотекстовые словари: Регистрирует словари, синонимы и ресурсы стоп-слов в кластере для многоязычной и доменно-специфичной токенизации.
• Standalone Woodpecker: Запускает журнал предварительной записи Milvus как независимо масштабируемый и наблюдаемый сервис.
• Entity TTL****: Истекает срок действия отдельных записей через поле TIMESTAMPTZ, с MVCC-фильтрацией и последующей сборкой мусора во время compaction.
• ForceMerge: Уплотняет небольшие сегменты до целевого размера и перестраивает индексы, чтобы снизить усиление чтения перед длительным обслуживанием с интенсивным чтением.
• И многое другое

Начните работу с Milvus 3.0

Milvus 3.0 доступен уже сегодня под лицензией Apache 2.0 и остается проектом LF AI & Data. Чтобы начать:

• Прочитайте release notes и quickstart, а исходный код получите на github.com/milvus-io/milvus.
• Присоединяйтесь к сообществу Milvus Discord или запишитесь на сессию Milvus Office Hours, чтобы обсудить ваш сценарий использования с мейнтейнерами.

Milvus 3.0 и Zilliz Vector Lakebase

Milvus 3.0 закладывает open-source основу для производственного AI-извлечения и формирующейся архитектуры Vector Lakebase, которая объединяет lake-native хранилище с высокопроизводительным векторным извлечением на едином источнике истины, каждое — с правильной стоимостью.

Zilliz Cloud — полностью управляемая Vector Lakebase, созданная командой, стоящей за Milvus. Она использует ту же распределенную lake-native архитектуру, что и Milvus, и полностью совместима с Milvus API. Благодаря собственному движку индексирования Cardinal Zilliz Cloud обеспечивает до 10× лучшую цена/производительность, чем стандартные open-source подходы к индексированию, одновременно устраняя операционную сложность управления инфраструктурой. Корпоративные возможности включают compute с масштабированием до нуля, межрегиональное аварийное восстановление, развертывание BYOC, безопасность и соответствие требованиям корпоративного уровня (SOC 2, HIPAA, ISO 27001 и GDPR), а также SLA до 99,99%.

Разработчики могут развернуть Milvus как open-source векторную базу данных или использовать Zilliz Cloud как управляемую платформу для множества рабочих нагрузок на протяжении всего жизненного цикла AI-данных.

Что дальше

Дорожная карта Milvus развивает архитектуру 3.0 с predicate pushdown для External Collections, external backfill, дополнительными операторами Spark и поддержкой большего числа табличных форматов, включая Delta Lake и Apache Paimon.

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