פיתוח מודל AI למיקרו-בקרים (TinyML)

המודל לא נכנס למיקרוקונטרולר: היכן פרויקט TinyML נשבר

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

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

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

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

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

מה משתנה כשהסקת המודל עוברת אל ההתקן עצמו

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

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

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

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

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

TinyML, אלגוריתמים קלאסיים או ענן: מה לבחור

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

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

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

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

שלבי פיתוח המודל למיקרוקונטרולר

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

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

ארטיפקטים של הפרויקט: מודל, קושחה, תיעוד

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

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

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

פרקטיקה: מודל לחיישן רעידות ב-TinyML

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

מה שינו

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

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

מדדים לפני ואחרי

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

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

מה לעשות אם מודל מאומן לא נכנס להתקן?

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

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

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

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

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

ספקות של צוותים הנדסיים: עונים לגופו של עניין

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

כיצד לעדכן את המודל בהתקנים שכבר נפרסו?

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

יש מעט נתונים לאימון — ממה להתחיל?

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

כיצד להבחין בהידרדרות המודל בשדה?

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

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

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

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

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

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