Как крупный индийский онлайн-ретейлер масштабировал сопоставление товаров с помощью Milvus
На 75% меньше использования памяти
Перенесли эмбеддинги из RAM в объектное хранилище, устранив память как узкое место при масштабировании.
В 6 раз быстрее время обработки
Сократили сопоставление каталогов с нескольких дней до нескольких часов при масштабном поиске.
Задержка ~200 мс
Обеспечил более высокую точность в масштабе при соблюдении строгих целевых показателей задержки.
Повышенная операционная гибкость
Независимое масштабирование узлов устраняет необходимость полной перестройки индекса при обновлениях.
О компании
Клиент — одна из крупнейших онлайн-платформ розничной торговли в Индии, которую часто называют «Amazon Индии»; она обслуживает аудиторию по всей стране в таких категориях, как электроника, мода, продукты питания и товары первой необходимости для дома. Помимо своего маркетплейса, ориентированного на потребителей, компания также управляет SaaS-подразделением, которое предоставляет комплексные commerce-решения для предприятий и онлайн-продавцов. Ключевым компонентом этого предложения является система ценовой аналитики, которая помогает ритейлерам сохранять конкурентоспособность на рынке, где цена остается одним из самых сильных факторов, влияющих на принятие решений покупателями.
Однако поддержка точного ценообразования в реальном времени на национальном масштабе создала серьезные инженерные вызовы. Команде необходимо было сопоставлять продукты в постоянно расширяющемся цифровом каталоге — выросшем с нескольких миллионов SKU до десятков миллионов — и ежедневно обновлять их по нескольким крупным конкурентам, у каждого из которых были собственные обширные товарные запасы. Этот взрывной рост перегрузил существующую архитектуру на основе ключевых слов и FAISS, увеличив инфраструктурные расходы и замедлив циклы обновления.
Чтобы устранить эти узкие места, команда перенесла свой пайплайн сопоставления продуктов в векторную базу данных Milvus. Благодаря дисковому индексированию и распределенной архитектуре Milvus они значительно сократили время обработки и снизили операционные затраты, создав более масштабируемую, устойчивую и высокопроизводительную систему для управления ценообразованием корпоративного уровня.
Задача: масштабирование сопоставления продуктов на корпоративном уровне
Платформа ценовой аналитики компании работает на трех основных модулях: конкурентная аналитика (отслеживание цен конкурентов с помощью скрейпинга и сопоставления продуктов), динамическое ценообразование (корректировки на основе правил с учетом рыночных сигналов) и аналитика ассортимента (выявление пробелов в каталоге ритейлера). По мере подключения к платформе новых корпоративных клиентов механизм сопоставления продуктов, лежащий в основе этих возможностей, начал демонстрировать признаки перегрузки.
Ритейлеры управляли более чем 20 миллионами SKU, обновляемыми ежедневно или даже ежечасно, при этом отслеживая 10 или более конкурентов. Каждый каталог конкурента добавлял еще 5 миллионов SKU для обхода и сравнения, создавая рабочую нагрузку, которая росла почти экспоненциально.
Помимо масштаба, сами неструктурированные данные были неоднородными: изображения продуктов с разным разрешением, описания, написанные в разных стилях, а также необходимость поддерживать как точные совпадения, так и варианты, «достаточно близкие» к ним.
Точность также была критически важна. Даже небольшой уровень ошибок мог негативно повлиять на рекомендации по ценообразованию, заставляя ритейлеров терять продажи, когда товары оценены слишком высоко, терять деньги, когда цены слишком низкие, или оставаться с запасами, которые не продаются, что напрямую снижало выручку и подрывало доверие ритейлеров к системе.
Оптимизация ресурсов представляла собой еще одно серьезное препятствие. Система должна была эффективно управлять вычислительными ресурсами, включая CPU, память и хранилище, для непрерывной обработки данных и выполнения запросов в масштабах крупного предприятия.
Устаревшая архитектура, построенная на односерверном in-memory индексе на базе FAISS, просто не была рассчитана на такой уровень роста данных. Эмбеддинги конкурентов хранились на локальном диске, а затем периодически загружались в память для поиска по сходству. Хотя при меньших объемах это работало, на масштабе такая схема перестала справляться. Использование памяти резко выросло — хранение около 20 миллионов 1 024-мерных эмбеддингов требовало почти 400 ГБ RAM, — что привело к скачку инфраструктурных затрат. Производительность также ухудшилась: выполнение некоторых сквозных задач обработки занимало до 12 дней. Для клиентов, ожидающих своевременной конкурентной аналитики, система явно достигла своих пределов.
Оценка путей масштабирования и выбор Milvus
Вертикальное масштабирование — переход на более крупные, требовательные к памяти ВМ. Хотя этот вариант мог временно удовлетворить требования к производительности, физические ограничения решения быстро проявились бы снова, что привело бы к значительному росту затрат. Очевидно, это было лишь временным решением.
Расширение их SQL-базы данных функциональностью векторного поиска. С точки зрения интеграции этот подход был привлекательным, но команда быстро осознала риски: перегрузка их основной SQL-базы данных могла замедлить как транзакционные операции, так и векторные запросы, подрывая надежность всей системы.
Внедрение специализированной векторной базы данных , разработанной для поиска по сходству в масштабе. Это оказалось наиболее перспективным вариантом. Команда провела обширные бенчмарки Milvus, Pinecone, Qdrant и Weaviate, тестируя скорость вставки, задержку запросов, точность фильтрации и гибкость развертывания. В этих оценках Milvus стал очевидным лидером.
Почему Milvus: ключевые факторы принятия решения
В ходе оценки Milvus оказался единственным решением, которое отвечало всем требованиям, поскольку он напрямую решал проблемы масштабирования и стоимости платформы. Ниже приведены ключевые факторы:
Распределенная архитектура Milvus позволяла выполнять горизонтальное масштабирование и эффективно использовать ресурсы, давая команде гибкость для обработки миллиардов эмбеддингов без избыточного выделения инфраструктуры. Кроме того, настраиваемая архитектура Milvus позволила инженерной команде оптимизировать систему под точные требования рабочих нагрузок их приложений.
Вторым отличительным фактором был DiskANN, дисковый алгоритм индексирования Milvus. Снижая требования к памяти до 75% по сравнению с методами в оперативной памяти, такими как HNSW, DiskANN сделал крупномасштабный поиск не только осуществимым, но и экономически эффективным. В сочетании с поддержкой объектного хранилища, такого как S3, это обеспечило платформе масштабируемую и доступную основу.
Наконец, возможности предварительной фильтрации Milvus идеально соответствовали стратегии оптимизации поиска команды, позволяя им сужать наборы кандидатов по категории, бренду или цене перед выполнением векторного поиска. Это значительно сократило пространство поиска, улучшив как производительность, так и точность.
Решение: создание сопоставления товаров в масштабе с помощью Milvus
После выбора Milvus инженерная команда клиента спроектировала новую архитектуру, оптимизированную как для масштаба, так и для точности.
Конвейер начинается с приема данных, при котором каталоги клиентов и данные конкурентов сканируются и сохраняются. Затем слой нормализации обрабатывает неструктурированные данные с ошибками, такие как несогласованные изображения и описания товаров, приводя их к стандартизированным форматам. Затем собственные модели машинного обучения команды, специально обученные на данных электронной коммерции, генерируют 1024-мерные векторы с 4-байтовыми числами с плавающей точкой, которые фиксируют ключевые атрибуты каждого товара. Эти эмбеддинги индексируются и хранятся в Milvus, где поиск по сходству сравнивает эмбеддинги товаров клиентов с каталогами конкурентов, используя косинусное сходство в многомерном пространстве.
Поисковый конвейер следует многоэтапному процессу. Он начинается с предварительной фильтрации на основе структурированных атрибутов, таких как категория, бренд и ценовой диапазон, сужая набор кандидатов. Затем Milvus выполняет векторный поиск по сходству в этом отфильтрованном подмножестве, после чего выполняются постобработка и оценка результатов. Наконец, фильтр на основе порогового значения формирует рекомендации, а к совпадениям с высокой степенью уверенности применяется ручная проверка. Такой многоуровневый подход обеспечивает баланс между автоматизацией и контролем, гарантируя как скорость, так и точность в корпоративном масштабе.
Внедрив Milvus, команда ускорила циклы сопоставления товаров, одновременно значительно снизив затраты на инфраструктуру. Что еще важнее, они создали перспективную основу, способную поддерживать корпоративных клиентов с огромными каталогами и крайне динамичной конкурентной средой.
Результаты: масштабируемое, экономичное и точное сопоставление товаров
Переход на Milvus изменил то, как платформа ценовой аналитики выполняет сопоставление товаров в корпоративном масштабе. То, что раньше ограничивалось пределами памяти, длительными циклами обработки и негибкими операциями, стало эффективным, точным и готовым масштабироваться вместе с ростом предприятия.
Снижение затрат на инфраструктуру: Предыдущая конфигурация FAISS требовала загрузки всех эмбеддингов в память, что делало масштабирование дорогим и непрактичным. Перейдя на Milvus, инженерная команда клиента сократила требования к памяти до 75%, перенеся хранение в бакеты S3 и GCP. То, что раньше было барьером по стоимости, теперь стало устойчивой основой для расширения.
Ускорение обработки в 6 раз: Крупные задачи сопоставления каталогов, которые раньше растягивались на 12 дней, теперь завершаются примерно за 2 дня при 20 млн поисковых запросов. Хотя процесс по-прежнему основан на пакетной обработке, это шестикратное улучшение гарантирует, что конкурентная аналитика остается достаточно актуальной, чтобы помогать принимать решения о ценообразовании в реальном времени.
Более высокая точность в масштабе: В ценообразовании точность не подлежит компромиссам. Milvus обеспечил более высокую точность, чем альтернативы, такие как HNSW, при этом соответствуя целевому показателю задержки команды в ~200 мс для пакетных запросов. Сочетая структурированные фильтры (категория, бренд, цена) с векторным поиском по сходству, команда минимизировала дорогостоящие несовпадения и укрепила доверие к своим рекомендациям.
Большая операционная гибкость: С Milvus команде больше не нужно выполнять полную перестройку индекса для обработки обновлений. Его распределенная архитектура позволяет независимо масштабировать узлы запросов, индексации и данных. Гибридная интеграция с MySQL дополнительно упростила рабочий процесс, сочетая структурированную фильтрацию с векторным поиском для максимальной эффективности.
Заключение
Для команды, стоящей за этой платформой, более качественное сопоставление товаров означало нечто большее, чем просто более быструю обработку — оно создало более прочную основу для всего их механизма ценообразования. Внедрив Milvus, они получили возможность обрабатывать огромные, неоднородные каталоги точно и с устойчивыми затратами. Используя DiskANN для индексирования, самостоятельно размещенную распределенную архитектуру для масштабирования и гибридный подход, интегрированный с существующими базами данных, команда построила систему, которая одновременно практична и устойчива.
Этот переход позволил им предоставлять надежные конкурентные инсайты и ценовые рекомендации, на которые корпоративные клиенты могут уверенно опираться. По мере роста каталогов электронной коммерции и усиления конкуренции этот опыт демонстрирует, что векторные базы данных предлагают практичный подход к достижению как масштаба, так и точности — качеств, которые теперь необходимы для сохранения конкурентоспособности на быстро развивающихся рынках.
- О компании
- Задача: масштабирование сопоставления продуктов на корпоративном уровне
- Оценка путей масштабирования и выбор Milvus
- Решение: создание сопоставления товаров в масштабе с помощью Milvus
- Результаты: масштабируемое, экономичное и точное сопоставление товаров
- Заключение
Контент
Пример использования
Отрасль
Электронная коммерция