Архітектура електронної комерції в GenAI: API, дані та JSON

У цій статті ви знайдете аналіз трансформації архітектури електронної комерції в бік систем, призначених для інтелектуальних агентів, що вимагає відходу від структур, побудованих виключно для фронтенду. Ви дізнаєтеся, як створювати "готові до ШІ" дані про товари та JSON-схеми, які мінімізують ризик галюцинацій моделей, і як оптимізувати API для RAG-систем. Ви також дізнаєтеся про роль проміжного програмного забезпечення Semly, яке стандартизує дані і дозволяє швидко впроваджувати функції штучного інтелекту, контролюючи при цьому витрати і безпеку.

Навіщо змінювати архітектуру інтернет-магазину під генеративний ШІ?

Генеративний ШІ змушує змінити уявлення про бекенд електронної комерції з підходу "API для фронт-енду" на підхід "API для інтелектуальних агентів".

Нові типи споживачів АФІ

Ваш API буде використовуватися не тільки сторінкою вашого магазину або мобільним додатком, але й..:

• товарні чат-боти (RAG, агенти штучного інтелекту),

• рівень рекомендацій та персоналізації (Магістр права як оркестрант),

• конвеєри генерації контенту (асинхронні ШІ-йоби),

• аналітичні інструменти з мовним шаром.

Роль Семлі в цих змінах

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

Які вимоги генеративний ШІ висуває до архітектури електронної комерції?

Ключові кейси використання ШІ проти потреб у даних

• Товарний чат-бот: Йому потрібні повні дані про продукт, його доступність, ціни та контекст користувача.
• Семантична пошукова система: Для цього потрібні докладні описи та пошуковий API, який дозволяє фільтрувати та сортувати.
• Рекомендації від LLM: Їм потрібні структуровані поведінкові події (перегляд, додавання в кошик, покупка).

Типи даних, необхідних для якісного ШІ

• Дані про продукт (Ідентифікація, тексти, технічні атрибути, маркетинг, SEO, мультимедіа, відносини).

• Дані про подію (Стандарт GA4: view_item, add_to_cart, begin_checkout, purchase).

• Контекстні дані (канал входу, місцезнаходження, бізнес-обмеження).

Розробка API магазину під генеративний ШІ

REST vs GraphQL в контексті штучного інтелекту

"Готові до ШІ" архітектури часто поєднують обидва підходи:

• ВІДПОЧИНОК: Ідеально підходить для експорту каталогів і пакетного завантаження (ETL у векторний індекс).
• GraphQL: Дозволяє завантажити саме ті поля, які вам потрібні в промті на вимогу.

Приклад відповіді GET /api/products/{id} з урахуванням ШІ:

{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Бігова взуття синя",
"brand": {"@type": "Brand", "name": "Acme Sports"},
"offers": {
"@type": "Offer",
"priceCurrency": "EUR",
"price": "69.51"
}
}

Дані про продукти в генеративному ШІ

Стандартизація та таксономії

Для того, щоб ШІ робив осмислені висновки, дані повинні бути узгодженими. Варто надихатися стандартами schema.org/Product і специфікацією Google Merchant Center.

Приклад моделі в дусі schema.org:

{
"cart_id": "cart-123",
"items": [{
"product_id": "TRAIL-001",
"quantity": 1,
"unit_price": 92.76
}],
"total": 92.76,
"currency": "EUR"
}

JSON-структури для обміну даними з AI-моделями

JSON кошика та сесії користувача

Кошик для покупок є ключовим контекстом для чат-бота:

{
"id": "product-uuid",
"sku": "TRAIL-001",
"slug": "кросівки-trail-running",
"title": "Кросівки Trail Running",
"brand": "Acme Sports",
"attributes": {
"terrain": "trail",
"cushioning": "високий",
"weight_g": 280
},
"price": {"amount": 92.76, "currency": "EUR"},
"availability": "в_наявності"
}

JSON подій користувача

За зразком GA4, прийняти загальний формат:

{
"event_type": "переглянути_товар",
"occurred_at": "2026-01-12T10:05:00Z",
"ecommerce": {
"items": [{"item_id": "TRAIL-001", "price": 92.76}],
"currency": "EUR"
}
}

Рівень історії подій та поведінки користувачів

Якщо ви збираєте події за допомогою GA4, Segment або Snowplow, у вас вже є база. Для ШІ події використовуються для персоналізації відповідей і виявлення намірів.

Інтеграція з генеративним ШІ на практиці

Архітектурні візерунки

• Мікросервісний ШІ: Відповідає за інтеграцію з LLM та підготовку підказок.

• Проміжне програмне забезпечення / BFF: Фронтенд взаємодіє з BFF, який об'єднує дані з API магазину та ШІ.

• ШІ-працівники, керовані подіями: Асинхронна генерація описів після події "ProductCreated".

Безпека та витрати

Як Semly підтримує розробників?

Semly вирішує проблеми інтеграції шляхом надання послуг:

1. Стандартизація даних: Зіставлення структур (Shopify, Magento) з моделлю, готовою до ШІ.
2. Готовий шар API: Кінцеві точки для чат-бота та рекомендації.
3. Контроль якості: Механізми кешування та моніторингу запитів.

Часті запитання для розробників

Як розпочати впровадження на існуючій SaaS-платформі (наприклад, Shopify, Shopware)?

Існуючі API (REST або GraphQL) слід використовувати для ефективного експорту каталогу продуктів і потокової трансляції подій. Ключовим кроком є виявлення прогалин у даних про продукти, таких як погані описи або відсутні технічні атрибути, і планування їх заповнення. Замість того, щоб безпосередньо пов'язувати фронтенд з моделями LLM, рекомендується додати проміжний рівень, такий як Semly

Що робити у випадку неповних або суперечливих даних?

ШІ може "заповнити прогалини" в природній мові, але на нього не можна покладатися в таких фактах, як технічні параметри або сумісність. Найбезпечніша стратегія - використовувати ШІ лише для збагачення описів на основі вже перевірених технічних даних. У самих підказках моделі має бути чітко заборонено "вгадувати" - вона повинна відкрито повідомляти про брак інформації, якщо не знаходить її в джерелі. Паралельно необхідно інвестувати в якість даних у джерелі, наприклад, у системи PIM.

Чи потрібне окреме сховище даних та сховище функцій для початку роботи?

На початковому етапі це не обов'язково - ви можете почати з простого експорту каталогу та подій безпосередньо до Semly або сервісу штучного інтелекту на ваш вибір. Однак сховище даних і сховище функцій стають критично важливими на етапі масштабування рішення, коли виникає потреба об'єднати дані з декількох джерел, створити розширені гібридні рекомендації або обслуговувати кілька брендів і ринків одночасно.

Як підійти до міграції даних про товари в нову структуру JSON?

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

Підсумок

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

Ось ключові стовпи сучасної архітектури електронної комерції:

• Семантичні API (REST та GraphQL): Основою є відхід від інтерфейсів, призначених виключно для фронтенду. Архітектура повинна пропонувати кінцеві точки, які надають моделям LLM повний бізнес-контекст без зайвого інформаційного шуму. GraphQL стає тут ключовим інструментом, дозволяючи отримувати точні набори полів (наприклад, тільки технічні атрибути і доступність) безпосередньо в запиті.
• Багаті та стандартизовані дані про товари: ШІ-моделі найкраще працюють зі структурованими даними, які відповідають стандартам, наприклад, schema.org або Google Merchant Center. Повна модель продукту повинна включати не лише маркетингові описи, але й, перш за все, типізовані технічні характеристики (наприклад, вага, потужність, сумісність) та перелік конкретних переваг і способів використання.
• Структуровані події (Events): Дані про поведінку користувачів (перегляд, додавання до кошика, купівля) перестають бути просто необробленими журналами для аналітики і стають паливом для персоналізації. Ці події в поєднанні з історією сесій дозволяють штучному інтелекту точно визначати наміри клієнтів щодо купівлі.

Джерела:

• commercetools HTTP API - Продукти
• Shopify Storefront API - Об'єкт продукту
• Google Merchant Center - Google Merchant Center - Специфікація даних продукту
• Google Analytics 4 - Вимірювання електронної комерції
• Vertex AI Пошук для комерції - Події користувача
• GA4 - Рекомендовані події для роздрібної торгівлі/комерції
• Снігоочисник - Посібник з міграції GA (діаграми подій)

Поділитися:

Копіювати посилання