بهینهسازی walk-forward این شهرت را دارد که روش صادقانهٔ تنظیم یک استراتژی است، و این شهرت را هم حق دارد — دستکم در مقایسه با بهینهسازی روی کل داده و تحسین نتیجه. اما این تکنیک حالتهای شکست خاموشی دارد و هر کدام دقیقاً یک محصول تولید میکنند: گزارش اعتبارسنجیای که میگوید «مقاوم» و به استراتژیای منگنه شده که نیست. اینها سه موردی هستند که مجبور شدهایم در برابرشان مهندسی کنیم، دستهبندیشده بر اساس خرابیای که بهجا میگذارند.
شکست اول: نشت پنجرهها
راه اشتباه: تنظیم روی ژانویه تا ژوئن، اعتبارسنجی روی ژوئیه، و بعد اجازه دادن به هر چیزی از ژوئیه که روی یک پاس دوم اثر بگذارد — اجرای مجدد بعد از دیدن عدد خارج از نمونه، یک «اصلاح کوچک» در شبکهٔ پارامترها، یک ویژگی که روی کل سری نرمالسازی شده. هرکدام بیگناه به نظر میرسند. کنار هم، پنجرهٔ خارج از نمونه را با کمی تأخیر به دادهٔ دروننمونه تبدیل میکنند.
خرابی: Sharpe خارج از نمونهای که بهطرز مرموزی Sharpe دروننمونه را دنبال میکند. نتایج واقعی خارج از نمونه پرنویز و ناامیدکنندهاند؛ رابطهٔ مشکوکانه صافِ IS/OOS یعنی اطلاعات دارد به عقب جریان پیدا میکند. ما این نسبت را صریحاً رصد میکنیم — دروننمونهٔ بیش از ۳ برابر خارج از نمونه، اجرا را علامتدار میکند، و خارج از نمونهٔ صفر یا کمتر آن را میکشد، فارغ از اینکه دروننمونه چقدر خوشگل باشد.
شکست دوم: خریدِ معیار در میان پنجرهها
سه پنجرهٔ walk-forward را اجرا میکنید، سه نتیجهٔ پرنویز میگیرید، و بعد خلاصه میکنید: میانگین Sharpe؟ میانه؟ حذف بدترین پنجره به بهانهٔ «تغییر رژیم»؟ هر انتخاب یک درجهٔ آزادی است، و یک بهینهساز مصمم (انسانی یا بیزی) آن خلاصهای را پیدا میکند که این استراتژی زیرش بهترین به نظر برسد. هفتادوپنج آزمایش Optuna در هر پنجره یعنی هفتادوپنج فرصت برای برازش نویز، ضربدر هر تعداد خلاصهای که حاضرید در نظر بگیرید.
خرابی: استراتژیای که اعتبارسنجی را پاس میکند و بعد در اجرای زنده عملکرد بدترین پنجره را تحویل میدهد، چون بدترین پنجره تنها پنجرهٔ صادق بوده. قاعدهٔ ما: نحوهٔ تجمیع پیش از اجرا در config قفل میشود، بودجهٔ آزمایشها ثابت است، و تحلیلگر نتایج را بهتفکیک پنجره و همراه با پراکندگی میخواند. استراتژیای که برای قبولی به خلاصهٔ دوستانه نیاز دارد، قبول نمیشود.
شکست سوم: holdoutی که دیگر holdout نیست
یک holdout دقیقاً یک بار کار میکند. بار دومی که یک استراتژی در برابرش ارزیابی میشود — بعد از یک تلنگر به پارامترها، یک دستکاری در سیگنال، یک «فقط یک نگاه بیندازیم» — دیگر holdout نیست؛ یک مجموعهٔ اعتبارسنجی کُند است. پانزده روز دستنخورده تا وقتی فشار تکرار از راه نرسیده، نگهداشتنش بدیهی به نظر میرسد و بررسی مجدد بیضرر حس میشود.
خرابی ظریف است: نتایج holdout که در طول تکرارهای یک استراتژی بهتر میشوند. دادهٔ تازهٔ خارج از نمونه هیچ دلیلی ندارد که تکرار سوم را بیشتر از تکرار اول پاداش دهد، و وقتی میدهد، یعنی holdout استخراج شده است. ما یکبارهبودن را بهصورت مکانیکی اعمال میکنیم: holdout در هر اجرای pipeline یک بار ارزیابی میشود، نتیجه در سابقه ثبت میشود، و استراتژیای که تلاش دیگری میخواهد باید کل مسیر پرمانع را از نو طی کند — با پنجرههای جدید و همهچیز. باید دستکم ۷۰٪ از Sharpe خارج از نمونهٔ walk-forward را حفظ کند، و آن تاس دیگر دوباره ریخته نمیشود.
نشانهای که از هر سه جان سالم به در میبرد
پیش از همهٔ اینها، یک جاروب حساسیت ساده اجرا میکنیم: هر پارامتر را ±۲۰٪ تکان میدهیم و معیارها را تماشا میکنیم. یک لبهٔ واقعی بهآرامی افت میکند؛ یک تصادف از پرتگاه میافتد. ارزانترین آزمون کل pipeline است و استراتژیهایی را وتو میکند که وگرنه از همهٔ مراحل بالا بهسلامت رد میشدند — چون پرتگاه پارامتری همان شکلی است که بیشبرازش دارد پیش از آنکه فرصت پیدا کند در ماشینآلات اعتبارسنجی پنهان شود.
هیچکدام از اینها بهینهسازی را امن نمیکند. فقط حالتهای شکست را پرسروصدا میکند — و این بیشترین چیزی است که صادقانه میشود از یک فرایند اعتبارسنجی خواست.
← همهٔ مطالب