Как распределить роли кода и LLM в аналитике

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

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

Сначала зафиксируйте смысл показателей

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

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

Эта подготовка относится и к данным. Отчёты площадок могут использовать разные модели выплат; их приводят к единой P&L-логике. Расхождение по SKU полезно помечать аномалией и разбирать отдельно. Усреднение тоже требует явного решения: для ряда показателей подходит средневзвешенное значение, тогда как обычное среднее создаёт ложную картину.

Почему сырая выгрузка создаёт риск

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

Есть и более тонкая проблема: модель уверенно достраивает пропущенную причинность. Например, падение заказов за прошлую неделю можно ошибочно объяснить отсутствием товара, которое началось только позднее. Красивое объяснение труднее проверить, чем арифметическую ошибку, поэтому границы задачи модели важно задавать заранее.

В модель не стоит передавать всю базу и разрешать ей произвольный SQL. Практичнее дать закрытый набор типизированных инструментов: период, сравнение с прошлым периодом, конкретный срез витрины. LLM выбирает бизнес-параметры, а фильтры, лимиты и доступ к таблицам контролирует приложение. Это снижает риск тяжёлых запросов и инъекций.

Конвейер из пяти этапов

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

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

Такое разделение сохраняет воспроизводимость там, где она критична: в цифрах и диагнозе. Текст объяснения может немного меняться от версии модели к версии, однако его вариативность не меняет исходные расчёты.

Сигналы должны быть проверяемыми

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

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

Одинаковый симптом далеко не всегда означает одинаковую причину. При падении заказов одной карточки проверка может показать остаток около 16 единиц при расходе около 200 единиц в день и нулевые размеры. В другой карточке остатки окажутся нормальными, зато вырастут отмены и снизится рекламная конверсия. Первый случай относится к запасам, второй — к качеству предложения и релевантности. Фиксированная последовательность проверок отделяет эти сценарии точнее, чем общий вопрос «почему упали заказы?».

Объяснение тоже нуждается в ограничениях

Готовые цифры защищают от ошибок в расчёте, но модель всё ещё может перепутать причины и следствия. Полезно включить в правила объяснения несколько санитарных проверок. Состояние запасов должно относиться к анализируемому периоду; лаг между заказом и перечислением денег на маркетплейсе может составлять 5–14 дней; конверсия выше 100 %, отрицательный остаток или отрицательная доля рекламных расходов требуют пометки как ошибки данных.

Промпт также должен требовать альтернативные объяснения там, где видна только корреляция. Рост продаж после запуска рекламы может совпасть с сезонным спросом. Снижение цены на 30 % при росте объёма в четыре раза выглядит успешно, пока расчёт не покажет, что логистика, приёмка и хранение съели маржу. Модель должна опираться на рассчитанные сигналы и обозначать границы уверенности.

При этом текст не следует превращать в протокол всех проверок. В ответ попадают только сработавшие условия и один приоритетный вывод; полный чек-лист остаётся внутри системы. Так руководителю легче увидеть суть, а аналитик сохраняет путь к деталям.

Данные можно минимизировать

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

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

Граница между кодом и LLM превращает ИИ-аналитику из чата с выгрузкой в поддерживаемый процесс. Качество такой системы определяется методикой расчёта, чистотой данных, набором проверяемых сигналов и дисциплиной объяснения. Именно эти части стоит проверять при выборе или проектировании аналитического помощника.