مدیریت اخبار فارکس در MQL5 راهنمای مرجع برای ساخت زیرساخت News Guard (نه نیوزتریدینگ)

نویسنده: بهرنگ موسوی

نوشته شده در: بهمن 1404

خبر در الگوتریدینگ دقیقاً «چی هست» و «چی نیست»؟

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

خبر چیست؟

خبر یعنی بازه‌ای که رفتار بازار از حالت معمول خارج می‌شود و کیفیت اجرای معاملات افت می‌کند. این خروج از حالت معمول معمولاً خودش را با این علائم نشان می‌دهد:

• اسپرد ناگهان بزرگ می‌شود و عددی که همیشه ۱ تا ۲ پوینت بود، تبدیل می‌شود به چند برابر.
• اسلیپیج غیرقابل پیش‌بینی می‌شود: سفارش در قیمتی اجرا می‌شود که اصلاً انتظارش را نداری.
• گپ (Jump) رخ می‌دهد: قیمت بدون اینکه روی تک‌تک سطوح حرکت کند، یک‌باره از نقطه‌ای می‌پرد به نقطه‌ای دیگر.
• نقدشوندگی واقعی کم می‌شود: پر شدن سفارش‌ها سخت‌تر می‌شود یا با کیفیت بد انجام می‌شود.
• بعداً که چارت را نگاه می‌کنی، همه چیز «قشنگ‌تر» به نظر می‌رسد چون نمایش چارت واقعیت اجرای Bid/Ask و جهش‌های لحظه‌ای را کامل نشان نمی‌دهد یا ذهن تو آن را ساده‌سازی می‌کند.

پس خبر در نگاه الگوتریدر یعنی: “ریسک اجرای بد” + “عدم قطعیت بالا” + “رفتار غیرنرمال هزینه معامله”.

خبر چیست نیست؟

خبر «به خودی خود» سیگنال معاملاتی مطمئن نیست. این تصور که:

• Actual از Forecast بزرگ‌تر شد، پس باید خرید بزنم
• یا Actual بد شد، پس فروش بزنم
  برای معامله‌گر دستی شاید یک قمار کنترل‌نشده باشد، اما برای اکسپرت، اغلب یک تله است. چون اکسپرت با «اجرای سفارش» سر و کار دارد و اجرای سفارش در خبر معمولاً بدترین کیفیت خودش را نشان می‌دهد.

خبر همچنین جای «تست گرفتن از شانس» نیست. اگر سیستم تو بیرون از خبر هم سودده نیست، خبر قرار نیست معجزه کند. و اگر سیستم تو سودده هم باشد، خبر می‌تواند همان سود را با چند اجرای بد، نابود کند.

تفاوت News Trading با News Guard (Risk Gate)

برای اینکه اشتباه مسیر را از همین جا ببندی، این دو مفهوم را قاطی نکن:

۱) News Trading (معامله بر اساس خبر)
در این رویکرد، خبر خودش منبع سیگنال است. یعنی تو می‌خواهی از اختلاف Actual و Forecast جهت حرکت را پیش‌بینی کنی و سریع وارد شوی. مشکل اصلی اینجاست که حتی اگر جهت درست باشد، کیفیت اجرا می‌تواند کل ایده را خراب کند: اسپرد بالا، اسلیپیج شدید، پر نشدن سفارش، و حرکت‌های جهشی که استاپ و ورود را بی‌معنی می‌کند.

۲) News Guard / Risk Gate (دروازه ریسک برای خبر)
اینجا خبر «سیگنال نیست»، خبر «محدودیت است». هدف این رویکرد محافظت از سیستم است:

• نزدیک خبر معامله جدید باز نکن
• اگر پوزیشن باز داری، ریسک را کاهش بده
• در صورت نیاز، بخشی از پوزیشن را ببند یا ریسک‌فری کن
• قوانین کنترل اسپرد/اسلیپیج فعال شود
• در پنجره زمانی خبر، رفتار اکسپرت تغییر کند (حتی اگر استراتژی سیگنال‌دهی همان باشد)

اگر داری یک مقاله مرجع درباره مدیریت اخبار فارکس در MQL5 می‌نویسی، ستون اصلی باید روی News Guard باشد، چون این دقیقاً همان چیزی است که برای “اکسپرت واقعی” حیاتی است.

چرا «استاپ در لحظه خبر می‌خورد» ولی بعداً روی چارت «نخورده» دیده می‌شود؟

این یکی از پرتکرارترین سوءبرداشت‌هاست و اگر همین را درست نفهمی، باقی مسیر هم آلوده می‌شود.

واقعیت فنی ساده است:

• معاملات خرید با Ask باز می‌شوند و با Bid بسته می‌شوند.
• معاملات فروش با Bid باز می‌شوند و با Ask بسته می‌شوند.
• استاپ‌ها هم بر اساس همان سمت قیمت فعال می‌شوند.
• در خبر، اسپرد می‌تواند ناگهان بزرگ شود. یعنی فاصله Bid و Ask زیاد می‌شود، حتی اگر “وسط بازار” خیلی جا به جا نشده باشد.

حالا سناریو:
فرض کن خرید داری و استاپ‌لاس مشخصی گذاشتی. در لحظه خبر اسپرد می‌ترکد. Bid ممکن است پایین‌تر از چیزی که روی چارت “می‌بینی” بیاید و استاپ را فعال کند. بعد از چند ثانیه که شرایط عادی می‌شود، چارت روی تایم‌فریم معمولی تو آن جهش‌های لحظه‌ای و تغییرات ریز Bid/Ask را کامل نمایش نمی‌دهد یا تو فقط خط قیمت اصلی را می‌بینی. نتیجه؟ تو فکر می‌کنی «استاپ بی‌دلیل خورد» یا «کارگزاری زد»، در حالی که بخش بزرگی از ماجرا همان اسپرد/اسلیپیج و تفاوت Bid/Ask است.

پس اگر دنبال “حقیقت” هستی، باید این را بپذیری:
در خبر، چارت یک روایت ساده‌شده است؛ اجرای سفارش واقعیتِ خشن‌تر است.

نتیجه عملی این بخش: تو دنبال کدامی؟

الان باید یک تصمیم شفاف بگیری:

• اگر هدفت این است که با Actual/Forecast سیگنال بسازی و در لحظه ورود بزنی، تو وارد حوزه News Trading می‌شوی؛ ریسک این مسیر بالاست و وابستگی شدید به اجرای سفارش و کیفیت بروکر دارد.
• اگر هدفت این است که اکسپرتت در خبر «له نشود»، تو در مسیر درست هستی: News Guard یا Risk Gate. این مسیر یعنی طراحی استاندارد برای فیلتر خبر، پنجره زمانی قبل/بعد، قوانین مدیریت پوزیشن و کنترل اسپرد/اسلیپیج.

و اگر فقط یک جمله قرار باشد از این بخش یادت بماند، این است:
خبر برای الگوتریدر بیشتر «ریسک اجرا» است تا «فرصت سیگنال».

  مسئله واقعی شما با «خبر» چیست؟ (قبل از هر راه‌حل)

  بیشتر کسانی که «مدیریت اخبار» را سرچ می‌کنند، دقیقاً نمی‌دانند مشکل‌شان چیست. فقط یک علامت می‌بینند: یا اکسپرت در خبر خراب می‌کند، یا بک‌تست نتایج عجیب می‌دهد، یا نمی‌توانند تقویم را از داخل MQL5 بخوانند، یا بین لایو و تستر رفتار سیستم‌شان دو دنیا فرق دارد. اگر اول intent را مشخص نکنی، هر راه‌حلی که بسازی یا زیادی سنگین می‌شود یا اساساً غلط.

در این مقاله، همه چیز را به چهار سناریوی تصمیم‌پذیر تبدیل می‌کنیم تا دقیقاً بفهمی کدام مسیر برای توست و قرار است چه چیزی را “حل” کنی.

سناریو A: «اکسپرت در خبر نابود می‌شود»

این سناریو یعنی سیستم تو خارج از خبر شاید قابل قبول باشد، اما نزدیک خبر یا حین خبر این چیزها رخ می‌دهد:

• استاپ‌ها غیرعادی می‌خورند
• ورودها با قیمت‌های عجیب انجام می‌شوند
• اسپرد و اسلیپیج کل منطق مدیریت ریسک را می‌شکند
• معامله‌هایی فعال می‌شوند که در حالت عادی فعال نمی‌شدند

راه‌حل این سناریو «سیگنال بهتر» نیست. راه‌حل، ساخت News Guard است:

• فیلتر خبر (چه خبرهایی، با چه اهمیتی)
• پنجره زمانی قبل/بعد خبر
• قوانین کنترل اسپرد و اسلیپیج
• تغییر رفتار اکسپرت در زمان خبر (عدم ورود یا مدیریت پوزیشن)

مثال عملی کوتاه: اگر در ۱۵ دقیقه قبل و ۱۵ دقیقه بعد از خبرهای High Impact اجازه ورود ندهی، بخش بزرگی از خرابکاری‌های اجرا حذف می‌شود، بدون اینکه مجبور شوی استراتژی اصلی را عوض کنی.

سناریو B: «می‌خواهم خبر را بک‌تست کنم»

این سناریو معمولاً با یک انتظار خطرناک شروع می‌شود: اینکه بک‌تست اخبار قرار است مثل بک‌تست تکنیکال دقیق و قابل اتکا باشد. در حالی که در اخبار چند مشکل ذاتی وجود دارد:

• داده‌های Actual/Forecast ممکن است Revision داشته باشند
• زمان‌بندی‌ها و جزئیات رویدادها همیشه ثابت و بدون تغییر نیستند
• Strategy Tester همه واقعیت‌های اجرای سفارش در لحظه خبر را بازسازی نمی‌کند
• اختلاف لایو و تستر می‌تواند نتیجه را غیرواقعی کند

هدف درست در این سناریو این است که بک‌تست را برای «ارزیابی کنترل ریسک در خبر» استفاده کنی، نه برای اثبات سوددهی خبر.

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

سناریو C: «می‌خواهم تقویم متاتریدر را با کد بخوانم»

در این سناریو، مسئله تو معامله‌گری نیست؛ مسئله تو داده و API است. یعنی می‌خواهی از داخل MQL5 به تقویم اقتصادی دسترسی بگیری و آن را به ساختار قابل استفاده تبدیل کنی:

• Country: کشورها و مشخصاتشان
• Event: رویدادها (نام، ارز، اهمیت، زمان‌بندی)
• Value/History: مقادیر Previous/Forecast/Actual و تاریخچه آن‌ها

این مسیر برای کسانی مناسب است که می‌خواهند فیلتر خبری، گزارش‌گیری، یا لاگ‌سازی دقیق داشته باشند و به داده خام متکی‌اند، نه حدس.

مثال عملی کوتاه: اگر بتوانی Eventهای مربوط به یک ارز را استخراج کنی و فقط High Impactها را نگه داری، پایه فیلتر خبری استانداردت ساخته می‌شود.

سناریو D: «می‌خواهم سیستم‌ام در لایو و تستر رفتار یکسان‌تری داشته باشد»

اینجا مشکل اصلی دوگانگی محیط است. یعنی همان اکسپرت:

• در تستر “قابل تحمل” است
• در لایو نزدیک خبر “غیرقابل اعتماد” می‌شود
  یا بالعکس: در لایو منطقی است ولی در تستر نمی‌توانی رفتار خبر را درست بازسازی کنی.

راه‌حل این سناریو معمولاً ترکیبی است:

• ساخت دیتاست اخبار (مثلاً CSV از زمان رویدادها)
• پیاده‌سازی News Guard دوحالته: یک رفتار برای لایو (Calendar) و یک رفتار برای تستر (Dataset)
• اعتبارسنجی اینکه پنجره خبر و فیلترها در هر دو محیط یکسان عمل می‌کنند

مثال عملی کوتاه: اگر در تستر به جای Calendar مستقیم، از دیتاست زمان‌های خبر استفاده کنی، می‌توانی منطق “پرهیز از خبر” را پایدارتر و قابل تست‌تر کنی.

جمع‌بندی انتخاب مسیر

اگر مشکل تو “اجرای بد در خبر” است، سناریو A مسیر اصلی توست.
اگر دنبال “تست‌پذیری” و واقع‌بینی درباره محدودیت‌ها هستی، سناریو B و D مهم می‌شوند.
اگر مسئله‌ات “دسترسی برنامه‌نویسی به تقویم” است، سناریو C نقطه شروع توست.

مبانی تقویم اقتصادی در متاتریدر ۵ برای برنامه‌نویس‌ها

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

تقویم اقتصادی از چه لایه‌هایی تشکیل شده است؟

ساختار داده‌ای تقویم اقتصادی را می‌توان خیلی ساده در سه لایه دید:

1. کشور (Country)
   کشور فقط «اسم کشور» نیست. کشور معمولاً با مشخصاتی مثل شناسه، نام، کدها و وابستگی‌های مرتبط تعریف می‌شود. این لایه کمک می‌کند بفهمی رویدادها به چه حوزه‌ای تعلق دارند و در بعضی موارد برای فیلترهای سطح بالا استفاده می‌شود.
2. رویداد (Event)
   رویداد همان چیزی است که کاربر در تقویم می‌بیند: مثلاً CPI، نرخ بهره، NFP و… . در سطح برنامه‌نویسی، رویداد یک موجودیت است با ویژگی‌های مهمی مثل:

• ارز مرتبط (Currency)
• اهمیت یا شدت اثر (Importance/Impact)
• زمان‌بندی انتشار (Time)
• کد/شناسه رویداد (برای ردیابی و فیلتر)

1. مقدار و تاریخچه مقدار (Value / Value History)
   این همان بخشی است که بیشتر افراد با آن اشتباه می‌کنند. رویداد به تنهایی کافی نیست؛ چون چیزی که در لحظه خبر معنی می‌دهد «مقدارها» هستند:

• Previous (قبلی)
• Forecast (پیش‌بینی)
• Actual (واقعی)
  و نکته مهم‌تر: این مقدارها می‌توانند تاریخچه داشته باشند و حتی در برخی رویدادها اصلاح شوند (Revision). یعنی ممکن است بعد از انتشار، بعضی مقدارها بازنگری شوند و این برای بک‌تست و تحلیل حساس است.

پس اگر خلاصه بخواهیم بگوییم:
Country به تو می‌گوید «این داده متعلق به کجاست»، Event به تو می‌گوید «چه خبری است»، و Value History به تو می‌گوید «در آن خبر چه عددهایی ثبت شده و چه تغییرهایی داشته‌اند».

اجزای کلیدی هر خبر که باید بشناسی

برای مدیریت اخبار در سطح برنامه‌نویسی، این فیلدها معمولاً ستون فقرات تصمیم‌گیری هستند:

• ارز (Currency): چون بیشتر تصمیم‌ها در فارکس روی ارز و نماد می‌چرخد.
• اهمیت (Importance/Impact): چون همه خبرها ارزش یکسان ندارند.
• زمان انتشار (Time): چون طراحی پنجره قبل/بعد خبر دقیقاً به این وابسته است.
• Previous / Forecast / Actual: چون پایه تحلیل داده‌ای خبر همین‌هاست، حتی اگر هدف تو سیگنال نباشد.
• Revision: چون اگر داده اصلاح شود، بک‌تست و گزارش‌گیری می‌تواند منحرف شود.

این‌ها حداقل‌هایی هستند که بدون دانستن‌شان، ساخت فیلتر خبر یا News Guard عملاً کورکورانه می‌شود.

مثال کوتاه برای فهم مدل داده

فرض کن رویداد «CPI آمریکا» را داریم.

• در لایه Event: “CPI آمریکا” یک رویداد است با ویژگی‌هایی مثل:
  • Currency: USD
  • Importance: معمولاً High
  • Time: زمان دقیق انتشار
• در لایه Value History: برای همین رویداد، در تاریخ‌های مختلف مقدارهای ثبت‌شده وجود دارد:
  • Previous: مقدار ماه قبل
  • Forecast: پیش‌بینی تحلیل‌گران
  • Actual: عدد واقعی منتشرشده
  • Revision: اگر عدد قبلی یا حتی عدد منتشرشده بعداً اصلاح شده باشد

این مثال نشان می‌دهد چرا فقط دانستن “اسم خبر” کافی نیست. برای پیاده‌سازی درست، باید بدانی رویداد چیست و مقدارهایش کجا و چگونه ذخیره می‌شوند.

این بخش چه تصمیمی را برای شما ساده می‌کند؟

بعد از این بخش باید بتوانی پاسخ بدهی که دقیقاً دنبال کدام سطح داده هستی:

• فقط می‌خواهم زمان خبر و اهمیتش را داشته باشم تا وارد معامله نشوم.
• می‌خواهم علاوه بر زمان، نوع خبر و ارز مرتبط را برای فیلتر دقیق‌تر داشته باشم.
• می‌خواهم مقدارهای Previous/Forecast/Actual و Revision را هم بخوانم تا لاگ دقیق یا تحلیل داشته باشم.
• می‌خواهم برای تستر و بک‌تست به سراغ Value History و حتی دیتاست بروم.

وقتی این تصمیم روشن شد، هم کدنویسی ساده‌تر می‌شود، هم انتظار تو از تقویم واقعی‌تر.

ستون فقرات فنی: خواندن Calendar با MQL5 (از ساده تا قابل استفاده)

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

Country و Event را چطور می‌گیریم؟

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

۱) گرفتن Country
در سطح Country معمولاً با این دو سر و کار داری:

• CalendarCountry
• ساختار MqlCalendarCountry

هدف این مرحله بیشتر این است که بتوانی کشورها را بشناسی و اگر لازم شد رویدادها را بر اساس کشور یا ویژگی‌های کشور محدود کنی. در بسیاری از پروژه‌ها ممکن است مستقیم به Currency و Event بروی، اما شناخت Country برای ساختاردهی و توسعه در آینده مفید است.

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

۲) گرفتن Event
رویدادها را می‌توانی از چند مسیر استخراج کنی، بسته به اینکه ورودی فیلتر تو چیست:

• CalendarEventByCountry
• CalendarEventByCurrency
• CalendarEventById
• ساختار MqlCalendarEvent

انتخاب روش درست کاملاً به نیاز تو بستگی دارد:

• اگر مسیر تو «کشور محور» است، از ByCountry استفاده می‌کنی.
• اگر برایت «ارز محور» مهم است (که در فارکس اغلب همین است)، ByCurrency منطقی‌تر است.
• اگر قبلاً شناسه یک رویداد را ذخیره کرده‌ای و می‌خواهی دقیقاً همان را واکشی کنی، ById مناسب است.

مثال کوتاه: برای ساخت یک News Guard که فقط روی USD حساس باشد، معمولاً ByCurrency بهترین نقطه شروع است چون از همان ابتدا داده را کوچک و مرتبط نگه می‌داری.

کلمات کلیدی مرتبط مناسب این بخش: تقویم اقتصادی MQL5، CalendarEvent MQL5، CalendarValue MQL5

نمونه‌کدهای تمیز CalendarEvent/CalendarCountry در MQL5 (با خطاگیری استاندارد)

Value History: Previous/Forecast/Actual و تله‌های Revision/Scale

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

۱) گرفتن Value History
برای مقدارها معمولاً این دو تابع/مسیر را می‌بینی:

• CalendarValueHistory
• CalendarValueHistoryByEvent

اگر می‌خواهی تاریخچه مقدارهای یک رویداد را داشته باشی، ByEvent معمولاً انتخاب طبیعی‌تری است چون از رویداد به مقدارها می‌رسی و داده‌های پرت کم می‌شود.

مثال کوتاه: اگر رویداد CPI آمریکا را داری، با ValueHistoryByEvent می‌توانی رکوردهای ماه‌های قبل و مقادیر Previous/Forecast/Actual را واکشی کنی.

۲) تله “Actual = 0” و چرا صفر معنی ندارد
یکی از اشتباهات رایج این است که افراد برای تشخیص «وجود داشتن Actual» چک می‌کنند که مقدار Actual صفر است یا نه. این روش غلط است، چون:

• ممکن است هنوز Actual منتشر نشده باشد و مقدار پیش‌فرض صفر باشد
• ممکن است مقدار واقعی در برخی داده‌ها صفر یا نزدیک صفر باشد
• ممکن است منطق تو با یک صفر اشتباه، کل سیستم را منحرف کند

راه درست این است که به جای حدس، از منطق “وجود داشتن مقدار” استفاده کنی:

• hasActualValue
• getActualValue

مثال کوتاه: اگر hasActualValue نداشته باشی و صرفاً Actual را بخوانی، ممکن است قبل از انتشار خبر هم عددی ببینی و فکر کنی منتشر شده، در حالی که سیستم فقط مقدار پیش‌فرض را برگردانده است.

۳) Revision و revised_previous_value
بخش خطرناک‌تر: داده‌های خبری همیشه یک‌بار برای همیشه ثابت نمی‌مانند. گاهی مقدارهای قبلی یا حتی بعضی گزارش‌ها بعداً اصلاح می‌شوند. این یعنی:

• اگر بک‌تست می‌کنی، ممکن است امروز یک مقدار ببینی و فردا همان تاریخ مقدار اصلاح‌شده داشته باشد
• اگر تحلیل می‌کنی، باید تفاوت “previous” با “revised_previous_value” را بفهمی
• اگر گزارش‌گیری می‌کنی، باید بدانـی کدام نسخه را ثبت کرده‌ای

مثال کوتاه: اگر در بک‌تست بر اساس previous تصمیم می‌گیری، ولی در لایو revised_previous_value مبنا می‌شود، نتیجه‌ها می‌توانند از هم جدا شوند و تو فکر می‌کنی «تستر دروغ می‌گوید» در حالی که مسئله تغییر داده است.

۴) مقیاس‌دهی عددی و خطای رایج نمایش/مقایسه
خیلی از داده‌های اقتصادی مقیاس دارند. یعنی عددی که می‌بینی ممکن است نماینده یک مقدار مقیاس‌خورده باشد (مثلاً میلیون، میلیارد، درصد، یا واحدهای خاص). اگر این را نفهمی:

• مقایسه Previous/Forecast/Actual غلط می‌شود
• نمایش عدد در لاگ یا پنل اکسپرت اشتباه می‌شود
• نتیجه می‌گیری خبر “خیلی بزرگ” یا “خیلی کوچک” بوده، در حالی که فقط مقیاس را نفهمیده‌ای

مثال کوتاه: اگر مقدارها را خام چاپ کنی و با هم مقایسه کنی، ممکن است به خاطر ×10^6 یا تفاوت واحد، اختلاف ظاهری بزرگ شود و فیلتر تو بی‌دلیل فعال گردد.

طراحی «News Guard» به زبان آدمیزاد: ریسک‌گیت یعنی چه تصمیم‌هایی؟

News Guard یعنی اینکه خبر را «سیگنال» نبینی، بلکه آن را یک «دروازه ریسک» بدانی. دروازه ریسک یعنی یک بازه زمانی مشخص که در آن، قوانین عادی معامله‌گری را موقتاً تغییر می‌دهی تا سیستم‌ات از رفتار غیرنرمال بازار آسیب نبیند. اینجا قرار نیست استراتژی بسازی یا جهت بازار را حدس بزنی؛ قرار است تصمیم‌های استاندارد و قابل تکرار تعریف کنی.

هدف این بخش این است که چارچوب تصمیم‌گیری تو را استاندارد کند:

• قبل از خبر چه کار می‌کنی؟
• در لحظه خبر چه کار می‌کنی؟
• بعد از خبر چه کار می‌کنی؟
  و برای هر کدام، دو حالت را پوشش دهد:
• وقتی پوزیشن نداری
• وقتی پوزیشن داری

News Guard چه تصمیم‌هایی شامل می‌شود؟

News Guard یک مجموعه تصمیم محدود و مشخص است. اگر تصمیم‌هایت مبهم و سلیقه‌ای باشد، نتیجه‌اش هم مبهم و غیرقابل تست می‌شود. تصمیم‌های رایج و استاندارد این‌ها هستند:

• عدم ورود (No Trade): در پنجره خبر هیچ معامله جدیدی باز نشود.
• کاهش حجم: اگر ورود لازم است، با حجم کمتر انجام شود.
• ریسک‌فری (Breakeven): ریسک پوزیشن‌های باز کم شود یا به نقطه سربه‌سر منتقل شود.
• بستن بخشی: بخشی از پوزیشن بسته شود تا مواجهه با ریسک کاهش یابد.
• بستن کامل: تمام پوزیشن‌ها بسته شوند و سیستم وارد حالت محافظه‌کار شود.

نکته مهم: لازم نیست همه این تصمیم‌ها را همزمان داشته باشی. اما باید دقیق بدانی کدام را انتخاب کرده‌ای و چرا.

مثال عملی کوتاه: اگر هدف تو «ضدگلوله کردن اکسپرت» است، معمولاً ترکیب “عدم ورود” برای معاملات جدید + “کنترل ریسک” برای پوزیشن‌های باز (مثل ریسک‌فری یا بستن بخشی) کافی و قابل دفاع است.

پنجره زمانی خبر یعنی چه و چرا باید تعریف شود؟

خبر فقط یک نقطه زمانی نیست. اثر عملی خبر معمولاً قبل از انتشار شروع می‌شود و بعد از انتشار هم مدتی ادامه دارد. بنابراین News Guard باید یک «پنجره زمانی» داشته باشد:

• قبل از خبر: زمانی که بازار شروع به غیرنرمال شدن می‌کند (افزایش اسپرد، کم شدن کیفیت اجرا، حرکت‌های پیش‌دستانه)
• بعد از خبر: زمانی که بازار هنوز ناپایدار است (جهش‌ها، برگشت‌های سریع، پرش‌های قیمتی)

تعریف پنجره یعنی اینکه تو برای هر خبر، یک بازه “شروع تا پایان” داشته باشی و تصمیم‌ها فقط در همان بازه اعمال شوند. بدون پنجره، یا زیادی محافظه‌کار می‌شوی و فرصت‌های عادی را از دست می‌دهی، یا خیلی دیر واکنش می‌دهی و هدف محافظت از بین می‌رود.

مثال عملی کوتاه: یک پنجره ساده مثل ۱۵ دقیقه قبل و ۱۵ دقیقه بعد برای خبرهای مهم، می‌تواند بخش بزرگی از آسیب‌های رایج را حذف کند، بدون اینکه سیستم را دائماً قفل کند.

چک دوره‌ای یعنی چه؟ (بدون ورود به کدنویسی)

News Guard با یک بار نگاه کردن به ساعت کار نمی‌کند. باید «مرتب بررسی» شود که آیا الان داخل پنجره خبر هستیم یا نه. این بررسی دوره‌ای می‌تواند با دو منطق رایج انجام شود:

• بررسی در بازه‌های زمانی کوتاه و ثابت
• بررسی روی تغییرات منطقی بازار (مثلاً با هر کندل جدید)

اینجا نکته مهم این است: بررسی باید به اندازه کافی منظم باشد که ورودهای ناخواسته در پنجره خبر اتفاق نیفتد، اما آنقدر هم سنگین نباشد که سیستم را کند یا پرهزینه کند.

مثال عملی کوتاه: اگر فقط ابتدای روز پنجره خبر را محاسبه کنی ولی در طول روز بررسی نداشته باشی، News Guard در عمل «فراموش می‌شود» و دقیقاً زمانی که باید محافظت کند، بی‌اثر می‌شود.

فیلتر خبر: همه خبرها ارزش یکسان ندارند

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

فیلتر خبر معمولاً بر اساس این معیارها تعریف می‌شود:

• اهمیت یا شدت اثر (Importance/Impact): فقط خبرهای مهم یا خیلی مهم
• نوع اثر یا دسته‌بندی (ImpactType): اگر سیستم تو به بعضی نوع خبرها حساس‌تر است
• وایت‌لیست (Whitelist): فقط مجموعه‌ای از رویدادهای مشخص که برایت مهم‌اند
• بلک‌لیست (Blacklist): حذف رویدادهایی که می‌دانی برایت دردسرسازند یا بی‌ربط‌اند
• کد رویداد (Event Code): چون نام خبر می‌تواند در منابع مختلف کمی متفاوت باشد، اما کد رویداد برای فیلتر دقیق‌تر استفاده می‌شود

مثال عملی کوتاه: اگر فقط روی USD معامله می‌کنی، وایت‌لیست تو می‌تواند شامل چند خبر فوق‌حساس مثل CPI، نرخ بهره و NFP باشد و باقی را نادیده بگیرد. نتیجه: News Guard هوشمندانه‌تر و کم‌مزاحمت‌تر عمل می‌کند.

حالت بدون پوزیشن vs حالت با پوزیشن (این را قاطی نکن)

بزرگ‌ترین اشتباه در طراحی News Guard این است که برای هر دو حالت یک تصمیم واحد بگذاری.

• وقتی پوزیشن نداری: ساده‌ترین و امن‌ترین تصمیم معمولاً «عدم ورود» است.
• وقتی پوزیشن داری: تصمیم‌ها باید حول «کاهش ریسک» بچرخند، نه توقف کامل سیستم. چون بستن کورکورانه می‌تواند هزینه‌زا باشد، ولی بی‌توجهی هم می‌تواند نابودکننده باشد.

مثال عملی کوتاه: ممکن است برای پوزیشن‌های باز تصمیم بگیری در پنجره خبر فقط ریسک را کم کنی (مثل ریسک‌فری یا بستن بخشی) ولی برای ورود جدید کاملاً ممنوعیت داشته باشی.

زمان و هماهنگی: مشکل واقعی «TimeCurrent» و زمان خبر

اگر قرار است فیلتر خبر یا News Guard بسازی، بزرگ‌ترین دام همین‌جاست: زمان. چون اگر مبنای زمان را اشتباه انتخاب کنی، همه چیز “ظاهراً درست” به نظر می‌رسد ولی در عمل پنجره خبرت جابه‌جا اجرا می‌شود. نتیجه هم معمولاً این است که فکر می‌کنی فیلتر خبر خراب است، در حالی که مشکل از منطق زمان‌بندی است.

تفاوت TimeCurrent و LocalTime دقیقاً چیست؟

برای ساده‌سازی، دو زمان داریم که آدم‌ها قاطی می‌کنند:

• TimeCurrent: زمانی که از دید ترمینال/سرور معاملاتی معنی دارد و رفتار اجرای معاملات و داده‌های بازار به آن وابسته است. این زمان معمولاً همان چیزی است که برای تصمیم‌های معاملاتی و هماهنگی با محیط متاتریدر باید جدی بگیری.
• LocalTime: زمان سیستم عامل یا زمان محلی کامپیوتر تو. این زمان برای راحتی انسان خوب است، اما برای تصمیم‌گیری معاملاتی می‌تواند خطرناک باشد چون ممکن است با زمان سرور تفاوت داشته باشد.

مشکل از اینجا شروع می‌شود که «زمان خبر» هم باید با یک مبنا مقایسه شود. اگر زمان خبر را بر اساس یک مبنا بگیری و بعد آن را با زمان دیگری مقایسه کنی، پنجره خبرت عملاً غلط می‌شود.

مبنای مقایسه زمان خبر چیست؟

قانون ساده‌ای که اگر رعایت نکنی، دیر یا زود سیستم‌ات را خراب می‌کند:

• زمان خبر و زمان تصمیم‌گیری باید در یک “سیستم زمانی” باشند.

یعنی یا همه چیز را بر اساس زمان سرور/ترمینال می‌سنجی، یا اگر مجبور شدی زمان محلی را وارد کنی، باید قبلش آن را دقیق به مبنای قابل مقایسه تبدیل کنی.

در عمل برای News Guard، مهم این است که تصمیم‌های “عدم ورود/تغییر رفتار” دقیقاً در همان بازه‌ای فعال شوند که بازار واقعاً وارد شرایط غیرنرمال می‌شود. این با زمان محلیِ کامپیوتر تضمین نمی‌شود، اما با زمان ترمینال/سرور قابل اتکاتر است.

مثال کوتاه: چرا پنجره خبر جابه‌جا می‌شود و فکر می‌کنی «کد کار نمی‌کند»؟

فرض کن می‌گویی:

• ۱۵ دقیقه قبل و ۱۵ دقیقه بعد از خبرهای مهم معامله نکن.

حالا اگر:

• زمان خبر را بر اساس یک مبنا در نظر گرفته باشی
• ولی زمان فعلی را با مبنای دیگری بسنجی

چه می‌شود؟
پنجره تو ممکن است:

• زودتر از موعد فعال شود و بی‌دلیل جلوی معاملات عادی را بگیرد
• یا دیرتر فعال شود و دقیقاً لحظه خبر را از دست بدهد
• یا حتی در بعضی روزها درست و در بعضی روزها غلط عمل کند

در این وضعیت، تو لاگ را نگاه می‌کنی و می‌بینی فیلتر خبر “گاهی کار می‌کند، گاهی نه” و سریع نتیجه می‌گیری مشکل از کدنویسی است. در حالی که مشکل از این است که زمان‌ها با هم هم‌مبنا نیستند.

نتیجه عملی این بخش

اگر News Guard را جدی می‌سازی، باید از همین ابتدا این استاندارد را برای خودت قطعی کنی:

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

چرا بک‌تست اخبار «همیشه» مسئله دارد؟ (و چطور آسیبش را کم کنیم)

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

• اگر هدف تو «اثبات سوددهی با خبر» است، احتمال اینکه خودت را گول بزنی بالاست.
• اگر هدف تو «کاهش آسیب خبر» و «کنترل ریسک در پنجره خبر» است، بک‌تست می‌تواند مفید باشد.

این تفاوت هدف، همه چیز را تعیین می‌کند: معیارها، روش تست، و اینکه چه نتیجه‌ای را معتبر می‌دانی.

مسئله اول: داده‌های خبری ناپایدارند (Revision و تغییر Forecast)

برخلاف قیمت که معمولاً یک سری داده‌ی تاریخی نسبتاً ثابت دارد، داده‌های خبر می‌توانند تغییر کنند:

• Revision: مقدارهای منتشرشده یا مقدارهای قبلی ممکن است بعداً اصلاح شوند.
• Forecast ممکن است قبل از انتشار تغییر کند (در بعضی منابع و سناریوها).
• حتی زمان‌بندی بعضی رویدادها می‌تواند جابه‌جا شود یا با تاخیر ثبت شود.

نتیجه: ممکن است امروز بک‌تست بگیری و “یک تاریخچه” ببینی، و چند وقت بعد همان دوره زمانی را دوباره بررسی کنی و دیتای خبر کمی فرق کرده باشد. این یعنی بک‌تست خبری می‌تواند به شکل خطرناکی «غیرقابل تکرار» شود.

مثال عملی کوتاه: اگر منطق تو روی اختلاف Forecast و Actual بنا شده باشد، تغییر Forecast قبل از انتشار یا اصلاح Previous می‌تواند باعث شود در بک‌تست یک سری معامله‌ها “فعال” شوند ولی در واقعیت تاریخیِ اصلاح‌شده یا در اجرای واقعی چنین سیگنالی رخ نداده باشد.

مسئله دوم: تفاوت لایو و تستر فقط عدد نیست، «رفتار» است

حتی اگر داده خبر را درست هم داشته باشی، بک‌تست یک مشکل ساختاری دیگر دارد: کیفیت اجرای معاملات در خبر.

در لایو، در زمان خبر ممکن است این اتفاق‌ها بیفتد:

• اسپرد جهشی
• اسلیپیج شدید
• پر شدن ناقص یا بد
• حرکت‌های تند که به قیمت‌های “بین راه” فرصت نمی‌دهد

اما تستر معمولاً این واقعیت را یا ساده می‌کند یا کامل بازسازی نمی‌کند. بنابراین بک‌تست خبری می‌تواند یک تصویر تمیز و خوشگل بدهد، در حالی که اجرای واقعی در همان شرایط، چیز دیگری است.

مثال عملی کوتاه: در بک‌تست می‌بینی استاپ منطقی عمل کرده و خروج دقیق بوده، اما در لایو همان نقطه می‌تواند با اسپرد لحظه‌ای فعال شود یا با اسلیپیج چندین پوینت بدتر پر شود. نتیجه: بک‌تست تو «از نظر منطق درست» است، ولی از نظر اجرا «غیرواقعی».

نتیجه مهم: بک‌تست خبر را برای «سیگنال» می‌خواهی یا برای «کنترل ریسک»؟

اینجا باید صریح باشیم:

• بک‌تست برای سوددهی خبر: یعنی می‌خواهی از خبر سیگنال بگیری و با بک‌تست ثابت کنی که این کار جواب می‌دهد. اینجا احتمال توهم بالاست، چون داده ناپایدار است و اجرا شبیه‌سازی کامل نمی‌شود.
• بک‌تست برای کنترل ریسک: یعنی می‌خواهی نشان بدهی اگر در پنجره خبر معامله نکنی یا رفتار سیستم را تغییر بدهی، چه مقدار از ضررها/هزینه‌ها کم می‌شود. اینجا بک‌تست می‌تواند واقعاً کاربردی باشد، چون دنبال “پیش‌بینی جهت” نیستی، دنبال “کاهش مواجهه” هستی.

چطور آسیب بک‌تست خبر را کم کنیم؟ (رویکرد News Avoidance)

مطمئن‌ترین راه برای استفاده مفید از بک‌تست خبر این است که تمرکز را از «گرفتن حرکت خبر» برداری و ببری روی «اجتناب از خبر» یا همان News Avoidance:

• به جای اینکه بک‌تست را روی ورودهای لحظه انتشار بنا کنی، آن را روی ممنوعیت ورود در پنجره خبر بنا کن.
• به جای اینکه دنبال سودهای انفجاری باشی، دنبال کاهش ضررهای ناگهانی و کاهش هزینه‌های اجرای بد باش.
• معیار موفقیت را تغییر بده: کمتر شدن Drawdownهای غیرعادی، کمتر شدن معامله‌های “بی‌کیفیت”، پایدارتر شدن نتایج.

برای نزدیک‌سازی رفتار تست به لایو هم باید اصل را این بگذاری که تستر یک «محیط ناقص» است. پس هدف تو باید این باشد که منطق News Guard در تستر هم قابل بررسی و قابل تکرار باشد، نه اینکه اجرای خبر را دقیقاً شبیه لایو کپی کند.

مثال عملی کوتاه: اگر در بک‌تست فقط بررسی کنی که در پنجره خبر معامله جدید باز نشده و مدیریت ریسک روی پوزیشن‌های باز فعال شده، نتیجه‌ات قابل دفاع‌تر و پایدارتر از این است که بخواهی با Actual/Forecast سودسازی را ثابت کنی.

دیتاست اخبار برای Strategy Tester: وقتی Calendar کافی نیست

تقویم اقتصادی داخلی متاتریدر برای خیلی از کارها کافی است، اما نه همیشه. مخصوصاً وقتی پای Strategy Tester وسط می‌آید، یک مشکل عملی ظاهر می‌شود: تو می‌خواهی رفتار News Guard را در تستر «قابل تکرار و قابل اعتماد» بررسی کنی، اما داده‌ها و شرایط تقویم در تستر ممکن است دقیقاً مثل لایو در دسترس نباشد یا به شکلی عمل نکند که برای تست‌های سیستماتیک مناسب باشد. اینجاست که دیتاست اخبار معنی پیدا می‌کند.

هدف این بخش این است که بفهمی:

• چه زمانی دیتاست لازم است،
• دیتاست چه ویژگی‌هایی باید داشته باشد،
• در تستر دقیقاً چطور از آن استفاده می‌شود (در سطح مفهومی، نه کدنویسی)،
• و چه اعتبارسنجی‌هایی لازم است تا مطمئن شوی دیتاست و فیلترها واقعاً درست کار می‌کنند.

چه زمانی Calendar کافی نیست و باید دیتاست بسازی؟

دیتاست وقتی لازم می‌شود که یکی از این نیازها را داشته باشی:

• می‌خواهی تست‌ها تکرارپذیر باشند و به تغییرات احتمالی تقویم یا شرایط لحظه‌ای وابسته نباشند.
• می‌خواهی در Strategy Tester دقیقاً همان پنجره‌های خبری را که در لایو داری، شبیه‌سازی کنی.
• می‌خواهی یک بار رویدادها را استخراج و استاندارد کنی و بعد در تست‌های متعدد، فقط از همان فایل ثابت استفاده کنی.
• می‌خواهی فیلترها و بلک‌لیست‌ها را مستقل از منبع تقویم، روی یک داده پایدار تست کنی.

در یک جمله: دیتاست یعنی “ثابت کردن زمین بازی” تا بتوانی منطق News Guard را دقیق‌تر ارزیابی کنی.

ساخت Discovery برای نام‌گذاری خبر بروکر

قبل از هر دیتاستی، یک مرحله حیاتی وجود دارد که خیلی‌ها از آن فرار می‌کنند: Discovery.

Discovery یعنی فهمیدن اینکه:

• بروکر تو رویدادها را با چه نام/کدی نشان می‌دهد،
• کدام رویدادها واقعاً در عمل برای نمادهای تو مهم‌اند،
• و چطور باید یک شناسه پایدار بسازی که بعداً بتوانی فیلترهای وایت‌لیست/بلک‌لیست را روی آن اعمال کنی.

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

مثال عملی کوتاه: ممکن است یک خبر مثل CPI در منابع مختلف با نام‌های متفاوت نمایش داده شود. Discovery کمک می‌کند تو یک مبنای استاندارد برای تشخیص و فیلتر آن بسازی، نه اینکه صرفاً به متن نمایشی تکیه کنی.

خروجی CSV: دیتاست باید چه شکلی باشد؟

مهم‌ترین ویژگی دیتاست خبری برای تستر این است که ساده، مرتب و قابل فیلتر باشد. خروجی رایج و کاربردی معمولاً CSV است، با این اصول:

• مرتب‌سازی زمانی (Sorted by Time): تا پردازش و تست پنجره خبر دقیق باشد.
• نگهداری فیلدهای حداقلی ولی ضروری:
  • زمان رویداد
  • ارز مرتبط
  • اهمیت (Impact)
  • شناسه/کد رویداد
  • نام نمایشی (اختیاری، برای گزارش)
• امکان اعمال Blacklist/Whitelist:
  • یا با ستون مستقل
  • یا با کد رویداد که بعداً بتوانی آن را فیلتر کنی

ایده این نیست که CSV را تبدیل به “پایگاه داده عظیم” کنی. هدف این است که برای Strategy Tester یک ورودی پایدار داشته باشی که بتوانی سریع و بدون ابهام روی آن تصمیم بگیری.

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

بارگذاری دیتاست در تستر و فیلتر رکوردهای مرتبط (مفهومی)

در Strategy Tester، دیتاست نقش «مرجع زمان‌های خبر» را بازی می‌کند. یعنی سیستم تو به جای اینکه هر بار از Calendar داده بگیرد، می‌تواند از فایل ثابت بخواند و تشخیص بدهد:

• الان داخل پنجره خبر هستیم یا نه؟
• خبر مربوط به ارز/اهمیت مورد نظر هست یا نه؟
• این رویداد در بلک‌لیست هست یا نه؟

نکته مهم: فیلتر کردن باید دقیقاً همان منطقی را داشته باشد که در لایو استفاده می‌کنی، وگرنه تستر یک چیز را تست می‌کند و لایو چیز دیگری را اجرا می‌کند.

مثال عملی کوتاه: اگر در لایو فقط High Impact روی USD را فیلتر می‌کنی، در تستر هم باید دقیقاً همان تعریف را روی دیتاست اعمال کنی، نه اینکه به خاطر راحتی، همه رویدادها را یکجا ببندی.

اعتبارسنجی دیتاست: بدون این‌ها به هیچ نتیجه‌ای اعتماد نکن

دیتاست اگر اعتبارسنجی نشود، می‌تواند تو را دقیق‌تر از قبل گمراه کند. حداقل تست‌های اعتبارسنجی که باید داشته باشی این‌ها هستند:

1. تعداد رکوردهای خوانده‌شده
   باید بدانی در هر بازه زمانی چند رکورد خوانده شده و آیا این عدد منطقی است یا نه. اگر یک ماه کامل تست می‌گیری و رکوردها غیرعادی کم یا زیادند، دیتاست مشکل دارد.
2. همسانی Blacklist
   اگر بلک‌لیست داری، باید مطمئن شوی رویدادهایی که باید حذف شوند واقعاً حذف می‌شوند و هیچ اختلافی بین تعریف بلک‌لیست و خروجی پردازش وجود ندارد.
3. تست پنجره خبر (News Window Test)
   این تست یعنی بررسی کنی که:

• قبل از خبر پنجره فعال می‌شود،
• در طول بازه فعال می‌ماند،
• بعد از خبر درست خاموش می‌شود،
  و هیچ جابه‌جایی زمانی یا اشتباه مرزی وجود ندارد.

این تست مخصوصاً برای جلوگیری از خطاهای زمانی حیاتی است، چون کوچک‌ترین خطا در زمان‌بندی، کل News Guard را بی‌اثر می‌کند.

مثال عملی کوتاه: اگر پنجره را ۱۵ دقیقه قبل تعریف کرده‌ای ولی در عمل ۱۰ دقیقه قبل فعال می‌شود، ممکن است دقیقاً بخش خطرناک را از دست بدهی و نتیجه بگیری “فیلتر خبر کار نمی‌کند”.

کنترل اسپرد و اسلیپیج در خبر: بخش بی‌رحم ماجرا

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

هدف این بخش این است که آن حس بد را تبدیل کند به قاعده‌های قابل اندازه‌گیری:

• سقف اسپرد مشخص
• محدودیت اسلیپیج مشخص
• تصمیم استاندارد برای اینکه وقتی هزینه اجرای معامله بالا رفت، سیستم چه کند

چرا اسپرد و اسلیپیج در خبر تعیین‌کننده‌اند؟

در شرایط عادی، اختلاف بین قیمت مورد انتظار و قیمت اجرا شده معمولاً کوچک است و در مدل استراتژی تو جذب می‌شود. اما در خبر:

• اسپرد می‌تواند چند برابر شود و عملاً «هزینه ورود و خروج» را یک‌باره زیاد کند.
• اسلیپیج می‌تواند باعث شود سفارش در قیمتی اجرا شود که منطق حد ضرر/حد سود را از بین می‌برد.
• جهش‌ها می‌توانند باعث شوند حدضرر یا حدسود با فاصله زیادی اجرا شود.

پس در خبر، حتی اگر جهت بازار را درست حدس زده باشی، کیفیت اجرا می‌تواند نتیجه را وارونه کند. این یعنی کنترل اسپرد و اسلیپیج بخشی از “مدیریت ریسک” است، نه جزئیات فنی حاشیه‌ای.

سقف اسپرد: معیار ساده‌ای که جلوی فاجعه را می‌گیرد

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

این تصمیم معمولاً یکی از این‌هاست:

• ورود جدید ممنوع شود
• مدیریت پوزیشن محافظه‌کار شود (مثلاً بستن‌های غیرضروری انجام نشود)
• سیستم به حالت انتظار برود تا شرایط به محدوده قابل قبول برگردد

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

مثال عملی کوتاه: اگر در پنجره خبر سقف اسپرد را تعیین کرده باشی، خیلی از ورودهای فریبنده که فقط به خاطر جهش و اسپرد ظاهراً “سیگنال” شده‌اند، اصلاً اتفاق نمی‌افتند.

اسلیپیج: وقتی “اجرا” با “منطق” قهر می‌کند

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

• حد ضرر از یک ابزار کنترل ریسک تبدیل شود به یک ضربه سنگین
• ورود تو بدترین نقطه ممکن باشد
• خروج تو به جای حفاظت، تبدیل به تسلیم در قیمت نامناسب شود

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

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

تداخل با Break Even و مدیریت بستن سفارش‌ها/پوزیشن‌ها

اینجا همان نقطه‌ای است که خیلی‌ها سیستم را خراب می‌کنند: ترکیب کردن کنترل اسپرد/اسلیپیج با قوانین Break Even و بستن پوزیشن‌ها، بدون اینکه تداخل‌ها را بشناسند.

چند تداخل رایج:

• در پنجره خبر، Break Even فعال می‌شود و شروع می‌کند به دستکاری حد ضرر، اما اسپرد جهشی باعث می‌شود همان حد ضرر سریع‌تر فعال شود.
• سیستم می‌خواهد بخشی از پوزیشن را ببندد یا پوزیشن را ریسک‌فری کند، اما به خاطر اسپرد بالا یا اسلیپیج، همین عملیات “مدیریتی” تبدیل می‌شود به یک هزینه سنگین.
• سیستم چند عملیات پشت سر هم انجام می‌دهد (مثلاً بستن، تغییر حد ضرر، تنظیم مجدد) و در خبر این‌ها می‌تواند بدترین زمان ممکن باشد.

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

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

نتیجه عملی این بخش

کنترل اسپرد و اسلیپیج یعنی تعریف یک استاندارد برای “کیفیت مجاز معامله”. اگر کیفیت پایین‌تر از حد استاندارد آمد، سیستم باید رفتار خود را تغییر دهد. این دقیقاً همان چیزی است که News Guard را از یک ایده مبهم تبدیل می‌کند به یک زیرساخت قابل اتکا.

نقش AI در این پروژه: کمک فنی، نه عصای جادویی

هوش مصنوعی در پروژه «مدیریت اخبار» می‌تواند خیلی مفید باشد، به شرطی که جای اشتباهی از آن انتظار داشته باشی. AI قرار نیست برای تو یک استراتژی سودده از روی Actual/Forecast بسازد و تمام. این همان مسیری است که معمولاً به توهم، بک‌تست‌های قلابی و تصمیم‌های بی‌پشتوانه ختم می‌شود. نقش درست AI در این پروژه، نقش یک دستیار فنی است: کمک برای فهمیدن کد، دیباگ، تمیز کردن ساختار، و استانداردسازی لاگ و تست‌ها.

هدف این بخش این است که مرز توقعات را شفاف کند: AI کمک می‌کند سریع‌تر و دقیق‌تر پیاده‌سازی کنی، نه اینکه مسئولیت فکر کردن را از تو بگیرد.

AI دقیقاً کجا مفید است؟

در پروژه‌ای مثل News Guard، ارزش AI بیشتر در سه جاست:

1. فهم مسئله و تشخیص خطا
   وقتی یک رفتار غیرمنتظره می‌بینی، AI می‌تواند کمک کند سناریوها را دسته‌بندی کنی و سریع‌تر بفهمی مشکل از کجاست: زمان‌بندی، فیلتر خبر، اسپرد/اسلیپیج، یا تفاوت لایو و تستر.
2. ساخت لاگ‌های معنادار
   بدترین حالت این است که سیستم کار نکند و تو فقط یک “print” بی‌معنی داشته باشی. AI می‌تواند در طراحی ساختار لاگ کمک کند تا هر بار که News Guard تصمیم می‌گیرد، دقیقاً معلوم باشد:

• چه خبری تشخیص داده شد
• چرا این تصمیم گرفته شد
• زمان و پنجره خبر چه بود
• وضعیت اسپرد/شرایط اجرا چه بود

1. رفرکتور و تمیز کردن معماری
   News Guard اگر شسته‌رفته طراحی نشود، خیلی زود تبدیل می‌شود به یک توده شرط‌ها و استثناها. AI می‌تواند پیشنهادهای معماری بدهد تا اجزای پروژه جدا و قابل توسعه بمانند: فیلتر خبر، زمان‌بندی، مدیریت پوزیشن، و لاگ.

AI کجا خطرناک است؟

AI در این پروژه وقتی خطرناک می‌شود که از آن «خروجی سودده» بخواهی، نه «خروجی فنی». مخصوصاً این موارد:

• تولید قوانین معاملاتی بر اساس Actual/Forecast بدون درک محدودیت‌های اجرا
• پیشنهاد پارامترهای جادویی (مثلاً پنجره خبر ۷ دقیقه، یا آستانه‌های عجیب)
• وعده‌هایی مثل “این اکسپرت در خبر سود می‌دهد” یا “این بک‌تست تضمینی است”
• نادیده گرفتن مسئله Revision و تغییر داده‌ها و تفاوت لایو/تستر

AI ممکن است خیلی قانع‌کننده حرف بزند، ولی قانع‌کننده بودن با درست بودن فرق دارد. اگر دنبال راه میان‌بُر باشی، دقیقاً همان‌جایی است که ضربه می‌خوری.

چک‌لیست استفاده صحیح از AI در پروژه News Guard

این چک‌لیست را می‌توانی به عنوان استاندارد استفاده کنی تا AI واقعاً مفید باشد:

1. مسئله را دقیق توضیح بده
   به جای “کار نمی‌کند”، بگو دقیقاً چه اتفاقی می‌افتد و چه انتظاری داشتی.
2. نمونه لاگ و سناریو ارائه کن
   یک نمونه از خروجی لاگ یا یک توصیف مرحله‌ای از سناریو بده: چه زمانی، چه خبر، چه نماد، چه رفتار.
3. از AI بخواه «فرضیه‌ها» را لیست کند
   یعنی چند علت محتمل را با اولویت پیشنهاد دهد، نه اینکه مستقیم نسخه نهایی بدهد.
4. از AI بخواه «ساختار لاگ» پیشنهاد دهد
   لاگ باید تصمیم‌محور باشد: علت تصمیم، داده‌های ورودی تصمیم، و نتیجه تصمیم.
5. از AI بخواه «رفرکتور» پیشنهاد دهد، نه “استراتژی”
   هدف این پروژه ساخت یک زیرساخت محافظتی است، نه تولید سیگنال سودده.
6. هر خروجی را با واقعیت اجرا و محدودیت‌ها تطبیق بده
   اگر AI پیشنهادی می‌دهد، باید با محدودیت‌های اسپرد/اسلیپیج، تفاوت لایو/تستر و مسئله زمان‌بندی سازگار باشد.

مثال عملی کوتاه از استفاده درست

اگر دیدی News Guard در تستر فعال نمی‌شود، استفاده درست از AI این است که:

• لاگ‌ها را ساختاردهی کنی تا مشخص شود آیا خبر تشخیص داده شده یا نه
• بررسی کنی زمان مبنا درست مقایسه می‌شود یا نه
• ببینی فیلتر اهمیت/ارز/بلک‌لیست باعث حذف همه رویدادها نشده باشد
• و بعد پیشنهادهای رفرکتور بگیری تا این تصمیم‌ها قابل ردیابی شوند

نه اینکه از AI بخواهی “یک استراتژی خبری بده که سود کنه”.

جمع‌بندی: استاندارد پیشنهادی برای مسیر یادگیری و پیاده‌سازی

این مقاله قرار نیست به جای دوره یا پروژه کامل بنشیند. خروجی‌اش چیز دیگری است: یک چارچوب استاندارد و قابل اتکا که باعث می‌شود در «مدیریت اخبار فارکس در MQL5» مسیر را درست انتخاب کنی، انتظاراتت را درست تنظیم کنی، و News Guard را مثل یک زیرساخت حرفه‌ای ببینی نه یک ترفند لحظه‌ای. اگر تا اینجا همراه آمده‌ای، حالا باید دقیق بدانی چه چیزی دستت آمده و قدم بعدی‌ات چیست.

News Guard چیست و چه فرقی با News Trading دارد؟

News Guard یعنی «دروازه ریسک» برای خبر. خبر را سیگنال نمی‌بینی، خبر را شرایط غیرنرمال می‌بینی و هدف این است که سیستم در پنجره خبر آسیب نبیند. خروجی‌اش معمولاً این‌هاست: عدم ورود، کاهش ریسک، مدیریت محافظه‌کارانه، کنترل اسپرد و اسلیپیج.
News Trading یعنی خبر را منبع سیگنال بدانی و بر اساس Actual/Forecast وارد معامله شوی. تفاوت کلیدی این است که در News Trading موفقیت وابسته به پیش‌بینی و اجرای فوق‌العاده سریع است، اما در News Guard موفقیت یعنی «کم کردن ضربه‌های خبر» و پایدار کردن سیستم. برای الگوتریدرها، News Guard معمولاً منطقی‌تر و قابل دفاع‌تر است.

چرا اکسپرت‌ها در خبر نابود می‌شوند وقتی استراتژی‌شان “بد” نیست؟

چون مشکل اغلب استراتژی نیست، «محیط اجرا» است. در خبر:

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

چگونه در متاتریدر ۵ تقویم اقتصادی را با MQL5 بخوانیم؟

مدل داده تقویم اقتصادی در MT5 سه‌لایه است: Country → Event → Value(History).
برای مدیریت اخبار معمولاً از این‌ها استفاده می‌شود:

• رویدادها (Event): نام/شناسه، ارز مرتبط، اهمیت، زمان انتشار
• مقدارها (Value History): Previous/Forecast/Actual و در صورت وجود Revision
  اگر هدف تو News Guard است، حداقل به «زمان انتشار + اهمیت + ارز» نیاز داری. اگر گزارش‌گیری/تحلیل می‌خواهی، آن وقت Value History هم مهم می‌شود.

CalendarValueHistoryByEvent دقیقاً چه کاربردی دارد؟

این مفهوم برای زمانی است که می‌خواهی به جای «اسم خبر»، با «عددهای خبر» کار کنی. یعنی برای یک رویداد مشخص، تاریخچه مقدارهای Previous/Forecast/Actual را در دوره‌های مختلف داشته باشی و بتوانی:

• ثبت دقیق خروجی‌ها و لاگ‌های خبری بسازی
• بررسی کنی آیا Actual منتشر شده یا نه
• Revision را تشخیص بدهی و تفاوت مقدار قبلی با مقدار اصلاح‌شده را بفهمی
  این ابزار برای “سیگنال‌سازی” الزاماً نیست؛ برای استانداردسازی داده و تحلیل و اعتبارسنجی خیلی مفید است.

TimeCurrent با LocalTime چه فرقی دارد و کدام مبنای زمان خبر است؟

TimeCurrent زمان مرجع ترمینال/سرور است و تصمیم‌های معاملاتی باید با این مبنا هماهنگ باشند. LocalTime زمان سیستم شماست و ممکن است با زمان سرور اختلاف داشته باشد.
اشتباه رایج این است که زمان خبر را با یک مبنا بگیری و بعد آن را با مبنای دیگر مقایسه کنی. نتیجه‌اش هم پنجره خبر جابه‌جا می‌شود و فکر می‌کنی فیلتر خبر خراب است.
قاعده ساده: زمان خبر و زمان تصمیم‌گیری باید در یک مبنای زمانی واحد باشند.

چرا بک‌تست اخبار قابل اعتماد نیست؟ (Revision یعنی چه؟)

دو مشکل اصلی وجود دارد:

1. ناپایداری داده: مقدارهای خبر می‌توانند Revision داشته باشند (اصلاح شوند) و حتی Forecast ممکن است قبل از انتشار تغییر کند. یعنی دیتای تاریخی خبر همیشه مثل قیمت “یک‌بار برای همیشه ثابت” نیست.
2. شکاف بین لایو و تستر: در خبر کیفیت اجرا (اسپرد/اسلیپیج/جهش) نقش تعیین‌کننده دارد و تستر معمولاً آن را کامل بازسازی نمی‌کند.
   پس بک‌تست خبری اگر با هدف «سوددهی خبر» انجام شود، خطر توهم بالاست. استفاده درستش معمولاً برای «کنترل ریسک و اجتناب از خبر» است.

چطور اخبار مهم را فیلتر کنیم؟ Importance/ImpactType/Whitelist/Blacklist

فیلتر خبر یعنی همه خبرها را یکسان نبینی. رایج‌ترین استانداردها:

• Importance/Impact: فقط خبرهای با اهمیت بالا
• ارز مرتبط: فقط ارزهایی که واقعاً روی نمادهای تو اثر دارند
• Whitelist: فقط چند رویداد مشخص و حساس (مثل نرخ بهره، CPI، NFP)
• Blacklist: حذف رویدادهای بی‌ربط یا دردسرساز
  هدف فیلتر این است که News Guard هم “هوشمند” باشد و هم “کم‌مزاحمت”. یعنی نه همیشه سیستم را قفل کند، نه خبرهای واقعاً خطرناک را جا بیندازد.

برای Strategy Tester به دیتاست اخبار نیاز دارم یا Calendar کافی است؟

اگر هدف تو فقط این است که در لایو نزدیک خبر معامله نکنی، Calendar معمولاً کافی است.
اما دیتاست وقتی لازم می‌شود که:

• می‌خواهی تست‌ها تکرارپذیر و پایدار باشند
• می‌خواهی رفتار News Guard در تستر به شکل قابل اعتماد بررسی شود
• می‌خواهی اختلاف‌های لایو و تستر را تا حدی مدیریت کنی
  در این حالت، دیتاست (مثلاً CSV زمان رویدادها) زمین بازی را ثابت می‌کند و امکان اعتبارسنجی دقیق‌تر می‌دهد.

چطور اسپرد و اسلیپیج را در خبر کنترل کنیم؟

با تبدیل “حس بد” به معیار:

• سقف اسپرد مشخص: اگر اسپرد از حد گذشت، ورود جدید ممنوع یا رفتار محافظه‌کارانه فعال شود
• محدودیت اسلیپیج: اگر کیفیت اجرا بد شد، سیستم از ورود/عملیات پرهزینه اجتناب کند
• کاهش دستکاری‌های پرهزینه در پنجره خبر: مخصوصاً وقتی Break Even یا تغییرات متعدد روی سفارش‌ها باعث هزینه اضافی می‌شود
  کنترل اسپرد/اسلیپیج یعنی تعریف استاندارد «کیفیت مجاز معامله». اگر کیفیت افت کرد، معامله انجام نشود یا رفتار سیستم تغییر کند.

AI در این پروژه کجا کمک می‌کند و کجا خطرناک است؟

کمک می‌کند در:

• دیباگ و تحلیل سناریوهای خطا (زمان‌بندی، فیلتر، پنجره خبر)
• طراحی لاگ‌های تصمیم‌محور و قابل پیگیری
• پیشنهاد رفرکتور و تمیز کردن ساختار پروژه
  خطرناک می‌شود وقتی:
• از AI “استراتژی سودده خبری” می‌خواهی
• دنبال پارامترهای جادویی و نسخه‌های قطعی هستی
• محدودیت‌های اجرا و مسئله Revision و تفاوت لایو/تستر را نادیده می‌گیری
  AI ابزار فنی است، نه تضمین سود. اگر جای این دو را عوض کنی، خروجی‌اش خیلی قانع‌کننده است و خیلی هم می‌تواند غلط باشد.

سوالات متداول (FAQ)

News Guard چیست و چه فرقی با News Trading دارد؟

News Guard یعنی «دروازه ریسک» برای خبر. خبر را سیگنال نمی‌بینی، خبر را شرایط غیرنرمال می‌بینی و هدف این است که سیستم در پنجره خبر آسیب نبیند. خروجی‌اش معمولاً این‌هاست: عدم ورود، کاهش ریسک، مدیریت محافظه‌کارانه، کنترل اسپرد و اسلیپیج.
News Trading یعنی خبر را منبع سیگنال بدانی و بر اساس Actual/Forecast وارد معامله شوی. تفاوت کلیدی این است که در News Trading موفقیت وابسته به پیش‌بینی و اجرای فوق‌العاده سریع است، اما در News Guard موفقیت یعنی «کم کردن ضربه‌های خبر» و پایدار کردن سیستم. برای الگوتریدرها، News Guard معمولاً منطقی‌تر و قابل دفاع‌تر است.

چرا اکسپرت‌ها در خبر نابود می‌شوند وقتی استراتژی‌شان “بد” نیست؟

چون مشکل اغلب استراتژی نیست، «محیط اجرا» است. در خبر:

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

چگونه در متاتریدر ۵ تقویم اقتصادی را با MQL5 بخوانیم؟

مدل داده تقویم اقتصادی در MT5 سه‌لایه است: Country → Event → Value(History).
برای مدیریت اخبار معمولاً از این‌ها استفاده می‌شود:

• رویدادها (Event): نام/شناسه، ارز مرتبط، اهمیت، زمان انتشار
• مقدارها (Value History): Previous/Forecast/Actual و در صورت وجود Revision
  اگر هدف تو News Guard است، حداقل به «زمان انتشار + اهمیت + ارز» نیاز داری. اگر گزارش‌گیری/تحلیل می‌خواهی، آن وقت Value History هم مهم می‌شود.

CalendarValueHistoryByEvent دقیقاً چه کاربردی دارد؟

این مفهوم برای زمانی است که می‌خواهی به جای «اسم خبر»، با «عددهای خبر» کار کنی. یعنی برای یک رویداد مشخص، تاریخچه مقدارهای Previous/Forecast/Actual را در دوره‌های مختلف داشته باشی و بتوانی:

• ثبت دقیق خروجی‌ها و لاگ‌های خبری بسازی
• بررسی کنی آیا Actual منتشر شده یا نه
• Revision را تشخیص بدهی و تفاوت مقدار قبلی با مقدار اصلاح‌شده را بفهمی
  این ابزار برای “سیگنال‌سازی” الزاماً نیست؛ برای استانداردسازی داده و تحلیل و اعتبارسنجی خیلی مفید است.

TimeCurrent با LocalTime چه فرقی دارد و کدام مبنای زمان خبر است؟

TimeCurrent زمان مرجع ترمینال/سرور است و تصمیم‌های معاملاتی باید با این مبنا هماهنگ باشند. LocalTime زمان سیستم شماست و ممکن است با زمان سرور اختلاف داشته باشد.
اشتباه رایج این است که زمان خبر را با یک مبنا بگیری و بعد آن را با مبنای دیگر مقایسه کنی. نتیجه‌اش هم پنجره خبر جابه‌جا می‌شود و فکر می‌کنی فیلتر خبر خراب است.
قاعده ساده: زمان خبر و زمان تصمیم‌گیری باید در یک مبنای زمانی واحد باشند.

چرا بک‌تست اخبار قابل اعتماد نیست؟ (Revision یعنی چه؟)

دو مشکل اصلی وجود دارد:

1. ناپایداری داده: مقدارهای خبر می‌توانند Revision داشته باشند (اصلاح شوند) و حتی Forecast ممکن است قبل از انتشار تغییر کند. یعنی دیتای تاریخی خبر همیشه مثل قیمت “یک‌بار برای همیشه ثابت” نیست.
2. شکاف بین لایو و تستر: در خبر کیفیت اجرا (اسپرد/اسلیپیج/جهش) نقش تعیین‌کننده دارد و تستر معمولاً آن را کامل بازسازی نمی‌کند.
   پس بک‌تست خبری اگر با هدف «سوددهی خبر» انجام شود، خطر توهم بالاست. استفاده درستش معمولاً برای «کنترل ریسک و اجتناب از خبر» است.

چطور اخبار مهم را فیلتر کنیم؟ Importance/ImpactType/Whitelist/Blacklist

فیلتر خبر یعنی همه خبرها را یکسان نبینی. رایج‌ترین استانداردها:

• Importance/Impact: فقط خبرهای با اهمیت بالا
• ارز مرتبط: فقط ارزهایی که واقعاً روی نمادهای تو اثر دارند
• Whitelist: فقط چند رویداد مشخص و حساس (مثل نرخ بهره، CPI، NFP)
• Blacklist: حذف رویدادهای بی‌ربط یا دردسرساز
  هدف فیلتر این است که News Guard هم “هوشمند” باشد و هم “کم‌مزاحمت”. یعنی نه همیشه سیستم را قفل کند، نه خبرهای واقعاً خطرناک را جا بیندازد.

برای Strategy Tester به دیتاست اخبار نیاز دارم یا Calendar کافی است؟

اگر هدف تو فقط این است که در لایو نزدیک خبر معامله نکنی، Calendar معمولاً کافی است.
اما دیتاست وقتی لازم می‌شود که:

• می‌خواهی تست‌ها تکرارپذیر و پایدار باشند
• می‌خواهی رفتار News Guard در تستر به شکل قابل اعتماد بررسی شود
• می‌خواهی اختلاف‌های لایو و تستر را تا حدی مدیریت کنی
  در این حالت، دیتاست (مثلاً CSV زمان رویدادها) زمین بازی را ثابت می‌کند و امکان اعتبارسنجی دقیق‌تر می‌دهد.

چطور اسپرد و اسلیپیج را در خبر کنترل کنیم؟

با تبدیل “حس بد” به معیار:

• سقف اسپرد مشخص: اگر اسپرد از حد گذشت، ورود جدید ممنوع یا رفتار محافظه‌کارانه فعال شود
• محدودیت اسلیپیج: اگر کیفیت اجرا بد شد، سیستم از ورود/عملیات پرهزینه اجتناب کند
• کاهش دستکاری‌های پرهزینه در پنجره خبر: مخصوصاً وقتی Break Even یا تغییرات متعدد روی سفارش‌ها باعث هزینه اضافی می‌شود
  کنترل اسپرد/اسلیپیج یعنی تعریف استاندارد «کیفیت مجاز معامله». اگر کیفیت افت کرد، معامله انجام نشود یا رفتار سیستم تغییر کند.

AI در این پروژه کجا کمک می‌کند و کجا خطرناک است؟

کمک می‌کند در:

• دیباگ و تحلیل سناریوهای خطا (زمان‌بندی، فیلتر، پنجره خبر)
• طراحی لاگ‌های تصمیم‌محور و قابل پیگیری
• پیشنهاد رفرکتور و تمیز کردن ساختار پروژه
  خطرناک می‌شود وقتی:
• از AI “استراتژی سودده خبری” می‌خواهی
• دنبال پارامترهای جادویی و نسخه‌های قطعی هستی
• محدودیت‌های اجرا و مسئله Revision و تفاوت لایو/تستر را نادیده می‌گیری
  AI ابزار فنی است، نه تضمین سود. اگر جای این دو را عوض کنی، خروجی‌اش خیلی قانع‌کننده است و خیلی هم می‌تواند غلط باشد.

از این مقاله چه خروجی می‌گیری؟

در پایان این مقاله باید این سه خروجی را داشته باشی:

1. یک مدل ذهنی درست از خبر برای الگوتریدر
   اینکه خبر “سیگنال” نیست؛ خبر یک وضعیت پرهزینه و غیرنرمال است که باید با Risk Gate کنترل شود.
2. یک مسیر تصمیم‌گیری روشن برای نیاز خودت
   فهم اینکه مشکل تو کدام است: نابودی اکسپرت در خبر، بک‌تست خبر، خواندن تقویم با کد، یا هماهنگی لایو و تستر.
3. یک استاندارد اجرایی برای News Guard
   یعنی بدانی News Guard دقیقاً شامل چه اجزایی است: فیلتر خبر، پنجره زمانی، تصمیم‌ها برای حالت با/بدون پوزیشن، کنترل اسپرد/اسلیپیج، و در صورت نیاز دیتاست.

مسیر مرحله‌ای (Roadmap) یادگیری و پیاده‌سازی

اگر بخواهی مسیر را استاندارد و بدون پرش جلو ببری، این ترتیب منطقی است:

1. تثبیت هدف: News Trading یا News Guard؟
   اگر هنوز به دنبال سیگنال‌گیری از Actual/Forecast هستی، اول تکلیف این موضوع را روشن کن.
2. شناخت داده‌های تقویم اقتصادی متاتریدر
   بدانی ساختار داده چیست و چه چیزهایی واقعاً در Calendar وجود دارد: Country، Event، Value History و مفهوم Revision.
3. طراحی مفهوم News Guard
   تعریف تصمیم‌ها، تعریف پنجره زمانی قبل/بعد خبر، و تعیین رفتار سیستم در حالت بدون پوزیشن و با پوزیشن.
4. حل مسئله زمان و هماهنگی
   قبل از هر چیز، مبنای زمان را درست کن تا پنجره خبر جابه‌جا اجرا نشود.
5. کنترل هزینه اجرای معامله در خبر
   سقف اسپرد، محدودیت اسلیپیج، و کاهش عملیات پرهزینه در پنجره خبر.
6. واقع‌بینی درباره بک‌تست اخبار
   بک‌تست را برای کنترل ریسک و اجتناب از خبر استفاده کن، نه اثبات سوددهی خبر.
7. (در صورت نیاز) ساخت دیتاست برای Strategy Tester
   وقتی Calendar برای تست پایدار کافی نیست، دیتاست زمان‌های خبر را استاندارد کن و اعتبارسنجی کن.

مسیر ادامه مطالعه (خوشه‌ها) به صورت منطقی از همین Roadmap بیرون می‌آید: هر مرحله می‌تواند یک مقاله خوشه‌ای مستقل باشد که جزئیات و مثال‌های عمیق‌تر را پوشش می‌دهد.

چک‌لیست “Done Definition” برای News Guard

برای اینکه News Guard فقط یک ایده روی کاغذ نباشد، باید تعریف کنی چه زمانی می‌گویی “تمام شد و قابل اتکاست”. این چک‌لیست یک تعریف استاندارد از Done است:

1. تعریف فیلتر خبر روشن است
   مشخص است کدام ارزها، کدام سطح اهمیت، و کدام رویدادها (وایت‌لیست/بلک‌لیست) مشمول هستند.
2. پنجره زمانی خبر دقیق و ثابت تعریف شده است
   قبل/بعد خبر مشخص است و رفتار سیستم دقیقاً وابسته به این پنجره است.
3. تصمیم‌ها برای دو حالت مشخص است

• بدون پوزیشن: قانون ورود در پنجره خبر شفاف است.
• با پوزیشن: قانون کاهش ریسک یا مدیریت پوزیشن شفاف است.

1. مبنای زمان درست و یکپارچه است
   هیچ مقایسه زمانی با مبنای اشتباه انجام نمی‌شود و پنجره خبر جابه‌جا فعال نمی‌شود.
2. کنترل اسپرد و اسلیپیج به معیار تبدیل شده است
   سقف‌ها تعریف شده‌اند و سیستم می‌داند در شرایط بدِ اجرا چه واکنشی نشان دهد.
3. لاگ تصمیم‌ها قابل بررسی است
   هر بار که News Guard تصمیمی می‌گیرد، قابل پیگیری است که چرا و بر اساس چه داده‌ای این تصمیم گرفته شده است.
4. تست حداقلی انجام شده است
   حداقل یک “News Window Test” انجام شده تا مطمئن شوی پنجره‌ها درست فعال/غیرفعال می‌شوند و فیلترها واقعاً کار می‌کنند.
5. اگر از دیتاست استفاده می‌کنی، اعتبارسنجی انجام شده است
   تعداد رکوردها، همسانی بلک‌لیست، و پوشش زمانی بررسی شده است.

اگر این موارد را داری، News Guard تو دیگر یک “ایده خام” نیست؛ یک Risk Gate قابل اتکاست.