fithia2/dev/phase4_deliverables/operator_research_runbook.md

Operator Research Runbook

1. 목적

이 문서는 연구자/개발자가 Phase 4 백테스트를 실행하고 결과를 검토할 때의 표준 절차를 설명합니다.

2. 실행 전 준비

1. Phase 0~3 문서를 모두 확인합니다.
2. 사용할 dataset snapshot id를 고정합니다.
3. 실험 목적을 한 줄로 정리합니다.
   • 예: event+price baseline vs event+price+attention ablation
4. manifest를 작성하고 schema 검증을 통과시킵니다.
5. output root가 비어 있거나 새로운 run_id를 사용할 것을 확인합니다.

3. 실행 절차

1. baseline run 실행
2. metrics summary 확인
3. blotter 샘플 확인
4. drawdown 기간의 거래를 수동 검토
5. score bucket 보고서 확인
6. regime split 실행
7. ablation 실행
8. 차이점을 run notes에 기록

4. 결과 검토 우선순위

4.1 먼저 볼 것

• trade count가 충분한가
• max drawdown이 과도하지 않은가
• expectancy가 양수인가
• score 상위 구간이 실제로 더 좋은가

4.2 그다음 볼 것

• 특정 이벤트 타입/섹터 편중 여부
• attention overlay가 의미 있게 기여했는지
• 포트폴리오 제약 때문에 너무 많은 기회를 놓쳤는지
• 손절 우선순위에 민감한지

5. 이상 징후 체크

아래 중 하나라도 보이면 누수/leakage를 먼저 의심합니다.

• 너무 매끈한 equity curve
• out-of-sample인데 hit rate가 비정상적으로 높음
• slippage를 넣어도 성과가 거의 안 변함
• score bucket monotonicity가 지나치게 완벽함
• 특정 해/특정 섹터에서만 비정상적 초과수익

6. run notes 템플릿

Run ID:
Objective:
Snapshot ID:
Main config deltas:
Key metrics:
Biggest winners:
Biggest losers:
Regime observations:
Leakage concerns:
Next actions:

7. 실패 시 우선 점검 순서

1. manifest validation
2. snapshot completeness
3. reaction day alignment
4. entry/exit price lookup
5. stop/target priority
6. portfolio gates
7. metrics aggregation

8. 보관 정책

• 중요한 run은 run directory 전체를 보관합니다.
• release candidate run은 immutable로 취급합니다.
• 결과 비교용 CSV/JSON은 삭제하지 않습니다.