สแนปช็อตข้อมูลตลาดที่ตรึงไว้ยังไม่เพียงพอที่จะทำให้แบ็กเทสต์น่าเชื่อถือ เพราะมันอาจให้คำตอบเดิมซ้ำได้ ทั้งที่ซ่อนอยู่ว่าผู้ให้บริการเปลี่ยนข้อมูลที่ใช้คำนวณผลลัพธ์นั้นไปแล้ว
เก็บสแนปช็อตไว้ แล้วทำบันทึกการเปลี่ยนแปลงที่บอกได้ว่าอะไรเปลี่ยน เปลี่ยนเมื่อไร และกลยุทธ์ได้รับผลกระทบหรือไม่ เรื่องนี้สำคัญที่สุดเมื่องานวิจัยของเราใช้รายการซื้อขายที่แก้ไขแล้ว ข้อมูลพื้นฐานที่ปรับปรุงใหม่ อัตรา funding ที่สร้างย้อนหลัง หรือข้อมูลย้อนหลังที่ผู้ให้บริการปรับปรุงเงียบ ๆ
ทำไมแบ็กเทสต์ที่ทำซ้ำได้ยังอาจทำให้เข้าใจผิด?
สมมติว่าคุณดาวน์โหลดแท่งข้อมูลรายชั่วโมงย้อนหลัง 5 ปีในวันจันทร์ แล้วรันกลยุทธ์หนึ่ง ในวันศุกร์ ผู้ให้บริการแก้รายการซื้อขายที่ผิด ปรับ corporate action หรือเติมข้อมูลช่วงที่ขาดหาย ไฟล์ที่คุณบันทึกไว้ยังคงให้ผลลัพธ์ของวันจันทร์ได้เหมือนเดิม นั่นคือทำซ้ำได้ แต่ถ้าคุณรันใหม่ด้วยข้อมูลย้อนหลังปัจจุบันจากผู้ให้บริการ ผลลัพธ์อาจต่างออกไป และคุณก็ไม่มีบันทึกว่าเพราะอะไร
ปัญหาไม่ได้จำกัดอยู่แค่การแก้ไขครั้งใหญ่ จุดสูงสุดที่เปลี่ยนไปเพียงจุดเดียวอาจทำให้เกิดคำสั่งหยุดขาดทุน ราคาปิดที่ปรับใหม่อาจทำให้ตัวบ่งชี้ข้ามเกณฑ์ ในจักรวาลสินทรัพย์ขนาดใหญ่ ข้อมูลย้อนหลังของสัญลักษณ์หนึ่งอาจเปลี่ยนอันดับและดันสินทรัพย์อีกตัวออกจากพอร์ต ค่า Sharpe สุดท้ายอาจค่อย ๆ เปลี่ยน แม้โค้ดกลยุทธ์และการตั้งค่าจะเหมือนเดิมทุกประการ
ค่าแฮชของไฟล์บอกคุณได้ว่าไฟล์ 2 ไฟล์แตกต่างกัน แต่ไม่ได้บอกว่าการปรับราคาจากการแตกพาร์เปลี่ยนราคาย้อนหลัง 40 ปี ผู้ให้บริการแก้รายการซื้อขาย 3 รายการ หรือ parser เปลี่ยนฟิลด์ว่างให้เป็นศูนย์
บันทึกการเปลี่ยนแปลงข้อมูลตลาดควรมีอะไรบ้าง?
บันทึกการเปลี่ยนแปลงในหน่วยย่อยที่สุดที่ยังเป็นประโยชน์ พร้อมบริบทมากพอที่จะรันงานวิจัยส่วนที่ได้รับผลกระทบซ้ำได้ สำหรับฟีดแท่งข้อมูล โดยทั่วไปควรมีตราสาร ช่วงเวลา เวลาเกิดเหตุ ค่าเดิมและค่าใหม่ แหล่งที่มา และเวลาที่คุณพบการอัปเดต เก็บ payload ต้นฉบับไว้เมื่อผู้ให้บริการส่งมาให้
| รายการที่บันทึก | เหตุผลที่ควรเก็บ | ตัวอย่าง |
|---|---|---|
| เวอร์ชันของแหล่งข้อมูลหรือเวลาที่ดึงข้อมูล | ระบุสถานะข้อมูลของผู้ให้บริการที่ใช้ | สแนปช็อตที่ดึงเมื่อ 2026-11-02 08:15 UTC |
| ฟิลด์ที่เปลี่ยนและค่าเดิม/ค่าใหม่ | แสดงให้เห็นว่าอะไรเปลี่ยนจริง | ETHUSDT 1h high: 3,412.10 → 3,418.60 |
| ประเภทการเปลี่ยนแปลง | แยกการแก้ไขข้อมูลออกจากการแปลงข้อมูล | แก้รายการซื้อขายล่าช้า, ปรับจากการแตกพาร์, เติมข้อมูลย้อนหลัง |
| เวอร์ชันของ pipeline และ schema | แยกการแก้ไขจากแหล่งข้อมูลออกจากการประมวลผลของคุณเอง | Normalizer v7, schema แท่งข้อมูลที่ปรับแล้ว v3 |
สำหรับชุดข้อมูลขนาดใหญ่ ให้เก็บสแนปช็อตที่แก้ไขไม่ได้ พร้อม manifest แบบกระชับที่ระบุ checksum เวอร์ชันของแหล่งข้อมูล และเวลาที่ดึงข้อมูล เพิ่ม diff ระดับแถวสำหรับพาร์ทิชันที่เปลี่ยน วิธีนี้เป็นจุดกึ่งกลางที่ใช้งานได้จริง: ยังรันซ้ำได้เต็มรูปแบบโดยไม่ต้องเขียนทุกแถวที่ไม่เปลี่ยนลงในตารางตรวจสอบอีกชุด
จะวัดได้อย่างไรว่าการแก้ไขข้อมูลมีผลหรือไม่?
อย่าหยุดแค่นับจำนวนแถวที่เปลี่ยน ให้รันกลยุทธ์ที่ได้รับผลกระทบซ้ำด้วยข้อมูลเก่าและข้อมูลใหม่ โดยใช้โค้ด พารามิเตอร์ ค่าธรรมเนียม และสมมติฐานการส่งคำสั่งชุดเดียวกัน แล้วเปรียบเทียบการตัดสินใจและเส้นทางที่นำไปสู่ผลลัพธ์
- ระบุตราสารและเวลาเกิดเหตุที่ได้รับผลกระทบจาก diff
- ตรวจสอบว่าฟีเจอร์ สัญญาณ คำสั่ง หรือสัดส่วนการลงทุนในพอร์ตใดใช้ข้อมูลเหล่านั้น
- รันซ้ำในช่วงเวลาที่เล็กที่สุดซึ่งยังถูกต้อง โดยรวม lookback และสถานะสถานะที่เปิดอยู่ด้วย
- เปรียบเทียบคำสั่ง การจับคู่คำสั่ง ระดับความเสี่ยง มูลค่าการซื้อขายสูงสุด การขาดทุนสูงสุด และผลการดำเนินงานสุดท้าย
ตัวอย่างเช่น การแก้ไขจากผู้ให้บริการที่เปลี่ยนจุดสูงสุดของแท่ง 1-minute ไป $0.02 อาจแตะข้อมูล 1 ล้านแถว แต่ไม่มีผลต่อกลยุทธ์โมเมนตัมรายวันเลย แท่งข้อมูลเพียงแท่งเดียวที่แก้ตรงระดับราคาหยุดขาดทุนอาจมีผลมากกว่า ให้วัดผลกระทบต่อการตัดสินใจ เพราะจำนวนระเบียนที่เปลี่ยนเป็นตัวแทนที่ไม่ดีของผลกระทบนั้น
แยกคำถาม 2 ข้อนี้ออกจากกัน: “ฉันสร้างผลลัพธ์ซ้ำจากข้อมูลที่บันทึกไว้ได้หรือไม่?” และ “ข้อมูลเวอร์ชันนี้จะมีให้กลยุทธ์ใช้ในเวลานั้นหรือไม่?” บันทึกการเปลี่ยนแปลงช่วยตอบได้ทั้ง 2 ข้อ แต่ข้อที่ 2 ยังต้องมีบันทึกความพร้อมใช้งานตามช่วงเวลาด้วย
การติดตามการเปลี่ยนแปลงมีต้นทุนเท่าไร และคุ้มค่าเมื่อไร?
การติดตามการเปลี่ยนแปลงเพิ่มทั้งพื้นที่จัดเก็บ งานนำเข้าข้อมูล และภาระในการตัดสินใจด้านการปฏิบัติงาน ผู้ให้บริการอาจไม่มีเวอร์ชันที่คงที่ และฟีดข้อมูลย้อนหลังบางส่วนถูกสร้างใหม่เป็นระยะโดยไม่มีประกาศการแก้ไขที่ชัดเจน คุณบันทึกการเปลี่ยนแปลงที่ไม่เคยพบไม่ได้
เริ่มจากข้อมูลที่การปรับปรุงอาจเปลี่ยนข้อสรุปของงานวิจัยได้: แท่งข้อมูลที่ใช้กับตรรกะหยุดขาดทุน หุ้นที่ปรับตาม corporate action ข้อมูลพื้นฐานแบบ point-in-time และชุดข้อมูล funding หรือ open interest ที่ถูกสร้างย้อนหลัง สำหรับชุดข้อมูลกว้าง ๆ ที่ค่อนข้างคงที่ manifest รายวันพร้อม checksum ของแต่ละพาร์ทิชันอาจเพียงพอแล้ว เพิ่ม diff ระดับฟิลด์ในจุดที่มีการอัปเดตบ่อยหรือการตัดสินใจซื้อขายไวต่อข้อมูลแต่ละระเบียน
ผู้วิจารณ์พูดถูกว่า คลังถาวรที่เก็บทุกการตอบกลับจากผู้ให้บริการครบถ้วนอาจมีค่าใช้จ่ายสูง และยังจับไม่ได้ว่าต้นทางรู้อะไรในเวลานั้น วิธีแก้คือกำหนดขอบเขตการตรวจสอบให้ครอบคลุมข้อมูลและการตัดสินใจที่สำคัญ พร้อมบันทึกช่องว่างไว้ สแนปช็อตช่วยให้คุณรันการทดลองซ้ำ ส่วนบันทึกการเปลี่ยนแปลงช่วยอธิบายว่าทำไมคำตอบจากการทดลองจึงเปลี่ยนไป
← บทความทั้งหมด
