Что такое Fire Monitor и зачем понадобился GeoAI-агент
Fire Monitor - система мониторинга лесных пожаров, которой управляет GeoAI-агент на базе модели Qwen3.7-Plus. Агент крутит ReAct-цикл «рассуждение + действие»: собирает термоточки со спутников VIIRS и MODIS, оценивает масштабы выгорания территории по снимкам Sentinel-2, строит маршруты от ближайших пожарных частей к очагу по дорожной сети для пожарных машин, рассчитывает траектории (галсы) для облёта территории беспилотниками. Систему сделала команда «Стрела» и показала на Космохакатоне-2026 (разбор проекта на Habr).
Задача хакатона формулировалась так: на основе исходных данных дистанционного зондирования Земли сделать программный продукт, которым реально захотят и смогут пользоваться пожарные, спасатели и экологи. Им нужно мониторить возникновение чрезвычайных ситуаций, предотвращать их и анализировать последствия.
GeoAI-агент в этом кейсе означает LLM, которой выдали геопространственные инструменты и право самой решать, какой из них вызвать. Пользователь пишет обычным языком: «Найди активные пожары в Иркутской области за последние сутки и отправь туда ближайшие пожарные расчеты». Модель разбирает запрос на шаги, вызывает инструменты и отдаёт результат, а не список ссылок на ручной разбор.
Почему дашборд с фильтрами не работает для диспетчера
Классическую идею с кучей кнопок и фильтров команда отбросила. Причина простая: когда у диспетчера на экране загораются сотни красных точек по всей стране, такой дашборд скорее пугает, чем помогает. Одинаковые по виду отметки не различаются по срочности, за ними не видно приоритетов, и внимание человека быстро расходуется.
Агент переворачивает логику: фильтрацию, сопоставление и ранжирование берёт на себя модель, а человек формулирует задачу словами. Это архитектурное решение, а не украшение интерфейса.
Как выглядит интерфейс: карта слева, чат справа
Экран разделён надвое: слева интерактивная карта со слоями, справа чат с AI-ассистентом, который понимает человеческий язык и управляет системой. Запрос можно набрать текстом или произнести голосом.
Детали оформления слоёв и полный список элементов карты в доступном описании не раскрыты, поэтому дальше речь только о схеме: запрос словами, ответ объектами и слоями на карте.
Архитектура Fire Monitor: Django, PostGIS, React и FastMCP
Оговорка по источникам: в открытой публикации подробно разобрана только вводная часть проекта. Детали стека ниже приводятся по материалам команды и не подтверждены независимой проверкой, так что читайте их как заявленную архитектуру, а не как проверенные цифры.
Стек собран из четырёх основных частей:
- Django REST Framework держит бэкенд и API для чата, карты и внешних потребителей.
- PostgreSQL 16 с PostGIS 3.4 хранит геоданные и считает пространственные операции: пересечение полигонов, буферы, расстояния, попадание точки в зону.
- React с MapLibre GL JS отвечает за фронтенд с векторной картой и переключаемыми слоями.
- FastMCP-сервер оборачивает инструменты под Model Context Protocol, чтобы агент видел их по стандартной схеме.
Логика выбора понятна: PostGIS умеет то, что на стороне приложения писать долго и медленно, MapLibre рендерит векторные слои в браузере без проприетарных лицензий, FastMCP превращает обычные функции в инструменты агента. Как устроен слой инструментов и оркестрация в агентских системах в целом, разобрано в статье про архитектуру самописного AI-агента на Python.
Поток данных: пользователь пишет в чат, LLM определяет намерение, ReAct-цикл выбирает инструмент, инструмент обращается к базе или внешнему сервису, ответ возвращается модели. Дальше она либо формулирует результат, либо запускает следующий вызов.
Три интерфейса подключения инструментов: MCP, function calling и REST API
Изначально агенту выдали 9 инструментов, управляемых через три интерфейса (описание на Habr).
| Интерфейс | Для чего нужен | Кто потребитель |
|---|---|---|
| Model Context Protocol | Стандартизованная отдача инструментов внешним системам | Другие AI-агенты |
| Function calling | Вызов инструментов моделью прямо из чата | Пользователь в веб-интерфейсе |
| REST API | Классические HTTP-запросы к тем же возможностям | Региональные ГИС |
Смысл в разных потребителях. Внешние агенты подключаются по MCP, веб-чат работает через function calling, и для этого выбранная LLM должна поддерживать такой вызов. Региональные ГИС продолжают ходить в привычный REST. Одни и те же данные, три способа добраться.
MCP-сервер как способ отдать инструменты агенту встречается и в других проектах: например, repopedia поднимает локальный MCP-сервер поверх графа кода в SQLite. Схема похожая: сервер описывает инструменты, клиент их вызывает.
ReAct-цикл и ограничение итераций
ReAct расшифровывается как reasoning и acting. Модель сначала рассуждает: какой шаг нужен, чего не хватает для ответа. Потом действует: вызывает инструмент. Получает результат, снова рассуждает.
Без ограничений такой цикл уходит в бесконечность: модель переспрашивает сама себя и повторяет вызовы. Чтобы этого не происходило, число итераций на запрос жёстко ограничили. Побочный эффект ожидаемый: часть сложных запросов не успевает дойти до конца и завершается частичным ответом. Взамен система получает предсказуемые время ответа и расход токенов. Похожие компромиссы видны в разборе ночного марафона Qwen 27B по кодингу, где агент работал сутки и упирался именно в лимиты и правила, а не в возможности модели.
Как LLM управляет спутниковыми данными: термоточки, ложные срабатывания и картирование гарей
VIIRS и MODIS: откуда берутся термоточки
VIIRS и MODIS - спутниковые инструменты, которые фиксируют тепловые аномалии. Агент сам собирает эти данные и использует их для обнаружения пожаров.
Термоточка не равна пожару. Это сигнал о возможном возгорании: пиксель с аномальной температурой, который требует проверки. Без фильтрации диспетчер получает поток ложных тревог, а вместе с ним и привычку не реагировать.
Overture Maps: как отсеиваются ложные срабатывания
Факелы на заводах, трубы котельных, карьеры и другие промышленные объекты дают тепловые аномалии, которые датчик отмечает как очаг. Агент сопоставляет термоточки с промышленными зонами по данным Overture Maps и отсеивает такие срабатывания.
Конкретные правила фильтрации (радиус проверки, пороги температуры, набор слоёв Overture) команда в доступном описании не привела. Пока это самое уязвимое место схемы: ошибка в фильтре либо скрывает настоящий очаг рядом с промзоной, либо возвращает лишние тревоги.
Sentinel-2, NBR и dNBR: как оцениваются масштабы выгорания
Картирование гарей строится на снимках Sentinel-2. В исходном описании название миссии приводится как «Santinel-2», что похоже на опечатку, дальше используется корректное Sentinel-2.
NBR (Normalized Burn Ratio) - индекс, который опирается на контраст отражения в ближнем и коротковолновом инфракрасном диапазонах. Живая растительность отражает ближний инфракрасный сильно, а коротковолновый слабо; после пожара соотношение меняется.
dNBR - разница между NBR до пожара и NBR после. Чем выше значение, тем сильнее повреждена растительность на участке. Расчёт ведётся по методике USGS, где значения dNBR переводят в классы тяжести выгорания. Точные границы классов стоит сверять по документации USGS: в открытом описании проекта они не приведены.
Практический смысл один: получить не точку, а площадь и степень повреждения, чтобы понимать масштаб последствий.
Маршруты пожарных расчётов и галсы дронов: как агент строит пути
Overpass API и OSRM: как строится маршрут пожарной машины
Агент строит маршруты от ближайших пожарных частей к очагу по дорожной сети для пожарных машин (описание проекта). Технически это два разных сервиса. Overpass API отдаёт объекты OpenStreetMap по заданной области: дороги, их классы, ограничения. OSRM строит маршрут по графу дорог и возвращает геометрию пути и время в дороге.
Агент определяет ближайшие пожарные части, а затем связывает их с очагом. Ценность в том, что запрос пользователя сразу превращается в маршрут, а не в набор координат для ручной работы в ГИС.
Галсы для дронов: как рассчитывается облёт территории
Галс - линия облёта территории беспилотником. Система рассчитывает галсы, чтобы дрон покрывал нужную зону съёмкой, а не летал хаотично. Такой облёт дополняет спутниковый мониторинг: спутник даёт регулярные снимки всей территории, дрон позволяет рассмотреть участок детальнее.
Параметры расчёта (шаг между галсами, высота, перекрытие снимков) в открытом описании не раскрыты. От них зависит, получится ли на выходе пригодная для анализа мозаика снимков, поэтому при повторении проекта их придётся подбирать самостоятельно.
Безопасность и оптимизация: песочница, кеширование и сжатые сводки
Песочница для Python-кода: Docker, AST-фильтрация и rlimits
Агенту разрешено генерировать Python-код для обработки геоданных, и этот код нужно где-то исполнять. Запускать его прямо на сервере приложения опасно: модель может ошибиться или сгенерировать разрушительные конструкции. Отсюда три барьера.
- Изоляция Docker выносит исполнение в отдельный контейнер без доступа к хосту.
- AST-фильтрация разбирает код в синтаксическое дерево и блокирует опасные операции до запуска.
- Лимиты rlimits ограничивают ресурсы процесса: процессорное время, память, число процессов.
AST-фильтр не даёт абсолютной гарантии: неполный список запрещённых узлов обходится хитрыми конструкциями. Поэтому его дополняют лимитами и изоляцией, а не полагаются только на статическую проверку. Похожая логика у песочницы LangSmith в агенте Deep Life Sci: код исполняется в изолированной среде, а не в основном процессе.
Кеширование GeoJSON с TTL 5 минут
Готовые GeoJSON-ответы кешируются с временем жизни 5 минут. Спутниковые данные обновляются с собственным интервалом, поэтому пятиминутный кеш не делает картину устаревшей, зато снимает нагрузку с внешних API и ускоряет ответ агента.
Компромисс очевиден: у кромки активного пожара пятиминутная задержка может быть критичной, и TTL для оперативных слоёв имеет смысл держать меньше. Пять минут разумны для фоновых слоёв, а не для обстановки, которая меняется на глазах.
Сжатые сводки для LLM: зачем и как
В модель уходят только сжатые сводки, а не сырые геоданные. Причины три: контекст LLM не резиновый, тысячи координат съедают токены и деньги, а на длинных массивах чисел модель чаще ошибается. Точные полигоны ей и не нужны, чтобы решить, какой инструмент вызвать, и сформулировать ответ человеку. Почему контекст стоит беречь, видно на примере TeaRAGs: монолит на 3,5 млн строк в контекст не помещается и требует отдельного слоя понимания.
Что это значит на практике: применимость и ограничения
Кому и как может быть полезна система
- Пожарные получают маршрут от ближайшей части к очагу и данные о самом очаге в одном ответе.
- Спасатели получают оперативную картину по чрезвычайной ситуации в регионе.
- Экологи получают оценку площади и степени выгорания по индексам NBR и dNBR.
- Региональные ГИС подключаются к тем же инструментам по REST API.
Система создавалась под конкретную задачу: продукт для мониторинга возникновения чрезвычайных ситуаций, их предотвращения и анализа последствий.
Ограничения и риски: что важно учитывать
- Fire Monitor остаётся хакатонным проектом, а не готовым продуктом с поддержкой и гарантиями.
- Работа зависит от внешних источников: спутниковых данных и API. Облачность, задержка снимков и лимиты сервисов напрямую влияют на результат.
- LLM ошибается. Решения агента нуждаются в проверке человеком, особенно когда речь идёт об отправке расчётов.
- Ограничение итераций ReAct-цикла означает, что часть сложных запросов завершится частичным ответом.
- Термоточка не равна пожару: точка окажется ложным срабатыванием, если фильтр по промышленным зонам не отработал.
Можно ли повторить такой проект самостоятельно
Большая часть компонентов доступна: PostgreSQL с PostGIS, MapLibre GL JS, FastMCP, Overpass API, OSRM, открытые спутниковые данные VIIRS, MODIS и Sentinel-2, открытая модель Qwen3.7-Plus. Повторить архитектуру реально, и решают три вещи: ограничение итераций ReAct-цикла, безопасное исполнение сгенерированного кода и отправка в модель сжатых сводок вместо сырых данных. Начинать стоит именно с них, иначе агент зациклится, сломает окружение или упрётся в лимит контекста на первом крупном запросе.