מודל AI לניתוח זרימת הזמנות Order Flow

ניתוח Order Flow: היכן נשברת תמונת הזרימה

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

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

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

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

מה משתנה לאחר הטמעת מודל זרימת ההזמנות

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

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

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

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

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

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

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

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

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

כיצד מתבצעת הטמעת מודל ניתוח הזרימה

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

סדר העבודות

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

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

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

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

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

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

ארטיפקטים של הפרויקט: תרשימים, כללים, נהלים

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

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

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

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

מה היה

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

מה שינינו

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

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

מה נהיה

הדיוק במרווח מחוץ למדגם עלה מ-58% ל-76%, שיעור האותות הכוזבים ירד מ-41% ל-13%. משך החזקת הפוזיציה הממוצע הצטמצם כמעט בחצי — היציאה הפכה למוקדמת יותר ולפי המצב, ולא לפי לוח זמנים. מספר הימים עם תוצאה שלילית פחת בכשליש בקירוב.

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

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

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

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

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

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

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

ספקות טכניים לפני תחילת הפרויקט

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

עד כמה הפיד ההיסטורי צריך להיות שלם?

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

כיצד לוודא שהמודל לא עבר אימון יתר?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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