פיתוח מערכת בקטסטינג לאסטרטגיות קריפטו תיקיות

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

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

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

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

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

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

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

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

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

גישת אירועים וגישת וקטור: היכן עובר הגבול

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

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

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

שחזוריות כדרישת הנדסה

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

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

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

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

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

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

במה נבדל בקטסט אירועי מבקטסט וקטורי ומתי לבחור במה?

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

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

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

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

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

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

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

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

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

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

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

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

מה השתנה במספרים

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

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

תאימות, הגירה והרשאות גישה: מה יש לדון לפני ההתחלה

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

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

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

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

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

עם המסירה מקבל הלקוח:

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

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

לוחות זמנים להטמעת מערכת בקטסטינג לפי שלבים

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

מה מאריך את לוחות הזמנים

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

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

מה מאיץ את העבודה

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

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