TimesFM 3.0 в BigQuery: как подготовить прогноз продаж с календарём акций

Новость — подробный разбор preview в BigQuery

12 октября 2026 года Google показала многомерное прогнозирование TimesFM 3.0 в BigQuery. Функция уже отмечена как preview в release notes от 7 октября; сама модель представлена Google Research 31 августа. Это не дата появления новой модели с нуля и не объявление общей доступности.

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

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

Задание аналитику: три разных роли у столбцов

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

1. Что прогнозируем: проданные порции кофе и выпечки. Это два целевых столбца, TARGET_COLS. Для прошлых дат в них записан согласованный факт; для будущих — NULL. Не добавляйте план продаж руководителя в будущую часть как будто это наблюдение.
2. Что знаем только после окончания дня: число посетителей. Если у точки есть надёжный счётчик, это кандидат в PAST_COVARIATE_COLS. В будущих строках значение остаётся NULL. Подставить будущий фактический поток в исторический тест значит дать модели сведения, которых у планировщика тогда не было.
3. Что известно заранее: выходной день и утверждённая акция. Для FUTURE_COVARIATE_COLS подготовьте числовые признаки, например 1 — событие действует, 0 — не действует. Они должны описывать и историю, и весь будущий горизонт. Неизвестный план акции нельзя молча превратить в ноль.

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

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

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

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

Что проверить до оплаты пилота

Официальный учебный сценарий требует проекта Google Cloud, включённого биллинга, доступа к BigQuery и прав на нужные данные и задания. Поэтому этот вариант проще оценивать компании, у которой подготовленная история уже находится в BigQuery. Перенос учёта ради одной демонстрации — отдельный проект.

В справочнике AI.FORECAST TimesFM 3.0 остаётся preview с возможной ограниченной поддержкой; по умолчанию используется 2.5. Для многомерного расчёта нужно явно выбрать 3.0. Максимальная история, передаваемая этой версии, — 2 048 точек, горизонт — 1 024 точки. Сверхлимитная история не используется моделью; это не разрешение удалить её из учёта.

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

Считайте текущий пилот и дальнейшую работу отдельно

Документация тарификации указывает: в preview Enterprise и Enterprise Plus используют оплату слотами, on-demand — по обработанным байтам. С 1 декабря 2026 года заявлен переход на оплату токенов модели плюс обычное потребление остальной части запроса. Перед продолжением пилота в декабре проверьте действующие условия ещё раз.

Запросите две сметы: ограниченный тест сейчас и регулярный пересчёт после перехода. В обеих учтите подготовку истории, хранение, частоту запусков, повторные тесты и работу аналитика. Без объёма данных и выбранного тарифа обещать фиксированную стоимость на точку нельзя.

Есть важное отличие способов использования. Google прямо поясняет, что работа TimesFM через BigQuery допускает коммерческое использование по условиям Google Cloud. Некоммерческая лицензия скачиваемых весов TimesFM 3.0 относится к самостоятельному размещению. Не переносите разрешение BigQuery автоматически на собственный сервер; условия выбранного варианта следует проверить до внедрения.

Как принять результат без обещания роста продаж

Для проверки полезности календаря акций попросите сравнить на одинаковых исторических датах выпуска и одном горизонте TimesFM 3.0 с колонкой акции и без неё. Признак выходного дня и остальные условия оставьте неизменными. На каждом срезе используйте только ту версию календаря, которая была утверждена и доступна к моменту выпуска прогноза; рядом покажите действующий простой прогноз. Это редакционная схема эксперимента, не доказательство превосходства модели. Определение ошибки можно взять из разбора WAPE, MAPE и смещения, не пересоздавая методику под удачный результат.

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

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

Источники проверены 13 октября 2026 года UTC. Автор: редакция SABSUS. Пример таблицы и критерии проверки — редакционные рекомендации. Модель, интеграция и экономический результат в клиентском аккаунте не тестировались.