Коротко

Milvus 3.0, опубликованный 29 июля 2026 года, превращает векторную базу в поисковый слой над озером данных. External Collection позволяет индексировать и искать данные, которые остаются в S3-совместимом объектном хранилище или таблице Iceberg, без обязательного копирования всей исходной таблицы внутрь Milvus.

Для бизнеса это может убрать дублирование данных и часть ETL-процессов. Но lake-native архитектура оправдана прежде всего там, где озеро данных уже существует и обслуживается. Строить Iceberg, объектное хранилище и распределённый Milvus ради первого RAG-пилота обычно дороже, чем начать с простой управляемой коллекции.

Что изменилось в версии 3.0

Главная тема релиза — работа с внешними коллекциями и Storage V3. Milvus может представить внешние файлы и таблицы как коллекцию, построить поисковые структуры и использовать привычные API поиска. Источник данных при этом остаётся на месте.

В стабильной версии 3.0 появились:

  • External Collection для Parquet, Lance, Iceberg, Vortex и формата `milvus-table`;
  • вычисление производных полей, включая BM25-векторы, MinHash и embeddings, поверх внешних данных;
  • обновление внешней коллекции при добавлении столбцов без полного перестроения;
  • добавление, backfill и удаление полей в работающей коллекции;
  • новые разреженные индексы SINDI, Block-Max WAND и Block-Max MaxScore;
  • длинные TEXT-поля и хранение крупных значений в LOB-файлах;
  • фасетный поиск, серверные агрегации и цепочки reranking;
  • прямое использование конфигураций FAISS через index-factory strings;
  • отдельное развёртывание журнала Woodpecker для крупных кластеров.

Это уже не косметическое обновление SDK, а изменение границы между хранилищем данных, индексом и сервисом поиска.

Как выглядит lake-native RAG

В классическом RAG-пайплайне документы сначала попадают в объектное хранилище или DWH. Затем ETL-процесс извлекает текст, строит embeddings и копирует результат в векторную базу. При изменении источника команда должна синхронизировать две системы и следить, чтобы индекс не отставал.

С внешней коллекцией схема меняется:

1. Исходные таблицы и файлы остаются в объектном хранилище.
2. Таблица имеет версионируемые метаданные, например Iceberg.
3. Milvus отображает внешние поля в свою схему.
4. Поисковые признаки строятся поверх этих полей.
5. Приложение обращается к Milvus как к retrieval-слою.
6. Refresh синхронизирует видимое состояние с новой версией внешней таблицы.

Дублирование уменьшается, а граница ответственности становится яснее: data-платформа владеет источником и его жизненным циклом, команда поиска — индексами, релевантностью и SLO.

Где бизнес получает выгоду

Меньше копий и ETL

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

Обновление embedding-модели без остановки

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

Гибридный поиск в одном слое

BM25, dense и sparse vectors, фильтры, фасеты и reranking можно объединить внутри поискового запроса. Для каталога, базы знаний или архива обращений это уменьшает объём клиентской оркестрации.

Ограничения, которые нельзя пропустить

Релизные заметки содержат несколько важных оговорок.

  • Storage V3 отключён по умолчанию и включается отдельным флагом.
  • Переход 2.6 → 3.0 допускает откат, но после использования функций, меняющих сериализованный формат данных, гарантия отката прекращается.
  • Новые версии индексов пока включаются вручную.
  • GPU-образы перешли на CUDA 12.9 и больше не сохраняют совместимость с Ubuntu 20.04.
  • Показатели «примерно в три раза меньший BM25-индекс» и «до десяти раз больше QPS» приведены разработчиками на внутренних тестах; их нельзя переносить на свою нагрузку без повторного измерения.

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

Кому это подходит

Архитектура разумна, если у компании уже есть:

  • объектное хранилище и дисциплина версионирования данных;
  • большой или быстро растущий набор документов;
  • несколько потребителей одного массива данных;
  • команда, способная сопровождать Milvus и lakehouse-компоненты;
  • потребность обновлять embeddings без длительного простоя;
  • измеримые требования к поиску и восстановлению.

Для небольшого бизнеса с десятками тысяч документов проще может быть Qdrant, pgvector или обычная коллекция Milvus. Lakehouse — не обязательный уровень зрелости для RAG. Это инструмент против масштаба и дублирования, а не знак архитектурной взрослости.

Как провести безопасный пилот

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

План проверки:

1. Зафиксировать источник, объём, частоту изменений и владельца данных.
2. Создать внешнюю коллекцию на отдельном стенде.
3. Проверить первоначальное индексирование и инкрементальный refresh.
4. Измерить задержку появления нового документа в поиске.
5. Сравнить Recall@k, nDCG и p95 с текущей системой.
6. Добавить новое embedding-поле и выполнить backfill без отключения чтения.
7. Проверить права на уровне источника, коллекции и приложения.
8. Сделать снимок и восстановить стенд.
9. Отдельно проверить сценарий отката до включения функций нового формата.
10. Посчитать стоимость хранения, вычислений, трафика и сопровождения за год.

Экономика без архитектурного романтизма

Экономия складывается не только из гигабайтов. Важны:

  • число копий одних и тех же данных;
  • стоимость ежедневного ETL и повторной индексации;
  • простой при смене схемы или embedding-модели;
  • сетевой трафик между хранилищем и векторной базой;
  • время инженеров на расследование рассинхронизации;
  • цена более сложной платформы и компетенций.

Если компания уже платит за озеро данных, копии и тяжёлые ETL, lake-native поиск может упростить контур. Если этих затрат ещё нет, Milvus 3.0 способен не сократить, а создать инфраструктурный бюджет.

Что взять руководителю

Milvus 3.0 делает важный шаг: retrieval может жить рядом с источником данных, а не требовать ещё одной полной копии. Это особенно ценно для крупных каталогов, архивов и быстро меняющихся корпоративных знаний.

Следующий шаг — не «перейти на lakehouse», а выбрать один дорогой поток копирования и доказать на нём три эффекта: меньше дубликатов, быстрее обновление индекса и приемлемое качество поиска. Робот может перестать таскать коробки, но кто-то всё равно должен проверить накладные.