Векторные базы данных и эмбеддинги: расходы и бюджет

Модель эмбеддингов, такая как модели OpenAI для эмбеддингов текста, Google Gemini Embeddings, Cohere Embed или открытые модели, например, с Hugging Face, превращает контент в список чисел. Контент с похожим смыслом получает похожие числа. «Водонепроницаемые походные ботинки» и «ботинки для прогулок под дождем» оказываются близко друг к другу, даже если у них мало общих слов.

Векторная база данных хранит эти списки и быстро находит наиболее близкие. Варианты включают управляемые сервисы, такие как Pinecone, Weaviate Cloud и Qdrant Cloud, расширения вроде pgvector для PostgreSQL, а также векторный поиск, встроенный в существующие платформы, такие как Elasticsearch, OpenSearch, MongoDB Atlas или Vertex AI.

Планируйте бюджет для каждой из этих статей отдельно, так как они масштабируются по-разному.

• Создание эмбеддингов: единовременные затраты на создание эмбеддингов для существующего контента, плюс текущие расходы на новые и измененные элементы. Обычно провайдеры API берут плату за токен.
• Хранение: зависит от количества векторов и их размерности. Эмбеддинги большего размера стоят дороже при хранении и поиске.
• Запросы: управляемые сервисы взимают плату за единицы чтения, вычислительную мощность или ежемесячный тариф.
• Вызовы языковых моделей: если векторы питают RAG-ассистента, каждый ответ также вызывает генеративную модель, что часто является самой большой статьей расходов.
• Инженерия и обслуживание: создание конвейера, переиндексация, мониторинг качества и обновление при смене моделей.

Цены часто меняются, поэтому стройте свою оценку на основе текущих страниц с ценами, а не на цифрах из статьи, включая эту.

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

Более крупные расходы — это объем запросов при масштабировании, вызовы генеративных моделей и время сотрудников. RAG-чат-бот, отвечающий на тысячи вопросов в день, может стоить дороже в плане вызовов моделей, чем в плане хранения векторов. А инженерные часы на очистку контента, проверку релевантности и обработку граничных случаев часто превышают все расходы на инфраструктуру в первый год.

Несколько решений имеют существенное значение.

Выберите правильный размер эмбеддинга

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

Используйте то, что у вас уже есть

Если ваш стек уже включает PostgreSQL, Elasticsearch или MongoDB, их векторные функции могут покрыть ваши потребности без привлечения другого поставщика.

Создавайте эмбеддинги только для важного

Пропускайте шаблонный контент, такой как текст навигации, футеры и дубликаты страниц. Более чистые входные данные дают более дешевое хранение и лучшие результаты.

Кэшируйте частые ответы

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

Доход зависит от варианта использования, поэтому определите метрику до начала разработки.

• Поиск по сайту: конверсия сессий, использующих поиск, доля поисков с нулевым результатом и доход на поисковую сессию.
• Рекомендации товаров: CTR и конверсия в корзину в блоках рекомендаций по сравнению с предыдущей логикой на основе правил.
• Ассистент поддержки: доля вопросов, решенных без тикета, и изменение объема тикетов по охваченным темам.
• Поиск по внутренней базе знаний: время на поиск документов, измеренное в ходе короткого теста «до и после» с сотрудниками.
• Операции с контентом: сэкономленное время на поиск связанных статей для внутренней перелинковки или обнаружения дубликатов.

По возможности запускайте старую и новую системы параллельно, например, через A/B-тест в поиске по сайту, чтобы разница была атрибутируемой.

Самая распространенная — начинать разработку до измерения проблемы. Команды настраивают векторную базу данных, потому что это модно, а затем обнаруживают, что их проблема с поиском заключалась в отсутствии списка синонимов.

Другая ошибка — пересоздавать эмбеддинги каждый раз при изменении контента. Конвейер, который создает эмбеддинги только для новых или отредактированных элементов, экономит деньги и время. Третья — игнорирование оценки; без тестового набора запросов и ожидаемых результатов никто не знает, достаточно ли хороша более дешевая модель или меньшая размерность, поэтому команды переплачивают для подстраховки.

Четкая структура помогает при представлении проекта финансовому отделу. Разделите оценку на расходы на настройку и текущие расходы. Настройка включает очистку контента, первый запуск создания эмбеддингов, построение конвейера и набор для оценки. Текущие расходы покрывают новые эмбеддинги, хранение векторов и запросы, вызовы моделей, если задействован ассистент, мониторинг и ежемесячный бюджет на проверки качества.

Назначьте дату пересмотра через три месяца после запуска. К тому времени у вас будут реальные объемы запросов и данные о результатах, и текущую оценку можно будет заменить фактическими цифрами.