[논문 연구] Large Scale Pre-Trained Models for Robust Machine Anomalous Sound Detection - 코드 작성 (260910, 작성중)
Deep Learning
논문의 "핵심 알고리즘적 아이디어"는 충분히 반영했지만, "논문 결과를 그대로 재현(reproduce)할 수 있는 수준"은 아닙니다. 목적에 따라 답이 달라집니다.
충분히 반영된 부분 (개념/메커니즘 수준)
논문이 제시한 4가지 핵심 기법이 모두 코드에 구현되어 있고, 각 기법이 서로 결합되어 작동하는 구조도 논문의 Fig. 1과 일치합니다.
| 논문의 기여 | 반영 여부 |
|---|---|
| 대규모 SSL 사전학습 모델 활용 | ✅ 구현됨 |
| WS (레이어별 가중합, Eq. 1) | ✅ 구현됨 |
| Status Augmentation (속도 변조) | ✅ 메커니즘 자체는 구현됨 |
| Transformer Pooling | ✅ 구현됨 |
| AAM-Softmax 학습 (Eq. 2) | ✅ 구현됨 |
| k-NN 이상탐지 백엔드 | ✅ 구현됨 |
| 학습 설정(lr, wd, steps, chunk 길이) | ✅ 논문 수치 그대로 |
즉, "논문이 왜 이렇게 설계했는가"를 이해하고 재현하는 교육/학습 목적이라면 이 코드는 충분합니다.
충분하지 않은 부분
1) 구조적 차이 — 레이블 소스 (가장 치명적)
논문의 핵심 학습 신호는 실제 기계의 attribute 메타데이터입니다. Status Augmentation은 그 위에 얹는 보조 기법일 뿐입니다. 그런데 제공된 데이터셋에는 메타데이터가 없어서, 코드는 Status Augmentation이 만드는 speed factor 인덱스를 레이블 자체로 재활용했습니다.
이는 사실상 "어떤 속도로 재생했는가"를 맞히는 과제로, 논문이 원래 풀려던 "이 기계가 어떤 작동 상태인가"를 맞히는 과제와 학습 목표 자체가 다릅니다. 임베딩 공간이 기계의 실제 작동 상태를 반영한다는 보장이 원 논문보다 약해집니다.
2) Table 1의 수치 재현 불가능
- 기계 종류(7종)별 개별 평가 → 논문 결과와 직접 비교할 기준이 없음
- 공식 DCASE train/test split이 아닌 임의 8:2 분할
- WS 정규화 방식, TFP 세부 구조(head 수, layer 수), AAM margin/scale 등 논문이 공개하지 않은 하이퍼파라미터를 임의로 채워 넣음
→ 이 코드로 학습해도 논문의 hmean 63.76(Table 1 최종 행)과 같은 수치가 나온다는 보장이 없습니다. 벤치마크 재현이나 논문 결과 검증이 목적이라면 부족합니다.
3) 검증 안 된 상태
샌드박스 환경 제약으로 실제 end-to-end 학습을 끝까지 돌려서 loss가 수렴하는지, 임베딩이 실제로 유의미한지 확인하지 못했습니다. 문법 오류는 없지만 동작 검증은 사용자 환경에서 처음 이루어지는 것입니다.
정리
| 목적 | 충분한가? |
|---|---|
| 논문의 알고리즘 구조를 이해/실습 | 예 |
| 자체 데이터(정상/이상만 있는 경우)로 anomaly detection 파이프라인 구축 | 예, 실용적 대안으로 기능 |
| 논문 Table 1 수치를 재현하거나 논문 저자 코드와 벤치마크 비교 | 아니오 — 공식 메타데이터, 공식 split, 비공개 하이퍼파라미터 부재로 불가능 |
만약 정확한 재현이 목적이라면, 실제 DCASE2023 공식 데이터셋(attribute 메타데이터 포함, dcase2023-task2)을 사용하고 dataset.py의 레이블 소스를 메타데이터로 교체하는 것이 필수입니다. 원하시면 그 방향으로 코드를 수정해드릴 수 있습니다.
