פיתוח והטמעה של Edge AI / TinyML על מיקרו-בקרים

פיתוח Edge AI: היכן פרויקטים נשברים על התקנים

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

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

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

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

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

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

מה נותנת הסקת המודל ישירות על ההתקן

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

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

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

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

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

גישות להטמעה: השוואת אפשרויות

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

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

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

שלבי פיתוח והטמעה באתר

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

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

ערכת מסירה: מודלים, סכימות ותקנות

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

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

מקרה בוחן: בקרת איכות בקו ייצור

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

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

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

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

מתי הסקה על ההתקן מפסידה לשרת

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

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

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

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

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

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

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

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

שאלות ששואלים לפני ההתחלה

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

הדיוק בקבלה נמוך מהצפוי — מה הלאה?

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

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

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

מי מתייג את מערך הנתונים?

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

מה כלול בתמיכה לאחר המסירה?

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

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

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

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

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

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