Chatbot router refactoring

Chatbot Router Refactoring: Out-of-Scope Guard 도입기

현재 운영 중인 챗봇의 기본 흐름은 사용자의 질문이 위치 기반(Location) 인지 여부를 판별한 뒤, 그에 따라 벡터 검색 노드 또는 답변 생성 노드로 라우팅된다. 하지만 기존 구조에서는 위치 기반이 아닌 질문도 무조건 벡터 검색을 거치도록 설계되어 있었다. 예를 들어 “What is my name? 같은 단순한 질의조차 벡터 검색을 통해 불필요한 문서를 LLM 입력에 추가했고, 그 결과 응답 속도가 느려지고 토큰 사용량이 증가했다.

이를 해결하기 위해 classify_query() 로직을 확장했다. 기존에는 “location”과 “common” 두 가지 타입으로만 분류했지만, 여기에 “visa” 와 “fallback” 타입을 추가했다. 새로운 라우팅 규칙에 따라 도메인 밖(fallback) 질문은 문서 검색을 생략하고 바로 답변 생성 노드로 보낼 수 있게 했다. 그 결과, 기존 테스트 실행 시간이 310.05초 → 241.72초로 약 22% 단축되었다.

범위 밖 질문 문제와 Out-of-Scope Guard

라우팅 개선 후에도, 범위 밖 질문(예: “Tell me a joke”)에 대해 LLM이 범용 답변을 하는 문제가 남았다. 이를 방지하기 위해, generate 노드 입구에서 도메인 판별을 거쳐 OOS(Out-of-Scope) 시 즉시 안내 메시지를 반환하는 Guard Layer를 추가했다. 이 Guard는 두 가지 기술을 조합했다.

1. Config-driven 룰 기반 필터
   • YAML/JSON 파일에 Allow(도메인) / Deny(스몰톡) 문구를 정의
   • 핫리로드 지원 → 운영 중에도 즉시 반영 가능
2. 다국어 임베딩 앵커 매칭
   • 멀티링구얼 임베딩 모델(multilingual-e5, bge-m3)을 사용해 언어·표현이 달라도 의미 유사도를 판단
   • 쿼리와 Allow/Deny 앵커를 임베딩 후 dot product로 유사도 계산
   • 임계값(allow/deny threshold) 조정으로 민감도 제어

이 방식을 채택한 이유는 다음과 같다.

• 언어 확장성: 키워드 매칭만으로는 다국어/패러프레이즈 대응이 어렵다.
• 운영 편의: 시그널 추가·수정이 즉시 반영되며 재배포가 불필요하다.
• 위험 최소화: Generate 단계 입구에서만 차단하므로 회귀 리스크가 적다.
• 비용/지연 최적화: 소형 임베딩 1회 + 코사인 유사도 계산만 추가, 캐싱 시 지연 거의 없음

구현 방식

OOS Guard는 다음 순서로 동작한다.

1. 도메인 매칭
   • Allow 리스트 매칭 시 바로 통과
   • 매칭 실패 시 Deny 리스트 매칭 + 짧은 질의 휴리스틱으로 OOS 확정
2. OOS 응답
   • 즉시 도메인 유도 안내 메시지 반환 (LLM 호출 생략)
3. 임계값 튜닝
   • 로그에 Allow/Deny 점수 기록, 주 단위 분석으로 threshold 재설정
4. Fallback 보강
   • FAQ 인덱스(BM25/임베딩)로 빠른 조회 후 매칭 시 안전 생성성

성능과 배포 영향

초기 구현에는 Hugging Face의 SentenceTransformer를 사용했으나, 모델 다운로드에 30초 이상 소요되고 Docker 빌드 시간도 10분 이상 증가했다. 운영 효율성을 위해 OpenAI Embedder로 기본 설정을 변경하자, 테스트 실행 시간이 210.45초로 더 줄었고, Docker 빌드도 94.5초, 이미지 크기는 1GB로 안정화되었다.

최종적으로, Out-of-Scope Guard 도입으로 서비스 범위 밖 질문을 LLM 호출 없이 처리하면서도 성능 저하 없이 안정적인 라우팅을 구현할 수 있었다.

OOS 결과: