מדוע בוט HFT מאבד תוצאות בעומס שיא
בוט HFT לא "נשבר" כולו — הוא מאבד תוצאה בהדרגה ככל שהעומס גדל. כל עוד זרם הציטוטים מתון, השהיית התגובה של הבוט נשמרת בטווחים הרגילים, ומודל ביצוע הפקודות תואם את החישוב.
בעומס שיא בזירה — פרסום נתונים סטטיסטיים, מכרז פתיחה, מפל הפעלות של פקודות סטופ — הזמן בין האות להצבת הפקודה גדל פי כמה, והאסטרטגיה מתחילה לפעול לפי תמונת שוק מיושנת.
נקודת כשל שנייה — החלקה של פקודות. ברגע של תנועה חדה, הצפיפות בספר הפקודות יורדת: המחיר עובר כמה רמות עד שהפקודה מגיעה לזירה, והביצוע מתקבל גרוע מהחישוב.
ככל שתדירות ההחלטות גבוהה יותר, כך גדל הפער בין מחיר הכניסה המודלי למחיר בפועל — הפוזיציה כבר פתוחה, והיתרון הצפוי נאכל על ידי התנועה.
כשל שלישי — ניתוק הקשר ברגע הכי לא מתאים. בתנודתיות שיא, מכסות הזירה על מספר ההודעות מתמלאות מהר יותר מאשר במצב רגוע: הבוט מאבד את זרם הנתונים, העותק המקומי של ספר הפקודות נפרד מזה הבורסאי, ולאחר חיבור מחדש חלק מהפקודות נשארות מחוץ לשליטה. כל דקה כזו — פוזיציות פתוחות ללא ניהול ודחיפה שלילית באסטרטגיה, שאותה אחר כך צריך לשחזר ידנית.
אנחנו מפרקים איך זה נסגר: היכן למדוד השהיה לפי שלבים — מקבלת הציטוט ועד אישור הביצוע, איך להתחבר מחדש בלי לאבד את מצב ספר הפקודות, ואילו מגבלות סיכון עוצרות את הבוט לפני שהפער הופך להפסד.
מה נותן המימוש: מהירות תגובה, כשלים, בקרת סיכון
מודול מסחר נמדד לא לפי מהירות שליחת הפקודה, אלא לפי כמה פקודות מגיעות לעסקה. שיעור הפקודות המבוצעות תלוי בעדכניות העותק המקומי של ספר הפקודות ובטיפול בביצועים חלקיים: אם המצב נפרד מזה הבורסאי, חלק מהפקודות נדחות כבר בזירה. לאחר עיבוד מחדש של התור והשוואת מצב, שיעור הפקודות המבוצעות עלה מ-78% ל-94% על אותו זרם אותות.
הפחתת הדחיפה השלילית נובעת לא מהמהירות כשלעצמה, אלא מהסדר במגבלות הסיכון. כאשר מגבלות על פוזיציה, על הפסד לעסקה ועל הפסד לפי מרווח נבדקות לפני שליחת הפקודה, ולא אחרי תגובת הזירה, המודול מפסיק לרדוף אחרי השוק בסדרה של הפעלות מאוחרות. התנהגות צפויה של המגבלות הסירה קפיצות שבגללן הדחיפה השלילית במרווח הגיעה עד 9%.
סוג נפרד של כשלים — ניתוק הערוץ. בוט HFT מחליף עם הזירה חבילות שירות, בעת ניתוק מתחבר מחדש אוטומטית, מסיר פקודות לא עדכניות ומשווה פוזיציה לפי פרוטוקול FIX. בעבר, לאחר ניתוק, המודול היה יכול לפתוח פוזיציה שנייה על אותו אות — כעת סוג הכשל הזה סגור.
ניטור מודול מסחר נבנה על ארבעה מדדים: זמן תגובה, עומק תור הפקודות, פער בין הפוזיציה המקומית לפוזיציה הבורסאית, מספר פקודות שנדחו. התראה מגיעה לפני שהפער הופך לפוזיציה לא מתוכננת — בקרת הסיכון מפסיקה להיות תגובתית.
מצבי עבודה: אוטונומי, חצי-אוטונומי, ארביטראז'
המצב נקבע לא כל כך לפי האסטרטגיה, אלא לפי הנקודה שבה מתקבלת ההחלטה: מי מציב את הפקודה ברגע הפעלת האות וכמה שלבים נותרו עד לעסקה.
אותו מודול חישובי במסלול אוטונומי ובמסלול חצי-אוטונומי נותן פרופיל סיכון שונה, ולכן אנחנו מקבעים את המצב לפני הפיתוח — אחרת יש לבצע שינויים בלוגיקה שכבר עובדת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מצב מסחר אוטונומי | האסטרטגיה מפורמלת עד לרמת חוקים: כניסה, גודל פוזיציה, סטופ מחושבים לפי ציטוטים ללא מעורבות אדם | שגיאה בלוגיקה משוכפלת באותה מהירות כמו התוצאה; נדרש מעגל בקרה חיצוני, מגבלות נוקשות ועצירה חירום |
| מצב חצי-אוטונומי | האותות מחושבים על ידי המערכת, ההחלטה מאושרת על ידי אדם — או שהבוט מפקח על פוזיציה ידנית | התגובה מוגבלת למהירות המפעיל: חלק מהאותות מוחמצים, הסטטיסטיקה נוטה לתרחישים רגועים יותר |
| ארביטראז' חוצה-זירות | אותו צמד נסחר במספר זירות, והפער במחירים מכסה את עלויות הכניסה והיציאה | דורש גישה מסונכרנת לכמה מקורות ציטוטים ורזרבות בכל זירה; חלון הפער חי זמן קצר |
מה בודקים לפני בחירת המצב
מכנה משותף לכל שלושת המסלולים — מגבלות נזילות. פקודה שבהיסטוריה בוצעה באופן מיידי, בשוק חי מזיזה את המחיר, וחלק מהרווח נאכל על ידי החלקה.
לכן את המודול החישובי מריצים על הקלטת ציטוטים עם עומק ריאלי, ומגבילים את גודל הפוזיציה לחלק ממחזור הזירה, ולא רק לאופטימום המתמטי של האסטרטגיה.
המצב אינו בהכרח קבוע: מסלול טיפוסי — התחלה במסלול חצי-אוטונומי, אישור סטטיסטיקה על נפח מוגבל, ואז מעבר לאוטונומי תוך שמירה על עצירה ידנית. תארו את האסטרטגיה שלכם — נחזור עם הערכה איזה מסלול מתאים לה ואילו מגבלות להטמיע.
שלבי פיתוח: מפירוק האסטרטגיה ועד ההשקה
פיתוח בוט מסחר מתחיל לא בקוד, אלא בפורמליזציה של האסטרטגיה: כל עוד חוק הכניסה והיציאה קיים רק בראש, אי אפשר לבדוק אותו או להגביל אותו לפי סיכון. להלן סדר העבודה, שבו כל שלב נשען על התוצרים של השלב הקודם, ולכן שגיאה בחישוב האות מתגלה בשלבים מוקדמים ולא בחשבון חי.
- פירוק האסטרטגיה. מקבעים את תנאי הכניסה והיציאה, את העבודה עם ביצוע חלקי ואת ההתנהגות ברגעים שבהם זרם הפקודות נשבר.
- תרשים זרימות נתונים. מגדירים מהיכן מגיעים הציטוטים, איך נצברת היסטוריית העסקאות והיכן עובר הגבול בין המודול החישובי לביצוע.
- הרכבת המודול. מטמיעים חישוב אותות, ניהול פקודות ותיעוד — כך שכל החלטה תשאיר עקבות לבדיקה.
- בדיקה על נתונים היסטוריים. מריצים את האסטרטגיה על הזרם שנצבר תוך התחשבות בעמלות ובהחלקה; בודקים לא רק את התוצאה, אלא גם את הדחיפה השלילית.
- הגדרת מגבלות סיכון. קובעים פוזיציה מקסימלית, סטופ יומי, הגבלה על מספר הפקודות ועצירה אוטומטית בעת סטייה מההתנהגות המחושבת.
- הרצת בדיקה על זרם חי. עובדים במצב צפייה ללא ביצוע בפועל, ומשווים את האותות המחושבים לשוק בפועל.
- מסירה וליווי. מוסרים קונפיגורציות, יומנים, תרשים זרימות ונוהל עצירת חירום; בהמשך — תקנון עדכון האסטרטגיה.
מה מוסרים בסיום: קונפיגורציות, לוגיקת סיכון, תקנונים
הפרויקט נסגר לא בהדגמה של בוט HFT עובד, אלא במסירת ערכה שלפיה המהנדסים שלכם יוכלו ללוות אותו ולפרק אירועים בלעדינו. התוצרים יושבים לצד הקוד במערכת בקרת גרסאות ומתעדכנים יחד איתו — אחרת התיעוד מתרחק במהירות מההתנהגות בפועל של המערכת.
- קונפיגורציות של כל המודולים — פרמטרי אסטרטגיה, מגבלות, ספים, זמני המתנה — בקבצים מנוהלי גרסאות, עם הסבר מה משנה כל הגדרה והיכן הטווח התקין שלה.
- תרשים זרימות נתונים ממקור נתוני השוק ועד להצבת הפקודה: נקודות שבהן הודעה יכולה ללכת לאיבוד או להגיע באיחור, ואיך המערכת מזהה זאת.
- לוגיקת בקרת סיכון בשכבות: מגבלה על פוזיציה ועל מכשיר, סטופ לפי תוצאה יומית, הסרה אוטומטית של פקודות ועצירה מלאה של המסחר לפי תנאים מוגדרים.
- תיעוד לכל מודול: ייעוד, כניסות ויציאות, תלויות, התנהגות בעת כשל של צומת שכן.
- יומן אירועים: הרכב הרשומות, רמת הפירוט, תקופת שמירה, סדר שחזור כרונולוגיית האירוע לפי הלוג.
- תקנון בעת תקלה: רצף פעולות התורן, מעבר למסלול גיבוי, חזרה לקונפיגורציה קודמת.
- עמדת בדיקות קבלה על נתונים היסטוריים: סט תרחישים שחייבים לעבור לפני כל עדכון של האסטרטגיה.
הערכה מיועדת לליווי עצמאי: בלי גישה לתשתית שלנו, בלי הסכמות בעל פה ועם סדר אחיד לפירוק כל תקלה. בהמשך את הבוט מפתחת הקבוצה שלכם — או אנחנו, אם תחליטו להשאיר את התמיכה אצלנו.
מקרה בוחן: בוט HFT לשמירה על ציטוטים — מדדים לפני ואחרי
מה היה לפני
הקבוצה שמרה על ציטוטים במספר מכשירים במקביל בשלוש זירות. ליבת המסחר עבדה לפי טיימר: חישוב מחדש של מחירים והצבת פקודות הלכו במחזור אחד, בלי הפרדה בין חישוב לביצוע. בשוק רגוע זה לא הפריע, אבל בתנועות חדות ההחלקה הגיעה ל-18–25 נקודות בסיס, ומספר ההפעלות השגויות — עד 40–60 ביום. לאחר ניתוק החיבור את הבוט היו מרימים ידנית, והשחזור ארך בין 20 ל-40 דקות.
צוואר הבקבוק
חישוב הציטוט ושליחת הפקודות חיו באותו זרם. אם הזירה הגיבה לאט יותר מהחישוב מחדש, תור הפקודות הצטבר, והבוט שלח אותן לפי מחיר שכבר היה מיושן — מכאן ההחלקה והעסקאות המיותרות. לא הייתה הגנה אוטומטית מפני ניתוק: רק ניטור חיצוני שהודיע על נפילה בדיעבד. את הליבה הרכיבו על בסיס Hummingbot, אבל כתבו מחדש את מעגל הביצוע לפי כללי הסיכון שלהם.
מה שינו ואילו מדדים התקבלו
הפרידו בין מעגל החישוב למעגל הביצוע, הוסיפו ספר פקודות מקומי עם חותמת זמן וכללים לביטול פקודה לפי גיל וסטייה ממחיר היעד. ערוץ התקשורת הגיבוי מתחלף אוטומטית, והפוזיציות מועברות ללא התערבות ידנית.
- החלקה: 18–25 → 3–6 נקודות בסיס לעסקה;
- הפעלות שגויות: 40–60 → 2–4 ביום;
- זמן שחזור לאחר ניתוק: 20–40 דקות → 40–90 שניות;
- שיעור הביטולים שהספיקו לעבור לפני הביצוע: 88% → 97%.
כעבור חודש עבודה בפרודקשן הצוות עבר לתורנות לפי חריגות: לא נדרש אפילו אתחול ידני אחד.
מה לעשות אם מודול המסחר כבר עובד בזירה?
מודול מסחר בתדירות גבוהה (HFT) שעובד בזירה — זו לא סיבה לכתוב הכול מחדש. קודם כל צריך פירוק של הלוגיקה הנוכחית: איך נוצרים האותות, היכן מוצבים מפסקי הביטחון לסיכון, מה קורה בעת ניתוק הקשר עם הבורסה ואיך המודול מתנהג בביצוע חלקי של פקודה.
ביקורת לוגיקת המסחר נעשית לפי ההתנהגות בפועל, ולא לפי תיעוד זר.
אנחנו מורידים יומני פקודות ועסקאות לתקופה מייצגת, משווים אותם לאסטרטגיה המוצהרת ומוצאים מקומות שבהם ההחלטה סוטה ממנה: תנאי כניסה מיושנים, עקיפת מגבלות סיכון, טיפול במצבים שחוזרים על עצמם לעתים רחוקות, שאחריהם הפוזיציה נשארת פתוחה יותר מהמתוכנן.
שדרוג של מודול קיים נבנה כך שלא לעצור את המסחר. השינויים מוציאים לשכבות נפרדות — חישוב אות, ביצוע, בקרת פוזיציה — ומופעלים באמצעות מתג מצב. הלוגיקה החדשה עוברת תחילה במקביל על זרם נתונים צל ובהרצות היסטוריות; עד שהתוצאות לא יתאימו למצופה, לשוק יוצאת הענף הקודם.
מסירה לליווי — שלב נפרד, וזה לא רק מסירת קוד מקור. נדרשת מערכת עובדת: תיאור הקונפיגורציה בפועל, תרשים זרימות נתונים, רשימת תרחישי חירום עם סדר פעולות, תקנון עדכונים ונקודת חזרה ברורה לגרסה הקודמת.
בסיום הלקוח מקבל מודול שאפשר לשנות בחלקים, ולא בשלמותו, וצוות שמבין מדוע התקבלה בו החלטה כזו או אחרת. תארו מה כבר עובד בזירה — נחזור עם הערכה ותוכנית.
ספקות טכניים לפני ההתחלה: השהיות, מגבלות, אמינות
לפני ההתחלה בודקים בדרך כלל ארבעה דברים: איך הזירה מגבילה את קצב הבקשות, מה עושה הבוט בעת ניתוק הערוץ, מי אחראי למערכת לאחר השחרור וכמה לא סטנדרטי נראה ממשק המסחר. להלן תשובות קצרות; בכל זירה הן מתבהרות בשלב הגישה למסלול הבדיקות.
איך הבוט חי בתוך מגבלות הזירה?
מגבלת הזירה היא לא רק מספר ההודעות בשנייה, אלא גם מכסות יומיות על ביטולים, הגבלה על מספר הפקודות הפעילות והשהיות ענישה על חריגה מהן. בליבה אנחנו מטמיעים מתזמן משלנו עם משקלות בקשות: כשמתקרבים לסף, חלק מהפקודות יוצאות במקבצים, וביטולים עודפים נבנים מחדש. המגבלה מפסיקה להיות מקור לחסימות אקראיות של החשבון.
מה קורה בעת ניתוק הקשר?
הבוט מנהל יומן מצב מקומי ומסמן כל פקודה במזהה שלפיו שליחה חוזרת לא יוצרת כפילות. לאחר שחזור הערוץ הוא משווה את התמונה שלו לזו הבורסאית, מסיר פקודות יתומות ורק אז חוזר למסחר. תרחיש נפרד — «מצב שטוח» חירום: סגירת פוזיציות ועצירת האסטרטגיה ללא התערבות ידנית.
מה כלול בליווי לאחר ההשקה?
מוסרים קונפיגורציות, תרשים פריסה ותקנון תורנות, ובהמשך מלווים את המערכת לפי חלון תגובה מוסכם: בודקים השהיות ביצוע, שיעור הפקודות שנדחו ופער מול המצב הבורסאי. התראות מגיעות לפני שהסטייה תהפוך להפסד, ושינויי האסטרטגיה עוברים דרך מסלול הבדיקות.
ואם לזירה יש ממשק לא סטנדרטי?
חלק מהזירות, במקום FIX, מספקות פורמט בינארי משלהן או סט מוגבל של קריאות. למקרה כזה כותבים מתאם נפרד ומריצים אותו על הקלטות של תעבורה אמיתית, כולל שגיאות ותשובות חלקיות. החלפת הממשק של הזירה נסגרת אז בתיקון של מודול אחד, ולא בכתיבה מחדש של הלוגיקה.
נדון במשימה: נשלח הערכה, תוכנית והרכב העבודות
הערכה ותוכנית עבודה נבנות מהלוגיקה שלכם למסחר, ולא מתיאור כללי «צריך בוט HFT». פירוק ראשון — שיחה קצרה עם הסוחר או הקוואנט שלכם: מכשירים, אופק החזקת הפוזיציה, כללי כניסה ויציאה, דחיפה שלילית מותרת. בהמשך מתקדמים בשלבים, ובכל שלב ברור מה נדרש מכם ומה אתם מקבלים בסיום.
- הגדרת המשימה, 1–2 ימים. מקבעים כללי כניסה, יציאה ומגבלות סיכון; בסיום — מפרט שאתם מאשרים בכתב.
- נתונים, 2–3 ימים. היסטוריית עסקאות וציטוטים, יומני גרסאות קודמות, תיאור מכשירים. מה שאין — מחשבים לפי הקיים ומסמנים הנחות ישירות בהערכה.
- גישות, במקביל. מסלול בדיקות של הברוקר, מפתחות לקריאה בלבד ולמסחר בארגז חול, חשבון נפרד לבדיקות. מפתחות ייצור לא נתבקש עד לקבלה.
- הערכה ותוכנית, 3–5 ימים. מסמך: שלבים, תוצאה של כל שלב, הרכב הצוות, תלויות חיצוניות וסיכונים עם חלופות לעקיפה.
- בדיקה על היסטוריה, 2–4 שבועות. מריצים את הלוגיקה על הנתונים שלכם ומראים היכן הפער — בכללים, בנתונים או בביצוע.
ההערכה מגיעה כהתוכנית עבודה עם הרכב הצוות ואזור האחריות של כל אחד. פורמט המסירה — מאגר קוד, תיעוד קונפיגורציה, תקנון הפעלה וחזרה לאחור; הנתונים והגישות נשארים אצלכם. תארו את המשימה — נחזור עם הערכה ותוכנית.







