LLM у commerce-бекендах: реальні кейси, патерни інтеграції та типові помилки команд

LLM почали з'являтися в нашій клієнтській роботі наприкінці 2023 року переважно як експерименти з генерацією контенту. До середини 2025-го ми побудували продакшн-інтеграції на дюжині commerce-стеків — генерація описів товарів у масштабі, витягування структурованих атрибутів із PDF постачальників, класифікація звернень у підтримку до потрапляння до людини. Що стало зрозумілим з цього досвіду: хайп і реальність знаходяться в дуже різних місцях. LLM справді корисні для певного класу завдань у комерції — і активно шкідливі для іншого класу. Розрив між ними — це місце, де більшість команд роблять дорогі помилки.

Де LLM реально корисні в комерції

Корисна зона — приблизно така: завдання, пов'язані з розумінням або генерацією природної мови, де ставки на виході помірні, де людина може перевірити граничні випадки, і де альтернатива — або ручна праця, або відсутність можливості взагалі. Генерація описів товарів, витягування атрибутів із неструктурованих даних постачальників, класифікація намірів у зверненнях підтримки, тегування каталогу — все це сюди.

Зона, де LLM створюють проблеми: все, що вимагає строгої числової коректності (розрахунок цін, прогноз інвентарю, валідація знижок), все критично важливе або пов'язане з шахрайством, і все, де впевнена неправильна відповідь гірша, ніж жодна. Ми бачили команди, що намагалися використовувати GPT-4 для генерації правил ціноутворення. Він видає граматично бездоганний вивід, який арифметично неправильний у 5% випадків — що в продакшні означає покупки товарів за цінами нижче собівартості.

Рішення в реальному часі, що приймаються per-request — "показувати чи цьому користувачу цей товар за цією ціною?" — майже ніколи не підходять для інференсу LLM. Одна лише затримка це виключає. Виявлення шахрайства, право на повернення, розрахунок доставки — це детерміновані завдання або завдання ML-класифікації, а не завдання розуміння мови. LLM впевнено дасть вам відповідь; надійну відповідь — не обов'язково.

Контент каталогу в масштабі

Це те, над чим ми працювали найбільше. Каталог із 50 000 SKU, імпортований від постачальника, зазвичай приходить із назвами у вигляді артикулів, описами ламаною мовою, відсутніми атрибутами і без жодного SEO. Писати ці описи вручну економічно нежиттєздатно. LLM роблять це реалізованим — але пайплайн навколо моделі важливіший за саму модель.

Патерн, що працює: витягніть усі наявні структуровані дані (категорія, бренд, розміри, матеріали, атрибути), складіть промпт із зазначенням тону, довжини, обов'язкових елементів і формату виводу (завжди JSON для структурних полів, ніколи вільний HTML), запустіть модель, провалідуйте вивід за схемою, направте на ручну перевірку виводи з низькою впевненістю. Для клієнта в сегменті товарів для дому ми запускаємо це на ~2 000 нових SKU на тиждень. Модель генерує чернетки в батч-джобі вночі; один редактор зранку перевіряє позначені ~5% із порушеннями схеми, помилковими специфікаціями або дрейфом тону.

Кілька речей, що роблять це робочим: few-shot приклади в промпті важливіші, ніж вибір моделі. Три добре підібрані приклади (дані товару → хороший опис) піднімають якість виводу значно вище ретельно налаштованих системних промптів самотужки. Примусовий формат виводу за схемою — обов'язковий: якщо дозволити моделі повертати вільний текст, рано чи пізно отримаєте непарсований вивід у продакшні. А для висококомерційних категорій (предмети розкоші, професійний інструмент) тримайте людину в контурі на першому проходженні. Ціна галюцинованої специфікації на об'єктив за 3 000 доларів дуже відрізняється від ціни помилки на чохол за 15 доларів.

RAG для бази знань комерції

Коли RAG краще за файнтюнінг

RAG — підключення мовної моделі до пошукової бази знань під час інференсу — майже завжди правильний вибір для commerce-застосунків замість файнтюнінгу, і причина практична: ваш каталог товарів, політики підтримки і правила повернення постійно змінюються. Файнтюновані моделі статичні. Перенавчати модель кожного разу, коли змінюється термін повернення — не той пайплайн, який хочеться підтримувати.

Ми будували RAG-пайплайни для клієнтських чат-асистентів, що паралельно тягнуть із трьох джерел: каталог товарів (для специфічних питань про товари), документація підтримки (для питань про політики) і історія замовлень (для питань за конкретним акаунтом). Крок ретривалу важливий: потрібен семантичний пошук по базі знань (що повертає нас до векторних ембедингів), а не keyword-пошук — користувачі формулюють питання зовсім не так, як написані політики.

Що RAG не вирішує

RAG не усуває галюцинації про факти, яких немає у витягнутому контексті. Якщо у витягнутих фрагментах немає відповіді, здатна LLM часто вигадає правдоподібну. Рішення: налаштувати модель відповідати "не знаю" або "не знайшов цього в нашій документації" при низькій впевненості — що вимагає включення явних негативних прикладів у промпт і тестування прогалин у покритті бази знань. Будувати це довше, ніж здається. Ми витрачаємо більше часу на якість ретривалу і поведінку "не знаю", ніж на саму генерацію.

Автоматизація підтримки клієнтів

Класифікація намірів — визначення того, чи стосується вхідне звернення повернення, затримки доставки, проблеми з оплатою чи питання про товар — завдання, яке LLM вирішують добре, і воно реально цінне. Неправильна маршрутизація тікета — це прихована вартість, яку більшість операційних команд відчувають, але не можуть легко порахувати. Ми бачили точність класифікації вище 94% на датасетах звернень commerce із добре налаштованим LLM, проти 78-82% у колишніх підходів на основі патерн-матчингу.

Логіка передачі важливіша, ніж класифікація. Потрібні чіткі правила: які наміри йдуть в автоматизацію, які вимагають людини, які ескалюються негайно. Повернення з пошкодженим товаром — завжди до людини. Суперечки і підозра на шахрайство — завжди до спеціалізованої команди. Простий "де моє замовлення" по вже відправленому замовленню — повністю автоматизується. Змішення цих правил коштує дорожче, ніж не автоматизувати взагалі.

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

Патерни інтеграції: синхронний, асинхронний, стримінг

Синхронні виклики LLM доречні у вузькому наборі кейсів: real-time відповіді користувачу, де він чекає і операцію не можна батчувати. Чат підтримки, віджети питань про товар, розширення пошукового запиту. Для всього іншого — генерація контенту, збагачення каталогу, масова класифікація — асинхронні пайплайни правильний патерн. Публікуєте завдання в чергу, воркер бере його, викликає API, записує результат, позначає завдання виконаним. Це розв'язує ваш веб-шар із затримкою LLM API і дозволяє керувати пропускною здатністю.

Обмеження швидкості і логіка повторних спроб заслуговують більше уваги, ніж зазвичай отримують. LLM API мають ліміти по токенах за хвилину і запитах за хвилину. При масштабі ви їх досягнете. Будуйте експоненційний backoff із jitter у клієнт з першого дня, а не заднім числом. Відстежуйте споживання токенів за типом завдання, щоб передбачати витрати і ставити circuit breakers до того, як аварійний retry-цикл спустошить бюджет. Ми бачили несподіваний рахунок у $8 000 через нічний retry-цикл без обмеження.

Стримінг відповідей — коли API повертає токени в міру генерації, а не чекає повного завершення — цінний для чат-інтерфейсів, де хочеться, щоб UI виглядав чуйно. Реалізувати правильно непросто: потрібно обробляти неповний JSON (якщо вивід структурований), обриви з'єднання і backpressure від клієнта. Для стримінгу з API OpenAI або Anthropic в браузер server-sent events (SSE) — найпростіший транспорт. Не використовуйте WebSockets для цього, якщо їх ще немає в стеку; накладні витрати того не варті.

Промпт-інжиніринг для структурованих commerce-виводів

Структурований вивід — основна вимога для більшості commerce-кейсів. Не можна використовувати вільний текст там, де пайплайн очікує JSON-об'єкт із конкретними полями. Підходи, на яких ми зупинилися: JSON-режим (OpenAI, Anthropic підтримують примусовий JSON по-різному), function calling / tool use (надійніше за звичайний JSON-режим для складних схем) і валідація схеми на виводі з повтором при невдачі.

Few-shot приклади в промпті надійніші для консистентності, ніж складні системні промпти. Включіть три-п'ять прикладів, що покривають граничні випадки, які важливі: короткі описи, довгі описи, товари з нестандартними атрибутами, товари з відсутніми даними. Модель вчиться патерну з прикладів краще, ніж з інструкцій. Коли працюєте зі схемою з необов'язковими полями, показуйте приклади, де ці поля null, а не лише заповненими.

Оновлення моделей, що ламають промпти — реальна операційна проблема. OpenAI і Anthropic випускають оновлення, що можуть тонко змінювати поведінку виводу, вподобання форматування і суворість дотримання інструкцій. Ми версіонуємо промпти так само, як код, ведемо регресійний тестовий набір (вхід, очікуваний формат виводу) і запускаємо його по кожній версії моделі перед викаткою в продакшн. Це здається накладними витратами — до тих пір, поки оновлення моделі не починає вставляти markdown-форматування у ваші JSON-рядки.

Специфічні для комерції режими відмови

Галюциновані технічні характеристики — найнебезпечніший режим відмови. LLM, генеруючи опис товару для карти пам'яті 32 ГБ, може впевнено написати "64 ГБ ємності", якщо в навчальних даних багато 64-гігабайтних карт у схожих категоріях. При малому масштабі це ловить людина. При 50 000 SKU на місяць потрібна автоматична валідація: витягуйте ключові числові характеристики зі згенерованого контенту і звіряйте з вихідними даними. Будь-яке розходження запускає прапор ручної перевірки. Це не опціонально, якщо вивід потрапляє на сторінку товару.

Непослідовні значення атрибутів по всьому каталогу — тонший момент. Якщо генеруєте описи батчами з часом, і поведінка моделі змінюється між батчами (через оновлення моделі, дрейф промптів або різні налаштування температури), ви отримуєте атрибути, що використовують різну термінологію для одного поняття: "можна прати в машині" в одному батчі, "безпечно для машинного прання" в іншому, "допускає машинне прання" в третьому. Це ламає фасетну фільтрацію і забруднює дані каталогу способами, які складно виявити. Застосовуйте контрольований словник для структурованих атрибутів — генеруйте їх як enum-значення, а не вільний текст.

Некоректна цінова інформація в згенерованому контенті зустрічається частіше, ніж очікуєш. Якщо ціновий контекст проникає в промпт опису товару (наприклад, сніпет "зараз за акцією за X гривень" у даних товару), модель може включити цю ціну в текст опису. Потім акція закінчується, опис не перегенеровується — і тепер у вас статичний текст із застарілою ціною. Прибирайте цінову інформацію з усього, що бачить модель. Описи ніколи не мають згадувати конкретні ціни — для цього існують структуровані цінові поля і шаблонізація.

Вибір моделі: практична версія

Для більшості commerce-кейсів у продакшні сьогодні рішення зводиться до вибору між OpenAI (GPT-4o і нова o-серія), Anthropic (Claude 3.5/3.7 Sonnet, Claude Opus), Google Vertex AI (Gemini 1.5/2.0 Pro) або opensource-моделями на самохостингу. Для збагачення каталогу важливий розмір контекстного вікна — може знадобитися передати довгі дані товарів або кілька документів з політиками. GPT-4o і Claude Sonnet впевнено працюють із 128k токенів; Gemini 1.5 Pro підтримує до 1M токенів, що зручно для масової обробки документів.

Вартість при масштабі — цифра, яку більшість команд недооцінює. Промпт плюс завершення в середньому 1 500 токенів, за тарифами GPT-4o, на 100 000 SKU на місяць — приблизно $450/місяць за поточними цінами. Нормально. Те саме навантаження через Claude Opus обходиться в 3-4 рази дорожче, але помітно краще справляється зі складними категорійними описами. Llama 3.1 70B на самохостингу на GPU-інстансі обходиться приблизно в $0,40/год на spot — привабливо для високообсягових завдань із меншою складністю, як класифікація, де розрив у якості з frontier-моделями невеликий.

Приватність даних — реальне обмеження для ряду commerce-стеків. Якщо каталог містить закупівельні ціни, умови контрактів або персональні дані користувачів у будь-якому полі, не можна відправляти це до стороннього API без перевірки угод про обробку даних. Opensource-моделі на власній інфраструктурі повністю обходять це питання. Для більшості завдань чистої генерації контенту дані не чутливі і це не блокер — але варто уточнити це до підписання контракту з провайдером моделі.