بک‌تستی ذخیره‌شده را دوباره اجرا کردیم و به منحنی سرمایه متفاوتی رسیدیم. همان کد استراتژی، همان بازه زمانی، همان نماد. موجودی پایانی 1.8% اختلاف داشت و زمان 3 معامله به‌اندازه یک کندل جابه‌جا شده بود.
همین برای آن‌که اعتماد به یک نتیجه پژوهشی دشوار شود کافی است. اگر هم‌تیمی‌تان، نسخه آینده خودتان یا یک سرویس معامله‌گری کاغذی نتواند اجرا را بازتولید کند، نمی‌توانید بفهمید تغییری استراتژی را بهتر کرده یا فقط آزمایش را عوض کرده است. این روندی است که برای پیدا کردن اختلاف دنبال کردیم.
روز 1: مشخص کردیم منظورمان از «همان اجرا» چیست
اشتباه اولمان این بود که فایل استراتژی را خودِ آزمایش فرض کردیم. چنین نبود. اجرا به داده‌های ورودی، نسخه موتور، تقویم، فراداده ابزار و تنظیمات اجرا هم وابسته بود. کد فقط یک بخش از محاسبه را توصیف می‌کرد.
پیش از هر تغییری، یک مانیفست اجرا ساختیم. در آن کامیت استراتژی، شناسه‌های اسنپ‌شات داده، بازه زمانی، محل معامله، برنامه کارمزد، منبع فاندینگ، مدل پرشدن سفارش و نسخه‌های نرم‌افزار را ثبت کردیم. سفارش‌ها و پرشدن‌های حاصل را هم ذخیره کردیم، چون منحنی سرمایه به‌تنهایی نشان نمی‌دهد دو اجرا نخستین بار کجا از هم جدا شده‌اند.
| دارایی | چه چیزی ثبت شود | چرا مهم است |
|---|---|---|
| داده‌های بازار | شناسه اسنپ‌شات، نسخه طرح‌واره، تعدیلات | تأمین‌کنندگان سابقه را اصلاح و رویدادهای شرکتی را بازنگری می‌کنند |
| اجرا | سطح کارمزد، سری فاندینگ، تنظیمات پرشدن و اثر بازار | پیش‌فرض‌ها و فرض‌های حساب نتیجه را تغییر می‌دهند |
| محیط اجرا | کامیت کد، نسخه‌های موتور و وابستگی‌ها | کتابخانه‌ها می‌توانند ترتیب، گرد کردن یا اندیکاتورها را تغییر دهند |
| خروجی | سفارش‌ها، پرشدن‌ها، موقعیت‌ها و معیارها | نشان می‌دهد اجراها از کجا با هم اختلاف پیدا می‌کنند |
روز 2: معاملات را مقایسه کردیم، نه Sharpe را
معیارهای خلاصه حواس‌پرت‌کن بودند. Sharpe هر دو اجرا تقریباً یکسان بود، اما گزارش‌های پرشدن سفارش نخستین ناهماهنگی را در تسویه فاندینگ نشان دادند. یک اجرا نرخ را به موقعیتی اعمال کرده بود که در زمان ثبت تسویه باز بود؛ اجرای دیگر از موقعیت پس از بازتنظیم همان زمان استفاده کرده بود.
کد استراتژی تغییر نکرده بود؛ ترتیب رویدادها در موتور تغییر کرده بود. به‌روزرسانی کوچکی در نسخه، ترتیبی را که پیش‌تر به نحوه مرتب‌سازی اتفاقی دو رویداد وابسته بود، صریح کرده بود.
قرارداد اجرا را اصلاح کردیم تا ترتیب را مشخص کند: نخست فاندینگ را به موقعیتی اعمال کن که وارد تسویه شده، سپس تصمیم‌های استراتژی را برای همان زمان پردازش کن. این قرارداد دقیق ممکن است بین محل‌های معامله و موتورهای مختلف فرق کند. مبهم گذاشتنش خودِ خطاست.
روز 3: معلوم شد یک فایل داده «یکسان» تفاوت داشت
بعد از تثبیت ترتیب رویدادها، ناهماهنگی‌های باقی‌مانده در چند معامله سهام متمرکز بودند. تأمین‌کننده تعدیل تاریخی یک تجزیه سهام را اصلاح کرده بود. نام فایل و تعداد ردیف‌هایش مثل قبل بود و همین باعث شده بود تغییرنکرده به نظر برسد.
حالا از هر اسنپ‌شات تغییرناپذیر داده اثرانگشت می‌گیریم و سیاست تعدیل را کنار آن نگه می‌داریم. هش می‌گوید بایت‌ها تغییر کرده‌اند یا نه؛ اما علت را توضیح نمی‌دهد. برای همین، مانیفست منبع، زمان دریافت و نسخه تبدیل را هم در بر می‌گیرد. برای داده‌هایی که بازنگری می‌شوند، این جزئیات بخشی از نتیجه‌اند.
بک‌تستی بازتولیدپذیر باید پاسخ دهد: «کدام نسخه از گذشته را دیده است؟»
روز 4: یک پیش‌فرض پنهان را پیدا کردیم
آخرین تفاوت، کارمزد maker بود که چون فیلدش در پیکربندی استراتژی نیامده بود، صفر در نظر گرفته شده بود. موتور جدیدتر کارمزد پیش‌فرض حساب را اعمال کرد. همین یک پیش‌فرض، معاملات مرزی را آن‌قدر تغییر داد که بخش عمده اختلاف موجودی پایانی را توضیح می‌داد.
تنظیمات اثرگذار اقتصادی را صریح کردیم و کاری کردیم موتور پیکربندی نهایی‌شده را در گزارش اجرا چاپ کند. پیش‌فرض‌ها هنگام بررسی اولیه کار را راحت می‌کنند؛ اما برای مقایسه نتایج در گذر زمان، مدرک خوبی نیستند.
دفعه بعد چه کارهایی را کنار می‌گذاریم
نیمی از روز را صرف مقایسه معیارهای تجمیعی کردیم، پیش از آن‌که نخستین پرشدن متفاوت را بررسی کنیم. از آن‌جا شروع نکنید. هر دو گزارش رویداد را بر اساس زمان مرتب کنید و نخستین اختلاف را بیابید؛ اختلاف‌های بعدی اغلب از همان علت ناشی می‌شوند.
همچنین این تصور را کنار می‌گذاریم که تصویر کانتینر به‌تنهایی اجرا را بازتولیدپذیر می‌کند. تصویر کانتینر بخش بزرگی از محیط نرم‌افزار را تثبیت می‌کند، اما فایل داده خارجی، برنامه کارمزدی که هنگام اجرا دریافت می‌شود یا سابقه بازنگری‌شده یک تأمین‌کننده را دربرنمی‌گیرد.
وقتی بک‌تست تغییر می‌کند، هر دو مانیفست اجرا و گزارش‌ها را نگه دارید و هر بار فقط یک منبع اختلاف را برطرف کنید. نتیجه مفید صرفاً منحنی‌ای نیست که بتوانید دوباره اجرا کنید؛ گزارشی است که توضیح می‌دهد چه داده‌ها و فرض‌هایی آن را ساخته‌اند و چرا اجرای بعدی ممکن است فرق کند.
← همهٔ مطالب
