מערכת בינה מלאכותית לחיזוי זרימת נוסעים בתחבורה

חיזוי זרימת נוסעים: היכן נשבר לוח הזמנים

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

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

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

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

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

נפרק איך זה נסגר.

השפעת המודל: פחות נסיעות ריקות והפרות לוח זמנים

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

דיוק החישוב לפי שעות

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

הוצאת תחבורה לפי הביקוש

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

צמצום נסיעות ריקות

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

תכנון תיקונים ועתודות

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

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

מצב החישוב נבחר לא לפי "עוצמת המודל", אלא לפי אופק החישוב ותדירות עדכון המודל.

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

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

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

יישום: מביקורת נתונים ועד מסירת המודל לתפעול

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

1. ביקורת נתוני נסיעות. מנתחים מקורות מתקופות קודמות: שלמות לפי ימים, כפילויות, פערים בניתוקי תקשורת, הזזות אזורי זמן, אנומליות של חגים ותיקונים. בפלט — רשימת מאפיינים שמישים ורשימת פערים שנסגרים לפני האימון.
2. תרשים זרימת נתונים. קובעים מאיפה ובאיזו תדירות מגיעים עסקאות וטלמטריה, היכן הם מנוקים ומצטברים, ואיך נשמרת ההיסטוריה. התרשים מסמן נקודות כשל ואת הבעלים של כל מקור.
3. התאמת המודל לקו. מביאים בחשבון מרווח נסיעה, סוג יום, עונתיות, חופשות, מזג אוויר ואירועים עירוניים. ההתאמה נעשית לפי כיוונים, ולא בעקומה ממוצעת אחת לכל הרשת.
4. בדיקה על תקופות היסטוריות. אימון ובקרה מופרדים בזמן, אחרת העתיד מרמז על התשובה. בודקים שגיאה באופק של יום ושבוע — בנפרד בשעות שיא ובהפרות לוח זמנים.
5. מסירת המודל לתפעול. החישוב נפרס במעגל של הלקוח, נקשר לנוהל עדכונים, ומפעילים התראות על ירידת דיוק וסחיפת נתוני קלט.
6. נוהל תמיכה. מוסרים לצוות הלקוח סדר אימון מחדש לאחר שינוי ברשת הקווים וניתוח פערים בין התחזית למציאות.

כך התחזית מפסיקה להיות ניסוי והופכת לשירות שהצוות של הלקוח מנהל בעצמו.

מה נשאר אצל הלקוח: תצורות, תרשימים, נהלים

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

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

מקרה בוחן: איך עלה הדיוק ופחתו הנסיעות הריקות

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

מה הראה המדד לפני היישום

בקווי שיא הפער מהמציאות הגיע ל-20-25%: בבוקר הוציאו כלי רכב מיותרים בשכונות מגורים, ובצמתי החלפה חסר קיבולת. שיעור הנסיעות המבוטלות נשאר סביב 6%, והכנת לוח הזמנים ארכה חמישה ימי עבודה — תיקונים לפי מזג אוויר ואירועים כבר לא נכנסו אליו.

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

הפער בקווי הבקרה ירד ל-7-9%, הביטולים — ל-2%, והנסיעות הריקות בשעות השפל הצטמצמו כמעט פי שלושה. לוח הזמנים נבנה ב-3-4 שעות ומחושב מחדש כשמזג האוויר משתנה או כשקטעים נסגרים.

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

מה לעשות אם רישום לפי מכשירי תיקוף כבר מתבצע בכוחות עצמכם

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

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

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

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

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

ספקות לגבי נתונים, דיוק ותמיכה במודל

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

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

מי תומך במודל אחרי ההפעלה?

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

עד כמה ההמלצות ניתנות להסבר?

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

נדון במשימה: נתאים מצב חישוב לצי שלכם

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

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

מה מבררים בהתחלה ובאיזו צורה נחזור:

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

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

תארו את משימת החישוב — רשת הקווים, הנתונים הזמינים ואופק התחזית. נחזור עם הערכה ותוכנית יישום.