챗봇의 블랙박스, 미분류(Other): 원인 분해로 개선하기

챗봇을 운영하다 보면 가장 답답한 순간이 있습니다.
모델 성능이 부족할 때가 아니라, “무엇이 문제인지 명확히 보이지 않을 때”입니다.

당시 운영에서는 응답 경로를 아래 3개로 구분해 확인했습니다.

• FAQ(지식 기반 답변)
• Ticket(문의 접수·이관)
• Other(미분류)

문제는 늘 Other(미분류)였습니다.
지표가 흔들릴 때도 “Other가 늘었다”는 사실까지만 보이고, 그 안에서 어떤 원인이 늘었는지는 잘 드러나지 않았습니다.

3분류 라벨로는 개선이 막연해집니다.
그래서 Other(미분류)를 원인 단위로 분해해, 원인 분포를 확인하고 → 우선순위를 세운 뒤 → 타겟 개선을 실행할 수 있는 구조(A안)로 정리했습니다.

왜 ‘3분류’가 한계가 되는가

Other(미분류)라는 바구니에는 성격이 다른 케이스가 쉽게 섞입니다.

• 일시 장애/타임아웃 같은 시스템 이슈
• 정책상 답변이 제한되는 차단 케이스
• 자동응답보다 사람이 처리해야 하는 문의 접수(티켓) 케이스
• 검색 기반 답변(RAG)의 검색 실패/커버리지 부족/시의성 문제
• 서비스 범위를 벗어난 도메인 이탈(OOD)

원인이 섞이면 개선 액션도 포괄적으로 나가기 쉽습니다.
예를 들어 “일단 모델 점검”, “일단 문서 보강” 같은 조치가 대표적입니다. 다만 실제로는 모델 문제가 아닌데 모델을 만지거나, 반대로 커버리지가 문제인데 라우팅만 조정하는 일이 발생할 수 있습니다.

결국 “데이터는 쌓이는데 개선은 감으로 하는” 상태가 됩니다.

단기 해결책(A안): Other만 ‘원인 단위’로 쪼개기

현실적으로 시스템 전체를 뜯어고치는 것은 어렵습니다.
그래서 선택한 것이 “최소 변경(A안)”입니다.

• 기존 3분류(FAQ / Ticket / Other)는 유지합니다.
• 대신 Other에만 서브타입 라벨을 추가합니다.
• 서브타입은 “분석용 분류”가 아니라 “조치 가능한 액션 단위”로 정의합니다.

이때 기준은 하나였습니다.

“이 라벨이 찍히면, 누가 무엇을 해야 하는가?”

분류에도 우선순위가 필요하다

현업 입력은 깔끔하지 않습니다. 라벨이 겹칠 수밖에 없습니다.
따라서 분류 우선순위를 먼저 고정했습니다.

시스템/차단 → Ticket(문의 접수) → RAG(검색 기반) → OOD → OTHER(잔여)

이 순서를 고정하면 “원인 분포”가 덜 흔들립니다.
운영/개발/PM이 같은 데이터를 보고도 같은 결론을 낼 가능성이 높아집니다.

일반화된 예시 3개(개념 설명용)

아래 예시는 실제 운영 데이터/문구가 아니라, 개념을 설명하기 위한 일반화된 사례입니다.

• 예시 1) 시스템/에러 계열
  • 사용자: “왜 답이 안 나와요?”
  • 기존: Other(미분류)로 묶여 원인 파악이 어려워집니다.
  • A안 이후: System Error로 분리되면 인프라/안정성 점검이 우선순위가 됩니다.
• 예시 2) Ticket(문의 접수) 필요 계열
  • 사용자: “아이템이 사라졌어요. 복구 가능해요?”
  • 기존: Other(미분류)로 묶여 접수 과잉/누락 여부 판단이 어렵습니다.
  • A안 이후: Ticket Required로 분리되면 접수 규칙/운영 정책 개선으로 연결됩니다.
• 예시 3) RAG 실패/답변불가 계열
  • 사용자: “이번 주 업데이트 핵심만 요약해줘”
  • 기존: Other(미분류)로 묶여 ‘검색 실패 vs 문서 부족’ 구분이 어렵습니다.
  • A안 이후: RAG 계열로 분리되면 문서 커버리지/검색 경로/시의성 처리를 우선 점검하게 됩니다.

핵심은 단순합니다.
Other를 분해하면 “기타를 줄이자”가 아니라, “어떤 기타를 줄일지”가 목표가 됩니다.

중장기 해결책(B안): 다차원 라벨링

중장기적으로는 Intent / Handling / Outcome / RootCause처럼 다차원 라벨로 확장하면, 원인 분석과 개선 백로그 분배를 더 정교하게 만들 수 있습니다.

예를 들어 “사용자 의도는 무엇이었는지(Intent)”, “시스템이 어떤 경로로 처리했는지(Handling)”, “사용자 관점에서 해결됐는지(Outcome)”, “왜 그 결과가 났는지(RootCause)”를 분리하면, 개선 과제가 모델·콘텐츠·라우팅·정책·인프라 중 어디에 속하는지 명확해집니다.

다만 이 방식은 로그/데이터 모델 보강이 필요한 영역입니다. 따라서 현실적으로는 단기 구조(A안)로 원인 분포와 우선순위를 먼저 잡고, 이후 단계적으로 확장하는 접근이 적합합니다.

마무리

결국 핵심은 단순합니다.
원인 단위로 분해하고, 분포를 보고, 우선순위를 세운 뒤, 타겟 개선을 실행하는 것입니다.

‘미분류’의 봉인을 푸는 순간부터, 개선은 ‘감’이 아니라 데이터 기반 루프로 굴러가기 시작합니다. 지금은 A안만 적용했지만, 이 구조만으로도 “어디를 먼저 고칠지”가 훨씬 명확해졌습니다.