От предсказания к ответственной деятельности: проектирование неопределенности в Femtech AI

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

Откройте большинство приложений для отслеживания фертильности или цикла, и вы увидите чистый результат: овуляция на 15-й день, высокий уровень фертильности, уровень уверенности 78%. Число выглядит точным. Биология под ним не такова.

Дата менструации – это то, что пользователь наблюдал. Овуляция – это скрытое событие, которое ни одно потребительское устройство не измеряет напрямую. Оно выводится из прокси. Температура кожи отражает не только прогестерон, но и сон, алкоголь, болезнь, окружающие условия и то, где датчик находился той ночью. Вход симптома смешивает физиологию с восприятием, памятью и решением пользователя о его регистрации. К тому времени, когда все это разрешается в “День 15, 78%”, несколько разных видов неопределенности были тихо сжаты в одну уверенно звучащую фразу.

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

Итак, моя аргументация заключается в том, что Femtech AI не нуждается в первую очередь в лучшем предсказании. Ему нужна лучшая неопределенность. И неопределенность – это не предупреждение, которое прикрепляется перед запуском; это архитектура. Я структурирую ее в шесть слоев, которые несут сигнал от сырых входных данных до действия, которое система может оправдать и проверить. Я применяю шестислойный вариант метода продукта “Решение-деятельность”, предназначенного для управления тем, как неопределенные сигналы здоровья преобразуются в разрешенные и ответственные действия. Метод включает квалификацию данных, калибровку вывода, картографирование последствий, политику контроля, выполнение рабочего процесса и цикл ответственности. Его управляющий путь начинается с данных о здоровье, что приводит к архитектуре решения, и завершается ответственной деятельностью.

1. Квалифицируйте данные, прежде чем доверять им

Первый слой решает, что система действительно знает. Продукты Femtech черпают из очень разных источников. Это может включать то, что пользователь直接 наблюдал, например, даты менструации или субъективные отчеты, такие как боль или настроение, а также функции носимых устройств, такие как температура кожи и вариабельность сердечного ритма, и переменные, которые модель сама сгенерировала. Относиться к этим данным как к взаимозаменяемым входным данным – это первородный грех.

Каждый сигнал требует происхождения, которое система может прочитать: откуда он пришел, когда, как часто он выборочно измеряется, что его искажает, и как он связан с тем, что вы действительно предсказываете. Овуляция – это событие. Температура, цервикальная слизь, ЛГ и даты цикла – это доказательства этого события, каждое со своей задержкой и ошибкой.

Отсутствующие данные заслуживают особого внимания, поскольку в отслеживании здоровья они редко бывают случайными. Люди регистрируют больше, когда они беспокоятся, и перестают, когда они чувствуют себя хорошо, поэтому пробел может нести столько же информации, сколько и запись. В реальном анализе более 600 000 овуляторных циклов овуляцию не удалось обнаружить в 665 603 из 1,4 миллиона циклов, первоначально рассматриваемых. Три четверти из них имели действительные показания температуры менее чем на половине дней цикла. Достаточность данных была значительным ограничивающим фактором в том, что могло сделать алгоритм. Продукт, который выдает четкий ярлык фертильности в этой ситуации, не уверен. Он изготавливает точность, которой не обладает.

2. Калибруйте вывод по отношению к доказательствам

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

В том же анализе только 13% циклов длились ровно 28 дней, а средняя фолликулярная фаза длилась 16,9 дней в диапазоне, достаточно широком, чтобы сделать любое фиксированное предположение “день 14” вводящим в заблуждение. Исследование женского здоровья Apple выявило, что длина цикла и внутриличностная вариативность были связаны с возрастом, самораскрытым этническим происхождением и индексом массы тела. Персонализация, тогда, не может означать замену среднего значения населения на одну личную точку. Она означает производство распределения, которое сужается, когда накапливаются доказательства.

Рассмотрим два прогноза на основе ИИ, которые оба читают “75%”. Один основан на году истории и плотных измерениях, а его неопределенность в основном связана с реальной биологией. Другой основан на двух циклах, пяти показаниях температуры, недавних путешествиях и неизвестных лекарствах. Здесь неопределенность в основном связана с отсутствием данных. Одно и то же число. Продукт не должен реагировать на них одинаково. Это также причина, по которой калибровка должна проверяться в подгруппах – агрегированная производительность может скрыть модель, которая过confident, особенно для нерегулярных циклов или пользователей в перименопаузе. Клиническая литература об ИИ теперь разделяет дискриминацию, калибровку и полезность принятия решений именно по этой причине. Модель может хорошо ранжировать пользователей и все же производить неправильные вероятности для реальных решений.

3. Отобразите последствия ошибки

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

Я сортирую выводы по четырем уровням по последствиям: информационным, поведенческим, репродуктивным и клиническим. Каждый имеет свой собственный порог доказательств, разрешенный язык и путь эскалации. Вероятность 70% может быть достаточной для угадывания, когда начнется менструация, и нигде не близка к тому, чтобы успокоить кого-то, пытающегося не забеременеть.

Это место, где дизайн встречается с регулированием. Будет ли программное обеспечение пересекать границу медицинского устройства, зависит от его предполагаемого использования и роли его вывода в решении о здоровье. Текущее руководство FDA по программному обеспечению для поддержки клинических решений, обновленное в январе 2026 года, явно указывает, что функции, предназначенные для пациентов и опекунов, могут соответствовать определению устройства. Регуляторное позиционирование не является юридическим обзором в конце. Оно закодировано в ваших порогах, вашем словах и логике эскалации с первого дня.

4. Преобразуйте неопределенность в политику контроля

Одиночное предупреждение “результаты могут быть неточными” передает всю проблему интерпретации обратно пользователю. Политика контроля делает противоположное. Для данного состояния доказательств она решает, показывает ли система наблюдение, предлагает ограниченный диапазон, запрашивает еще одно измерение, указывает на клинициста или отказывается отвечать. Воздержание – это возможность продукта, а не его неудача. “Мы еще не уверены” должно быть спроектированным состоянием с следующим шагом, а не экраном ошибки.

Конкретно, вместо “Овуляция: День 15, 78%”, управляемый ответ читается ближе к этому: овуляция, вероятно, в четырехдневном окне; уверенность ограничена отсутствием данных температуры и нарушенным сном; несколько дополнительных показаний могли бы уточнить оценку, и тест ЛГ мог бы добавить перспективные доказательства и сузить вероятное окно. Пользователь получает оценку, причину, по которой она неопределенна, и одно действие, которое изменило бы ее.

5. Поддержите действие, подразумеваемое выводом

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

Граница между рекомендациями продукта и медицинским советом живет здесь, и это не фиксированная линия. Образовательный контент, объясняющий, что общий сигнал означает, безопасно находится на стороне рекомендаций. Продукт переходит в территорию более высокого риска, когда он интерпретирует данные одного человека как болезнь, направляет лечение или предлагает уверенность, которая несет в себе реальный клинический вес. Эта граница должна держаться на каждом взаимодействии, а не только в условиях обслуживания.

6. Закройте цикл ответственности

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

Каждая значимая реакция должна быть восстанавливаемой после этого. Регуляторы, стандартные органы и глобальные институты управления здравоохранением все чаще принимают этот взгляд на жизненный цикл. Принципы хорошей практики машинного обучения IMDRF рассматривают достоверное медицинское ИИ как ответственность за весь жизненный цикл, охватывающую проектирование, развертывание и мониторинг, отражающую руководство ВОЗ по ИИ для здоровья.

Как выглядит архитектура на практике

Предположим, что у продукта есть три месяца дат менструаций, шесть ночей температуры, один положительный тест ЛГ, несколько записей симптомов и неделя плохого сна. Наивысшая вероятность овуляции модели падает на 15-й день. Приложение с точечной оценкой показывает “Овуляция: День 15, Уверенность 78%”.

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

Право на действие

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

Точность описывает качество предсказания. Целостность принятия решений решает, заслужил ли продукт право действовать на его основе.