v10-01: Server-Centric FL Evaluation — Phase Opening¶
0. Executive Summary¶
v6~v9 phase는 전부 "seen client × personalized local model" 축 위에서 PAPE / HR / MSE를 측정했다. 이는 FL의 전체 파이프라인
Local 정보 수집 → Server aggregate → 분배 중 마지막 두 단계가 만들어낸 서버 모델 자체의 가치를 정면으로 측정하지 못한 구조적 결함을 남긴다.
본 phase(v10)는 FL 연구의 본질적 질문으로 평가 축을 재정렬한다:
"우리의 Local 기여를 aggregate한 서버 모델이 (a) 참여 가구 personalization, (b) unseen 가구 zero/few-shot 전이, (c) communication round 효율의 세 축에서 각각 어디에 있으며, Chronos-Bolt 급 외부 대형 사전학습 서버와 비교해 어떤 보완/우위를 가지는가?"
| 가설 | 내용 | 판정 축 |
|---|---|---|
| H10-1 | FeDPM/FedAvg-DLinear의 aggregate 서버 모델은 held-out unseen 가구에서 Chronos-Bolt zero-shot 대비 1개 이상 메트릭(PAPE 또는 HR)에서 우위 | (B) Unseen 0-shot |
| H10-2 | 1주일(168h) few-shot adapt 후 서버 모델(FeDPM/FedAvg + local adapt)이 Chronos Pooled-LoRA를 HR·PAPE 동시 beat | (B) Unseen k-shot |
| H10-3 | Aggregation ON(FeDPM/FedAvg) vs OFF(local-only) ablation에서 서버 집계가 held-out PAPE를 유의하게(>2%p) 개선 | (A)+(C) 서버 기여 순효과 |
| H10-4 | Chronos FedLoRA (post-hoc adapter aggregation) ≥ Chronos Pooled-LoRA in unseen zero-shot | FM × FL 상호작용 |
Stage 2(critic review) 이후 성공 기준 달성 시 논문 contribution narrative를 "Server-side federated aggregator가 FM zero-shot의 전이력을 보완/초과한다"로 전환한다.
1. 배경: v9까지 평가 축이 Local-centric으로 굳은 이유¶
1.1 현재 파이프라인 감사 결과¶
| 항목 | 위치 | 관찰 |
|---|---|---|
| EVAL 5가구는 federation에 강제 포함 | experiments/federated/v6_0415_fedpm_mvp.py:703 |
fed_households = EVAL_HOUSEHOLDS + extra_households — unseen 평가 불가능 |
| FeDPM 평가 루프 | v6_0415_fedpm_mvp.py:774-779 |
fedpm_models[i] = i번째 가구에 개인화된 로컬 모델로 해당 가구 test만 평가 |
| 서버가 실제 보유하는 것 | src/fed_learning/fedpm.py (MemoryAlignmentServer) |
shared codebook prototypes (shared_ratio=γ)만. encoder/decoder/head는 로컬 소유 → 단일 "server model" 객체가 존재하지 않음 |
| Round 단위 로깅 | v6_0415_fedpm_mvp.py:569-577 |
fedpm_val_loss, codebook_utilization만. held-out 가구에 대한 round-wise 메트릭 없음 |
| Chronos 계열 | experiments/forecasting/v9_0423_chronos_lora.py |
per-household 독립 학습. FL 축에 아예 올라와 있지 않음 |
get_federation_households(exclude=...) |
src/fed_learning/data_utils.py:102-136 |
exclude 파라미터는 이미 존재. held-out 분리 인프라는 무료로 사용 가능 |
→ 가구 분할/평가 모드만 재정렬하면 서버 축 측정은 코드 수준에서는 저비용이다.
1.2 v9-04 결론이 남긴 공백¶
- v9 Stage 1 H9-1 FAIL(HR tol 완화 시 B1이 Chronos 추월) 및 Stage 2 H9-2 PAPE boundary/Watch는 모두 seen-EVAL 5가구 personalized 축에서만 확정되었다.
- Apt6(ΔPAPE −6.97%p) vs Apt30(+5.86%p)의 상반된 LoRA 반응 — critic §4가 제기한 "5가구 mean 위험성" — 은 per-household 축에서는 해소 불가. 서버 aggregate 축으로 옮기면 "pooled/federated LoRA가 per-household 편차를 흡수하는가"라는 답 가능한 질문으로 재구성된다.
- v9-04 §5 옵션 C(Chronos-prior + VQ residual)는 Stage 3 후보지만, 서버 축 정의 없이는 "prior가 얼마나 좋은지"를 독립 평가할 기준이 없어 옵션 C critic §5 리스크("adapter underfit 상태라 prior로 쓰면 zero-shot과 동등")를 입증/반증할 수 없다. v10이 이 기준을 선공급한다.
1.3 경쟁/비교 구도의 정합성 붕괴¶
Chronos-Bolt zero-shot(v6/v9 기준 PAPE 44.98%, HR@1 37.71%)은 본질적으로 "외부 대형 서버 모델이 unseen 가구에 zero-shot 적용된" 성능이다. 이를 우리 FeDPM-R1b(PAPE 37.36%, seen 가구 personalized)와 같은 표에 놓고 비교한 v9-04 §1·§2 표는 엄밀히 서로 다른 저울을 섞고 있다. v10은 두 모델을 같은 저울(unseen 0-shot) 위에서 처음으로 비교한다.
2. 서버 가치 세 축의 조작적 정의¶
| 축 | 기호 | 질문 | 지표 예시 | v9까지 측정 여부 |
|---|---|---|---|---|
| In-federation personalization | (A) | 참여 가구에서 FL이 local-only 대비 우위? | M1 PAPE per seen apt |
✅ |
| Server aggregate generalization | (B) | 서버 지식이 unseen 가구로 얼마나 전이? | M2 PAPE (0-shot), M3 PAPE (k-shot) |
❌ |
| Communication efficiency | (C) | round 수 대비 수렴? | round-to-95% target |
❌ |
본 phase primary goal은 (B), (C)를 채우는 것이다. (A)는 v6/v9 결과를 재사용한다.
3. 실험 프로토콜 (v10-02 exp-designer 이관 대상 초안)¶
3.1 가구 분할 재설계 (결정적 변경)¶
EC50 전체 (year=2016, min_hours=7000 기준 가용 가구 ≈ 50개)
├─ Federation 참여 (K=30): 서버 학습에 기여. 매 round 집계 대상.
├─ EVAL_HOUSEHOLDS (5): {Apt6,15,30,51,88} — v6/v9 호환성 유지. (A) 축.
└─ HELDOUT_UNSEEN (M=5~10): federation에 절대 포함 안 됨. (B) 축의 핵심.
구현 훅:
- src/fed_learning/config.py: HELDOUT_HOUSEHOLDS: list[str] 상수 추가. 선정 방법은 §3.1.1.
- 실험 스크립트: get_federation_households(num_households=K, exclude=EVAL_HOUSEHOLDS + HELDOUT_HOUSEHOLDS) 호출 형태로 강제.
- MLflow tag: split_version="v10", n_held_out, n_federation 기록.
3.1.1 HELDOUT 선정 방법¶
쏠림(쉬운/어려운 가구만) 회피를 위해 계층 추출:
- EC50 전체 가구의
mean,std, 일평균 peak load, weekday/weekend ratio를 4차원 피처로 계산. - K-means(k=M, seed=42)로 층화 후 각 cluster에서 1가구씩 대표 추출.
- EVAL_HOUSEHOLDS와의 Pearson 상관 중앙값이 상위/하위 20% 밖이 되도록 1회 재추첨(있으면).
결정된 목록은 config.py에 하드코딩(재현성). 이 선정 자체를 report/exp-designer/v10-02 smoke 단계 첫 artifact로 MLflow log.
3.2 평가 모드 M1~M4¶
| 모드 | 대상 가구 | 서버 파라미터 사용 | Local adaptation | 측정 목적 |
|---|---|---|---|---|
| M1 Seen-Personalized | EVAL 5 | 학습 중 aggregate 결과 | 라운드별 local epochs (현재 방식) | v6/v9 호환 (A) 축 |
| M2 Server 0-shot Unseen | HELDOUT M | 오직 서버 파라미터만 | 없음 | (B) 서버 지식 전이력 |
| M3 Server k-shot Unseen | HELDOUT M | 서버 파라미터 init | HELDOUT train 앞 {24h, 168h, 720h}만 사용해 소량 local step | (B) + 실용성 |
| M4 Round-wise Held-out | HELDOUT M | round r에서 추출된 서버 파라미터 | 없음 (또는 고정 k-shot) | (C) 수렴 곡선 |
M4 로깅 규칙: 매 round마다 evaluate_server_on_heldout(heldout_clients, server_params)를 호출하여 heldout_pape_round_{r}, heldout_hr_round_{r}을 MLflow step 메트릭으로 기록. 수렴 목표선: held-out PAPE가 Chronos zero-shot 44.98%의 95% 선(= 42.73%)에 도달한 round 수를 primary convergence metric으로 정의.
3.3 "FeDPM에서 서버 모델이란 무엇인가" — 3개 정의의 ablation¶
FeDPM은 구조상 aggregate된 encoder/decoder/head가 없다. unseen에 적용하려면 정의가 필요하다. 이 선택 자체가 논문 contribution의 핵심.
| ID | 정의 | 구현 | 가설 |
|---|---|---|---|
| D1 Codebook-only | 서버 = {shared prototypes γ·M개}. Unseen에는 encoder/decoder/head를 random init + shared codebook freeze + HELDOUT의 k-shot으로 head만 tune | 현재 MemoryAlignmentServer 출력을 그대로 사용, encoder/decoder fresh | "codebook prototype 자체가 전이 가능한 지식"인지를 정면으로 검증 |
| D2 Mean-client | encoder/decoder/head도 참여 가구 파라미터의 FedAvg 평균을 별도로 유지 (학습 중에는 사용 안 함, 평가 전용) | 매 round 종료 시 server_side_shadow = FedAvg(local_models) 추가 저장 |
"개인화 FeDPM에 bonus global model을 공짜로 붙일 수 있는가" |
| D3 Prototype-warm FedAvg | B1 확장. FedAvg로 DLinear+VQ 동시 집계. unseen에는 완전 aggregated model | run_fedavg_dlinear + VQ layer 집계 추가 |
Chronos-Bolt의 FL 사촌 — "중앙 집중 학습 대체 가능성" |
세 정의를 모두 table로 찍어 "어떤 서버 정의가 unseen에서 최선인가"를 비교.
3.4 비교/경쟁 모델¶
모든 모델을 M1/M2/M3 세 모드로 동시 찍는다. 현재 per-household 독립인 Chronos-LoRA는 server 축에서 경쟁군이 아니므로 2개 신규 baseline 추가.
| ID | 모델 | M1 | M2 | M3 | 비고 |
|---|---|---|---|---|---|
| C0 | Local-only DLinear | v6 B0 재사용 | N/A | HELDOUT에서 처음부터 학습 | 하단선 |
| C1 | B1 FedAvg-DLinear | v6 재측정 | 신규 | 신규 | Non-FM FL baseline |
| C2 | FeDPM R1b (β=2) [D1/D2/D3] | v6 재측정 | 신규 | 신규 | Stage 2 winner |
| C3 | Chronos zero-shot | 기록(= M2와 동일) | v6 재사용 | — | FM 외부 서버 상한 |
| C4 | Chronos Pooled-LoRA | 신규 | 신규 | 신규 | federation 참여 K가구 데이터 concat 1개 adapter |
| C5 | Chronos FedLoRA (post-hoc) | 신규 | 신규 | 신규 | v9-Stage2 가구별 adapter 5개 + 추가 K−5개 학습분을 A_mean, B_mean 또는 FedSA-LoRA(A만 평균)로 집계 |
| C6 | v9 per-household LoRA | v9-Stage2 재사용 | N/A (per-house라 unseen 무의미) | N/A | 비교 맥락용 기록 |
C5는 v9 자산 재활용: outputs/v9_chronos_lora/{apt}/r8_seed42/adapter/를 그대로 사용, 추가로 federation 확장 K개 가구의 adapter만 새로 학습(≈ 가구당 30분 × 25 = 12.5h). 학습 없이 기존 5개만으로 먼저 feasibility smoke를 돌릴 수 있다.
3.5 1차 결과 표 (목표 형태)¶
| Model | M1 PAPE (Seen 5) | M2 PAPE (Unseen) | M3 PAPE (Unseen, 168h) | Rounds → 95% target |
|---|---|---|---|---|
| C0 Local DLinear | 42.55 (v6) | — | ? | — |
| C1 B1 FedAvg-DLinear | 43.55 (v6) | ? | ? | ? |
| C2 FeDPM R1b [D1] | 37.36 (v9) | ? | ? | ? |
| C2 FeDPM R1b [D2] | = C2/D1 | ? | ? | ? |
| C2 FeDPM R1b [D3] | ? | ? | ? | ? |
| C3 Chronos 0-shot | 44.98 | 44.98 | — | — |
| C4 Chronos Pooled-LoRA | ? | ? | ? | — |
| C5 Chronos FedLoRA | ? | ? | ? | ? |
"?" 칸이 곧 v10 phase의 primary deliverable. 동일 표를 HR@1, HR@2, MSE로도 중복 산출.
4. Stage 구성 및 성공 기준¶
Stage 0 (현재 문서) — Phase opening + goal analysis¶
- 산출:
report/version10/lab-leader/v10-01_fl_aspect.md(본 문서) - Gate: 사용자 승인 → exp-designer 호출
Stage 1 — Split & infrastructure¶
- exp-designer:
v10-02_server_centric_design.md상세 설계 - engineer:
HELDOUT_HOUSEHOLDS선정 스크립트 +evaluate_server_on_heldout()헬퍼 + round-wise held-out 로깅 훅 - 산출물: 가구 선정 결과 CSV + MLflow logged
- Gate (Pass): HELDOUT 5~10가구 리스트 재현성 확보, smoke로 M2 경로가 Chronos zero-shot과 일치(0-shot이므로 값이 일치해야 함) 확인
Stage 2 — Non-FM FL 서버 평가 (C0, C1, C2/D1~D3)¶
- 각 모델에 M1/M2/M3 3모드 + M4 round-wise 수집
- 3-seed 확대 기본 (v9 결론 교훈 반영 — boundary 판정 방지)
- Gate:
- Pass: H10-1 성립 (FeDPM 또는 B1이 held-out PAPE 또는 HR@1에서 Chronos zero-shot 우위 중 하나 달성) + H10-3 성립(aggregation ON/OFF 간 held-out PAPE 차이 >2%p, p<0.05 paired)
- Watch: Pass 조건 중 하나만 충족 → Stage 3로 조건부 진행
- Fail: 둘 다 실패 → FL 축의 contribution을 "unseen 전이력"에서 "comm 효율" 또는 "privacy 가드" 축으로 재프레이밍 (ADR 작성 후 phase close)
Stage 3 — FM 계열 FL 서버 평가 (C4, C5) + 종합 비교¶
- Chronos Pooled-LoRA, FedLoRA(FedAvg + FedSA-LoRA 2개 aggregation) 학습 및 M1/M2/M3 수집
- v9 adapter 재활용(C5 post-hoc feasibility smoke)을 먼저 돌려 비용-효익 검증 후 본학습 진입
- Gate:
- Pass: H10-2 또는 H10-4 성립 → 논문 narrative "FM × FL × on-device" 완성
- Watch: Pooled-LoRA > FedLoRA (서버 집계가 centralized에 밀림) → 왜 밀리는지(non-IID 심도, rank, aggregation 방식) 원인 분석 1 subphase 추가
- Fail: 두 FM-FL 모두 Chronos zero-shot보다 unseen에서 악화 → Stage 3 closure + "FM-FL은 본 데이터에서 효과 없음" 명제 기록
Stage 4 (옵션) — Stage 3 결과 반영 후 v9 옵션 C(Chronos-prior + VQ residual) 재개¶
- Stage 3에서 C4/C5가 unseen에서 살아남으면 prior 품질이 입증된 것이므로 옵션 C 경로 진입 정당화됨
- 아니면 v6 R1b 계열 심화(PAPE<37.36 목표)로 분기
성공 기준 공식 (phase 전체)¶
| 레벨 | 조건 |
|---|---|
| Primary Pass | Stage 2 Pass + Stage 3 Pass |
| Secondary Pass | Stage 2 Pass만 (FM-FL은 Watch/Fail이어도 비-FM FL 기여 확정) |
| Narrative Pivot | Stage 2 Fail → ADR-011 "FL contribution axis pivot" |
5. 위험 및 가드¶
| # | 위험 | 영향 | 가드 |
|---|---|---|---|
| R1 | HELDOUT 선정이 편향 → M2 결과가 우연 | H10-1 결론 신뢰도 훼손 | §3.1.1 층화 추출 + 대체 시드로 sanity re-run 1회 |
| R2 | FeDPM D1(codebook-only)은 encoder fresh로 시작 → k-shot 부족 시 붕괴 | M3 결과가 "FeDPM 무력" 오인 | k ∈ {24h, 168h, 720h} 3-point sweep. 168h를 primary로 삼고 24h/720h는 monotonicity 확인용 |
| R3 | Chronos Pooled-LoRA(C4)가 너무 세서 H10-2 실패가 자동 확정 | Stage 3 narrative 붕괴 | C5 FedLoRA에 FedSA-LoRA + DoRA bias=LoRA 변형 추가 풋프린트 확보. narrative를 "FedLoRA ≥ Pooled"가 아니라 "privacy-preserving 제약 하에서는 FedLoRA"로 재조정 가능하도록 §4 Stage 3 Watch 분기 선언 |
| R4 | Round-wise held-out 평가는 계산 비용 증가 | 총 phase 시간 증가 | HELDOUT 평가 주기를 매 5 round로 조정 가능. "최종 수렴" 판정이 우선이므로 curve 해상도는 타협 가능 |
| R5 | v9 adapter 재사용 C5가 seed=42 단일 → H10-4 통계 약함 | critic 쟁점화 | 처음부터 3-seed 기준. 기존 seed=42 adapter는 1 point로만 사용하고 {123, 456} 추가 학습 요구 → engineer workload 체크 필요 |
| R6 | FeDPM D2(shadow mean-client)가 실제로는 B1(FedAvg DLinear)과 통계적으로 동등할 가능성 | D2 정의의 논문 가치 훼손 | D2는 "공짜로 붙는" 옵션이므로 별도 추가 비용 없음. 동등 판정이 나와도 실패는 아님(오히려 "FeDPM 개인화가 aggregation에서 얻는 게 없다"는 발견 자체가 기록 가치) |
6. v9 산출물 재활용 인벤토리¶
| 자원 | 경로 | v10 재사용처 |
|---|---|---|
| v6 baseline 예측 | outputs/v9_recap/**/predictions/*.npy |
C0/C1/C2 M1 재측정 불필요, 표 그대로 인용 |
| v9 가구별 LoRA adapter | outputs/v9_chronos_lora/{apt}/r{4,8}_seed42/adapter/*.safetensors |
C5 FedLoRA post-hoc aggregation 1차 smoke |
| v9 LoRA 학습 스크립트 | experiments/forecasting/v9_0423_chronos_lora.py |
C4 Pooled-LoRA 데이터 로더 교체 + apt_loop 제거로 재사용 |
| FeDPM 학습 스크립트 | experiments/federated/v6_0415_fedpm_mvp.py |
C2 학습 루프. evaluate_server_on_heldout 훅 추가만 필요 |
| HELDOUT 분리 인프라 | fed_learning.data_utils.get_federation_households(exclude=...) |
이미 구현됨. 상수만 추가 |
| MLflow re-eval pattern | v9-03 results § | round-wise held-out 메트릭 스키마로 차용 |
예상 신규 학습 워크로드(조감): - C1/C2 3-seed × 3 D정의 ≈ 9 runs × ~30분 = 4.5h - C4 Pooled-LoRA 3-seed × 2 rank = 6 runs × ~3h = 18h - C5 FedLoRA 학습 필요분(K=30 - 기존 5) = 25 adapter × ~30분 = 12.5h (단, 3-seed 확장 시 ×3 = 37.5h) - 기타 평가/smoke ≈ 5h → 단일 RTX 5070 Ti 기준 총 ≈ 40~65시간. 3-seed를 C4/C5에 대해 seed=42 primary + {123, 456} 보조로 할 경우 30~40h로 축소 가능. 2 병렬(VRAM 여유 확인된 v9 전례) 시 실제 wall-time 절반.
7. 문헌 근거 (v9-02 서베이에서 연장)¶
- FedSA-LoRA (Sun et al., ICLR 2025, arXiv:2410.01463) — C5의 기본 aggregation 선택지.
- FFA-LoRA (arXiv:2403.12313) — A 고정 / B만 학습으로 non-IID aggregation bias 제거. C5 변형.
- FedEx-LoRA (arXiv:2410.09432) — exact aggregation via residual. 통신 비용 증가는 있으나 H10-4 판정 강화 목적으로 대안 체크.
- FeDaL (arXiv:2508.04045, 2025) — "shared generalized knowledge + preserved personalized knowledge" 분해. D1/D2 해석 근거.
- TIME-FFM (NeurIPS 2024) — FM×FL×TS 구체 사례. M2/M3 평가 프로토콜 차용 근거.
- Xu et al. (arXiv:2502.09744, 2025) — medical TS FM FL. heterogeneous client + privacy 문맥에서 held-out 평가 필수성 논거.
- FeDPM / Memory Alignment — v6 내부 자산, D1의 이론 기반.
- Chronos-Bolt AutoGluon docs (2024–2025, AWS) — C4 Pooled-LoRA 학습 하이퍼파라미터 (lr=1e-5, 1000 steps) 준거.
8. 다음 단계 (승인 대기)¶
- User approval gate (현재) — 본 설계 방향 승인 시 아래 2, 3으로 진행.
- exp-designer 호출 —
v10-02_server_centric_design.md작성 (§3, §4 Stage 1 상세, HELDOUT 선정 스크립트 스펙, M2/M3/M4 평가 함수 signature, D1/D2/D3 구현 pseudocode, MLflow 로깅 스키마). - engineer 호출 — v10-02 설계 기반 구현.
HELDOUT_HOUSEHOLDS선정 스크립트 +evaluate_server_on_heldout()헬퍼 + FeDPM D2 shadow-aggregator 훅 + MLflow round-wise held-out 로깅.
ADR은 Stage 2 Fail 판정이 나오기 전까지 보류(v10 phase는 v9 방향의 "평가 축 확장"이지 방향 전환이 아님). Stage 2 Fail 시 ADR-011_fl_contribution_axis_pivot.md 예약.
판정 (draft)¶
v10 phase는 "서버 aggregate 모델이 unseen 가구에 얼마나 전이되는가 + Chronos-Bolt 급 외부 FM 대비 어디 위치하는가"를 처음으로 측정하는 것을 primary goal로 설정한다. 성공 시 논문 contribution이 기존 "peak-weighted loss + residual의 local 우위"에서 "FL 서버 모델이 FM zero-shot과 경쟁/보완"으로 승격된다. 실패 시 contribution을 privacy/comm 축으로 피벗 (ADR-011).
phase opening draft 완료. user 승인 후 v10-02 exp-designer 설계서로 이관.