Изначально InSales уже имела готовые дашборды для клиентов, однако для работы с ними пользователям нужно было владеть BI-инструментами.
Те не хотели разбираться в сложных интерфейсах с множеством графиков, таблиц и фильтров. В результате значительная часть клиентов просто игнорировала доступную аналитику.

Вместо этого — топили поддержку в типовых запросах:

• Почему снизились продажи за последние дни?
• Какие товары лучше продавались на прошлой неделе?
• Что не так с рекламой на Ozon и Wildberries?

И чаще всего вопрос звучал просто: «Как увеличить продажи?».

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

Основную проблему, которую ставила команда: нужно было упаковать данные таким образом, чтобы сделать по ним можно было сделать полезные выводы.

Первым делом провели исследование аудитории. Основные запросы пользователей звучали следующим образом:

• «Мне не нужны все эти графики. Скажите, что сломалось и что с этим делать».
• «Хочу открыть аналитику и сразу понять: у меня всё нормально или уже горит?»
• «Открыл аналитику и закрыл. Не понимаю, куда смотреть»

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

Важно, чтобы ИИ-аналитик умел обосновывать свой ответ, поскольку вопрос недоверия пользователей оставался ключевым.

Также определили метрики успешности нового сервиса.

Был риск, что пользователю воспримут его как баловство — поиграют, посмотрят, но не станут использовать постоянно.

В качестве таких метрик выбрали следующие показатели:

— количество уникальных пользователей в неделю и отношение ко всей базе клиентов;
— среднее количество посещений в неделю;
— среднее количество вопросов и ответов;
— соотношение положительных и отрицательных ответов.

Когда видение бизнеса было оформлено, команда перешла к поиску решения — вначале протестировали готовое open-source решение Vanna AI.

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

В среднем точность ответов составляла около 24%, это означало, что 3/4 SQL-запросов не соответствовали ожиданиям.

Поэтому команда решила разработать собственное решение на базе LLM, использовав Retrieval-Augmented Generation (RAG)* — без дорогостоящего переобучения модели с нуля.

Retrieval-Augmented Generation (RAG) — метод работы больших языковых моделей, при котором перед генерацией ответа модель ищет и подбирает релевантную информацию из внешних источников и добавляет её к запросу. Это помогает выдавать более точные и полезные ответы.

Теперь ассистент работает по следующему алгоритму:

1. Пользователь задает вопрос в чат.
2. Ассистент генерирует SQL-запрос к подготовленным витринам на основе примеров из заранее подготовленного датасета.
3. SQL-запрос проверяется, чтобы избежать ошибок.
4. Пользователь получает ответ и пояснение к нему.

Команда занимается как промт-инженерией для работы с последовательностью размышления модели, так и контекстной инженерией для повышения качества ответов и точности генерации SQL.

В результате получился кастомный датасет — команда вручную собрала 1800 пользовательских вопросов с SQL-запросом для каждого из них.

• Вопросы имитировали реальные формулировки селлеров: простые, неформальные, часто с нарушенной логикой.
• SQL-запросы были составлены и проверены экспертами, чтобы соответствовать структуре и бизнес-логике платформы.
• Охватывались основные пользовательские сценарии: падение выручки, эффективность рекламы, сравнительный анализ категорий и т.д.

Одним из артефактов стала база знаний (domain knowledge) — глоссарий и другие объяснения бизнес-домена.

Ниже показана работа функциональности — Объяснить ответ.

После добавления кастомного датасета и настройки логики промптинга точность модели выросла до 94% — по следующим метрикам на собственном датасете.

• Exact Match — совпадает ли с эталонным SQL дословно.
• Soft Accuracy — позволяет понимать вопросы пользователей в разных формулировках.
• R-VES — проверка релевантности и валидации результата на уровне схемы данных.

Это открыло возможность запускать MVP в тестирование с реальными пользователями.

Даже после настройки модели и улучшения точности команда столкнулась с рядом вызовов — без них не обходится ни одно внедрение ML.

Галлюцинации модели в запросе
Команда заметила, что модель пыталась придумать связи между таблицами, которых в реальности не было. Это выглядело очень правдоподобно — но было неправильно.
Поэтому даже несмотря на высокое качество генерации, модель иногда формировала некорректные SQL-запросы.
Например, обращалась к несуществующим таблицам или строила запросы, не соответствующие бизнес-логике.

Решение: внедрили цепочку проверок

• техническая валидация SQL-запроса перед отправкой в базу;
• логическая проверка структуры запроса;
• объяснение reasoning в интерфейсе, чтобы пользователь мог сам оценить ход рассуждений.

Нестабильные API и данные
Иногда данные от маркетплейсов могли приходить с задержкой или быть неполными (например, за предыдущий день еще не прогрузились или в системе был какой-то сбой).
Бывало, что система возвращала нулевой результат, и пользователь думал, что это ошибка модели. Хотя проблема была в источнике данных.

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

И самая важная проблема — недоверие пользователей
На ранних этапах пользователи воспринимали ответы ассистента как черный ящик. Даже правильный результат вызывал сомнения, если для него не было объяснения.

Решение: СOT
В интерфейс добавили пошаговое пояснение логики расчета — Chain-of-Thought. Это резко повысило доверие и вовлеченность. Теперь по модели было понятно как она рассужает.

Для InSales запуск такой инициативы стал важным шагом к трансформации пользовательского опыта и продуктовой модели.
По сути, это движение в сторону полноценного ИИ-ассистента для селлера на платформе.
Как продукт из пилота превращается в полноценный инструмент:

Увеличение длины диалога — пользователи стали задавать не один вопрос, а вести более развернутые беседы. Это указывало на повышение вовлеченности и доверия к инструменту.

Появление новых сценариев использования — пользователи стали интересоваться не только текущим состоянием метрик, но и возможностями детализации и анализа (стали спрашивать «почему», «в каком сегменте», «что дальше»).

Снижение потребности в ручной поддержке — часть типовых аналитических запросов, ранее обрабатывавшихся через чат или поддержку, теперь обрабатываются в AI-интерфейсе.

Что касается следующих шагов — сейчас команда развивает несколько направлений.

Во-первых, прорабатываются полноценные сценарии, которые выходят за рамки одиночных запросов — например, автоматическое выявление товаров, близких к out-of-stock, с последующим автозаказом.

Во-вторых, внедряются алерты: если ключевые показатели уходят в «красную зону», пользователь получает автоматическое уведомление. Третье направление — персонализация.

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

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

1. Начинайте с конкретной роли, а не с абстрактного AI
InSales не пытался «внедрить ИИ» во все бизнес-процессы сразу. Вместо этого была выбрана одна прикладная роль — аналитик-помощник, с четко измеримой пользой: сократить путь от вопроса до ответа.

Такой подход позволяет быстро выйти на MVP и увидеть реальные метрики поведения пользователей, не тратя месяцы на инфраструктуру или ресерч.

2. Подготовка собственных данных — обязательный этап
Без кастомного датасета точность модели составляла 24%. Только после создания и экспертной разметки 1800 пар «вопрос–SQL» модель достигла 94% точности. Это стало критической точкой перехода от прототипа к продукту.

Не существует универсального ML, который «просто работает». Ваши данные = ваша специфика.

3. ML-продукт должен быть не только точным, но и понятным
Даже при высокой точности пользователи сначала не доверяли ассистенту. Преодолеть недоверие получилось за счет визуализации процесса рассуждения модели. Люди начали понимать не только что им говорят, но и почему.