AI-мониторинг ментального состояния по данным носимых устройств

Почему AI-мониторинг ментального состояния ломается на данных

Носимые устройства дают неравномерный и разнородный поток: браслет, кольцо и часы пишут пульс, вариабельность ритма, сон и активность с разной частотой и в разных форматах, а часть данных приходит из дневника самонаблюдения, где человек вручную отмечает настроение. Часовые пояса, калибровка сенсоров и момент начала записи у каждой модели свои, поэтому даже простой признак вроде «средний пульс за ночь» приходится собирать из нескольких источников и приводить к единой шкале, иначе данные с носимых устройств не стыкуются между собой.

Пропуски в сигнале — не исключение, а норма: устройство снимают на ночь, садится батарея, синхронизация уходит в очередь на сутки, а пользователь забывает отметить эпизод. В реальной выборке до трети временных окон оказываются пустыми, при этом редкие события — эпизоды выраженного ухудшения состояния — встречаются в единицах процентов записей. На таком перекосе модель быстро выучивает ложные связи: разницу между буднями и выходными, всплеск активности, сезон отпусков — всё, что correlates с целевым признаком, но не описывает его.

Дальше начинается то, ради чего всё считалось: ложные срабатывания. Алгоритм тревожится на прогулке или после недосыпа, а настоящий эпизод пропускает — доверие к системе падает быстрее, чем растёт точность на отложенной выборке. Именно на этом ломается большинство проектов AI мониторинга ментального состояния: они не доживают до промышленной эксплуатации. Разбираем, как это закрывается.

Что меняется после внедрения: задержка реакции и пропущенные эпизоды

Польза от непрерывного наблюдения измеряется не «умностью» модели, а четырьмя проверяемыми сдвигами, которые видно в выгрузке за месяц. Ниже — чек-лист приёмки: каждый пункт считается по журналу сигналов и подтверждениям специалистов, а не по субъективной оценке.

Отдельные замеры дают разрозненные точки, и эпизод между ними просто не виден. Непрерывное наблюдение строит личную норму по ритму и активности, поэтому отклонение от неё заметно раньше жалобы и подтверждается динамикой, а не одним значением.

Специалист получает сигнал с готовым контекстом: когда началось, как долго длится, что было до этого. Время уходит на разговор и решение, а не на поиск, — число разобранных случаев за смену растёт без роста нагрузки.

Пункты фиксируем в приёмке: если доля выявленных эпизодов не растёт, а время реакции не сокращается, настройка сигналов требует доработки.

Непрерывный мониторинг против периодических опросов и самозаполнения

Три способа сбора отвечают на разные вопросы и не заменяют друг друга. Пассивная регистрация с носимых устройств (Apple Watch, Garmin, Wear OS) даёт непрерывный ряд: пульс, вариабельность ритма, длительность и качество сна, двигательная активность, время у экрана. Периодические опросники вроде PHQ-9 и GAD-7 дают редкий, но валидированный срез субъективного состояния. Самозаполнение дневника фиксирует эпизод в моменте — когда человек сам решил его отметить.

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

Рабочая схема — гибрид с явным разделением ролей: шкалы служат точками калибровки и опорой для порогов, пассивный ряд даёт фон и ловит отклонения между замерами, дневник уточняет контекст. Дальше разбираем, как такой режим сбора собирается в один контур.

Как мы внедряем: от аудита данных до передачи модели в эксплуатацию

Внедрение разбито на семь шагов, и каждый закрывается только после точки контроля: без согласованного результата шага следующий не начинается. Так снимается типовой риск, когда модель обучена на исторических данных, а в промышленный контур не вышла.

1. Аудит данных. Смотрим, что реально пишут носимые устройства: полнота рядов, доля пропусков и артефактов движения, качество разметки эпизодов. На выходе — отчёт о пригодности данных и границах применимости.
2. Схема признаков. Определяем, какие сигналы и в каких окнах описывают состояние, как считаются суточные и недельные профили. Схема фиксируется письменно — по ней обучение воспроизводимо.
3. Сборка и обучение. Готовим обучающую выборку и отдельно валидационную. Сравниваем несколько семейств моделей на одной схеме признаков, чтобы выбор был обоснованным, а не единственным.
4. Проверка на отложенном периоде. Тестируем на данных, не участвовавших в обучении, включая участки со сменой режима. Смотрим устойчивость по людям и по времени, а не только среднюю метрику.
5. Вывод в эксплуатацию. Разворачиваем в промышленном контуре заказчика: потоки данных, отказоустойчивость, журналирование и оповещения о деградации входных сигналов.
6. Обучение команды. Передаём рабочие процедуры, а не презентацию: как переобучать, как откатывать версию модели, что делать при смене устройства.
7. Приёмка и передача. Совместно прогоняем контрольные сценарии, фиксируем метрики приёмки, документацию и зоны ответственности.

Что остаётся у заказчика: модели, конфигурации и регламенты

Передать заказчику обученную модель недостаточно — без конфигурации, схем интеграции и регламентов её нельзя эксплуатировать и развивать. Поэтому комплект мы собираем так, чтобы команда заказчика сопровождала систему самостоятельно: меняла параметры обработки, подключала новые источники и разбирала инциденты без нас.

• Конфигурация обработки: окна агрегации сигналов, пороги срабатывания, калибровка индивидуальной нормы по первым неделям ношения, правила гашения ложных отклонений при пропусках данных.
• Схема интеграции источников: какие носимые устройства и приложения подключены, форматы выгрузки, частота синхронизации, поведение при обрыве связи и повторной доставке.
• Политики доступа к чувствительным данным: роли специалистов, разграничение по подразделениям, сроки хранения, обезличивание при выгрузке в отчётность, журнал обращений.
• Документация на систему: описание признаков и модели, границы применимости, случаи, где результат неуверенный и требует ручной проверки.
• Регламент сопровождения: контроль дрейфа, плановое переобучение, реакция на просадку качества, порядок отката на предыдущую версию.
• Порядок приёмки: прогон на исторических данных заказчика, сверка с эталонной разметкой, фиксация метрик до и после внедрения.

Передача считается закрытой, когда специалисты заказчика сами меняют пороги, подключают новый источник и разбирают сбой по документации. Дальше остаётся канал связи с нашими инженерами — для изменений модели и расширения набора сигналов.

Кейс: сократили пропущенные эпизоды вдвое на пилотной группе

Пилот запускали на группе со сменным графиком: носимые устройства отдавали пульс, вариабельность ритма и качество сна, а модель помечала эпизоды, которые куратор разбирал вручную. На входе стояла пороговая логика — она пропускала каждый третий значимый эпизод, потому что резкие отклонения на фоне накопленной усталости выглядели как обычное восстановление.

Что изменили

Логику переписали: модель оценивает не отдельные значения, а суточную динамику — сдвиг личной базовой линии, скорость восстановления после нагрузки, разброс ночных показателей. Порог срабатывания стал адаптивным и подстраивался под норму конкретного человека, а сигналы из серой зоны уходили куратору с пометкой «низкая уверенность» вместо срабатывания по умолчанию.

Период наблюдения — восемь недель, сравнение шло с предыдущими двумя месяцами на тех же людях. Доля пропущенных эпизодов упала с 31% до 12%, уровень ложных тревог — с 4,1 до 1,5 обращения на человека в неделю: куратор перестал разбирать шум. Время реакции сократилось с полутора суток до нескольких часов, потому что очередь строилась по уверенности модели, а не по времени поступления сигнала.

Парк устройств менять не потребовалось: источник данных — Garmin и совместимые браслеты. Модель дообучалась на разметке кураторов: каждый закрытый эпизод уточнял личную норму, поэтому качество росло по ходу наблюдения, а не выходило на плато.

Что делать, если данные уже собираются в другом контуре?

Сбор уже налажен — сторонним сервисом, платформой производителя носимых устройств или системой другого подразделения. Данных достаточно, но доступ ограничен форматом выгрузки, а признаки посчитаны по чужой модели. Для нашего AI-мониторинга ментального состояния такие наборы подходят лишь частично.

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

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

Разрыв наблюдения дороже, чем кажется: базовая линия у каждого своя, и пропуск в несколько суток ломает сравнение с историей. Поэтому перенос идёт без паузы — параллельно поднимаем свой сбор, сверяем метки времени и расхождения на контрольных окнах, и только после совпадения отключаем старый контур. Исторические данные забираем архивом и помечаем, какой моделью они посчитаны: отчётность не рвётся, а новые выводы строятся уже на нашей стороне.

Технические сомнения: точность, приватность, ложные срабатывания

Сомнения по таким системам возникают не вокруг «работает или нет», а вокруг измеримости: как считается качество модели, что происходит с физиологическими данными, кто получает доступ и как ведёт себя система при деградации сигнала — потеря связи, браслет снят на ночь, слабый прижим датчика.

Что происходит с чувствительными данными?

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

Как оформляется согласие пользователя?

Согласие — отдельный шаг с понятным перечнем: какие показатели считываются, кому и в каком виде они видны, на какой срок. Отзыв работает так же явно: данные удаляются или обезличиваются по описанному заранее правилу, а не «когда-нибудь потом».

Что будет при деградации сигнала?

Система следит за качеством входного потока: долей пропусков, шумом, стабильностью ношения. Если качество падает ниже порога, интервал помечается недостоверным и модель молчит вместо тревоги — так ложные срабатывания не растут вместе с шумом.

Обсудим задачу: что уже есть и к какому результату идём

Чтобы вернуться с рабочей оценкой и планом первого этапа, а не общими соображениями, нам нужен короткий срез по вашей задаче. Опишите, что уже есть: какие носимые устройства в контуре, какие показатели с них снимаются и в каком виде данные доходят до вас сегодня. Ниже — то, что снимает большинство неопределённостей на старте.

• Парк устройств: модели часов, браслетов или колец и доля каждой — от этого зависят доступный набор показателей и частота их записи.
• Состав данных: пульс, вариабельность ритма, качество и фазы сна, уровень активности, субъективные отметки пользователя.
• Формат и путь данных: выгрузка файлами, обращение к облаку производителя или собственный сбор, есть ли исторический архив и за какой период.
• Требования к данным: нужно ли обезличивание, где разрешено хранить записи, как оформляются согласия пользователей.
• Что считается результатом: сигнал специалисту при отклонении, отчёт человеку о своём состоянии или агрегированная картина по группе.
• Точка встраивания: мобильное приложение, корпоративный портал, кабинет специалиста — куда должен приходить результат.
• Ограничения: сроки внедрения, с которыми вы уже связаны, и внешние требования к системе.

С этим набором мы возвращаемся с оценкой и планом работ: что делаем на первом этапе, какие требования к данным фиксируем и сколько времени занимает внедрение. Опишите задачу — обсудим по существу.