You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
83 lines
2.2 KiB
Markdown
83 lines
2.2 KiB
Markdown
# 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 템플릿
|
|
|
|
```text
|
|
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은 삭제하지 않습니다.
|