เรารีสตาร์ตกลยุทธ์ Paper Trading กลางคันระหว่างการเทรด แล้วได้ลำดับคำสั่งซื้อขายต่างจากที่เกิดขึ้นก่อนรีสตาร์ต ข้อมูลตลาดชุดเดิม กลยุทธ์เวอร์ชันเดิม ยอดเงินในบัญชีเท่าเดิม การคำนวณสัญญาณตรงกัน แต่ความจำของกลยุทธ์เกี่ยวกับสถานะที่ถืออยู่และคำสั่งที่รอดำเนินการกลับไม่ตรงกัน
เราไล่หาสาเหตุของความคลาดเคลื่อนตลอดการจำลองย้อนหลังหนึ่งวัน และได้บทเรียนที่เรียบง่ายว่า สำหรับซอฟต์แวร์ของคุณ การรีสตาร์ตคือเหตุการณ์ในตลาด หากไม่ทดสอบว่ากลยุทธ์สร้างสถานะกลับขึ้นมาอย่างไร การทดสอบย้อนหลังที่ดูเรียบร้อยก็อาจกลบข้อเท็จจริงที่ว่าระบบ Paper Trading ลืมไปว่าตัวเองมีอะไรอยู่บ้าง
09:10 — เราเลือกสถานะที่ไม่มีอะไรซับซ้อน
กลยุทธ์ทดสอบเทรดสัญญา Perpetual ที่มีสภาพคล่องสูง: เปิด Long เมื่อค่าเฉลี่ยเคลื่อนที่ระยะสั้นตัดขึ้นเหนือค่าเฉลี่ยที่ยาวกว่า แล้วปิดสถานะเมื่อเกิดการตัดลง เราเริ่มจำลองย้อนหลังโดยมีสถานะขนาดเล็กเปิดค้างอยู่แล้ว พร้อมคำสั่ง Limit แบบ Reduce-only ที่วางรอไว้เพื่อลดสถานะ การกู้คืนจึงต้องสร้างข้อเท็จจริง 2 อย่างกลับมาให้ได้: เราถืออะไรอยู่ และได้สั่งให้แพลตฟอร์มทำอะไรไปแล้วบ้าง
ณ จุดตรวจสอบ บัญชีถืออยู่ 0.04 สัญญา และมีคำสั่งเปิดอยู่ที่ 0.01 กลยุทธ์แคชค่าทั้งสองไว้ในหน่วยความจำ แต่ขั้นตอนเริ่มต้นระบบดึงข้อมูลมาเฉพาะสถานะที่ถืออยู่ จึงคิดว่าคำสั่งที่แคชไว้ถูกยกเลิกไปแล้ว
09:25 — คำสั่งซ้ำรายการแรกปรากฏขึ้น
หลังรีสตาร์ต กลยุทธ์เห็นสถานะ Long ที่มีอยู่แล้ว รันตรรกะสัญญาณ แล้วส่งคำสั่งลดสถานะอีก 0.01 ตอนนี้แพลตฟอร์ม Paper Trading มีคำสั่งที่ยังทำงานอยู่ 2 รายการ แต่ละรายการไม่ได้มีปัญหาในตัวเอง หากทั้งคู่ถูกจับคู่ ระบบอาจขายออกเป็น 2 เท่าของจำนวนที่ตั้งใจไว้
ตอนแรกเราโทษลูปสัญญาณ แต่ปัญหาไม่ได้อยู่ที่ลูป แต่อยู่ที่ข้อมูลสถานะซึ่งไม่ครบ กลยุทธ์ถามว่า “ฉันมีสถานะอะไรอยู่?” แต่ไม่เคยถามว่า “มีคำสั่งไหนที่ยังรอดำเนินการอยู่บ้าง?”
| สถานะหลังรีสตาร์ต | สิ่งที่โปรเซสเข้าใจ | สิ่งที่บัญชีถืออยู่ |
|---|---|---|
| สถานะ | Long 0.04 | Long 0.04 |
| คำสั่งลดสถานะที่เปิดอยู่ | ไม่มี | 2 รายการ รายการละ 0.01 |
| Exposure ที่ตั้งใจไว้หลังจับคู่ 1 รายการ | Long 0.03 | อาจเหลือ Long 0.02 |
10:00 — เราแก้การกู้คืน แล้วพบปัญหาจังหวะเวลา
เราแก้ขั้นตอนเริ่มต้นระบบให้สร้างสถานะกลับจากสถานะที่ถืออยู่ในบัญชีและคำสั่งที่ยังเปิดอยู่ ก่อนเปิดให้ตัดสินใจใหม่ วิธีนี้กำจัดคำสั่งซ้ำได้ จากนั้นเราทำให้เหตุการณ์ขาดการเชื่อมต่อยุ่งยากขึ้น: มีคำสั่งหนึ่งถูกจับคู่ขณะที่กลยุทธ์ออฟไลน์ และการแจ้งเตือนการจับคู่มาถึงหลังเชื่อมต่อใหม่
ข้อมูลสถานะบัญชีสะท้อนการจับคู่ไปแล้ว แต่การแจ้งเตือนที่มาช้ากลับทำให้สถานะในเครื่องลดลงซ้ำอีกครั้ง ชั่วครู่หนึ่ง กลยุทธ์จึงเข้าใจว่าถืออยู่ 0.02 สัญญา ทั้งที่บัญชีถืออยู่ 0.03 การปรับสมดุลครั้งถัดไปจึงอิงกับปริมาณที่ขาดไปซึ่งไม่มีอยู่จริง
เราเพิ่มกฎการปรับข้อมูลให้ตรงกัน: ใช้ข้อมูลสถานะบัญชีเป็นจุดตั้งต้น ใช้รหัสเหตุการณ์เพื่อข้ามการจับคู่ที่สะท้อนในข้อมูลนั้นแล้ว และอย่าส่งคำสั่งจนกว่าการซิงก์ครั้งแรกจะเสร็จ การแจ้งเตือนอาจมาช้าหรือซ้ำได้ ขั้นตอนกู้คืนต้องรับมือได้ทั้งสองกรณี
13:40 — การจำลองย้อนหลังจับความคลาดเคลื่อนที่มองข้ามได้ง่าย
เราจำลองเส้นทางราคาเดิมซ้ำทั้งรอบที่รันครั้งแรกและรอบที่รีสตาร์ต การเปรียบเทียบ P&L สุดท้ายคงทำให้พลาดปัญหานี้ไป เพราะทั้ง 2 เวอร์ชันจบด้วยสถานะเดียวกันหลังตลาดกลับทิศ แต่การเปรียบเทียบเหตุการณ์คำสั่งซื้อขายเผยให้เห็นความผิดปกติ
เราบันทึกการตัดสินใจแต่ละครั้งพร้อมสถานะที่ใช้: สถานะที่ถืออยู่ คำสั่งที่เปิดอยู่ รหัสการจับคู่ล่าสุดที่ประมวลผลแล้ว ค่าสัญญาณ และเวอร์ชันกลยุทธ์ เหตุการณ์แรกที่เริ่มแตกต่างกันจึงอธิบายได้ รอบหนึ่งเห็นคำสั่งที่กำลังดำเนินการอยู่ แต่อีกรอบเห็นรายการว่าง ต่อมาอีกรอบหนึ่งประมวลผลการจับคู่ซ้ำสองครั้ง
ยอดเงินคงเหลือที่ตรงกันตอนจบไม่ได้พิสูจน์ว่าพฤติกรรมตรงกัน ให้เปรียบเทียบลำดับการตัดสินใจและคำสั่ง โดยเฉพาะช่วงที่ระบบกำลังกู้คืน
16:20 — ครั้งหน้าจะทำอะไรต่างออกไป
เราใช้เวลาจำลองข้อมูลราคานานเกินไป ก่อนตรวจสอบการเปลี่ยนสถานะในบัญชี ครั้งหน้าเราจะจำลองกรณีขัดข้องก่อน และทำให้เส้นทางตลาดแทบไม่มีการเปลี่ยนแปลง วิธีนี้ช่วยให้เห็นข้อผิดพลาดของซอฟต์แวร์ได้ชัด โดยไม่ต้องวินิจฉัยท่ามกลางการเคลื่อนไหวผันผวนของตลาด
- รีสตาร์ตขณะมีสถานะและคำสั่งที่จับคู่ไปแล้วบางส่วน
- ตัดการเชื่อมต่อหลังส่งคำสั่ง แล้วเชื่อมต่อใหม่ก่อนการแจ้งเตือนการจับคู่จะมาถึง
- ส่งเหตุการณ์การจับคู่เดิมซ้ำ 2 ครั้ง และตรวจสอบว่าสถานะเปลี่ยนเพียงครั้งเดียว
- ระงับคำสั่งใหม่จนกว่าสถานะที่ถืออยู่และคำสั่งที่เปิดอยู่จะปรับข้อมูลตรงกันทั้งคู่
- เปรียบเทียบบันทึกการตัดสินใจและคำสั่งระหว่างรอบที่ทำงานต่อเนื่องกับรอบที่รีสตาร์ต
เรายังได้เรียนรู้ว่าควรบันทึกสแนปช็อตสำหรับการกู้คืนไว้พร้อมเวอร์ชันกลยุทธ์และบันทึกเหตุการณ์ด้วย วิธีนี้ทำให้จำลองข้อผิดพลาดซ้ำได้ในไม่กี่นาที แทนที่จะต้องหวังให้ใครสักคนจำลำดับการเชื่อมต่อใหม่ที่แน่นอนได้
กลยุทธ์ Paper Trading ที่ทำงานถูกต้องเฉพาะตอนที่โปรเซสยังมีชีวิตอยู่ ยังสอบซ้อมไม่ครบถ้วน ลองรีสตาร์ตระหว่างถือสถานะ ปล่อยให้การจับคู่มาถึงล่าช้า แล้วตรวจดูทุกคำสั่งที่ส่งหลังจากนั้น เป้าหมายไม่ใช่พิสูจน์ว่าระบบไม่มีวันผิดพลาด แต่คือทำให้มองเห็นการกู้คืนได้ ก่อนที่บัญชี Paper Trading จะสอนบทเรียนเดิมให้คุณแบบไม่ทันตั้งตัว
← บทความทั้งหมด
