AI-агент, который пишет описания карточек товара
Сегодня разбирал архитектуру AI-агента для товарного контента. На первый взгляд задача простая: нужно, чтобы нейросеть автоматически писала описания карточек для маркетплейсов. Но если вы пробовали пользоваться встроенными AI генераторами, которые предлагают маркетплейсы, скорее всего встречались с посредственным результатом: текст формальный, сухой, характеристики путаются, видно что текст писала машина. Задача которую ставлю перед собой: Описание должно соответствовать TOV, не искажало факты о товаре, было SEO оптимизированным, ориентированно на целевую аудиторию.
Архитектура
Я строю систему закрытого локального контура. Логика работы отличается от привычного понимания агента — сотрудника, который делает весь процесс от начала до конца. В моей системе процесс построения карточки содержит уже 2 роли: catalog_manager и editor:
Первая роль — catalog_manager. Это агент товарных данных. Он работает с МойСклад, получает данные по артикулу, собирает внутреннюю модель товара canonical_product, применяет бизнес-правила и готовит карточку для маркетплейсов.
Вторая роль — editor. Это агент текста. Он не создаёт карточку, не меняет характеристики, не трогает цену и не придумывает свойства. Его задача — взять проверенные данные и превратить их в понятное описание, SEO-ключи и буллеты.
Такая логика позволяет предотвратить проблемму галлюцинирования модели. Агент не выдумывает карточку, чтобы затем генерировать синтетические данные. Он работает от четкой структурированной утвержденной информацией из единой базы данных.
Режимы работы
У агента 3 режима запуска: автоматический после создания карточек catalog_manager, по запросу пользователя, и по готовому canonical_product.
Режим 1 — автоматический после catalog_manager
catalog_manager → editor_handoff_package → editor
catalog_manager создает пакет новых карточек -> передает данные в editor
Режим 2 — по готовому canonical_product
canonical_product → orchestrator → editor_handoff_package → editor
Карточка уже существует, данные товара подтянуты. Оркестратор оборачивает canonical_product в handoff_package нужно только обновить описание.
Режим 3 — по SKU
По запросу например Обнови описание для kprk-pod120200lio на Ozon
SKU → МойСклад API → | catalog_managerresolver →canonical_product → editor_handoff_package
Editor не пишет сразу текст, сначала catalog_manager получает товарные данные из базы, создает canonical_product в соответствии с бизнес правилами оборачивает в формат ahandoff_package и на основании этой информации пишет описание.
Правила текста
Отдельно я вынес правила текста в файл semitono_content_rules.yaml. В нём будут храниться структура описаний, tone of voice, SEO логика, запрещённые формулировки и правила проверки. Например, нельзя писать, что простыня подходит для любого матраса, если размер и высота матраса ограничены данными, которые лежат в базе.
Если нет каких то данных в базе, агент останавливается и отправляет поле в manual_check. Это предотвращает проблемму галлюцинирования. На первом этапе агент не будет сам обновлять карточки через API. Он готовит черновик, отчёт и файл для проверки. Только после ручного подтверждения можно делать внешний API update.
Преимущества системы
Мне нравится эта архитектура тем, что она превращает генерацию описаний в управляемый производственный процесс. Агенты не путаются в ролях, проще контролируется результат и отладка, проще масштабирование. Все работает от единой базы данных, у каждого агента есть своя зона ответственности: Catalog_manager — поля и данные на карточке, Editor — тексты. У каждого действия есть граница безопасности. А так же заимозаменяемость моделей, благодаря понятной структуре.