291 товар за полчаса: что умеет ИИ-агент в каталоге товаров

Мы делаем программу, в которой интернет-магазины и продавцы на маркетплейсах ведут свои товары. В ней есть ИИ-агент: ему пишут в чат обычную просьбу, и он выполняет работу сам. Расскажу, что он умеет, что делает по своей инициативе и где ошибается. Всё это не впечатления, а разбор реальных сессий — разговоров, которые я брал целиком.

Компания прислала агенту прайс нового поставщика, скриншот и одну фразу. В файле было 292 строки: название, артикул, цена и отметка, есть ли товар в наличии. Фраза:

«необходимо загрузить поставщика Тоесть создать поставщика, загрузить прайс, провести ценообразование, создать карточки, которых нет. Что еще от меня необходимо?»

(Орфография сохранена. «Прайс» — это тот самый файл с ценами, «ценообразование» — расчёт цены продажи.)

Агент ничего не стал делать сразу, а задал пять вопросов: как назвать поставщика, какая нужна наценка и в какой валюте, заполнять ли его реквизиты, загрузка разовая или по расписанию, что делать с разделами каталога. Человек ответил одним сообщением.

Дальше агент двадцать минут работал один. Он завёл поставщика, а реквизиты для него взял на официальном сайте производителя. Разобрал файл и проверил, нет ли таких товаров в каталоге. Создал 51 новый раздел: под эту группу товаров разделов почти не было. Заметил, что четыре позиции на самом деле другой марки, и завёл её отдельно. Создал 291 новый товар и посчитал цены для тех, что были в наличии. Каталог вырос с 883 до 1 174 товаров — на треть.

Потом человек попросил добавить описания и фотографии — ещё тринадцать минут. Описания появились у 276 товаров, фотографии у 104: у остальных 187 ссылки на картинки в файле самого поставщика оказались битыми. Агент это перепроверил и предложил три варианта — оставить как есть, искать фото по страницам производителя или написать поставщику.

Итого: три сообщения от человека и около получаса работы агента.

Страница товара на маркетплейсе — это карточка: фотография, название, описание, характеристики, цена. В большом магазине таких карточек сотни тысяч, и каждую нужно завести, заполнить и дальше поддерживать: поставщик изменил цену — пересчитать, площадка добавила обязательное поле — заполнить. Раньше это делали люди, копируя значения из одной вкладки в другую.

Наша программа и раньше умела хранить товары, считать цены и отправлять их на площадки. Мы дали агенту доступ почти ко всем её операциям и научили понимать обычные просьбы на человеческом языке.

В другой раз компания подключала поставщика — сам завод-производитель. Агент не просто загрузил файл: он открыл сайт производителя и сверил с ним каждую цену — все 259 артикулов, хотя в задании просили проверить двадцать. Совпали все, кроме одного.

Из этого совпадения он сделал вывод, которого в файле не было. Цена на сайте была подписана «с НДС». Значит, и в файле цены указаны с налогом, а закупочную цену каталог хранит без него — её нужно получать делением на 1,22. В инструкции, которую прислал человек, так и было написано, но агент не поверил на слово, а проверил: будь цены в файле закупочными, они бы не совпали с сайтовыми до копейки.

Единственный несовпавший артикул оказался ошибкой на стороне поставщика: под одним номером в файле шли две строки, а на сайте под этим же номером лежали два разных товара, причём второй — с нулевой ценой. Обе строки агент не загрузил и оставил человеку на разбор.

И самое полезное: он увидел, что товары этой линейки уже лежат в каталоге под другой маркой — их оказалось 194. Подсказку дал сайт поставщика: он называл себя тем же заводом, чья марка в каталоге уже была. Часть строк из файла совпала с этими карточками, и их агент привязал к существующим, а не создал заново. Иначе в магазине появились бы дубли — два одинаковых товара с разными ценами и остатками.

Ещё пример: тысячи строк поставщика не находили себе пару в каталоге. Агент понял почему — настоящий артикул был записан не в поле артикула, а в конце длинного названия. Человек поменял настройку сопоставления, и почти четыре тысячи строк нашли свои товары.

И последнее. Пользователь попросил поднять контент-рейтинг карточек до 100 — так площадка оценивает полноту карточки. Агент выяснил, что из 93 500 оценённых товаров ни один не поднимается выше 82%, и сказал, что 100% достижимы не всегда. Проверить результат он не смог — обновлять рейтинг на площадке он не умеет — и признался в этом вместо красивой цифры.

Отдельная роль у него там, где значения переносит не он, а автоматический перенос из источников: в одной карточке цена утекла в поле веса и у товара появился вес 63 килограмма, в другой ёмкость аккумулятора в мА·ч записалась как 5 700 граммов. Обе ошибки агент нашёл и исправил.

Он не выдумывает значения. Если надёжных данных нет, поле остаётся пустым, и агент так и пишет. Пустое поле видно в фильтре, и его заполнят позже, а правдоподобное, но неверное значение, скорее всего, найдёт уже покупатель.

Он не генерирует изображения. Фотографии он только находит — те, что уже опубликованы, — и сохраняет их у себя вместе со ссылкой на страницу, откуда взял. На вопрос, не нарушает ли это права, честно отвечает, что проверить водяные знаки и авторство не может.

Он спрашивает, когда решение нельзя отменить или когда проверить нечем. Для части товаров площадка требует указать класс опасности при перевозке: у разных марок он разный, а исправить значение после модерации не получится — агент перечислил, что знает, и попросил решить человека. Сбор сертификатов соответствия брать отказался: официальные реестры нельзя прочитать программой. И массовую работу молча не начинает — если нужно сгенерировать описания сразу для ста тысяч товаров, он сначала спросит.

Ошибается, как любой новый сотрудник, только работает быстрее.

Сразу оговорюсь: тот срез мы с тех пор разобрали целиком, и найденное пошло в работу — что-то починили в системе, что-то превратили в правила и дополнительные проверки, что-то ещё доделываем. Так что ошибки ниже — это скорее то, с чем мы столкнулись тогда, чем то, что происходит сейчас.

Он создал несколько дублей, потому что не догадался проверить похожие названия, — и пересматривать созданное начал только после того, как человек ткнул в один из них. Товар отличался от уже существующего порядком слов и тем, что римская двойка в артикуле была набрана двумя строчными L. Агент пересмотрел всю партию, нашёл три настоящих дубля и удалил свои. На другом поставщике он создал 23 карточки не под той записью бренда; позже его же параллельные задачи это заметили, и товары объединили обратно.

Он додумывал лишнее там, где данных не хватало: на четырёх карточках взял страну производства из адреса завода в справочниках, часть признаков проставил по аналогии с соседними товарами, а у одной стёр код, который человек считал просто неподтверждённым. Всё это откатили после двух замечаний. Он же положил конвейерную ленту в раздел клея и придумал раздел для частотных преобразователей, хотя подходящий уже был.

Отправка на площадки — это цикл: проверил у себя, исправил, отправил, получил ответ площадки, снова исправил. Карточки мы проверяем сами, до отправки, и часть до площадки не доходит; подгонять данные, чтобы проверка прошла, агент не стал — он спросил, что делать. А узкое место здесь чаще не агент, а очередь задач и ограничения площадки.

Главный вывод: правила нужно записывать заранее. Как называть товары, где брать фотографии, как считать цену — если это нигде не записано, агент будет угадывать, а человек будет за ним переделывать.

Магазину — товары появляются в продаже быстрее и их становится больше: отдел, который раньше заводил карточки руками, теперь проверяет результат и решает спорные вопросы.

Нам — отличную уникальную возможность для платформы, агент возможен только потому, что платформа единая: прайсы поставщиков, карточки, источники данных, цены и выгрузка живут в одном месте и связаны между собой. Он не склеивает данные между разными системами, а пользуется почти теми же операциями, что и человек в интерфейсе. Результат для компании не в том, что агент «внедрён», а в том, что им реально пользуются каждый день, за день в срез попали три десятка каталогов, и это обычная эксплуатация, а не демонстрации. А разбор таких сессий стал у нас способом тестирования — по нему видно, где система мешает агенту.

Мы сделали агента, который забирает монотонную работу, чтобы людям осталась та, где нужно думать. Значения в карточках он не выдумывает. Но правила ему всё равно нужно записывать, а трудные решения оставлять людям.

Юрий, разработчик catalog.app.