داده‌های تیک بک‌تست شما را نجات نمی‌دهد — برای بیشتر استراتژی‌ها اوضاع را بدتر می‌کند

توصیه رایج این است: اگر بک‌تستی واقع‌بینانه می‌خواهید، داده‌های تیک تهیه کنید. به‌نظر من این توصیه برای بیشتر استراتژی‌ها اشتباه است و پیروی از آن معمولاً بک‌تست را بدتر می‌کند، نه بهتر. نه به این دلیل که داده‌های تیک دقیق نیستند — دقیق‌ترین داده‌ای هستند که می‌توانید به‌دست آورید — بلکه چون بیشتر افراد با استفاده از آن، تفکیک‌پذیری را جایگزین دقت و سخت‌گیری می‌کنند، درحالی‌که این دو یکی نیستند.

اینجا روندی است که به شکست می‌انجامد. پژوهشگری استراتژی‌ای بر پایه کندل‌های 1 دقیقه‌ای می‌سازد و به Sharpe دلخواهش می‌رسد. بعد کسی — راهنما، نوشته‌ای در انجمن یا تردید آزاردهنده خودش — می‌گوید بک‌تستش صادقانه نیست، چون بر پایه کندل‌هاست. پس کل خط پردازش را با داده‌های تیک از نو می‌سازد: هر معامله و هر به‌روزرسانی مظنه، با زمان‌مهر در حد میکروثانیه. بک‌تست کندتر می‌شود، کد سه برابر پیچیده‌تر می‌شود و Sharpe... به‌زحمت تغییر می‌کند یا در جهتی می‌رود که هیچ‌کس نمی‌تواند توضیحش دهد. بااین‌حال آن را منتشر می‌کنند، چون داده‌های تیک حس دقت و سخت‌گیری بیشتری می‌دهد؛ اما این حس با دقت و سخت‌گیری واقعی یکی نیست.

تفکیک‌پذیری تیک واقعاً چه چیزی به شما می‌دهد

داده‌های تیک توالی و قیمت هر معامله و (اگر هزینه‌اش را بپردازید) هر به‌روزرسانی دفتر سفارش را نشان می‌دهد. این اطلاعات واقعی است. با آن می‌توانید جایگاه در صف را بازسازی کنید، احتمال اجرا را در سطح قیمتی مشخص برآورد کنید و انتخاب نامطلوب را ببینید — اینکه آیا بازار درست پس از اجرای فرضی سفارش شما، برخلاف جهتتان حرکت می‌کند یا نه. همه این‌ها وقتی اهمیت زیادی دارند که دوره نگهداری‌تان چند ثانیه باشد و مزیتتان کسری از یک تیک.

اما بیشتر استراتژی‌هایی که در Stratmill می‌بینیم — و بیشتر استراتژی‌هایی که پژوهشگران خرد و نیمه‌حرفه‌ای واقعاً اجرا می‌کنند — موقعیت‌ها را از چند دقیقه تا چند روز نگه می‌دارند. در این افق، چیزی که تعیین می‌کند بک‌تستتان صادقانه است یا نه، این نیست که معامله شماره 40 در یک دقیقه مشخص را مدل کرده‌اید یا نه. مسئله این است که آیا اسپرد، نرخ فاندینگ، منحنی لغزش قیمت و این واقعیت را مدل کرده‌اید که سفارش محدود شما پشت سفارش‌های دیگران در صف قرار می‌گیرد یا نه. ممکن است هر چهار مورد را با داده‌های تیک اشتباه مدل کنید و با کندل‌های 1 دقیقه‌ای هر چهار را درست درآورید. تفکیک‌پذیری و صداقت به هم وابسته نیستند.

مورد آخر چیزی است که معمولاً اهمیتش را دست‌کم می‌گیرند. بک‌تست در سطح تیک صرفاً «همان بک‌تست با ردیف‌های بیشتر» نیست. معاملات در بیشتر صرافی‌ها نسبت به زمان دریافت داده‌هایتان خارج از ترتیب می‌رسند، بعداً اصلاح می‌شوند، بین چند بخش موتور تطبیق سفارش پخش می‌شوند و — در چند پلتفرمی که داده از آن‌ها دریافت کرده‌ایم — گاهی هنگام اتصال مجدد تکرار یا کاملاً حذف می‌شوند. ساخت خط پردازش تیکی که واقعاً از خط پردازش کندلیِ خوب‌ساخت دقیق‌تر باشد، نه فقط ریزتر، یک پروژه واقعیِ سامانه‌ای است. بیشتر تیم‌ها چنین پروژه‌ای را انجام نمی‌دهند. فایل تیک یک فروشنده را به بک‌تستر وصل می‌کنند و کار را تمام‌شده می‌دانند؛ یعنی مجموعه‌ای شناخته‌شده و مستند از تقریب‌ها (OHLCV) را با مجموعه‌ای ناشناخته و بی‌سند عوض کرده‌اند (هر کاری که منطق تطبیق داده‌های تیک فروشنده در یک روز بد انجام می‌دهد).

نویزی که بابتش هزینه می‌دهید

هزینه دومی هم وجود دارد که بیشتر آماری است تا مهندسی. ثبت قیمت معاملات منفرد بین قیمت خرید و فروش نوسان می‌کند — این همان جهش بین خرید و فروش است و از دهه 1980 در پژوهش‌های ریزساختار بازار به‌عنوان یک اثر جانبی شناخته شده است. اگر سیگنالتان سریع‌تر از چند ثانیه عمل می‌کند، بک‌تست در سطح تیک ممکن است باعث شود در چیزی ساختار ببینید که درواقع فقط همان جهش است. دیده‌ام پژوهشگری الگویی زیبا از بازگشت به میانگین در داده‌های معامله‌به‌معامله پیدا کند که به‌محض تجمیع داده‌ها حتی در کندل‌های 5 ثانیه‌ای ناپدید شود، چون آن الگو همان جهش بود.

یک معامله‌گر کمی که می‌شناسم — پیش‌تر بازارساز بوده و حالا دفتر کوچکی در بازار کریپتو دارد — این‌طور برایم توضیح داد: «داده‌های تیک مثل ذره‌بین‌اند. اگر آن را روی مزیتتان بگیرید، عالی است. اگر روی نویزتان بگیرید، شش ماه صرف مدل‌کردن زیبای نویزتان می‌کنید.» او حالا تقریباً همه‌چیز را با کندل‌های 1 ثانیه‌ای یا 1 دقیقه‌ای بک‌تست می‌کند و فقط برای پرسش مشخص «آیا این سفارش محدود واقعاً اجرا می‌شد؟» سراغ داده‌های تیک می‌رود؛ این پرسشی درباره احتمال اجراست، نه سیگنال.

این تفکیک رویکرد درستی است و بیشتر طرفداران داده‌های تیک از آن غافل می‌شوند. استفاده صادقانه از داده‌های تیک این نیست که کل استراتژی‌تان را با آن اجرا کنید؛ بلکه باید آن را هدفمند، برای یکی دو پرسشی به‌کار ببرید که داده‌های کندلی واقعاً نمی‌توانند پاسخ دهند.

مواردی که منتقدان حق دارند

بااین‌همه، استراتژی‌هایی هم هستند که در آن‌ها داده‌های تیک اختیاری نیست و اگر وانمود کنم غیر از این است، ادعایم را بیش از حد تعمیم داده‌ام. اگر کاری شبیه بازارسازی انجام می‌دهید — مظنه‌گذاری در هر دو سوی بازار، مدیریت موجودی در هر تیک و توجه به جایگاهتان در صف در یک سطح قیمتی مشخص — داده‌های کندلی اصلاً نمی‌توانند مسئله‌تان را بازنمایی کنند. تمام اقتصاد این استراتژی درون یک دقیقه جریان دارد، نه بین دقیقه‌ها. همین‌طور برای آربیتراژ آماری حساس به تأخیر بین پلتفرم‌ها، که پرسش دقیقاً این است که «کدام معامله اول انجام شد؟»، و برای بازارسازی اختیار معامله در حجم بالا، که چند صد میلی‌ثانیه انتخاب نامطلوب پس از ثبت قیمت، اصل ماجراست. در این شرایط، بک‌تست با کندل‌ها ساده‌سازی نیست؛ خطای مقوله‌ای است: نسخه‌ای کم‌تفکیک‌تر از استراتژی‌تان را نمی‌سنجید، بلکه استراتژی دیگری را می‌سنجید که فقط اتفاقاً نامش با استراتژی واقعی یکی است.

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