Масовий електронний комерційний бізнес: Як інженер-програміст сортує мільйони хаотичних атрибутів продукту

Більшість дебатів щодо масштабування електронної комерції зосереджені навколо сексуальних тем: розподілені пошукові системи, живе управління запасами, алгоритми рекомендацій. Але за цим ховається проблема, яка є тихішою, але більш настирливою: управління атрибутними значеннями. Це технічний шум, який присутній у кожному великому онлайн-магазині.

Тихіша проблема: чому атрибутні значення ускладнюють усе

Атрибути продукту є фундаментальними для досвіду клієнта. Вони рухають фільтри, порівняння та пошукове ранжування. У теорії це звучить просто. У реальності ж: сирі значення хаотичні.

Просте значення може виглядати так: “XL”, “Small”, “12cm”, “Large”, “M”, “S”. Кольори? “RAL 3020”, “Crimson”, “Red”, “Dark Red”. Матеріал? “Steel”, “Carbon Steel”, “Stainless”, “Stainless Steel”.

Розглядаючи окремо, ці непослідовності здаються нешкідливими. Але помножте це на понад 3 мільйони SKU, кожен із десятками атрибутів — проблема стає системною. Фільтри поводяться непередбачувано. Пошукові системи втрачають релевантність. Клієнти відчувають повільніше, розчаровуючі пошуки. А в бекенді члени команд втомлюються від ручного очищення даних.

Інженер-програміст у Zoro стикався саме з цією проблемою: проблемою, яку легко пропустити, але яка впливала на кожну сторінку продукту.

Шлях до розумної автоматизації без втрати контролю

Перше принципове правило було ясним: жодних чорних ящиків з ШІ. Такі системи важко довіряти, налагоджувати або масштабувати.

Замість цього була розроблена гібридна конвеєрна лінія, яка:

• залишається пояснюваною
• працює передбачувано
• справді масштабується
• керується людьми

Результат поєднав контекстне мислення сучасних мовних моделей із жорсткими правилами та контролями. ШІ з керівними рамками, а не поза контролем.

Огляд архітектури: як це працює разом

Уся обробка виконується у фонових офлайн-завданнях, а не в реальному часі. Це не був компроміс — це було архітектурно необхідно.

Обробка в реальному часі може здаватися привабливою, але веде до:

• непередбачуваної затримки
• крихких залежностей
• дорогих піків обчислень
• операційної крихкості

Офлайн-обробка дозволяє навпаки:

• високий пропуск: обробляти мільйони даних без впливу на живу систему
• стійкість: помилки ніколи не впливають на клієнтський трафік
• контроль витрат: планувати обчислення у менш навантажені часи
• ізоляція: затримка мовних моделей ніколи не впливає на сторінки продуктів
• послідовність: оновлення атомарні та передбачувані

Архітектура працює так:

1. Дані продукту надходять із PIM-системи
2. Завдання екстракції витягує сирі значення та контекст
3. Це надходить до сервісу AI-сортування
4. Оновлені документи зберігаються у MongoDB
5. Вихідна синхронізація оновлює початкову систему
6. Elasticsearch і Vespa синхронізують відсортовані дані
7. API з’єднують усе з клієнтським інтерфейсом

Чотири шари рішення

Шар 1: підготовка даних

Перед застосуванням інтелекту відбувався чіткий етап попередньої обробки. Вилучення пробілів. Дедуплікація значень. Контекстуалізація категорійних breadcrumb у структуровані рядки. Видалення порожніх записів.

Це може здаватися базовим, але значно покращувало продуктивність ШІ. Непотрібне — видаляємо, і навпаки. У цьому масштабі дрібні помилки можуть згодом перерости у великі проблеми.

Шар 2: розумне сортування з контекстом

Модель мовлення була не просто інструментом сортування. Вона думала про значення.

Сервіс отримував:

• очищені атрибутні значення
• метадані категорій
• визначення атрибутів

З цим контекстом модель могла зрозуміти:

• що “напряження” у електроінструментах має бути числовим
• що “розмір” у одязі слідує відомій прогресії
• що “колір” можливо відповідає стандартам RAL
• що “матеріал” має семантичні зв’язки

Модель повертала:

• впорядковані значення у логічному порядку
• уточнені імена атрибутів
• рішення: детерміноване або контекстне сортування

Шар 3: детерміновані резерви

Не кожен атрибут потребує інтелекту. Числові діапазони, значення з одиницями та прості множини виграють від:

• швидшої обробки
• передбачуваного результату
• нижчих витрат
• відсутності неоднозначності

Конвеєр автоматично розпізнавав ці випадки і використовував детерміновану логіку. Це зберігало ефективність системи і уникало зайвих викликів LLM.

Шар 4: людське перезаписування

Кожна категорія могла бути позначена як:

• LLM_SORT: модель визначає порядок
• MANUAL_SORT: люди задають порядок

Ця двовекторна система дозволяла людям приймати остаточні рішення, а інтелекту — виконувати більшу частину роботи. Це також будувало довіру — продавці могли будь-коли перезаписати модель.

Від хаосу до ясності: практичні результати

Конвеєр перетворював хаотичні сирі дані:

Ці приклади демонструють, як поєднується розуміння контексту з чіткими правилами.

Збереження та контроль у всій ланцюжку

Усі результати зберігалися безпосередньо у MongoDB для продуктів. MongoDB став єдиним джерелом для:

• відсортованих атрибутних значень
• уточнених імен атрибутів
• тегів сортування за категоріями
• порядків сортування для конкретних продуктів

Це полегшувало перевірки, перезаписи, повторну обробку категорій і синхронізацію з іншими системами.

Після сортування значення потрапляли до:

• Elasticsearch для пошуку за ключовими словами
• Vespa для семантичного та векторного пошуку

Це забезпечувало логічне відображення фільтрів, послідовність атрибутів на сторінках і точніше ранжування продуктів пошуковими системами.

Чому не використовувати просто реальний час?

Обробка у реальному часі означала б:

• непередбачувану затримку для живих запитів
• вищі обчислювальні витрати для миттєвих результатів
• крихкі залежності між системами
• операційну складність і потенційні помилки при високому трафіку

Офлайн-завдання пропонували:

• ефективність при обробці мільйонів продуктів
• асинхронні виклики LLM без впливу на живу систему
• надійну логіку повторів
• можливість людської перевірки
• передбачувані обчислювальні результати

Компромісом стала невелика затримка між отриманням даних і їх відображенням. Але перевага — послідовність у масштабі, що цінують клієнти набагато більше.

Вимірювані результати

Рішення забезпечило:

• послідовне сортування атрибутів понад 3 мільйонів SKU
• передбачуваний числовий порядок через детерміновані резерви
• контроль бізнесу через ручне тегування
• чистіші сторінки продуктів і інтуїтивніші фільтри
• покращену релевантність і ранжування пошуку
• підвищену довіру клієнтів і кращі конверсії

Це був не лише технічний успіх — це був перемога для досвіду користувача і бізнес-результатів.

Основні висновки для інженерів-програмістів у сфері електронної комерції

• Гібридні конвеєри перевершують чистий ШІ у масштабах. Інтелект потребує керівних рамок.
• Контекст значно підвищує точність мовних моделей.
• Офлайн-завдання критичні для пропускної здатності і стійкості.
• Механізми людського перезапису формують довіру і прийняття.
• Чисті вхідні дані — основа надійних виходів.

Висновок

Сортування атрибутних значень здається простим. Але коли йдеться про мільйони продуктів, це стає справжнім викликом.

Завдяки поєднанню інтелекту мовних моделей із чіткими правилами, розумінням контексту і людським контролем, було перетворено складну, приховану проблему у чисту, масштабовану систему.

Це нагадує, що деякі з найбільших успіхів приходять із вирішення нудних проблем — тих, що легко пропустити, але які з’являються на кожній сторінці продукту.