Как мы научили алгоритм видеть тренды раньше конкурентов

Как мы научили систему различать тренды: от сырых данных к методологии V2

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

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

Первый день: копание в данных

Первым делом я создал серию исследовательских отчётов. Начал с 01-raw-data.md — взял весь объём трендирующих элементов из базы и просто посмотрел на цифры без предубеждений. Какие сигналы вообще есть? Какие данные полны, а какие похожи на швейцарский сыр? Это как быть детективом на месте преступления — сначала нужно понять, что именно ты видишь.

Потом пригласил в процесс экспертов. 02-expert-analysis.md — это был мозговой штурм в текстовом формате. Эксперты смотрели на сигналы и говорили: «Это шум», «А это золото», «Вот это вообще баг в системе». Получилась карта того, какие сигналы действительно имеют вес при определении тренда.

Вторая волна: архитектура методологии

Третий отчёт, 03-final-methodology.md, был поворотным. Мы поняли, что один скор — это неправда. Тренд не может быть описан одним числом. Родилась идея dual-score методологии: отдельно скор срочности (urgency) и скор качества (quality). Срочность показывает, насколько быстро что-то растёт прямо сейчас. Качество показывает, насколько это вообще надёжный сигнал.

Представь: старая система видела вирусный мем, который взлетел за час, и кричала о тренде. А потом через два часа мем забыли, и система выглядела глупо. Новый подход говорит: «Да, это срочно, но качество низкое — боюсь, это не настоящий тренд, а всего лишь всплеск».

04-algorithms-validation.md — это была проверка на прочность. Мы взяли исторические данные и прогнали их через алгоритм валидации. Ловили edge cases: что если все сигналы нулевые? Что если они противоречивы? Что на границах данных? Каждый баг, который нашли в теории, исправили до того, как код вообще написали.

Последняя фаза: осознание пробелов

05-data-collection-gap.md был честным разговором с самими собой. Мы поняли, что нам не хватает информации. Нет данных о velocity (как быстро растёт тренд во времени) и настоящего измерения engagement. Мы просто не собирали эту информацию раньше.

Вот здесь и пришёл 06-data-collection-plan.md — план того, как мы будем собирать недостающие сигналы. Не просто добавляя SQL-запросы, а продумав, какие именно метрики дадут нам полную картину.

Что дальше?

Весь этот мозговой марафон — это фундамент для реальной реализации. Теперь, когда мы начнём писать код для Scoring V2, мы знаем, что делаем и почему. Нет наугад, нет сомнений. Только чёткая методология и валидированные алгоритмы.

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

😄 Почему scikit-learn считает себя лучше всех? Потому что Stack Overflow так сказал.