בדיקות לאחור של אסטרטגיות DeFi עם Jesse Python: אינטגרציה והגדרה

אינטגרציית Jesse: היכן נשברת הבדיקה של אסטרטגיות DeFi

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

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

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

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

מה נותנת אינטגרציית Jesse: השפעות מדידות

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

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

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

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

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

דרכי הרצה: סביבה מקומית, קונטור משותף, ענן

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

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

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

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

סדר העבודה: מניתוח האסטרטגיה ועד מסירת הסביבה

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

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

מה נשאר לצוות לאחר הטמעת הסביבה

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

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

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

מקרה בוחן: כיצד הסירו אי-התאמות בתוצאות ההרצות

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

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

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

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

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

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

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

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

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

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

מה לעשות אם הנתונים ההיסטוריים חסרים או בפורמטים שונים?

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

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

איך מועברים מפתחות גישה לזירות מסחר?

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

אפשר להעביר אסטרטגיות מוכנות שכתבתם?

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

מדוע תוצאת הרצה מקומית שונה מזו של השרת?

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

נדון במשימה: נבנה סביבה לאסטרטגיות שלכם

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

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

מה לשלוח לניתוח:

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

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