Почему никто не объясняет аномалии во временных рядах?

[CrissSquirrel]

Что насчёт внутренних проблем? Допустим, сбой случился из-за нашей собственной ошибки: криво обновили код, упала своя база данных или нахлынули боты. В открытом интернете про это ни слова. Сможет ли WhyTrend понять, в чём дело, или он в любом случае начнёт подгонять под эту дату внешние новости, даже если они не при чём?

[AlexProvatorov]

Фреймворк модульный и сам по себе «внутренности» компании не видит. Если в Pipeline подключены только внешние источники (Google News, Hacker News и т.п.), а про ваш деплой / падение БД / наплыв ботов в открытом интернете тишина, WhyTrend не сможет надёжно назвать настоящую причину: у него просто нет этих данных.

В лучшем случае, когда внешний контекст пустой или явно слабый, LLM по системному промпту должна сказать, что внешних подтверждений нет, и снизить confidence. Но если внешние новости за ту же дату просто «рядом» по словам, модель всё ещё может ошибочно к ним притянуться — это не железный отказ по низкому BM25 (ranker сейчас ранжирует, а не отбрасывает шум).

Прелесть WhyTrend в другом: пользователь может написать свой InternalSlackCollector или GitLabReleasesCollector на базе BaseCollector, подключить через .add_collector(...) в Pipeline — и тогда фреймворк сможет связать внутренний деплой / инцидент с графиком метрик. Без внутренних источников остаётся честный ответ: «аномалия есть, внешней причины не видно».

[Kriketo]

С Google Trends и хайповыми темами вроде DeepSeek пример выглядит очень убедительно, так как в эти дни интернет буквально гремел новостями. А тестировался ли фреймворк на более специфичных и "тихих" бизнес-метриках? Например, если у нас локальный интернет-магазин автозапчастей и внезапно подскочили продажи конкретной категории. Сможет ли BM25 выудить крупицы полезного контекста из условных новостей индустрии, или для узких ниш придется писать кастомные внутренние Collectors (например, парсить календарь акций конкурентов)?

[AlexProvatorov]

Да — на одних только стандартных публичных коллекторах (Wikipedia / HN / общий Google News) узкий B2B-кейс вроде локального магазина автозапчастей обычно не взлетит: в открытом интернете часто просто нет сигнала, а BM25 ранжирует уже собранное и «из воздуха» индустриальный контекст не достанет.

WhyTrend задуман как фреймворк (подключаемые Source / Collector / Ranker / Explainer), а не готовое SaaS «под любую нишу из коробки». Сила в том, что под задачу пишете свой CompetitorPromoCollector или OrdersSQLCollector, цепляете в Pipeline — а ранжирование и суммаризацию WhyTrend берёт на себя. Для тихих бизнес-метрик кастомные (часто внутренние) collectors — нормальный и ожидаемый путь, а не костыль.

[ToxaBes]

Спасибо за обзор, отличная идея, хотелось бы только уточнить как ваш фреймворк борется с ложными корреляциями?

Дело в том, что LLM по своей природе склонны находить причинно-следственные связи там, где есть только совпадение во времени. Если в день случайного выброса на графике в новостях происходило что-то отдаленно похожее, BM25 подтянет эту статью, а LLM уверенно сгенерирует красивое, но абсолютно ложное объяснение.

[AlexProvatorov]

Спасибо за вопрос — это главная ловушка explainable anomaly detection / RAG.

WhyTrend не претендует на доказательство причинности. Задача сейчас — быстро собрать кандидатов и черновик гипотезы, а не заменить каузальный анализ.

Как снижаем риск ложной корреляции (мягко):

1. Ограничение контекста. LLM видит только collectors + ranker; промпт запрещает выдумывать факты и просит при слабом evidence снизить confidence. Галлюцинаций меньше, но «дотянуть» историю из совпадения по дате модель всё ещё может.

2. Прозрачность. В отчёте остаются cited causes (источник, URL, score) и confidence — аналитик видит, на чём стоит вывод, и может отбраковать мусор.

3. Модульность. Для узких метрик лучше свои collectors (деплои, акции, логи), а не надежда, что Google News + BM25 отделят причину от шума.

Жёсткого фильтра «только совпадение → drop», каузальных тестов и обязательного no_causal_link пока нет: BM25/embeddings ранжируют похожесть текста, не причинность.

В планах — слой после ranker (до explainer): пороги relevance, умнее rerank и явный вердикт (evidence_insufficient / correlation_only / likely_cause). Плюс на стороне ряда в dev уже есть ZScoreDetector, ProphetDetector и RupturesDetector — разные типы аномалий ловим, а вот anti false-correlation для объяснений как раз следующий шаг что добавиться в roadmap. Спасибо, что подсветили это.

[ToxaBes]

Теперь понял, спасибо за ответ.