Backtest ที่ตรวจสอบได้สำหรับ Perpetual Futures (AutoQuant)

แก่นของเรื่อง

ถ้าจำได้อย่างเดียว ให้จำประโยคนี้ (สรุปของเรา จากข้อเท็จจริงในหน้านี้): ผล backtest เชื่อได้เท่ากับกฎที่ล็อกไว้ก่อนเห็นผล ถ้ากฎ execution, ต้นทุน และบทบาทของแต่ละ window ไม่ถูกล็อก ผู้ชนะที่เลือกได้อาจเป็นผลของการลองหลายครั้ง ไม่ใช่ความสามารถของกลยุทธ์

ทำไมถึงได้ผล

1. การเลือก config ที่ดีที่สุดจากหลายชุดบนข้อมูลชุดเดียว ทำให้ผู้ชนะมีโชคปนอยู่ ยิ่งลองมากยิ่งพอง (เหตุผลเดียวกับที่ PBO และ DSR ถูกสร้างมาวัด) (p.53-54)
2. ต้นทุนของ perpetual futures เกิดตาม turnover และตามเวลาที่ถือ position ถ้าไม่ใส่ จะพองไม่เท่ากันทุก config ลำดับผู้ชนะจึงเปลี่ยนได้ (p.57 ระบุว่าลำดับ candidate เปลี่ยนได้ แต่ไม่มีตารางแสดง)
3. ถ้า window ที่ใช้เลือกถูกเรียกว่า out-of-sample ตัวเลขที่รายงานก็ไม่เป็นอิสระจากการเลือก (p.52)
4. การล็อกกฎล่วงหน้าไม่ได้ทำให้กลยุทธ์ดีขึ้น มันทำให้ตัวเลขที่ออกมาตรงกับสิ่งที่จะเกิดขึ้นจริงมากขึ้น แล้วจึงรู้ว่ากลยุทธ์ดีหรือไม่

20% ที่สำคัญที่สุดในการใช้งานจริง

ยังไม่ต้องทำในรอบแรก: Bayesian optimizer (random หรือ grid ก็ใช้ pipeline เดียวกันได้ p.15), Live guard, DSR และ PBO ส่วนนี้เพิ่มเมื่อ pipeline สร้างผลซ้ำได้แล้ว (ข้อเสนอของเรา)

ช่วยให้ดีขึ้นอย่างไร

แต่ละแถวบอกว่าอะไรดีขึ้น เท่าไร และหลักฐานระดับไหน

อ่านแล้วได้ข้อสรุปสามข้อ

• ได้ผลชัดที่สุด: ต้นทุนครบทำให้ผลที่เห็นลดลงเกินหนึ่งในสาม เป็นขั้นที่ควรทำก่อนอย่างอื่น
• ได้ผลด้านความเสี่ยง ไม่ใช่ผลตอบแทน: Stage II ลด drawdown ใน 10 จาก 12 window แต่ไม่ได้เพิ่มกำไร
• ยังพิสูจน์ไม่ได้: ว่าผลที่ผ่านทุกด่านจะทำกำไรจริง PBO ยังสูง และ blind hold-out ของ BTC ที่ buy-and-hold ชนะ

ลองใช้

ตัวอย่างประกอบ: ต้นทุนกินผลไปเท่าไร

ตัวเลขนี้เป็นเลขคณิตจากค่าที่รายงาน ไม่ใช่ผลทดลองของ pipeline

ค่าที่ใช้มาจาก p.34 (fee 4 bps, slippage 2 bps, funding fallback 1 bp ต่อ 8 ชั่วโมง) และ p.45 (636 trades) สมมติฐาน [ASSUMPTION]: ขนาดการเปลี่ยน position ต่อครั้งเป็น 1 หน่วย ซึ่งในงานจริงต่างกันตาม exposure ที่ถูกลดหรือสมูท และ funding จริงเปลี่ยนตามตลาด (fallback เป็นค่าคงที่แบบระวังไว้ก่อน) ใช้ตัวเลขนี้เพื่อให้เห็นลำดับขนาดเท่านั้น ไม่ใช่การประเมินต้นทุนจริงของ config นั้น

ข้อสังเกต: ในสมมติฐานนี้ funding ที่ถือเต็ม 1 เท่าตลอด (ราว 11% ต่อปี) กับ fee รวม slippage (ราว 16.5% ต่อปี) มีขนาดใกล้กัน ถ้าตัดช่องใดช่องหนึ่งออกจะมองผลดีเกินจริง

ใช้เมื่อไหร่

ก้าวแรกที่เล็กที่สุด

รัน backtest ของ config ที่มีอยู่ 3 รอบด้วยสัญญาณและ engine เดียวกัน: ไม่มีต้นทุน, เฉพาะ fee, ต้นทุนครบ แล้วดูว่าตัวเลขลดลงเท่าไร

วิธียืนยันว่าดีขึ้นจริง (ข้อเสนอของเรา)

ทดสอบความเข้าใจ

Core concepts

ต้นทุนและ execution ของ perpetual futures ต่างจากตลาดหุ้น จึงต้องรู้ก่อนว่า backtest พองได้จากช่องไหนบ้าง

แหล่งที่ทำให้ backtest พอง

STRICT4H: กฎ execution ที่ล็อกไว้

• t+1: สัญญาณคำนวณที่ปิดแท่ง t มีผลตั้งแต่แท่ง t+1 เท่านั้น ห้าม execute ในแท่งเดียวกัน (p.19)
• Funding carry-forward: ค่า funding ที่เห็นที่เวลา tau ใช้ได้ตั้งแต่แท่งถัดไป ห้ามเติมย้อนหลังจากค่าใหม่ (p.19, p.34)
• Cap โดยโครงสร้าง: ถ้าสัญญาณทำให้ position เกิน leverage หรือ notional cap engine จะลดขนาดเทรดลงให้พอดี ไม่ปฏิเสธเทรด (p.35)
• ข้อมูลต้องต่อเนื่อง: ไม่ interpolate หรือ forward-fill แท่งที่หาย พบช่องว่างเกินเกณฑ์ (ปกติ 0) pipeline หยุด (p.31-32)

การแยกส่วนแบบ expert system

AutoQuant เรียกตัวเองว่า expert-system-like ในความหมายของกฎที่เขียนชัดและตรวจสอบได้ ไม่ได้อ้างว่าคิดค้นการให้เหตุผลเชิงสัญลักษณ์ (p.8)

บทบาทของแต่ละ window

ช่วง 2023 ของ BTC ถูกเว้นไว้เพื่อแยก window เลือกออกจาก hold-out (p.37)

Important Validation ไม่ใช่ out-of-sample เต็มรูป เพราะ Stage II ใช้มันเลือก candidate ตัวเลขบน validation จึงอ่านเป็นการตรวจความทนทาน ส่วน window เดียวที่ไม่เคยถูกใช้คือ blind hold-out (p.30, p.52)

How it works

รูปที่ 1 (p.10): ข้อมูลและโมเดลต้นทุน เข้า Stage I ได้ candidate pool ส่งเข้า Stage II ได้ stable candidates ซึ่งอยู่ภายใต้ guard ส่วน Stage II ต่อกับ accounting invariants

1. ตั้งโมเดลต้นทุนก่อนค้นหา

ผลสุทธิต่อแท่งคือ (p.20, p.22)

r_net(t) = r_raw(t) - C_fee(t) - C_slip(t) - C_fund(t)
r_raw(t) = pi(t) * r_mkt(t)          # pi(t) มาจากสัญญาณของแท่ง t-1
C_fee(t)  = |d_pi(t)| * f_eff        # f_eff = taker fee (maker ratio = 0)
C_slip(t) = |d_pi(t)| * s            # s = slippage_bps / 10000 * multiplier
C_fund(t) = pi(t) * fr_8h(t) * (dh / 8)    # dh = 4 ชั่วโมง

Fallback ของ funding คือ 1 bps ต่อ 8 ชั่วโมง ใช้เมื่อไม่มีชุดข้อมูลจริง (p.34) ไม่มี maker rebate ในโมเดล จึงเอนไปทางประเมินต้นทุนสูงกว่าจริง (p.34)

2. กำหนดครอบครัวสัญญาณ (ไม่สร้างสัญญาณใหม่)

สัญญาณถูกมองเป็น black box ที่ map ข้อมูลกับ hyperparameter เป็น {-1, 0, +1} ใน case study ใช้ momentum จาก EMA เร็วและช้า ผสมกับ mean-reversion (p.12)

m(t)  = 0.5 * (1 + tanh((EMA_fast - EMA_slow) / (sigma(theta) * EMA_slow)))
C(t)  = w_mom * m(t) + (1 - w_mom) * a(t)        # a(t) = max ของ sub-score mean-reversion
signal = +1 if C >= tau_long ; -1 if C <= 1 - tau_short ; 0 otherwise
tau_long(t) = tau_base + kappa * max(|fr(t)| - theta_bias/10000, 0)

ถ้า kappa = 0 กลไกปรับ threshold ตาม funding จะปิด (p.13) ช่วงค้นหาหลัก เช่น ema_fast 6-32, ema_slow 20-96, bb_period 10-30, min_hold_bars 1-6 และพารามิเตอร์ risk หลายตัวที่ค่าเริ่มต้น 0 คือปิด (Table 3, p.17)

3. Stage I: Bayesian search

1. ใช้ TPE (Optuna) บน training window ใต้ต้นทุน baseline (p.14-15)
2. เป้าหมายเดียวคือ CAGR สุทธิ rann = (1 + Rtot)^(AF/N) - 1 โดย AF = 2190 (6 แท่งต่อวัน x 365) (p.14)
3. ไม่ใส่เงื่อนไข drawdown ใน Stage I เพื่อไม่ฝังความชอบด้านความเสี่ยงลงใน sampler (p.15)
4. เก็บ candidate ที่คะแนนสูงสุด K ตัวเป็น pool (p.11)

TPE ถูกเลือกเพราะพื้นที่ค้นหามีทั้งค่าต่อเนื่อง ค่าไม่ต่อเนื่อง และบล็อกที่เปิดปิดได้ (p.15) sampler สลับเป็นตัวอื่นได้โดยไม่แตะกฎ execution (p.15)

4. Stage II: double screening

ไม่ optimize ซ้ำ เพียงกรอง pool เดิมด้วยสองสาย (p.20)

1. Held-out window: ประเมินทุก candidate บน rolling window ยาว 2000 แท่ง เลื่อนทีละ 500 แท่ง ไม่ train ใหม่ในแต่ละ window
2. Cost scenario: ตาราง taker_bps {3, 4, 6} x fund_mult {0.5, 1.0, 1.5} รวม 9 สถานการณ์ และ stress เพิ่ม fee กับ slippage 2x/3x กับกรณีปิด funding

5. กฎเลือก stable candidate

รวมค่าทุกสถานการณ์ต้นทุน แล้วกรองด้วยเกณฑ์ที่ตั้งไว้ล่วงหน้า (Table 8, p.23)

ผู้ผ่านเกณฑ์ถูกเรียงตาม mean_monthly_true จากมากไปน้อย แล้ว maxDD_mean จากน้อยไปมาก เลือก K = 5 (p.23) ค่ารายเดือนคำนวณจากผลตอบแทนรวมรายเดือนของ r_net (p.22)

6. Accounting invariants และ Live guard

• Invariant: exposure, fee, slippage, funding สุทธิ และ PnL ต้อง reconcile ภายใน tolerance ระหว่าง backtest, paper trading และ log การรันที่ใช้ code path เดียวกัน (p.22-23)
• Guard: เฝ้าผลตอบแทน 30 และ 90 วัน, drawdown จากจุดสูง, ขาดทุนรายวันสูงสุด และความถี่เทรด แล้วออกคำสั่ง ok, watch หรือ kill โดย kill จะปิด position และอาจหยุดเทรดจนกว่าจะสั่งต่อด้วยมือ (p.23-24)
• สถานะหลักฐาน: guard เป็นแบบแผนที่มีหลักฐานจำกัดเฉพาะ config ไม่มีสถิติ track record ระยะยาว (p.24) ค่าเกณฑ์ที่ทำให้เป็น watch หรือ kill ไม่ปรากฏในข้อความที่สกัดได้

7. ตรวจ multiple testing

• DSR: จำนวน trial ที่มีผล Ntotal อยู่ระหว่าง Nopt x Nwindows ถึง Nopt x Nwindows x Nscen = 40 x 9 = 360 ถึง 40 x 9 x 9 = 3,240 (p.24)
• CSCV/PBO: แบ่งผลรายเดือนเป็น 8 ช่วง 70 combinatorial splits บน top-40 ของ Stage I (p.25)

Evidence

ตัวเลขด้านล่างมาจากตารางที่รายงานโดยตรง ยกเว้นแถวที่ระบุว่าคำนวณเอง ทุก config ต่างกันตามตาราง จึงห้ามเทียบข้ามตารางโดยไม่ดูว่าใช้ config ไหน

ต้นทุนทำให้ผลพองเท่าไร

Config stress test หนึ่งตัว บน BTC core sample (2019-09-08 ถึง 2021-12-31) CAGR เป็นทศนิยม 2.726 หมายถึง 272.6% ต่อปี (p.45)

คำนวณเอง: CAGR ของ Standard สูงกว่า Rigorous 1.58 เท่า และ Naive สูงกว่า 1.92 เท่า การผ่อน cap ของ leverage ไม่เปลี่ยนตัวเลขใน snapshot นี้ (p.44-45)

Baseline เดี่ยว แยกตาม window

Baseline ที่ freeze หลัง Stage I ผลตอบแทนพลิกจากบวกเป็นลบเมื่อเข้า validation (Table 14, p.39)

One-stage เทียบ two-stage (BTC)

ผลตอบแทนรายเดือนแบบ geometric เป็นทศนิยม (Table 15, p.41)

Buy-and-hold เหนือทั้งสอง config ใน post-ETF ส่วน validation buy-and-hold ติดลบ (-0.024) และ MaxDD 0.771 (p.41)

Bootstrap แบบ moving block (block 3 เดือน) ของผลต่างรายเดือน two-stage ลบ one-stage บน validation ได้ -0.016 ช่วงเชื่อมั่น 95% คือ [-0.040, 0.008] ซึ่งคร่อมศูนย์ (Table 16, p.43)

สินทรัพย์อื่น

ตาราง 19 และ 20 (p.46, p.48) ใช้ครอบครัวสัญญาณเดียวกันและต้นทุนที่เข้มกว่าสำหรับ mid-cap

นับเองจาก Table 15, 19, 20 AVAX เห็นต่างสุด: MaxDD one-stage 0.795 กับ two-stage 0.055 บน training (p.48)

Execution semantics และการตรวจภายใน

Drawdown-bucket risk budgeting

ลด exposure ใน bucket ที่ drawdown ลึกขึ้น เทียบ baseline บน window ยาว (Table 22, p.49)

Diagnostic overfitting

Figures

รูปที่ 3: เส้นราบยาวหมายถึงช่วงที่ไม่มี position ค่าจากแกน log เป็นการอ่านด้วยสายตา ไม่ใช่ตัวเลขที่ระบุ

Critical analysis

แยกข้อเท็จจริง ความเห็น และการตีความ

จุดที่อ่านแล้วไม่ลงรอยหรือยังไม่ชัด

• Baseline ที่บอกว่าเป็น "production-oriented" ขาดทุน 24.09% ต่อปี และ MaxDD 0.95 บน window ยาว (p.38-39) ส่วน config ในตารางอื่นให้ผลดีกว่ามาก จึงเทียบข้ามตารางไม่ได้
• Threshold ที่เข้มกว่าไม่ได้ให้ MaxDD ต่ำกว่า: เพดาน 0.25 เลือก trial 87 ซึ่ง MaxDD บน validation = 0.386 เทียบกับเพดาน 0.30 ที่ได้ 0.231 (Table 17, p.44) เพราะตัวกรองวัดค่าเฉลี่ยข้ามสถานการณ์บน training+validation ไม่ใช่ validation เดียว
• ผล validation ที่เลือกเปลี่ยนตาม threshold: CAGR 0.332-1.058, Sharpe 0.844-1.667, MaxDD 0.209-0.386 จาก 27 นโยบาย (p.43) ผลจึงมาจากการเลือก threshold พอ ๆ กับการเลือก config
• Random search ใน Table 5 ให้ -1.0 ที่ 10 trials และค่าเดียวกัน (-0.7832 +- 0.4848) ที่ 20, 40 และ 60 trials จำนวน seed ไม่ระบุ จึงอ่านความแรงของ TPE จากตารางนี้ยาก (p.18)
• Funding gate ไม่เปลี่ยนผลบน validation (0.004 และ MaxDD 0.365 เท่ากันทั้งคู่) ผลบวกมีเฉพาะ training และเป็น trial เดียว (p.20)
• Cross-asset (Table 21, p.48): CAGR 0.44% บน ETH และ -0.17% บน BTC ด้วย 3,100 และ 3,403 เทรด ซึ่งใกล้ศูนย์ ข้อความเรียกว่า "robustness" แต่ตัวเลขไม่ได้แสดงกำไร หน่วยในตารางคือ % จึงควรระวังเวลาเทียบกับตารางที่ใช้ทศนิยม
• Risk budgeting เปลี่ยนผล -24.09% เป็น +0.37% ถึง +8.46% และ MaxDD ยังสูง 0.695-0.810 (p.49) รายงานบน window ยาวเดียว ไม่มี hold-out แยก
• ตารางเทียบกับเฟรมเวิร์กอื่น (Table 1, p.6) ประเมินจากเอกสารและการใช้งานทั่วไป ไม่ใช่การทดสอบ

Risks and limits

Warning ผลตอบแทนทั้งหมดมาจาก backtest บัญชีเล็กภายใต้ต้นทุนเชิงเส้น ไม่มี market impact และ capacity ค่า CAGR ที่เกิน 1.0 (100% ต่อปี) เป็นตัวชี้วัดความไวต่อต้นทุนและ window ไม่ใช่ความสามารถทำกำไรที่ขยายได้ (p.7, p.56)

การทดลอง ATR guard บนแท่ง 1 ถึง 60 นาทีไม่พบการปรับปรุงที่ชัดเจนหลังหัก fee และ slippage (p.62) ซึ่งเป็นหลักฐานเสริมของกรอบ 4 ชั่วโมง ไม่ใช่ผลหลักที่รายงาน

Applying it

ขั้นตอน 1-6 ปรับจากโปรโตคอลห้าข้อที่ระบุไว้ (p.51) ส่วนเกณฑ์ตรวจและข้อผิดพลาดที่พบบ่อยเป็นข้อเสนอเพิ่มของเรา

ขั้นตอน

1. ตรวจข้อมูลต่อเนื่องและกำหนดโปรไฟล์ต้นทุนกับ cap ให้ตายตัวก่อนเริ่มค้นหา
2. ตรึง execution: t+1, funding carry-forward, cap ที่บังคับเมื่อสร้าง order
3. รัน Bayesian search บน training window เท่านั้น ตั้งงบ trial ล่วงหน้า
4. ประเมิน candidate pool เดิมบนหลาย window และกริดต้นทุน โดยไม่ปรับพารามิเตอร์ซ้ำ
5. กรองด้วย threshold ที่เขียนไว้ก่อนเห็นผล เรียงตามเกณฑ์ที่ประกาศ
6. อ่านผลร่วมกับ DSR และ PBO ตรวจ invariant ระหว่าง backtest กับ replay แล้วจึงตั้ง guard

เกณฑ์ตรวจ (ข้อเสนอเพิ่มเติม)

ข้อผิดพลาดที่พบบ่อย (ข้อเสนอเพิ่มเติม)

• รายงานผล validation เป็น out-of-sample หลังใช้มันกรองแล้ว
• เทียบตัวเลขจากต่าง config หรือ window เหมือนเป็นการทดลองเดียว
• เชื่อ CAGR ทศนิยมที่เกิน 1.0 โดยไม่ดู drawdown และ cost ladder
• ปรับ threshold หลังเห็น hold-out
• สรุปว่า guard ปลอดภัยแล้วโดยยังไม่มีเกณฑ์ที่ทดสอบจริง

Recommendation ถ้านำแนวคิดนี้ไปใช้ ให้เริ่มจากสิ่งที่ตรวจสอบได้ถูกที่สุดก่อน: ตรึงกฎ execution และต้นทุน, ทำ cost ladder, ส่งออก ledger รายแท่ง ส่วน Stage II และ PBO ค่อยเพิ่มเมื่อมี pipeline ที่สร้างผลซ้ำได้แล้ว นี่เป็นคำแนะนำของเรา ไม่ใช่ข้อความที่ระบุไว้

Checklist

สถานะ: 🟢 ผ่าน, 🟡 บางส่วน, 🔴 ไม่ผ่าน, ⚪ ยังไม่ตรวจ

Glossary

Page map

Sources

• Journal of Computational Finance (2017): วิธี CSCV และ Probability of Backtest Overfitting
• Journal of Portfolio Management (2014): Deflated Sharpe Ratio
• Advances in Neural Information Processing Systems (2011): TPE สำหรับ hyper-parameter search
• ACM SIGKDD (2019): Optuna
• Annals of Statistics (1989): moving block bootstrap

ตัวย่อที่ใช้ในหน้านี้

หน้านี้ใช้ตัวย่อทั้งหน้า ตารางนี้อธิบายตัวย่อทุกตัวที่ใช้ในหน้านี้ เรียงตามกลุ่ม

ตัวชี้วัดผลลัพธ์

ตัวตรวจ overfitting และสถิติ

ตัวย่อด้านวิธีและข้อมูล

หน่วยและสินทรัพย์

แถวที่มาจากความรู้ทั่วไป ไม่ใช่นิยามที่งานให้ไว้: bps, USDT, สัญลักษณ์เหรียญ, EMA, ATR, CI, BO, CPU/GPU และคำอธิบาย Sharpe

Summary

AutoQuant ไม่ใช่กลยุทธ์ใหม่ และไม่ได้พิสูจน์ว่ามี alpha ถาวร (p.1-2) มันเป็นชุดกฎกับขั้นตอนที่ล็อก execution, funding และต้นทุนไว้ก่อน แล้วเลือกพารามิเตอร์ของสัญญาณที่กำหนดไว้แล้วภายใต้กฎเหล่านั้น พร้อมส่งออกไฟล์ที่ตรวจย้อนได้ทุกแท่ง (p.5-7)

• ปัญหา: backtest ของ perpetual futures พองง่ายเมื่อมองข้าม fee, funding, slippage และ cap ของ leverage หรือเมื่อใช้ window เดิมซ้ำตอนเลือกพารามิเตอร์ (p.1-2)
• วิธี: Stage I ใช้ Bayesian search (TPE) บน training window, Stage II กรอง candidate เดิมข้ามหลาย window และหลายสถานการณ์ต้นทุนโดยไม่ optimize ซ้ำ (p.19-21)
• ผลที่สำคัญ: ตัดต้นทุนออกแล้ว CAGR ของ config เดียวกันเพิ่มจาก 2.726 เป็น 4.308 (เหลือแค่ fee) และ 5.225 (ไม่มีต้นทุน) (p.45)
• สิ่งที่ Stage II ให้: MaxDD ต่ำกว่า one-stage ใน 10 จาก 12 window ที่รายงาน ไม่ได้ให้ผลตอบแทนสูงกว่า (นับจากตาราง p.41, 46, 48)
• สิ่งที่ยังไม่ผ่าน: PBO = 0.586 และ DSR ไม่ปฏิเสธ Sharpe จริงเป็นศูนย์ แปลว่ายังเสี่ยง overfit สูง (p.25)