מדוע ניטור AI של מצב נפשי נשבר על נתונים
התקנים לבישים מספקים זרימה לא אחידה והטרוגנית: צמיד, טבעת ושעון רושמים דופק, שונות קצב לב, שינה ופעילות בתדירויות שונות ובפורמטים שונים, וחלק מהנתונים מגיע מיומן תצפית עצמית, שבו האדם מסמן ידנית מצב רוח.
אזורי זמן, כיול חיישנים ורגע תחילת ההקלטה שונים בכל דגם, ולכן אפילו מאפיין פשוט כמו «דופק ממוצע בלילה» יש לאסוף מכמה מקורות ולהביא לסקאלה אחידה, אחרת הנתונים מהתקנים לבישים אינם מתואמים זה עם זה.
חוסרים באות הם לא יוצא דופן אלא נורמה: מסירים את המכשיר בלילה, הסוללה מתרוקנת, הסנכרון נכנס לתור ליום שלם, והמשתמש שוכח לסמן אפיזודה. במדגם אמיתי עד שליש מחלונות הזמן מתבררים כריקים, ובמקביל אירועים נדירים — אפיזודות של החמרה ניכרת במצב — מופיעים באחוזים בודדים מהרשומות.
על הטיה כזו המודל לומד במהירות קשרים כוזבים: הבדל בין ימי חול לסופי שבוע, פרץ פעילות, עונת חופשות — כל מה שמתאם עם מאפיין המטרה, אך אינו מתאר אותו.
מכאן מתחיל מה שלשמו חושב הכול: התראות שווא. האלגוריתם מתריע בטיול או אחרי חוסר שינה, ומפספס אפיזודה אמיתית — האמון במערכת יורד מהר יותר מאשר הדיוק עולה על מדגם האימות. בדיוק על זה נשברים רוב פרויקטי ניטור ה-AI של מצב נפשי: הם אינם שורדים עד לתפעול הייצור. נפרט כיצד זה נסגר.
מה משתנה לאחר ההטמעה: השהיית תגובה ואפיזודות שהוחמצו
התועלת מניטור רציף נמדדת לא ב«חוכמה» של המודל, אלא בארבעה שינויים ניתנים לבדיקה שנראים בייצוא נתונים חודשי. להלן צ'קליסט קבלה: כל סעיף מחושב לפי יומן האותות ואישורי מומחים, ולא לפי הערכה סובייקטיבית.
| כיוון | מה מחשבים | מה נראה לאחר ההטמעה |
|---|---|---|
| זיהוי מוקדם של אפיזודות | שיעור האותות המאושרים ומקרים שהתגלו לפני פנייה | סטייה נתפסת בתחילתה, ולא כשהאדם עצמו מבקש עזרה |
| מהירות תגובה | הזמן מהסטייה היציבה הראשונה ועד ליצירת קשר עם מומחה | ימים מתקצרים לשעות |
| בדיקות ידניות | שיעור הרשומות שנבדקות ידנית | סקירה גורפת מוחלפת בבדיקה של אותות ממוקדים |
| עומס על המומחים | מספר התראות השווא למשמרת | הקשב עובר למקרים מורכבים, ולא לרעש |
מדידות בודדות נותנות נקודות מפוזרות, והאפיזודה שביניהן פשוט אינה נראית. ניטור רציף בונה נורמה אישית לפי קצב ופעילות, ולכן סטייה ממנה מורגשת לפני תלונה ומאושרת באמצעות דינמיקה, ולא לפי ערך בודד.
המומחה מקבל אות עם הקשר מוכן: מתי זה התחיל, כמה זמן זה נמשך, מה היה לפני כן. הזמן מוקדש לשיחה ולקבלת החלטה, ולא לחיפוש — מספר המקרים שנבחנו למשמרת גדל בלי עלייה בעומס.
את הסעיפים מתעדים בקבלה: אם שיעור האפיזודות שזוהו אינו עולה, וזמן התגובה אינו מתקצר, כיול האותות דורש שיפור.
ניטור רציף לעומת שאלונים תקופתיים ומילוי עצמי
שלוש דרכי איסוף עונות על שאלות שונות ואינן מחליפות זו את זו. רישום פסיבי מהתקנים לבישים (Apple Watch, Garmin, Wear OS) מספק סדרה רציפה: דופק, שונות קצב הלב, משך ואיכות שינה, פעילות מוטורית, זמן מול מסך.
שאלונים תקופתיים כמו PHQ-9 ו-GAD-7 מספקים חתך נדיר אך מתוקף של מצב סובייקטיבי. מילוי עצמי של יומן מתעד אפיזודה בזמן אמת — כשהאדם עצמו החליט לסמן אותה.
הסדרות אינן ניתנות להמרה ישירה זו לזו. אות פסיבי מראה שהפיזיולוגיה סטתה מהנורמה האישית, אך אינו מגדיר את הסיבה: אותה ירידה בשונות קצב הלב מופיעה אחרי אימון קשה, מחלה או חוסר שינה. השאלון מנסח את המצב במילים, אבל נאסף אחת לשבוע-שבועיים, והערכה רטרוספקטיבית מוטה באופן שיטתי. היומן מדויק בזמן, אך נשען על הרגל המילוי.
| אופן איסוף הנתונים | מתי מתאים | מגבלות השיטה |
|---|---|---|
| רישום פסיבי מהתקנים לבישים | נדרש רקע רציף וסטיות מהנורמה האישית | אינו מסביר את סיבת הסטייה; תלוי בכך שהאדם עונד את המכשיר; ארטיפקטים של תנועה והסרה |
| שאלונים תקופתיים לפי סקאלות מתוקפות | השוואה לספים קליניים, הערכת דינמיקה לאורך שבועות | חתכים נדירים, עיוות רטרוספקטיבי, התרגלות לשאלות |
| מילוי עצמי של יומן לפי טריגר | תיעוד אפיזודה בזמן אמת וההקשר שלה | חוסרים וחוסר אחידות, תלות במוטיבציה, אי-השוואתיות של ניסוחים |
התוכנית העובדת היא היברידית עם חלוקת תפקידים מפורשת: הסקאלות משמשות נקודות כיול ותמיכה לספים, הסדרה הפסיבית מספקת רקע ותופסת סטיות בין מדידות, והיומן מדייק את ההקשר. בהמשך נפרט כיצד אופן איסוף כזה נאסף למעגל אחד.
כיצד אנו מטמיעים: מביקורת נתונים ועד מסירת המודל לתפעול
ההטמעה מחולקת לשבעה שלבים, וכל שלב נסגר רק לאחר נקודת בקרה: בלי תוצאה מוסכמת לשלב, לא מתחילים את הבא. כך מוסר הסיכון הטיפוסי שבו המודל מאומן על נתונים היסטוריים, אך אינו יוצא למעגל הייצור.
- ביקורת נתונים. בודקים מה באמת רושמים ההתקנים הלבישים: שלמות הסדרות, שיעור החוסרים והארטיפקטים של תנועה, איכות סימון האפיזודות. בפלט — דוח על כשירות הנתונים וגבולות היישום.
- סכמת מאפיינים. מגדירים אילו אותות ובאילו חלונות מתארים את המצב, כיצד מחושבים פרופילים יומיים ושבועיים. הסכמה מתועדת בכתב — לפיה האימון ניתן לשחזור.
- הרכבה ואימון. מכינים מדגם אימון ובנפרד מדגם אימות. משווים כמה משפחות מודלים על אותה סכמת מאפיינים, כדי שהבחירה תהיה מנומקת ולא יחידה.
- בדיקה על תקופה מושהית. בודקים על נתונים שלא השתתפו באימון, כולל קטעים עם שינוי משטר. בוחנים יציבות לפי אנשים ולפי זמן, ולא רק מדד ממוצע.
- העברה לתפעול. פורסים במעגל הייצור של הלקוח: זרימות נתונים, עמידות לתקלות, תיעוד ביומן והתראות על הידרדרות אותות הקלט.
- הכשרת הצוות. מעבירים נהלי עבודה, ולא מצגת: כיצד לאמן מחדש, כיצד לחזור לגרסת מודל קודמת, מה לעשות בעת החלפת מכשיר.
- קבלה ומסירה. מריצים יחד תרחישי בקרה, מתעדים מדדי קבלה, תיעוד ותחומי אחריות.
מה נשאר אצל הלקוח: מודלים, קונפיגורציות ותקנות
למסור ללקוח מודל מאומן זה לא מספיק — בלי קונפיגורציה, סכמות אינטגרציה ותקנות אי אפשר להפעיל ולפתח אותו. לכן את החבילה אנו מרכיבים כך שצוות הלקוח יתחזק את המערכת בעצמו: ישנה פרמטרי עיבוד, יחבר מקורות חדשים ויטפל בתקריות בלעדינו.
- קונפיגורציית עיבוד: חלונות צבירה של אותות, ספי הפעלה, כיול נורמה אישית לפי השבועות הראשונים של ענידה, כללים לדיכוי סטיות שווא בעת חוסרים בנתונים.
- סכמת אינטגרציה של מקורות: אילו התקנים לבישים ואפליקציות מחוברים, פורמטי ייצוא, תדירות סנכרון, התנהגות בעת ניתוק קשר ומסירה חוזרת.
- מדיניות גישה לנתונים רגישים: תפקידי המומחים, הפרדה לפי מחלקות, תקופות שמירה, אנונימיזציה בעת ייצוא לדיווח, יומן פניות.
- תיעוד המערכת: תיאור המאפיינים והמודל, גבולות היישום, מקרים שבהם התוצאה אינה ודאית ודורשת בדיקה ידנית.
- תקנון תחזוקה: בקרת דריפט, אימון מחדש מתוכנן, תגובה לירידה באיכות, נוהל חזרה לגרסה קודמת.
- נוהל קבלה: הרצה על נתונים היסטוריים של הלקוח, השוואה לסימון ייחוס, תיעוד מדדים לפני ואחרי ההטמעה.
המסירה נחשבת לסגורה כשהמומחים של הלקוח עצמם משנים ספים, מחברים מקור חדש ומטפלים בתקלה לפי התיעוד. בהמשך נשאר ערוץ קשר עם המהנדסים שלנו — לשינויים במודל ולהרחבת מערך האותות.
מקרה בוחן: צמצמנו אפיזודות שהוחמצו בחצי בקבוצת פיילוט
את הפיילוט הפעלנו בקבוצה עם משמרות מתחלפות: התקנים לבישים סיפקו דופק, שונות קצב הלב ואיכות שינה, והמודל סימן אפיזודות שאותן בדק רכז ידנית. בנקודת הפתיחה עמדה לוגיקת סף — היא החמיצה כל אפיזודה משמעותית שלישית, מפני שסטיות חדות על רקע עייפות מצטברת נראו כמו התאוששות רגילה.
מה שינינו
את הלוגיקה כתבנו מחדש: המודל מעריך לא ערכים בודדים, אלא דינמיקה יומית — שינוי בקו הבסיס האישי, מהירות התאוששות לאחר מאמץ, פיזור מדדי הלילה. סף ההפעלה הפך אדפטיבי והתאים את עצמו לנורמה של האדם הספציפי, ואותות מהאזור האפור עברו לרכז עם סימון «ודאות נמוכה» במקום הפעלה כברירת מחדל.
תקופת הניטור — שמונה שבועות, ההשוואה נעשתה מול החודשיים הקודמים על אותם אנשים. שיעור האפיזודות שהוחמצו ירד מ-31% ל-12%, רמת התראות השווא — מ-4.1 ל-1.5 פניות לאדם בשבוע: הרכז הפסיק לבדוק רעש. זמן התגובה התקצר מיממה וחצי לכמה שעות, מפני שהתור נבנה לפי ודאות המודל, ולא לפי זמן הגעת האות.
לא היה צורך להחליף את מלאי המכשירים: מקור הנתונים — Garmin וצמידים תואמים. המודל אומן נוסף על סימוני הרכזים: כל אפיזודה שנסגרה דייקה את הנורמה האישית, ולכן האיכות עלתה לאורך הניטור, ולא הגיעה לפלטו.
מה לעשות אם הנתונים כבר נאספים במעגל אחר?
האיסוף כבר מוסדר — באמצעות שירות צד שלישי, פלטפורמה של יצרן ההתקנים הלבישים או מערכת של מחלקה אחרת. יש מספיק נתונים, אך הגישה מוגבלת לפורמט הייצוא, והמאפיינים מחושבים לפי מודל זר. עבור ניטור ה-AI שלנו של מצב נפשי, סטים כאלה מתאימים רק באופן חלקי.
אנו עושים שימוש חוזר בסדרות זמן גולמיות: דופק, שונות קצב הלב, משך ושלבי שינה, פעילות מוטורית, טמפרטורת עור. אם הייצוא מספק דגימות עם חותמות זמן, ולא רק צבירות יומיות, מעבירים אותן למעגל שלנו ומחשבים מחדש את המאפיינים לפי המודל שלנו.
כאשר בפלט יש רק ניקוד או סיכומים יומיים, אי אפשר לשחזר מהם פיזיולוגיה — את שכבת החיישנים יהיה צורך להקים מחדש.
תאימות מקורות נפתרת בשכבת נרמול: דגמי צמידים שונים נותנים תדירות דגימה משלהם וכיול משלהם. אנו מביאים הכול לסקאלת זמן אחידה, חותכים ארטיפקטים של ענידה, ומסמנים את סוג המכשיר ואת גרסת הקושחה. בלי זה, השוואה של אדם עם עצמו כעבור חודש תיתן דינמיקה כוזבת.
פער בניטור יקר ממה שנראה: קו הבסיס הוא אישי לכל אחד, וחוסר של כמה ימים שובר את ההשוואה להיסטוריה. לכן המעבר נעשה בלי הפסקה — במקביל אנו מקימים איסוף משלנו, משווים חותמות זמן ופערים בחלונות בקרה, ורק לאחר התאמה מכבים את המעגל הישן.
נתונים היסטוריים נלקחים כארכיון ומסומנים לפי איזה מודל חושבו: הדיווח אינו נשבר, והמסקנות החדשות נבנות כבר בצד שלנו.
ספקות טכניים: דיוק, פרטיות, התראות שווא
ספקות לגבי מערכות כאלה עולים לא סביב «עובד או לא», אלא סביב מדידות: כיצד מחושבת איכות המודל, מה קורה לנתונים פיזיולוגיים, מי מקבל גישה וכיצד המערכת מתנהגת בעת הידרדרות אות — אובדן קשר, צמיד שהוסר בלילה, הצמדה חלשה של החיישן.
כיצד נמדדת איכות המודל, ולא «דיוק על הנייר»?
על מדגם מסומן אנו מחשבים שני מדדים נפרדים: רגישות (שיעור האפיזודות שנמצאו בפועל) ושיעור התראות השווא. את סף ההפעלה מכווננים לפי המשימה: בתרחיש קליני מזיזים אותו לעבר רגישות, ובארגוני — לעבר שקט, כדי לא להטריד אנשים לחינם. את המדדים מתעדים לפני השחרור וממשיכים לעקוב אחריהם בזרימה חיה.
מה קורה עם נתונים רגישים?
האות הגולמי נשאר במעגל הלקוח: המאפיינים מחושבים בצד המכשיר, והחוצה יוצא מצרף — מגמה, סטייה מקו הבסיס האישי, סוג האפיזודה. הגישה מופרדת לפי תפקידים, ופנייה לשדות רגישים נרשמת ביומן.
כיצד מנוסחת הסכמת המשתמש?
ההסכמה היא שלב נפרד עם רשימה מובנת: אילו מדדים נקראים, למי ובאיזו צורה הם גלויים, ולכמה זמן. החזרה מההסכמה פועלת באותה בהירות: הנתונים נמחקים או עוברים אנונימיזציה לפי כלל שהוגדר מראש, ולא «מתישהו אחר כך».
מה יקרה בעת הידרדרות האות?
המערכת עוקבת אחר איכות זרימת הקלט: שיעור החוסרים, רעש, יציבות הענידה. אם האיכות יורדת מתחת לסף, המרווח מסומן כלא אמין והמודל שותק במקום להתריע — כך התראות השווא אינן גדלות יחד עם הרעש.
נדון במשימה: מה כבר קיים ולמול איזו תוצאה אנו הולכים
כדי לחזור עם הערכה מעשית ותוכנית לשלב הראשון, ולא עם שיקולים כלליים, נדרש מאיתנו חתך קצר לפי המשימה שלכם. תארו מה כבר קיים: אילו התקנים לבישים נמצאים במעגל, אילו מדדים נלקחים מהם ובאיזו צורה הנתונים מגיעים אליכם היום. להלן מה שמסיר את רוב אי-הוודאויות כבר בהתחלה.
- מלאי המכשירים: דגמי שעונים, צמידים או טבעות והחלק היחסי של כל אחד — מכך תלויים מערך המדדים הזמין ותדירות הרישום שלהם.
- הרכב הנתונים: דופק, שונות קצב הלב, איכות ושלבי שינה, רמת פעילות, סימונים סובייקטיביים של המשתמש.
- פורמט ונתיב הנתונים: ייצוא בקבצים, פנייה לענן של היצרן או איסוף עצמאי, האם קיים ארכיון היסטורי ובאיזו תקופה.
- דרישות לנתונים: האם נדרשת אנונימיזציה, היכן מותר לאחסן רשומות, כיצד מנוסחות הסכמות המשתמשים.
- מה נחשב לתוצאה: אות למומחה בעת סטייה, דוח לאדם על מצבו, או תמונה מצטברת לפי קבוצה.
- נקודת ההטמעה: אפליקציית מובייל, פורטל ארגוני, אזור אישי של המומחה — לאן התוצאה צריכה להגיע.
- מגבלות: לוחות זמנים להטמעה שאליהם אתם כבר מחויבים, ודרישות חיצוניות למערכת.
עם המערך הזה אנו חוזרים עם הערכה ותוכנית עבודה: מה עושים בשלב הראשון, אילו דרישות לנתונים מתעדים וכמה זמן נדרש להטמעה. תארו את המשימה — נדון לגופו של עניין.







