Backtest มักนับการเทรดราวกับว่าสัญญาณเปลี่ยนเป็นสถานะถือครองโดยตรง ส่วน paper trading จะมีคำสั่งคั่นอยู่ระหว่างกลาง คำสั่งนั้นอาจค้างอยู่ ถูกจับคู่เพียงบางส่วน ถูกยกเลิก ถูกปฏิเสธ หรือยังทำงานอยู่แม้สัญญาณจะเปลี่ยนไปแล้ว หากกลยุทธ์จำลองของคุณข้ามวงจรชีวิตนี้ไป จำนวนการเทรดและความเสี่ยงที่ถืออยู่อาจแทบไม่ตรงกับสิ่งที่บัญชี paper บันทึกไว้
วิธีแก้ที่ใช้ได้จริงคือทำให้คำสั่งเป็นออบเจ็กต์ที่คงอยู่ พร้อมสถานะและเวลาประทับ สัญญาณคือคำสั่งให้ลองเทรด ไม่ใช่หลักฐานว่ามีการเทรดเกิดขึ้นแล้ว
ทำไม Paper Strategy ของฉันจึงมีการเทรดน้อยกว่า Backtest?
เริ่มจากคำสั่งที่ไม่เคยถูกจับคู่ Backtest อาจสมมติว่าคำสั่ง Limit ทุกคำสั่งถูกจับคู่ทันทีที่ตลาดแตะราคาที่ตั้งไว้ แต่ในตลาดจริง การที่ราคาแตะไม่ได้บอกว่าคำสั่งของคุณอยู่ลำดับต้นคิวหรือไม่ มีปริมาณซื้อขายมากพอหรือเปล่า หรือยังมีราคาเสนอขายนั้นอยู่ตอนที่คำสั่งไปถึงตลาดหรือไม่
ลองพิจารณากลยุทธ์ที่ส่งคำสั่ง Buy Limit ที่ราคา $100 และยกเลิกหลัง 30 วินาที ตลาดซื้อขายที่ราคา $100.00 แต่มีปริมาณซื้อขายที่ราคานั้นเพียงเล็กน้อย และคำสั่งอื่นอยู่ก่อนในคิว คำสั่งของคุณอาจถูกจับคู่เพียงบางส่วนหรือไม่ถูกจับคู่เลย Backtest ที่อิงแค่การแตะราคาจะบันทึกสถานะเต็มจำนวน ส่วนบัญชี paper ที่จำลองสมมติฐานเรื่องคิวอาจบันทึกว่าไม่มีการจับคู่เลย
Market Order มีความคลาดเคลื่อนอีกแบบหนึ่ง Backtest อาจจับคู่ปริมาณทั้งหมดที่ราคาเปิดของแท่งถัดไป ขณะที่ paper trading อาจปฏิเสธปริมาณที่เกินข้อกำหนดของกระดานเทรด หรือทยอยจับคู่เป็นส่วน ๆ ขณะที่สมุดคำสั่งซื้อขายเคลื่อนไหว แท่งราคาคือสรุปการซื้อขาย ไม่ได้รับประกันว่าคำสั่งทั้งหมดของคุณจะซื้อขายได้ที่ราคาเดียวกัน
Backtest ควรทำอย่างไรเมื่อสัญญาณเปลี่ยนก่อนที่คำสั่งจะถูกจับคู่?
ให้คำสั่งเดิมยังทำงานอยู่จนกว่าเครื่องจำลองจะได้รับและประมวลผลการยกเลิก หากสัญญาณกลับทิศขณะที่คำสั่ง Buy ยังค้างอยู่ กลยุทธ์อาจต้องการยกเลิกคำสั่งนั้นและส่งคำสั่ง Sell แต่ความตั้งใจดังกล่าวไม่ได้ทำให้คำสั่ง Buy หายไปทันที คำสั่งอาจถูกจับคู่ระหว่างที่การยกเลิกกำลังดำเนินการ ทำให้บัญชียังถือสถานะ Long ในจังหวะที่สัญญาณใหม่บอกให้ถือ Short
จำลองเหตุการณ์นี้เป็นลำดับ: สัญญาณเปลี่ยน กลยุทธ์ส่งคำขอยกเลิก ตลาดรับทราบหรือรายงานว่ามีการจับคู่ แล้วกลยุทธ์จึงทราบสถานะสุดท้ายของคำสั่ง แม้แต่การกำหนดความหน่วงคงที่แบบง่าย ๆ ก็ช่วยให้เห็นเหตุการณ์แข่งกันที่ Backtest แบบยกเลิกทันทีซ่อนไว้ได้
สำหรับแบบจำลองที่ตั้งใจให้เรียบง่าย ความหน่วงในการยกเลิก 1 วินาทีและการประมวลผลตามเหตุการณ์ถัดไป อาจให้ข้อมูลมากกว่าการสมมติว่าการยกเลิกเกิดขึ้นทันที ความหน่วงที่เหมาะสมขึ้นอยู่กับตลาดและระบบ ประเด็นคือควรจำลองความหน่วงไว้ หากคำสั่งของคุณเป็น Market Order ที่ไม่มีช่วงเวลาให้ยกเลิก ปัญหาเดียวกันนี้ก็ยังสำคัญสำหรับการจับคู่บางส่วนและรายงานที่มาถึงล่าช้า
Paper Trading Simulator ควรบันทึกสถานะคำสั่งใดบ้าง?
ใช้ state machine ขนาดเล็กและเก็บทุกการเปลี่ยนสถานะพร้อมเวลา คำเรียกที่แต่ละตลาดใช้จะแตกต่างกัน แต่ความแตกต่างหลักยังเหมือนกัน:
- ใหม่หรือรอดำเนินการ: ส่งคำสั่งแล้ว แต่ยังไม่ได้รับการตอบรับ
- เปิดอยู่: ได้รับการยอมรับและยังมีสิทธิ์ถูกจับคู่
- จับคู่บางส่วนแล้ว: มีการซื้อขายบางปริมาณ ส่วนที่เหลืออาจยังเปิดอยู่
- จับคู่ครบแล้ว: ไม่มีปริมาณคงเหลือ
- รอยกเลิก: คำขอยกเลิกอยู่ระหว่างดำเนินการ คำสั่งยังถูกจับคู่ได้
- ยกเลิกแล้ว ถูกปฏิเสธ หรือหมดอายุ: ไม่มีปริมาณเหลือให้ซื้อขายภายใต้คำสั่งนั้นอีก
บันทึกปริมาณที่จับคู่แล้วแยกจากปริมาณที่ร้องขอ พร้อมราคาและค่าธรรมเนียมของการจับคู่ คำสั่งที่จับคู่บางส่วนถือเป็นทั้งการเทรดที่เกิดขึ้นแล้วและภาระที่ยังค้างอยู่สำหรับส่วนที่เหลือ หากมองว่าคำสั่งนั้นเปิดอยู่ทั้งหมดหรือเสร็จสิ้นทั้งหมด ก็จะทำให้ข้อมูลที่กลยุทธ์ต้องใช้กำหนดขนาดการดำเนินการครั้งถัดไปสูญหาย
| เหตุการณ์คำสั่ง | สิ่งที่กลยุทธ์ควรรู้ | วิธีลัดที่มักใช้ใน Backtest |
|---|---|---|
| จับคู่บางส่วน | ปริมาณที่ดำเนินการแล้ว ปริมาณคงเหลือ ราคาเฉลี่ย | ถือว่าคำสั่งทั้งหมดจับคู่ที่ราคาเดียว |
| คำขอยกเลิก | เวลาที่ส่งคำขอและการยืนยันยกเลิกหรือจับคู่ที่ตามมา | นำคำสั่งออกทันที |
| ปฏิเสธ | เหตุผลและควรลองส่งใหม่หรือไม่ | สมมติว่าการเทรดตามที่ร้องขอเกิดขึ้นแล้ว |
| หมดอายุ | เวลาที่คำสั่งหมดสิทธิ์ถูกจับคู่ | ปล่อยให้เปิดอยู่จนกว่าราคาจะมาแตะในภายหลัง |
จะเปรียบเทียบการเทรดใน Backtest กับ Paper Trading ให้เป็นธรรมได้อย่างไร?
เปรียบเทียบเหตุการณ์คำสั่งก่อน แล้วจึงดูสถานะถือครอง และดู P&L เป็นลำดับสุดท้าย หาก Backtest จับคู่คำสั่งที่บัญชี paper ไม่เคยจับคู่ได้ ความแตกต่างของ P&L ในภายหลังเป็นผลที่ตามมา ไม่ใช่จุดเริ่มต้นในการวินิจฉัยปัญหา
สำหรับทุกคำสั่งที่ตั้งใจส่ง ให้จับคู่การรันทดสอบทั้งสองชุดด้วยรหัสการตัดสินใจของกลยุทธ์หรือรหัสคำสั่งที่คงที่ จากนั้นตรวจสอบเวลาส่ง ราคาและปริมาณที่ร้องขอ ระยะเวลาที่คำสั่งมีผล การจับคู่ การยกเลิก การปฏิเสธ ค่าธรรมเนียม และสถานะถือครองสุดท้าย รวมถึงเก็บเหตุผลที่จำลองว่าไม่ถูกจับคู่ไว้ด้วย เช่น ราคาไม่เคยถึง Limit สมมติว่าคิวด้านหน้าของเรายังไม่ถูกจับคู่หมด หรือคำสั่งหมดอายุ
ตัวอย่างสั้น ๆ ช่วยให้เห็นลำดับเหตุการณ์ชัดเจน สัญญาณต้องการ 10 หน่วย ทั้งสองระบบส่งคำสั่งตอน 10:00:00 Backtest สมมติว่าจับคู่ครบตอน 10:00:01 ส่วน Paper Trading จับคู่ได้ 4 หน่วยตอน 10:00:01 ได้รับคำขอยกเลิกตอน 10:00:02 แล้วรายงานว่าจับคู่เพิ่มอีก 2 หน่วยก่อนยืนยันการยกเลิกตอน 10:00:03 การเปรียบเทียบที่ตรงไปตรงมาคือจับคู่ได้ 6 หน่วยเทียบกับ 10 หน่วย โดยยกเลิกไป 4 หน่วย การเฉลี่ยทุกอย่างรวมเป็น “การเทรด” รายการเดียวจะบดบังความเสี่ยงที่กลยุทธ์ถืออยู่จริง
ต้องมี Exchange Simulator เต็มรูปแบบเพื่อทำให้ถูกต้องไหม?
ไม่จำเป็น Backtest เริ่มจากสมมติฐานที่ระบุชัดเจนเพียงไม่กี่ข้อได้ เช่น การแตะราคา Limit เพียงพอหรือไม่ ปริมาณซื้อขายต้องผ่านราคามากเท่าใดจึงจะถือว่าคิวที่สมมติไว้ด้านหน้าถูกจับคู่หมด คำสั่งเปิดค้างไว้นานเท่าใด และจำลองความหน่วงในการยกเลิกอย่างไร ทดลองรันกลยุทธ์ภายใต้การตั้งค่าที่เป็นไปได้มากกว่าหนึ่งแบบ หากผลการดำเนินงานขึ้นอยู่กับการจับคู่คำสั่ง Limit ที่ค้างอยู่ทุกคำสั่งแบบเต็มจำนวน คุณก็ได้เรียนรู้สิ่งสำคัญเกี่ยวกับแบบจำลองแล้ว
Paper Trading ก็ไม่ใช่ข้อมูลจริงที่ใช้ตัดสินคุณภาพการส่งคำสั่งซื้อขายได้เสมอไป เพราะอาจใช้การจับคู่จำลองและไม่มีคิวจริง ประโยชน์ของมันในที่นี้มีขอบเขตกว่า คือช่วยให้เห็นว่ากลยุทธ์กับตัวจัดการคำสั่งเข้าใจปริมาณคงค้าง การยกเลิก สถานะถือครอง และการลองส่งใหม่ตรงกันหรือไม่ เมื่อเหตุการณ์ต่าง ๆ เข้ามาตามเวลา
ข้อดีเล็ก ๆ ของงานนี้คือ บันทึกคำสั่งที่ดีทำให้ความคลาดเคลื่อนที่เคยชวนงงกลายเป็นเรื่องธรรมดาได้ “คำสั่งย่อยรายการที่ 2 ถูกจับคู่หลังส่งคำขอยกเลิก” ชัดเจนกว่า “Paper Trading ดูแปลก ๆ” เมื่อ Backtest กับบัญชี paper ให้ผลไม่ตรงกัน ให้ไล่ดูวงจรชีวิตของคำสั่งก่อนแก้สัญญาณ
← บทความทั้งหมด
