Как Zilliz увидела будущее векторных баз данных — и создала решение для продакшена
Этот пост представляет собой краткий обзор подкаста с Innovator Coffee и Джеймсом Луаном, VP of Engineering в Zilliz.
До того как генеративный ИИ стал мейнстримом, векторные базы данных редко обсуждались сами по себе. Основное внимание по-прежнему было сосредоточено на реляционных базах данных, поисковых системах или фреймворках для больших данных. Векторный поиск, если о нем вообще заходила речь, обычно существовал в исследовательских статьях или внутри алгоритмических библиотек — а не в разговорах о продакшен-системах.
Но векторные базы данных не возникли из ниоткуда. Они выросли из более глубокого изменения в том, как данные создаются и используются. Примерно в 2017–2018 годах команды Zilliz начали замечать одну и ту же проблему: компании хотели работать с гораздо большим объемом неструктурированных данных — текстом, изображениями, аудио, логами, поведением пользователей, — но существующие инструменты не были для этого предназначены. Традиционные базы данных и поиск по ключевым словам могли хранить эти данные, но не умели хорошо их понимать. Они хорошо справлялись с точными совпадениями. Смысл и сходство — совсем другая история.
Векторы предложили практичный способ закрыть этот разрыв. Преобразуя текст, изображения и другой контент в эмбеддинги, системы смогли напрямую вычислять сходство. Когда данные стали представляться таким образом, базы данных перестали просто хранить записи. Они получили возможность извлекать информацию на основе смысла, а не только ключевых слов.
Поэтому векторные базы данных находятся между мощными моделями и хаотичными данными реального мира, делая неструктурированную информацию доступной для поиска, сравнения и использования в масштабе.
Так как же векторный поиск совершил переход из исследований в продакшен — и куда векторные базы данных движутся дальше? В недавнем выпуске англоязычного подкаста Innovator Coffee Джеймс Луан, VP of Engineering в Zilliz, поделился своим взглядом, опираясь на историю основания компании, идеи, лежащие в основе Milvus, open-source векторной базы данных Zilliz, и принципы проектирования, сформировавшие систему.
От алгоритмов к продакшену: эволюция векторных баз данных
Оглядываясь на ранние дни, когда векторный поиск еще не был готов к продакшену, Джеймс Луан отмечает, что большинство первых достижений происходило внутри крупных технологических компаний. Проекты вроде Meta’s FAISS заложили техническую основу, но это были библиотеки, а не базы данных. Похожие системы векторного поиска существовали в таких компаниях, как Microsoft и Spotify, обычно создавались для внутреннего использования и адаптировались под конкретные нагрузки. Эти инструменты были эффективны, но их никогда не проектировали как универсальные, долгоживущие системы.
Переломный момент наступил, когда векторный поиск перешел из исследований в реальные продукты. Как только команды попытались развернуть его в продакшене, системные вызовы стало невозможно игнорировать. Масштабируемость, надежность и повседневная эксплуатация стали так же важны, как и качество поиска. Появились разные пути развития. Одни команды создавали управляемые сервисы, оптимизированные для онлайн-инференса и тесной интеграции с большими языковыми моделями. Другие выбрали более широкий инфраструктурный подход, интегрируя векторный поиск с озерами данных и традиционными базами данных для поддержки сценариев корпоративного масштаба. С точки зрения Джеймса, такое расхождение — естественный этап возникновения любого нового инфраструктурного слоя.
По мере того как большие языковые модели развивались, а приложения выходили в продакшен, роль векторных баз данных быстро расширялась. Ранние сценарии использования были сосредоточены на извлечении данных на основе сходства — рекомендательных системах, поиске изображений и сопоставлении контента. За последние два-три года Retrieval-Augmented Generation (RAG) стала доминирующим паттерном. В RAG-системах векторные базы данных предоставляют моделям релевантный, обоснованный контекст, позволяя извлекать факты и помогая снижать количество галлюцинаций.
Эта роль становится еще более важной в агентных системах. Здесь векторные базы данных выступают как долговременная или почти оперативная память, поддерживая многошаговое рассуждение, сжатие контекста и мультимодальный поиск. Джеймс резюмирует этот сдвиг простым принципом: меньше структуры, больше интеллекта. По мере улучшения возможностей моделей жесткие пайплайны и трудоемкая предварительная разметка могут сдерживать системы. Агенты работают лучше, когда действуют в гибком семантическом пространстве и динамически решают, как извлекать и комбинировать информацию.
В то же время Джеймс подчеркивает, что векторные базы данных — не магия. Качество поиска зависит от управления данными не меньше, чем от алгоритмов. Хорошо подготовленные, релевантные предметной области данные — и непрерывная оценка — крайне важны. Модели эмбеддингов, реранкеры и стратегии поиска быстро развиваются, и команды, которые слишком долго не пересматривают свой стек, часто отстают.
Заглядывая за пределы инференса, Джеймс видит, что векторные базы данных играют все более значимую роль в обучении и подготовке данных. По мере того как мультимодальные модели становятся более распространенными, векторный поиск все чаще используется для очистки, дедупликации и курирования больших наборов данных, включающих текст, изображения, видео и PDF-файлы. Со временем это может сблизиться с озерами данных в архитектуре «векторного озера», соединяющей пакетную обработку данных с онлайн-инференсом.
В этой более долгосрочной перспективе векторные базы данных уже не просто поисковые движки. Они становятся семантическим слоем, охватывающим обучение, инференс и долгосрочное управление данными, поддерживая полный жизненный цикл систем ИИ.
Как Zilliz нашла свое направление до того, как векторные базы данных стали мейнстримом
Джеймс описывает ранние дни Zilliz как период исследования, а не мгновенной ясности. И он, и CEO компании пришли из мира традиционных баз данных, проведя годы за созданием транзакционных систем в Oracle. С самого начала они знали, что не хотят строить еще одну обычную базу данных, — но каким должна быть эта альтернатива, оставалось открытым вопросом.
Их первой попыткой стала база данных с GPU-ускорением, нацеленная на ускорение крупномасштабной обработки данных с помощью специализированного оборудования. Технически это работало. Коммерчески — нет. GPU обеспечивали высокую производительность, но были дорогими, и для большинства реальных рабочих нагрузок соотношение цены и производительности было трудно оправдать. В то же время системы на базе CPU, такие как ClickHouse, быстро совершенствовались, закрывая значительную часть разрыва в производительности за малую долю стоимости.
Этот опыт заставил глубже переосмыслить подход. Вместо того чтобы спрашивать, как сделать базы данных быстрее, команда начала задавать другой вопрос: какие типы данных по-прежнему обслуживаются плохо? Для традиционной аналитики и транзакционных нагрузок уже существовали зрелые решения. Выделялись неструктурированные данные — текст, изображения и другой контент, который пользователи все чаще хотели искать и понимать, а не просто хранить.
Поворотный момент наступил благодаря обратной связи от пользователей. Некоторые ранние пользователи спрашивали, можно ли использовать систему для ускорения поиска изображений. Этот вопрос указал на более широкую возможность: семантическое сходство в масштабе, обеспечиваемое векторными представлениями. Команда поняла, что векторы, а не GPU, были более фундаментальной абстракцией. Из этого понимания родился Milvus как open-source-проект, ориентированный на крупномасштабный векторный поиск.
Джеймс подчеркивает, что этот разворот не был продиктован хайпом. В то время «векторные базы данных» не были признанной категорией, и даже сам термин не имел четкого определения. Решением руководило убеждение, укорененное в фундаментальных принципах баз данных: если семантический поиск будет иметь значение, ему в конечном итоге потребуются те же качества, что и любой критически важной системе данных, — масштабируемость, стабильность и надежность.
Этот выбор определил направление всего, что последовало. Рано сделав ставку на векторы как данные первого класса и на базы данных как долгоживущие системы, Zilliz заняла позицию впереди отраслевого сдвига к приложениям на основе ИИ — задолго до того, как этот сдвиг стал широко заметен.
По мере того как модели позже перешли из исследований в production, векторные базы данных стали ключевой частью корпоративных AI-архитектур, поддерживая RAG-пайплайны, агентные системы, мультимодальный retrieval и крупномасштабную дедупликацию обучающих данных. С этим расширением появились новые ожидания. Одной скорости уже было недостаточно. Точность, масштабируемость, эффективность затрат, управление данными и безопасность — всё это стало первоочередными задачами.
Вывод Джеймса заключается в том, что создание систем, которые балансируют эти требования, — это не задача краткосрочной оптимизации. Это требует терпения, устойчивых инженерных инвестиций и долгосрочной приверженности фундаментальным принципам инфраструктуры — далеко за пределами первоначального ажиотажа вокруг новой категории.
Технические сложности и решения: запуск векторных баз данных в production
По мере того как векторные базы данных переходили в реальные production AI-системы, Джеймс утверждает, что успех перестал сводиться к сырой производительности. В ранних внедрениях скорость была важнее всего. Но когда в игру вступили большие языковые модели, настоящей задачей стало создание систем, способных устойчиво масштабироваться, — одновременно балансируя стоимость, точность, надежность и корпоративные требования.
Стоимость: выход за пределы поиска только в памяти
Джеймс отмечает, что ранние системы векторного поиска в значительной степени полагались на индексы в оперативной памяти. Такой подход работал, когда наборы данных были небольшими, но становился экономически неустойчивым по мере того, как приложения на базе LLM увеличивали объемы данных. В таком масштабе сокращение задержки на несколько миллисекунд гораздо менее важно, чем контроль затрат на хранение.
Решение — многоуровневый подход к хранению и индексированию. Комбинируя индексы в памяти, на диске и в объектном хранилище, векторные базы данных могут снижать затраты на хранение до 100 раз. Этот сдвиг не просто оптимизирует существующие рабочие нагрузки — он в принципе делает крупномасштабный retrieval практичным.
Масштабируемость и стабильность в реальном масштабе
Давление затрат быстро выявляет ограничения масштабируемости. Джеймс отмечает, что многие команды начинают с простых одноузловых конфигураций, потому что их легко развернуть. Проблемы проявляются позже, когда объем данных за короткое время вырастает в 10, 50 или даже 100 раз.
Эта реальность привела Zilliz к перестройке Milvus в распределенную cloud-native систему. Для Джеймса масштабируемость неотделима от стабильности. Система, которая может масштабироваться, но непредсказуемо отказывает под реальными нагрузками, не является пригодной инфраструктурой.
Он подчеркивает, что стабильность часто является самой сложной частью превращения векторного поиска в production-систему. С существующими open-source инструментами многие команды могут построить рабочий прототип за шесть–двенадцать месяцев. Сложность в том, чтобы заставить эту систему надежно работать в течение длительного времени по мере изменения объема данных, шаблонов запросов и операционной сложности.
В отличие от оптимизации производительности, стабильность не возникает из одного прорыва. Прирост производительности виден — бенчмарки могут показать улучшение на 20% или 30% за несколько месяцев. Стабильность строится иначе. Каждое исправление может улучшить SLA лишь на долю процента, едва заметную само по себе. Но благодаря сотням небольших накопительных улучшений система постепенно становится достаточно надежной, чтобы работать как долгосрочная инфраструктура.
Точность: retrieval задает верхнюю границу
В RAG и агентных системах качество retrieval напрямую определяет производительность модели. Если системе не удается извлечь нужную информацию, у модели нет способа это компенсировать.
Джеймс подчеркивает, что точность — это не только вопрос базы данных. Она зависит от всего retrieval-стека, включая embedding-модели, стратегии reranking и качество данных. Поскольку эти компоненты быстро развиваются, командам нужно часто переоценивать свои конфигурации — зачастую каждые несколько месяцев, — чтобы поддерживать точность с течением времени.
Как Zilliz балансирует open source и бизнес
За последний год или два Джеймс много думал о вызове, который снова и снова возникает перед open-source компаниями: как создать и поддерживать активное open-source сообщество, одновременно управляя растущим бизнесом.
Цели open source и коммерческие цели не всегда аккуратно совпадают. Open-source-проекты зависят от открытости, долгосрочного участия и доверия сообщества, в то время как компании нужно управлять целевыми показателями выручки и ограничениями роста. В последние годы это несоответствие стало более заметным во всей отрасли. James видел, как несколько команд переводили свои open-source-проекты в режим сопровождения — не потому, что технология перестала работать, а потому, что open-source-модель становилась сложной для поддержки по мере масштабирования бизнеса.
Но для Zilliz open source — это не просто технический выбор, это также решение в сфере go-to-market. На практике он работает почти как высокотехническая бесплатная пробная версия — способ для разработчиков обнаружить продукт, оценить его и обрести уверенность в нем через реальное использование. Это особенно важно для стартапов, где привлечение первых пользователей дается трудно. Для инженерно-ориентированной команды вроде Zilliz это оказалось гораздо эффективнее, чем традиционный маркетинг или подходы, основанные на продажах.
Открыв исходный код Milvus, команда сосредоточилась на GitHub как на основной точке входа. Разработчики использовали Milvus в реальных рабочих нагрузках, делились обратной связью и вносили улучшения обратно в проект. Со временем это создало тесный цикл обратной связи между пользователями, сообществом и разработкой продукта.
Результаты были ощутимыми. James отмечает, что примерно 80% клиентов Zilliz Cloud начинали как пользователи open-source-проекта Milvus. Open source также служил мощным механизмом доверия — командам, которые уже запускали Milvus самостоятельно, было гораздо комфортнее впоследствии переходить на коммерческое предложение.
Однако этот переход никогда не был автоматическим. James ясно говорит, что один только open source не создает бизнес. Коммерческий продукт должен делать больше, чем просто упаковывать open source, — он должен решать проблемы, которые open-source-версия не решает. Для Zilliz эта ценность заключается в надежной эксплуатации Milvus в масштабе — управлении обновлениями, обработке сбоев и постоянной оптимизации производительности и стоимости.
Важным результатом такого подхода является то, что многие пользователи обнаруживают снижение своих общих затрат после перехода на управляемое предложение. Векторные базы данных быстро развиваются под влиянием достижений в индексировании, квантизации и хранении данных. С Zilliz Cloud пользователи непрерывно получают выгоду от этих улучшений, не беря на себя бремя обновлений или управления инфраструктурой.
С точки зрения James, именно этот баланс делает модель устойчивой. Open source создает доступ и доверие. Коммерческое предложение превращает долгосрочный инфраструктурный прогресс в практическую ценность — не подрывая при этом открытость, которая изначально привлекла пользователей.
Чем Zilliz выделяется на переполненном рынке
Когда его спрашивают о том, как сегодня выглядит рынок векторных баз данных, James признает, что быстрое внедрение AI стремительно сделало это пространство переполненным. Сейчас оно включает управляемые сервисы, легковесные плагины и растущее число новых участников, предлагающих возможности векторного поиска. На первый взгляд многие из этих решений выглядят похожими.
По мнению James, настоящее отличие определяется не списками функций, а глубиной и зрелостью лежащих в основе систем. Создать базовую функцию векторного поиска относительно просто. Создать систему, способную надежно работать в масштабе на протяжении длительного времени, — нет.
Зрелость систем
Преимущество Zilliz начинается со зрелости систем — в частности, масштабируемости, стабильности и контроля затрат. С самого начала Milvus проектировался как распределенная, Kubernetes-native база данных, созданная так, чтобы сохранять стабильность при росте объемов данных в десятки раз. Это важно, потому что векторные рабочие нагрузки редко масштабируются плавно. Системы, которые хорошо работают в небольшом масштабе, часто испытывают трудности, когда использование становится устойчивым, скачкообразным и непредсказуемым.
Стоимость также является частью этой зрелости. Zilliz рано инвестировала в многоуровневое индексирование, объединяющее память, диск и объектное хранилище. Это дает пользователям практическую гибкость в балансировании производительности и стоимости по мере развития рабочих нагрузок, вместо того чтобы привязывать их к одному дорогому режиму эксплуатации.
Готовность к корпоративному использованию
Готовность к корпоративному использованию — еще один ключевой отличительный фактор. Джеймс противопоставляет Zilliz командам, которые в основном пришли из областей, ориентированных на модели или ИИ. Корни Zilliz в традиционной инженерии баз данных привели к ранним инвестициям в такие возможности, как контроль доступа, изоляция данных, развертывания BYOC, шифрование и соответствие требованиям.
Эти функции не являются опциональными на корпоративном уровне. Именно они позволяют векторным базам данных выйти за рамки экспериментов разработчиков и войти в регулируемые среды, такие как финансы, здравоохранение и крупные организации со строгими требованиями к безопасности и управлению.
Операционная надежность
Джеймс отмечает, что многие команды недооценивают долгосрочную операционную сложность векторных баз данных. Ранние системы могут хорошо работать в контролируемых конфигурациях, но настоящие трудности появляются, когда данные быстро растут, увеличивается параллельность, а ИИ-приложения переходят в непрерывную эксплуатацию.
Большинство компаний не хотят вкладывать свое время и ресурсы в эксплуатацию сложной инфраструктуры, особенно в таких узкоспециализированных областях, как векторный поиск. Именно здесь Джеймс видит роль Zilliz: взять на себя операционную нагрузку по запуску векторных баз данных в масштабе, чтобы команды могли сосредоточиться на создании приложений, а не на поддержании инфраструктуры. По мере созревания рынка такое разделение труда становится все более важным.
Взгляд в будущее: следующий этап развития векторных баз данных
Заглядывая на три-пять лет вперед, Джеймс прагматично оценивает, куда движется индустрия. Рост продолжится, но ключевой вопрос будет уже не в том, можно ли создавать системы векторных баз данных, а в том, можно ли эксплуатировать их устойчиво. По мере того как модели становятся крупнее, а ИИ-приложения глубже входят в продуктивную эксплуатацию, объемы данных будут быстро расти, повышая планку для контроля затрат, надежности, точности и безопасности.
В такой среде способность снизить затраты на порядок без ущерба для качества извлечения данных становится определяющим ориентиром. Джеймс считает, что именно здесь формируются устойчивые преимущества. Долгосрочных лидеров в сфере векторных баз данных будут определять не функции и не ажиотаж, а инфраструктурная дисциплина — способность эффективно, надежно и долго эксплуатировать крупномасштабные системы.
Чтобы услышать полное обсуждение, вы можете найти выпуск на Spotify, Apple Podcasts и YouTube.
Читать далее
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty
Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.
DeepSeek-VL2: Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding
Explore DeepSeek-VL2, the open-source MoE vision-language model. Discover its architecture, efficient training pipeline, and top-tier performance.