פיתוח אלגוריתם HFT (מסחר בתדירות גבוהה)

מדוע אלגוריתם HFT אינו מניב תוצאה על נתונים אמיתיים

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

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

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

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

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

מה נותן מסחר בתדירות גבוהה בניהול מבוקר

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

זמן תגובה צפוי מראש

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

עמידות תחת שיא ועיקרון תקלות מבוקר

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

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

אלגוריתם HFT: אפשרויות יישום ומגבלותיהן

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

בחירת מצב העבודה של הלוגיקה

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

תאימות למסלול קיים בפעולה

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

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

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

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

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

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

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

קבלה ומסירת הפתרון

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

ערכת מסירה: קונפיגורציות, סכמות, נהלים

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

קונפיגורציות, סכמות וגישות

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

נהלים ותיעוד

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

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

ניתוח יישום: מדדים לפני ואחרי

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

היכן המערכת איבדה זמן

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

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

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

במה שונה השהיה נמוכה מתדירות פקודות גבוהה?

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

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

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

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

מגבלות, סיכונים ושאלות נפוצות

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

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

מי אחראי לתקלה של ספק נתונים חיצוני?

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

איך בודקים אסטרטגיה לפני הרצה על נפח אמיתי?

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

איזו תקלה נחשבת לגרועה ביותר ומה אז?

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

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

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

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

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

בפלט אתם מקבלים:

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

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