Аналитика без SQL и отчётов: как продавцы в Amazon получают инсайты напрямую из данных

В e-commerce продавцу постоянно приходится принимать решения на лету: что поднять в рекламе, где просели продажи, какие товары тянут бизнес вниз, а какие — дают рост. При этом данных вокруг много, но польза от них не всегда очевидна. Чтобы получить ответ, нужно открыть несколько инструментов, понять, где лежит нужный отчёт, как его собрать, какие фильтры поставить, а потом ещё и правильно интерпретировать результат. Авторы работы Insight Agents предлагают более человеческий путь: дать продавцу возможность “поговорить” со своими данными обычным языком — и быстро получить либо аккуратную сводку цифр, либо понятный бизнес-инсайт.

В центре идеи — разговорная система на базе LLM, построенная как мультиагентная система, где разные “роли” отвечают за разные куски работы. Важно, что это не демонстрация ради демонстрации: систему реально запустили для продавцов Amazon в США и проверили на точность и скорость.

Как устроен ассистент: менеджер и два «специалиста»

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

Менеджер делает две вещи, которые сильно влияют на практичность: он отсеивает вопросы “не по адресу” и маршрутизирует запрос к правильной ветке. Причём авторы сознательно борются с типичной болезнью LLM-систем — задержкой. Вместо того чтобы каждый раз спрашивать саму LLM, они ставят лёгкие ML-модули там, где это возможно.

Первый модуль — детектор выхода за рамки (OOD). Он нужен, чтобы не запускать дорогую цепочку рассуждений там, где вопрос не про аналитические инсайты или не покрывается данными. Для этого используется автоэнкодер, который быстро проверяет, “похож” ли запрос на допустимые вопросы. Второй модуль — маршрутизатор: компактная BERT-модель решает, отправить запрос в “витрину данных” или в “генератор инсайтов”. Оба решения дают выигрыш по скорости по сравнению с LLM-классификацией.

Есть и третий, более “человеческий” элемент — уточнение запроса. Например, фраза “за прошлую неделю” без контекста легко превращается в путаницу. Поэтому система добавляет конкретный временной интервал и правила трактовки периода прямо в промт следующего шага.

Почему здесь не Text-to-SQL и при чём тут планирование

Самая интересная инженерная часть — работа с табличными данными. Во многих проектах ассистента пытаются заставить писать SQL. Авторы идут другим путём: они опираются на внутренние data API и строят вокруг них “модель данных на уровне действий”. Это снижает свободу, зато резко повышает надёжность: системе проще выбрать из ограниченного набора корректных операций, чем каждый раз “сочинять” запрос к базе и ошибаться в колонках или синтаксисе.

Дальше включается планирование в стиле plan-and-execute. Запрос разбирается на подзадачи, подбираются нужные API и функции, генерируются параметры вызовов (по сути slot filling), затем исполнитель аккуратно собирает, агрегирует и пост-обрабатывает таблицы. И уже после этого LLM формирует ответ — либо в виде понятной таблицы/сводки, либо в виде интерпретации с доменными подсказками.

Для генератора инсайтов предусмотрена маршрутизация по доменным сценариям (производительность, бенчмарки, рекомендации и т.д.). Это похоже на “рельсы” для рассуждения: LLM всё ещё пишет текст, но делает это в рамках заранее продуманного пути, где есть подсказки и примеры от доменных экспертов.

Что получилось на практике: точность и скорость

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

На выходе получилась система, которая в реальном запуске показала около 90% точности по человеческой оценке (question-level accuracy 89.5% на in-scope вопросах) и при этом удержала P90 задержку ниже 15 секунд (13.56s). Для “разговорной аналитики”, где часто нужно сходить за данными, агрегировать и только потом объяснить, это довольно сильный инженерный компромисс.

Отдельно показательно, что быстрые ML-модули действительно помогают: автоэнкодер для OOD даёт очень высокую precision и работает за доли миллисекунды на пример, а маршрутизация на лёгком BERT обгоняет LLM-классификатор и по точности, и по latency.

Что это значит и куда двигаться дальше

Insight Agents — хороший пример того, как LLM стоит “встраивать” в продуктовую аналитику: не как единственный мозг на все случаи, а как часть оркестрации, где рядом работают быстрые фильтры, планирование, ограниченные инструменты доступа к данным и доменные заготовки. Такой подход снижает риск галлюцинаций, экономит время и делает ответы повторяемыми — то есть пригодными для бизнеса, а не только для демо.

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