یک نسخهٔ ثابت از داده‌های بازار برای قابل‌اعتماد بودن بک‌تست کافی نیست. چنین نسخه‌ای می‌تواند همان نتیجه را بازتولید کند و درعین‌حال پنهان بماند که فروشنده ورودی‌های سازندهٔ آن نتیجه را تغییر داده است.
نسخهٔ ثابت را نگه دارید. بعد گزارشی از تغییرات داشته باشید که نشان دهد چه چیزی، چه زمانی جابه‌جا شده و آیا استراتژی به آن اهمیت داده است. این موضوع به‌ویژه وقتی مهم است که پژوهش شما از معاملات اصلاح‌شده، اطلاعات بنیادی بازبینی‌شده، فاندینگ بازسازی‌شده یا تاریخچه‌ای استفاده می‌کند که فروشنده بی‌سروصدا به‌روزرسانی کرده است.
چطور ممکن است یک بک‌تست تکرارپذیر همچنان گمراه‌کننده باشد؟
فرض کنید دوشنبه پنج سال دادهٔ کندل ساعتی دانلود می‌کنید و استراتژی‌ای را اجرا می‌کنید. تا جمعه، فروشنده یک معاملهٔ نادرست را اصلاح کرده، رویداد شرکتی را تعدیل کرده یا شکافی را پر کرده است. فایل ذخیره‌شدهٔ شما همچنان دقیقاً نتیجهٔ دوشنبه را می‌دهد. این یعنی تکرارپذیری. اما اگر دوباره با تاریخچهٔ فعلی فروشنده اجرا کنید، ممکن است نتیجهٔ متفاوتی بگیرید و هیچ سابقه‌ای از دلیل آن نداشته باشید.
مسئله فقط به اصلاحات بزرگ محدود نیست. تغییر یک سقف می‌تواند حد ضرر را فعال کند؛ اصلاح قیمت پایانی می‌تواند یک اندیکاتور را از آستانه‌اش عبور دهد. در یک جهان دارایی گسترده، تغییر تاریخچهٔ یک نماد می‌تواند رتبهٔ آن را عوض کند و دارایی دیگری را از پرتفوی بیرون براند. حتی اگر کد و پیکربندی استراتژی یکسان باشند، Sharpe نهایی ممکن است تغییر کند.
هش فایل به شما می‌گوید دو فایل با هم فرق دارند. اما نمی‌گوید تعدیل ناشی از تجزیهٔ سهام قیمت‌های 40 سال را تغییر داده، فروشنده سه معامله را اصلاح کرده یا تجزیه‌گر یک فیلد خالی را به صفر تبدیل کرده است.
چه چیزهایی باید در گزارش تغییرات داده‌های بازار ثبت شوند؟
تغییرات را در کوچک‌ترین واحد کاربردی ثبت کنید و به‌اندازه‌ای زمینه فراهم کنید که پژوهش متأثر از تغییر قابل‌بازپخش باشد. برای خوراک کندل، این کار معمولاً به معنی ثبت ابزار، بازه، زمان رویداد، مقادیر قبلی و جدید، منبع و زمانی است که به‌روزرسانی را مشاهده کرده‌اید. اگر فروشنده payload اصلی را ارائه می‌دهد، آن را نگه دارید.
| مورد ثبت‌شده | دلیل نگهداری | نمونه |
|---|---|---|
| نسخهٔ منبع یا زمان دریافت | وضعیت دادهٔ فروشندهٔ مورداستفاده را مشخص می‌کند | نسخهٔ ثابت دریافت‌شده در 2026-11-02 08:15 UTC |
| فیلد تغییرکرده و مقادیر قدیم/جدید | نشان می‌دهد دقیقاً چه چیزی جابه‌جا شده است | ETHUSDT 1h سقف: 3,412.10 → 3,418.60 |
| دسته‌بندی تغییر | اصلاح‌ها را از تبدیل‌ها جدا می‌کند | اصلاح دیرهنگام معامله، تعدیل تجزیهٔ سهام، تکمیل دادهٔ گذشته |
| نسخهٔ خط لوله و شِما | تغییرات منبع را از پردازش‌های خودتان متمایز می‌کند | Normalizer v7، شِمای کندل تعدیل‌شده v3 |
برای مجموعه‌داده‌های بزرگ، نسخه‌های ثابت و تغییرناپذیر را همراه با مانیفستی کم‌حجم از checksumها، نسخه‌های منبع و زمان‌های دریافت ذخیره کنید. برای بخش‌های تغییرکرده، تفاوت‌های ردیفی را اضافه کنید. این راه‌حل میانه‌ای کاربردی است: بازپخش کامل همچنان ممکن می‌ماند، بی‌آنکه هر ردیف بدون تغییر را در جدول ممیزی دومی بنویسید.
چطور بسنجیم که یک اصلاح اهمیت دارد؟
پس از شمردن ردیف‌های تغییرکرده متوقف نشوید. استراتژی متأثر را با داده‌های قدیم و جدید، تحت همان کد، پارامترها، کارمزدها و فرض‌های اجرا دوباره اجرا کنید. تصمیم‌ها و مسیری را که به نتیجه رسیده مقایسه کنید.
- با استفاده از تفاوت‌ها، ابزارها و زمان‌های رویداد متأثر را مشخص کنید.
- مشخص کنید کدام ویژگی‌ها، سیگنال‌ها، سفارش‌ها یا وزن‌های پرتفوی از این رکوردها استفاده می‌کنند.
- کوچک‌ترین بازهٔ معتبر را بازپخش کنید؛ از جمله هر دورهٔ نگاه‌به‌عقب و وضعیت موقعیت‌های باز را.
- سفارش‌ها، معاملات اجراشده، میزان مواجهه، گردش معاملات، افت سرمایه و عملکرد نهایی را مقایسه کنید.
برای نمونه، اصلاح فروشنده که سقف 1-minute را به‌اندازهٔ $0.02 تغییر می‌دهد ممکن است یک میلیون ردیف را درگیر کند و هیچ اثری بر استراتژی مومنتوم روزانه نداشته باشد. اما یک کندل اصلاح‌شده در سطح حد ضرر می‌تواند مهم باشد. اثر بر تصمیم‌ها را بسنجید؛ شمارش رکوردهای تغییرکرده معیار مناسبی برای آن نیست.
دو پرسش را جداگانه بررسی کنید: «آیا می‌توانم نتیجه را با داده‌هایی که ذخیره کرده‌ام بازتولید کنم؟» و «آیا این نسخهٔ داده در آن زمان در دسترس استراتژی بود؟» گزارش تغییرات به پاسخ‌گویی به هر دو کمک می‌کند، اما پرسش دوم به سوابق دسترس‌پذیری در همان مقطع زمانی هم نیاز دارد.
این کار چه هزینه‌ای دارد و چه وقت می‌ارزد؟
ردیابی تغییرات به فضای ذخیره‌سازی، کار دریافت داده و تصمیم‌های عملیاتی نیاز دارد. ممکن است فروشندگان نسخه‌های پایدار ارائه نکنند و برخی خوراک‌های تاریخی به‌طور دوره‌ای، بدون اطلاع‌رسانی روشن دربارهٔ اصلاحات، بازسازی شوند. تغییری را که هرگز مشاهده نمی‌کنید نمی‌توانید ثبت کنید.
از جایی شروع کنید که بازبینی‌ها می‌توانند نتیجهٔ پژوهش را تغییر دهند: کندل‌های مورداستفاده در منطق حد ضرر، سهام تعدیل‌شده بر اساس رویدادهای شرکتی، اطلاعات بنیادی در مقطع زمانی مربوط و سری‌های فاندینگ یا بهرهٔ باز که بازسازی می‌شوند. برای مجموعه‌داده‌های گسترده و باثبات، مانیفست روزانه به‌همراه checksum بخش‌ها شاید کافی باشد. برای داده‌هایی که زیاد به‌روزرسانی می‌شوند یا تصمیم‌های معاملاتی به رکوردهای منفرد حساس‌اند، تفاوت‌های سطح فیلد را اضافه کنید.
منتقدان درست می‌گویند که آرشیو کامل و همیشگیِ هر پاسخ فروشنده می‌تواند پرهزینه شود و باز هم نتواند آنچه منبع در همان زمان می‌دانست ثبت کند. راهکار این است که دامنهٔ ممیزی را به داده‌ها و تصمیم‌های مهم محدود کنید و خلأها را مستند سازید. نسخهٔ ثابت به شما امکان می‌دهد آزمایش را دوباره اجرا کنید. گزارش تغییرات به شما امکان می‌دهد توضیح دهید چرا پاسخ آزمایش تغییر کرده است.
← همهٔ مطالب
