Селлер на маркетплейсах — это человек с тремя личными кабинетами и вечным долгом перед отзывами. Утром посмотреть заказы за ночь. Проверить, что ничего не кончилось на складе. Ответить на вопросы покупателей, пока их не увидел конкурент. Поднять цену на то, что уходит слишком быстро, и понять, почему реклама съела дневной бюджет к обеду. На Wildberries, Ozon и Яндекс Маркете это одна и та же работа в трёх разных интерфейсах.

Мы делаем AI-сотрудников для бизнеса, и менеджер маркетплейсов среди них самый «рукастый». Ему мало написать текст: он лезет в кабинет продавца, где лежат цены, остатки и рекламные бюджеты, то есть чужие деньги.

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

Что менеджер должен уметь с первого дня

Мы не стали начинать с «умного советника». Начали с того, на что селлер тратит время каждый день:

• заказы и продажи за сегодня, вчера, неделю, месяц;

• остатки на складах и когда пора везти поставку;

• цены и акции площадок;

• карточки товаров и их названия;

• реклама — пока только посмотреть;

• воронка: показы, переходы, корзины, заказы;

• вопросы и отзывы покупателей;

• отчёт в Excel одной командой;

• утренняя проверка: если что-то срочное, менеджер сам пишет в чат.

Всё это работает через официальные API площадок по ключу владельца. Селлер подключает кабинет, а дальше просто пишет в чат обычными словами.

Как устроен прототип: фраза, правило, API

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

Фраза сначала проходит через набор правил, и на выходе получается намерение: какая операция, какая площадка, за какой период.

Выглядит это так (сильно сокращено):

def words(q: str) -> dict:
    """Без модели: намерение по словам. Порядок проверок — от изменения к чтению."""
    low = q.lower().replace("ё", "е")
    p = {"op": "ask", "goods": q, "day": "", "days": 0}
    if re.search(r"сегодн", low):
        p["day"] = "today"
    elif re.search(r"вчера", low):
        p["day"] = "yesterday"
    m = re.search(r"(\d{1,3})\s*(дн|день|сут)", low)
    p["days"] = int(m.group(1)) if m else 30 if "месяц" in low else 7 if "недел" in low else 0
    # ... дальше — ответы покупателям, цены, акции, остатки, заказы
    return p

Обратите внимание на строку в docstring: проверки идут от изменения к чтению. Сначала ищем, не просят ли что-то поменять, и только потом — показать. Ошибиться в сторону «показал лишнюю таблицу» не страшно. Ошибиться в сторону «поменял цену» — очень.

Площадку определяет такое же правило. Тут сразу нашлись грабли русского языка: «маркетплейсы» — это не Яндекс Маркет.

asked = [k for k, w in (("ozon", r"ozon|озон"),
                        ("ym",   r"маркет(?!плейс)|market(?!place)"),
                        ("wb",   r"\bwb\b|\bвб\b|wildberries|вайлдберр"))
         if re.search(w, low)]

Если площадку не назвали, менеджер отвечает по всем подключённым. Если назвали ту, что не подключена, — по первой, которая есть.

Дальше всё прямолинейно. Операция зовёт свой обработчик, обработчик ходит в API нужной площадки, разделы WB, Ozon и Маркета запрашиваются параллельно, ответ собирается в таблицу. Свежий снимок кабинета кладём в базу и обновляем в фоне, чтобы второй вопрос подряд не ждал площадку заново.

Где здесь нейросеть

Правила хороши, пока человек пишет предсказуемо. Поэтому, если модель подключена, фраза уходит и ей — вместе со списком операций и одной строкой описания к каждой:

def parse(q: str) -> dict:
    p = words(q)                      # сначала правила
    if not llm.available():
        return p
    ai = llm.complete_json(_PARSE + "
".join(f"{k} — {v}" for k, v in OPS.items()),
                           json.dumps({"фраза": q}, ensure_ascii=False),
                           SCHEMA, effort="low", max_tokens=400) or {}
    if ai.get("op") in OPS:           # чужую операцию не примем
        p.update({k: v for k, v in ai.items()
                  if k in SCHEMA["properties"] and v not in (None, "")})
    return p

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

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

Деньги — только кнопкой

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

Это правило появилось в первый же день, и отменять его мы не собираемся. Что бы ни менялось в устройстве менеджера, тратить деньги владельца без его явного согласия он не будет.

Почему мы начали именно так

Можно было сразу дать модели инструменты и сказать «разбирайся». Мы сознательно пошли от правил, и причины были вполне практические.

Предсказуемость. На каждый ответ можно показать пальцем: вот правило, которое сработало. Если менеджер ответил не то, понятно, что чинить.

Скорость. Модели нужен один короткий ответ — название операции, а не рассуждение. Без модели правила отвечают сразу.

Проверяемость. Мы написали подставные WB, Ozon и Маркет, которые работают без сети. Весь менеджер прогоняется смоук-тестом без единого запроса наружу: заказы, остатки, цены, ответы, отчёты, кнопки.

Цена. Модель вызывается коротко и по мелочи.

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

Как будем тестировать

Прототип мы выпустили в два места.

Демо-магазин. Магазин на трёх площадках с правдоподобными заказами, остатками и отзывами — без сети и без риска. Его может подключить любой проект и поговорить с менеджером, не давая ключи от своего кабинета.

Первые владельцы с живыми кабинетами. Тут всё по-настоящему: реальные товары, реальные покупатели, реальные деньги за кнопками.

Смотреть будем на три вещи:

• сколько фраз не распознались и ушли в общий ответ;

• где менеджер понял фразу, но показал не то;

• какие правки владельцы готовят, но не подтверждают, и почему.

Первые владельцы уже пишут ему в чат. Пока мы пишем эту статью, ответы ****хорошо ли? Мы пока сами не знаем. Как только разберём первые разговоры, поделимся результатами.