Контекст и задача
Круглосуточное наблюдение за одиноко проживающими пожилыми людьми — задача, которая десятилетиями решалась либо инвазивными методами (камеры видеонаблюдения), либо пассивными устройствами (кнопки экстренного вызова, фитнес-браслеты). Оба подхода имеют фундаментальные ограничения в реальной эксплуатации. Камеры нарушают приватность, требуют постоянного хранения видеопотока и зависят от человеческого внимания оператора. Кнопки и браслеты полагаются на сознательное действие пользователя в момент кризиса, что при падении, потере сознания или дезориентации часто невозможно. Рынок давно нуждается в автономной системе, которая непрерывно анализирует акустическую обстановку и паттерны движения, отличает бытовую активность от реальных угроз и доставляет верифицированные алерты родственникам или сиделкам без ручного вмешательства.
Задача, сформулированная для данного проекта, звучала технически строго и операционно точно: создать систему, которая принимает от носимого устройства ежесекундные данные о движении и минутные фрагменты аудио, обрабатывает их в реальном времени, применяет несколько специализированных нейросетевых моделей для детекции аномалий и верификации контекста, и при подтверждении инцидента формирует алерт с эскалацией в Telegram и, при необходимости, голосовой вызов. При этом система должна сохранять приватность пользователя, работать стабильно при непрерывном потоке данных, не перегружать вычислительные ресурсы и предоставлять родственникам объективную картину повседневной активности без необходимости постоянного вмешательства.
Это не прототип и не исследовательский стенд. Это производственная система, спроектированная с расчётом на долгосрочную эксплуатацию, где цена ошибки измеряется человеческим благополучием, а ложные срабатывания ведут к потере доверия к технологии в самый критический момент. Архитектура, конвейеры обработки, управление памятью, маршрутизация сообщений и интерфейс взаимодействия с пользователем выстраивались вокруг единственного принципа: инженерная дисциплина важнее технологического хайпа.
Риски и архитектурные ограничения
Проектирование подобной системы начинается не с выбора моделей, а с осознания рисков, которые могут разрушить её операционную ценность. В процессе анализа были выявлены и зафиксированы пять фундаментальных ограничений, каждое из которых потребовало отдельного архитектурного решения.
Ложные срабатывания и усталость от уведомлений
Детекция падений на чистом акселерометре или по простому аудиопорогу неизбежно даёт высокий уровень шума. Бросок сумки, падение стула, резкий кашель или фоновый шум телевизора могут быть интерпретированы как инцидент. Если система начнёт отправлять родственникам оповещения при каждом таком событии, возникнет эффект «усталости от алертов». Через неделю пользователь перестанет реагировать на уведомления, и в момент реального падения система окажется проигнорированной. Это классическая проблема безопасности: надёжность определяется не частотой срабатываний, а точностью верификации.
Задержки и блокирующие синхронные вызовы
Нейросетевые модели для распознавания речи, анализа дистресса и верификации голоса требуют значительных вычислительных ресурсов. Если передать аудиофайл в модель синхронно внутри HTTP-запроса, поток заблокируется до завершения инференса. При минутном потоке с десятков устройств это приведёт к каскадному накоплению очередей, таймаутам и полной остановке API. Система должна быть асинхронной по дизайну, с чётким разделением приёма данных, маршрутизации и вычислений.
Перегрузка GPU и управление памятью
Модели вроде Qwen2-Audio или Whisper в исходном виде занимают от 4 до 8 ГБ видеопамяти. При непрерывном потоке сообщений из очередей воркеры будут запускать инференс параллельно, что быстро приведёт к OOM (Out Of Memory) и падению процессов. Решение требует ленивой загрузки моделей, LRU-кеширования, автоматической выгрузки неиспользуемых весов, квантования до 4 бит и явного контроля за освобождением кэша PyTorch после каждого цикла обработки.
Приватность и комплаенс
Постоянная передача сырого аудио на сервер создаёт риски утечки, усложняет соответствие требованиям 152-ФЗ и формирует психологический дискомфорт у пользователя. Архитектура должна быть спроектирована так, чтобы исходные аудиоданные не покидали периметр обработки без необходимости. На сервер передаются только транскрипты, векторные эмбеддинги, агрегированные метрики и ссылки на записи, создаваемые исключительно при подтверждённом инциденте. Все инференсы логируются с временными метками для аудита, но без хранения полных аудиофайлов в открытом виде.
Сетевая нестабильность и потеря контекста
Носимые устройства работают в условиях переменного качества Wi-Fi, периодических обрывов связи и ограниченного заряда батареи. Система должна корректно обрабатывать пропущенные пакеты, восстанавливать состояние после разрыва, хранить команды для отправки при следующем подключении и не терять контекст многоэтапной верификации. Это требует явного управления состоянием в Redis, таймаут-мониторинга и детерминированной маршрутизации команд.
Архитектура и решение
Система построена на событийно-ориентированном конвейере с чётким разделением ответственности между устройствами, API-шлюзом, асинхронными воркерами, хранилищем данных и интерфейсом взаимодействия.
Минутный синк и сбор телеметрии
Устройство работает в режиме строгого таймера: каждые 60 секунд оно устанавливает соединение с эндпоинтом /alive, передаёт массив данных о движении за прошедшую минуту и фрагмент аудио, после чего опрашивает сервер на наличие команд. Это не произвольный поток, а детерминированный heartbeat, который позволяет системе предсказуемо планировать нагрузку и отслеживать статус устройства.
При получении запроса FastAPI выполняет несколько операций атомарно: обновляет статус устройства в PostgreSQL (is_online, last_sync, last_movement), сохраняет матрицу движения в компактном строковом формате, извлекает команды из Redis-очереди и возвращает их в ответе. Если команд нет, устройство получает пустой ответ и продолжает цикл. Если команда есть (например, special_ask или restart), устройство выполняет её и подтверждает исполнение на следующем пинге. Такая архитектура исключает потерю команд при кратковременных обрывах связи: они остаются в Redis до момента получения подтверждённого статуса.
Асинхронная маршрутизация через RabbitMQ
После предобработки аудио (ресемплинг до 16 кГц, шумоподавление, нормализация) данные не обрабатываются синхронно. Они публикуются в RabbitMQ по одному из четырёх изолированных каналов:
fall_queue— детекция падения через AST-классификатор;dla_queue— анализ повседневной активности (питание, гигиена, сон, речь);set_queue— распознавание речи, поиск триггерных слов, верификация голоса;fall_confirm_queue— анализ дистресса через Qwen2-Audio для подтверждения реального инцидента.
Разделение очередей решает несколько задач: предотвращает блокировку критического пути, позволяет независимо масштабировать воркеры и задавать разные параметры надёжности для каждого конвейера.
Многоэтапная верификация падений
Детекция падения никогда не завершается одним вызовом модели. Она проходит через несколько стадий, каждая из которых отсекает шум и повышает уверенность.
- Стадия 1 (AST-классификация): аудио передаётся в модель Audio Spectrogram Transformer. Если уверенность ниже порога (0.15) – событие маркируется как фоновое.
- Стадия 2 (корреляция с движением): анализируется матрица движения. Если движение отсутствует – событие считается шумом.
- Стадия 3 (запрос
special_ask): устройству отправляется команда подтверждения. Пользователь отвечает голосом. - Стадия 4 (анализ дистресса): ответ обрабатывается Qwen2-Audio (4‑bit) для выявления боли/паники.
- Стадия 5 (верификация резидента): голос кодируется в эмбеддинг (ECAPA-TDNN) и сравнивается с сохранённым через pgvector.
Только при совпадении всех факторов создаётся запись в alerts, отправляется уведомление в Telegram и, при необходимости, инициируется голосовой вызов.
DLA-агрегация и отчёты
События из dla_queue агрегируются в таблицу events_mart с ключом (serial_number, date). Раз в сутки формируется персонализированный отчёт с интерпретацией активности (например: «Жизнедеятельность ниже возрастной нормы – рекомендуется увеличить физическую активность»). Отчёты доставляются через Telegram-бота с возможностью настройки времени и режима.
Приватность по дизайну
Сырое аудио не покидает устройство. На сервер передаются только транскрипты, эмбеддинги и агрегированные метрики. Полные записи создаются исключительно при подтверждённом инциденте. Все инференсы логируются для аудита, но без хранения полных аудиофайлов в открытом виде.
Управление конфигурацией и горячая перезагрузка
Пороги срабатывания, модели распознавания, триггерные слова и таймауты хранятся в таблице algorithm_config с поддержкой профилей (default, high_sensitivity, low_sensitivity) и загружаются динамически через ConfigManager. Изменения применяются без перезапуска сервисов.
Результат и эксплуатационная зрелость
- Стабильная реакция при сохранении приватности: подтверждение инцидента занимает <30 секунд, ложные срабатывания снижены многофакторной верификацией.
- Объективная картина жизнедеятельности: ежедневные AI-отчёты с возрастными нормами позволяют выявлять негативные тренды до кризиса.
- Устойчивость под нагрузкой: ленивая загрузка моделей, LRU-кеширование, квантование до 4 бит и контроль памяти предотвращают OOM.
- Управляемость и аудит: динамическая конфигурация, логирование всех алертов и инференсов, Telegram-бот для полного цикла управления.
Технологический стек
- FastAPI – асинхронный HTTP-шлюз
- RabbitMQ – брокер сообщений с гарантированной доставкой
- Redis – кеш состояний и очередь команд
- PostgreSQL + pgvector – хранение событий и эмбеддингов
- PyTorch + SpeechBrain + Whisper + AST + Qwen2-Audio (4‑bit) + ECAPA-TDNN – стек моделей
- Pyrogram – Telegram-бот
- Docker Compose – оркестрация
- Prefect + YandexGPT – ETL и суммаризация
Инженерный вывод
ИИ не всегда должен «понимать смысл». Иногда достаточно детектировать паттерны в данных, запустить предопределённые сценарии верификации и сформировать алерт только при совпадении нескольких независимых факторов. Это надёжнее, дешевле и проще в комплаенсе. Система, описанная в этом кейсе, не пытается заменить человеческое суждение. Она создаёт инженерный контур, который фильтрует шум, сохраняет приватность, агрегирует метрики и доставляет только подтверждённые сигналы. Многоступенчатая верификация, асинхронная маршрутизация, управление памятью и динамическая конфигурация превращают «умную коробочку» в эксплуатационно зрелую систему, которой можно доверять. Спокойно, точно, в долгую.