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

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

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

שאלות נפוצות

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

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1376
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1350
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    798
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1088
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1034
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1130

המעבר מ-backtest ל-live: היכן נשברת האסטרטגיה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כיצד אנו בונים את המעבר: שלבי העבודה ההנדסית

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

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

מה נשאר לכם לאחר מסירת המערכת

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

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

רשימת הבדיקה של הקבלה באה יחד עם הערכה: לפיה אתם בודקים בעצמכם שהעמדה הוקמה כהלכה ושהמעבר מ-backtest למסחר אמיתי משוחזר בצד שלכם.

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

מה היה

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

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

מה שינו

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

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

מה נהיה

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

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

במה שונה הביצוע ב-backtest מהזמנה אמיתית

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

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

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

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

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

ספקות טכניים: השהיות, ניתוקי תקשורת, נזילות

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

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

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

כיצד המסחר מתאושש לאחר ניתוק החיבור?

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

מה מונע כפילות הזמנות בעת שליחה חוזרת?

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

מה לעשות אם הנזילות של הכלי אינה מספיקה לנפח?

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

נדון במשימה: מה נדרש להערכה מדויקת של ההפעלה

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

אספו את מה שיש בהישג יד:

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

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

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