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