האם אופטימיזציה היברידית המשלבת בין SGD ל-AdaHessian היא הפתרון האידיאלי או אולי אשליית ביצועים?

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

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

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

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

3. מגבלות הקירוב האלכסוני בעמקים צרים אחת המטרות הייתה חילוץ מבעיות Ill-Conditioned, אך עמקים צרים נוצרים לרוב בגלל תלות וקורלציה כבדה בין פרמטרים שונים ברשת. AdaHessian מבוסס על קירוב אלכסון שמתעלם לחלוטין מהאינטראקציות החוצות. לכן, הוא אינו מסוגל לתקן את הגיאומטריה המורכבת הזו באמת. הפתרון האמיתי לבעיות אלו מצוי באלגוריתמים ממשפחת SOAP או Shampoo שמפרקים טנזורים ושומרים על קורלציות.

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

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

ה-State-of-the-Art הנוכחי מסביר ומדגים שמיתוג קשיח אינו הדרך. העתיד נמצא בשילובים רציפים, הרמוניים והשהייתיים. אלגוריתמים מתקדמים כגון Sophia מציעים אומדן אלכסוני מושהה וחסכוני במשאבים, בעוד ש-SOAP מחדיר אופטימיזציה מסדר ראשון ישירות אל תוך הבסיס העצמי מבלי לקטוע את התהליך.

שתפו אותי בתגובות - האם נתקלתם בהלם אופטימיזציה באימון המודלים שלכם? באילו אופטימיזטורים אתם בוחרים כיום למשימות כבדות?

האם אופטימיזציה היברידית המשלבת בין SGD ל-AdaHessian היא הפתרון האידיאלי או אולי אשליית ביצועים?

יש לכם תהליכים אלגוריתמים שדורשים האצה? לא יודעים איך לעשות את זה? צריכים עזרה במחקר אלגוריתמי יישומי? צריכים מי שיבין בזריזות מה יעבוד ומתי ומה לא יעבוד ומדוע? אנחנו ב-Mathematic.ai הכתובת! דברו איתי:

שלמה יונה

מייסד ומדען ראשי, מתמטיקאי מחקר ופיתוח בע"מ

053-7326360

shlomo.yona@mathematic.ai 

https://mathematic.ai

פודקאסט על החברה ועליי, שלמה יונה, ואופן העבודה שלנו ואיתנו: A technical deep dive about Mathematic.ai