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-модели на собственной инфраструктуре полностью обходят этот вопрос. Для большинства задач чистой генерации контента данные не чувствительны и это не блокер — но стоит уточнить это до подписания контракта с провайдером модели.