Как подключить ML-модель к BI

Определить решение и простое правило для сравнения

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

Сложную модель сравнивают с доступным простым правилом, например прогнозом по прошлому сопоставимому периоду. Такое сравнение предусмотрено и в рекомендациях scikit-learn. Кроме общей ошибки, полезно видеть результат по магазинам, категориям и товарам с редкими продажами. Для планирования также различают завышение и занижение: одинаковая абсолютная ошибка может приводить к разным действиям.

Исключить сведения из будущего

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

Утечка возможна и при подготовке признаков. Средние для заполнения пропусков, параметры масштабирования и отбор признаков должны определяться на обучающей части. В документации scikit-learn для этого рекомендуется Pipeline, применяемый внутри процедуры проверки. Он помогает правильно обучать преобразования, но не обнаружит автоматически признак, смысл которого раскрывает будущее.

Проверить на последующих периодах

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

TimeSeriesSplit — один из инструментов такой проверки, а не универсальный рецепт. Его документация оговаривает равномерный шаг наблюдений для сопоставимости периодов между разбиениями. Для панели «магазин × товар» обычно отдельно проектируют границы по календарным датам, чтобы строки одной прогнозной недели не оказались одновременно по обе стороны разделения.

Выбрать момент расчёта в BI

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

Таблица прокручивается влево и вправо

В классическом Qlik SSE внешние вычисления подключаются через протокол gRPC. В аналитических соединениях Qlik Cloud SSE-синтаксис преобразуется в REST-запросы к моделям. Это разные механизмы. Скрипт загрузки и выражение диаграммы также имеют разные ограничения на возвращаемые данные.

Передавать результат с его контекстом

Рекомендуемый состав записи — идентификатор объекта, дата расчёта, прогнозируемый период, значение, версия модели и статус обработки. Рядом с графиком указывают, где факт, а где оценка. Если расчёт не выполнен или устарел, это отдельное состояние, которое нельзя незаметно заменять нулём.

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

Проверять модель после внедрения

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

Рекомендации Google по ML-системам отдельно описывают расхождения между подготовкой данных при обучении и применении. Практическая мера — сохранять достаточный контекст расчёта для расследования. Заранее определённое резервное правило позволяет продолжать работу при сбое модели; условия его включения и последующего возврата проверяют вместе с основным сценарием.