Backbone
S4는 표현력이 크지만 배포 비용이 크다. S3가 비슷한 정확도를 유지하면 모바일 후보가 될 수 있다.
Research design · 2026-06-12
연구 설계와 논문식 실험 기준
이 문서는 Landmark Assistant 모델 실험을 어떤 연구 질문으로 설명하고, 어떤 조건을 통제해야 공정한 비교가 되는지 정리한다. 실제 논문 본문에는 이 문서의 핵심만 압축해 Method, Experiments, Discussion에 옮긴다.
핵심 연구 문제
목표는 단순히 높은 validation score를 얻는 것이 아니다. Flutter 온디바이스 앱에 탑재 가능한 MobileCLIP 계열 landmark recognizer를 만들고, 이미지 검색과 자연어 검색, hard negative 구분, low-confidence 처리까지 설명 가능한 실험 근거를 확보하는 것이다.
Research Questions
| ID | 질문 | 필요한 증거 |
|---|---|---|
| RQ1 | MobileCLIP2-S3와 S4 중 어떤 backbone이 현재 데이터셋에서 더 적합한가? | 동일 dataset, split, train method, loss, epoch 조건의 5-fold 평균과 표준편차. |
| RQ2 | full, partial, LoRA 중 어떤 fine-tuning 방식이 정확도와 배포 비용의 균형이 좋은가? | Top-1, Top-3, macro-F1, hard-case accuracy, trainable parameter, export 가능성. |
| RQ3 | ArcFace 계열 margin loss가 비슷한 궁궐/문루/전각 구분에 도움이 되는가? | confusion pair accuracy, low-margin count, per-class F1, 광화문/근정문/근정전 error analysis. |
| RQ4 | image-text contrastive와 catalog/caption 구조가 자연어 검색 품질에 기여하는가? | 한국어/영어 query recall, alias query, visual-description query, text retrieval failure cases. |
| RQ5 | 선택된 모델이 앱 artifact로 변환되어도 성능과 latency가 유지되는가? | PyTorch ↔ ONNX parity, INT8 parity, artifact size, cold/warm latency, memory usage. |
Hypotheses
Fine-tuning
partial unfreeze는 full보다 안정적일 수 있고, LoRA는 artifact 관리와 반복 실험 비용에서 장점이 있을 수 있다.
Margin Loss
ArcFace는 top-1 평균보다 hard negative margin과 low-margin 감소에서 효과가 더 잘 보일 수 있다.
Multi-task
classification만으로는 특정 class 이름을 맞히기 쉽지만, image-text alignment는 자연어 검색과 caption 기반 retrieval에 필요하다.
Fair Comparison Rule
아래 조건이 다르면 같은 표에서 최종 우열을 말하지 않는다. 다르면 screening 또는 ablation으로 분류한다.
- 같은 dataset fingerprint와 같은 split manifest를 사용한다.
- 같은 fold 수, 같은 seed 정책, 같은 test lock 정책을 사용한다.
- backbone 비교는 train method와 loss를 같게 둔다.
- train method 비교는 backbone과 loss를 같게 둔다.
- loss 비교는 backbone과 train method를 같게 둔다.
- epoch, batch size, optimizer, scheduler, image size, augmentation 차이를 기록한다.
- 결과는 fold별 값, mean, std를 함께 보고 단일 fold만으로 결론 내지 않는다.
Dataset Card에 반드시 남길 것
| 항목 | 기록 내용 | 이유 |
|---|---|---|
| Dataset snapshot | root path, archive name, checksum, 생성일, 작성자. | 나중에 같은 데이터로 다시 split을 만들 수 있어야 한다. |
| Class inventory | class id, parent_landmark_id, image count, confirmed/uncertain/rejected count. | class imbalance와 parent grouping 영향을 설명한다. |
| Labeling provenance | catalog prompt, label prompt, human review, confusion_prior version. | 라벨이 어떤 기준으로 만들어졌는지 검증한다. |
| Leakage control | duplicate hash, source_group_id, 같은 촬영 묶음, train/test 중복 검사. | 실험 성능이 shortcut으로 과대평가되는 것을 막는다. |
| Split manifest | seed, folds, test ratio, confirmed-only 정책, holdout_non_confirmed 정책. | 같은 split으로 재현하고 비교하기 위해 필요하다. |
Model Selection Rule
최종 모델은 단일 점수 최고값만으로 고르지 않는다. 앱 탑재 프로젝트이므로 정확도, 혼동 케이스, 변환 안정성, 모바일 실행 비용을 함께 본다.
- validation mean Top-1과 macro-F1을 1차 기준으로 본다.
- hard-case accuracy와 low-margin count가 나쁘면 평균 점수가 높아도 보류한다.
- Top-3는 사용자에게 후보를 보여주는 앱 UX 안정성 기준으로 본다.
- text retrieval은 자연어 검색 기능을 유지하기 위한 secondary metric으로 둔다.
- ONNX parity와 INT8/mobile runtime이 깨지면 앱 후보에서 제외하거나 별도 artifact 후보로 둔다.
- 차이가 매우 작으면 더 단순하고 작은 모델, 더 안정적으로 export되는 모델을 우선한다.
Threats to Validity
Dataset Bias
일부 class는 야간, wide view, 특정 출처 이미지가 많을 수 있다. class별 support와 scene_group 분포를 같이 본다.
Near Duplicate
같은 촬영 묶음이나 resize/crop 변형이 split을 넘으면 성능이 과대평가된다. hash와 source_group 검사가 필요하다.
Top-1 중심 해석
앱은 Top-3와 confidence policy도 사용한다. Top-1이 높아도 ambiguous/OOS 처리가 약하면 실제 UX는 나빠질 수 있다.
Deployment Gap
PyTorch에서 좋은 모델이 ONNX/INT8/NPU에서 그대로 좋다는 보장은 없다. 변환 후 parity를 따로 본다.