OOD 기준: 챗봇의 책임 범위를 정하는 법
[AI 품질 개선 시리즈 1/3]
Safety와 UX 충돌: 욕설은 막아도, 버그 제보는 놓치면 안 됩니다
[AI 품질 개선 시리즈 2/3]
fallback_idk 분석: 챗봇의 “모르겠습니다”를 품질 개선으로 바꾸는 법
[AI 품질 개선 시리즈 3/3]
OOD 기준: 챗봇의 책임 범위를 정하는 법
AI 챗봇을 운영하다 보면 OOD라는 기준을 자주 만나게 됩니다.
Out of Domain, 즉 챗봇이 답변해야 하는 범위를 벗어난 질문을 의미합니다.
OOD는 분명 필요합니다.
챗봇이 모든 질문에 답하려고 하면 오답이나 운영 리스크가 커질 수 있기 때문입니다. 하지만 실무에서는 반대의 문제도 생깁니다. OOD를 너무 넓게 잡으면, 원래 답해야 할 질문까지 버리게 됩니다.
그래서 OOD를 판단하기 전에 먼저 정해야 할 것이 있습니다.
바로 챗봇이 어디까지 책임지고 답변할 것인가입니다. 예를 들어 게임 챗봇이라면 기본 범위는 “해당 게임 정보 + CS 처리와 연결되는 질문”입니다. 이 범위를 벗어난 일상 대화, 의미 없는 발화, 타 게임이나 외부 서비스 질문은 OOD로 볼 수 있습니다. 반대로 해당 게임이나 CS 문제와 연결된다면, 표현이 어색하거나 정보가 부족하더라도 바로 OOD로 버리기보다 다른 처리 경로를 먼저 검토해야 합니다.
1. 문제 제기 | OOD는 안전장치이지만, 너무 넓으면 품질을 낮춥니다
OOD는 챗봇 운영에서 중요한 안전장치입니다.
예컨대, 게임 챗봇이라면 게임과 무관한 일상 대화, 타 서비스 질문, 의미 없는 발화, 위험한 요청 등을 무리하게 답변하지 않도록 막아야 합니다.
문제는 OOD가 너무 편리한 분류라는 점입니다.
애매한 질문, 검색 결과가 부족한 질문, 문장이 불완전한 질문까지 모두 OOD로 보내기 시작하면 운영은 편해질 수 있습니다. 하지만 사용자는 답변받을 수 있었던 질문까지 놓치게 됩니다.
예를 들어 에러코드가 포함된 질문이 들어왔다고 해서 바로 OOD로 보내면 어떻게 될까요?
자연어 질문처럼 보이지는 않지만, 실제로는 게임 실행 문제를 해결하려는 질문일 수 있습니다. 이 경우는 도메인 밖 질문이 아니라, FAQ나 RAG, 또는 문의 접수 경로로 연결해야 하는 질문에 가깝습니다. 실제 검토 사례에서도 에러코드나 기술 문구가 포함된 발화를 OOD로 볼 것인지, 답변 대상 또는 지식 보강 대상으로 볼 것인지가 중요한 쟁점이었습니다.
결국 중요한 질문은 이것입니다.
“이 질문은 정말 도메인 밖인가, 아니면 답변 경로를 다르게 잡아야 하는 질문인가?”
2. 왜 생기나 | OOD 안에는 서로 다른 문제가 섞여 있습니다
OOD 판단이 흔들리는 이유는, 실제 로그 안에 성격이 다른 케이스가 섞여 있기 때문입니다.
[OOD로 보내기 전에 다시 봐야 하는 케이스]
- 오타/띄어쓰기 실패
예: “퀘스트어디서받음”, “입장이안되요”
→ 질문 의도는 도메인 안에 있지만 표현이 깨진 경우 - 에러코드/기술 문구
예: “DirectX 12 is not supported”, “OTP error”, “np 1703 10010”
→ 자연어 질문처럼 보이지 않지만 실제 문제 해결 요청일 수 있음 - 검색 결과 부족
예: “○○ 아이템 어디서 얻나요?”를 물었지만 현재 KB/RAG에 정보가 없는 경우
→ 도메인 밖이 아니라 지식 보강 대상 - 멀티턴/문맥 부족 질문
예: 이전 맥락 없이 “그거 어디서 해요?”, “왜 안돼요?”라고 묻는 경우
→ OOD라기보다 재질문이나 fallback 안내가 필요한 경우 - 정책/FAQ 근거 부족
예: “이 버그 보상되나요?”, “제재 풀 수 있나요?”
→ 공식 근거가 부족하면 무리하게 답하기보다 fallback 또는 문의 접수로 연결할 문제
반대로 의미 없는 발화나 단순 잡담성 입력은 OOD로 처리하는 것이 맞습니다.
예를 들어 “123”, “ㅋㅋㅋ”, “안녕”처럼 해당 게임이나 CS 문제와 직접 연결되지 않는 입력은 범위 외 질문으로 보고 안내 후 대화를 종료하는 쪽이 자연스럽습니다.
즉, OOD 문제처럼 보이는 것 중 일부는 사실 지식 부족 문제이고, 일부는 라우팅 문제이고, 또 일부는 정책 기준 문제입니다. 이걸 한데 묶어 OOD로 보내면 개선이 멈춥니다.
3. 어떻게 풀었나 | OOD를 좁게 정의하고, 나머지는 다른 경로로 보냅니다
OOD 기준을 정리할 때 가장 중요한 원칙은 하나였습니다.
진짜 도메인 밖 질문만 OOD로 본다.
그 외의 케이스는 OOD로 밀어내기보다, 더 적절한 처리 경로를 정해야 합니다.
[OOD 판단 기준 정리 방식]
| 구분 | OOD 여부 | 예시 | 처리 방향 |
|---|---|---|---|
| 게임/서비스와 무관한 질문 | OOD | “오늘 날씨 어때?” | 도메인 안내 또는 제한 응답 |
| 타 게임/외부 서비스 질문 | OOD | “다른 게임 쿠폰 알려줘” | 답변 범위 안내 |
| 의미 없는 발화/단순 잡담 | OOD | “123”, “ㅋㅋㅋ”, “안녕” | 범위 외 안내 후, 대화 가능 범위 안내 |
| 오타/띄어쓰기 실패 | OOD 아님 | “입장이안되요” | RAG/FAQ 답변 대상 |
| 에러코드/기술 문구 | OOD 아님 | “DirectX 12 is not supported” | FAQ/RAG 또는 지식(KB) 보강 대상 |
| 검색 결과 부족 | OOD 아님 | “○○ 아이템 획득처 알려줘” | 지식(KB) 보강 또는 fallback 안내 |
| 공식 근거 부족 | OOD 아님 | “보상 받을 수 있나요?” | IDK/fallback 또는 문의 접수 연결 |
| 문맥 부족 질문 | OOD 아님 | “그거 어디서 해요?” | 재질문 또는 fallback 안내 |
이렇게 정리하면 OOD는 “모르는 질문을 버리는 통”이 아니라, 정말 답변 범위 밖인 질문을 제한하는 기준이 됩니다.
실제 현업에서도 OOD는 게임 외 질문, 일상 대화, 의미 없는 발화, 타 게임/외부 서비스 질문에 한정하는 쪽이 적절하다고 봤습니다. 반면 오타, 에러코드, 검색 결과 부족, 멀티턴 미지원 질문 등은 OOD가 아니라 RAG/FAQ 답변 대상이거나 fallback/IDK 처리 대상으로 보는 방향이 더 적절하다고 정리했습니다.
여기서 중요한 것은 OOD만 따로 보는 것이 아닙니다.
작업자와 개발자가 같은 기준으로 판단할 수 있도록, 라벨링 기준도 함께 정리해야 합니다.
예를 들어 단순히 no_match 하나로 묶으면 개선 지점이 잘 보이지 않습니다.
그래서 단기적으로는 no_match를 세분화하고, 장기적으로는 Intent, Handling, Outcome, RootCause 같은 축으로 나눠보는 방식이 필요합니다. 그래야 이 문제가 콘텐츠 문제인지, 라우팅 문제인지, 정책 문제인지, 모델 문제인지 구분할 수 있습니다.
4. 실무적 교훈 | OOD는 버리는 기준이 아니라, 책임 범위를 정하는 기준입니다
OOD를 잘못 쓰면 챗봇은 안전해 보입니다.
하지만 실제로는 답해야 할 질문까지 버리는 서비스가 될 수 있습니다.
그래서 OOD는 “모르는 질문을 밀어내는 기준”이 아니라, 챗봇이 책임질 범위를 정하는 기준이어야 합니다.
게임 챗봇이라면 먼저 책임 범위를 정해야 합니다.
해당 게임 정보와 CS 처리에 연결되는 질문은 가능한 한 답변하거나 적절한 경로로 연결해야 합니다. 반대로 게임과 무관한 일상 대화, 의미 없는 발화, 타 게임이나 외부 서비스 질문은 OOD로 제한할 수 있습니다.
답할 수 있는 질문은 FAQ나 RAG로 연결하고,
근거가 부족한 질문은 IDK나 fallback으로 안전하게 처리하고,
처리가 필요한 질문은 문의 접수나 상담 경로로 넘기고,
정말 도메인 밖 질문만 OOD로 제한해야 합니다.
결국 좋은 AI 챗봇 운영은 질문을 더 많이 답하게 만드는 일이 아닙니다.
무엇을 답하고, 무엇을 보류하고, 무엇을 다른 경로로 연결할지 기준을 정하는 일입니다.
OOD 기준이 정리되어야 라벨링도 흔들리지 않고, 라벨링이 흔들리지 않아야 품질 개선도 정확해집니다.
챗봇이 답해야 할 질문까지 버리지 않으려면, 먼저 OOD의 경계를 좁고 명확하게 그어야 합니다.
One Comment