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

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

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

יום שני: ההרצה החוזרת לא תאמה

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

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

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

יום שלישי: מצאנו את הקבלה החסרה

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

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

התייחסנו ל„אותה שאילתה” כאילו פירושה „אותם נתונים”. ההנחה הזאת גרמה לניסוי להיראות שחזורי יותר מכפי שהיה בפועל.

יום רביעי: התיקון שינה את התמונה

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

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

יום חמישי: שינינו את רשומת המחקר

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

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

יום שישי: על מה היינו מוותרים בפעם הבאה

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

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

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