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

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

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

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

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

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

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

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

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

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

יכולת שחזור תוצאות הבדיקה נשענת על שלוש נעילות: snapshot של נתוני השוק עם סכום בקרה, גרסת קוד האסטרטגיה וזרע (seed) קבוע של הגנרטור.

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

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

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

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

מצבי הרצה: וקטורי, מבוסס-אירועים וזורם

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

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

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

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

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

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

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

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

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

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

הרכב המסירה: סכמות נתונים, יומני הרצה, נהלים

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

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

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

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

היכן אבד הדיוק

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

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

מה שינינו

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

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

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

במה נבדל בקסטינג מבדיקת פורוורד בחשבון דמו?

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

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

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

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

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

ספקות נפוצים: נתונים, השהיות, נזילות, התאמת יתר

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

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

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

האסטרטגיה לא תתאים את עצמה יתר על המידה להיסטוריה?

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

האם נלקחים בחשבון נזילות והשהיית הביצוע?

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

כיצד לדעת שהבדיקה תואמת את הביצוע בפועל?

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

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

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

הסט המינימלי להתחלה:

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

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