The Architecture of Survival

KOOeda6 — Edge Seeker

RAIDER ไม่ได้เริ่มต้นจากคำถามว่าเราจะทำกำไรจากตลาดได้มากที่สุดเพียงใด แต่เริ่มจากคำถามที่พื้นฐานกว่าและยากกว่า — ระบบหนึ่งจะสามารถอยู่รอดในตลาดที่ไม่มีวันรับประกันอนาคตได้อย่างไร

ในโลกของการพัฒนาระบบเทรด การค้นหา parameter ที่ให้ผลลัพธ์ดีที่สุดในอดีตไม่ใช่เรื่องยาก สิ่งที่ยากกว่าคือการแยกให้ออกว่า performance ที่เราเห็นนั้นเกิดจากความได้เปรียบที่มีอยู่จริง หรือเป็นเพียงผลจากการที่ระบบปรับตัวเข้ากับข้อมูลชุดหนึ่งได้ดีเกินไป เพราะตลาดไม่ได้มีหน้าที่ทำซ้ำอดีต และ parameter ที่ดูสมบูรณ์แบบในช่วงเวลาหนึ่งอาจกลายเป็นจุดอ่อนทันทีเมื่อเงื่อนไขของตลาดเปลี่ยนไป

RAIDER จึงค่อย ๆ พัฒนาจากระบบที่มองหา performance ไปสู่ระบบที่พยายามทำความเข้าใจ fragility ของตัวเอง

จุดเริ่มต้นของกระบวนการนี้คือ Walk-Forward Optimization หรือ WFO แต่สำหรับ RAIDER การทำ WFO ไม่ได้มีความหมายเพียงการแบ่งข้อมูลออกเป็น In-Sample และ Out-of-Sample แล้วค้นหาชุด parameter ที่ทำกำไรได้ดีที่สุด กระบวนการทั้งหมดถูกสร้างขึ้นเป็น deterministic pipeline ที่สามารถทำซ้ำ ตรวจสอบย้อนหลัง และติดตามที่มาของผลลัพธ์ได้ ทุกขั้นตอนตั้งแต่การกำหนดช่วงเวลา การสร้าง parameter space การ optimization การ scoring ไปจนถึงการ validation ถูกแยกออกจากกันอย่างชัดเจน เพื่อไม่ให้การตัดสินใจของระบบขึ้นอยู่กับความรู้สึกหรือการเลือกผลลัพธ์ย้อนหลังตามสิ่งที่เราอยากเห็น

In-Sample ทำหน้าที่เป็นพื้นที่สำหรับการค้นหา แต่สิ่งที่ค้นพบในพื้นที่นั้นยังไม่มีสิทธิ์ถูกเชื่อ

Candidate จำนวนมากสามารถดูดีเมื่อถูกประเมินด้วยข้อมูลที่ใช้ในการสร้างมันเอง ดังนั้น Profit Factor, Expected Payoff, Drawdown หรือ Profit จึงไม่ถูกมองแยกจากกัน และไม่มี metric ใดได้รับสิทธิ์เป็นคำตอบสุดท้าย การคัดเลือกจึงค่อย ๆ เปลี่ยนจากการมองหา extreme performer ไปสู่การมองหา balance ระหว่าง profitability, risk และ stability

นี่เป็นการเปลี่ยนแปลงที่สำคัญ เพราะระบบเริ่มปฏิเสธแนวคิดที่ว่า “ดีที่สุด” หมายถึง “ทำกำไรสูงสุด”

สำหรับ RAIDER candidate ที่น่าสนใจกว่าอาจไม่ใช่ตัวที่ทำกำไรสูงที่สุด แต่อาจเป็นตัวที่ยอมเสีย performance บางส่วนเพื่อแลกกับ drawdown ที่ต่ำกว่า behavior ที่สม่ำเสมอกว่า และความสามารถในการทำงานได้ภายใต้สภาวะที่แตกต่างออกไป

Out-of-Sample จึงไม่ใช่เพียงขั้นตอนต่อจาก optimization แต่มันคือการบังคับให้ candidate เผชิญกับข้อมูลที่ไม่เคยมีส่วนในการสร้างตัวมันเอง ผลลัพธ์ของแต่ละรอบถูกนำกลับมารวมกับข้อมูล In-Sample จนเกิดเป็น longitudinal record ของพฤติกรรมระบบผ่านหลายช่วงเวลา แทนที่จะถามเพียงว่าระบบเคยทำได้ดีเพียงใด เราเริ่มถามว่าเมื่อเวลาเปลี่ยนไป มันยังคงทำงานได้หรือไม่

เมื่อข้อมูล Out-of-Sample จากหลาย cycle ถูกสะสมมากขึ้น การประเมินก็เดินต่อไปสู่ Monte Carlo Simulation

ในจุดนี้เราไม่ได้สนใจเพียง historical sequence ที่เกิดขึ้นจริงอีกต่อไป แต่เริ่มตั้งคำถามกับลำดับเหตุการณ์ที่อาจเกิดขึ้นได้ หาก trade เดิมเกิดในลำดับที่ต่างออกไป หากช่วงขาดทุนมาติดกันเร็วกว่าที่เคยเกิด หาก randomness ทำให้เส้น equity ไม่ได้เดินในรูปแบบที่เราคุ้นเคย ระบบยังสามารถอยู่รอดได้หรือไม่

Monte Carlo จึงไม่ได้มีไว้เพื่อทำนายอนาคต แต่มีไว้เพื่อทำลายความมั่นใจที่มากเกินไปในอดีต

ยิ่ง RAIDER พัฒนาต่อไป การวิเคราะห์ก็เริ่มเคลื่อนออกจาก performance metrics และเข้าใกล้โครงสร้างภายในของระบบมากขึ้น Candidate ที่ผ่าน WFO และ validation ไม่ได้ถูกมองเป็นเพียงชุดตัวเลขอีกต่อไป แต่ถูกนำกลับไป execute ในระดับ trade-by-trade เพื่อดูว่ามันสร้างพฤติกรรมแบบใดเมื่อเผชิญกับ price movement จริงในแบบจำลองของตลาด

ตรงนี้เองที่ hedge เริ่มเปลี่ยนความหมาย

จำนวน hedge ไม่ได้เป็นเพียงสถิติที่เกิดขึ้นหลังการเทรด แต่เป็นตัวแทนของ structural stress ภายใน RAIDER ทุก position ที่เพิ่มขึ้นคือการใช้ทุน การใช้ margin และการขยาย exposure ของระบบ ดังนั้นระบบที่ให้ profit ใกล้เคียงกันสองระบบอาจมีคุณภาพต่างกันอย่างมาก หากระบบหนึ่งต้องเดินผ่าน hedge sequence ที่ลึกกว่าอีกระบบหนึ่งเพื่อไปถึงผลลัพธ์เดียวกัน

จากจุดนี้ RAIDER จึงเริ่มเปลี่ยนจาก optimization-driven selection ไปสู่ structure-aware filtering

Parameter, profit, drawdown, risk-reward และ hedge behavior ถูกนำมามองร่วมกัน Candidate ไม่ได้ถูกจัดลำดับจากดีที่สุดไปหาแย่ที่สุดเพียงเส้นเดียว แต่เริ่มถูกจำแนกตาม behavioral profile เพราะความหลากหลายของ behavior มีความสำคัญไม่แพ้ performance หากระบบหลายตัวใน portfolio มีโครงสร้างเหมือนกันทั้งหมด ความหลากหลายของชื่อหรือ parameter ไม่ได้หมายความว่าความเสี่ยงได้ถูกกระจายออกจริง

สิ่งที่ดูเหมือน diversification บน spreadsheet อาจยังเป็นความเสี่ยงชนิดเดียวกันที่ถูกทำซ้ำหลายครั้ง

เมื่อการวิเคราะห์ลงลึกถึงระดับ execution เราเริ่มมองเห็นวันที่มี hedge activity สูง ช่วงเวลาที่ระบบอยู่ภายใต้ stress และลักษณะของ parameter ที่ทำให้ระบบต้องเดินเข้าสู่โครงสร้างที่หนักขึ้น ข้อมูลเหล่านี้ไม่สามารถมองเห็นได้จาก Net Profit หรือ Profit Factor เพียงค่าเดียว เพราะ aggregate metric สามารถซ่อนเส้นทางที่ระบบต้องเดินผ่านก่อนจะไปถึงผลลัพธ์ปลายทางได้

และสำหรับ RAIDER เส้นทางนั้นสำคัญพอ ๆ กับปลายทาง

ระบบที่ได้กำไรในที่สุดอาจยังเป็นระบบที่ไม่เหมาะสม หากระหว่างทางมันต้องเข้าใกล้ข้อจำกัดของทุนมากเกินไป

เมื่อแนวคิดนี้ชัดเจนขึ้น hedge capacity จึงกลายเป็นส่วนหนึ่งของ engineering ไม่ใช่เพียงการวิเคราะห์ย้อนหลัง Margin, capital และจำนวน position ที่ระบบสามารถรองรับได้เริ่มทำหน้าที่เป็น physical constraint ของ architecture

ตลาดสามารถเคลื่อนที่ได้ไกลกว่าที่เราคาด

ดังนั้นคำถามจึงไม่ควรมีเพียงว่า “ตลาดน่าจะไปได้ไกลแค่ไหน”

คำถามที่สำคัญกว่าคือ “ถ้ามันไปไกลกว่านั้น ระบบยังอยู่หรือไม่”

นี่เป็นจุดที่ RAIDER เริ่มก้าวออกจากโลกของ backtest อย่างแท้จริง เพราะข้อจำกัดของระบบไม่ได้ถูกกำหนดจากกราฟเพียงอย่างเดียวอีกต่อไป แต่ถูกกำหนดจากความสัมพันธ์ระหว่าง market movement, position structure, margin dynamics และทุนที่มีอยู่จริง

Candidate ที่ให้ผลตอบแทนดีแต่ต้องอาศัยโครงสร้างที่ทุนจริงไม่สามารถรองรับได้ ไม่ใช่ candidate ที่ดี

มันเป็นเพียงผลลัพธ์ที่สวยงามภายใต้เงื่อนไขที่ไม่มีอยู่จริง

หลังจาก selection pipeline สามารถระบุ candidate ที่ผ่านทั้ง performance และ structural constraints ได้ RAIDER ก็เดินเข้าสู่คำถามอีกชุดหนึ่ง ซึ่งต่างจาก optimization อย่างสิ้นเชิง

เมื่อใดควรปล่อยให้ระบบทำงาน

การมีระบบที่ดีไม่ได้หมายความว่าระบบควรถูก activate อยู่ตลอดเวลา Candidate ที่ผ่านการทดสอบแล้วยังต้องเข้าไปอยู่ในโลกที่มีข้อจำกัดของทุน margin และ market conditions ที่เปลี่ยนแปลงตลอดเวลา ดังนั้นระหว่าง “ระบบพร้อม” กับ “ระบบทำงาน” จำเป็นต้องมี decision boundary

Activation layer จึงเกิดขึ้นตรงรอยต่อนี้

มันทำหน้าที่แบ่งระหว่างช่วงที่ RAIDER ควรเข้าสู่ตลาดกับช่วงที่ควรอยู่เฉย ๆ

แนวคิดนี้ทำให้ initial order มีความหมายเปลี่ยนไปโดยสิ้นเชิง

ในระบบทั่วไป initial order อาจถูกมองว่าเป็นเพียง entry

แต่ใน RAIDER มันคือจุดเริ่มต้นของ risk cycle

เมื่อ position แรกถูกเปิด Distance A, Distance B, RiskPercent, MaxStopLoss และข้อจำกัดอื่น ๆ ไม่ได้ควบคุมเพียง trade แรก แต่กำลังสร้างเงื่อนไขเริ่มต้นของ trajectory ที่อาจพัฒนาไปเป็น hedge sequence ทั้งชุด

การตัดสินใจเปิด position แรกจึงมีน้ำหนักมากกว่าการพยายามหาจุดเข้าที่แม่นที่สุด

เพราะทันทีที่ระบบถูก activate สิ่งที่ตามมาไม่ใช่ trade เดี่ยว แต่เป็นโครงสร้างของความเสี่ยงที่เริ่มเคลื่อนตัวไปพร้อมกับตลาด

RAIDER ไม่ได้พยายามเปลี่ยน parameter ตลอดเวลาหลังจากเข้าสู่ cycle แต่ปล่อยให้ deterministic rules ที่ถูกกำหนดไว้ล่วงหน้าทำงานภายใน stochastic environment สิ่งที่ระบบสามารถควบคุมได้คือกฎของตัวเอง ส่วนสิ่งที่ควบคุมไม่ได้คือเส้นทางของราคา

ตรงรอยต่อนี้เองที่ architecture มีความหมาย

เราไม่สามารถทำให้ตลาด deterministic ได้

แต่เราสามารถทำให้การตอบสนองของเราต่อความไม่แน่นอนมีโครงสร้างได้

เมื่อ cycle เริ่มทำงาน monitoring จึงมีบทบาทมากกว่าการดูว่าระบบกำไรหรือขาดทุน Current drawdown, number of active positions, margin level และ equity trajectory คือข้อมูลที่บอกว่าระบบกำลังอยู่ตรงไหนเมื่อเทียบกับ safe operating zone ของมัน

RAIDER จึงไม่จำเป็นต้องมีเพียงสองสถานะคือ trade กับ stop

ระบบสามารถมี state ของตัวเอง

มันอาจ continue เมื่อทุกอย่างยังอยู่ภายใน boundary อาจ pause เมื่อ risk เริ่มเปลี่ยน หรืออาจ deactivate เมื่อเงื่อนไขบางอย่างเดินออกจากขอบเขตที่ architecture ยอมรับได้

นี่เป็นความแตกต่างระหว่างระบบที่เพียง “ทำตามกฎ” กับระบบที่รู้ว่าตัวเองกำลังอยู่ในสภาวะใด

ท้ายที่สุด ทุก cycle ที่จบลงไม่ได้ถือเป็นเพียงผลกำไรหรือขาดทุนหนึ่งรายการ แต่กลายเป็นข้อมูลใหม่ที่ย้อนกลับเข้าสู่กระบวนการวิเคราะห์ Execution สร้างประสบการณ์ใหม่ ประสบการณ์ถูกนำกลับไปตรวจสอบ assumption เดิม และสิ่งที่เรียนรู้ถูกนำไปใช้ปรับ parameter, threshold หรือ constraint ใน cycle ต่อไป

เกิดเป็น feedback loop ระหว่าง selection และ execution

RAIDER จึงไม่ได้ evolve เพราะมันสามารถทำนายตลาดได้ดีขึ้นเรื่อย ๆ

มัน evolve เพราะมันเรียนรู้ข้อจำกัดของตัวเองได้ดีขึ้นเรื่อย ๆ

ความแตกต่างนี้สำคัญ

ระบบที่พยายามทำนายอนาคตต้องหวังว่าความเข้าใจของมันเกี่ยวกับตลาดจะถูกต้อง

แต่ระบบที่ถูกสร้างเพื่ออยู่รอดเริ่มต้นจากการยอมรับว่าความเข้าใจนั้นอาจผิดได้เสมอ

สิ่งที่เราสามารถทำได้จึงไม่ใช่การกำจัด uncertainty แต่เป็นการออกแบบ architecture ที่ uncertainty ไม่สามารถทำลายได้ง่าย

นี่คือเหตุผลที่เป้าหมายของ RAIDER ไม่เคยเป็นการ maximize return ในความหมายง่าย ๆ

Return เป็นสิ่งจำเป็น เพราะระบบที่ไม่มี positive expectancy ไม่สามารถดำรงอยู่ได้ แต่ return ที่ต้องแลกด้วย fragility ที่สูงเกินไปไม่ใช่ edge ที่ยั่งยืน มันเป็นเพียงการเลื่อนเวลาของความล้มเหลวออกไป

ดังนั้น optimization สำหรับ RAIDER จึงไม่ใช่การค้นหาจุดสูงสุด

มันคือการค้นหาพื้นที่ที่ระบบยังสามารถหายใจได้

Validation ไม่ได้มีไว้เพื่อยืนยันว่าเราถูก

มันมีไว้เพื่อพยายามพิสูจน์ว่าเราอาจผิด

Monte Carlo ไม่ได้มีไว้สร้างความมั่นใจ

มันมีไว้ถามว่าหาก randomness ไม่เป็นมิตรกับเรา เรายังเหลืออะไรอยู่

Hedge analysis ไม่ได้มีไว้เพื่ออธิบายอดีต

มันมีไว้เปิดเผยว่าระบบต้องแบกรับโครงสร้างแบบใดระหว่างทาง

Activation ไม่ได้มีไว้เพื่อหาจังหวะที่สมบูรณ์แบบ

มันมีไว้ตัดสินว่าเมื่อใดความเสี่ยงควรได้รับอนุญาตให้เริ่มต้น

Monitoring ไม่ได้มีไว้เฝ้าดูกำไร

มันมีไว้เฝ้าดูว่าสิ่งที่เราสร้างยังอยู่ภายในขอบเขตที่มันถูกออกแบบมาให้มีชีวิตอยู่หรือไม่

ทั้งหมดนี้นำกลับมาสู่คำถามแรกที่ RAIDER พยายามตอบมาตลอด

ไม่ใช่—

เราจะชนะตลาดได้อย่างไร

แต่คือ—

เราจะสร้างระบบอย่างไรให้ยังคงอยู่ เมื่อวันหนึ่งตลาดไม่เป็นอย่างที่เราคิด

ตลาดจะเปลี่ยน

Distribution จะเปลี่ยน

Volatility จะเปลี่ยน

ความสัมพันธ์ที่เคยมีอาจหายไป

สิ่งที่เคยดูผิดปกติอาจกลายเป็นเรื่องปกติ และสิ่งที่เราเคยคิดว่าแทบเป็นไปไม่ได้อาจเกิดขึ้นจริง

Architecture of Survival จึงไม่ได้สร้างขึ้นบนความเชื่อว่าอนาคตสามารถคาดการณ์ได้

มันสร้างขึ้นบนข้อสันนิษฐานตรงกันข้าม

อนาคตไม่จำเป็นต้องเป็นอย่างที่เราคาด

และระบบที่ดีควรถูกออกแบบโดยเริ่มจากความจริงข้อนั้น

RAIDER จึงไม่ใช่ architecture ที่พยายามเอาชนะ uncertainty

มันเป็น architecture ที่พยายามดำรงอยู่ภายใน uncertainty

เพราะท้ายที่สุด ความอยู่รอดไม่ใช่ผลข้างเคียงของการทำกำไร

ความอยู่รอดคือเงื่อนไขที่ทำให้เรายังมีโอกาสทำกำไรในวันต่อไป