Сокращение затрат до 50 раз при создании GenAI-приложений с использованием Zilliz Cloud Serverless
Введение
С недавними достижениями в области генеративного ИИ сценарии использования векторных баз данных растут экспоненциально. Например, Retrieval Augmented Generation (RAG), популярная техника улучшения больших языковых моделей (LLM), использует векторные базы данных, такие как Milvus и Zilliz Cloud (управляемый Milvus), для хранения, индексирования и извлечения релевантной информации, чтобы помогать LLM генерировать более точные результаты.
На недавнем Unstructured Data Meetup в Сан-Франциско James Luan, VP of Engineering в Zilliz, рассказал, как разработчики могут использовать Zilliz Cloud Serverless, новое предложение Zilliz, в своих приложениях генеративного ИИ. Вкратце, этот новый сервис от Zilliz позволяет пользователям хранить, индексировать и запрашивать огромные объемы векторных эмбеддингов лишь за малую часть стоимости. Хорошая новость в том, что производительность Zilliz Cloud Serverless также весьма конкурентоспособна по сравнению с векторными базами данных в оперативной памяти.
В этой статье мы подытожим ключевые тезисы James и более подробно рассмотрим Zilliz Cloud Serverless. Вы также можете посмотреть его выступление на YouTube, чтобы узнать больше.
Почему векторные базы данных важны в эпоху ИИ
Современным приложениям и техникам ИИ, таким как Retrieval Augmented Generation (RAG), рекомендательные системы, чат-боты на базе ИИ и движки семантического поиска, требуется надежная система для эффективной обработки огромных объемов неструктурированных данных. Векторные базы данных — это системы хранения, которые позволяют нам эффективно хранить, индексировать и извлекать эти данные.
Векторные базы данных, такие как Milvus и Zilliz Cloud, оснащены продвинутыми методами индексирования, из которых пользователи могут выбирать для эффективного и быстрого извлечения данных. Многие из них, особенно Milvus и Zilliz Cloud, также предлагают удобные интеграции с популярными AI-фреймворками и платформами, такими как LangChain, Spark, Snowflake и Hugging Face, что упрощает разработчикам генеративного ИИ создание сложных AI-приложений. Благодаря различным подходам к семантическому поиску, таким как плотный векторный поиск и гибридный поиск по плотным и разреженным векторам, разработчики могут получать наиболее релевантные результаты для любого сценария использования.
Недавний опрос 2024 года среди 1 000 разработчиков Generative AI в сообществе Milvus выявил семь аспектов, на которые они обращают внимание в векторной базе данных, прежде чем рассматривать ее использование в своих AI-приложениях:
Качество поиска: Насколько релевантны полученные результаты для заданного запроса?
Экономическая эффективность: Насколько экономична база данных с точки зрения эксплуатационных расходов и затрат на обслуживание?
Простота использования: Насколько база данных удобна и интуитивно понятна для разработчиков при внедрении и управлении?
Производительность: Насколько быстро и эффективно база данных может обрабатывать запросы и возвращать результаты?
Масштабируемость: Насколько хорошо база данных может обрабатывать растущие объемы данных и количество арендаторов без ущерба для производительности?
Высокая доступность: Насколько надежно база данных может поддерживать время безотказной работы и предотвращать потерю данных в случае сбоев?
Безопасность: Насколько хорошо база данных защищает конфиденциальные данные и предотвращает несанкционированный доступ?
Рисунок 1: Ключевые факторы выбора векторной базы данных, собранные от 1000 разработчиков Gen AI
Milvus высоко оценивается за качество поиска. Он позволяет пользователям выбирать различные методы индексирования и векторного поиска, чтобы сбалансировать производительность и полноту поиска, а также извлекать релевантную информацию как по глубине, так и по контексту.
Пользователи могут выбирать среди Flat, IVFFlat, HNSW и многих других методов индексирования. У каждого метода индексирования есть плюсы и минусы, и подробное объяснение этих методов можно найти в этой статье о выборе векторного индекса.
Для операций векторного поиска можно использовать плотный, разреженный или гибридный поиск, чтобы получать релевантные результаты по запросу. Мы также можем использовать скалярную фильтрацию с подходом булевых операций во время операции поиска для дальнейшего уточнения результата.
Внедрение Zilliz Cloud Serverless значительно улучшает второй и третий наиболее желаемые аспекты векторной базы данных, упомянутые выше: экономическая эффективность и простота использования. В следующих разделах будет показано, как Zilliz Cloud Serverless улучшает Milvus в этих двух аспектах.
Распространенные проблемы при разработке AI-приложений
При разработке AI-приложения создание прототипа является следующим шагом после решения о том, какую векторную базу данных использовать. На этом этапе мы обычно сохраняем все наши данные или их подмножество в векторной базе данных, затем выбираем большую языковую модель (LLM) и разрабатываем промпты. Затем мы выбираем LLM и набор промптов, которые соответствуют целевым показателям качества нашего сценария использования. Наконец, мы развертываем наше AI-приложение в production.
Однако по мере роста пользовательской базы нашего AI-приложения сложность поддержки и масштабирования нашей инфраструктуры становится более выраженной. Мы должны учитывать такие аспекты, как стоимость на пользователя, мониторинг производительности приложения в production, работа с multi-tenancy, управление пиковым трафиком, устранение программных ошибок и многое другое.
Чем больше наша пользовательская база, тем дороже становится удовлетворять потребности пользователей, сохраняя при этом ключевые метрики производительности, такие как качество поиска, задержка и доступность. Поэтому выбор правильной инфраструктуры и программной архитектуры имеет решающее значение при развертывании вашего AI-приложения в production-среде.
Одно из решений для масштабирования вашего AI-приложения — использование выделенных кластеров в Zilliz Cloud.
Рисунок 2: Архитектура выделенных кластеров Zilliz
Выделенные кластеры предлагают выделенную среду и ресурсы для вашего AI-приложения, позволяя обрабатывать более крупные наборы данных с улучшенной производительностью. Они предоставляют расширенные функции, такие как:
Разделение хранения и вычислений.
Эластичный пул ресурсов для пакетных рабочих нагрузок.
Резервное копирование данных в объектные хранилища, такие как S3.
Кэширование данных для еще более высокой скорости извлечения.
Эти кластеры размещаются в облаке, что устраняет необходимость в управлении локальной инфраструктурой.
Однако существенным недостатком выделенных кластеров является высокая первоначальная и текущая стоимость. Даже когда кластер простаивает без какой-либо поисковой активности, он потенциально может стоить более $100 в месяц. Кроме того, производительность может снижаться по мере роста пользовательской базы хранимых данных и объема. Поэтому необходимо более эффективное решение для построения архитектуры, которая будет не только экономичной, но и сможет масштабироваться по мере того, как наше AI-приложение достигнет более широкой пользовательской базы.
Zilliz Cloud Serverless, экономия затрат до 50 раз
Zilliz Cloud Serverless представляет собой новейшие архитектурные достижения, предлагаемые Zilliz для минимизации инфраструктурных затрат и бесперебойного запуска ваших AI-приложений в production. Он обеспечивает экономию затрат до 50 раз по сравнению с векторными базами данных in-memory благодаря таким функциям, как оплата по мере использования и автомасштабирование, которые адаптируются к различным рабочим нагрузкам. Serverless-предложение доступно у основных облачных провайдеров, включая AWS и GCP, и скоро будет доступно на Azure.
Рисунок 3- Ключевые преимущества Zilliz Cloud Serverless
Zilliz Cloud Serverless реализует четыре ключевые технологии для оптимизации затрат ваших AI-приложений:
Логические кластеры и автомасштабирование
Разделение потоковых и исторических данных
Многоуровневое хранилище, адаптированное под различные потребности хранения данных
Мультиарендность и разделение горячих и холодных данных
Теперь рассмотрим каждую из этих технологий подробнее.
Логические кластеры и автомасштабирование
Zilliz Cloud Serverless вводит концепцию логических кластеров и автомасштабирования. Логический кластер соответствует базе данных в физическом кластере. Физический кластер состоит из нескольких типов узлов, каждый со своей функциональностью:
Прокси-узлы: Маршрутизируют трафик, ограничивают запросы на основе квот и масштабируются в соответствии с CPU и пропускной способностью сети.
Потоковые узлы: Обслуживают поиск по потоковым данным и масштабируются на основе времени очереди записи и использования CPU/памяти.
Узлы запросов: Обрабатывают поисковые запросы по историческим данным и масштабируются в соответствии с временем очереди поиска и CPU/памятью.
Индексные узлы: Создают индексы для blob-данных, хранящихся в объектном хранилище.
Рисунок 4: Диаграмма логических кластеров
Логический кластер работает с использованием механизма аутентификации для каждого арендатора через API-ключ. У каждого арендатора есть уникальный API-ключ, который система использует для маршрутизации запросов и обеспечения получения корректных данных во время операций запросов.
Во время операций записи данных все данные, генерируемые на лету, хранятся в течение определенного временного интервала внутри потоковых узлов. Это гарантирует, что свежие данные могут быть получены с низкой задержкой. Через некоторое время эти потоковые данные сбрасываются в blob-хранилище (например, S3), где индексный узел создает индекс всех данных.
Во время операций запросов все проиндексированные данные кэшируются на локальных дисках узлов запросов. Этот метод значительно снижает затраты на хранение по сравнению с индексированием in-memory.
Разделение потоковых и исторических данных
Как обсуждалось в предыдущем разделе, Zilliz Cloud Serverless эффективно отделяет потоковые данные от исторических, реализуя различные типы узлов в своей архитектуре.
Потоковые данные относятся к данным реального времени, которые непрерывно генерируются и обрабатываются на лету, тогда как исторические данные относятся к ранее собранным и сохраненным данным. Потоковые данные содержат свежую, актуальную информацию, которая хранится внутри потоковых узлов в течение определенного периода, обеспечивая быстрое получение во время операций запросов.
По истечении заранее заданного периода данные внутри потоковых узлов сбрасываются в blob-хранилище, фактически становясь частью исторических данных. Этот переход крайне важен, поскольку blob-хранилище, как правило, является более экономичным решением для больших объемов данных, которым не требуется такой же уровень немедленного доступа, как данным в реальном времени или свежим данным.
Figure 5- Рабочий процесс различных узлов в логическом кластере
Во время операций поиска все исторические данные кэшируются в узлы запросов. Затем система объединяет результаты поиска из потоковых узлов и узлов запросов, чтобы предоставить комплексные результаты.
Многоуровневое хранилище
Одна из основных причин высоких операционных затрат векторных баз данных заключается в том, что все данные хранятся в RAM. Чтобы решить эту проблему, Zilliz Cloud Serverless внедряет в свою архитектуру технологию многоуровневого хранения данных.
Многоуровневое хранение данных устроено просто: данные организуются по разным уровням на основе требований к производительности, стоимости и частоты доступа. Общее правило заключается в том, что часто используемые данные хранятся в более дорогом высокопроизводительном хранилище, тогда как менее часто используемые данные хранятся в более дешевом и медленном хранилище. Реализуя разные уровни хранения для каждой категории данных, мы можем оптимизировать общую стоимость хранения данных.
Figure 6- Диаграмма многоуровневого хранилища
Часто используемые данные, которые необходимо извлекать с низкой задержкой, хранятся в RAM. Как показано выше, хранение данных в RAM стоит примерно $5 за GB хранилища. Однако взамен мы получаем результаты примерно за 100 наносекунд, что является самым быстрым показателем по сравнению с другими уровнями.
С другой стороны, менее часто используемые данные хранятся в blob-хранилище, таком как Amazon S3. Это стоит примерно $0.023 за GB хранилища, но извлечение результатов занимает более 10 миллисекунд.
Мультитенантность и разделение на горячие и холодные данные
Zilliz Cloud Serverless вводит многоуровневое кэширование данных, особенно для сценариев использования с мультитенантностью. Он различает хранение данных для "горячих" и "холодных" тенантов.
Горячий тенант — это высокоактивный пользователь, который часто выполняет поиск данных или запросы. И наоборот, холодный тенант менее активен и выполняет поиск данных редко.
Когда тенанты классифицируются как горячие, их данные хранятся в локальной памяти, обеспечивая извлечение с низкой задержкой. Между тем, если тенант классифицируется как холодный и хочет выполнить поиск данных, все данные сначала должны быть загружены из blob-хранилища (например, S3), что приводит к более длительному времени извлечения по сравнению с горячими тенантами.
Figure 7: Разделение на горячие и холодные данные в сценарии мультитенантности
Приложение можно предварительно прогреть, чтобы улучшить задержку, загрузив все данные из blob-хранилища в локальную память. Затем, когда пользователи обращаются к своему AI-приложению, процесс извлечения может быть выполнен с низкой задержкой.
Zilliz Cloud Serverless также реализует кластеризацию данных по ключам разделов под капотом, чтобы дополнительно ускорить процесс поиска данных. Во время извлечения данных система ищет только данные в перспективных разделах, а не во всех доступных данных.
Ниже приведено сравнение стоимости между холодным, теплым и горячим поиском:
| Холодный поиск | Теплый поиск | Горячий поиск | |
| 1M, 768Dim | 2.3s | 80ms | 4ms |
| 10M, 768Dim | 7s | 150ms | 7ms |
Таблица: Сравнение задержки между холодным и горячим поиском в одном тенанте.
Как показано, холодный поиск (при котором все данные находятся в blob-хранилище) требует больше времени для извлечения данных во время поисковых операций. Для 10 миллионов эмбеддингов, каждый из которых состоит из 768-мерного вектора, системе требуется примерно 7 секунд для выполнения поисковой операции. Эта скорость все еще приемлема для распространенных сценариев использования генеративного ИИ, таких как RAG. В отличие от этого, тот же сценарий требует всего 7 миллисекунд, если все данные находятся в локальной памяти.
Однако выполнение холодного поиска приводит к значительной экономии затрат. База данных для холодного поиска стоит примерно 915 для горячего поиска. Это означает 50-кратную экономию затрат благодаря архитектуре Zilliz Cloud Serverless.
Что нового в Zilliz Cloud?
В дополнение к serverless-предложению Zilliz недавно объявила о новых функциях в Zilliz Cloud, которые улучшают поддержку запуска AI-нагрузок в производственных средах. Вот краткий обзор этих новых добавлений и улучшений:
Общая доступность Serverless (GA).
Migration Service ****для бесшовной передачи векторных данных между базами данных и другими системами данных
Fivetran Connector: новая интеграция с Fivetran, которая значительно расширяет возможности загрузки неструктурированных данных из 500+ источников
Multi-replica: обеспечивает репликацию на уровне кластера, значительно улучшая производительность запросов и доступность системы.
Auto-scaling (private preview): Zilliz Cloud запускает функцию автоматического масштабирования в private preview, которая решает распространенную проблему в производственных средах: управление емкостью кластера в ответ на колеблющиеся требования.
Новый регион Zilliz Cloud онлайн: AWS Tokyo (ap-northeast-1), что означает более низкую задержку, лучшую производительность и больший суверенитет данных для пользователей в Азиатско-Тихоокеанском регионе и соседних регионах.
И многое другое! Для получения более подробной информации прочитайте последний launch blog Zilliz Cloud.
Заключение
Zilliz Cloud Serverless представляет собой последнее достижение, реализованное Zilliz для оптимизации работы и стоимости систем AI-приложений. Используя четыре ключевые технологии, пользователи потенциально могут запускать свои AI-приложения с затратами до 50 раз ниже, чем при использовании векторных баз данных в памяти. Эти технологии включают логические кластеры, разделение потоковых и исторических данных, многоуровневое хранилище и hot-cold separation для многопользовательской среды.
Если вы хотите начать работу с Zilliz Cloud Serverless, вы можете попробовать его бесплатно. Посетите эту страницу, чтобы узнать больше!
Читать далее
Zilliz Cloud Update: Smarter Autoscaling for Cost Savings, Stronger Compliance with Audit Logs, and More
What's new in Zilliz Cloud? Smarter autoscaling with scale-down, audit logs GA, enhanced SSO, and Milvus 2.6 in Private Preview.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.