یک آزمون مفید برای بک‌تست هیچ ربطی به پیدا کردن پارامتر بهتر ندارد: فرایند را در میانه متوقف کنید، آن را بازیابی کنید و همان بازپخش را تا پایان ادامه دهید. با ورودی‌های یکسان و شبیه‌ساز اجرای کنترل‌شده، تصمیم‌ها، سفارش‌ها و ارزش ویژه باید با اجرای بی‌وقفه مطابقت داشته باشند.
اگر چنین نیست، به مشکل مدیریت وضعیت برخورده‌اید. استراتژی به چیزی وابسته است که ذخیره نکرده‌اید یا نمی‌توانید بازسازی‌اش کنید. این وابستگی هر وقت اجرای پژوهش از سر گرفته شود، پردازشگرها جایگزین شوند یا سرویس معاملات کاغذی کد تازه‌ای را مستقر کند، اهمیت پیدا می‌کند.
این آزمون را دوست دارم، چون پاسخ مورد انتظارش به‌طرز غیرمعمولی روشن است. بحثی بر سر تغییر بازار نیست. هر دو اجرا همان بازار را دریافت می‌کنند.
در ادامه سه روش نادرست برای راه‌اندازی مجدد را می‌بینید. اعداد نمونه‌ای هستند؛ هر یک از این خطاها می‌تواند در سامانه‌ای کاملاً قطعی هم رخ دهد.
1. چند کندل بارگیری کنید و فرض کنید اندیکاتورها گرم شده‌اند
فرض کنید استراتژی از میانگین متحرک نمایی با دورهٔ 100 استفاده می‌کند. به‌روزرسانی آن چنین است:
alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previousفرایند بی‌وقفه مقدار انباشتهٔ EMA را به جلو می‌برد. فرایندِ دوباره‌راه‌اندازی‌شده 100 کندل می‌گیرد، EMA را با قیمت پایانی نخست مقداردهی می‌کند و فرض می‌کند اندیکاتور 100دوره‌ای به 100 مشاهده نیاز دارد.
این فرض، پارامتر هموارسازی اندیکاتور را با یک پنجرهٔ حافظهٔ محدود اشتباه می‌گیرد. EMA سهمی کاهنده از وضعیت اولیه‌اش را حفظ می‌کند. اگر اختلاف EMA دو نسخه در آغاز 10 واحد قیمت باشد، قیمت‌های بعدی یکسان این اختلاف را به شکل زیر کاهش می‌دهند:
| تعداد به‌روزرسانی‌ها از زمان مقداردهی اولیه | اختلاف باقی‌مانده | سهم خطای اولیه |
|---|---|---|
| 100 | 1.353 | 13.53% |
| 250 | 0.0674 | 0.674% |
| 500 | 0.000454 | 0.00454% |
محاسبه به این صورت است: 10 * (99 / 101)^k. بارگیری 100 کندل فقط 99 به‌روزرسانی به شما می‌دهد، اگر مشاهدهٔ نخست را مقدار آغازین بگیرید.
آسیب معمولاً نزدیک مرز تصمیم‌گیری آشکار می‌شود. در یک اجرا قیمت بالاتر از EMA است و در دیگری پایین‌تر. اختلاف عددی کوچک، یک معاملهٔ اضافی کامل ایجاد می‌کند. بعد از آن، دوره‌های توقف، وجه نقد در دسترس و تصمیم‌های بعدی هم می‌توانند از هم فاصله بگیرند.
وضعیت بازگشتی اندیکاتور، وضعیت مقداردهی اولیه و آخرین رویداد پردازش‌شده را ذخیره کنید. راه دیگر این است که بازپخش را از یک وضعیت آغازین معلوم انجام دهید. گرم‌کردن طولانی‌تر می‌تواند تقریب قابل‌قبولی به دست دهد، اما طول آن را بر پایهٔ آستانهٔ خطای مشخص انتخاب کنید و بررسی کنید آیا آن آستانه می‌تواند تصمیم‌ها را تغییر دهد. «پنج برابر دوره» یک قاعدهٔ رایج است، نه اثبات.
ضمن اینکه اندیکاتورها تمام تاریخچه نیستند. صدک متحرک به پنجرهٔ خودش نیاز دارد. یک مدل برخط ممکن است به وضعیت بهینه‌سازش نیاز داشته باشد. قانونی که پس از زیان 3 کندل منتظر می‌ماند، باید آن زیان و شمارنده را به خاطر بسپارد.
2. موقعیت‌ها را ذخیره کنید و سفارش‌های در جریان را از یاد ببرید
موقعیت هدف شما 10 واحد است. سفارش خرید 10 واحدی، 4 واحد پر شده و 6 واحد در انتظار دارد. موقعیت را به‌صورت 4 ذخیره می‌کنید، فرایند را از نو راه می‌اندازید و برای 6 واحد باقی‌مانده سفارش خرید دیگری می‌فرستید.
اگر هم باقی‌ماندهٔ سفارش اصلی و هم سفارش جایگزین پر شوند، 16 واحد در اختیار دارید.
نسخهٔ بک‌تست این خطا اغلب پنهان می‌ماند، چون با راه‌اندازی مجدد موتور پرشدن سفارش، سفارش‌های فعال بی‌سروصدا پاک می‌شوند. در معاملات کاغذی، شبیه‌ساز یا سرویس خارجی ممکن است آن‌ها را نگه دارد. در این صورت، همان کد بازیابی بسته به اینکه کدام مؤلفه باقی مانده، میزان مواجههٔ متفاوتی ایجاد می‌کند.
| هنگام راه‌اندازی مجدد | وضعیت واقعی | بازیابی فقط بر پایهٔ موقعیت می‌بیند |
|---|---|---|
| موقعیت هدف | 10 | 10 |
| موقعیت پرشده | 4 | 4 |
| مقدار سفارش خرید در انتظار | 6 | 0 |
| مقدار اضافی موردنیاز | 0 | 6 |
آسیب به شکل موج ناگهانی و بی‌توضیحی از سفارش‌ها بلافاصله پس از بازیابی نمایان می‌شود. گاهی میزان مواجهه دو برابر می‌شود. گاهی موقعیتی بسته می‌شود که سفارش حفاظتی‌اش هنوز فعال است و آن سفارش بعداً می‌تواند موقعیت تازه‌ای باز کند.
نقطهٔ وارسی باید علاوه بر موقعیت‌ها، شناسهٔ سفارش و وضعیت چرخهٔ عمر آن را هم در بر بگیرد. بازیابی باید پیش از تولید اقدام‌های تازه، این سوابق را با سامانهٔ اجرا تطبیق دهد. اگر نتیجهٔ یک سفارش معلوم نیست، باید بررسی شود؛ فرض‌کردن اینکه «تأییدیه‌ای ذخیره نشده» یعنی «سفارشی ارسال نشده» همان چیزی است که سفارش‌های تکراری را به وجود می‌آورد.
شناسه‌های پایدار سفارشِ سمت کارخواه کمک می‌کنند بفهمید چه اتفاقی افتاده است. آن‌ها فقط زمانی جلوی تکرار را می‌گیرند که سامانهٔ دریافت‌کننده واقعاً قواعد لازم برای یکتایی یا بی‌اثری تکرار را اعمال کند. شناسه‌های اجرای پردازش‌شده را هم ذخیره کنید تا بازپخش یک پرشدن، موقعیت را دو بار افزایش ندهد.
من به صفحهٔ خسته‌کنندهٔ وضعیت سفارش‌ها علاقهٔ خاصی دارم. روز راه‌اندازی مجدد، ردیف‌های کوچک آن ناگهان به جذاب‌ترین رابط کاربری ساختمان تبدیل می‌شوند.
3. موقعیت را بازیابی کنید و یک دفتر P&L تازه آغاز کنید
یک نمونهٔ نقدیِ بدون اهرم و کارمزد را در نظر بگیرید. با 10,000$ وجه نقد شروع می‌کنید، 10 واحد را به قیمت 100$ می‌خرید و وقتی قیمت‌گذاری به 110$ می‌رسد نقطهٔ وارسی می‌گذارید.
وضعیت درست، 9,000$ وجه نقد به‌علاوهٔ موقعیتی به ارزش 1,100$ است: ارزش ویژهٔ 10,100$. اگر بازیابی 10 واحد را برگرداند اما وجه نقد را به مقدار اولیهٔ 10,000$ بازنشانی کند، 11,100$ گزارش می‌شود. با راه‌اندازی دوبارهٔ یک فرایند، 1,000$ خلق کرده‌اید.
نمونه‌های دیگر کمتر چشمگیرند. بازیابی ارزش ویژه را دست‌نخورده نگه می‌دارد، اما قیمت ورود را به 110$ بازنشانی می‌کند. ارزش ویژهٔ کل ممکن است درست بماند، در حالی که تفکیک سود و زیان تحقق‌یافته از تحقق‌نیافته تغییر می‌کند. اگر حد ضرر یا شرط خروج به قیمت ورود وابسته باشد، این میان‌بر حسابداری حالا رفتار معاملاتی را تغییر می‌دهد.
یا سامانه اوج قبلی ارزش ویژه را فراموش می‌کند. فرض کنید ارزش ویژه پیش از افت به 10,100$، به 10,600$ رسیده بود. افت سرمایه حدود 4.72% است. اگر هنگام بازیابی بالاترین مقدار ثبت‌شده بازنشانی شود، استراتژی ناگهان تصور می‌کند افت سرمایه‌اش صفر است. هر کنترل ریسک مبتنی بر افت سرمایه به‌تازگی بدون مجوز بازنشانی شده است.
پس آسیب می‌تواند به شکل گسست در ارزش ویژه، بهبود مشکوک افت سرمایه یا قاعدهٔ ریسکی باشد که پس از استقرارهای جدید دیگر فعال نمی‌شود. دفتر حسابداری و وضعیت وابسته به حسابداری استراتژی را حفظ کنید: جابه‌جایی‌های وجه نقد، موقعیت‌ها، بهای تمام‌شدهٔ مرتبط، هزینه‌های انباشته و حافظهٔ کنترل ریسک. ارزش ویژهٔ بازیابی‌شده را در همان زمان ارزش‌گذاری با دفتر تطبیق دهید.
نقطهٔ وارسی به مرزی سازگار نیاز دارد. ذخیره‌کردن وجه نقد پس از پرشدن سفارش و مقدار موقعیت پیش از همان پرشدن، وضعیتی می‌سازد که هرگز وجود نداشته است. وضعیت‌های مرتبط را با هم ثبت کنید یا دنبالهٔ رویدادهای پایداری را ذخیره کنید تا از روی آن بازسازی شوند. نشانگر رویداد را هم همراه وضعیت ذخیره کنید تا بازیابی نه رویدادی را جا بیندازد و نه پرشدن سفارش را دوباره اعمال کند.
آزمونی که در چارچوب پژوهش نگه می‌دارم، ابتدا یک بازپخش مرجعِ بی‌وقفه اجرا می‌کند و سپس اجرای دومی را در نقاطی عمداً دردسرساز از نو راه می‌اندازد: هنگام مقداردهی اولیهٔ اندیکاتور، پس از پرشدن بخشی از سفارش و وقتی محدودیت ریسک فعال است. ترتیب رویدادها را یکسان نگه دارید و وضعیت تصادفی شبیه‌ساز را حفظ کنید. نخستین تصمیم پس از بازیابی، سوابق سفارش و پرشدن و مسیر ارزش ویژه را مقایسه کنید. یکسان‌بودن ماندهٔ نهایی به‌تنهایی می‌تواند خطاهای جبرانی را پنهان کند.
برای حالتی که فرایند پس از ارسال و پیش از دریافت تأییدیه از کار می‌افتد، چارچوب آزمون باید وضعیت سرویس اجرا را مستقل از فرایند استراتژی حفظ کند. وگرنه همان ابهامی را پاک می‌کند که می‌خواهید بیازمایید.
مشخصات یک استراتژی شامل چیزهایی است که به یاد می‌سپارد. این حافظه را آن‌قدر روشن و صریح کنید که بتوانید فرایند را در میانهٔ بازپخش متوقف کنید و دقیقاً نشان دهید چگونه دوباره کارش را از سر می‌گیرد.
← همهٔ مطالب
