콘텐츠로 이동

v9-05 Baseline Extension — 적대적 검토

0. 종합 판정

Revision-Required.

FAIL 판정 자체는 robust하나, 보고서가 (1) MLflow per-step 로깅 규약 위반(Training loss 전량 미로깅, CLAUDE.md 강제 사항) 을 누락 없음 으로 기술, (2) FEDformer×Apt51 outlier 해석이 post-hoc cherry-picking 구조, (3) Wall-clock 1.15× 해석이 "빠르다" 로 치환되어 R1 완화 결론에 무리, (4) MLflow 정리 주장의 실제 상태 기술에 모호성 (tombstone 3 vs 2.2 문장에서 "3건"이라 썼으나 실제 2건은 초기 시도 중복 + 1건은 RUNNING 고아 — 소분류 기술은 정확하나 "이미 목표 상태" 주장이 절차적 공백을 숨김) 의 4가지를 반드시 수정해야 한다. 추가로 v9-01 수치 인용의 seed 비대칭은 보고서가 §8.2 한계 항목에서 명시적으로 기록했으나, §4 표와 §4.1 순위 해석에서는 여전히 공정하지 않은 비교를 주장 근거로 끌어다 쓰고 있어 §4.1 해석 문구 수정이 필요하다.

VQ 후보 부재 결론(§6)과 "사용자 결정에 위임" 프레이밍은 적절하다. FAIL 판정에 대한 상대우위 해석(§5.2)은 단일 가구 강점을 방법론적 주장 근거로 사용하지 않는다는 자기-경계가 올바르게 존재한다.

1. 리뷰 방법론

  • 재현 확인: outputs/v9_baseline_ext/summary.csv (45 records) 로드 → 보고서 §3 테이블 mean/std 재계산, 모두 일치 (±0.001 이내).
  • MLflow 상태 조회: experiment_id=766380978402830870, run_view_type=3 (ALL) 로 active 46 + deleted 3 = 49 확인. 보고서 §2.1의 49건 breakdown 일치.
  • CLAUDE.md 규약 대비: MLflow 로깅 규칙 (학습 loss per-step) 위반 확인 (§1.1 이하).
  • 선행 보고서 (v9-04, v9-01) 와의 인용 정합성 교차 검증.
  • 원천 소스 코드 (experiments/forecasting/v9_0424_baseline_extension.py, v6_0415_nf_baseline.py) 의 hyperparameter override 일치 검증.

2. Critical Issues

2.1 [Critical] MLflow per-epoch 학습 loss 로깅 전량 누락 — CLAUDE.md 강제 규약 위반

문제: 45개 active 학습 run 중 단 한 건도 train_loss 또는 val_loss 또는 val_mse metric 을 per-step 로깅하지 않았다. 샘플 확인 결과 (FEDformer_Apt6_seed42, FEDformer_Apt51_seed7 등):

  • run.data.metrics keys = {hr_tol1, hr_tol2, mae, mape, mse, pape, smape} — 최종 7개 metric만 존재.
  • get_metric_history(run_id, "train_loss") → empty.
  • outputs/v9_baseline_ext/logs/main_run.log = 12 lines (INFO 레벨 Lightning 헤더만 존재, epoch-level loss 라인 없음).

CLAUDE.md 명시: 

MLflow Logging Rules (mandatory in every experiment script)
- Training loss → mlflow.log_metric(step=) per epoch/round

또 프로젝트 memory feedback_mlflow_full_logging: 

학습 loss / y_true·y_pred artifact / 평가값 전종 필수 기록

증거: - mlflow.tracking.MlflowClient().get_metric_history(...) 결과 전 run에서 len(hist)=0. - v9_0424_baseline_extension.py 전체에서 mlflow.log_metric(..., step= 호출을 단 0회 사용 (grep 검증). - 설계서 §4.3 "Per-step metrics (mlflow.log_metric(..., step=epoch)): train_loss / val_mse" — 설계에서 요구했으나 스크립트에서 구현 누락.

파급: - 본 critic 보고서의 § 3.3 (Wall-clock R1 해석 공격) 의 반박 근거 부재: "FEDformer 가 충분히 수렴했는가, 500 steps 에서 잘렸는가" 를 판별할 수 없음 (loss curve 없음). - Informer distil 효과 해석 (§8.1 관찰 3) 도 근거 없음 — epoch 수가 early_stop 으로 빨리 끝났는지, max_steps 에서 잘렸는지 알 수 없음. - 설계서 R4 (NF random_seed non-determinism) 의 적합성 자체 검증 불가.

심각도: Critical. 재실행 불필요(결과 테이블과 artifact 저장은 정상)이나 후속 phase 에서 v9-05 결과를 근거로 삼는 모든 해석의 수렴/진행 상황 근거가 소멸했다. 추가로 프로젝트-wide 재발 방지 설명 필수.

수정 요구: 1. 보고서 §2 "MLflow 정리 내역" 또는 §8.2 "한계" 항목에 이 누락을 명시적으로 기록하고, "후속 TSLib 2차 착수 또는 v10 VQ 재시도 시 per-epoch loss 로깅을 강제한다" 는 commitment 추가. 2. 가능하면 outputs/v9_baseline_ext/logs/main_run.log 가 아닌 PyTorch Lightning CSVLogger 재부활 여부를 engineer 에게 문의 (NF 내부에 CSVLogger 가 붙어 있을 수 있으나 disabled 로 보임 — enable_progress_bar=False 옵션이 영향?). 3. Lightning progress_bar disable 이 loss 로깅까지 sink 한 원인인지 점검 후, 후속 스크립트에 mlflow.pytorch.autolog() 또는 custom MLflowLogger 주입 가이드를 docs/reference/project_state/ 에 기록. 4. 본 보고서의 §7 "Wall-clock" 절이 "max_steps 500 에 갇혀 과소학습" 가능성을 배제할 수 없다 는 caveat를 §7 또는 §8.2 에 추가해야 한다.

2.2 [Critical] 보고서 §8.2 한계 항목이 이 로깅 누락을 인식하지 못함

§8.2 는 한계 5건 (seed 수, seed 비대칭, non-determinism, MAPE 이상치, 3-tier gating 미적용) 을 열거하지만 가장 중대한 재현성 공백 — per-epoch loss 부재 — 은 누락. 이는 critic 이 issue 2.1 을 제기하기 전까지 사각지대로 남아 있었음을 의미한다. "한계 셀프-인정" 의 완결성이 깨진다.

수정 요구: §8.2 에 "Per-epoch train/val loss 미로깅 — 수렴 판별 불가" 를 6번째 한계 항목으로 명시 추가. 이 항목은 track 외 리스크 가 아니라 본 보고서 결과 해석의 직접적 제약 임을 명기.

3. Major Issues

3.1 [Major] FEDformer × Apt51 outlier 해석의 post-hoc cherry-picking 구조

보고서 주장 (§5.2 마지막 문단, §8.1 관찰 2): - "FEDformer × Apt51 은 HR@1 41.90%, HR@2 65.71% — Apt51 은 v9-01 §4 에서 '주기적 peak 패턴이 강한 가구' 로 관찰됐던 apt 이며, FEDformer 의 frequency-domain attention 이 이 구조에 부합할 가능성이 있다."

비판: 1. v9-01 §4 의 "주기성 가구" 언급은 설계서 §1/§2 의 가설 구성에 포함되지 않았다. v9-05 설계서 §1.3 의 H9-5a / H9-5b 가설 어디에도 "FEDformer 는 주기성 가구에서 특히 잘 작동할 것이다" 또는 "Apt51 이 FEDformer 에 적합" 같은 사전 등록이 없다. 결과를 보고 Apt51 단독 강점을 발견한 후 v9-01 의 "주기성" 키워드를 소환해 정당화하는 구조다. 이것이 HARKing 의 전형적 패턴이다. 2. v9-01 §4 의 원문 확인 결과, Apt51 에 대해 기재된 것은:

"Apt51 은 모든 모델에서 HR 이 상대적으로 높다 (B1 HR@1=69.95, Chronos HR@1=69.04). 주기적 peak 패턴이 강한 가구로 해석." 즉 모든 모델에서 HR 이 높은 가구이지, FEDformer 특이적 가구가 아니다. Chronos-Bolt 는 Apt51 에서 HR@1=69.04%, FEDformer 는 41.90%로 Chronos 보다 27%p 낮다. "Fourier attention 정합"이라는 해석은 이 격차를 설명하지 못한다. 3. 보고서 자신이 §5.2 말미 "다만 단일 가구 관찰로는 방법론적 주장 근거가 부족하며" 라는 자기-경계를 달아 놓았으나, §8.1 에서는 "FEDformer 의 Fourier mode 기반 attention 이 단일 가구 수준에서 Chronos/B1 와 경쟁하는 조합이 있음은 주목할 만하나" 로 다시 강조하며 해석을 내러티브에 편입시킨다. 두 기술이 상충한다.

수정 요구: 1. §5.2 의 "Apt51 은 v9-01 §4 에서 주기적 peak 패턴이 강한 가구" 문장을 삭제 또는 다음으로 교체:

"Apt51 은 모든 모델에서 HR 이 상대적으로 높은 가구이며 (v9-01 §4, Chronos HR@1 69.04% / B1 HR@1 69.95% 대비 FEDformer 41.90%), 이 값은 가구 자체의 learnability 에 기인할 가능성이 높다. FEDformer 특이적 frequency attention 해석은 본 결과만으로 지지되지 않으며, post-hoc speculation 으로 기록한다." 2. §8.1 관찰 2 에서 "Fourier mode 기반 attention 이 단일 가구 수준에서 Chronos/B1 와 경쟁" 문구를 제거하거나, "Chronos/B1 의 Apt51 HR@1 이 각각 69.04/69.95% 로 FEDformer 41.90% 를 크게 상회 → 경쟁 주장은 성립하지 않음" 으로 정정.

3.2 [Major] Wall-clock 1.15× 해석의 "빠르다" 치환 — 수렴 상태 불명

보고서 주장 (§7.2):

FEDformer / Autoformer 비율: 94.3 / 81.7 = 1.15× (설계서 §7 R1 예상 "1.5–2×" 보다 현저히 낮음, 위험 R1 완화)

비판: - 설계서 §7 R1 은 "학습 시간이 Autoformer 대비 2–3배 이상일 때 wall-clock budget 초과" 를 관리하는 리스크. 즉 "예상보다 빠르다" 가 완화의 조건이 아니라, 예산 초과가 없다 가 완화의 조건이다. - 본 보고서는 "예산 초과가 없다" 를 "빠르다" 로 치환하면서, 동시에 모델이 실제로 얼마나 학습했는지는 기록하지 않았다 (issue 2.1). - max_steps=500 + early_stop_patience=50 + val_check_steps=50 설정에서는, val_loss 가 50 step 이후 10회 (=500 step) 동안 개선 없으면 중단. 즉 모든 FEDformer run 이 max_steps 500 까지 학습했는지, 일부가 early_stop 으로 훨씬 일찍 끝났는지 구별 불가. 94.3 초/run 의 대부분이 data loading + validation 시간일 수 있음. - Informer 가 Autoformer 의 47% 수준인 것 역시 "ProbSparse + distil 의 추론 효율" 이 아니라 "Informer 가 더 일찍 early_stop 으로 종료됨" 때문일 수 있다. - seed 간 wall-clock std 가 FEDformer=0.6s, Autoformer=1.7s, Informer=0.6s 로 극히 작다 는 점은 오히려 3 seed 모두 동일하게 max_steps 에 도달 한 신호로 해석할 수 있다 (early_stop 이 작동했다면 seed 간 변동이 더 컸을 것). 이 해석이 옳다면 "빠르다" 가 아니라 "모두 500 step 한계에서 잘렸다" 가 정확한 기술.

수정 요구: 1. §7.2 에 위 3가지 해석 (data loading 비중 / early_stop 여부 불명 / seed std 작음이 시사하는 max_steps 한계) 를 명시적으로 기록. 2. "R1 완화" 주장은 "예산 초과 없음" 으로 한정해 재기술. "빠르다/효율적" 해석은 근거 부재이므로 철회. 3. §8.1 관찰 3 "Informer distil 효과가 학습 시간에서만 유효" 주장은 early_stop 여부 불명으로 무근거. 삭제 또는 "wall-clock 이 짧은 것은 distil 효과일 수도, early_stop 일 수도 있음 (per-epoch loss 로깅 누락으로 판별 불가)" 으로 축소.

3.3 [Major] v9-01/v6 baseline 인용 비교표의 seed 비대칭이 §4.1 순위 해석에 반영되지 않음

보고서 §4 표: - v9-05 신규 3종: 5-apt × 3-seed = 15 runs mean - v9-01/v6 baseline: 5-apt × 1-seed (seed=42) = 5 runs mean

§4 footnote 에 "seed 기준이 다르다" 를 기록했으나, §4.1 의 순위 해석은 이 차이를 무시하고 "v9-05 신규 3종은 PAPE 축에서 전 baseline 중 최하위 구간에 위치" 라고 단정한다.

실제 계산 (동일 seed=42 로 제한 시): | Model | v9-05 seed=42 PAPE | v9-05 3-seed PAPE | Δ | |-------|:---:|:---:|:---:| | Autoformer | 54.31 | 52.91 | +1.40pp | | Informer | 52.17 | 53.40 | −1.24pp | | FEDformer | 52.16 | 52.04 | +0.12pp |

seed=42 만으로 제한해도 최하위 구간 위치는 거의 동일하므로 순위 자체는 robust하다. 그러나 보고서가 seed=42 비교를 보조 표로 제공했어야 한다. 또한 v6/v9-01 baseline 수치에 seed noise band 를 표시하지 않아 "R1b 37.36 PAPE" 가 seed=42 단일 측정이라는 사실이 § 순위표에서 은폐된다.

증거: - 본 critic이 re-computed seed=42 수치는 위 표. - v9-01 recap § "seed: RANDOM_SEED = 42 단일" 명시.

수정 요구: 1. §4 테이블 주석(footnote)에 각 baseline row 의 seed (v6/v9-01 = seed 42 단일) 를 열(column) 로 추가하거나, row 별 annotation 으로 명시. 2. §4.1 순위 해석 첫 단락에 "v9-05 는 15-run 평균, v9-01/v6 는 5-run 평균이므로 동일 seed=42 기준 재비교 표 (보조 §4.2) 를 참조" 로 가드. 3. 또는 §3.1 아래에 "seed=42 단일 비교 보조 테이블" 을 1개 추가하고, v9-05 의 seed=42 subset 만으로 v6/v9-01 과 비교한 순위를 별도로 제시.

3.4 [Major] MLflow 정리 §2.2 의 "이미 목표 상태" 주장이 수행 주체/시점을 생략

보고서 §2.2:

본 집계 시점에 이미 orchestrator (또는 직전 세션) 가 정리를 수행해 lifecycle_stage=deleted 로 전환한 3건이 tombstone 상태로 남아 있다. (...) 추가 삭제 동작은 수행하지 않았다 (이미 목표 상태).

비판: - MLflow에는 삭제 기록의 주체/시점 감사 로그가 없다. "orchestrator 또는 직전 세션이 수행" 은 추측. 누가 언제 삭제했는지 불명확한 상태에서 "이미 목표 상태" 라는 긍정적 결론을 내린다. - 3건의 tombstone 중 1건은 RUNNING (465e6dc1...) 상태 고아 process — 이것이 언제 생긴 고아인지, 정상 종료된 게 맞는지 감사 필요. 보고서는 "초기 시도" 로 치부. - 지시서의 명시 상태 ("46 active = 45 model + 1 aggregate") 와 실제 상태가 일치하는 것은 사실이나, 보고서가 정리 액션이 필요 없었음 을 판단하기 전에 tombstone lifecycle 로 전환된 경위를 먼저 기록해야 했다. - critic 검증: client.search_runs(..., run_view_type=3) 로 active=46, deleted=3 확인 → 보고서 수치 정합.

수정 요구: 1. §2.2 의 "orchestrator (또는 직전 세션)" 불명 기술을 제거하고, "본 exp-expert 세션 진입 시점에 이미 deleted lifecycle 이었으며, 전환 주체 식별은 불가 (MLflow 파일스토어 메타에 주체 감사 없음)" 으로 정정. 2. deleted 3건의 end_time 또는 start_time 을 §2.2 표에 절대 시간으로 기록하여 "초기 시도" 라는 추론의 근거를 데이터로 남긴다. (예: RUNNING 고아가 본 실행 시작 이전의 timestamp 인지 확인 가능)

4. Minor Issues

4.1 [Minor] smoke 재실행 산출물 기록 누락

설계서 §5.3 은 "본 실행 직전 smoke 단계" 를 요구. outputs/v9_baseline_ext/summary_smoke.csv 가 실제로 존재하며 1 record (Autoformer_Apt6_seed42, max_steps=50) 가 기록되어 있다. 그러나 보고서 §1 "실행 요약" 이나 §9 "산출물 인덱스" 에 smoke 결과 파일이 열거되지 않는다.

수정 요구: §9 산출물 인덱스에 summary_smoke.csv 를 추가하고, §1.1 에 "smoke 실행: max_steps=50, 1-run, metric finite 검증 완료" 한 줄 포함.

4.2 [Minor] seed={42, 7, 123} 선택 근거의 문서 내 재언급 누락

v9-02 설계서 §1.3 은 "seed ∈ {42, 7, 123}" 을 명시했으나, v9-04 phase summary §2.3 의 3-seed 확장은 실제로는 {42, 123, 456} 로 실행됐다. v9-05 는 v9-02 설계와 일치하는 {42, 7, 123} 을 사용했으나, v9-04 에서 사용된 seed set 과 다른 이유에 대한 1문장 설명이 보고서에 없다.

수정 요구: §1.1 "시드: {42, 7, 123}" 뒤에 괄호로 "(v9-02 설계 §1.3 에 사전 등록된 집합 — v9-04 Stage 2 3-seed 확장은 {42, 123, 456} 을 사용했으나 본 phase 는 설계서 §3.4 에 따라 v9-02 원안을 재사용)" 같은 1문장 justification 추가.

4.3 [Minor] "seed=42 단일 비교 보조" (issue 3.3 대응) 미제공 + 재현 스크립트 단일

_aggregate_analysis.py 가 3-seed mean 기준 집계만 수행. seed=42 로만 필터링한 보조 비교는 스크립트에도 보고서에도 없다. §4 표의 신뢰성을 위해서는 issue 3.3 수정 시 이 보조 표를 자동으로 생성하도록 스크립트 확장 필요.

수정 요구: _aggregate_analysis.py 에 "seed42_only_comparison" 섹션 추가, §4.2 재생성. (engineer 개입 불필요 — 본 critic 이 확인한 pandas 1-line filter 로 가능)

4.4 [Minor] § 8.1 관찰 4 "Autoformer 가 HR 축에서 최하" 의 인과 해석

MovingAvg decomposition 이 hourly 가구별 noise 를 과도하게 smoothing 하고 peak 시점 정렬을 놓칠 가능성이 있다.

이는 합리적 가설이나 검증되지 않은 speculation. 보고서는 이 주장을 지지할 ablation (MovingAvg_window 변화) 을 수행하지 않았다.

수정 요구: "가능성이 있다" 를 "가설 — ablation 미수행, 본 phase 범위 외" 로 한정. 또는 후속 작업 후보로 §8.3 에 이관.

4.5 [Minor] §4 표의 NHITS 수치 MSE 오류 가능성 의심 — 재확인 필요

보고서 §4 표에서 NHITS: MSE 0.648, HR@1 22.29. v9-01 recap §2 표에서도 동일 (MSE 0.648, PAPE 39.26, HR@1 22.29). 이는 Autoformer v9-05 MSE 와 정확히 0.660 vs 0.648 로 매우 근접. v6 원본 파일 확인 결과 NHITS 의 MSE 0.648 은 v6 NF-Baseline 에서 동일 값인지 확인 필요. (critic 은 v6_nf_baseline_results 원본 조회 미수행 — minor 수준으로 남김.)

수정 요구: §4 NHITS row 의 MSE 0.648 이 v6 report 와 동일한지 spot-check 후 각주에 "v6 NF-Baseline experiment run_id=..." 같은 구체적 근거 MLflow run_id 기록.

4.6 [Minor] v9-01 §1.1 의 "predict_len=1h" 텍스트와 실제 코드의 불일치 (v9-05 책임 외)

v9-01 recap 의 §1.1 은 "context_len=24h, predict_len=1h" 라 적혀 있으나 실제 v6_0415_nf_baseline.py 는 INPUT_SIZE=96, HORIZON=24 를 사용. 즉 v9-01 문서 자체에 오기가 있었고, v9-05 는 올바르게 INPUT_SIZE=96, HORIZON=24 로 설계됨 (일치). 본 v9-05 보고서의 책임 범위는 아니나, 인용 경로상 오기 전파 방지를 위해 1문장 보완 권장.

수정 요구: §1.1 "공통 파라미터" 줄 다음에 "v9-01 recap 텍스트의 'predict_len=1h' 는 문서 오기로 확인 (실제 v6 NF baseline 코드는 INPUT_SIZE=96, HORIZON=24, v9-05 와 일치)" 주석 추가.

5. 인정되는 강점

  1. §5.2 "상대 우위 분석" 의 자기-경계 — "Apt51 단일 가구 관찰로는 방법론적 주장 근거가 부족" 이라는 명시적 자기-제한 문구. Post-hoc cherry-picking 의 위험을 부분적으로 차단하려는 시도가 있다 (issue 3.1 에서 완전히 실패했다고는 기술했지만, 완화 문장 자체는 인정).
  2. §6.3 의 "TSLib 2차 착수 여부는 사용자 결정 사항" 프레이밍 — exp-expert 가 옵션 선택을 강제하지 않고 설계서 §6.3 규약대로 위임한 것은 올바른 행동.
  3. §8.3 의 "VQ 의 가치는 backbone 정확도 FAIL 과 독립" 주장 — "v9-05 결과는 VQ track 의 해산 근거로 단독 사용되어서는 안 된다" 라는 신중한 경계. 이것이 설계서 §6.3 옵션 B ("VQ track 전면 중단") 결정 시의 중요한 brake 로 작동한다.
  4. 재현성 — _aggregate_analysis.py 가 실제로 summary.csv 에서 보고서 모든 수치를 재생성 가능함을 critic 이 검증. ±0.001 이내 일치.
  5. §3.3 seed std 테이블의 정확성 — FEDformer PAPE seed std 0.82%p 은 summary.csv 에서 재계산 가능하며 일치. 재현성 주장의 quantitative backbone 은 honest.
  6. §8.2 한계 2 (seed 비대칭 명시) — v6 baseline 과의 seed 비대칭을 한계로 인식함. 다만 §4.1 순위 해석에서 이 한계를 반영하지 않은 것이 issue 3.3 의 비판 대상.

6. exp-expert 에게 전달하는 필수 수정 사항

6.1 Critical 수정 (필수 — 본 수정 없이 reporter 진입 불가)

  • C1 (issue 2.1, 2.2): 보고서 §8.2 에 6번째 한계 항목 추가 — "Per-epoch train/val loss 미로깅 — 수렴 판별 불가 (설계서 §4.3 spec 대비 구현 누락). 후속 TSLib 2차 또는 v10 VQ 재시도 시 mlflow.log_metric(..., step=epoch) 강제." 이 항목은 본 보고서의 모든 수렴 관련 주장 (§7 wall-clock 해석, §8.1 관찰 3 Informer distil 주장 등) 의 전제 불성립 신호.
  • C2 (issue 2.1 파생): §7.2 "1.15× → R1 완화" 결론에 caveat 추가 — "단, FEDformer/Informer/Autoformer 가 각각 실제로 어떤 지점에서 학습 종료했는지 (early_stop vs max_steps 도달) 는 per-epoch loss 미로깅으로 인해 판별 불가. 본 해석은 종료 조건이 동일하다는 가정 하에만 유효."
  • C3 (issue 2.2): §8.1 관찰 3 "Informer distil 효과가 학습 시간에서만 유효" 문구 삭제 또는 "Wall-clock 이 짧은 원인은 distil 효율과 early_stop 조기 종료 중 판별 불가 (로깅 누락)" 로 교체.

6.2 Major 수정 (필수 — 본 수정 없이 reporter 진입 불가)

  • M1 (issue 3.1): §5.2 마지막 문단의 Apt51 "주기성 가구 × Fourier attention 정합" 해석 삭제 or Chronos/B1 의 Apt51 HR@1 대비 격차를 명시하는 문장으로 교체. §8.1 관찰 2 에서도 동일 처리.
  • M2 (issue 3.2): §7.2 "빠르다" 해석을 "예산 초과 없음" 으로 제한. Seed std 극소 (FEDformer 0.6s) 가 시사하는 max_steps 도달 가능성을 §7 또는 §8 에 명시.
  • M3 (issue 3.3): §4 테이블에 각 baseline row 의 seed column 추가 + seed=42 단일 보조 비교 테이블 §4.2 신규 작성 + _aggregate_analysis.py 에 seed42 필터링 블록 추가.
  • M4 (issue 3.4): §2.2 MLflow 정리 기술을 "본 세션 진입 시점에 이미 deleted lifecycle" 로 정정. deleted 3건의 start_time 을 §2.2 표에 추가.

6.3 Minor 수정 (권고 — 수정 없이도 reporter 진입 가능하나 권장)

  • m1: §9 산출물 인덱스에 summary_smoke.csv 추가.
  • m2: §1.1 seed 목록에 "v9-02 설계 사전 등록" 주석 추가.
  • m3: §8.1 관찰 4 Autoformer MovingAvg 인과 해석을 "가설, ablation 미수행" 으로 한정.
  • m4: §4 NHITS 등 v6 baseline 수치의 MLflow run_id 정확 인용.
  • m5: §1.1 에 v9-01 recap 의 "predict_len=1h" 오기 정정 주석.

7. 재실험 권고

재실험 불필요. 본 critic 은 결과 자체 (FAIL 판정, FEDformer 3종 중 상대 우위, Apt-level Pass 0 / Watch 1) 의 robustness 는 인정. summary.csv 의 45 records 는 완전하고 재현 가능.

단, 후속 phase (TSLib 2차 착수 또는 v10 VQ 재시도) 에서는 다음을 강제:

  • 재실험 P1: mlflow.log_metric(..., step=epoch) 로 train_loss, val_loss, val_mse 필수 로깅 (CLAUDE.md 재점검). Pytorch Lightning CSVLogger + MLflowLogger 중첩 설정 가이드를 docs/reference/project_state/v9_baseline_ext_lessons.md 에 기록.
  • 재실험 P2: 사전 가설 등록 문서화 — "모델 A 가 가구 X 에서 특히 잘 작동할 것" 같은 apt-specific 예측은 설계서 §1.3 가설에 포함해야만 post-hoc 해석을 허용.
  • 재실험 P3: seed=42 단일 + 3-seed mean 보조 비교를 aggregate 스크립트에 기본 포함하여 seed 비대칭 표시 누락을 방지.

8. 참고 — critic 검증에 사용한 스크립트

# (1) summary.csv 재현 검증
df = pd.read_csv('outputs/v9_baseline_ext/summary.csv')
assert len(df) == 45
for m in ['Autoformer','Informer','FEDformer']:
    sub = df[df.model==m]
    assert sub[['pape','hr_tol1','mse']].notna().all().all()

# (2) MLflow lifecycle 확인
client = mlflow.tracking.MlflowClient()
runs = client.search_runs(['766380978402830870'], run_view_type=3)  # ALL
active = sum(1 for r in runs if r.info.lifecycle_stage == 'active')   # 46
deleted = sum(1 for r in runs if r.info.lifecycle_stage == 'deleted') # 3

# (3) train_loss 로깅 확인
for r in runs:
    if r.info.lifecycle_stage == 'active' and r.info.run_name != 'aggregate_mean':
        hist = client.get_metric_history(r.info.run_id, 'train_loss')
        assert len(hist) == 0  # 전량 누락 — CRITICAL

# (4) seed=42 보조 비교
seed42 = df[df.seed==42]
for m in ['Autoformer','Informer','FEDformer']:
    sub = seed42[seed42.model==m]
    print(m, sub.pape.mean(), sub.hr_tol1.mean())

9. 종합 판정 (재명기)

  • H9-5a: FAIL 판정 robust (model-level 모든 모델이 model-level 두 축 gating 미달, 검증 완료).
  • exp-expert 보고서: Revision-Required — Critical 2건 + Major 4건 + Minor 6건. Critical 은 MLflow 로깅 규약 위반 미인식, Major 는 Apt51 post-hoc + Wall-clock 치환 + seed 비대칭 순위 해석 + MLflow 정리 주체 불명 기술.
  • 수정 완료 후 reporter 진입 가능. 재실행 불필요.

다음 체인: exp-expert revision cycle 트리거 → 위 6.1/6.2 체크박스 완료 → 재제출 후 critic 판정 재확인 → reporter.