בניתי בינה מלאכותית לנצח את הפותר בהתאוששות צוותי תעופה. היא הפסידה, וההפסד הפך למוצר.
הבנצ'מרק שבניתי כדי לנצח, והפסדתי
בניתי את הגרסה הראשונה של StormCrew כדי לנצח את הפותר. זו הייתה כל ההצעה בראש שלי. בקרת תפעול של חברות תעופה רצה על מנועי אופטימיזציה בני עשרות שנים, אז אם אוכל לאמן משהו חכם יותר, יהיה לי סיפור ששווה לספר. השקעתי בזה שבועות. ואז השוויתי את מנוע ההתאוששות שלי מול CBC, פותר מספרים שלמים מעורבים בקוד פתוח בוגר שעמד במבחן שטח מאז לפני שידעתי לכתוב לולאת for, ו-CBC ניצח. לא בשגיאת עיגול.
אני זוכר שהבטתי בשתי עמודות המספרים והרגשתי את החלל הספציפי הזה שמרגישים כשהניסוי שתכננתם כדי להוכיח שאתם צודקים מוכיח במקום זאת שאתם טועים. הפותר היה מהיר יותר. התוכניות שלו היו זולות יותר. הוא מעולם לא החזיר לוח זמנים בלתי ישים. הגרסה החכמה שלי הפסידה בשלושתם.
אז עשיתי את הדבר היחיד הכנה שיכולתי לחשוב עליו. שיניתי את הטענה, לא את המספרים.
בניתי את הבינה המלאכותית כדי לנצח את הפותר. הפותר ניצח. החלק המעניין התברר ככל מה שהמאבק הזה הסתיר.
ההיפוך הזה הוא עמוד השדרה של מה ש-StormCrew באמת הפך להיות, ואני חושב שזה הסיפור השימושי יותר מזה שיצאתי לספר. אפשר להריץ את הכל בעצמכם ב-veriprajna.com/he/demos/airline-crew-scheduling-ai, אבל תנו לי לעבור על מה ששינה את דעתי, כי הציר הוא הנקודה.
מה באמת נשבר כשסופה סוגרת תחנה מרכזית?
חזרתי וקראתי את ניתוחי הכשל אחרי ש-CBC השפיל אותי, וכמעט אף אחד מהכישלון לא היה "המתמטיקה הייתה מעט לא אופטימלית." תפעול לא סדיר, מה שהענף מכנה IROPS, עולה לחברות תעופה בערך $60B בשנה (IATA). האסון הקנוני, Southwest בדצמבר 2022, עלה בערך $1.2B, עם כ-16,900 ביטולים ובערך 2 מיליון נוסעים שנתקעו. כשעקבתי אחרי איך הימים האלה באמת מתפרקים, האופטימייזר מעולם לא היה הנבל.
שלושה דברים נשברים במקום זאת. ההתאוששות היא איטית מדי: כשסופה סוגרת תחנה מרכזית, שיבוץ מחדש של שרשרת ההשפעה במורד הזרם הוא עדיין בעיקר המולה ידנית של 4 עד 12 שעות (בנצ'מרק ממקורות, לא מספר שהמצאתי). היא מסוכנת מדי: כל שיבוץ מחדש חייב לכבד FAA Part 117 לתורנות ולמנוחה ואת ה-CBA של האיגוד לכל מוביל, והפרה אחת היא אירוע ציות, לא הערת שוליים. והיא אטומה מדי: שרשרת הטיסות במורד הזרם שאיבדו זה עתה את הצוות שלהן בלתי נראית עד שהטיסות האלה כבר מתבטלות.
זה האחרון הוא מה שהכלים הישנים מפספסים, וזה הדבר הראשון שגרמתי לדמו להראות. הזריקו סופה בתחנה העמוסה ביותר והאפליקציה מדגישה את רדיוס הפגיעה: הטיסות שסוגרו פלוס הטיסות במורד הזרם במרחק קפיצה אחת שמאבדות את הצוות שלהן דרך הסיבוב. בתרחיש המוזרע זה 53 טיסות בסיכון ברחבי הרשת.
מאז כלל ההחזר האוטומטי של ה-DOT (אוקטובר 2024), כל עיכוב מתגלגל של שלוש שעות ומעלה הוא כעת גם מכה כספית אוטומטית. אז עלות האיטיות, אי-החוקיות או העיוורון עלתה בדיוק בזמן שהכלים נשארו זהים. אף אחד משלושת הכישלונות האלה לא מתוקן על ידי פונקציית מטרה טובה יותר. ביצעתי אופטימיזציה לדבר האחד שכבר היה בסדר.
למה הפסקתי לנסות לנצח את CBC והתחלתי להאכיל אותו?
עשיתי שלום עם ההפסד ל-CBC בכך שנתתי לו תפקיד אחר. במקום להתחרות בפותר, עטפתי אותו. הצינור כולו אמיתי, דטרמיניסטי, קוד מוזרע: רשת חברת תעופה סינתטית ומצב צוות, מזרק שיבושים שמחשב את רדיוס הפגיעה לפי נגישות בגרף על פני הסיבוב, מחולל תורנויות, ואז CBC כמנוע שבוחר את התוכנית, ואז השוואת צל מול עשיית כלום, ואז תעודה חתומה.
כשאני מריץ את זה על הסופה המוזרעת, המחולל מייצר 1,762 תורנויות התאוששות חוקיות (52 מהן הצבות מחדש ב-deadhead כדי להזיז צוותים לאן שצריך), פלוס 53 חלופות ביטול, עבור 1,815 עמודות מועמדות בסך הכל. CBC פותר את 1,815 משתנים, 115 אילוצים בעיית חלוקת-קבוצות בעלות מינימלית ל-OPTIMAL ומחזיר תוכנית בכ-0.11 שניות. תוצאה בתרחיש הזה: 52 מתוך 53 טיסות שובצו מחדש (98 אחוז), ביטול אחד, 34 צוותים בשימוש (25 קו ו-9 עתודה).
הבעיה של חברת התעופה מעולם לא הייתה שהפותר חלש מדי. היא הייתה שההתאוששות הייתה איטית מדי, מסוכנת מדי, ובלתי נראית עד שכבר היה מאוחר מדי.
שימו לב לכנות של צילום המסך הזה. מנוע ההתאוששות הוא CBC, ששמו מופיע בפאנל. הטענה העמידה אינה שהקוד שלי מבצע אופטימיזציה טובה יותר מפותר. היא שהתוכנית מגיעה הרבה מתחת לשנייה במקום שבו התהליך הידני המתועד לוקח 4 עד 12 שעות, והאפליקציה מודדת את הפער הזה בגלוי. אני רוצה להיות מדויק לגבי ההיקף, כי זה דמו ואני מסרב להלבין אותו ליותר ממה שהוא: המספרים המדויקים האלה הם תוצאות של רשת סינתטית מוזרעת אחת, לא הבטחה לעולם פתוח. טענת מהירות-מול-ידני היא זו ששורדת.
ערבות החוקיות שייכת לקוד, לא לשיפוט של מודל
יש לי דעה חזקה שהרווחתי רק בכך שבניתי את זה, אז תנו לי לנסח אותה בבהירות. ערבות חוקיות לא יכולה לחיות בשיפוט של מודל. היא חייבת לחיות בקוד דטרמיניסטי, לפי בנייה. הדרך למנוע שתורנות צוות בלתי חוקית תומלץ אי פעם אינה לאמן מודל להימנע ממנה, וגם לא להוסיף מונח עונש לפונקציית המטרה ולקוות שהאופטימייזר יעקוף אותה. היא להפוך את התורנות הבלתי חוקית לבלתי אפשרית לייצור מלכתחילה.
אז האילוצים נאכפים בזמן הייצור, לא מקבלים ציון אחר כך. Part 117 מגביל תקופת תורנות ל-780 דקות, זמן טיסה ל-480 דקות, ודורש זמן sit מינימלי של 30 דקות; ה-CBA לדוגמה מגביל תורנות ל-4 מקטעים. רק תורנויות שמקיימות את כולן הופכות אי פעם לעמודות מועמדות. זהו מיסוך פעולות. שיבוץ בלתי חוקי אינו נענש, הוא בלתי ייצוגי. מה ש-CBC עושה עם העמודות שהוא מקבל, ומה שהקופיילוט האופציונלי אומר אחר כך על התוכנית, אף אחד מהם לא יכול להחזיר לחיים תורנות בלתי חוקית, כי היא מעולם לא הייתה בקבוצה.
זה נותן לי אינווריאנט במקום ציון: 0 שיבוצים בלתי חוקיים, לעולם, נבדקים ביחידות (ערכת הבדיקות עוברת 3/3, בודקת שרדיוס הפגיעה אינו ריק, שרק עמודות חוקיות נוצרות, ושהתוכנית המשוחזרת היא חלוקה חוקית). ציון אפשר לרגרס. אינווריאנט אפשר להבטיח.
זו גם הסיבה שאני כבר לא מוצא הצעות של "תפעול בינה מלאכותית אוטונומי" משכנעות כשסיפור הבטיחות הוא "המודל למד לא לעשות." סמכתי על מודל לכבד כלל קשיח בדיוק פעם אחת במהלך הבנייה הזו, מוקדם, וזה היה בסדר עד לקלט האחד שבו זה לא היה. בתחום שבו הפרה אחת היא אירוע רגולטורי, "בדרך כלל חוקי" זהה ל-"לא חוקי." אני מעדיף למחוק את האפשרות מאשר לפקח עליה.
מה קורה ביום הגרוע ביותר בשנה?
כמעט שחררתי גרסה שהייתה מאשרת אוטומטית הכל, ואני שמח שתרחיש עצר אותי. העבירו את הדמו למצב חמור, שבו האירוע גרוע מספיק שעתודות מתרוקנות ורק כ-30 אחוז מהצוותים נשארים. CBC עדיין מוצא תוכנית חוקית לחלוטין, בכ-0.05 שניות, עדיין 0 בלתי חוקי. אבל התוכנית הזו הייתה מבטלת 20 מתוך 53 טיסות, שזה 38 אחוז מהרדיוס, הרבה מעל סף האישור האוטומטי של 15 אחוז של ה-OCC.
המהלך הנכון שם אינו לחתום בשקט על תוכנית שמבטלת יותר משליש מהרשת המושפעת. אז הסטטוס מתהפך ל-ESCALATE, נדרש אישור אנושי, עם הסיבה מוצגת. התוכנית עדיין מחושבת, עדיין חוקית, עדיין מוצגת לבקר (33 טיסות שוחזרו, 62 אחוז מהרדיוס). היא פשוט אינה מאושרת אוטומטית.
החלק שרוב הצעות ה"אוטונומיות" מדלגות עליו הוא לדעת מתי הפעולה הנכונה היא לא לפעול, ולהעביר את היום לאדם.
בניית השער הזה שינתה איך אני מרגיש לגבי כל הקטגוריה. הסלמה אינה כשל של המערכת. היא המערכת כשהיא כנה לגבי יום רע. יועץ שתמיד מחזיר תשובה בטוחה קל להדגים ומסוכן לבטוח בו. זה שלפעמים אומר "זה מעל הקו שלכם, אתם מחליטים" הוא זה שהייתי באמת שם ליד בקר ב-3 לפנות בוקר.
הארטיפקט שהייתי רוצה אילו הייתי הבקר
המשכתי לשאול את עצמי מה בקר תפעול היה צריך בבוקר שאחרי, והתשובה לא הייתה לוח בקרה, אלא רשומה. אז כל התאוששות נחתמת ל-recovery_plan.json חתום: השיבוש, התוכנית שנבחרה פעולה אחר פעולה עם צוות וטיסה, סעיף Part 117 ו-CBA הספציפי שנבדק לכל פעולה מול התקרה שלה, שעון הקיר של ההתאוששות, ונתוני החיסכון. זהו רשומת הביקורת של ה-OCC של למה ההתאוששות הזו הומלצה, לייצוא בלחיצה אחת.
יש גם תוכנית קופיילוט אופציונלית, ואני רוצה להיות ברור לגבי איפה הוא יושב. זהו מתאם דק ל-LLM (ברירת מחדל Claude, ניתן להחלפת ספק, או גשר מקומי ללא מפתח) שמסביר את התוכנית באנגלית פשוטה. הוא נמנע לחלוטין ללא מפתח, כל השאר רץ אופליין וללא מפתח, והוא חי מחוץ לליבת ההחלטה. המיסוך הדטרמיניסטי, CBC ושער ההסלמה מחליטים. המודל רק מספר אחרי מעשה. שמתי אותו שם במכוון, כי ברגע שמודל השפה משפיע על השאלה אם תורנות חוקית, איבדתי את הערבות שהשקעתי את כל הבנייה בהשגתה.
לגבי החיסכון, אותה משמעת חלה. בתרחיש הרגיל השוואת הצל מראה 52 ביטולים שנמנעו ובערך $2.37M של חשיפת החזר DOT שנמנעה (מודל של $300 לנוסע) מול עשיית כלום. זו המסגרת המחמיאה ביותר האפשרית, כי קו הבסיס הוא להשאיר תקוע את כל רדיוס הפגיעה, והיא מסומנת כאילוסטרטיבית של אותו תרחיש אחד. זה לא כותרת, ובטח לא הוכחה שהקוד שלי מבצע אופטימיזציה טובה יותר מכל דבר. הפסדתי את הטיעון הזה ל-CBC ביום הראשון. אני לא הולך לנצח אותו בשקט בחזרה במספר שיווקי.
אז מה באמת אומר "להרחיב, לא להחליף"?
נהגתי לחשוב שהרחבה היא הבחירה הביישנית, הדבר שאומרים כשלא מצליחים לבנות את הדבר הנועז. עכשיו אני חושב את ההפך. הקונה כאן כבר מחזיק בערימת פותרים טובה, Jeppesen או IBS, ואינו יכול לסבול קריעה-והחלפה, נעילה, או המלצה בלתי מוסברת ביום הגרוע ביותר בשנה שלהם. לומר לקונה הזה "זרקו את זה עבור המודל החכם יותר שלי" אינו נועז, זו טענה שכבר הפרכתי לעצמי בבנצ'מרק.
מה שאני יכול להציע בכנות הוא השכבה התפעולית סביב הפותר שהם כבר סומכים עליו. להפוך את השרשרת לנראית לפני שהיא נושכת. להפוך מהלכים בלתי חוקיים לבלתי אפשריים לייצור במקום רק לא מומלצים. לקרוס שעות לשניות. ולדעת מתי היום גרוע מספיק שהתשובה הנכונה היא להסלים, לא לאשר אוטומטית. הכל בדמו סינתטי ומוזרע, הרשת, הצוותים, השיבוש, מספרי הדולרים, אין נתוני חברת תעופה אמיתיים בשום מקום בו. מה שאמיתי הוא המנגנון, ואפשר לצפות בו רץ מקצה לקצה ב-veriprajna.com/he/demos/airline-crew-scheduling-ai.
ואם תעדיפו לראות מאשר לקרוא אותי מתאר, הנה הכל רץ מקצה לקצה.
הנה השאלה שלא הפסקתי להפוך מאז ש-CBC ניצח אותי. כשהפותר שאתם מתחרים בו כבר טוב, והקונה כבר מחזיק בו, מה שנשאר לבנות אינו תשובה טובה יותר. זה יחס טוב יותר לתשובה: מהיר יותר, חוקי בהוכחה, נראה, וצנוע מספיק כדי להסלים. אז כמה מהבינה המלאכותית שמוכרים לכם השנה באמת פותרת את החלק הקשה, וכמה פותרת מחדש את החלק שמעולם לא היה שבור?
