איך לשפר מחזור פיתוח אלגוריתמים בארגון עם סוכן AI שמפחית ניסויים יקרים

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

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

איך משפרים מחזור פיתוח אלגוריתמים בארגון עם סוכן AI

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

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

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

מה שונה כאן לעומת AutoML ואופטימיזציה שחורה

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

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

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

איפה זה פוגש תהליכים עסקיים ומדדי ROI

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

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

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

שלושה תרחישי הטמעה שמייצרים ערך מהר

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

צעד ראשון מומלץ להטמעה בארגון

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

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

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