פיתוח בוט ארביטראז' AI מבוסס ML

מדוע בוט ארביטראז' מאבד רווח בתנועות חדות בשוק

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

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: מהירות החלטה ובקרת סיכון

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

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

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

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

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

תרשימי חיבור לבורסות ומצבי ביצוע עסקאות

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

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

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

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

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

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

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

מה מוסרים לידיים: קונפיגורציות, תרשימים, נהלים ודוחות

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

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

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

מקרה בוחן: כיצד צמצמנו הפסד והסרנו התערבויות ידניות

לפני ההטמעה, ארביטראז' בין שתי זירות מסחר נשען על אישור ידני: המפעיל ראה פער מחירים, בדק מגבלות והציב הזמנות בעצמו. התגובה ארכה 6-8 שניות — בזמן הזה את הפער סגרו הזמנות של אחרים, או שהוא עבר לשלילי. במשמרת הצטברו 40-60 פעולות ידניות, וההפסד בקטע ארוך הגיע עד 18%.

מה שינינו

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

• זמן תגובה: מ-6-8 שניות להחלטת מפעיל עד עשיריות השנייה.
• שיעור ההזמנות שבוצעו: 71% → 96%, את השאר חותכים מסננים לפי עומק ספר ההזמנות.
• התערבויות ידניות: 40-60 במשמרת → 1-2, רק טיפול במצבים חריגים.
• תדירות כשלים: כמה אירועים בשבוע → אחד בחודש, וגם הוא בצד הזירה.
• הפסד: מ-18% ל-6-7% בקטע דומה.

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

במה נבדל מודל מכונה מחוקים נוקשים בבוט ארביטראז'

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

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

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

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

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

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

ספקות טכניים: אמינות, סיכון ותמיכה במערכת

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

כיצד מוגנים מפתחות המסחר?

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

מה לעשות אם האסטרטגיה תפסיק לעבוד?

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

מי אחראי לכשלים לאחר ההפעלה?

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

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

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

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

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

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