학습 라벨의 slot 축이 추론을 다시 발명한다
TL;DR
- 구조화 추출 SFT에서
slot_id축(예: P/I/O/T)은 역할(role) 과 섞이면 사고가 난다. - train jsonl에서 slot prefix 히스토그램만 그려도 잔존 축·잡슬롯이 보인다.
- 라벨에 옛 축이 많으면 모델이 그걸 배운다. 라벨을 깨끗이 지워도, 입력 패턴만 보고 축을 재발명할 수 있다.
- 고치는 순서: 감사 → 마이그레이션 → (필요 시) 후처리 가드 → 재학습.
들어가며
이전 글에서 시험지와 loss로 “데이터 쪽” 냄새가 나면, 다음으로 보는 게 라벨 포렌식이다.
특히 JSON 한 건이 조건 배열일 때, 사람들이 대충 붙이는 필드가 slot_id다.
“제외면 E-1”처럼 축과 역할을 한 필드에 섞은 습관이 데이터에 남아 있으면, 스키마를 바꿔도 모델이 옛 습관을 다시 꺼낸다.
1. slot과 role을 한 장으로
| 개념 | 의미 | 예시 |
|---|---|---|
| slot 축 | 질문이 속하는 틀 (PICOT 등) | P, I, C, O, T |
| role | 그 조건의 역할 | inclusion / exclusion / outcome |
| 잘못된 습관 | 제외를 새 축으로 만듦 | 제외 → E-1 |
제외는 축이 바뀌는 게 아니라, 같은 축 + role=exclusion인 경우가 많다.
예: 대상자 제외 → slot_id=P-n, role=exclusion.
2. 포렌식: prefix 히스토그램
train jsonl을 읽어 assistant JSON의 slot_id에서 - 앞을 센다.
P #######
E ######### ← 스키마상 없어야 하는데 더 많으면 위험
O ###
I #
잡음: "제외기준", "1", "주요결과" …
이 한 장이면 “마이그레이션이 안 끝났구나”가 바로 보인다.
3. 케이스 A — 라벨에 옛 축 잔존
| 증상 | 해석 |
|---|---|
train에 E-*가 절반 가까이 |
모델이 E축을 정상 패턴으로 학습 |
| 입력에 제외 섹션 헤더 | 라벨러·교사 모델이 E로 라우팅하기 쉬움 |
slot_id가 제외기준, 1 |
파서/변환 버그 또는 검수 부재 |
이때 “추론만 이상하다”고 보면 시간이 낭비다.
학습 목표가 이미 오염돼 있다.
4. 케이스 B — 라벨은 깨끗한데 추론에서 재발명
반대로 새 데이터는 P/I/O/T만 있는데도, 모델이 제외 문장에서 E-1을 다시 내는 경우가 있다.
| 가능한 이유 | 메모 |
|---|---|
| 입력 패턴이 옛 분포와 닮음 | 섹션 헤더·”제외” 키워드 |
| 프롬프트가 금지만 하고 예제가 약함 | 금지 문장 < 입력 습관 |
| 이전 어댑터/베이스의 잔상 | 학습 레시피 확인 |
| 과적합으로 규칙 일반화 실패 | loss·스트레스 동시 악화 |
이건 “데이터에 E가 있다”가 아니라 일반화 실패에 가깝다.
그래도 대응은 비슷하다: 금지만 외치지 말고 올바른 (slot, role) 예를 충분히, 필요하면 추론 후처리 가드.
5. 고치는 순서
- 감사 — prefix 히스토그램 + 잡슬롯 샘플 10개
- 마이그레이션 —
E-n→ 적절한 PICOT 축 +role=exclusion(규칙 문서화) - 가드(단기) — 추론 출력에서
E-*면 리라이트 (배포 방어막) - 재학습 — 마이그레이션된 셋으로만, 가능하면 epoch·정규화 재조정
- 재채점 — 같은 채점기로 holdout + 스트레스
마치며
slot 축 오염은 “모델이 멍청해서”가 아니라 라벨 계약이 흔들려서 생기는 일이 많다.
다음 글에서는 그보다 더 억울한 경우 — 프롬프트는 지켰는데 채점기가 깎는 경우 — 를 본다.
시리즈
- SFT 결과가 이상할 때 — holdout·스트레스·loss로 먼저 가르기
- 학습 라벨의 slot 축이 추론을 다시 발명한다 (이번 글)
- 모델은 프롬프트를 지켰는데 점수가 깎일 때
Comments