Від хаосу до ясності: як штучний інтелект трансформує каталоги електронної комерції

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

Як Full-Stack інженер у Zoro, я щодня стикався з цією проблемою: як навести порядок у понад 3 мільйонах SKU, кожен з яких має десятки атрибутів? Відповідь полягала не у чорній коробці AI, а у розумній гібридній системі, яка поєднує можливості LLM з чіткими бізнес-правилами та механізмами ручного контролю.

Проблема у великому масштабі

Зовні атрибутна неконсистентність здається нешкідливою. Візьмемо розміри: “XL”, “Small”, “12cm”, “Large”, “M”, “S” – все означає одне й те саме, але нічого не стандартизовано. З кольорами ситуація схожа: “RAL 3020”, “Crimson”, “Red”, “Dark Red” – частина стандартів кольорів (RAL 3020 — стандартизований червоний), частина — фантазійні назви.

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

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

Стратегічний підхід: гібридний AI з правилами

Моя мета не була у загадковій системі AI, що творить чорну магію. Я хотів створити систему, яка:

• Пояснювана — розуміє, чому прийнято рішення
• Передбачувана — без несподіваних збоїв або аномалій
• Масштабована — для мільйонів атрибутів
• Залишається керованою людьми — бізнес-команди можуть втручатися

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

Чому офлайн-обробка замість реального часу?

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

Реальні пайплайни спричиняли б:

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

Замість цього офлайн-завдання забезпечували:

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

Розділення систем для клієнтів і обробки даних — обов’язкове при роботі з такою кількістю даних.

Обробна конвеєрна система

Процес проходив у кілька етапів:

Етап 1: очищення даних

Перед застосуванням AI дані проходили попередню обробку:

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

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

Етап 2: AI-логіка з контекстом

LLM не просто сортував за алфавітом. Він думав над значеннями. Сервіс отримував:

• очищені атрибутні значення
• breadcrumb категорії (наприклад, “Електроінструменти > Дриль”)
• метадані атрибутів

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

• що “Напруга” у електроінструментах має сортуватися числовим порядком
• що “Розмір” слідує відомій прогресії (S, M, L, XL)
• що “Колір” частково відповідає стандартам RAL
• що “Матеріал” має семантичні зв’язки (Сталь > Нержавіюча сталь > Вуглецева сталь)

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

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

Етап 3: Детерміновані резерви

Не кожен атрибут потребує AI. Багато краще обробляти за допомогою чіткої логіки:

• числові діапазони (2см, 5см, 12см, 20см)
• значення з одиницями вимірювання
• категорійні колекції

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

Етап 4: контроль торговців

Критичні для бізнесу атрибути потребували ручного контролю. Тому кожна категорія могла мати позначки:

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

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

Збереження та системи-послідовники

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

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

Після цього дані йшли у два напрямки:

• Elasticsearch: для пошуку за ключовими словами, де чисті атрибути формують фільтри
• Vespa: для семантичного та векторного пошуку, де консистентність покращує ранжування

Фільтри тепер з’являються у логічному порядку. Сторінки товарів показують послідовні характеристики. Пошукові системи ранжують товари точніше. Клієнти навігають по категоріях без розчарувань.

Конкретні результати

Конвеєр перетворював хаотичні сирі дані у чисті, зручні для використання результати:

Ця трансформація була послідовною для понад 3 мільйонів SKU.

Наслідки

Результати виходили за межі технічної сфери:

• Консистентний порядок атрибутів у всьому каталозі
• Передбачувана поведінка для числових значень через детерміновані резерви
• Бізнес-контроль через ручне тегування
• Чисті сторінки товарів з інтуїтивними фільтрами
• Покращена релевантність пошуку
• Збільшена довіра і конверсія

Це був не лише технічний, а й бізнесовий успіх.

Основні висновки

• Гібридні конвеєри переважають чистий AI у масштабах. Обмеження — це не перешкода, а особливість.
• Контекст — все: LLM з категорійною інформацією і метаданими працює в 10 разів краще.
• Офлайн-обробка — обов’язкова: при такій кількості даних потрібна ефективність пакетної обробки і стійкість до помилок.
• Ручне керування створює довіру: команди приймають AI, коли можуть його контролювати.
• Гігієна даних — основа: очищені вхідні дані — надійні вихідні. Завжди.

Висновок

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

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