Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
Что насчёт внутренних проблем? Допустим, сбой случился из-за нашей собственной ошибки: криво обновили код, упала своя база данных или нахлынули боты. В открытом интернете про это ни слова. Сможет ли WhyTrend понять, в чём дело, или он в любом случае начнёт подгонять под эту дату внешние новости, даже если они не при чём?
Фреймворк модульный и сам по себе «внутренности» компании не видит. Если в Pipeline подключены только внешние источники (Google News, Hacker News и т.п.), а про ваш деплой / падение БД / наплыв ботов в открытом интернете тишина, WhyTrend не сможет надёжно назвать настоящую причину: у него просто нет этих данных.
В лучшем случае, когда внешний контекст пустой или явно слабый, LLM по системному промпту должна сказать, что внешних подтверждений нет, и снизить confidence. Но если внешние новости за ту же дату просто «рядом» по словам, модель всё ещё может ошибочно к ним притянуться — это не железный отказ по низкому BM25 (ranker сейчас ранжирует, а не отбрасывает шум).
Прелесть WhyTrend в другом: пользователь может написать свой InternalSlackCollector или GitLabReleasesCollector на базе BaseCollector, подключить через .add_collector(...) в Pipeline — и тогда фреймворк сможет связать внутренний деплой / инцидент с графиком метрик. Без внутренних источников остаётся честный ответ: «аномалия есть, внешней причины не видно».
С Google Trends и хайповыми темами вроде DeepSeek пример выглядит очень убедительно, так как в эти дни интернет буквально гремел новостями. А тестировался ли фреймворк на более специфичных и "тихих" бизнес-метриках? Например, если у нас локальный интернет-магазин автозапчастей и внезапно подскочили продажи конкретной категории. Сможет ли BM25 выудить крупицы полезного контекста из условных новостей индустрии, или для узких ниш придется писать кастомные внутренние Collectors (например, парсить календарь акций конкурентов)?
Да — на одних только стандартных публичных коллекторах (Wikipedia / HN / общий Google News) узкий B2B-кейс вроде локального магазина автозапчастей обычно не взлетит: в открытом интернете часто просто нет сигнала, а BM25 ранжирует уже собранное и «из воздуха» индустриальный контекст не достанет.
WhyTrend задуман как фреймворк (подключаемые Source / Collector / Ranker / Explainer), а не готовое SaaS «под любую нишу из коробки». Сила в том, что под задачу пишете свой CompetitorPromoCollector или OrdersSQLCollector, цепляете в Pipeline — а ранжирование и суммаризацию WhyTrend берёт на себя. Для тихих бизнес-метрик кастомные (часто внутренние) collectors — нормальный и ожидаемый путь, а не костыль.
Спасибо за обзор, отличная идея, хотелось бы только уточнить как ваш фреймворк борется с ложными корреляциями?
Дело в том, что LLM по своей природе склонны находить причинно-следственные связи там, где есть только совпадение во времени. Если в день случайного выброса на графике в новостях происходило что-то отдаленно похожее, BM25 подтянет эту статью, а LLM уверенно сгенерирует красивое, но абсолютно ложное объяснение.
Спасибо за вопрос — это главная ловушка explainable anomaly detection / RAG.
WhyTrend не претендует на доказательство причинности. Задача сейчас — быстро собрать кандидатов и черновик гипотезы, а не заменить каузальный анализ.
Как снижаем риск ложной корреляции (мягко):
Ограничение контекста. LLM видит только collectors + ranker; промпт запрещает выдумывать факты и просит при слабом evidence снизить confidence. Галлюцинаций меньше, но «дотянуть» историю из совпадения по дате модель всё ещё может.
Прозрачность. В отчёте остаются cited causes (источник, URL, score) и confidence — аналитик видит, на чём стоит вывод, и может отбраковать мусор.
Модульность. Для узких метрик лучше свои 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. Спасибо, что подсветили это.
Какие LLM использовали для генерации кода проекта?
Никакие :) Весь код проекта от первой до последней строчки написан вручную. Кода там на самом деле не так много, архитектура достаточно компактная, и мне было важно и интересно самому спроектировать взаимодействие через протоколы (typing.Protocol) и логику конвейера. Так что в плане логики тут исключительно чистый ручной крафт!
Единственное — я привлекал LLM, чтобы немного "причесать" структуру и английский язык в README. Но на саму кодовую базу это никак не повлияло.
Спасибо за вопрос)
Как именно формируется запрос для поиска? Откуда беруться ключевые слова или на основании чего формируется поисковый эмбединг?
Рассмотрим пример:
Допустим в продуктовом магазине А в день хх.хх.2026 случился небывалый наплыв покупателей и мы хотим узнать причину этого.
Допустим что реальная причина - в магазине Б (основном конкуренте) в этот день был пожар и все покупатели микрорайона были вынуждены идти за продуктами в магазин А.
Как фреймворк обнаружит эту причину? Ведь в анализируемом временном ряду нет ключевого слова "пожар".
Спасибо за отличный вопрос. Отвечу структурно.
Keyword задаёт аналитик при сборке пайплайна (CSVSource(..., keyword="..."), GoogleTrends("...") и т.п.). Ряд даёт только момент аномалии и окно ±window_days. Collectors ищут внешние материалы по этому keyword и датам. Ranker (BM25 или embeddings) упорядочивает уже найденные тексты — эмбеддинг не "угадывает причину из графика", а ранжирует документы относительно запроса/события.
Магазин A и пожар в B
Если keyword — только "магазин A", фреймворк сам слово "пожар" не выведет. Причину найдет лишь если в окне дат попалась подходящая новость/пост и она поднялась в ранге — или если аналитик задал более широкий/умный keyword. Иначе честный исход: мало evidence или ложная/слабая корреляция.
WhyTrend не заменяет аналитика и не выводит причинность из кривой. Он ускоряет рутину: быстрее карта аномалий + черновик гипотез со ссылками в том же временном окне(автоматизация рутины). Гипотезу, keyword и финальный вывод по-прежнему делает человек.
Завтра выйдет статья про "разбор аномалий BTC 2022–2026 с WhyTrend". Рассмотрим как это работает на практике: keyword + окно + внешний контекст. Как раз релевантный кейс — длинный ряд, много переломов, keyword очевиден (Bitcoin), причины обычно в том же информационном поле (новости/HN в окне дат), а руками это долго гонять по каждой точке. Фреймворк как раз ускоряет эту рутину: карта аномалий -> контекст -> черновик гипотез. Там будет видно где и в чем происходит ускорение работы аналитика. Не "доказали причинность", а "быстро собрали расследование по публичному рынку".
Кейс с пожаром у конкурента — другая задача: нужна гипотеза аналитики или более широкий keyword.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему никто не объясняет аномалии во временных рядах?