Paper trading: היכן הסימולציה מתפצלת מהמסחר האמיתי
הרצת בדיקה של אסטרטגיה מסתיימת בגרף חלק כלפי מעלה, אך אותה לוגיקה בחשבון אמיתי מניבה תוצאה שאינה מתיישבת עם החישוב — לא במספר העסקאות ולא בתשואה הממוצעת.
הטעות אינה בקוד: Paper trading כברירת מחדל מניח ביצוע אידיאלי — הזמנה מתמלאת במלואה לפי מחיר מהזרם הציטוטים, ביטול פועל באופן מיידי, וספר ההזמנות מתחת לפקודה שלנו לא משתנה.
כל הנחה בנפרד נראית תמימה, אך יחד הן מזיזות את הערכת האסטרטגיה עד כדי כך שבדיקת פורוורד של אסטרטגיות מפסיקה לחזות את התוצאה.
החלקה בסימולציה מופיעה רק במקום שבו היא הוטמעה במפורש במודל. אם נפח ההזמנה דומה לנפח הנראה ברמת המחיר, הביצוע בפועל עובר דרך כמה רמות בספר, ומחיר העסקה הממוצע מתברר כגרוע מהמחיר בבדיקה.
הסימולטור לעומת זאת ממלא את כל הנפח במחיר הטוב ביותר — במכשירים דקים זה יוצר פער, שבסדרת עסקאות ארוכה מכסה את כל התשואה המוצהרת של האסטרטגיה.
המקור השני — השהיית ביצוע. האות מחושב לפי סגירת נר, מגיע לשער המסחר בעיכוב רשת, והזרם הנגדי מספיק לשנות מחירים: בבדיקה בין האות לעסקה עובר אפס זמן, במציאות — חלק ניכר משנייה.
לכך מתווסף זרם ציטוטים חלקי: ניתוק החיבור עובר את הבדיקה בשקט וממשיך לחשב לפי המחיר הידוע האחרון, בעוד שבמסחר אמיתי באותו רגע אי אפשר לא להיכנס ולא לצאת.
בנפרד מתפצלת הלוגיקה של ביטול הזמנות. בסימולציה הסרה והעברה של פקודה הן חינמיות ומיידיות, ולכן כל אסטרטגיה עם היצמדות להזמנת לימיט נראית רווחית מכפי שהיא.
בבורסה ביטול יכול להגיע לאחר ביצוע חלקי או להידחות בגלל מגבלת קצב בקשות — ואז הפוזיציה נשארת פתוחה, ומיד לאחר מכן מגיע אות בכיוון ההפוך. נבחן כיצד הפער בין הבדיקה לעסקאות אמיתיות נסגר בארכיטקטורה של פורוורד-טסט.
מה נותן פורוורד-טסטינג לפני העלאת האסטרטגיה לפעולה
פורוורד-טסטינג (Paper trading) מריץ אסטרטגיה על זרם נתוני שוק חי, אך ההזמנות אינן נשלחות לבורסה אלא אל אמולטור ביצוע.
מעגל הבדיקה מתחבר לאותו API מסחר כמו בסביבת הפרודקשן: ב-Binance ובפלטפורמות אחרות סט המתודות זהה, ולכן הפער בין ההרצה לחשבון אמיתי נובע מהלוגיקה של ההיפותזה, ולא מהבדל בתשתית.
בדיקת היפותזת מסחר נכנסת לימים במקום שבועות, ומדדי הרצת הבדיקה מחושבים באותו קוד כמו בפרודקשן. הפחתת הסיכון של האסטרטגיה מפסיקה להיות הצהרה: ההשפעות נראות בדוח, והכשלים מוסרים לפני שהאסטרטגיה מקבלת חשבון אמיתי.
השפעות שנראות בדוח
- זמן בדיקת ההיפותזה — ימים במקום שבועות, ההרצה מתבצעת ברצף.
- שיעור העסקאות הניתנות לשחזור — מעל 95% כאשר סנפשוט ספר ההזמנות קבוע וההרצה חוזרת.
- זמן ההשבתה של מעגל הבדיקה — דקות לאתחול מחדש במקום שעות של הרכבה ידנית של המתקן.
- יכולת חיזוי של דראודאון — העקומות המחושבת והמצויה מתכנסות, מגבלות הסיכון נקבעות מראש.
- מחלקות כשל — נסגרות במעגל הבדיקה, ולא בחשבון אמיתי.
מצב לפני ואחרי
| מחלקת כשל | לפני פורוורד-טסט | אחרי |
|---|---|---|
| ביטול הזמנה ברגע הביצוע | מרוץ, פוזיציה כפולה | נתפס בהרצה |
| ביצוע חלקי | עיוות בגודל הפוזיציה | נבדק בכל הרצה |
| חזרה על בקשה בעת ניתוק תקשורת | שכפול פקודות | אידמפוטנטיות מאומתת |
| ניתוק זרם הנתונים | האסטרטגיה ממתינה בשקט | סגירת חירום והתראה |
פורמטים של Paper trading: היסטוריה, זרם חי, מצב צל
היסטוריה, זרם חי וליווי צל אינם מחליפים זה את זה — הם עונים על שאלות שונות: האם הלוגיקה תעמוד בנתוני העבר, כיצד האסטרטגיה מתנהגת בספרדים אמיתיים ומה ישתנה אם נציב אותה לצד מעגל פעיל.
חתכים היסטוריים אנו שולפים מארכיונים כמו CoinGecko ומנרמלים לפורמט אחיד, כדי שההרצות יהיו ניתנות לשחזור.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הרצת בדיקה על היסטוריה | סינון ראשוני של היפותזות, כיוונון פרמטרים | אין החלקה ותור הזמנות, סיכון של התאמה-יתר לעבר |
| זרם ציטוטים חי | בדיקת ביצוע בספרדים ובעיכובים אמיתיים | פערי נזילות נדירים נשארים בלתי מזוהים |
| מצב מסחר בצל | השוואת גרסה חדשה לזו הפעילה באותו שוק | עומס כפול, נדרש חשבונאות אותות נפרדת |
איך לבחור מצב לפי סוג האסטרטגיה
עבור אסטרטגיות עם תדירות עסקאות גבוהה, הזרם החי הופך למכריע: בהיסטוריה העמלה וההחלקה נראות אחרת לגמרי מאשר בספר ההזמנות האמיתי. אסטרטגיות פוזיציה זולות יותר לבדיקה בהרצה על היסטוריה — שם חשובים יותר עמידות באופק ארוך והתנהגות באירועים נדירים, ולא מיקרו-מבנה הביצוע.
איך בנויה הרצת צל במקביל למעגל פעיל
עותק הצל מקבל את אותו זרם נתונים כמו המעגל הפעיל, אך אינו שולח הזמנות — האותות ומחירי החישוב נכתבים ליומן נפרד.
השוואה בין שני היומנים מראה פער בזמן הכניסה ובמחיר הביצוע: אם הגרסה החדשה מסמנת מוקדם יותר וסוגרת פוזיציה ב-2-3% רווחית יותר, אפשר לקדם אותה למעגל הראשי; אם הפער בכיוון ההפוך — התיקונים חוזרים להרצה.
שלבי הטמעת מערכת הבדיקות: מביקורת ועד מסירה
הטמעת מערכת הבדיקות מתחילה לא בקוד, אלא במלאי: כל עוד לא תוארו האסטרטגיות, המכשירים והמצבים, המתקן ישחזר את המערכת המבצעית בצורה הגרועה ביותר. אנו מובילים את הפרויקט בשלבים, ובכל שלב מתעדים תוצאה ניתנת לבדיקה.
- ביקורת אסטרטגיות מסחר: אוספים רשימה, טיים-פריימים, סטים של מכשירים וכללי בקרת סיכונים, מסמנים מה נבדק בבידוד ומה דורש חשבון משותף.
- תרשים זרמי נתונים: מתארים מהיכן מגיעים הציטוטים, ספר ההזמנות ואירועי בלוקצ'יין, כיצד הם מנורמלים ליומן משותף והיכן עובר הגבול בין המעגל המבצעי למעגל הבדיקה.
- הרכבת המתקן: פורסים סביבת Paper trading עם חשבונות מבודדים, אמולציה של מגבלות הבורסה ומאגר נפרד לתוצאות.
- כיול מודל הביצוע: מגדירים השהיות, החלקה, ביצוע חלקי של הזמנות לימיט ועמלות, כך שהתוצאה המדומה תתכנס עם זו הממשית.
- השוואה בעסקאות ייחוס: מריצים סט עסקאות ידועות ומשווים למציאות לפי מחיר כניסה, נפח וזמן, פערים מנתחים עד לרמה מקובלת.
- מסירה והדרכה: מראים לצוות כיצד להוסיף אסטרטגיות, לקרוא דוחות ולעדכן את מודל הביצוע ללא התמיכה שלנו.
קריטריוני קבלה
הקבלה מתבצעת לפי שחזוריות: אותו סט נתונים ואותה קונפיגורציה נותנים תוצאה זהה מהרצה להרצה. בנפרד מתעדים שהפער מול עסקאות הייחוס נכנס למסדרון המוסכם, והיומן שומר את נתוני הקלט ואת גרסת מודל הביצוע עבור כל הרצה.
הפעלה ללא עצירת המעגל הפעיל
את המתקן מקימים לצד המערכת המבצעית ומחברים לאותם מקורות דרך חיבורים ומגבלות נפרדים — המעגל הפעיל אינו נעצר ואינו משנה התנהגות. העברת אסטרטגיות מתבצעת אחת-אחת, עם אפשרות חזרה: אם הבדיקה מפריעה לעומס או מעוותת נתונים, החיבור מנותק בלי עקבות במעגל הפעיל.
מה הלקוח מקבל לידיו: מתקן, תרשימים, נהלים
מתקן ל-Paper trading אנו מוסרים לא "כפי שהוא", אלא כסט שלם שלפיו הצוות שלכם מריץ ובודק אותו ללא מעורבותנו. למסירה נכללים קונפיגורציות, תרשימים, כללי גישה ונהלים — להלן רשימת הארטיפקטים.
- קונפיגורציות של המתקן: קובצי סביבה, סטים של פרמטרי אסטרטגיות, תרחישי הרצה ותנאי התחלה שבהם התוצאה משוחזרת שוב.
- תרשים אינטגרציה עם פלטפורמות מסחר: אילו זרמים עוברים בזמן אמת, אילו נלקחים מההיסטוריה, היכן נמצאים חוצצים וכיצד מטפלים בניתוק תקשורת.
- כללי גישה ותפקידים: הפרדה לצופה, אנליסט ומנהל, מפתחות נפרדים לחשבונות בדיקה, יומן פעולות משתמשים.
- דוח כיול: כיצד השוו את זרם ההזמנות והעסקאות למקור ייחוס, אילו פערים נמצאו, כיצד נסגרו ומה נותר במגבלות ידועות.
- תיעוד למתקן הבדיקה: תיאור מודולים, פורמטים של נתוני קלט, נקודות הרחבה לחיבור פלטפורמות ומכשירים חדשים.
- נוהל ליווי: תדירות עדכון ספרי העזר, סדר הפעולות בעת עצירת מקור, למי נשלחת התראה ובאיזה מועד.
- צ'ק-ליסט קבלה: תרחישים שמורצים בצד שלכם לפני שהמתקן הופך לפעיל.
איך מעבירים ידע לצוות
מקיימים סקירה של המתקן עם המהנדסים שלכם: מראים הפעלה, התערבות ידנית בפרמטרים והפקת מדדים. הצוות שלכם מריץ בעצמו תרחיש אחד מתחילתו ועד סופו — זהו תנאי קבלה, לא פורמליות.
בהמשך התמיכה מתנהלת לפי נוהל הליווי: תיקונים באסטרטגיות אתם מבצעים בעצמכם, הרחבת אינטגרציות אנו לוקחים על עצמנו.
מקרה בוחן: צמצמנו את הפער בין הבדיקה לעסקאות אמיתיות
בתחילת הפרויקט פורוורד-טסטינג חושב לפי נרות היסטוריים: הזמנה נסגרה לפי מחיר הנר, עיכובי מסירה וביצועים חלקיים לא נלקחו בחשבון.
הדוחות התיישבו זה עם זה, אך לא התיישבו עם עסקאות אמיתיות — מחיר הכניסה לא תאם בכשליש מהמקרים בערך, והחלטות על אסטרטגיות התקבלו על נתונים שהצוות לא סמך עליהם.
מודל ביצוע עסקאות והתחשבות בעיכובים
את המתקן שיכתבו להרצת ספר הזמנות בורסאי מוקלט דרך קונקטור ל-Binance: הזמנה נכנסת לתור ומבוצעת לפי הנזילות הזמינה, נלקחים בחשבון נפח חלקי, עמלה, שיעור מימון ובנפרד — העיכוב בין האות להצבת הפקודה. אותו מדדו במעגל הפעיל והציבו בסימולציה.
ההרצה קשורה לתמונת מצב של נתונים ולגרסת פרמטרים, ולכן הרצה חוזרת נותנת תוצאה זהה — בעבר הגדרות צפות הפכו השוואה בין הרצות לחסרת משמעות.
השוו שלושה מדדים: הפער במחיר הכניסה ירד משליש מהמקרים ל-4%, הפער בתשואה הממוצעת בין המתקן לחשבון חי הצטמצם מ-40% ל-6%, והרצת היסטוריה יומית הואצה פי ארבעה.
העברת הגדרות המתקן למעגל הפעיל
ההגדרות כבר לא נמצאות בשני מקומות: תמונת מצב של פרמטרים — עמלות, השהיות, מגבלות נפח — מיוצאת מהמתקן ומוצבת במודול המבצעי כפי שהיא, ופערים נרשמים ביומן. אם אסטרטגיה במתקן ובחשבון מתפצלת מעבר לסף, ההרצה מסומנת כלא מהימנה: זה תופס שגיאת קונפיגורציה לפני שהיא הופכת להפסד.
במה פורוורד-טסטינג שונה מבדיקה על היסטוריה
בדיקה על היסטוריה עובדת עם סט נתונים קבוע: כל הטווח כבר נמצא במאגר, והאסטרטגיה רואה את השוק כולו. כך נוח לסנן במהירות היפותזות — בהרצה אחת נבדקות אלפי קומבינציות פרמטרים. הצד השני הוא שעקומת תשואה חלקה מתקבלת כאן בקלות רבה מדי: התאמה-יתר לעבר כמעט לא נתקלת בהתנגדות.
פורוורד-טסט, או Paper trading, לוקח את אותו ליבת אסטרטגיה, אך מקבל נתונים נר אחר נר — בלי גישה לעתיד. האותות מחושבים על נתונים נכנסים, והעסקאות אינן נשלחות לרשת: הביצוע מדומה לפי ספר ההזמנות הנוכחי עם עמלה והחלקה. האסטרטגיה מתנהגת כפי שהייתה מתנהגת בקרב, אך בלי סיכון לאבד כספים.
רק במצב הזה נראים דברים שאין בהיסטוריה השמורה: החלקה על ספר דק, ביצועים חלקיים, השהיה בין האות להצבת הפקודה, התנהגות לאחר ניתוק תקשורת והפעלה מחדש. מדגם היסטורי מחליק פרטים כאלה ולכן אינו מציג אותם.
הדבר העיקרי שפורוורד-טסט תופס — התאמת-יתר של האסטרטגיה. על היסטוריה הפרמטרים נבחרים עד לעקומה יפה, שמתפוררת בקטע הראשון הלא מוכר של השוק. בדיקה על נתונים נכנסים מתבצעת על קטע שלא היה קיים בזמן הכיוונון, ומראה את העמידות האמיתית של הלוגיקה, ולא את איכות ההתאמה.
לכן גישה אחת אינה מספיקה: ההיסטוריה עונה על השאלה "מה היה", והפורוורד — "מה קורה עכשיו, בזמן שהשוק זז מעצמו". הראשונה מסננת רעיונות חלשים מראש, השנייה מאשרת שהכללים שורדים על נתונים לא מוכרים ושהתוצאה לא התפוררה יחד עם הכיוונון.
שאלות טכניות לפני תחילת הפרויקט
לפני תחילת הפרויקט לקוחות מביאים את אותו סט של ספקות הנדסיים: האם מודל הביצוע ב-Paper trading לא יתברר כ"חממה" מדי, האם יספיקו נתונים היסטוריים והאם הסימולטור לא יתחיל להפריע למעגל הפעיל. תשובות קצרות להלן בדרך כלל מסירות את השאלות האלה לפני דיון בהערכות ובתוכנית.
עד כמה מודל הביצוע תואם לעסקה אמיתית?
הסימולטור לא "מצייר" מחיר אידיאלי — ההזמנה מותאמת מול ציטוטים נגדיים תוך התחשבות בספרד, בהחלקה ובביצוע חלקי של הנפח. אנו מדמים עמלות, השהיית מסירת הזמנה והפעלת מגבלות, ולכן הפער מול הרצה מבצעית נשאר ביחידות אחוזים, ולא בפקטורים.
מה הדרישות לנתונים היסטוריים?
צריך סדרה רציפה של ציטוטים עם צעד אחיד וסט שדות מלא, כולל נפח. את ההיסטוריה בודקים לאיתור חוסרים, כפילויות ופערי סשנים לפני תחילת הבדיקה — אחרת בגרף מופיעות עסקאות במחיר שלא היה קיים באותו רגע.
מה לעשות עם מכשירים נדירים?
עבור ניירות ערך וזוגות בעלי נזילות נמוכה אנו מרימים תמונות מצב שמורות של ספר ההזמנות ומחשבים ביצוע לפי המחיר הזמין הגרוע ביותר. אם הנתונים מועטים באופן אובייקטיבי, מסמנים את המכשיר כבעל בדיקות מוגבלות — התוצאה שלו אינה מתערבבת בסטטיסטיקה הכללית.
האם הסימולטור יעמיס על מעגל המסחר הפעיל?
מעגל הבדיקה מבודד: חשבון משלו, זרם נתונים נפרד, הגבלת קצב בקשות. אסטרטגיות מבצעיות אינן רואות הזמנות בדיקה, ועומס השיא של הסימולטור אינו מוסיף השהיות לעסקאות אמיתיות.
מה משתנה במערכת לאחר המסירה?
אנו מוסרים קונפיגורציה, כללי התאמת הזמנות, תיעוד להרחבה וסט תרחישים לרגרסיה. מכשיר חדש או שדה חדש במודל הביצוע מתווספים בעריכת קונפיגורציה, בלי לכתוב מחדש את הליבה.
נדון במשימת הבדיקה של האסטרטגיות שלכם
כדי שהערכת הפרויקט תהיה מדויקת ולא מקורבת, יש צורך בחתך של התשתית שלכם ושל מה שהמערכת ל-Paper trading אמורה להראות. להלן — מה לשלוח בהודעה הראשונה: לפי הרשימה הזו נקבע את הדרישות למערכת ונחזור עם תוכנית הטמעה בשלבים.
- תיאור האסטרטגיות: לוגיקת כניסה ויציאה, האינדיקטורים והטיים-פריימים שבשימוש, כיצד מחושבים האותות כיום — ידנית, בטבלאות או כבר בקוד.
- מקורות נתונים: פלטפורמות ומכשירים, עומק ההיסטוריה הנדרש, האם נדרש זרם ציטוטים בזמן אמת ובאיזו תדירות עדכון.
- תרשים מעגלים: כמה סביבות נדרשות — הרצה על היסטוריה, Paper trading על זרם חי, השוואה למסחר אמיתי — וכיצד הן קשורות זו לזו.
- דרישות לדיווח: אילו מדדים לחשב (תשואה, דראודאון, שיעור עסקאות רווחיות), באיזה אופן למסור — פאנל ניטור, ייצוא לטבלה, דוח תקופתי.
- מגבלות: לוחות זמנים, הרשאות גישה לפלטפורמות ולנתונים, כללי הפרדת הרשאות, מערכות שצריך להשתלב בהן.
- פיתוחים קיימים: מה כבר קיים וצריך להישמר, ומה אפשר להחליף בלי לאבד את הלוגיקה.
עם הסט הזה ננתח את צווארי הבקבוק, נקבע את הדרישות למערכת ונחזור עם הערכת פרויקט ותוכנית הטמעה. אם חלק מהנתונים עדיין לא נאסף — תארו במילים, את השאלות המבהירות נשאל בעצמנו.