Кейс автоматизации генерации контента для интернет-магазина на 1С-Битрикс: 1 000 описаний товаров за сутки, архитектура на FastAPI + MySQL + Redis, интеграция через REST API и JWT.
Упростили жизнь одному контент-менеджеру
Мы разрабатываем и сопровождаем интернет-магазины на 1С-Битрикс. Наши клиенты давно используют ИИ для рерайта и генерации контента. С одним-двумя описаниями проблем нет: скопировал текст в нейросеть, получил результат, вставил обратно.
Но когда в каталоге тысяча товаров — ручной труд превращается в бесконечную рутину.
Один из наших клиентов — интернет-магазин с каталогом около 1 000 позиций. Товары не эксклюзивные, такие же продаются на других сайтах и маркетплейсах. Клиент хотел отличаться: сделать описания уникальными и обогатить их полезной информацией.
Что и было успешно сделано для нескольких позиций средствами ИИ. Но вручную это выглядело бы так:
- Открыть карточку товара на сайте.
- Скопировать описание.
- Вставить в ИИ с промптом.
- Получить ответ.
- Скопировать обратно в карточку.
- Повторить 1 000 раз.
Итог: 2–3 минуты на товар = около недели непрерывной работы, хотя по правде несколько недель.
Мы реализовали автоматизированный механизм рерайта описаний и генерации дополнительного блока «Преимущества и особенности по отзывам о товаре в интернете», содержимое которого также генерировалось ИИ. Механизм успешно отработал, появились запросы на повторение опыта на других проектах, но всё решение было заточено под конкретный проект.
Тиражируем успешный опыт
Возникла идея оформить накопленные решения и опыт в отдельный модуль, который достаточно установить на сайт, указать параметры подключения к провайдеру ИИ, написать промпт и запустить генерацию для выбранных товаров.
Исходили из того, что пользователь не будет вдаваться в параметры работы с ИИ — температуру, top-p и другие. Всё, что ему нужно: написать промпт (возможно, уже с помощью ИИ), протестировать на паре товаров, запустить массово и после проверки либо безопасно откатить, либо оставить.
Чтобы не создавать излишние сложности для клиента — установку на сервер специальных библиотек, указание необходимых для работы с ИИ настроек и так далее — вынесли всю логику работы с ИИ на свой отдельный сервер. Модуль просто обращается к серверу с запросом и получает готовый текст: ничего дополнительно настраивать на сайте не нужно.
В итоге выложили на Маркетплейс 1С-Битрикс модуль «Генератор контента Kemplox», который умеет:
- Генерировать описания товаров, названия, прочие контентные блоки.
- Заполнять мета-теги (title, description) — вручную их редко кто заполняет для каждого товара.
- Работать как с товарами, так и с разделами.
- Обрабатывать весь каталог в фоновом режиме — запустили и забыли.
Стоимость модуля — 4 990 рублей. Доступен полнофункциональный демо-режим, чтобы оценить его на своём каталоге.
Можно обрабатывать не весь каталог, а только часть, указав нужный фильтр. К примеру, задали выбрать только товары с пустым описанием и запустили выполнение фонового задания.
В каждом задании есть возможность задать обработку сгенерированных текстов, например простые замены текста (к примеру, удалить символ звёздочки) или с помощью регулярных выражений.
Благодаря возможности работы с SEO-шаблонами можно формировать метаданные для каталога не по типовому шаблону, а по промпту, делая их более разнообразными и близкими к написанным человеком. Стоимость одного метаописания — несколько десятков копеек.
Практические результаты
Модуль использовали для рерайта описаний товаров и для генерации блока «Анализ отзывов покупателей», в котором ИИ генерировал текст типа:
«По итогам анализа отзывов покупателей в интернете отмечают следующие особенности товара: надёжный корпус, удобная рукоятка, но есть нарекания на вес — некоторым пользователям он кажется тяжёлым...»
То есть на каждый товар делалось два запроса к ИИ. Модуль для снижения нагрузки выполняет в фоновом режиме один запрос в 1–2 минуты, не прерываясь на обед, сон... По итогу менее чем за сутки он в фоновом режиме обработал полностью весь каталог, уникализировав описания и добавив везде блок «Анализ отзывов покупателей».
Проводили эксперимент по ручному заполнению этих двух блоков с помощью ИИ, получалось порядка 2–3 минут на товар. Но очевидно, что никто не будет безотрывно сутками заниматься такой работой. Поэтому по итогу сэкономили минимум неделю труда со стороны сотрудников клиента.
Сейчас клиенты уже сами экспериментируют с промптами и вносят правки, доводя контент до того состояния, которое им видится оптимальным.
А если что-то пойдёт не так?
Модуль сохраняет оригинальные тексты до генерации. Если результат не понравился — откатываете задание в один клик и возвращаетесь к исходному состоянию. Пробовать безопасно.
Техническая часть: как это устроено внутри
Этот раздел — для разработчиков, технических директоров и тех, кому интересно, что под капотом.
Почему вынесли AI-логику на отдельный сервер
Сразу решили всю AI-логику вынести в отдельный микросервис на своём сервере. Это сделано, чтобы не зависеть от инфраструктуры, на которой работает сайт, и не нагружать сайт тяжёлыми Python-библиотеками и сложными зависимостями.
Мы рассматривали два варианта: вызывать LLM напрямую из модуля на PHP или вынести всю логику на отдельный сервис. Первый вариант отпал быстро: Python-экосистема для работы с LLM (openai, langchain, tiktoken) несопоставимо богаче PHP, а тянуть Python в инфраструктуру Битрикса (особенно BitrixVM) — это боль. Второй вариант даёт ещё и независимость: сайт не зависит от того, какая версия Python установлена на сервере, какие библиотеки доступны, как настроен nginx.
Кроме того, решение ориентировано на неподготовленных пользователей, которые не будут вдаваться в параметры работы с ИИ — температуру, top-p и другие.
Схема архитектуры
|
1С-Битрикс (сайт) Модуль Kemplox Агенты / cron · Очередь задач |
||
| ↓ REST + JWT ↓ | ||
|
AI-бэкенд (Python) FastAPI + OpenAI SDK Оркестрация · Rate-limiting · Retry / fallback |
||
| ↓ ↓ ↓ | ||
| MySQL | Redis |
LLM-провайдер Yandex / Cloud.ru |
Технологический стек и обоснование выбора
Бэкенд написан с помощью FastAPI и работает на связке баз данных MySQL и Redis.
FastAPI выбран из-за асинхронности: запросы к LLM могут занимать десятки секунд, и блокирующий синхронный код здесь не подходит. Плюс автоматическая валидация через Pydantic и генерация OpenAPI — удобно для интеграции с модулем.
MySQL — по двум причинам: во-первых, это стандартная СУБД для Битрикса, и мы не хотим плодить зоопарк технологий; во-вторых, у команды большой опыт работы с ней. В MySQL хранятся пользователи, профили моделей (наборы параметров: temperature, top-p, промпты) и настройки инференс-провайдеров.
Redis решает две задачи: управление сессиями API и rate-limiting запросов к LLM-провайдерам. Лимиты нужны разные — на пользователя, на провайдера, на модель. Готовые решения (redis-cell) не подошли, поэтому написали свой Lua-скрипт со скользящим окном:
-- проверка и инкремент счётчика в скользящем окне
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local limit = tonumber(ARGV[3])
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count >= limit then return 0 end
redis.call('ZADD', key, now, now)
redis.call('EXPIRE', key, window)
return 1
Для взаимодействия с поставщиками ИИ-мощностей Yandex Cloud и Cloud.ru мы использовали унифицированный подход через OpenAI SDK: это позволяет абстрагироваться от специфики конкретных вендоров и очень быстро переключать провайдеров. Многие провайдеры предоставляют OpenAI-совместимый API, и добавление нового — это вопрос конфигурации, а не кода.
Docker Compose — осознанный выбор. Проект не требует автомасштабирования и оркестрации уровня Kubernetes. Отдельные контейнеры для Nginx, MySQL, Redis, Python-приложения и Certbot. Конфигурация — через .env, секреты хранятся отдельно.
Инженерные решения
Nginx и долгие запросы. Стандартные таймауты (60 секунд) не подходят для LLM: генерация описания может занимать 30–90 секунд, а для длинных текстов — и больше. Пришлось увеличить proxy_read_timeout и proxy_send_timeout, а также отключить буферизацию для стриминга:
location /api/v1/generate {
proxy_pass http://backend:8000;
proxy_read_timeout 300s;
proxy_send_timeout 300s;
proxy_buffering off;
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;
}
Rate-limiting на Redis + Lua. Лимиты нужны на разных уровнях: на пользователя модуля, на провайдера LLM, на конкретную модель. Реализовали через атомарный Lua-скрипт (см. выше) — это позволяет избежать гонок и лишних round-trip к Redis.
Интеграция с 1С-Битрикс
Бэкенд предоставляет RESTful API, защищённое JWT-аутентификацией. Модуль на стороне Битрикса отправляет в API ИИ-генерации только сырые данные и системную инструкцию, а бэкенд берёт на себя оркестрацию запроса и обработку ответа.
Формат запроса:
POST /api/v1/generate
Authorization: Bearer <jwt>
{
"provider": "yandex",
"model": "yandexgpt-lite",
"prompt": "Напиши описание для {NAME}. Категория: {SECTION}",
"variables": {
"NAME": "Смартфон XYZ",
"SECTION": "Электроника"
}
}
Ответ:
{ "task_id": "abc123", "status": "queued" }
Поскольку рерайт каталога из тысяч товаров — процесс долгий, мы реализовали механизм фоновой обработки. Битрикс ставит задачи в очередь (через агенты) и выполняет их с заданным интервалом, что позволяет массово генерировать контент без блокировки основных процессов сайта. Микросервис на Python асинхронно, без риска обрыва соединения по таймауту и потери запросов, отправляет готовый к размещению на сайте контент.
Модуль периодически опрашивает бэкенд по task_id (polling с экспоненциальной задержкой). Если бэкенд недоступен — задача остаётся в очереди и повторяется с backoff. Ошибки логируются, и администратор может их посмотреть в интерфейсе модуля.
Грабли и их решения
Rate-limiting у провайдеров. У Yandex Cloud есть лимиты на RPS и на количество токенов в минуту. Мы быстро упёрлись в них, когда запустили обработку каталога из 10 000 товаров. Пришлось ввести глобальный rate-limit на нашей стороне, разнести запросы во времени и настроить очередь с приоритетами.
Качество генерации. Первые версии промптов давали «воду» — текст был гладким, но бессмысленным. Пришлось ввести few-shot примеры, добавить постобработку (удаление шаблонных фраз, проверка на длину) и дать пользователю возможность править промпт.
Таймауты при стриминге. Без настройки Nginx запросы обрывались на 60 секундах. Решили увеличением таймаутов и отключением буферизации.
Вместо резюме
Написать вручную контент для большого каталога — это очень долго и дорого, поэтому и прибегают к использованию ИИ: он справляется быстрее, дешевле и не устаёт. Наш модуль делает этот процесс ещё более простым: установил, написал промпт, запустил.
Если у вас сайт на Битриксе и вы хотите автоматизировать генерацию контента — попробуйте модуль «Генератор контента Kemplox» в Маркетплейсе. Доступен полнофункциональный демо-режим — можно оценить на своём каталоге без рисков.
