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

Ключевая инженерная задача — преобразовать поток неструктурированного текста в структурированные события, с которыми может работать остальная система. Ежедневно обрабатываются сотни событий, и ручная модерация плохо масштабируется, поэтому ставка сделана на автоматизацию. Часть работы выполняет LLM-конвейер, часть — сами пользователи, которые могут сообщать о событиях и проверять сообщения друг друга. Пользователь задаёт локацию любой степени детализации — от целого региона до района в городе — и интересующие категории опасности, а система на основе этих фильтров доставляет только релевантные оповещения. Таким образом, из каждого поста необходимо выделить категорию события и географическую привязку.

Архитектурно система состоит из нескольких этапов. Отдельный Telegram-скрейпер читает каналы и складывает новые посты во входящую очередь. Затем сообщение проходит тематическую фильтрацию, извлечение события, определение и проверку локации, дедупликацию, подбор получателей и постановку в очередь доставки. Для хранения используются Postgres (основные данные и надёжная очередь доставки), Qdrant (векторы для поиска потенциальных дублей) и Redis (входящая очередь и управление скоростью отправки для соблюдения лимитов Telegram). Центральная роль отведена LLM: она проверяет релевантность публикации выбранной теме, извлекает пары «регион + локация» (одна публикация может описывать события в нескольких городах), формулирует краткое описание, проверяет, действительно ли событие произошло в указанном месте, и выступает арбитром в неоднозначных случаях дедупликации. Промпты настраиваются отдельно для каждой категории и хранятся в Postgres, что позволяет добавлять новые категории опасности без правки кода приложения. Значительная сложность связана с вызовами LLM: предусмотрены тайм-ауты, резервная модель и повторные попытки с экспоненциальной задержкой, поскольку внешний API может отвечать медленно, быть временно недоступным или возвращать результат, не соответствующий ожидаемой схеме.

Дедупликация — критически важный этап, так как одно событие за короткое время могут описать десятки каналов. Прямое сравнение текстов неэффективно: один источник пишет о «взрывах в районе промзоны», другой — о «работе ПВО над городом», хотя речь может идти об одном и том же. Поэтому применяется двухуровневый подход. Сначала эмбеддинги быстро отбирают потенциально похожие события по семантической близости, не требуя дословного совпадения. Затем сравниваются локации событий: семантически почти одинаковые сообщения из разных городов нельзя объединять. Найденный дубль не удаляется, а добавляется к существующему событию как дополнительный источник; если новая публикация уточняет информацию, оповещение может быть обновлено. Геокодирование также играет ключевую роль: после извлечения LLM может вернуть строку вроде «Шебекино», и географический модуль должен превратить её в структуру, позволяющую определить получателей и сравнить геометрию событий. Сравнивать названия как строки неудобно: «Шебекино» и «Шебекинский городской округ» могут относиться к одной территории, а одинаковые названия населённых пунктов встречаются в разных регионах. Поэтому и место события, и выбранная пользователем территория приводятся к единому представлению — пути в дереве административных границ. Россия, Краснодарский край, Туапсе, Сочи, Центральный район — пример такого пути. Построение пути идёт в два этапа: сначала название нормализуется через Google Maps, который возвращает официальное название, регион, город и координаты (это помогает, например, если в посте указано «ТЦ Европейский» без адреса — геокодер определит, что это в Москве). Затем по нормализованным данным ищется соответствующая территория среди административных границ OpenStreetMap. Полигоны хранятся в PostGIS, а цепочка административных уровней — в Postgres как ltree.

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

Для российского рынка подобные системы могут быть востребованы в условиях, когда доступ к официальным каналам оповещения ограничен или запаздывает. Пользователи получают персонализированные уведомления, что снижает информационный шум. Однако остаются риски, связанные с зависимостью от внешних API (Google Maps, LLM-провайдеры), которые могут быть недоступны или ограничены в работе на территории России. Кроме того, вопросы конфиденциальности и защиты данных пользователей требуют отдельного внимания. Реакция отрасли пока не известна, но проект демонстрирует, как современные технологии — LLM, векторный поиск, ГИС — могут применяться для решения социально значимых задач в реальном времени.

По сравнению с альтернативами, такими как ручной мониторинг каналов или простые боты на ключевых словах, «Мигалка» предлагает более глубокую семантическую обработку и геопространственную дедупликацию. Это снижает количество ложных срабатываний и повышает релевантность. Однако сложность архитектуры требует значительных ресурсов: поддержка нескольких хранилищ, настройка промптов, обработка отказов LLM. В перспективе развитие системы может идти в сторону расширения категорий опасности, улучшения моделей геокодирования и, возможно, добавления краудсорсинговой верификации. Открытыми остаются вопросы масштабирования на другие регионы, интеграции с официальными службами и обеспечение отказоустойчивости при пиковых нагрузках. Также неясно, как система собирается монетизироваться или поддерживаться, что важно для долгосрочной устойчивости.