רכבים אוטונומיים, רובוטים תעשייתיים וצי רחפנים אינם פועלים לפי ספרי חוקים נוקשים שנכתבו ידנית והניעו מערכות טייס אוטומטי ישנות. הם לומדים מכמויות עצומות של נתונים, מה שאומר שההתנהגות שלהם היא הסתברותית ולא דטרמיניסטית. טייס אוטומטי מסורתי של מטוס מגיב לקלטי חיישנים באמצעות לוגיקה המקודדת במפורש. מודל למידת מכונה מגיב באמצעות תבניות שהוא הסיק במהלך האימון. הבחנה זו הופכת את האימות לקשה הרבה יותר, וזו בדיוק הסיבה שקהילת למידת המכונה עברה לעבר מסגרות הבטחת איכות (assurance frameworks) מובנות במקום בדיקות אד-הוק.
מדוע הבטחת איכות של למידת מכונה היא בלתי מתפשרת
כאשר מערכת אוטונומית טועה, ההשלכות חורגות מעבר לשגיאת שרת או אפליקציה קפואה. רובוט מחסן המזהה בטעות מכשול עלול להרוס מלאי או לפצוע עובד. רחפן משלוחים המסווג קו חשמל כשמיים פתוחים עלול להתנגש בתשתית. מכיוון שמערכות אלו מסתמכות על רשתות נוירונים מורכבות ומודלים סטטיסטיים, מצבי הכשל שלהן הם מעודנים. הן כמעט ולא נשברות בדרכים ברורות. במקום זאת, הן דועכות בשקט כאשר הן נתקלות בקלטים שנמצאים מחוץ להתפלגויות שהן ראו במהלך האימון.
שגיאות בלמידת מכונה אוטונומית אינן נובעות תמיד מקוד רע באופן מובהק. הן יכולות להופיע כתוצאה מפערי נתונים באימון, שינויים סביבתיים בלתי צפויים, או תחזיות בעלות ביטחון עצמי מופרז במקרי קצה. ארגונים המתייחסים לרכיבי ML כאל מודולים של תוכנה סטנדרטית, מתוך הנחה שערכת בדיקות יחידה (unit test suite) היא מספיקה, מגלים מאוחר מדי שדיוק מעבדתי אינו מתרגם לבטיחות בעולם האמיתי. אתם זקוקים לתקן שיטתי שמתייחס לסיכונים הייחודיים של התנהגות נלמדת. זהו הפער שמסגרת AMLAS נועדה לסגור.
מה AMLAS באמת מכסה
AMLAS, שפירושה Assurance of Machine Learning for use in Autonomous Systems, מספקת גישה מקצה לקצה לאימות לכך שרכיבים נלמדים מתאימים לפריסה במצבים בעלי סיכון גבוה. היא אינה מתייחסת לבטיחות כאל מחשבה שבדיעבד או כשער אחרון לפני שחרור. במקום זאת, היא שוזרת פעילויות הבטחת איכות לתוך מחזור החיים של המערכת.
המסגרת מתמקדת בשלושה עמודי תווך מעשיים:
שיטות אימות למודלי ML. זה הולך הרבה מעבר למדדי חלוקת אימון-בדיקה סטנדרטיים כמו דיוק (accuracy) או מדד F1. הבטחת איכות תחת AMLAS שואלת האם המודל מתנהג בצורה צפויה בגבולות ההחלטה, כיצד הוא מגיב לקלטים מחוץ להתפלגות (out-of-distribution), והאם מדדי הביטחון שלו הם אינדיקטורים אמינים של אי-ודאות ממשית. מהמהנדסים מצופה לבחון את המודל באמצעות דוגמאות אדברסריות (adversarial examples) ולבצע בדיקות עומס מול קלטים מתחומים שנמצאים מעט מחוץ סט נתוני האימון. המטרה אינה שלמות. המטרה היא להשיג מספיק ראיות כדי לדעת מתי ניתן לסמוך על המודל ומתי לא.
פרוטוקולי בטיחות לפעולות אוטונומיות. מודל תפיסה (perception model) נלמד מזין תוכנת תכנון ובקרה שמניעה חומרה פיזית. AMLAS דורשת שפעולות אלו בשלבים הבאים יכללו מעקות בטיחות (guardrails). גם אם רשת נוירונים מסווגת אובייקט בטעות, הרכב או הרובוט לא אמורים להיות מסוגלים פיזית לבצע מסלול המפר את אילוצי החומרה. זה עשוי להיות מגבלות מומנט בזרועות רובוטיות, גיאופנסינג (geofencing) לרחפנים, או מסדרונות בלימה מחייבים לכלי רכב קרקעיים. המערכת האוטונומית זקוקה לשכבות ארכיטקטוניות שמונעות מטעות של מודל בודד להפוך לאירוע פיזי בלתי נשלט.
שיטות להפחתת אי-ודאות. אי-ודאות בלמידת מכונה מגיעה בצורות מרובות. ישנה אי-ודאות אלאטורית (aleatoric uncertainty), רעש מובנה בקריאות חיישנים או בסביבות, ואי-ודאות אפיסטמית (epistemic uncertainty), המשקפת את מה שהמודל עדיין אינו יודע. AMLAS מעודדת פרקטיקות המכמתות ומנהלות את שתיהן. טכניקות יכולות לכלול שיטות אנסמבל (ensemble methods), שבהן מספר מודלים מסמנים חוסר הסכמה כסימן אזהרה, או שכבות תיקוף קלט הדוחות נתונים הידועים כגורמים להתנהגות לא עקבית. ייתכן שלא תוכלו לחסל את אי-הוודאות לחלוטין, אך תוכלו למנוע מהמערכת לפעול באופן עיוור על פיה.
נתיב מעשי לבניית אמון
מסגרות עבודה משמעותיות רק אם צוותים מיישמים אותן בפועל. AMLAS מתורגמת בצורה הטובה ביותר לפעולה כאשר ארגונים פועלים לפי רצף ממושמע.
הגדירו את יעדי הבטיחות שלכם לפני שתאספו אפילו סט נתונים אחד. בהנדסת תוכנה מסורתית, הדרישות מגיעות ראשונות. פרויקטים של למידת מכונה הופכים לעיתים קרובות את הסדר הזה, ומתייחסים לבטיחות כבעיה שיש לפתור לאחר שהמודל כבר אומן. הפכו את ההרגל הזה. התחילו עם תחום עיצוב תפעולי (operational design domain) ברור. תחת אילו תנאים המערכת תפעל? מהו שיעור כשלים נסבל עבור כל סיכון? אילו כשלים דורשים התערבות אנושית מיידית? מענה על שאלות אלו בשלב מוקדם מעצב את הכל — מאיסוף הנתונים ועד לארכיטקטורת המודל.
בדקו את המודלים שלכם מול נתונים המשקפים את הבלגן התפעולי האמיתי. מדדי מעבדה (benchmarks) הם מרגיעים, אך הם משקרים. רובוט מחסן שאומן אך ורק על תמונות ברקוד נקיות ייכשל כאשר התוויות מקומטות, מוארות בצורה גרועה או חסומות בלכלוך. רחפן אוטונומי שנבדק רק במזג אוויר נוח יתקשה עם סנוור ורוחות חזקות. אתם זקוקים ליומני רישום (logs) מסביבות פריסה אמיתיות, כולל מקרי הקצה (edge cases) המתסכלים שמעולם לא מופיעים במאגרי נתונים מסודרים. הריצו ניסויי "מצב צל" (shadow mode) שבהם המערכת האוטונומית מקבלת החלטות במקביל למפעילים אנושיים אך עדיין אינה שולטת בחומרה. השוו את היומנים באופן קפדני.
נטרו את הביצועים באופן רציף לאחר הפריסה. העולם אינו עומד במקום. שינויים עונתיים בתאורה, משטחי כביש שחוקים, עיצובי אריזה חדשים ותבניות תעבורת רשת משתנות יכולים כולם לפגוע במודל שבעבר תפקד בצורה מרשימה. הקימו מערכת טלמטריה העוקבת אחר ביטחון בחיזוי (prediction confidence), סטייה בהתפלגות הקלט (input distribution drift) ושיעורי תקריות. קבעו ספים שיפעילו בדיקה אנושית או הגבלות תפעוליות זמניות כאשר מתרחש שינוי בהתנהגות. מודל אינו מוצר סטטי ששולחים ושוכחים. הוא רכיב שמתיישן ברגע שהוא פוגש את העולם האמיתי.
האמת הקשה על תיקוף בעולם האמיתי
צוותים רבים משכנעים את עצמם שציון תיקוף (validation score) גבוה מעיד על מוכנות. הוא לא. תיקוף בעולם האמיתי דורש אימוץ של חוסר נוחות. המשמעות היא להטיס רחפנים בתנאי רוח חזקים, להפעיל רובוטים במחסן במהלך משמרת הלילה כשהנורות מהבהבות, ולחשוף מודלים של תפיסה (perception models) למדבקות אדברסריות (adversarial stickers) על תמרורים. אם סביבת הבדיקה שלכם מרגישה מסודרת וצפויה, אתם לא בודקים. אתם מתרגלים.
תהליך זה יקר ואיטי. הוא דורש שיתוף פעולה בין מהנדסי למידת מכונה, מומחי בטיחות ומפעילים בתחום שמבינים את הסביבה הפיזית. התמורה היא גוף של ראיות. כאשר תפרסו בסופו של דבר, אתם אמורים להיות מסוגלים להצביע על תנאי בדיקה ספציפיים, מצבי כשל ידועים ודרכי הפחתה הקשורות לכל סיכון. התיעוד הזה הוא מה שמפריד בין אב-טיפוס לבין מערכת שאתם מוכנים להפעיל ללא השגחה ליד בני אדם.
לשמור על אמינות המערכות לאורך זמן
ניטור לאחר פריסה הוא המקום שבו תוכניות הבטחת איכות רבות קורסות בשקט. צוותים חוגגים את ההשקה ומקצים מחדש משאבים לתכונה הבאה. בינתיים, המודל הפרוס מתמודד עם זרם של קלטים שסוטים בעדינות ממהלך האימון שלו. ללא ניטור פעיל, הסטייה הזו מצטברת עד שתקרית חמורה תאלץ לבצע חקירה רטרואקטיבית.
הקימו לולאות משוב מובנות. רשמו כל מקרה שבו המודל מביע ביטחון נמוך או שבו מפעילים אנושיים מתערבים. השתמשו ביומנים אלו כדי לאמן מחדש או לבצע כוונון עדין (fine-tune) למודל באופן תקופתי, אך תקפו כל עדכון דרך אותם שערי הבטחת איכות (assurance gates) שהוחלו על הגרסה המקורית. התייחסו לעדכוני מודל באותה זהירות שהייתם מיישמים בעת החלפת מערכת בלמים מכנית בעיצוב חדש.
השורה התחתונה
למידת מכונה במערכות אוטונומיות אינה ארגז חול מחקרי. היא תשתית הנושאת סיכון פיזי, והיא ראויה לאותה קפדנות שמהנדסי תעופה וחלל ומכשירי רפואה מיישמים על חומרה. AMLAS מציעה אוצר מילים וזרימת עבודה לקפדנות הזו. היא לא תייצר עבורכם אמון באופן אוטומטי, אך היא נותנת לכם דרך ניתנת לשחזור להרוויח אותו. התחילו ביעדי בטיחות כנים. תקפו מול נתונים מלוכלכים ואותנטיים. עקבו אחר המערכת כמו ספק מרגע שהיא עולה לאוויר. המסגרות קיימות. השאר הוא משמעת.
לקבלת הפירוט הטכני המלא של הנחיות AMLAS, קראו את הפרטים המקוריים כאן: https://dev.to/paperium/guidance-on-the-assurance-of-machine-learning-in-autonomous-systems-amlas-f9
אם ברצונכם לדון באסטרטגיות הבטחת איכות ולהחליף הערות מעשיות עם קהילה העובדת על בעיות דומות, הצטרפו לשיחה כאן: https://t.me/GyaanSetuAi