บล็อก

บทสรุปของซีรีส์เรื่อง search-and-overfit ที่จบลงด้วยผลลบ — และเป็นผลลบที่ถูกต้อง การค้นหาแบบ dual-timeframe บนสัญลักษณ์เดียว (ETHUSDT) พบคอนฟิกที่ทำได้ +16.35% แบบ out-of-sample และ +2.62% บน holdout ที่ไม่เคยถูกแตะต้อง แต่ Deflated Sharpe Ratio ซึ่งคำนวณจากการทดลองราว 37,000 ครั้ง กลับลดค่านั้นเหลือ 0.00 การทดสอบข้ามเครื่องมือ (cross-instrument) กับห้าเหรียญหลัก (ETH/BTC/SOL/BNB/XRP ประมาณ 1.18 ล้านแท่ง 1 นาทีต่อเหรียญ) โดยคัดเลือกด้วยค่ามัธยฐาน (median) ของ out-of-sample ยิ่งตอกย้ำผลลบนี้ให้ชัดเจน: dual DSR 0.24 / PBO 0.264, triple DSR 0.14 / PBO 0.327 — ทั้งคู่ไม่ผ่านเกณฑ์ (gate) แชมป์ทำกำไรได้เพียง 1 ใน 5 สัญลักษณ์ และขาดทุนในที่เหลือ นี่คือเหตุผลที่เครื่องมือต่อต้าน overfitting มีไว้ทำ: เพื่อหยุดไม่ให้คุณนำ noise ที่ดีที่สุดไปขายเป็น alpha

Multi-timeframe backtest รั่วไหลข้อมูลอนาคตผ่านแท่ง (bar) higher-timeframe ที่ยังก่อตัวไม่เสร็จ ซึ่งราคาปิดสุดท้ายยังไม่มีอยู่จริง คุณไม่สามารถอาศัยแค่การ code review เพื่อสร้างความมั่นใจได้ — ต้องทดสอบมันจริง ๆ เราจำลองกฎ closed-bar ของบอทที่รันจริง (live bot) ขึ้นมาใหม่อย่างตรงเป๊ะ แล้วพิสูจน์ว่าไม่มีการรั่วไหลด้วย shifted-future probe: รบกวนทุกแท่งในอนาคต แล้วยืนยันว่าทุกสัญญาณและทุกการเทรดในอดีตไม่เปลี่ยนแปลงแม้แต่บิตเดียว ผ่านการตรวจสอบ parity ครบ 25/25 และ probe นี้ก็มี "เขี้ยวเล็บ" จริง ๆ ด้วย

ความได้เปรียบของ GPU เหนือ CPU เพิ่มขึ้นตามขนาด batch — จาก 54.5x เมื่อประมวลผลทีละหนึ่ง combo ต่อการเรียก ไปจนถึง 359.6x ที่ 61 combo บนการ precompute indicator แบบ multi-timeframe ของเรา — เพราะ sweep ขนาดเล็กไม่สามารถ amortize ต้นทุนคงที่จากการเปิด kernel และการถ่ายโอนข้อมูลได้ เราแยกตัวเลขพาดหัว 167x ออกเป็นชัยชนะจากอัลกอริทึม 27x ที่ช่วย CPU ได้เช่นกัน และชัยชนะจากฮาร์ดแวร์ 6.2x แสดงให้เห็นว่าความได้เปรียบที่แท้จริงของ GPU เทียบกับ CPU ที่ดีที่สุดอยู่ที่เพียง 3.2x สำหรับ single-timeframe และ 6.2x สำหรับ multi พร้อมให้แนวทางตัดสินใจว่า sweep ต้องกว้างแค่ไหนก่อนที่ GPU จะคุ้มค่าที่จะซื้อมาใช้

GPU Metal ของ Apple ไม่มี float64 เลย หากพอร์ต backtest แบบ vectorized ไปใช้อย่างไม่ระวัง สูตร WMA แบบ prefix-sum ที่ดูน่าใช้ที่สุดจะทำให้ fp32 overflow — ค่าความคลาดเคลื่อนสัมพัทธ์สูงสุดถึง 211 เท่า — แต่โปรแกรมก็ยังรันจบและคืนตัวเลขที่ดูสมเหตุสมผลออกมา ทางแก้ไม่ใช่การเพิ่มความแม่นยำ แต่คือการเปลี่ยนสูตรคำนวณ: ใช้ windowed convolution โดยตรง ซึ่งปลอดภัยกับ fp32 ถึงระดับ 8×10⁻⁷ และเร็วกว่า numba แบบ single-thread ถึง 55.9 เท่า กับดักนี้ หลักคณิตศาสตร์เบื้องหลัง และวิธีพิสูจน์ว่าคุณไม่ได้ตกหลุมพราง

การค้นหาแบบ drill-down / multi-fidelity (ASHA, successive halving, Hyperband) คัดกรองค่าคอนฟิกหลายพันแบบด้วยต้นทุนต่ำ และเลื่อนขั้นเฉพาะผู้รอดชีวิตไปสู่การประเมินเต็มรูปแบบที่มีราคาแพง มันคือการเร่งความเร็วที่แท้จริง แต่มันจะพังลงอย่างเงียบๆ หากการจัดอันดับที่ความเที่ยงตรงต่ำไม่สอดคล้องกับการจัดอันดับที่ความเที่ยงตรงสูง เราวัดค่าสหสัมพันธ์อันดับระหว่างโฟลด์ (fold-rank correlation) พบว่าที่หนึ่งโฟลด์ ค่า Spearman ρ อาจอยู่ที่ 0.03 (จัดอันดับแทบจะสุ่ม) แล้วไต่ขึ้นไปที่ 0.43, 0.67, 0.78, 0.91 เมื่อจำนวนโฟลด์เพิ่มขึ้น ทางแก้คือประตูบังคับหนึ่งด่าน นั่นคือวัดค่า ρ(ราคาถูก, เต็มรูปแบบ) ก่อน แล้วปรับความเที่ยงตรงขั้นต่ำขึ้นโดยอัตโนมัติไปยังขั้นแรกที่ ρ ≥ 0.5

เมื่อ backtest หนึ่งครั้งมีต้นทุนต่ำ Sobol แบบ scrambled ที่โง่ ๆ จะชนะด้วย throughput ดิบ — smart sampler (TPE, CMA-ES, ASHA) ต้องจ่าย ask/tell tax ใน Python ที่ทำให้ช้าลง 20 เท่า จึงประเมินจุดได้น้อยกว่ามากเมื่อ wall-clock เท่ากัน และแพ้ไป แต่ถ้าทำให้แต่ละ eval มีต้นทุนสูงขึ้น (multi-TF + walk-forward fold) จุดตัดก็จะพลิกกลับ เราวัดทั้งสองระบอบ และเหตุใด fold-rank fidelity (ρ@1 เพิ่มจาก 0.03→0.43) จึงเป็นเงื่อนไขที่ต้องมีก่อนที่ pruning จะให้ผลตอบแทนคุ้มค่า

พารามิเตอร์แต่ละตัวมีต้นทุนการค้นหาไม่เท่ากัน พารามิเตอร์ของกลยุทธ์แยกออกเป็นแกนราคาแพง (อินดิเคเตอร์ — ต้องคำนวณใหม่ตลอดทั้งซีรีส์ราคา) และแกนราคาถูก (ค่าเกณฑ์ตัดสินใจ — การกวาด O(n) รอบเดียวบนสัญญาณที่คำนวณล่วงหน้า) เพราะอินดิเคเตอร์ไม่แปรผันต่อค่าเกณฑ์ คุณจึงคำนวณมันครั้งเดียวแล้วสวีปคอนฟิกค่าเกณฑ์นับพันที่ ~5,600 cfg/s — ถูกกว่าการคำนวณใหม่ต่อคอนฟิกราว 1,600 เท่า นี่คือการตีราคาคำสาปแห่งมิติเสียใหม่