S1 · ระบบทั้งหมดในหน้าเดียว + กติกา
▶ clip: https://youtu.be/QIGRkFkYecQ
จบบทนี้แล้วทำได้:
- บอกได้ว่างานวิจัย EA หนึ่งชิ้นเดินผ่านขั้นอะไรบ้าง และ Standard สอนขั้นไหน
- บอกได้ว่าแต่ละขั้น "จบ" เมื่อผ่านด่านอะไร และเมื่อไรต้องเดินย้อนกลับ
- จำกติกาสี่ข้อที่ใช้กับทุกงานในคอร์สนี้
- จับได้เมื่อตัวเองกำลังสรุปผิดแบบใดแบบหนึ่งในสามแบบ
ต้องมีก่อน: ติดตั้ง kit ตาม M0-LAB แล้ว · บทนี้ไม่มี lab แต่เปิด research\README.md ใน kit อ่านคู่กันได้ ตารางในบทนี้มาจาก file นั้น
1 · pipeline 10 ขั้น · Standard สอนขั้น 3–5
งานวิจัย EA ทุกชิ้นในระบบนี้เดินเส้นทางเดียวกัน คือขั้น 0 ถึงขั้น 9 (รวม 10 ขั้น)
| ขั้น | ชื่อ | ทำอะไร | สอนใน |
|---|---|---|---|
| 0 | intake | รับ EA เข้ามา จด sha · ตัดตัวซ้ำ | A2 |
| 1 | screen | คัดกรองบนกระดาษ G1 cost · G2 โครงสร้าง | A3 |
| 2 | decode | ถอดกลไกจาก source หรือ log | A4 |
| 3 | prereg | เขียน criteria ไว้ก่อน run | S2 · A1 |
| 4 | backtest | run บน real ticks | S3 · S4 · A6 |
| 5 | verdict | ตัดสินผล · 7 มิติ · R1–R6 | S5–S8 · A7 |
| 6 | release | ใช้ binary ตัวที่ test | A8 |
| 7 | onboarding | ตรวจบัญชีจริง | A9 |
| 8 | forward | สอบยอด · ไม่แทรกแซง | A10 · A11 |
| 9 | evaluate | เทียบกับ backtest | A11 |
บนจอ ขั้นที่มีกรอบเขียวเข้มคือขั้นที่ Standard สอน (3–5) ส่วน Advanced สอนครบทุกขั้น
folder ใน research\ เรียงตามขั้นเหล่านี้ ดังนั้นเปิด folder ก็รู้ทันทีว่างานอยู่ตรงไหน ใน kit มี folder บางขั้นอยู่แล้ว (3-prereg · 6-release · 8-forward · 9-evaluate) ส่วน folder ของขั้นที่เหลือสร้างเพิ่มเมื่อมีงานในขั้นนั้น
หลักที่ต้องถือไว้: งานหนึ่งชิ้นอยู่ได้ขั้นเดียว ไม่ใช่อยู่ครึ่ง ๆ กลาง ๆ ระหว่างสองขั้น ทุกครั้งที่ทำงาน ให้ถามตัวเองสองข้อ
- ตอนนี้งานนี้อยู่ขั้นไหน
- ต้องผ่านอะไรก่อนจึงจะไปขั้นถัดไปได้
ถ้าตอบข้อ 1 ไม่ได้ แปลว่างานกำลังปนกันอยู่ เช่น run backtest ไปแล้วแต่ยังไม่ได้เขียน criteria ซึ่งเท่ากับข้ามขั้น 3 โดยไม่ได้บันทึกว่าข้าม
ของจริงไม่ตรง → ย้อนกลับ ไม่ใช่ tune ทับ (กรอบด้านล่างซ้ายของจอ)
| เจออะไร | ย้อนไปขั้น | ทำไม |
|---|---|---|
| ผลขั้น 5 หรือ 9 ขัดกับกลไกที่ถอดไว้ | 2 · decode | แปลว่าเข้าใจกลไกผิด |
| แก้ code EA | 3 · prereg | version ใหม่คือการทดสอบใหม่ |
| build หรือ preset บนบัญชีไม่ตรงกับที่ test | 6 หรือ 7 | สิ่งที่ run อยู่ไม่ใช่สิ่งที่ test |
2 · ขั้นจบเมื่อผ่านด่าน ไม่ใช่เมื่อทำเสร็จ
"ทำงานเสร็จ" กับ "ผ่านด่าน" คนละเรื่องกัน run backtest จบแล้วไม่ได้แปลว่าขั้น backtest จบ ขั้นจะจบเมื่อผ่านด่านของขั้นนั้นเท่านั้น
| ขั้น | ด่านที่ต้องผ่านก่อนไปขั้นถัดไป | เครื่องมือ |
|---|---|---|
| 3 · prereg | criteria เขียนก่อน run · block IS/OOS จาก is_oos · ลง Šidák correction |
is_oos · tick_years |
| 4 · backtest | history_quality = real ticks · จด cost ของ era นั้น |
run · config_*.yaml |
| 5 · verdict | กวาดครบ 7 มิติ · ผ่าน/ตกตามเกณฑ์ที่เขียนในขั้น 3 | mc |
| 5R · robustness | R1 เวลา · R2 broker · R3 ต้นทุน · R4 การส่งคำสั่ง · R5 parameter · R6 ข้อมูลรบกวน — ผ่าน หรือข้ามพร้อมเหตุผล ครบทุกข้อ | walk · stability · slip_gate · sensitivity |
ชื่อใน column เครื่องมือ = bt\ea-bt.exe <ชื่อ> เช่น bt\ea-bt.exe is_oos · ดูวิธีใช้ทุกตัวด้วย bt\ea-bt.exe <ชื่อ> --help
ขยายความแต่ละด่าน:
- prereg — ช่วงทดสอบต้องเอามาจากเครื่องมือ
is_oosไม่ใช่พิมพ์วันที่เอง (รายละเอียดใน S2) เหตุผลคือถ้าพิมพ์เอง เราเลือกช่วงที่ "ถูกใจ" ได้โดยไม่รู้ตัว - backtest — รายงานต้องใช้ tick จริง (อ่านบรรทัด History Quality ตาม S5) และต้องจด cost ของยุคนั้นไว้ เพราะ spread เปลี่ยนตามยุค ผลที่แย่ลงอาจมาจาก cost ไม่ใช่กลยุทธ์ (S2)
- verdict — กวาดครบเจ็ดมิติก่อนสรุป ลงรายละเอียดใน S7
ข้ามขั้นได้ เมื่อเขียนไว้ว่าข้ามเพราะอะไร ข้ามโดยไม่เขียน = คนที่มาอ่านทีหลัง (รวมถึงตัวคุณเองในอีกสามเดือน) ไม่รู้ว่าด่านนั้นถูกข้ามไป
งานเดินถอยหลังได้:
- ผลที่ออกมาขัดกับกลไกที่ถอดไว้ → กลับขั้น decode
- แก้ code EA แม้บรรทัดเดียว → กลับขั้น prereg เพราะ version ใหม่คือการทดสอบใหม่ทั้งชุด criteria เดิมเขียนไว้สำหรับ version เดิม
3 · กติกาที่ไม่ต่อรอง
| # | กติกา | ถ้าไม่ทำตาม |
|---|---|---|
| 1 | criteria เขียนก่อน run · แก้หลังเห็นผลไม่ได้ | เกณฑ์ที่แก้หลังเห็นผล ถูกปรับให้เข้ากับผล ไม่ได้ทดสอบอะไรเลย |
| 2 | ตัวเลขทุกตัวต้องมีที่มา · ห้ามเดา spec | ตัวเลขที่เดาผิดไม่มีอะไรเตือน ผลผิดไปเงียบ ๆ |
| 3 | ผลดี ≠ พร้อมใช้เงินจริง | backtest ดีเป็นแค่ด่านหนึ่ง ยังมีขั้น 5R ถึง 9 |
| 4 | ไม่มีคำชม — หน้าที่คือหาจุดอ่อน | คำชมกินพื้นที่ของคำเตือน |
ทำไมต้องเข้มขนาดนี้: ประวัติของ project นี้คือสรุปผิดแล้วต้องถอนหลายครั้ง และทุกครั้งเกิดจากการรีบสรุปด้านบวก ใน session เดียวเมื่อวันที่ 4 กันยายน 2026 สรุปผิดไปถึงเจ็ดครั้ง ปัญหาไม่ได้มาจากการวิจารณ์มากเกินไป แต่มาจากการเชื่อผลดีเร็วเกินไป
4 · สามแบบของการสรุปผิด
การสรุปผิดเจ็ดครั้งในวันที่ 4 ก.ย. 2026 แบ่งได้แค่สามแบบ
| แบบ | จำนวนครั้ง | คืออะไร |
|---|---|---|
| 1 | 4/7 | อ่าน proxy แทนตัวชี้ขาด |
| 2 | 2/7 | บอกว่า "ไม่มี / ไม่ต่าง" โดยไม่วัด |
| 3 | 1/7 | เชื่อตัวเลขจากตารางเก่าโดยไม่ตรวจ |
แบบที่ 1 · อ่าน proxy แทนตัวชี้ขาด
proxy คือตัวเลขที่ "ดูเหมือน" ตอบคำถาม แต่ไม่ใช่ตัวที่ตัดสินจริง
| proxy ที่อ่านแล้วหลง | ตัวชี้ขาดจริง |
|---|---|
expected_payoff |
E[R] |
| ΣR/DD | equity multiplier แบบ compounding |
| สัดส่วน / percent | จำนวนนับ |
| กำไรเป็นเงิน | R |
expected_payoffเป็นเงิน จึงขึ้นกับขนาด lot ส่วน E[R] คือค่าเฉลี่ยของ R ต่อ trade ไม่ขึ้นกับ lot- ΣR หารด้วย drawdown เป็นผลบวกเชิงเส้น แต่เงินในบัญชีที่ compounding โตแบบคูณกัน ต้องดูว่าทุนโตจริงกี่เท่า (ดูเฉลยข้อ 2 ท้ายบท)
- สัดส่วนบอกไม่ได้ว่า n จริงเท่าไร ต้องดูจำนวนนับด้วย
- กำไรเป็นเงินโตได้เพราะ lot ใหญ่ขึ้น ไม่ใช่เพราะกลยุทธ์ดีขึ้น
แบบที่ 2 · บอกว่า "ไม่มี / ไม่ต่าง" โดยไม่วัด
ข้อความที่บอกว่า ไม่มีอะไร ต้องวัดเหมือนข้อความที่บอกว่า มีอะไร case จริง: เคยบอกว่าสัดส่วน 90 ต่อ 10 "เป็นกลาง" จากการให้เหตุผลล้วน ๆ พอวัดจริงได้ +14.3%
แบบที่ 3 · เชื่อตัวเลขจากตารางเก่าโดยไม่ตรวจ
case จริง: spread ของบัญชี Razor จดไว้ในตารางเก่าว่า 0.18 แต่ของจริงอยู่ที่ 0.08 ถึง 0.10 ข้อสรุปที่ใช้ตัวเลขนั้นจึงกลับด้าน ตัวเลขที่ยืมมาจากรายงานหรือตารางเก่า ต้องมีแหล่งที่สองยืนยัน หรือเขียนกำกับว่ายังไม่ได้ตรวจ
จุดที่มักพลาด
| พลาด | ผลที่ตามมา | ทางกัน |
|---|---|---|
| ถือว่า run backtest เสร็จ = ขั้น backtest จบ | ใช้รายงานที่ไม่ได้ใช้ tick จริงหรือไม่ได้จด cost | ตรวจด่านของขั้นก่อนไปขั้นถัดไป |
| แก้ code EA แล้วใช้ criteria เดิม run ต่อ | ทดสอบ version ใหม่ด้วยเกณฑ์ที่ไม่ได้เขียนให้มัน | แก้ code = กลับขั้น prereg เขียนเกณฑ์ใหม่ |
| ข้ามขั้นโดยไม่เขียนเหตุผล | ไม่มีใครรู้ว่าด่านนั้นถูกข้าม | เขียนว่าข้ามเพราะอะไรทุกครั้ง |
| ผลไม่ตรงแล้ว tune ทับ | ปิดบังว่ากลไกเข้าใจผิด | ย้อนกลับขั้น decode |
| แก้เกณฑ์หลังเห็นผล | เกณฑ์ไม่ได้ทดสอบอะไร | เขียนเกณฑ์ก่อน run และห้ามแก้ |
ตัดสินด้วย expected_payoff หรือกำไรเป็นเงิน |
สรุปผิดแบบที่ 1 | ตัดสินด้วย E[R] |
| บอกว่า "ไม่ต่าง" จากการให้เหตุผล | สรุปผิดแบบที่ 2 (case 90 ต่อ 10 = +14.3%) | วัดก่อนพูด |
| ยกตัวเลขจากตารางเก่ามาใช้ตรง ๆ | สรุปผิดแบบที่ 3 (Razor 0.18 vs 0.08–0.10) | หาแหล่งที่สอง หรือเขียนว่ายังไม่ตรวจ |
ทวนท้ายบท
- แก้ code EA หนึ่งบรรทัดหลัง run backtest ไปแล้ว งานนี้ต้องกลับไปขั้นไหน เพราะอะไร
- portfolio ที่ผสมสอง EA ให้ ΣR/DD ดีขึ้น แปลว่าได้เงินมากขึ้นไหม
- บอกว่า "สองแบบนี้ไม่ต่างกัน" จากการให้เหตุผลโดยไม่ได้วัด เป็นการสรุปผิดแบบไหน
เฉลย
- กลับไปขั้น prereg เพราะ version ใหม่คือการทดสอบใหม่ ต้องเขียนเกณฑ์ใหม่ก่อน run
- ไม่แน่ เพราะ R บวกกัน แต่เงินคูณกัน case จริงของ EA-A ผสมกับ EA-C อัตราส่วน ΣR/DD ดีขึ้น +1% · +12% · +63% แต่เงินที่ได้จริงคือ −25% · −40% · +39%
- แบบที่สอง บอกว่าไม่มีหรือไม่ต่างโดยไม่วัด เหมือน case 90 ต่อ 10 ที่วัดจริงได้ +14.3%