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

Как мы научили систему анализа трендов видеть связи между явлениями

Работаем над проектом trend-analysis — это система, которая анализирует тренды в данных и выявляет причинно-следственные связи. Всё интересно, но вот беда: когда аналитик хочет глубже погрузиться в конкретный тренд, система не могла его за ручку взять и показать, откуда вообще взялась эта информация. Анализы существовали сами по себе, графики — сами по себе. Нужно было связать их воедино.

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

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

Дальше — самая интересная часть. Нужно было хранить эту информацию, поэтому добавили поле trend_id в таблицу analyses. Но одного сохранения мало — нужно было ещё и по-человечески отображать результат. Началось с описаний эффектов: когда система выявляет причинно-следственную связь (это называется causal_chain в кодовой базе), она может объяснить, почему один фактор влияет на другой. Мы вытащили эти рассуждения (rationale) и превратили их в читаемые описания эффектов — теперь они отображаются прямо на интерактивном графе.

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

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

Всё это потребовало фиксов в типах TypeScript для навигации по параметрам поиска — система должна была знать, какие параметры можно передавать и как они называются. Без этого была бы путаница с undefined и ошибки во время выполнения.

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

В итоге: система стала гораздо более связной. Теперь аналитик видит не просто скучную таблицу с анализами, а историю того, как конкретный тренд повлиял на другие явления, с объяснениями на его языке. Граф перестал быть набором непонятных точек и стал рассказывать. Обновили CHANGELOG, и задача легла в историю проекта.

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

😄 Почему граф анализа пошёл к психологу? Потому что у него было слишком много глубоких связей.