Від передбачення до відповідальної дії: проектування неоднозначності в Femtech AI

У сфері жінокського здоров’я точність необхідна, але це тільки перший рівень безпеки продукту. Для системи важливо знати, коли передбачення достатньо сильне, щоб на нього покластися, і бути здатною сказати про це, коли воно недостатньо сильне.

Відкрийте більшість застосунків для відстеження фертильності або циклу, і ви побачите чистий результат: овуляція на 15-й день, мітка високої фертильності, рівень впевненості 78%. Цифра виглядає точною. Біологія під нею не така.

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

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

Отже, моя аргументація полягає в тому, що Femtech AI не потребує перш за все кращого передбачення. Їй потрібно краще проектування неоднозначності. А проектування неоднозначності – це не застереження, яке прикріплюється до продукту перед запуском; це архітектура. Я структурую її у шість шарів, які несуть сигнал від сирої інформації до дії, яку система може виправдати та перевірити. Я застосовую шестишарову версію методу продукту рішення-дія, призначеного для управління тим, як неоднозначні сигнали охорони здоров’я перетворюються в дозволені та відповідальні дії. Метод включає кваліфікацію даних, калібрування висновку, картування наслідків, політику контролю, виконання робочого процесу та бухгалтерський облік відповідальності. Його керуючий шлях починається зі здоров’я даних, який веде до архітектури рішення та завершується відповідальною дією.

1. Кваліфікувати дані перед тим, як їм довіряти

Перший шар вирішує, що система насправді знає. Продукти Femtech витягують інформацію з дуже різних джерел. Це можуть бути речі, які користувачка безпосередньо спостерігала, наприклад дати менструації або суб’єктивні звіти, такі як біль чи настрій, а також функції носимих пристроїв, такі як температура шкіри та варіабельність серцевого ритму, а також змінні, які модель сама генерує. Розгляд цих даних як взаємозамінних вхідних даних – це первинний гріх.

Кожний сигнал потребує походження, яке система може прочитати: звідки він походять, коли, як часто він вибірково збирається, які чинники його впливають, і як він пов’язаний з тим, що ви фактично передбачаєте. Овуляція – це подія. Температура, шийна слиз, LH та дати циклу – це дані про цю подію, кожен з власним запізненням та власною помилкою.

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

2. Калібрувати висновок до даних

Один рівень впевненості не може представляти, що насправді відбувається, оскільки ці системи одночасно стикаються з декількома різними джерелами неоднозначності. До них належать біологічна мінливість процесу самої себе, якість вимірювання, відсутність даних через самовідстеження, неоднозначність моделі через тонкі дані тренування, а також зміна розподілу, коли поточний користувач не нагадує населення, на якому модель була перевірена.

У тому ж аналізі тільки 13% циклів тривали точно 28 днів, а середня фоллікулярна фаза складала 16,9 днів у діапазоні, достатньо широкому, щоб зробити будь-яке фіксоване припущення “день 14” оманливим. Дослідження здоров’я жінок Apple виявило, що тривалість циклу та внутрішньопersonальна мінливість були пов’язані з віком, самозаявленою етнічністю та індексом маси тіла. Персоналізація, отже, не може означати заміну середнього населення на одну особисту точку. Вона означає створення розподілу, який звужується, коли накопичуються дані.

Розгляньте два прогнози на основі штучного інтелекту, які обидва читаються як “75%”. Один спирається на рік історії та густі вимірювання, а його неоднозначність в основному реальна біологія. Інший спирається на два цикли, п’ять показників температури, недавні поїздки та невідомі ліки. Тут неоднозначність в основному викликана відсутністю даних. Та ж сама цифра. Продукт не повинен реагувати на них однаково. Це також пояснює, чому калібрування повинно перевірятися в підгрупах – агрегована продуктивність може приховати модель, яка надто впевнена, особливо для нерегулярних циклів або користувачів у перименопаузі. Клінічна література штучного інтелекту тепер розрізняє дискримінацію, калібрування та корисність рішення пPrecisely за цю причину. Модель може добре ранжувати користувачів, але все одно виробляти неправильні ймовірності для реальних рішень.

3. Картувати наслідки помилки

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

Я сортую виходи за чотири рівні за наслідками: інформаційний, поведінковий, репродуктивний та клінічний. Кожен має свій власний поріг доказів, дозволену мову та шлях ескалації. Ймовірність 70% може бути достатньо доброю для припущення, коли починається період, і ніде близько достатньо, щоб заспокоїти когось, хто намагається не завагітнути.

Це місце, де дизайн зустрічається з регулюванням. Чи програмне забезпечення переходить у територію медичного пристрою, залежить від його призначеного використання та ролі його виходу в рішенні про охорону здоров’я. Поточне керівництво FDA щодо клінічного програмного забезпечення підтримки рішень від січня 2026 року явно заявляє, що функції, призначені для пацієнтів та опікунів, можуть відповідати визначенню пристрою. Регуляторне позиціонування не є юридичним переглядом наприкінці. Воно закодовано в ваших порогах, вашій формули, і вашій логіці ескалації з дня один.

4. Перетворити неоднозначність на політику контролю

Загальна заява “результати можуть бути неточними” передає всю проблему інтерпретації назад користувачу. Політика контролю робить протилежне. Для даного стану доказів вона вирішує, чи показує система спостереження, пропонує обмежений діапазон, просить про ще одне вимірювання, вказує на клініциста чи відмовляється відповідати. Утримання є можливістю продукту, а не його провалом. “Ми ще не впевнені” повинно бути проектованим станом з наступним кроком, а не екраном помилки.

Конкретно, замість “Овуляція: День 15, 78%”, керований відповідь читає ближче до цього: овуляція найімовірніше відбувається в чотириденному вікні; впевненість обмежена відсутністю даних температури та порушеним сном; кілька додаткових показань могли б уточнити оцінку, а тест LH міг би додати перспективні дані та звузити ймовірне вікно. Користувач отримує оцінку, причину, через яку вона невизначена, і одну дію, яка б її змінила.

5. Підтримувати дію, яку припускає вихід

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

Кордон між продуктом та медичною порадою існує тут, і це не фіксована лінія. Освітній контент, який пояснює, що загалом означає сигнал, знаходиться безпечно на боці керівництва. Продукт переходить у територію вищого ризику в момент, коли він інтерпретує дані однієї людини як захворювання, спрямовує лікування чи пропонує заспокоєння, яке несе справжню клінічну вагу. Цей кордон повинен триматися на кожній взаємодії, а не тільки у умовах обслуговування.

6. Закрити бухгалтерський облік відповідальності

Останній шар оцінює всю систему, а не тільки модель. Стандартні метрики моделі все ще мають значення та зосереджуються на дискримінації, калібруванні, продуктивності підгруп, зовнішній та часовій валідності. Але метрики рівня продукту мають таке ж значення. Ми повинні запитати, як часто система мала достатньо входів, щоб діяти, як часто вона утримувалася. Плюс той, на який я наполягатиму, – це рівень помилкової впевненості, тобто як часто вона казала комусь, що все виглядає добре на підставі, яка не могла б підтримати це твердження.

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

Як виглядає архітектура на практиці

Припустимо, що у продукту є три місяці дат менструації, шість ночей температури, один позитивний тест LH, розсип симптомів та тиждень поганого сну. Найвища ймовірність овуляції моделі припадає на 15-й день. Застосунок з точки оцінки показує “Овуляція: День 15, Впевненість 78%”.

Архітектура виробляє щось інше. Вона позначає дані температури як розріджені та спотворені сном. Вона генерує розподіл по декількох кандидатських днях, а не одну. Вона застосовує м’який поріг для усвідомлення циклу, але суворіші, якщо вихід торкається запобігання вагітності. Вона пропонує діапазон плюс наступне корисне вимірювання. І вона зберігає весь стан доказів, щоб рішення можна було пізніше реконструювати. Та ж сама модель підкладки та зовсім інший продукт.

Право діяти

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

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