ยินดีต้อนรับสู่การตรวจสอบความสมเหตุสมผล: การทำ Backtesting สำหรับ VaR

สวัสดีครับ! หลังจากที่คุณเรียนรู้วิธีการคำนวณ Value at Risk (VaR) มาแล้ว คุณคงทราบดีว่ามันเป็นเครื่องมือที่ทรงพลังมาก แต่เราจะรู้ได้อย่างไรว่าโมเดล VaR ของเราทำงานได้จริงหรือไม่? นี่คือที่มาของคำว่า Backtesting ครับ ให้มองว่า Backtesting เปรียบเสมือน "สมุดพก" หรือใบประเมินผลสำหรับโมเดลความเสี่ยงของคุณ ถ้าโมเดลของคุณบอกว่าควรจะขาดทุนเกิน 1 ล้านดอลลาร์แค่ปีละครั้ง แต่เหตุการณ์นี้กลับเกิดขึ้นทุกสัปดาห์ ก็ชัดเจนว่าโมเดลของคุณมีปัญหาแล้ว ในบทนี้เราจะมาเรียนรู้วิธีการพิสูจน์เชิงสถิติว่าโมเดลนั้นเชื่อถือได้หรือไม่ หรือว่าถึงเวลาที่ต้องรื้อทำใหม่ทั้งหมดแล้ว

ไม่ต้องกังวลไปนะครับถ้าช่วงแรกจะดูเหมือนมีสถิติเยอะไปหน่อย! เราจะค่อยๆ ย่อยคณิตศาสตร์ให้เป็นขั้นตอนง่ายๆ พร้อมยกตัวอย่างให้เห็นภาพชัดเจนจนคุณจำได้อย่างแน่นอน

1. Backtesting คืออะไรกันแน่?

Backtesting คือกระบวนการเปรียบเทียบกำไรและขาดทุนจริง (P&L) ของพอร์ตการลงทุน กับค่า VaR ที่โมเดลคำนวณออกมา

เมื่อผลขาดทุนจริงมีมูลค่ามากกว่าค่า VaR ที่ประมาณการไว้ เราจะเรียกเหตุการณ์นั้นว่า exception (หรือ exceedance) ตัวอย่างเช่น ถ้าค่า 95% 1-day VaR ของคุณอยู่ที่ 100,000 ดอลลาร์ แล้ววันนี้คุณขาดทุนไป 120,000 ดอลลาร์ แบบนี้ถือว่าเกิด exception ขึ้น 1 ครั้งครับ

แนวคิดสำคัญ: ความถี่ของการเกิด Exceptions

ถ้าเราใช้ระดับความเชื่อมั่น (Confidence Level) ที่ 95% เราก็ คาดหวัง ว่าจะมี exception เกิดขึ้นประมาณ 5% ของเวลาทั้งหมด ถ้าเราดูข้อมูลย้อนหลัง 100 วัน เราก็ควรจะเห็น exception ประมาณ 5 ครั้ง

  • ถ้ามี exception เยอะเกินไป? แปลว่าโมเดล ประเมินความเสี่ยงต่ำเกินไป (Underestimating) (โลกสวยเกินไปนั่นเอง)
  • ถ้ามี exception น้อยเกินไป? แปลว่าโมเดล ประเมินความเสี่ยงสูงเกินไป (Overestimating) (ระวังตัวมากเกินไป)

ทบทวนสั้นๆ: Backtesting บอกเราว่า "วันที่แย่ที่คาดไว้" กับ "วันที่แย่จริงๆ" นั้นตรงกันหรือไม่

2. การทดสอบ Kupiec POF (Proportion of Failures)

วิธีที่นิยมที่สุดในการทดสอบความถี่คือ Kupiec Test ซึ่งใช้ การแจกแจงแบบทวินาม (Binomial Distribution) เพราะในแต่ละวันจะมีแค่สองสถานะคือ "สำเร็จ" (ไม่เกิด exception) หรือ "ล้มเหลว" (เกิด exception ขึ้น)

คณิตศาสตร์ (ฉบับย่อ)

เราจะใช้ Likelihood Ratio (LR) test เพื่อดูว่าจำนวนเหตุการณ์ที่ล้มเหลวที่สังเกตได้จริง \( x \) นั้นแตกต่างจากจำนวนที่คาดหวัง \( N \times p \) อย่างมีนัยสำคัญหรือไม่

สูตรสำหรับ Kupiec LR test คือ:
\( LR_{uc} = -2 \ln \left[ (1-p)^{N-x} p^x \right] + 2 \ln \left[ (1-\frac{x}{N})^{N-x} (\frac{x}{N})^x \right] \)

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

รู้หรือไม่?

Kupiec test ได้ชื่อว่าเป็น "Unconditional Coverage" เพราะมันไม่สนใจเลยว่า exception ทั้ง 10 ครั้งนั้นจะเกิดขึ้นติดต่อกันในสัปดาห์เดียว หรือกระจายกันออกไปทั้งปี มันแค่ไล่นับจำนวนเฉยๆ ครับ!

3. ข้อผิดพลาดในการทำ Backtesting: Type I และ Type II

เปรียบเสมือนในศาลยุติธรรม เราสามารถตัดสินโมเดล VaR ผิดพลาดได้ 2 แบบ ลองจินตนาการว่าโมเดลกำลังขึ้นศาลดูนะครับ:

Type I Error: การปฏิเสธโมเดลที่ ดี (โทษคนบริสุทธิ์)
เปรียบเทียบ: สัญญาณเตือนไฟไหม้ดังขึ้นทั้งที่ไม่มีไฟ คุณเลยทิ้งเครื่องตรวจจับที่ยังดีอยู่ไปเพราะคิดว่ามันเตือนมั่ว (False Positive)

Type II Error: การยอมรับโมเดลที่ แย่ (ปล่อยคนผิดไป)
เปรียบเทียบ: สัญญาณเตือนไฟไหม้เงียบสนิททั้งที่บ้านกำลังไฟไหม้ ในโลกการบริหารความเสี่ยง สิ่งนี้อันตรายกว่ามาก!

ข้อควรจำ: มันคือการแลกเปลี่ยน (Trade-off) หากคุณตั้งเกณฑ์ให้เข้มงวดเพื่อป้องกัน Type I error (โดยการผ่อนปรนให้โมเดลผ่านง่ายๆ) คุณก็จะเพิ่มความเสี่ยงที่จะเกิด Type II error (ปล่อยให้โมเดลห่วยๆ หลุดรอดไป) แทน

4. ระบบ "ไฟจราจร" ของ Basel

เพื่อให้เป็นมาตรฐานเดียวกัน คณะกรรมการ Basel ได้สร้างวิธีง่ายๆ ในการจัดหมวดหมู่ผลการ Backtesting โดยดูจากจำนวน exception ที่เกิดขึ้นในรอบ 250 วันทำการ (ประมาณ 1 ปี) สำหรับโมเดล 99% VaR

  • Green Zone (0 ถึง 4 ครั้ง): โมเดลถือว่าแม่นยำ ไม่มีการลงโทษ
  • Yellow Zone (5 ถึง 9 ครั้ง): โมเดลอาจจะโอเค แต่อาจมีพิรุธ หน่วยงานกำกับดูแลอาจสั่งให้คุณเพิ่มเงินกองทุนสำรอง
  • Red Zone (10 ครั้งขึ้นไป): โมเดลพังแล้ว! คุณจะถูกลงโทษโดยอัตโนมัติและต้องแก้ไขโมเดลทันที

เทคนิคช่วยจำ: นึกถึงไฟจราจรเลยครับ
เขียว = ไปต่อได้เลย
เหลือง = ชะลอรถและระวังตัว
แดง = หยุด! โมเดลมีปัญหาแล้ว

5. ความเป็นอิสระและการกระจุกตัว: Christoffersen’s Test

จำที่เราบอกได้ไหมว่า Kupiec test สนใจแค่ จำนวนรวม เท่านั้น? นั่นคือจุดอ่อนของมันครับ ในโลกความจริง exceptions มักจะมาเป็น "กลุ่ม" (cluster) เพราะความผันผวนของตลาด

ทำไมการกระจุกตัวถึงแย่?

ถ้าคุณมี 5 exceptions กระจายอยู่ตลอดทั้งปี โมเดลของคุณอาจจะยังถือว่าโอเค แต่ถ้า 5 ครั้งนั้นเกิดขึ้น ในสัปดาห์เดียว แปลว่าโมเดลของคุณปรับตัวเข้ากับสภาพตลาดที่เปลี่ยนไปไม่ทัน เปรียบเหมือนแอปฯ พยากรณ์อากาศที่พยากรณ์พลาดทุกวันตอนมีพายุเข้า แบบนี้ไม่ใช่แค่ผิดพลาดธรรมดา แต่เป็นความผิดพลาดในช่วงเวลาที่สำคัญที่สุดครับ

Christoffersen’s Independence Test

การทดสอบนี้จะเช็คเฉพาะเจาะจงว่า exception ของวันนี้ขึ้นอยู่กับว่าเมื่อวานมี exception หรือไม่

  • ถ้า exceptions เป็น อิสระต่อกัน (Independent) มันควรจะเกิดขึ้นแบบสุ่ม
  • ถ้า exceptions มีการ กระจุกตัว (Clustered) แสดงว่าโมเดลคุณพลาดอะไรสำคัญไป (เช่น เรื่อง Autocorrelation ของความผันผวน)

Conditional Coverage: เมื่อคุณเอา Kupiec test (ความถี่) มารวมกับ Christoffersen test (ความเป็นอิสระ) คุณจะได้สิ่งที่เรียกว่า Conditional Coverage test ซึ่งเป็นมาตรฐานทองคำสำหรับการทำ Backtesting ครับ

6. ข้อควรระวังและข้อผิดพลาดที่พบบ่อย

เวลาเรียนเรื่อง Backtesting นักเรียนมักจะพลาดจุดเหล่านี้ครับ:

1. สับสนระหว่างระดับความเชื่อมั่น (Confidence Levels): ถ้าใช้ VaR ที่ 99% คุณก็ควรคาดหวังว่าจะเจอ exception น้อยกว่าตอนใช้ 95% อย่าลืมเช็คระดับความเชื่อมั่นก่อนจะเริ่มนับ "ความล้มเหลว"

2. "Clean" P&L กับ "Dirty" P&L:
- Clean P&L: ใช้พอร์ตการลงทุนเดิมจากเมื่อวาน (ไม่มีการซื้อขายเพิ่ม) แบบนี้เหมาะที่สุดสำหรับการทดสอบความแม่นยำของ โมเดล
- Dirty P&L: รวมกำไร/ขาดทุนจากการซื้อขายจริงระหว่างวันเข้าไปด้วย แบบนี้สะท้อนความเสี่ยง ของบริษัท ได้จริง แต่อาจทำให้เห็นข้อผิดพลาดของโมเดลได้ยาก

หลักสูตร FRM โดยทั่วไปจะชอบให้ใช้ Backtesting กับ Clean P&L เพื่อแยกประสิทธิภาพของโมเดลออกมาดูให้ชัดเจนครับ

บทสรุปและประเด็นสำคัญ

- Backtesting คือการเปรียบเทียบ VaR ที่คาดการณ์ กับผลขาดทุนจริง

- Exceptions เกิดขึ้นเมื่อผลขาดทุนจริง > ค่า VaR

- Kupiec Test เช็คว่า จำนวน ของ exceptions นั้นถูกต้องหรือไม่ (Unconditional Coverage)

- Christoffersen Test เช็คว่า exceptions มีการกระจายตัวแบบ สุ่ม หรือไม่ (Independence)

- Type I Error คือการปฏิเสธโมเดลที่ดี; Type II Error คือการยอมรับโมเดลที่แย่

- ระบบไฟจราจรของ Basel ใช้ข้อมูล 250 วันของ 99% VaR เพื่อจัดกลุ่มโมเดลเป็นสีเขียว เหลือง และแดง

ฝึกทำโจทย์ความน่าจะเป็นแบบทวินามเยอะๆ นะครับ! เมื่อคุณเข้าใจตรรกะเบื้องหลังระบบ "ไฟจราจร" และข้อผิดพลาดทั้งสองแบบแล้ว คุณจะเตรียมตัวสำหรับพาร์ทนี้ในข้อสอบได้อย่างมั่นใจแน่นอนครับ