Encoder Fine-Tuning
정해진 label을 안정적으로 많이 처리해야 하는 task라면, pretrained Encoder를 해당 task에 fine-tuning하는 것이 유효한 선택이다. Open-ended text를 생성하는 능력과 고정된 label·span·score를 빠르게 내는 능력은 운영 조건이 다르다. 교수님이 강조한 판단 기준은 대표적인 labeled data를 모을 수 있는지, 그리고 task에 맞춰 실제로 tuning할 수 있는지다.
Match the Output to the Workload
Classification에서는 sequence 전체의 label을, NER/PII에서는 token이나 span의 label을, Reranking에서는 query–document pair의 score를 원한다. 이처럼 필요한 output이 명확하면, 그 output에 맞는 head와 objective로 Encoder를 학습할 수 있다.
| Workload | Why an Encoder Fits | Metric |
|---|---|---|
| Spam / Moderation | Stable label set, 높은 처리량 | F1, throughput, cost |
| NER / PII detection | Token-level output, on-prem 요구 | Span F1, p99 latency |
| Reranking | 많은 pair를 scoring | nDCG, pairs per second |
| Guardrail classifier | LLM 앞에서 작은 output으로 판단 | Recall at target FPR |
Guardrail의 Recall은 false positives를 어느 수준까지 허용하는지와 함께 봐야 한다. Reranking도 단순 classification accuracy보다 실제 ranking 품질과 pair 처리량이 중요하다. 이 표는 task에 맞는 metric을 선택해야 한다는 의미다.
Labels와 output format이 안정적이고 대표 training data가 있으며, volume·latency·privacy·on-prem control이 중요하면 Encoder가 맞을 수 있다. 반면 requirements가 자주 바뀌고 labeled data가 부족하거나, open generation과 빠른 prototype이 필요하면 general LLM의 context 활용이 장점이 된다. On-prem이라는 조건만으로 어느 한 architecture를 정하는 것은 아니다. 최종 비교는 내 traffic의 quality, p99 latency, throughput, total cost로 해야 한다.
Fine-Tuning the Backbone and Head
강의 예시는 한국어 checkpoint에 3-class sequence-classification head를 연결한다.
model = AutoModelForSequenceClassification.from_pretrained(
"klue/roberta-base",
num_labels=3,
)이 traditional fine-tuning에서는 Encoder와 task head를 모두 update한다. Head만 학습하는 것과 같은 뜻이 아니다. Head는 sequence를 요약하는 위치의 state를 읽으며, BERT의 [CLS] 역할을 RoBERTa에서는 <s>가 맡는다. Bidirectional Encoder이므로 이 첫 위치도 뒤의 입력 전체를 읽을 수 있다.
Token-level task에서는 각 token의 state에 대응하는 output을 사용한다. 어떤 head를 붙이는지와 backbone을 어떻게 update하는지는 구분해야 하며, Auto class를 사용해도 실제 학습 경로를 이해하고 있어야 한다.
Validate the Conditions, Not Just One Score
강의의 starting grid는 learning rate {2e-5, 3e-5, 5e-5}, epochs {2, 3, 4}, batch {16, 32}다. 이는 탐색의 출발 범위이며 정답을 보장하는 설정이 아니다. Optimizer, schedule, warmup, weight decay, stopping 조건도 함께 기록해야 결과를 비교할 수 있다.
먼저 실제 data의 길이를 보고 max length를 정하며, 잘려 나가는 input의 비율인 truncation도 보고한다. 중요한 정보가 뒤에서 잘리면 모델의 능력과 별개로 target을 맞힐 근거가 사라질 수 있기 때문이다. 전체 평균 metric뿐 아니라 per-class metric을 확인하고, 작은 data에서는 여러 seeds의 mean±std로 변동을 본다.
Class imbalance가 있으면 다수 class만 잘 맞히는 결과가 전체 score에 가려질 수 있다. Class weights나 resampling을 검토하고 task-relevant metric으로 다시 확인한다. 교수님은 실제 classification·quality-estimation 문제에서 이런 imbalance가 흔하다는 점을 강조했다. Pretrained model을 가져오는 일과, 내 data의 분포에서 제대로 동작하는지 검증하는 일은 별개의 단계다.
Check
Stable labels의 대량 moderation에서 Encoder와 LLM generation을 비교할 이유는?
Answer
Output이 정해져 있고 latency/throughput/cost/privacy 조건에서 fine-tuned Encoder가 유리할 수 있다. 실제 traffic의 quality와 함께 검증한다.
Fine-tuning을 head-only 학습으로 이해하면 강의 recipe와 어떻게 다른가?
Answer
전통 full fine-tuning에서는 Encoder와 head를 모두 업데이트한다. Frozen features나 parameter-efficient 방법은 별도 선택이다.