분류 프롬프트 정확도, 정의문을 늘리는 것보다 경계 케이스 few-shot 3개가 잘 먹혔다

고객 문의를 카테고리로 분류하는 프롬프트의 정확도가 안 올라서 한동안 정의문만 계속 늘렸다. "환불은 결제 취소 및 금액 반환 요청을 의미하며..." 식으로 각 카테고리 설명을 정교하게 다듬었는데, 정확도는 거의 그대로였다. 모델이 정의를 못 읽는 게 아니라 경계를 못 긋는 거였다.

안 되던 방식

정의를 늘리는 접근은 이런 식이었다.

분류 기준:
- 환불: 결제 취소 및 금액 반환 요청
- 교환: 동일/유사 상품으로의 교체 요청
- 반품: 상품 반송 요청 (환불 동반 가능)
...

정의를 아무리 늘려도 "받은 상품이 불량인데 환불 말고 같은 걸로 다시 받고 싶어요" 같은 케이스에서 교환/반품/환불 사이를 계속 헷갈렸다. 정의가 부족한 게 아니라, 정의들이 겹치는 회색지대에서 모델이 판단을 못 했다.

잘 된 방식

정의는 짧게 두고, 대신 자주 틀리던 경계 케이스를 few-shot으로 2~3개 박았다. 깨끗하고 명확한 예시는 도움이 안 됐다. 모델은 그런 건 이미 잘 맞춘다. 효과가 난 건 매번 틀리던 애매한 케이스를 예시로 고정한 것이었다.

예시:
입력: "불량이라 같은 걸로 다시 받고 싶어요"
분류: 교환   # 환불 아님 — 금액 반환이 아니라 상품 교체가 목적

입력: "환불해주세요. 박스도 안 뜯었어요"
분류: 반품   # 반송이 동반되므로 단순 환불(교환)과 구분

입력: "결제가 두 번 됐어요"
분류: 환불   # 상품 이슈 아님 — 중복 결제 반환

이 세 개를 박고 나서야 정확도가 올라갔다. 핵심은 예시 안에 "왜 이 카테고리인지"의 경계 근거를 주석처럼 같이 넣은 것이다. 모델이 정의는 알아도 경계를 못 긋던 부분을, 예시가 직접 선을 그어준 셈이다.

정리

분류 정확도가 정체되면 정의문을 늘리기 전에 오답 로그부터 본다. 모델이 어디서 헷갈리는지 패턴을 뽑고, 그 경계 케이스를 few-shot으로 고정하는 게 정의를 다듬는 것보다 훨씬 효율이 좋았다. few-shot은 모범 답안 모음이 아니라 의사결정 경계를 보여주는 도구로 쓰는 게 맞다.