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


