- 라벨 규칙(정의/매핑/예외)이 바뀌면 모델이 아니라 데이터가 흔들려요.
- 전처리·특징 추출이 달라져도 같은 문서인데 라벨이 갈라져요.
- 평가 방식(샘플링/윈도우/지표)이 바뀌면 “성능 하락”처럼 보일 수 있어요.
분류 정확도가 갑자기 떨어지면 보통 모델을 의심하죠. 그런데 실제로는 라벨이 기준대로 붙었는지부터 틀어져 있는 경우가 많아요. 특히 “정답 라벨”이 내부 규칙과 어긋나면, 모델이 똑같이 예측해도 점수가 떨어집니다.
아래 6가지만 순서대로 체크해보면, 라벨 불일치가 생기는 구간을 빠르게 좁힐 수 있어요. (각 항목마다 점검 예시도 같이 넣었어요.)
라벨 스키마·정의가 바뀌었는지 먼저 확인해요(규칙 불일치)
정확도가 떨어질 때 가장 흔한 원인이 “라벨이 같은 것 같아도 사실 정의가 다른” 상황이에요. 예를 들면 A 라벨은 “환불 요청”으로 정의돼 있는데, 운영 중 누군가 “환불 문의(정보 요청)”까지 A에 넣기 시작한 경우죠.
점검 포인트
- 라벨 정의 문서(한 줄 규칙/예외 조건)가 최근에 수정됐는지
- 라벨 간 경계(예: ‘문의’ vs ‘요청’, ‘불만’ vs ‘상담’)가 바뀌었는지
- 지도학습용 정답 라벨과 운영용 라벨이 같은 체계를 쓰는지
예시
- 정답 라벨: “기기 고장 신고” = B
- 운영 라벨링: “고장 같아요(추정)”도 B로 처리
- 결과: 모델은 문맥상 추정 표현을 ‘고장 신고’로 보지 못해 C(기타)로 갈 가능성이 커져요.
여기서 한 가지 더 중요한 건, 라벨 정의가 바뀐 시점과 정확도 하락 시점이 같은지예요. 둘이 맞물리면 “모델 문제”가 아니라 “정답 기준 문제”일 확률이 올라가요.
라벨 매핑(동의어/통합)이 달라졌는지 점검해요(예: A→X)
라벨을 학습/평가/서빙 단계에서 서로 다른 방식으로 매핑하면, “정답과 예측이 서로 다른 스키마를 보는” 일이 생겨요. 특히 전처리 파이프라인이나 후처리에서 매핑이 섞이면 더 자주 터집니다.
점검 포인트
- 학습 데이터 라벨이 서빙 라벨과 동일한 ID/명칭 체계를 쓰는지
- 동의어 처리(예: “해지”=“탈퇴”, “환불”=“보상”)가 최근 바뀌었는지
- 멀티라벨/마스크 처리에서 우선순위 규칙이 바뀌었는지
예시
- 학습: “분실” → L1
- 서빙: “분실 신고”는 L2로 매핑
- 평가: L1 정답 기준으로 계산되어 L2 예측이 전부 오답으로 보일 수 있어요.
이 경우 모델 성능이 사실 그대로여도, 지표만 떨어져요. 그래서 “라벨 매핑 로그”를 한 번이라도 찍어보는 게 빨라요.
전처리·특징 추출이 바뀌었는지 확인해요(입력 스키프트)
문서 분류는 입력 텍스트의 가공(정규화, 불용어 처리, 마스킹, 길이 제한 등)이 조금만 달라져도 라벨 경계가 흔들릴 수 있어요. 특히 운영에서 토크나이저/청킹/필드 추출이 바뀌면 “같은 문서”가 “다르게 모델에 들어가는” 문제가 나옵니다.
점검 포인트
- 문서에 붙는 메타데이터 필드(제목/본문/카테고리)가 동일하게 들어오는지
- 청킹 단위(몇 토큰/몇 글자)와 집계 방식(평균/최대/가중합)이 같은지
- 클린업 규칙(이메일/전화번호 마스킹, 숫자 치환)이 바뀌었는지
예시
- 이전: 전화번호 패턴을 “<PHONE>”로 치환
- 이후: 치환하지 않고 그대로 통과
- 결과: 특정 라벨에서 자주 보이던 패턴이 노이즈로 바뀌어 오분류가 늘 수 있어요.
라벨러 가이드(어노테이션) 해석이 흔들렸는지 체크해요(작업자/규칙 드리프트)
라벨링을 사람이 한다면, 시간이 지나며 “해석”이 조금씩 달라질 수 있어요. 이건 모델이 학습을 바꾼 게 아니라, 정답 생성 과정이 바뀐 겁니다.
점검 포인트
- 라벨러 간 합의 규칙(샘플 기준)가 최신인지
- 재라벨링(소급 라벨) 여부가 있었는지
- 가이드에 “애매하면 X” 같은 처리 규칙이 있는지, 실제로 지켜지는지
예시
- 가이드: “증상 설명이 없으면 상담”=C
- 최근: “증상일 수도 있는 문장”까지 상담으로 넓힘
- 결과: ‘진단 요청’ 라벨이 줄고 ‘상담’이 늘면서 라벨 분포가 바뀌어요.
가능하면 최근에 라벨링한 데이터 몇 백 건을 골라 “가이드대로 판정 가능한지”를 다시 검토해보면 원인이 빨리 드러납니다.
프롬프트/템플릿/디코딩 규칙이 달라졌는지 확인해요(지시 불일치)
LLM 기반 분류라면 프롬프트 템플릿, 출력 포맷, 디코딩 설정이 살짝만 바뀌어도 라벨 불일치가 생깁니다. 특히 “라벨명만 출력” 같은 포맷 지시가 흐려지면, 후처리에서 매핑이 실패할 수도 있어요.
점검 포인트
- 프롬프트에 들어가는 라벨 리스트 순서/형식이 동일한지
- 출력 제약(예: JSON 필수, 라벨명 정확 일치)이 지켜지는지
- 온도/Top-p 등 디코딩 설정이 바뀐 적이 있는지
예시
- 이전 템플릿: “가능하면 가장 적절한 라벨 1개만 선택하세요.”
- 변경: “관련 라벨을 모두 선택할 수 있어요.”가 추가됨
- 결과: 멀티라벨이 섞여 후처리 기준과 어긋나면서 오답처럼 보일 수 있어요.
클래스 불균형·평가 방식이 바뀌었는지 점검해요(지표 착시)
라벨 불일치 자체가 아니라, 평가가 바뀌어서 성능이 떨어진 것처럼 보일 수도 있어요. 특히 데이터 분포(특정 라벨이 갑자기 늘거나 줄기), 샘플링 방식(어떤 기간/어떤 채널 위주인지), 지표 계산(매크로/마이크로 F1, 정확도 기준)이 함께 바뀌면 착시가 생깁니다.
점검 포인트
- 평가 기간 윈도우가 달라졌는지(최근 이슈/캠페인 영향)
- 학습-평가 분포가 얼마나 달라졌는지(특정 라벨 급증 여부)
- 평가 지표가 매크로에서 마이크로로 바뀌었는지
- 임계값/후처리 규칙(예: confidence cutoff)이 바뀌었는지
예시
- 이전 평가: 전 라벨을 고르게 샘플
- 이후 평가: 운영 장애 보고 라벨이 몰린 기간만 평가
- 결과: 특정 라벨에서만 오분류가 커져 정확도 전체가 크게 출렁일 수 있어요.
| 체크 결과 | 가능성이 큰 원인 | 바로 해볼 조치 |
|---|---|---|
| 정답 라벨 정의 문서 변경 후 하락 | 규칙 불일치(라벨 스키마/정의) | 정의/예외 조건을 되돌리거나, 재라벨링 범위를 확정 |
| 특정 라벨만 유독 오분류 | 전처리/청킹/라벨 매핑 차이 | 해당 라벨 샘플의 “원문→모델 입력→예측→후처리 결과”를 추적 |
| 전체 라벨 지표가 동시에 출렁 | 평가 방식/샘플링 변경 | 같은 기간·같은 샘플로 재계산(재현성 테스트) |
라벨 불일치 원인 찾기 10분 체크리스트
- 정답 라벨 정의/가이드 문서가 하락 시점 근처에 바뀐 적 있나요?
- 학습 라벨 ID ↔ 서빙 라벨 ID 매핑이 동일한가요?
- 최근 배포 후 전처리(청킹/토크나이즈/필드 추출)가 바뀌었나요?
- 프롬프트 템플릿/출력 포맷/디코딩이 바뀌었나요?
- 평가 기간/샘플링/지표 설정이 바뀌었나요?
위 5개에서 하나라도 “변경”이 걸리면, 그 구간에 맞춰 샘플을 20~50건만 뽑아서 원인 확인을 시작하세요. 원인을 넓게 보기 시작하면(모델만 계속 만지기) 시간이 더 오래 걸립니다.
라벨 정의→라벨 매핑→전처리→프롬프트/출력→평가 방식 순서로, “정답 기준이 흔들린 지점”을 찾아가면 가장 빨라요.
자주 묻는 질문
라벨 불일치면 모델이 ‘나빠진 것’이 아닌가요?
대부분은 “모델이 나빠졌다”기보다, 정답 기준(라벨 정의/매핑)이나 입력(전처리/청킹)이 바뀌어서 점수만 흔들리는 경우가 있어요. 그래서 먼저 정답 생성과 모델 입력이 같은지부터 확인하는 게 안전합니다.
전처리가 바뀐 걸 어떻게 눈으로 확인하나요?
같은 원문 샘플을 잡아 “원문→전처리 결과(모델 입력)→예측→후처리 결과”를 로그로 비교해보세요. 원문이 같아도 전처리 결과가 달라지면 라벨 불일치가 따라붙는 경우가 많습니다.
평가 방식이 바뀌면 어떤 지표에서 특히 티가 나나요?
전체 정확도보다 매크로/마이크로 F1, 클래스별 성능(특정 라벨만 급락)에서 먼저 티가 납니다. 또한 샘플링이 달라졌다면 “재현성 테스트(같은 샘플로 재계산)”에서 쉽게 확인돼요.
프롬프트를 바꿨는데도 라벨이 엇갈려요. 이때는 모델을 다시 학습해야 하나요?
먼저 출력 파싱(포맷이 JSON/라벨명 정확히 맞는지), 라벨 리스트 형식, 디코딩 설정 변화 여부를 점검하세요. 파싱 실패나 매핑 불일치면 학습 전에 해결될 가능성이 큽니다.
정답 기준과 입력 파이프라인이 “같은 가정”에서 돌아가고 있는지만 확인하면, 분류 정확도 하락의 원인을 꽤 빠르게 줄일 수 있어요.
