Анализ встроенного поиска OpenAI: раскрытие ограничений хранилища, пробелов в производительности и проблем стоимости
После последних анонсов OpenAI я начал сомневаться, подходят ли OpenAI Assistants для приложений продакшен-уровня с учетом их ограничений, в частности лимита в 20 файлов и цены $0,2 за ГБ в день. Учитывая это, я написал статью, сосредоточившись на трех темах.
Дорого ли стоит $0,2/ГБ/день для базы знаний OpenAI Assistants?
Разбираемся во внутренних решениях OpenAI на основе опубликованной ими информации.
В каком направлении должна развиваться инфраструктура базы знаний AI Assistants?
Примечание: Следующий материал содержит некоторые расчеты. Вы можете изучить эти подробные вычисления или сосредоточиться на выделенных выводах для быстрого обзора.
Стоимость базы знаний OpenAI Assistants
Давайте выполним простые расчеты:
Office 365 взимает $6 за ТБ данных в месяц. Google Workspace взимает $8 за ТБ данных в месяц.
Для OpenAI Assistants стоимость составляет 0,2 ($) x 30 (дней) x 1024 (ГБ) = $6 144 за ТБ в месяц.
Следовательно, добавление AI-ассистента к моим офисным документам с помощью OpenAI Assistants обойдется на три порядка дороже, чем традиционный сервис для документов ($6 против $6 144). Это дорого? Я говорю: «Да!» это кажется чрезмерно высокой ценой.
| Сервисы | Цены |
|---|---|
| Традиционные сервисы документов | $6 /ТБ |
| OpenAI Assistants | $6 144/ТБ |
Давайте также кратко рассчитаем операционные затраты со стороны OpenAI. Следующий анализ немного сложен, но вывод прост: обслуживание 1 ГБ документов требует генерации 1,5 ГБ векторов, а серверные затраты на обслуживание этих векторов составляют около $0,30 в день. Дорого? Это выгодная сделка по сравнению с ценником $0,20/ГБ. Интересно!
| Цены | |
|---|---|
| Затраты OpenAI | $0,3/ГБ в день |
| Цена OpenAI | $0,2/ГБ в день |
Вот оценка:
Рассмотрим 1 ГБ текста с использованием модели OpenAI text-embedding-ada-002 для генерации векторов для поиска. На каждый 1 КБ текста эта модель создает embedding размерностью 1536. Каждая размерность вектора соответствует одному float32 (то есть 6 КБ на вектор), в результате чего соотношение размера входного текста к выходным векторам составляет 1:6, то есть 1 ГБ текста соответствует 6 ГБ векторов. Сжатие векторов с помощью квантизации может обеспечить степень сжатия 4:1, что означает, что 1 ГБ текста соответствует 1,5 ГБ векторов.
Давайте рассмотрим стоимость сервера для обслуживания 1,5 ГБ векторов. Выбор экономичного экземпляра AWS EC2 стоит примерно $0,30 в день на каждые 1,5 ГБ памяти. Этот сценарий более чем справедлив, поскольку он предполагает только хранение и поиск векторов. Он не включает другие элементы, такие как метаданные, мониторинг, логи, индексные файлы и стоимость высокой доступности с несколькими репликами, которые необходимы в продакшен-средах.
Вывод по анализу затрат
Новая функция Assistants от OpenAI обходится компании дороже, чем приносит, из-за высокой серверной стоимости $0,3/ГБ/день по сравнению с ценой $0,2/ГБ/день. Однако разработчики, которые хотят использовать Assistants, должны платить более чем в 1 000 раз больше, чем за традиционные сервисы документов. Поэтому они должны создавать бизнес-ценность на три порядка выше, чем обычные сервисы документов, чтобы оправдать затраты.
Эта модель ценообразования может быть оправдана для B2C-бизнесов, поскольку несколько ГБ данных стоимостью в десятки долларов в месяц вряд ли станут существенной проблемой для индивидуальных пользователей. Однако для B2B-бизнесов, работающих с данными большого масштаба, эта стоимость может значительно снизить выручку бизнеса или даже превысить ценность самого бизнеса. Например, создание персонализированного обслуживания клиентов или интеллектуальной системы поиска по патентам и юридическим документам может стать непомерно дорогим.
Разбор решения OpenAI
Давайте разберем текущую схему OpenAI Assistants. Вот некоторая общедоступная информация:
Максимум 20 файлов на одного assistant
Ограничение 512 МБ на файл
Скрытое ограничение в 2 миллиона токенов на файл, обнаруженное во время нашего тестирования
Поддерживается только текст.
Серверный трафик значительно вырос после OpenAI DevDay. Количество пробных пользователей и соответствующих создаваемых assistants не раскрывалось, но оно должно было быть значительным.
Разбор retrieval-сервиса OpenAI
Давайте проведем некоторые расчеты на основе приведенной выше общедоступной информации.
- Пользователи ограничены 20 файлами, каждый из которых ограничен 2 миллионами токенов. Если принять 200 токенов на фрагмент (соответствующий вектору), то существует ограничение в 200 000 векторов на пользователя.
| Лимит файлов на пользователя | Количество токенов | Количество векторов |
|---|---|---|
| / | 200 | 1 |
| 1 файл | 2 000 000 (верхний предел) | 10 000 |
| 20 файлов | 40 000 000 (верхний предел) | 200 000 |
- Поскольку большинство пользователей не достигнет лимита в 2 миллиона токенов на файл, мы можем оценить, что файл каждого пользователя будет содержать в среднем 400 000 токенов, что соответствует 2 000 векторам. Учитывая верхний предел в 200 000 векторов на пользователя и среднее значение 2 000 векторов на пользователя, достижение коэффициента перепродажи 1000:1 является осуществимым.
| Лимит файлов на пользователя | Количество токенов | Количество векторов |
|---|---|---|
| / | 200 | 1 |
| 20 файлов | 400 000 (в среднем) | 2 000 |
Кроме того, у OpenAI есть значительная пользовательская база, что требует от компании поддерживать стабильную систему и эффективно управлять последствиями любых аварий. Поэтому на начальных этапах разработки OpenAI Assistants они вряд ли выберут решение на основе сверхкрупного кластера. Вместо этого OpenAI, вероятно, создаст систему (показанную ниже), в которой каждая группа пользователей сможет совместно использовать небольшой экземпляр векторной базы данных для повышения стабильности.
Упрощенная архитектура Retrieval Feature в OpenAI Assistants
Предположим, что каждый физический узел имеет 32 ГБ памяти и разделен на четыре Pods. Каждый Pod размещает отдельный экземпляр векторной базы данных, при этом Pod выделяется 8 ГБ памяти. 3 ГБ выделяется системе векторной базы данных, а 5 ГБ резервируется для обслуживания пользовательских векторных данных.
При ограничении в 200 000 векторов на пользователя квантованные векторы и их индексы требуют примерно 500 МБ памяти. Поэтому каждый Pod может обслуживать десять пользователей без перепродажи. Однако при коэффициенте перепродажи 1000:1 один Pod может обслуживать до 10 000 пользователей (при как минимум сотнях активных пользователей). В результате один сервер, состоящий из четырех Pods, может обслуживать 40 000 пользователей.
Эта архитектура кажется достаточной для поддержки пробных пользователей. Однако каждый физический узел потенциально может хранить до 20 ГБ векторов и индексов для платящих клиентов, что соответствует примерно 8 ГБ исходного текста. При полной загрузке потенциальная дневная выручка составляет скромные $1.6, что заметно мало.
Примечание: В крайних случаях, когда несколько пользователей с большими файлами совместно используют один Pod, мы можем смягчить потенциальные сложности с помощью планирования. Например, развертывание нового Pod может эффективно перенести нагрузку от этих более крупных пользователей.
Краткое резюме
Архитектура сервиса retrieval OpenAI может хорошо работать для пробных пользователей, но может быть недостаточно масштабируемой для поддержки более крупных компаний с более обширными требованиями к данным.
Текущая архитектура накладывает ограничения на хранение пользовательских данных, снижая потенциальную прибыль и увеличивая расходы.
Кроме того, архитектура недостаточна для мультитенантности на уровне приложения, поскольку некоторым клиентам может потребоваться отдельный ассистент для каждого клиента. Подробнее обсуждения см. на форуме OpenAI.
Почему база знаний OpenAI Assistants недостаточно хороша
Ранее мы обсуждали ограничения OpenAI Assistants и его архитектуры. Итак, как мы можем решить эту проблему и снизить затраты? Наиболее эффективным решением было бы оптимизировать архитектуру сервиса.
Прежде чем углубляться в решение, рассмотрим ключевые факторы, которые прокладывают путь к оптимизированной архитектуре системы.
Усовершенствованное решение для векторной базы данных: гибридное дисковое/оперативное хранение векторов
Векторные базы данных обычно загружают векторы и индексы в память, чтобы ускорить ответы на запросы. Однако приложения Assistant являются типичным сценарием использования Retrieval Augmented Generation (RAG) , поэтому узкое место производительности находится в инференсе больших языковых моделей (LLM), а не в процессе запросов к векторной базе данных. В таких случаях сверхбыстрые ответы векторного поиска не требуются. Намеренно снижая производительность векторной базы данных, чтобы согласовать ее с LLM, мы можем достичь баланса между экономической эффективностью и расширенными возможностями хранения. Один из перспективных путей — исследование решения векторной базы данных на основе диска, где в память загружаются только «горячие» данные. Такой подход не только существенно снижает затраты на оборудование, но и увеличивает общую емкость хранения системы.
Оптимизация аварийного восстановления: объединение системных данных в пул
В настоящее время OpenAI Assistant использует несколько грубый подход к аварийному восстановлению, назначая каждому Pod отдельный экземпляр векторной базы данных и выделяя более 1/3 памяти в каждом Pod для системных нужд. Однако, учитывая, что разделения требуют только пользовательские данные, более тонкая стратегия предполагает объединение системных компонентов в общий пул. Такой подход повышает высокую доступность, позволяя этим компонентам функционировать независимо, не будучи привязанными к отдельным Pod.
Поддержка мультитенантности для разнообразной пользовательской базы
Архитектурная основа должна беспрепятственно обслуживать как многочисленных небольших пользователей, так и крупные компании с крупномасштабными данными. Поддержка мультитенантности на уровне приложения является фундаментальным требованием для Agent applications, особенно тех, у которых значительные пользовательские базы.
Следуя этой мысли, набросаем архитектурную диаграмму.
Оптимизированная архитектура функции retrieval OpenAI Assistants
Выделим некоторые ключевые изменения:
Разделение системных компонентов и компонентов запросов. Ранее совместно размещенные в каждом Pod, системные компоненты теперь объединены в независимый пул, что снижает их ресурсный след с 1/3 до менее чем 1/10 по сравнению с предыдущей схемой.
Повышенная гибкость компонентов запросов: Компоненты запросов теперь могут динамически распределяться на основе различного количества Pod, получая физическую изоляцию для независимого масштабирования. Контроль над радиусом воздействия тщательно управляется на уровне детализации компонентов запросов. Их упрощенная структура повышает надежность по сравнению с более сложными системными компонентами.
Гибридная архитектура памяти/диска: Введение гибридной архитектуры памяти/диска, где память загружает исключительно горячие данные, является еще одним важнейшим изменением. Это улучшение позволяет тому же объему памяти обслуживать в 5–10 раз больше исходного текста по сравнению с предыдущим решением.
Поддержка нескольких разделов для мультитенантности: Добавление поддержки нескольких разделов обеспечивает мультитенантность на уровне приложения. Каждому пользователю верхнего уровня теперь можно назначить независимый раздел данных, что предоставляет недорогое решение на уровне приложения. Физическая изоляция достигается путем назначения одного компонента запросов на группу пользователей.
При пересчете поддержки данных с этой архитектурой узел запросов с 32 GB памяти, дополненный дисковым пространством, теперь может эффективно поддерживать 320 GB векторов и индексов, что эквивалентно 128 GB исходного текста пользователя. Объединенные ресурсы системных компонентов, выделенные этим узлам запросов, составляют 3 GB и физически отделены от узлов запросов. В общей сложности 35 GB памяти могут вместить 128 GB пользовательских данных, что соответствует примерно 3,6 GB пользовательских данных на GB памяти. Напротив, предыдущий дизайн позволял 32 GB памяти поддерживать 8 GB пользовательских данных, в среднем 250 MB пользовательских данных на GB памяти. Это отражает впечатляющее 15-кратное повышение эффективности.
Обзор популярных векторных баз данных: Milvus, Chroma и Qdrant
Векторные базы данных играют ключевую роль в оптимизации архитектуры OpenAI Assistants, делая выбор наиболее надежного варианта первостепенно важным. Здесь мы подробно рассматриваем три известные векторные базы данных с открытым исходным кодом — Milvus, Chroma и Qdrant, — оценивая их сильные стороны и ограничения в улучшении архитектуры OpenAI Assistants.
Milvus
Плюсы: Milvus — наиболее зрелая векторная база данных с открытым исходным кодом, широко используемая в крупномасштабных распределенных системах. Среди примечательных возможностей — эффективное разделение системных компонентов и компонентов запросов, изоляция компонентов запросов с помощью функции Resource Group, гибридная архитектура памяти/диска и мультитенантность на уровне приложения, обеспечиваемая функциями RBAC и Partition.
Минусы: Несмотря на свои сильные стороны, Milvus не достигает полной изоляции аномалий посредством изоляции компонентов запросов на основе Resource Group. Кроме того, он вводит некоторые сторонние зависимости, такие как Etcd и MinIO, что приводит к повышенным затратам на развертывание и эксплуатацию.
Chroma
Плюсы: Chroma появляется как новый и удобный для пользователя проект, известный своей простотой. Он хорошо подходит для быстрого прототипирования и быстрой итерации AI-приложений, набирая популярность среди индивидуальных разработчиков.
Минусы: Chroma превосходен в сценариях меньшего масштаба, но не предназначен для крупномасштабных корпоративных приложений. Ему не хватает ключевых функций, таких как распределенное развертывание, разделение компонентов, гибридная архитектура памяти/диска и мультитенантность на уровне приложения.
Qdrant
Плюсы: Qdrant, как новичок, предлагает поддержку небольшомасштабного распределенного развертывания с упрощенным процессом настройки. Он также может похвастаться гибридной архитектурой памяти/диска, что соответствует современным требованиям к базам данных.
Минусы: В настоящее время Qdrant не поддерживает важнейшие функции, такие как разделение компонентов или мультитенантность на уровне приложения, что ограничивает его применимость в определенных сценариях использования.
При оценке этих векторных баз данных становится очевидно, что каждое решение имеет свои уникальные сильные стороны и компромиссы, поэтому выбор зависит от конкретных требований и приоритетов в контексте оптимизации архитектуры OpenAI Assistants.
Summary
В этом посте блога мы подробно рассмотрели тонкости OpenAI Assistants, изучив его ценообразование, архитектуру и потенциальные оптимизации для повышения экономической эффективности и расширения возможностей хранения. Ключевым выводом стало то, что стоимость инфраструктуры векторных баз данных существенно влияет на развертывание баз знаний и приложений Agent.
Проанализировав затраты и прибыль OpenAI, связанные с Assistants, мы выявили заметный дисбаланс: расходы превышают потенциальную выручку. Хотя это может быть оправдано на этапе пробного использования, при привлечении новых клиентов и расширении сообщества, необходим более устойчивый баланс.
В посте блога предлагается решение для оптимизации архитектуры, открывающее перспективу десятикратного снижения затрат для таких типов приложений по сравнению с существующими решениями. Подчеркивается ключевая роль векторных баз данных в этом процессе оптимизации, при этом Milvus выделяется как особенно подходящий вариант среди доступных альтернатив.
Тем не менее, признавая присущие существующим векторным базам данных ограничения, этот пост подчеркивает, что ни одно решение для векторных баз данных не может всесторонне решить все проблемы и удовлетворить каждое проектное требование для предстоящего развития инфраструктуры. Выбор векторных баз данных должен быть адаптирован к конкретным требованиям, чтобы эффективно справляться со сложностями оптимизации архитектуры OpenAI Assistants.
Читать далее
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
8 Latest RAG Advancements Every Developer Should Know
Explore eight advanced RAG variants that can solve real problems you might be facing: slow retrieval, poor context understanding, multimodal data handling, and resource optimization.