24 اوت 2026 · پژوهش

چرا بک‌تست من بیشتر از استراتژی آزمایشی‌ام معامله می‌کند؟

چرا بک‌تست من بیشتر از استراتژی آزمایشی‌ام معامله می‌کند؟

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

راهکار عملی این است که سفارش‌ها را با وضعیت‌ها و زمان‌مهرهایشان به‌صورت اشیای ماندگار نگه داریم. سیگنال دستوری برای تلاش جهت معامله است؛ مدرکی نیست که معامله‌ای انجام شده باشد.

چرا استراتژی آزمایشی من معاملات کمتری از بک‌تستم دارد؟

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

استراتژی‌ای را در نظر بگیرید که سفارش خرید محدود را روی $100 می‌گذارد و پس از 30 ثانیه لغو می‌کند. بازار قیمت $100.00 را ثبت می‌کند، اما حجم کمی در آن قیمت معامله می‌شود و سفارش‌های دیگر اولویت دارند. ممکن است بخشی از سفارش شما پر شود یا اصلاً پر نشود. بک‌تستی که فقط رسیدن قیمت را ملاک می‌گیرد، یک موقعیت کامل ثبت می‌کند. حساب آزمایشی که فرض‌های مربوط به صف را دنبال می‌کند، ممکن است هیچ پرشدنی ثبت نکند.

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

اگر سیگنال پیش از پرشدن سفارش تغییر کند، بک‌تست باید چه کند؟

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

این فرایند را به شکل دنباله‌ای مدل کنید: سیگنال تغییر می‌کند، استراتژی درخواست لغو می‌فرستد، محل معامله لغو را تأیید می‌کند یا پرشدن سفارش را گزارش می‌دهد و تازه بعد از آن استراتژی از وضعیت نهایی سفارش باخبر می‌شود. حتی یک تأخیر ثابت و ساده هم می‌تواند رقابت‌هایی را آشکار کند که بک‌تست با لغو فوری پنهان می‌کند.

برای مدلی که عمداً ساده نگه داشته شده، تأخیر 1 ثانیه‌ای در لغو و پردازش در رویداد بعدی می‌تواند از فرض لغو آنی آموزنده‌تر باشد. تأخیر مناسب به محل معامله و سیستم بستگی دارد؛ نکته این است که اصلاً تأخیری در نظر بگیریم. اگر سفارشتان سفارش بازار باشد و بازه‌ای برای لغو نداشته باشد، همین موضوع همچنان برای پرشدن‌های جزئی و گزارش‌های دیرهنگام اهمیت دارد.

شبیه‌ساز معاملات آزمایشی باید چه وضعیت‌هایی را برای سفارش ثبت کند؟

از یک ماشین حالت کوچک استفاده کنید و زمان هر گذار را نگه دارید. واژگان دقیق هر محل معامله متفاوت است، اما تمایزهای اصلی ثابت‌اند:

مقدار پرشده را جدا از مقدار درخواستی، همراه با قیمت‌های پرشدن و کارمزدها ثبت کنید. سفارش نیمه‌پرشده هم معامله‌ای انجام‌شده است و هم تعهدی فعال برای مقدار باقی‌مانده دارد. اگر آن را فقط باز یا فقط تمام‌شده در نظر بگیریم، اطلاعاتی را از دست می‌دهیم که استراتژی برای تعیین اندازهٔ اقدام بعدی به آن نیاز دارد.

رویداد سفارشآنچه استراتژی باید بداندمیان‌بر رایج بک‌تست
پرشدن جزئیمقدار اجراشده، مقدار باقی‌مانده، میانگین قیمتثبت کل سفارش به‌عنوان پرشده با یک قیمت
درخواست لغوزمان درخواست و تأیید نهایی لغو یا پرشدنحذف فوری سفارش
رد سفارشدلیل و اینکه تلاش مجدد معتبر است یا نهفرض کردن اینکه معاملهٔ درخواستی انجام شده است
انقضازمانی که سفارش دیگر واجد شرایط اجرا نبودباز نگه‌داشتن سفارش تا رسیدن قیمت در زمانی بعد

چطور معاملات بک‌تست را منصفانه با معاملات آزمایشی مقایسه کنم؟

اول رویدادهای سفارش، بعد موقعیت‌ها و در آخر P&L را مقایسه کنید. اگر بک‌تست سفارشی را پر کرده که حساب آزمایشی هرگز پر نکرده، اختلاف بعدی P&L پیامد آن است، نه نقطهٔ شروع برای پیدا کردن ایراد.

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

یک مثال کوچک توالی رویدادها را روشن می‌کند. سیگنال درخواست 10 واحد می‌دهد. هر دو سیستم در 10:00:00 سفارش می‌فرستند. بک‌تست فرض می‌کند سفارش در 10:00:01 کاملاً پر شده است. معاملات آزمایشی در 10:00:01 مقدار 4 واحد را پر می‌کند، در 10:00:02 درخواست لغو دریافت می‌کند و پیش از تأیید لغو در 10:00:03، پرشدن 2 واحد دیگر را گزارش می‌دهد. مقایسهٔ درست، 6 واحد پرشده در برابر 10 واحد است و 4 واحد لغوشده. میانگین گرفتن از همهٔ این موارد و ثبتشان به‌عنوان یک «معامله»، میزان مواجهه‌ای را پنهان می‌کند که استراتژی واقعاً داشته است.

برای درست انجام دادن این کار به شبیه‌ساز کامل صرافی نیاز دارم؟

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

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

یک نکتهٔ کوچکِ لذت‌بخش در این کار: گزارش خوب سفارش می‌تواند اختلافی را که در غیر این صورت گیج‌کننده است، به موضوعی ساده و روشن تبدیل کند. «سفارش فرزند دوم پس از درخواست لغو پر شد» از «معاملات آزمایشی عجیب به نظر می‌رسد» بهتر است. وقتی بک‌تست و حساب آزمایشی اختلاف دارند، پیش از دست‌کاری سیگنال، چرخهٔ عمر سفارش را دنبال کنید.

معاملات آزمایشی، مدیریت سفارش، بک‌تست، اجرا، پژوهش استراتژی
اشتراک‌گذاریXLinkedInFacebookRedditHacker NewsWhatsAppTelegramEmail
← همهٔ مطالب