Решение
Сервис построен как каскад ИИ-агентов, каждый из которых решает одну узкую задачу, а между агентами работают алгоритмические проверки по справочникам. Теги присваиваются по «осям» — категориям тегов: страна производства, тип кожи, тип продукта, назначение, ключевые компоненты, объём и т. д. Оси привязаны к категориям товаров (у кремов и шампуней свой набор), у каждой оси есть описание для модели и лимит тегов на товар. Новые оси и категории товаров модель может создавать только если это явно разрешено в задаче — так облако тегов не разрастается бесконтрольно.
Как проходит генерация
- Постановка задачи. Через API или админку передаётся список товаров и параметры: пересоздать теги с нуля или дополнить существующие, пропускать ли товары, у которых тегов уже достаточно. Задача ставится в очередь и выполняется асинхронно, её статус и время завершения видны в истории задач. Рекомендуемый режим — общий прогон по всей базе, затем повторный только для товаров, где тегов пока мало.
- Группировка товаров. Перед отправкой в модель товары сортируются по векторной близости названий и собираются в небольшие группы (по умолчанию по 5). Похожие товары одной линейки размечаются в общем контексте и получают теги в едином стиле.
- Генерация тегов. Агент генерации получает название, описание, состав и характеристики товаров, список осей с описаниями и лимитами, а также уже существующие теги, и присваивает теги в формате «Ось — Тег». Результат нормализуется по регистру и пунктуации, похожие категории не дублируются благодаря нечёткому сравнению строк, англицизмы отсекаются алгоритмическим фильтром.
- Фильтрация. Отдельный агент проверяет каждый тег на соответствие описанию товара и удаляет «додуманные» — компоненты, которых нет в составе, неверные объёмы и т. п. Фильтрацию можно запустить и отдельно по уже размеченной базе.
- Синонимизация. Теги сверяются со справочником синонимов: если найден синоним, его связи с товарами переносятся на целевой тег (при необходимости он создаётся), а синоним удаляется. Есть режим предпросмотра, который только показывает найденные совпадения.
- Запрещённые теги. Теги из справочника запрещённых удаляются перед финальным сохранением.
- Сохранение. Теги записываются в базу товаров, каждое изменение фиксируется в истории по задаче, промежуточные результаты всех шагов сохраняются для разбора спорных случаев.
Справочник синонимов пополняет отдельный агент: он получает все теги оси и текущий справочник, находит теги, которые означают одно и то же (например, «для всех типов кожи» и «все типы кожи»), и дописывает новые пары, не трогая уже проверенные записи. Агент запускается вручную после массовой генерации — чтобы контролировать, что попадает в справочник, — затем проверка по обновлённому справочнику применяется ко всей базе. Справочники синонимов и запрещённых тегов, лимиты осей и настройки агентов (модель, системный промпт, температура, размер группы) редактируются в админке без участия разработчиков.
Как пришли к такой схеме. Первая версия с одной моделью и фиксированным числом тегов на товар давала дубли («кокосовое масло», «масло кокоса»), непоследовательную разметку одинаковых товаров и ошибки в объёмах. Затем появился агент унификации, который анализировал всю базу и схлопывал похожие теги, но на практике он объединял слишком агрессивно («охлаждающий эффект» → «увлажнение») и упирался в размер контекста на больших базах. В итоге унификацию сделали опциональной, а качество обеспечивают агент фильтрации, справочники синонимов и запрещённых тегов и агент генерации синонимов. Фиксированное число тегов на товар заменили лимитами по осям — это заметно повысило полноту разметки.
Модели. Разработка начиналась на облачной YandexGPT. После сравнения на эталонных товарах сервис перевели на локальные модели: генерацию тегов выполняет DeepSeek-R1 (32B), для синонимов использовались Magistral и Qwen 3.5. Модели работают через Ollama на сервере заказчика, поэтому данные каталога не уходят во внешние облака. Подключение облачной модели через API остаётся опцией и требует небольшой доработки.
Бэкенд и админка. FastAPI с двумя базами Postgres (внутренняя — настройки, агенты, пользователи, задачи на генерацию; внешняя — товары, теги, оси, связи товар-тег, справочники) и очередью задач на Celery и Redis. Поверх — API Gateway с Basic Auth и веб-админка: поиск товаров по ID, штрихкоду, коду, названию и тегу, карточка товара с тегами в формате «Категория тега — Тег», раздел «Агенты» в настройках, история изменений тегов по задачам. Финальный этап — подготовка docker-compose и передача сервиса на инфраструктуру заказчика.
