Source: report/version8/exp-critic/v8_0420_failure_analysis_review.md

v8 실패 분석 adversarial review¶

종합 판정: FAIL (v9 Option d 경로). 보고서의 dominant cause 진단이 틀렸거나 정당화되지 않았으며, 그 오진이 Option d 선정의 핵심 근거이기 때문. 경쟁 ADR-009 (track-f) 가 같은 증거를 더 정합적으로 해석함.

요약¶

v8 보고서는 "v7 decoder capacity (≈35K) vs v6 Transformer decoder (≈270K) 격차"를 dominant 원인으로 지목하고 이를 근거로 Option d (shared linear adapter) 를 선정했다. 그러나 v6 decoder 는 Transformer 가 아니라 FC-MLP (XcodeYtimeDecoder(decoder_type='fc'), ≈957K params) 이며, 이 사실은 경쟁 ADR-009 (track-f) 가 이미 correct 했다. 따라서 §2 근거는 구조 misidentification 위에 쌓였고, §3 Option 비교의 "a/b/c 는 §2.1 1번(capacity)을 해결하지 못함" exclusionary 논리도 함께 무너진다. Option d 는 capacity 해결을 포기한 채 PAPE 45~47 목표로 downgrade 하는 결정인데, track-f 는 capacity 복원을 직접 시도하는 경로임을 §4 에서 전혀 다루지 않는다 (경쟁 ADR 존재 자체가 누락). Cycle 2 재제출 권고.

치명적 문제 (Critical) 🔴¶

C1. v6 decoder 구조 오인 — Option d 선정 전제 붕괴¶

§2 table (line 73) 은 v6 decoder 를 Transformer (d_model=64, nhead=4, d_hid=256, nlayers=4) 로 기술, §2.1 Dominant 논리의 축.

실측 근거: - experiments/federated/v6_0415_fedpm_original.py:126 — args.decoder_type = "fc" (하드코딩) - experiments/federated/v6_0415_fedpm_original.py:216 — XcodeYtimeDecoder(..., decoder_type=args.decoder_type, ...) - src/FedUnit-64D1/lib/models/decoder.py:447 — FCDecoderBackbone (Linear 4-layer MLP) - MLflow params/decoder_type = "fc" (mlruns/628304840000878755/5e040971.../params/decoder_type) - 파라미터 계산: ≈957K

nhead=4, d_hid=256, nlayers=4 는 argparse default 로 생성자에 전달될 뿐, decoder_type='fc' 분기에서 미사용 (decoder.py:524~544만 nhead 활용). 생성자 호출만 보고 분기 로직 누락한 결과.

영향: Option d 예상 PAPE 45~47 "confidence" (§4 근거 3) 가 흔들린다. decoder 가 FC-MLP 라면 v6 복원 경로는 track-f W1 (FC-MLP 포팅) 이 직접적이며 Transformer 교체를 v10 rollback 으로 미룰 이유가 약화.

C2. 경쟁 ADR-009 (track-f decoder swap) §4 미언급¶

docs/decisions/ADR-009_v8_to_track_f_decoder_swap.md 가 존재, critic cycle 1/2 통과. track-f 는 decoder-only 구조 복원으로 §2.1 1번을 직접 해결. v8 보고서 §3/§4/§6 어디에도 "decoder 교체 경로" 가 Option 에 등장하지 않음.

track-f ADR line 40: "v6 decoder = FC-MLP XcodeYtimeDecoder(type='fc'), 956,696 params"
track-f ADR line 41: "Decoder capacity 격차 38.6× (이전 7~8× 추정의 5배)"
track-f ADR line 63: "이전 ADR-009 draft (Option d) 는 본 파일로 대체 (user가 A경로 선정으로 d 기각)"

§3 4 옵션 비교 (a/b/c/d) 가 "VQ 알고리즘 복잡도" 축에만 options 를 나열하고 "decoder/encoder 구조" 축을 누락한 편향된 framing.

C3. Option d 예상 PAPE "45~47" 의 empirical 근거 부족¶

§3 table + §4 근거 2 는 Option d 예상 PAPE 45~47 + "A1(47.1) 에서 소폭 개선" 주장. 하지만 A1 이 지지하는 것은 "VQ 없어도 47.1 달성 가능"이지 "shared linear adapter 가 47.1 이하로 낮춘다" 가 아님. 논리적 비약.

v9 design spec §7 자체가 "≤ 45 는 정직하게 달성 못할 가능성 높음" (line 49) 으로 인정. 즉 Option d 기대치는 A1 동등 수준이며 개선 폭 기대 없음.

주요 문제 (Major) 🟡¶

M1. 파라미터 수 ≈35K vs ≈270K 추정 오류¶

v6 FC-MLP decoder: 957K (track-f 수치)
v6 total: ~1.13M
v7 total: ~50K
실제 격차: decoder 38.6×, total 20~25× (보고서 7~8× 대비 5× 과소)

M2. "VQ 거의 무시된 통신 채널" 해석의 비대칭 적용¶

VectorQuantizer (fedpm.py:112) 의 util 은 unique index / M — frequency-weighted 아님
10개 code 가 batch 100% cover 해도 util 4% — "소수 code 고활용" 과 구별 불가
vq_magnitude, res_ratio, perplexity 재확인 필요

M3. v6 aggregation 전략 교란 누락¶

v6 R1b MLflow: aggregation_strategy=cos_similarity, memory_fill_strategy=client_personalized, similarity_threshold=0.7, gamma=0.95
v7/v8: plain FedAvg
Option d 예상 PAPE 추정에서 이 교란 disclose 안 됨

M4. rounds=10 기각 근거 약함¶

§6.1 (a) 근거는 부족 인정 → "유효 반론 아님" 결론과 모순
V4/V5 rounds=30 1-seed 재실행 없이 가설 기각 premature

M5. "파라미터 튜닝 금지" 해석의 회피¶

ADR-008 §5 원문은 4 옵션 examples 이며 decoder 교체 금지 불명시
§4.5 "user 결정권" 프레이밍이 Option d 정당화 방향으로 편향
track-f ADR line 58: "아키텍처 교체이며 하이퍼파라미터 조정 아님" 명시적 허용

경미 문제 (Minor) 🟢¶

m1. ADR-009 번호 충돌¶

두 파일 공존, v9 ADR 을 archive 또는 rename 필요.

m2. 2-가구 smoke BFS 실패 확정 범위¶

v6 R1b 는 5-가구. Apt6+Apt88 2-가구만으로 "BFS 불가능" 확정 부당.

m3. Optimizer 표기 오류¶

§2 table 의 "AdamW (v6_0415_fedpm_mvp.py)" 는 38.40 run 과 무관. v6_0415_fedpm_original.py:310 은 Adam + differential LR.

m4. §0 "MemoryAlignmentServer 미통합 반증" 논증 오류¶

V4/V5 실패 = alignment 도움 안 됨 은 순환 논증 (decoder 병목이 dominant 면 alignment 효과 masked).

인정되는 강점¶

MLflow 직독 근거: §1 V4/V5 per-round metric 표 재현 가능, 숫자 일치.
V4 vs V5 메커니즘 분리: §1.1 moving target / §1.2 RESET util-but-no-PAPE 독립 변수 분석.
self-check §6: 선제적 4 반론 제시 (일부 근거 약하지만 방향 옳음).
v6 R1b util=4% 발견: track-f ADR 에도 계승된 유효 발견.
workload 수치화: 시간 기반 의사결정 base 제공.

권고 경로: track-f (W1=FC-MLP decoder swap) 우선, Option d 는 rollback¶

축	Option d (adapter)	track-f W1 (FC-MLP)
§2.1 1번 dominant 해결	불가 (decoder 그대로)	직접 해결 (38.6× 복원)
예상 PAPE	47 (A1 동등)	conservative 43~45, stretch 38~40
Workload	3h	5~7h
초록 claim 수정	Yes (VQ 제거)	No (VQ 유지)
재발 위험	낮음	중
논문 기여 3-축	FL peak-loss 단독	FL + VQ + decoder capacity 분리

핵심: exp-expert 의 "§2.1 1번은 4 옵션 중 누구도 해결 못함" 주장은 Option e (decoder 교체) 를 옵션 집합에서 배제한 결과 성립. 제약 걷어내면 track-f 가 capacity 원인을 직접 해결하며 초록 claim 유지. FC-MLP 포팅 workload 도 단순 XcodeYtimeDecoder import 로 2~4h 가능성.

논문 제출 일정 관점: abstract-first rollback 위험. track-f 는 VQ 유지로 abstract 축 변경 없이 진행 가능.

exp-expert 에게 전달하는 필수 수정 사항 (12건)¶

추가 검증 필요 실험¶

V4/V5 rounds=30 재실행 (M4): 1-seed, 30분 내 완료.
v6 R1b MLflow re-analysis (M2): 코드 변경 불필요, 30분.
A1 cell 5-가구 확장 smoke (C3): Option d 예측 empirical base.

결론¶

판정: FAIL (cycle 2 재제출 요구)

핵심: v8 보고서 §2 진단이 v6 decoder 구조를 misidentify, 이 오진 위에서 Option 집합이 편향 구성 (decoder 교체 경로 누락). 경쟁 ADR-009 (track-f) 가 같은 날짜에 이미 correct. Cycle 2 재제출 필수 — 필수 수정 12 건 반영 후 재검토.

2번째 cycle 필요: Critical 3 건 확인 → exp-critic ↔ exp-expert 추가 revision cycle 필요.

근거 MLflow¶

v6 R1b: mlruns/628304840000878755/5e0409718fd347d085190264e43d4284 (PAPE=38.40, util=4.0625%, decoder_type="fc", aggregation=cos_similarity)
v7 V4 seed42: mlruns/488793251950638315/2fab575cef1e470ba8016fd210e9b48f (pape_avg=56.5099, train_loss 1.0866→1.9055, n_components 8→178)
v7 V5 seed42: mlruns/488793251950638315/584cc9a61eba4afe808b677efd4a6c17 (pape_avg=53.3151, train_loss 1.08→1.15, util 86%)