Google Flu Trends: когда большая модель проиграла простому baseline

Коротко

Google Flu Trends оценивал распространение гриппа по поисковому поведению и сравнивался с традиционными наблюдениями. На раннем этапе подход получил много внимания, но позже исследователи показали эпизоды значительного завышения. В одном из разборов модель переоценивала активность в 100 из 108 недель рассматриваемого периода.

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

• Сравнивай модель с простым baseline.
• Разделяй in-sample качество и прогноз в новых условиях.
• Следи за изменением источника сигнала.
• Не скрывай модель за красивым dashboard score.

Что именно сломалось

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

Это классический сдвиг data-generating process. Колонки в таблице могут остаться теми же, а смысл наблюдения изменится. Для модели это выглядит как новый сигнал болезни, хотя на самом деле изменилась коммуникация вокруг болезни.

Почему большой объём данных не спас

Большая выборка уменьшает случайный шум, но не исправляет систематическую ошибку. Если все миллионы наблюдений измеряют не тот объект, модель будет очень уверенно считать неправильный ответ. Это особенно опасно для прокси-метрик: они удобны, потому что результат появляется быстро, но связь с реальным outcome может быть нестабильной.

Вторая проблема — сложность модели и отсутствие прозрачности. Когда аналитик не может назвать признаки, версии, пороги и дату последней проверки, невозможно понять, сломался источник, коэффициент или само определение target.

Как проверить похожую модель в СНГ

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

Для SaaS похожий риск возникает с сигналом «интерес к функции»: просмотры документации могут расти из-за ошибки, а не из-за adoption. Для банка — с поисками условий кредита. Во всех случаях прокси нужно проверять через фактическое действие и держать независимый baseline.

• Собери target из операционной системы, а не только из digital-сигнала.
• Делай time-based split и отдельный holdout после релиза.
• Храни feature drift и долю неизвестных значений.
• Добавь ручной review для решений с высокой стоимостью ошибки.

Рабочая схема контроля

Перед запуском зафиксируй, что именно модель предсказывает, в какой момент доступен каждый признак и какое действие последует за прогнозом. Затем сравни сложную модель с последним наблюдаемым значением, сезонным правилом и простым регрессионным baseline. Если сложная система выигрывает только на исторических данных, это не победа.

После запуска мониторь не один score, а три слоя: входы, предсказания и реальные outcomes. Для каждого сигнала должен быть порог, владелец и действие: остановить автоматическое решение, перекалибровать, обучить заново или перейти на fallback.

from sklearn.metrics import mean_absolute_error

train = data[data['period'] < '2025-01']
test = data[data['period'] >= '2025-01']

baseline = test['target'].shift(1).fillna(train['target'].iloc[-1])
mae = mean_absolute_error(test['target'], baseline)
print(f'baseline MAE: {mae:.3f}')

Практика для аналитика

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

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

• Сравнить с наивным прогнозом.
• Проверить out-of-time период.
• Посмотреть график ошибки по сегментам.
• Назначить условие остановки автоматизации.

Вывод для команды

Урок Google Flu Trends не в том, что большие данные плохи. Он в том, что модель должна быть частью измерительного процесса: с независимым target, baseline, мониторингом дрейфа и понятным уровнем доверия. Быстрый сигнал полезен, пока команда помнит, что это сигнал, а не сама реальность.

Для бизнеса в СНГ практическое правило простое: чем дороже решение, тем меньше права у одной непрозрачной метрики. Прогноз помогает сузить внимание, но финальное действие должно опираться на несколько источников и проверяемое ограничение.

Как превратить публичный факап в рабочий процесс

История «Google Flu Trends: когда большая модель проиграла простому baseline» полезна только тогда, когда превращается в конкретный способ работы. Не начинай с вывода «у нас такого не случится». Сначала выпиши объект измерения, решение, которое зависит от сигнала, и момент, когда ошибка становится дорогой. Для прогноза это может быть закупка, для эксперимента — rollout, для дашборда — изменение бюджета или приоритета команды.

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

Такой разбор помогает не копировать масштаб крупной компании. В локальном продукте может не быть отдельной платформы экспериментов или команды исследователей, но может быть короткий design document, SQL-проверка, журнал изменений и еженедельный review отклонений. Этого достаточно, чтобы снизить самые дорогие ошибки до появления сложной инфраструктуры.

• Назвать outcome и бизнес-решение.
• Отделить прокси от фактического результата.
• Зафиксировать baseline и период проверки.
• Назначить владельца сигнала и fallback.
• Сохранить версию расчёта и историю решений.

Минимальный контур данных для команды в СНГ

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

Для каждого сигнала заведи паспорт: название, определение, grain, источник, окно, исключения, owner, дата последней проверки и известные ограничения. Если речь о модели, добавь target, момент доступности признаков, версию датасета, baseline и метрики по ключевым сегментам. Если речь об эксперименте, добавь unit, exposure, eligibility, primary и guardrails.

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

Как принять решение после сигнала

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

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

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

• Что мы знаем точно?
• Какая гипотеза объясняет сигнал?
• Какой следующий тест дешевле всего?
• Какой guardrail остановит решение?
• Когда и кто пересмотрит результат?

Источники и границы адаптации

Это не перевод исходных публикаций и не попытка выдать внутренние процессы компании за полную картину. Мы берём публично описанные факты, выделяем аналитическую механику и переносим её на задачи команд в СНГ: продуктовые метрики, маркетплейсы, SaaS, e-commerce и внутренние системы.

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