fallback_idk 분석: 챗봇의 “모르겠습니다”를 품질 개선으로 바꾸는 법

[AI 품질 개선 시리즈 2/3] 
fallback_idk 분석: 챗봇의 “모르겠습니다”를 품질 개선으로 바꾸는 법

AI 챗봇을 운영하다 보면 자주 마주치는 응답이 있습니다.
“죄송합니다. 잘 모르겠습니다.”
“아직 답변이 준비되지 않은 내용입니다.”

실무에서는 이런 “모르겠습니다”류 응답을 fallback_idk 같은 실패 버킷으로 따로 모아보기도 합니다. 중요한 것은 이 버킷을 단순 실패로만 보지 않는 것입니다. fallback_idk는 챗봇이 답하지 못한 결과이기도 하지만, 동시에 어디서 품질이 깨지고 있는지 알려주는 신호이기도 합니다.

특히 이런 응답이 반복된다면 먼저 질문을 바꿔야 합니다.
“왜 답을 못했을까?”보다 중요한 것은 정말 몰라서 못 답한 것인지, 원래 답할 수 있었는데 매칭에 실패한 것인지를 구분하는 일입니다.

1. 문제 제기 | “모르겠습니다”는 하나의 실패처럼 보입니다

챗봇이 “모르겠습니다”라고 답하면 운영자는 보통 이렇게 생각하기 쉽습니다.

“아, 이건 챗봇이 답변하지 못한 질문이구나.”

물론 맞는 말입니다.
하지만 충분한 설명은 아닙니다.

실제 로그를 보면 fallback_idk 안에는 서로 다른 질문들이 섞여 있습니다.
퀘스트나 길찾기처럼 원래는 답변할 수 있어야 하는 질문도 있고, 설정이나 조작법처럼 FAQ로 처리할 수 있는 질문도 있습니다. 계정, 결제, 오류, 신고처럼 챗봇이 직접 해결하기보다 상담이나 문의 접수로 연결해야 하는 질문도 있습니다.

그런데 이 모든 질문이 같은 “모르겠습니다”로 끝나면, 사용자는 답답함을 느낍니다.
더 큰 문제는 운영자도 무엇을 고쳐야 하는지 알기 어려워진다는 점입니다.

fallback_idk가 많다는 사실만으로는 부족합니다.
중요한 것은 어떤 질문들이 왜 fallback으로 떨어졌는지를 보는 일입니다.

2. 왜 생기나 | fallback_idk 안에는 여러 원인이 섞여 있습니다

fallback_idk는 결과입니다.
사용자 입장에서는 “모르겠습니다”라는 응답이고, 운영 관점에서는 답변 실패 버킷입니다.

하지만 그 원인은 하나가 아닙니다.

예를 들어 어떤 질문은 실제로 지식베이스에 정보가 부족해서 답하지 못합니다.
이 경우는 콘텐츠나 FAQ, RAG 문서를 보강해야 합니다.

반대로 어떤 질문은 답변할 수 있는 정보가 있었지만, 챗봇이 질문을 적절한 의도나 도메인으로 매칭하지 못해 no_match로 떨어집니다.
이 경우는 지식 부족보다 라우팅이나 의도 분류 문제에 가깝습니다.

또 어떤 질문은 챗봇이 직접 해결하기 어려운 영역입니다.
계정, 결제, 제재, 오류처럼 개인정보 확인이나 운영 처리가 필요한 경우가 그렇습니다. 이런 질문은 억지로 답변하기보다 정책 안내와 문의 접수 경로를 함께 제공하는 것이 더 안전합니다.

즉 fallback_idk는 단순히 “모르는 질문”의 묶음이 아닙니다.
그 안에는 지식 부족, 매칭 실패, 라우팅 문제, 상담 필요, UX 안내 부족이 섞여 있습니다.

그래서 fallback_idk를 줄이려면 먼저 이 버킷을 잘게 나눠봐야 합니다.

3. 어떻게 풀었나 | fallback을 개선 과제로 바꿨습니다

fallback을 개선하려면 먼저 로그를 많이 보는 것보다, 어떻게 나눠볼지가 더 중요합니다.

저는 fallback_idk를 하나의 실패로 보지 않고, 개선 과제로 바꿔볼 수 있는 단위로 나눠봤습니다.

[fallback_idk를 개선 과제로 바꾸는 방식]

이렇게 나누면 fallback은 단순 실패 로그가 아니라 개선 백로그가 됩니다.

중요한 것은 모든 fallback을 무리하게 답변으로 바꾸는 것이 아닙니다.
어떤 질문은 답해야 하고, 어떤 질문은 되물어야 하고, 어떤 질문은 상담이나 문의 접수로 넘겨야 합니다.

그래서 개선 방향도 크게 세 가지로 정리할 수 있습니다.

첫째, 답할 수 있는 질문은 지식과 라우팅을 보강합니다.
퀘스트, 설정, 아이템처럼 정보 기반으로 답할 수 있는 질문은 KB, RAG, FAQ를 보강하고 해당 도메인으로 잘 들어가게 해야 합니다.

둘째, 직접 해결하기 어려운 질문은 다음 행동을 안내합니다.
계정, 결제, 제재, 오류처럼 운영 확인이 필요한 영역은 챗봇이 억지로 답하기보다 정책 설명과 접수 경로를 함께 제공해야 합니다.

셋째, 애매한 입력은 바로 실패시키지 않고 한 번 더 묻습니다.
맥락 없는 단문이나 스몰토크성 입력은 “모르겠습니다”로 끊기보다, 사용자가 질문을 이어갈 수 있게 선택지나 예시를 주는 편이 낫습니다.

즉 fallback 개선의 핵심은 “모르겠습니다”를 없애는 것이 아닙니다.
사용자가 다음에 무엇을 할 수 있는지 보이게 만드는 것입니다.

4. 실무적 교훈 | fallback은 실패 로그가 아니라 품질 개선 지도입니다

챗봇이 “모르겠습니다”라고 답했다는 사실만으로는 충분하지 않습니다.
중요한 것은 왜 그렇게 답했는지입니다.

정말 지식이 없어서 답하지 못한 것인지,
답할 수 있었지만 라우팅에 실패한 것인지,
아니면 상담이나 문의 접수로 넘겨야 했는데 다음 행동을 안내하지 못한 것인지 나눠봐야 합니다.

좋은 챗봇은 모든 질문에 억지로 답하는 챗봇이 아닙니다.
답할 수 있는 질문은 놓치지 않고, 답하기 어려운 질문은 안전하게 다음 행동으로 연결하는 챗봇입니다.

그래서 fallback 로그는 단순한 실패 기록이 아니라, 다음 품질 개선의 지도에 가깝습니다.
“모르겠습니다”가 반복된다면, 그 안에는 챗봇이 어디서 막히고 있는지에 대한 힌트가 숨어 있습니다.