ניטור בינה מלאכותית של כושר גופני לפי חיישנים

מדוע ניטור AI של כושר גופני נשבר על נתונים אמיתיים

על מתנדב אחד עם לוח זמנים אחיד המערכת מפיקה עקומות יפות: דופק, קצב, התאוששות. בתפעול אמיתי ניטור AI של כושר גופני נשבר לא על המודל, אלא על מה שמגיע לקלט. עשרות אנשים, מכשירים שונים, אופני ענידה שונים — ואיכות נתוני הקלט הופכת למגבלה המרכזית.

פערים בטלמטריה הם הדבר הראשון שכל אלגוריתם נתקל בו. צמיד שהוסר, טלפון שהתרוקן, אובדן קליטה במרתף — בהקלטה מופיעים חורים של דקות ועד שעות. אינטרפולציה פשוטה ממלאת אותם במספרים סבירים, והמודל מחשב עומס לפי נתונים שלא היו.

אי-סנכרון חיישנים יוצר סוג שני של שגיאות. מד הדופק ומד התאוצה כותבים בקצבים שונים, הענן מוסיף השהיה — הזרמים מגיעים בהיסט של שברירי שנייה. בלי איחוד לציר זמן אחד, שיא העומס מחושב לפי חלון אחד וההתאוששות לפי החלון הסמוך.

רעש וארטיפקטים בהקלטה — מכה במעקה, רעד של היד, רצועה שהחליקה — מוסיפים קפיצות שכללי סף מפרשים כעבודת אינטרוולים.

לכך מתווספים כפילויות בסנכרון מושהה ופער בשעונים בין המכשיר לשרת. בחירת מודל מעל נתונים מלוכלכים לא מרפאת את זה: קודם כל נדרשים ולידציה של הקלט, ציר זמן אחיד וכללי פסילה של חלונות. להלן נפרק כיצד זה נסגר.

מה נותן ניטור רציף של המצב: אפקטים מדידים

את אפקט ההטמעה סופרים לא בתחושות, אלא בגדלים מדידים: כמה זמן לוקח הדוח, איזה חלק מההתראות הוא שווא, אילו כשלים אנו מיירטים וכמה מהר אנו מגיבים לסטייה.

הדוח מוכן עד הבוקר, ולא אחרי יממה

נתונים ממכשירים לבישים ומחיישנים נאספים למאגר באופן רציף, ולכן סיכום על ספורטאי או על משמרת נבנה אוטומטית לתחילת היום. הזמן עד לדוח מוכן מתקצר משעות של איחוד טבלאות ידני לדקות, והדינמיקה נראית על פני תקופה, ולא כחתך בתאריך בדיקה.

התראות שווא נחתכות בקלט

חריגה בודדת בדופק או פער באות אינם מעירים את התורן: הכלל מופעל על סטייה יציבה בחלון תצפית. חלק התראות השווא יורד לאUnits של אחוזים — תשומת הלב של הצוות עוברת לניתוח סטיות אמיתיות, ולא לרעש בנתונים.

אימון יתר נראה לפני השבירה

המודל משווה עומס, שונות קצב הלב ואיכות שינה, ולכן תשישות מצטברת מתגלה כמה ימים לפני ירידת התוצאה. זהו סוג כשל שבמדידות תקופתיות כלל לא יורט.

ניטור התאוששות ותגובה לסטייה

תוכנית העומס נבנית מהמצב בפועל, ולא מלוח הזמנים: ניטור ההתאוששות נשען על נתונים, ולא על הערכה עצמית. זמן התגובה לסטייה — מהופעת הסימן ועד תיקון התוכנית — נמדד בשעות, ולא בימים של תיאומים.

הוצאת נתונים משעונים וצמידים אנו מבצעים דרך אינטגרציות פתוחות, למשל Garmin Health — הזנה ידנית של נתונים יוצאת מהתהליך.

אופני איסוף נתונים ועיבוד עומס: מה לבחור למשימה

אופני איסוף הנתונים ומקום העיבוד הם שני פתרונות בלתי תלויים, ואין לבחור בהם בנפרד. תדירות הדגימה של החיישנים קובעת איזה נפח אות ממשיך הלאה, והמקום שבו הוא מחושב — במכשיר או בענן — קובע את השהיית התגובה, את האוטונומיה ואת הדרישות לערוץ התקשורת.

נקודת ייחוס לתדירות הדגימה אינה "כמה שיותר, כך מדויק יותר", אלא הפיזיקה של התנועה: אם דוגמים בתדירות גבוהה בהרבה מקצב השינוי של הגודל הנמדד, ההפרש הולך לרעש ולעומס תעבורה מיותר. להלן האפשרויות שביניהן באמת בוחרים, והמגבלות שלהן.

אפשרויות ומגבלות

בפועל משלבים בין התרחישים: סינון ראשוני וזיהוי אירועים מתבצעים במכשיר, וזיהוי תבניות מורכבות וחישוב מחדש של ההיסטוריה — בענן.

מעבר כזה מוגדר בקונפיגורציה, ולא בכתיבה מחדש של הקושחה, ולכן החלפת מצב אינה שוברת נתונים שכבר נצברו ומאפשרת לחזור לאפשרות הקודמת אם איכות האות באתר מתבררת כנמוכה מהצפוי.

כיצד אנו מטמיעים את המערכת: שלבי העבודה ההנדסית

אנו מתחילים לא מהמודל, אלא מהנתונים: בלי סנכרון חיישנים ותיוג, אנליטיקת הכושר מפיקה גרפים יפים בלי משמעות מעשית. שבעת השלבים בנויים כך שהסיכונים נחשפים על ארכיונים, ולא על משתמשים חיים — כל שלב נשען על תוצאה מדודה של קודמו.

1. אודיט נתונים. מפרקים את מה שכבר קיים: אילו חיישנים וצירים, תדירות דגימה, חלק הסשנים המתויגים, פערים ואי-סנכרון בין הזרמים. מתעדים אילו הקלטות חסרות וכיצד לאסוף אותן.
2. תרשים הפתרון. מגדירים מדדי כושר יעד, חלונות ניתוח ומאפיינים; מחליטים מה מחושב במכשיר ומה בשרת — מכך תלויים השהיית התגובה ונפח ההעברה.
3. הגדרת העיבוד. מסננים רעש, מכיילים חיישנים, מאחדים את הזרמים לציר זמן אחד ומתייגים שלבי תנועה. בפלט — מערך מאפיינים בלתי תלוי במכשיר מסוים.
4. בדיקה על נתונים היסטוריים. מריצים את העיבוד על הארכיון ומצליבים עם תיוג מומחה: סופרים שגיאה לפי סוגי תרגילים ומחפשים היכן המודל מבלבל בין תנועות דומות.
5. פיילוט על קבוצה מוגבלת. בוחנים התראות שווא, נפילות סנכרון ואיכות בתנאי אות חלש של החיישן; מאמנים מחדש על המקרים הבעייתיים.
6. אינטגרציה. מחברים את הפתרון לאפליקציה או לפאנל, מגדירים עיבוד זורם ובקרת איכות של נתוני הקלט.
7. מסירה והדרכת הצוות. מוסרים תיעוד, נוהל אימון מחדש והרשאות, מנתחים אירועים ומלמדים את הצוות לתחזק את המערכת באופן עצמאי.

מה נשאר אצלכם בידיים: קונפיגורציות, תרשימים, נהלים

פתרון לניטור כושר גופני נשאר לעיתים קרובות כבול לצוות שבנה אותו: לא ניתן לעדכן מודל או לנתח אירוע בלי היוצרים. לכן אנו מוסרים ערכה שלפיה המהנדסים שלכם פורסים את המערכת מחדש ומתחזקים אותה בעצמם.

• תיעוד הפתרון — ארכיטקטורת השירותים, דרישות לסביבה, תלויות ותיאור הקשר "איסוף מדידות מהחיישנים → חישוב מדדים → מסירה למשתמש". כתוב עבור התשתית שלכם, ולא כתיאור כללי של מוצר.
• תרשימי זרימת נתונים — מהיכן מגיעות המדידות הגולמיות, היכן הן מנורמלות, אילו מאפיינים הם נגזרים, היכן נשמרת ההיסטוריה וכיצד נבנים חלונות הדיווח. התרשים מאפשר להוסיף סוג חיישן חדש בלי לכתוב מחדש את העיבוד.
• מדיניות הרשאות — תפקידים, זכויות על נתונים אישיים, הפרדה בין תרחישי תמיכה וביקורת, כללי שמירה ומחיקה לפי בקשה של משתמש.
• נהלי תפעול — בדיקות יומיות, מה נחשב לאירוע, סדר ההסלמה, פעולות במקרה של אי-זמינות מקור נתונים או פער בין החישוב לתוצאה בפועל.
• בקרת איכות המודל — מערכי נתוני ייחוס, ערכי סף של מדדים, בדיקה להטיה לפי קבוצות משתמשים, כללי נסיגה לגרסה קודמת.
• הוראות לאימון מחדש — כיצד לאסוף ולתייג מערך חדש, להריץ אימון ולהשוות את התוצאה לגרסה הנוכחית; יומן ניסויים וקריטריוני קבלה.

מקרה בוחן: ניטור התאוששות ספורטאים לאחר עומסים

המשימה הגיעה מהמטה שמכין ספורטאים במחנות אימון: המאמנים אספו ידנית שינה, דופק מנוחה ודינמיקת התאוששות ממכשירים לבישים לטבלאות והצליבו בעין. בקבוצה של כמה עשרות אנשים, הערכת המצב בבוקר עוד נכנסה לנוהל, אבל סטיות שהצטברו במהלך היום צפו רק באימון הבא — את העומס עד אז כבר נתנו. חלק הסטיות שהוחמצו עמד על כשליש.

מה שינו

זרם הנתונים מהחיישנים של Garmin וממדדי דופק חזה מתאחד למאגר אחד: שינה, דופק מנוחה, קצב התאוששות והערכה סובייקטיבית של ההרגשה מובאים למודל משותף.

לאחר מכן מחושבת לכל ספורטאי בסיס אישי על פני השבועות הקודמים, והערכים הנוכחיים מושווים בדיוק אליו — "שינה גרועה" חדלה להיות סף אחיד לכל הקבוצה. האות עולה כאשר כמה מדדים יוצאים מהמסלול בו-זמנית, ולכן התראות שווא פחתו, והמאמן לא מתרגל להתעלם מההתראות.

מה השתנה

מדדים לפני ואחרי: סטיות שהוחמצו — 31% מול 6%, דיוק הערכת המצב — 74% מול 92% בהצלבה עם מסקנות רופא הקבוצה. זמן התגובה של המאמן התקצר מ-20 שעות ל-40 דקות — ההתראה מגיעה לאותו ממשק שבו מתכננים את העומס.

הירידה בתחלואה באה לידי ביטוי בבלוקים האינטנסיביים: חלק הפגיעות ברקמות הרכות בתקופת ההכנה קטן בכמחצית.

ניתוח של ספורטאי אחד דרש 12 דקות של הצלבה ידנית, וכעת — כשתי דקות. בצוות של ארבעה מאמנים זה מפנה כמה שעות ביום, והן עוברות לעבודה אישית, ולא לאיחוד טבלאות.

במה עיבוד זורם שונה מניתוח אצווה?

השאלה אינה במהירות המודל, אלא היכן מתבצע החישוב. עיבוד זורם מחשב מאפיינים עם הגעתן של דגימות מהחיישנים: התגובה מגיעה תוך שניות, והמערכת מספיקה להתערב ממש בתרגיל.

ניתוח אצווה לוקח את הסשן כולו — מדויק יותר מבחינת הקשר, אבל התוצאה מופיעה כעבור דקות או שעות, כשהאימון כבר מזמן הסתיים.

השהיית התגובה של המערכת תלויה לא רק באלגוריתם. תבנית זורמת זקוקה לערוץ קבוע ולחוצץ במכשיר, אחרת ניתוק הקישור קוטע את ההנחיות; תבנית אצווה שורדת אובדן קישור וצורכת משאבים בצורה אחידה יותר, כי אפשר לפזר את העומס על פני הזמן.

בפועל לרוב מנצחת התבנית ההיברידית. במכשיר נשאר מודל קל — החלקת אות, זיהוי תנועה, ספי עומס; במרכז מודל כבד מחשב מחדש את הסשן על נתונים מלאים. ההנחיה ברגע נתון אינה ממתינה להוצאה, וההערכה הסופית אינה סובלת מחלון תצפית מקוצץ.

את בחירת הארכיטקטורה אנו מתחילים לא מהטכנולוגיות, אלא מהשאלה: איזו החלטה המערכת מקבלת בעצמה וכמה מהר. אם מחיר הטעות הוא אימון מקולקל או פציעה, נדרשת תגובה תוך שניות; אם מדובר בתיקון התוכנית לשבוע הבא, די בניתוח אצווה.

ספקות טכניים: דיוק, התראות שווא, פרטיות

הדיוק של ניטור AI לכושר גופני אינו מספר אחד, אלא טווח שתלוי בסוג החיישן, במקום ההידוק ובפיזיולוגיה של האדם המסוים. לכן איננו מציגים "דיוק של 98%", אלא מחשבים את השגיאה על מדגם בקרה ומוסרים אותה יחד עם רווח סמך: היכן המודל בטוח, והיכן הנתונים מועטים וההערכה משוערת. כיול עבור הספורטאי הוא שלב חובה, ולא אופציה.

כיצד אתם מתמודדים עם התראות שווא?

אירוע נרשם לא לפי חריגה אחת מהסף, אלא לפי סטייה יציבה בחלון מחליק עם היסטרזיס — כך חריגה בודדת מטלטול או מהפרעה אינה הופכת להתראה. אירועים קריטיים מאושרים על ידי אות בלתי תלוי נוסף, וחלק ההתראות השווא נמדד על מערך מתויג ונשאר בדוח לאחר כל עדכון של המודל. אם צריך להזיז את הסף למשימה, זהו פרמטר בקונפיגורציה, ולא כתיבה מחדש של הלוגיקה.

מה קורה עם נתונים אישיים?

מדדים גולמיים מעובדים במכשיר, והחוצה יוצאים אגרגטים ואירועים, ולא זרם טלמטריה רציף. הסכמה לעיבוד נתונים אישיים ניתנת באופן מפורש, תקופת השמירה נקבעת במדיניות ומוגבלת, הגישה מופרדת לפי תפקידים, ומחיקה לפי בקשה נוגעת גם לחישובים הנגזרים. בעת הצורך הנתונים עוברים אנונימיזציה לפני הכניסה למאגר.

מה אם החיישן הוסר או שהנתונים אבדו?

פערים אינם מושלמים בניחושים: הקטע מסומן כבלתי מהימן ומוצא מההערכה. לאחר החזרת החיישן אנו מחשבים את החלון מחדש, ואם תזוזה של ההידוק מורגשת — מבקשים כיול חוזר, כדי לא לגרור את השגיאה לסשנים הבאים.

נדון במשימה ונחזור עם הערכה ותוכנית

כדי שהערכת לוחות הזמנים תישען על נתונים ולא על הנחות, אנו מתחילים מניתוח המשימה ותנאי הקלט. נדון במשימה בהקשר שלכם: היכן המערכת פועלת, מי משתמש בה, איזו תוצאה נחשבת להצלחה ומה כבר קיים ברשותכם.

להתחלה די להעביר לנו את הדברים הבאים:

• תיאור החיישנים, אופן ההידוק שלהם והתנועות שאתם מחשיבים לייחוס — מכך תלוי מה האלגוריתם יפרש כהפרעה ומה כאות מועיל;
• הוצאה של הקלטות גולמיות מכמה אימונים, ובהכרח עם הערות מאמן היכן הביצוע נכון והיכן לא;
• מדדי יעד: מה נחשב לחזרה נכונה ואיזו רמה של התראות שווא מקובלת בעבודה בפועל;
• תנאי התפעול — חדר כושר, חוץ או אימונים בבית, עד כמה יציב מעבר הנתונים מהחיישנים;
• דרישות לשמירה ולפרטיות: היכן מעובדות ההקלטות ואילו הגבלות גישה חלות;
• קריטריוני הקבלה שלכם והאחראי שמאשר את התוצאה לפי שלבים.

בתגובה נשלח תוכנית הטמעה: הרכב העבודה לפי שלבים, הערכת לוחות זמנים לכל אחד ותרשים פיילוט על הנתונים שלכם עם מדדי קבלה. הפיילוט רץ על נפח הקלטות מוגבל ואינו דורש לשנות את המערכות שלכם — מתוצאותיו נראה אם הזיהוי מגיע לאיכות הנדרשת לפני השקה תעשייתית.

תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.