AutoKeras: איפה בחירה ידנית של ארכיטקטורה שוברת לוחות זמנים
בחירה ידנית של ארכיטקטורת רשת נוירונים נראית כמו מחקר, אבל בפועל הופכת לצוואר בקבוק בפרויקט. המהנדס בודק קונפיגורציה אחת אחרי השנייה: משנה את מספר השכבות ורוחבן, את אופן חיבור הבלוקים, מריץ מחדש את האימון ומשווה מטריקות על סט הבדיקה המוחזק בצד. מחזור אחד כזה אורך שעות, וכדי להגיע לתוצאה דומה נדרשים עשרות מחזורים.
מחיר ההמתנה נופל על צוות המוצר. בזמן שהחיפוש נמשך, הממשק, האינטגרציות ותרחישי העבודה עם המודל עומדים במקום — לוחות הזמנים של השקת המודל במוצר נדחים לא בימים אלא בשבועות.
גרוע מכך, האיכות תלויה בניסיון של מומחה אחד: האינטואיציה שלו היא שקובעת אילו אפשרויות בכלל ייכנסו לחיפוש, וקונפיגורציות לא טיפוסיות אך מדויקות יותר פשוט לא נבחנות.
המחסור במומחי ML מחריף את האפקט: אותו מהנדס נדרש גם בהכנת הנתונים, גם בניתוח שגיאות וגם בבחירת ארכיטקטורת רשת הנוירונים. תור המשימות גדל, והחיפוש אחר ארכיטקטורה נשאר שלב שכמעט בלתי אפשרי לפצל במקביל בלי לאבד את ההקשר.
AutoKeras סוגר בדיוק את התלות הזו: כיוונון ידני של המודל מוחלף בחיפוש אוטומטי בתוך מרחב אפשרויות מוגדר, שבו קריטריון האיכות הוא מטריקה ולא שיפוט סובייקטיבי. נפרט איך זה בנוי בפרויקט ומה נשאר באחריות המהנדס.
חיפוש ארכיטקטורה אוטומטי: מה משתנה במטריקות של המודל
חיפוש ארכיטקטורה ב-AutoKeras אינו הרצה של מודל אחד, אלא חיפוש מנוהל: מספר הבלוקים וסוגם, רוחב השכבות, פונקציות אקטיבציה, אסטרטגיות רגולריזציה וקצב הלמידה נבדקים בתוך תקציב זמן מוגדר.
בפלט מתקבלת לא רשת אחת אלא רשימה מדורגת של קונפיגורציות עם מטריקות על הוולידציה, שמתוכה בוחרים לפי מדידה ולא לפי אינטואיציה.
האפקט הראשון — קיצור מחזור החיפוש. חיפוש ידני בדרך כלל נתקע על 8–12 אפשרויות: יותר מזה המהנדס פשוט לא מספיק פיזית. חיפוש אוטומטי באותו פרק זמן בודק עשרות ומאות צירופים על אותן חלוקות נתונים — מחזור אימון המודל מתכווץ משבועות לימים, וההחלטה נשענת על השוואה ולא על הרגל.
השני — איכות המודל על נתונים חדשים. אנחנו בוחרים לא את המטריקה הטובה ביותר על הוולידציה, אלא את הקונפיגורציה עם הפיזור המינימלי בין הפולדים של הקרוס-ולידציה: כזו ששורדת החלפת עונה ועדכון של המדגם.
לשם כך אנחנו מקבעים את ה-seed של המחולל, את סדר הפרה-פרוססינג ואת גרסאות התלויות — יכולת השחזור של הניסויים הופכת לתכונה של התהליך ולא למזל של הרצה מסוימת.
השלישי — הפחתת העומס מצוות. המהנדסים מפסיקים להריץ ידנית וריאנטים שגרתיים ועוסקים במה שפותר את הבעיה: תיוג, פיצ'רים, ניתוח שגיאות. הרשימה המדורגת של הקונפיגורציות ויומן החיפוש נשארים בפרויקט — האיטרציה הבאה מתחילה מהמדידות שנצברו ולא מאפס.
מצבי חיפוש ארכיטקטורה: השוואת גישות
חיפוש ארכיטקטורה אוטומטי הוא תמיד פשרה בין איכות המודל לתקציב החישוב. ככל שמרחב החיפוש רחב יותר, כך עולה הסיכוי להיתקל בקונפיגורציה מוצלחת, אבל החיפוש נמשך זמן רב יותר, וקשה יותר לשחזר את התוצאה לאחר מכן. לכן המצב נבחר בהתאם למשימה, ולא «כברירת מחדל — החזק ביותר».
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| חיפוש אוטומטי מלא | יש מספיק נתונים, אין השערות לגבי סוג המודל | החיפוש נמשך שעות וימים; התוצאה רגישה לתיוג ולאיכות המדגם |
| הגבלת מרחב החיפוש | יש הבנה של סוג המשימה ומשפחות המודלים המותרות | יחד עם הגבולות נפסלות גם אפשרויות מוצלחות שלא נכנסו לתוכם |
| תבנית קבועה עם כיוונון עדין של מודל מוכן | מעט נתונים, לוחות זמנים קשיחים, נדרשת צפיות | תקרת האיכות נקבעת מראש על ידי המודל הנבחר ואינה עולה |
בפועל AutoKeras מכסה את שני המצבים הראשונים: מבצע חיפוש בין האפשרויות בתוך מרחב מוגדר ועוצר עם מיצוי תקציב החישוב. את המצב השלישי אנחנו מחזיקים כקו בסיס — איתו אנחנו משווים כל מה שהחיפוש מצא, כדי שההסתבכות של הארכיטקטורה תצדיק את עצמה ולא רק תאריך את זמן האימון. פרמטרי ההרצה והאקראיות מקובעים, אחרת הרצה חוזרת נותנת תוצאה אחרת והשוואת גישות הופכת לחסרת משמעות.
הטמעת AutoKeras: שלבי העבודה ההנדסית
חיפוש ארכיטקטורה אוטומטי אינו «להריץ חיפוש ולקחת את המודל הטוב ביותר». הוא משתלם כאשר הנתונים ומטריקת איכות המודל מוגדרים עוד לפני ההתחלה: אחרת AutoKeras מייעל קריטריון לא נכון, והתוצאה הטובה ביותר לפי ההערכה הפנימית אינה מאושרת על נתונים חדשים. לכן את הטמעת החיפוש האוטומטי אנחנו עוברים שלב-שלב.
סדר השלבים
- אודיט נתונים: נפח ותיוג, חוסר איזון בין מחלקות, כפילויות, דליפות בין חלקי המדגם, זמינות הפיצ'רים ברגע החיזוי. לדלג על השלב הזה פירושו לאמן את החיפוש על נתונים שלא יהיו בעבודה בפועל.
- מטריקת איכות המודל: מטריקה עיקרית אחת וסף קבלה לעבודה. עבור משימות לא מאוזנות זו אינה שיעור התשובות הנכונות אלא recall על המחלקה המטרה.
- סכמת החיפוש: מרחב הארכיטקטורות, טווחי הפרמטרים, מגבלת זמן וכלל עצירה מוקדמת, כדי שהחיפוש לא יתנהל בעיוורון.
- כיוונון AutoKeras: קונפיגורציית החיפוש, יומן של כל ניסיון ותוצאתו, קיבוע האקראיות — התוצאה הופכת לניתנת לשחזור.
- בדיקה על סט מוחזק בצד: את המודל שנבחר לפי הוולידציה מריצים על נתונים שלא השתתפו לא באימון ולא בבחירת הארכיטקטורה.
- השוואה לנקודת ייחוס ומסירה: מדידה מול מודל פשוט או היוריסטיקה קיימת, ולאחר מכן קונפיגורציות, תקנון אימון מחדש והדרכת צוות הלקוח.
כל שלב נסגר בארטיפקט שניתן לבדוק מחדש — ולכן החיפוש חוזר על עצמו גם בלעדינו.
ארטיפקטים של ההטמעה: קונפיגורציות, סכמות, תקנונים
ההטמעה אינה מסתיימת בהדגמה של מודל מאומן, אלא במסירה לצוות הלקוח של סט ארטיפקטים שלפיהם הפתרון ממשיך לחיות בלעדינו. מודל בלי קונפיגורציית חיפוש ובלי תקנון אימון מחדש מדרדר בתוך חודשיים — ואין במה לחזור על הרצה מוצלחת. לכן הקבלה כוללת לא רק אב-טיפוס עובד אלא גם את כל מה שמתאר את השחזור שלו.
- קונפיגורציית חיפוש הארכיטקטורה — קבצים עם מרחב האפשרויות: אילו סוגי שכבות וטווחי היפרפרמטרים AutoKeras מחפש, כמה ניסיונות מוקצים למודל, לפי איזה קריטריון נבחרת ההרכבה הטובה ביותר וכיצד מקובע ה-seed לשם חזרתיות.
- סכמת צינור האימון — מאיפה מגיעים הנתונים, היכן מתבצעים התיוג והוולידציה, כיצד נוצרים מדגם האימון ומדגם הבדיקה, ובאיזה שלב נשמר ארטיפקט המודל.
- כללי גישה לנתונים — אילו חשבונות שירות קוראים את הדאטהסט, היכן נשמרים המפתחות, מי מקבל גישה לתוצאות האימון ולתצורות של פיצ'רים ביניים.
- תקנון אימון מחדש — סף הדרדרות המטריקה והסימן להזזה של הנתונים שבהם מופעל מחזור חדש, האחראי על ההפעלה, משך המחזור ובדיקה שהגרסה החדשה אינה גרועה מהקודמת.
- תיעוד הפתרון — תיאור הקלטים והפלטים של המודל, מגבלות לפי סוגי נתונים, נקודות תורפה ידועות והוראות הרצה בסביבה נקייה.
- תיאור תשתיתי — דרישות לסביבה, רשימת התלויות, סכמת הפריסה ונוהל החזרה לגרסה הקודמת של המודל.
- צ'קליסט קבלה — סט בדיקות ומטריקות שלפיהם הצוות שלכם בודק בעצמו כל גרסה חדשה לפני העלאה לפרודקשן.
כל סעיף מתואם עם המהנדסים שלכם לפני המסירה: אנחנו עוברים על הקונפיגורציה והתקנון יחד עם מי שליווה אותם.
מקרה בוחן: איך קיצרנו את מחזור בחירת המודל משבועות לשעות
המשימה הייתה טיפוסית: חיזוי נטישה על נתונים טבלאיים עם פיצ'רים הטרוגניים. שני מהנדסים חיפשו ארכיטקטורות ידנית — כ-50 קונפיגורציות בשלושה שבועות, ובד בבד האיכות על הסט המוחזק בצד «רחפה» מהרצה להרצה, והתוצאה הטובה ביותר לא שוחזרה בהרצה חוזרת.
קיבענו את הליך החיפוש: מרחב הארכיטקטורות והשכבות, תקציב זמן לניסוי בודד, מטריקת בחירה אחידה ואותה סכמת קרוס-ולידציה לכל המועמדים. את החיפוש עצמו העברנו ל-AutoKeras — הוא בונה ומאמן את הווריאנטים אוטומטית ועוצר כאשר קונפיגורציות חדשות מפסיקות לשפר את מטריקת המטרה.
לפני: שלושה שבועות עבודה, ~50 קונפיגורציות ידניות, פיזור איכות על הסט המוחזק בצד של 5–7 נקודות, וחזרה למודל הקודם חייבה הרכבה מחדש ביד.
אחרי: 180+ קונפיגורציות במשמרת עבודה אחת, בחירת המודל הטוב ביותר לפי המטריקה על הסט המוחזק בצד, הפיזור בין הרצות חוזרות הצטמצם ל-1–2 נקודות, ושיעור השגיאות ירד בכ-12%.
אצל המהנדסים נשאר מה שהחיפוש האוטומטי לא מחליף: הגדרת המטריקה, בדיקת דליפות של פיצ'רים בין מדגם האימון לסט המוחזק בצד, פרשנות התוצאה והעברת הארכיטקטורה הנבחרת לקונטור הפרודקשן. בדיוק הצעדים האלה הופכים את החיפוש לתוצאה ניתנת לשחזור שאפשר להגן עליה בפני הלקוח.
במה נבדל חיפוש ארכיטקטורה אוטומטי מכיוונון ידני
החיפוש האוטומטי לא חושב במקום המהנדס: הוא מחפש קונפיגורציות בתוך מרחב שהוגדר מראש ומשווה ביניהן לפי המטריקה על הסט המוחזק בצד. הכיוונון הידני יוצא מהשערות על הנתונים — חוסר איזון בין מחלקות, אופי האות, דלילות הפיצ'רים. זה לא «חכם מול ידני», אלא חיפוש מול צמצום מומחה של מרחב החיפוש.
החיפוש האוטומטי מנצח במקום שבו יש הרבה וריאנטים וצריך לעבור עליהם מהר: מספר הבלוקים וגודלם, סדר השכבות, קצב הלמידה, רגולריזציה. AutoKeras בונה ומעריך עשרות ארכיטקטורות בלילה אחד ומנהל יומן ניסיונות — התוצאה ניתנת לשחזור.
הוא מפסיד בגבולות. במדגם נתונים קטן החיפוש עובר אובר-פיטינג על הוולידציה, ומטריקה שהוגדרה פורמלית מעודדת התנהגות של המודל שלא נדרשת למוצר. כאשר נדרשת עיבוד לא סטנדרטי או זמן תגובה קשיח — מרחב החיפוש לא מתאר את הפעולה הזו, והאפשרות הטובה ביותר שנמצאה נחותה מזו שהורכבה ידנית.
תפקיד המהנדס לא נעלם אלא מתעד: הוא מגדיר את מרחב החיפוש ואת התקציב, בוחר את המטריקה ואת סכמת הוולידציה, עוקב אחרי דליפות בין המדגמים, ומגביל את האפשרויות לפי זיכרון וזמן תגובה. אחרת החיפוש ימצא בשקדנות אופטימום של מטרה לא נכונה.
הפרשנות נשארת בידי האדם: היומן מראה אילו קונפיגורציות ניצחו, אבל לא מסביר למה. ניתוח התרומה של הפיצ'רים והרצות ביקורת בלי בלוקים חשודים מראים שהמודל למד דפוס אמיתי ולא ארטיפקט תיוג.
הסכמה העובדת — חיפוש אוטומטי כמעבר ראשון על מרחב רחב, ולאחר מכן ליטוש ידני של המועמד וחיפוש חוזר במרחב מצומצם.
ספקות טכניים: מגבלות, נתונים, בקרת איכות
ספקות בנוגע לנתונים, לאובר-פיטינג ולשחזור אנחנו בודקים לפני תחילת העבודה — אחרת חיפוש ארכיטקטורה אוטומטי ב-AutoKeras הופך ללוטו. להלן תשובות לארבע שאלות שלרוב קובעות את פורמט הפרויקט.
כמה נתונים דרושים כדי שחיפוש הארכיטקטורה יניב תוצאה?
את הנפח קובע לא הספרייה אלא סוג המשימה: עבור נתונים טבלאיים עובדות כמה אלפי שורות עם פיצ'רים מפורשים, ועבור תמונות — מאות דוגמאות למחלקה בהעברת למידה.
בשלב המחקר אנחנו מחשבים את האיכות על 60, 80 ו-100% מהמדגם ומראים את נקודת היציאה לרמה — שם רואים היכן נתונים חדשים כבר לא מוסיפים דיוק, ואת תקציב האיסוף אין צורך לנפח.
איך אתם שולטים באובר-פיטינג של המודל?
החיפוש נעשה על סט מוחזק בצד עם חלוקה סטרטיפיקטיבית, ולא על מדגם האימון. כל ארכיטקטורה נעצרת כאשר המטריקה על הוולידציה הפסיקה לעלות כמה אפוקים ברציפות, ואת התוצאה אנחנו משווים למודל בסיס פשוט: אם החיפוש לא מנצח אותו בפער, לפרודקשן נכנס המודל הבסיסי.
האם התוצאה תחזור על עצמה בעוד חצי שנה?
כן. אנחנו מקבעים את ה-seeds של מחולל המספרים האקראיים, מניפסט של הסביבה ויומן חיפוש עם הפרמטרים של כל ארכיטקטורה שנבדקה. הרצה חוזרת על אותו סט נתונים מניבה את אותה שלישיית המודלים המובילה, והפער במטריקה — שברי אחוזים.
איך המודל ייכנס לקונטור הסגור של הלקוח?
את המודל הטוב ביותר אנחנו מייצאים לפורמט שנקרא על ידי רנטיים סטנדרטי בלי ספריית החיפוש האוטומטי — היא נדרשת רק בשלב החיפוש.
אימון אנחנו יכולים לערוך אצלנו, ואת ההסקה להשאיר בתוך הקונטור בלי רשת חיצונית; את התלויות אנחנו מוסרים כמראה מקומית של חבילות, כדי שהפריסה לא תדרוש גישה החוצה.
נדון במשימה: אילו נתונים דרושים להערכת הפתרון
כדי לחזור עם הערכת היקף העבודה ולא עם שיקולים כלליים, אנחנו צריכים פרוסה של המשימה — לא תצוגה מלאה ולא גישה לקונטור העבודה. מספיק קטע נתונים אנונימי, תיאור של השדות והבנה איזו תשובה נחשבת נכונה.
AutoKeras בוחר ארכיטקטורה והגדרות בדיוק על הקטע הזה, ולכן איכות הפרוסה משפיעה ישירות על דיוק ההערכה ועל מספר השלבים שההטמעה תדרוש.
מה לשלוח לפני השיחה הראשונה:
- קטע נתונים אנונימי — כמה מאות רשומות, כולל מקרים מורכבים ומקרי גבול;
- תיאור השדות והסוגים שלהם: מספרים, קטגוריות, טקסט, תמונות, סדרות עתיות;
- מטריקת המטרה והערך הנוכחי שלה — איתו נשווה את תוצאת המודל;
- כיצד המשימה נפתרת כרגע: ידנית, לפי כללים, בכלי אחר;
- היכן המודל יעבוד לאחר ההשקה ומי משתמש בתשובות שלו;
- מגבלות על זמן התגובה ועל נפח הנתונים שצריך לעבד;
- כיצד נבדקת התוצאה: מי ולפי איזה קריטריון מקבל או דוחה תשובה.
בשיחה אנחנו מסכמים על תוכנית שלבים: הכנת נתונים, חיפוש ארכיטקטורה, בדיקה על סט מוחזק בצד, העברה לקונטור העבודה ומסירת המודל לצוות הלקוח. תארו את המשימה ושלחו את מה שיש — נחזור עם הערכת היקף העבודה ותוכנית הטמעה.







