خطرناک‌ترین خطای زمان‌بندی در یک بک‌تست ممکن است حتی پس از بررسی بی‌نقص مُهرهای زمانی هم پنهان بماند. ممکن است روی دو رویداد هر دو زمان 10:00:00.000 ثبت شده باشد، اما در عمل به ترتیبی رخ داده باشند که شبیه‌ساز شما حدس زده است.
این موضوع هر وقت استراتژی به چیزی بیش از کندل‌های کامل‌شده واکنش نشان دهد اهمیت پیدا می‌کند: به‌روزرسانی مظنه، معامله، اعلان فاندینگ، تغییر وضعیت صرافی یا تأییدیهٔ سفارش خود استراتژی. مُهر زمانی می‌گوید رویداد چه زمانی برچسب خورده است؛ اما لزوماً نمی‌گوید استراتژی شما از چه زمانی می‌توانسته بر اساس آن عمل کند.
ترتیب رویدادها چه چیزی را تغییر می‌دهد؟
استراتژی‌ای را تصور کنید که وقتی بهترین قیمت فروش به زیر $100.00 می‌رسد، خرید می‌کند. در یک میلی‌ثانیهٔ یکسان، فید یک به‌روزرسانی قیمت فروش به $99.99 و یک معامله در $99.99 را ثبت می‌کند. اگر بک‌تست شما ابتدا معامله و بعد مظنه را پردازش کند، استراتژی قیمت فروش جدید را می‌بیند و سفارش می‌فرستد. پردازش مظنه در ابتدا هم می‌تواند درست باشد، به شرطی که رویداد واقعاً در دسترس بوده باشد. اما اگر معامله پیش از رسیدن سفارش، نقدینگی نمایش‌داده‌شده را مصرف کرده باشد، اجرا در $99.99 خیالی است.
مرتب‌سازی ردیف‌ها فقط بر اساس مُهر زمانی، انتخاب ترتیب رویدادهای هم‌زمان را به شبیه‌ساز واگذار می‌کند. ترتیب فایل، ترتیب نمادها یا برنامهٔ اجرای یک پرس‌وجوی پایگاه داده ممکن است ناخواسته به قاعده‌ای برای اجرا تبدیل شود. در این حالت منحنی بازده می‌تواند تغییر کند، بی‌آنکه دادهٔ زیربنایی تغییری کرده باشد.
برای دیدن اینکه این موضوع چقدر می‌تواند دل‌بخواهی باشد، رویدادهای هم‌زمان را بر اساس نام نماد مرتب کنید، نه ترتیب رسیدنشان. در این صورت رفتار یک استراتژی چنددارایی می‌تواند صرفاً به این دلیل فرق کند که نمادی در ترتیب الفبایی زودتر از نماد دیگر آمده است.
بک‌تست باید کدام ساعت‌ها را نگه دارد؟
داده‌های بازار و پردازش سفارش‌ها معمولاً چند زمان جداگانه دارند. فیلدهایی را که منبع داده در اختیارتان می‌گذارد حفظ کنید و معنای هرکدام را دقیق نام‌گذاری کنید. در بسیاری از فیدها، مُهر زمانی رویداد در صرافی و مُهر زمانی دریافت محلی هر دو مفیدند؛ هیچ‌کدام حقیقتی جهان‌شمول دربارهٔ چیزی که همهٔ مشارکت‌کنندگان دیده‌اند نیستند.
| ساعت | چه چیزی را ثبت می‌کند؟ | به‌تنهایی چه چیزی را ثابت نمی‌کند؟ |
|---|---|---|
| زمان رویداد در صرافی | زمانی که صرافی می‌گوید رویداد رخ داده است | ترتیبی که فید دیگری یا فرایند شما آن را دیده است |
| زمان دریافت | زمانی که گردآورندهٔ دادهٔ شما پیام را دریافت کرده است | زمانی که استراتژی شما پردازش آن را تمام کرده است |
| زمان تصمیم‌گیری | زمانی که کد شما سیگنال را ارزیابی کرده است | اینکه قیمت مظنه‌شده همچنان در دسترس بوده است |
| زمان رسیدن سفارش | زمانی که صرافی می‌توانسته سفارش را اجرا کند | انجام‌شدن معامله، مگر اینکه قواعد تطبیق و نقدینگی آن را ممکن کنند |
برای داده‌های تاریخی فاقد زمان دریافت، فرض خود را روشن بیان کنید. ممکن است بک‌تست رویدادهای صرافی را به ترتیب پردازش کند و از زمان تصمیم‌گیری تا رسیدن سفارش، تأخیری ثابت برابر با 5 ms در نظر بگیرد. این یک مدل است، نه تاریخچه‌ای که بازیابی شده باشد. اگر برای مُهرهای زمانی هم‌زمان در صرافی شمارهٔ ترتیب ندارید، قاعدهٔ رفع تساوی شما هم یک فرض است.
چطور رویدادهای هم‌زمان را مدل کنم؟
اول، شماره‌های ترتیب منبع را هرجا که وجود دارند حفظ کنید. شمارهٔ ترتیب، درون فید خودش ترتیب قوی‌تری از مُهر زمانی به دست می‌دهد؛ هرچند ممکن است فضاهای شماره‌گذاری در کانال‌ها یا محصولات مختلف جدا باشند.
بعد، قاعدهٔ پردازش شبیه‌ساز را شفاف کنید. برای هر رویداد تصمیم بگیرید که آیا می‌تواند اطلاعات در دسترس استراتژی را به‌روز کند، نقدینگی موجود را تغییر دهد، سفارشی را فعال کند یا سفارشی را تأیید کند. این‌ها کارهای متفاوتی هستند؛ یکی‌کردنشان در قالب «پردازش ردیف» راهی است که اجراهای ناممکن از آن به بک‌تست راه پیدا می‌کنند.
- فقط اطلاعات بازاری را اعمال کنید که تا زمان تصمیم‌گیری استراتژی رسیده باشد.
- سفارش را ایجاد کنید، سپس زمان را تا زمان رسیدن مدل‌شدهٔ آن به صرافی جلو ببرید.
- اجرا را فقط در برابر نقدینگی واجد شرایط پس از رسیدن سفارش مجاز بدانید و فرض‌های اجرا برای آن نوع سفارش را رعایت کنید.
- ورودی‌ها، ترتیب رویدادها و تأخیر به‌کاررفته را برای هر اجرای شبیه‌سازی‌شده ثبت کنید.
برای استراتژی مبتنی بر کندل، شاید این سازوکار بیش از چیزی باشد که پرسش به آن نیاز دارد. اگر سیگنال از کندل‌های کامل‌شدهٔ 1 دقیقه‌ای استفاده می‌کند و سفارش‌ها با یک مدل هزینهٔ محتاطانه در قیمت بازشدن کندل بعدی اجرا می‌شوند، احتمالاً ترتیب زیر میلی‌ثانیه نتیجهٔ پژوهش را تغییر نمی‌دهد. نکته این است که جزئیات زمان‌بندی با ادعایی که بک‌تست مطرح می‌کند تناسب داشته باشد.
بدون دادهٔ زمان رسیدن، می‌توانم به بک‌تست اعتماد کنم؟
هنوز هم می‌توانید از آن استفاده کنید، اما محدودیت را روشن نگه دارید. اگر استراتژی آهسته معامله می‌کند و حدود ریسک گسترده‌ای دارد، چند میلی‌ثانیه شاید بی‌اهمیت باشد. اما اگر به مظنه‌هایی که زود ناپدید می‌شوند واکنش نشان می‌دهد، برای جایگاه در صف رقابت می‌کند یا به سیگنال پیشتازی‌ـ‌تأخیری میان صرافی‌ها وابسته است، نبود زمان رسیدن ممکن است برای نتیجه تعیین‌کننده باشد.
منتقدان درست می‌گویند که زمان‌بندی دقیق رویدادها می‌تواند به دقت‌نمایی کاذب منجر شود. فیدهای تاریخی ناقص‌اند، ساعت‌ها از هم فاصله می‌گیرند و مُهرهای زمانی صرافی همهٔ گام‌های شبکه را آشکار نمی‌کنند. حتی شبیه‌سازی با فیلدهای نانوثانیه‌ای هم ممکن است فرضی خام دربارهٔ اجرا داشته باشد.
پس به‌جای ادعای قطعیت، حساسیت را بسنجید: بازپخش را با چند قاعدهٔ معقول برای تعیین ترتیب رویدادهای هم‌زمان و تأخیر سفارش انجام دهید، سپس تعداد معاملات، قیمت اجرا و سیگنال‌هایی را که باقی می‌مانند مقایسه کنید. اگر نتیجه به ترتیبی وابسته است که داده نمی‌تواند آن را اثبات کند، این وابستگی باید در گزارش پژوهش ذکر شود. بک‌تست با ساعتی ناقص هم می‌تواند مفید باشد؛ فقط باید بپذیرد که واقعاً چه زمانی را می‌داند.
← همهٔ مطالب
