Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 10
Первое, на что обратил внимание, это работа с кешированными данными. У меня в одной из систем была довольно забавная проблема: агент уверенно отвечал пользователям на основании копий репозиториев, которые не обновлялись месяцами. Поэтому рекомендовал бы сразу предусмотреть контроль актуальности данных, особенно перед операциями изменения цен и остатков.
Второй момент. Как у вас обрабатывается ситуация, когда пользователь подтвердил действие, запрос в API ушел, но система упала или получила таймаут до сохранения результата? Операция могла выполниться, а могла и нет. Была у меня такая ситуация, в итоге пришлось отдельно прорабатывать сохранение состояния операций и восстановление после неопределенного результата. Некоторые технические детали описывал здесь: https://habr.com/ru/articles/1095776/, если интересно можешь изучить
Ну и немного смутило поведение с неподключенными площадками. Если пользователь запрашивает Ozon, а система подставляет WB, можно получить фактически неправильный ответ. Лучше явно сообщать об отсутствии подключения.
Самое сложное в таких системах когда пытаешься гарантировать, что она не натворит пиздеца при совершенно штатных сбоях)
Спасибо за подробный разбор — все три пункта по делу.
Про кэш. Снимок кабинета у нас живёт 20 минут: дальше показываем его и параллельно собираем новый, старше суток — не показываем вовсе. После любой правки снимок сбрасывается. Но в главном вы правы: в прототипе «было → станет» для цен считалось по снимку, и прямо перед записью мы позиции заново не перечитывали. Если за эти минуты цену поменяли руками в кабинете, владелец увидел бы неверное «было». Перечитать позиции перед отправкой стоит копейки — добавим.
Про таймаут после подтверждения. Здесь нас во многом спасает то, что правки пишутся абсолютными значениями: «поставить 1990 ₽», а не «поднять на 10%». Повторное нажатие после неясного исхода приводит к тому же состоянию, а не удваивает изменение. Если площадка вернула ошибку, менеджер её показывает, а кнопка остаётся. Там, где площадка сама работает асинхронно (создание карточки на WB), после действия появляется отдельный шаг «Проверить, создала ли площадка». Для правок в рекламных кабинетах рядом есть «Вернуть как было» со значениями, прочитанными до правки. А вот отдельного состояния «отправлено, исход неизвестен» с восстановлением после падения у нас действительно нет. За ссылку спасибо, посмотрим, как вы это сделали.
Про неподключённую площадку — да, это ошибка, и вы её точно поймали в коде из статьи: next(..., on[0]). Правильно ответить «Ozon не подключён», а не молча показать WB. Исправим.
Под последней фразой подписываемся. Штатные сбои страшнее нештатных: к ним никто не готовится.
Сами регулярки вы же с ИИ писали, да? Это как раз то, что они делают практически идеально. В целом подход здравый — если что-то можно решить кодом, зачем тащить туда LLM?
Да, писали вместе с ИИ — и здесь он правда почти идеален: даёт регулярку, сам подбирает фразы, на которых она должна и не должна сработать, и не устаёт от пятидесятой проверки подряд. Мы оставили себе решать, что вообще считается операцией и в каком порядке проверять: сначала «изменить», потом «показать».
Насчёт кода против LLM — согласны, для детерминированных вещей вроде периода, площадки или артикула модель не нужна: код быстрее, дешевле и одинаково отвечает на одинаковый вопрос. Вопрос в том, где проходит граница. Правила хорошо понимают то, как пишет разработчик, а селлеры пишут по-своему. Насколько велика эта разница на живых кабинетах — как раз сейчас и смотрим.
ссылка на сервис??
Два раза прочитал, и не понял ответ на вопрос "Что менеджер должен уметь с первого дня", чтобы понять, что такого предлагает сервис по сравнению с личным кабинетом маркетплейсов, которые достаточно развитые в аналитике, и за доп. подписки предлагаю возможности, которые вы никогда не получите сами через API.
Справедливо — в статье мы описали, что менеджер умеет, но не сказали, зачем это селлеру, если кабинет площадки показывает то же самое.
Уникальных данных у нас нет, и мы с этим не спорим. Джем на WB или Premium на Ozon дают аналитику, которую через API не получить. Но кабинет — это цифры. Их все видят, все читают, а вот что с ними делать, кабинет не говорит.
Он покажет, что у карточки мало переходов, но не скажет, что дело в слабом SEO: в названии и характеристиках нет слов, по которым её ищут. Покажет расход на рекламу, но не скажет, что половина бюджета уходит на запросы, по которым никто не покупает, и эти деньги тратятся впустую. Покажет остатки, но не скажет, что через неделю ходовой товар закончится, а поставка едет дольше.
Это и есть работа менеджера: связать цифры между собой и сказать словами, где проблема и что поправить. Плюс сразу подготовить правку — новое название, ставку, цену — и сделать её после вашего подтверждения.
И бытовые вещи сверху: три площадки в одном чате, вопрос вместо поиска нужного раздела, а о срочном менеджер пишет утром сам, не дожидаясь, пока вы зайдёте в кабинет.
Что-то несколько раз прочитал и не понял. Это какой-то телеграм бот получается, в который пишешь и он что-либо делает с инфой из маркетплейсов?
Почти, только не в Телеграме. Это чат с AI-менеджером в веб-кабинете на сайте. Вы подключаете кабинет продавца на WB, Ozon или Маркете ключом API, а дальше пишете обычными словами — что с остатками, сколько заказов за вчера, какие вопросы покупателей висят без ответа. Менеджер забирает данные из кабинета через официальный API и отвечает таблицей, а если нужно — готовит правку: цену, ответ покупателю, название карточки. Любая правка уходит в кабинет площадки только после того, как нажмёте кнопку.
О срочном он пишет в этот же чат сам, утром: товар заканчивается, покупатели ждут ответа.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
AI-менеджер для WB, Ozon и Маркета: почему мы начали с регулярок, а не с агента