라이브 채팅 위젯에서 지식베이스가 있는데도 '없음' 응답이 나오는 원인과 해결책

동일한 문제를 겪은 경험을 공유하며 대체로 공감이 많을 것으로 보인다. 많은 참여자는 간단한 prior-turn 결합이 빠른 완화책으로 유효하다고 언급할 가능성이 높고 더 정교한 재작성 체인을 도입해 재현성과 정확도를 개선한 사례를 인용할 것으로 예상된다. 반면 비용·지연·프롬프트 설계 복잡성 때문에 즉시 LLM 재작성으로 전환하기 어려웠다는 실무적 제약도 함께 제기될 여지가 있다.

• 문제 발생 시 가장 먼저 실제로 검색 엔진에 전달된 쿼리를 로그로 수집하고 샘플을 재현해 보아야 한다. 원문에서는 많은 'KB가 깨졌다' 보고가 주제 누락으로 인해 잘못된 청크가 반환된 사례였음을 확인했으므로 쿼리 로깅이 불필요한 임베딩 재생성이나 데이터 재수집을 피하는 비용 절감책이 된다. 로그는 쿼리와 대응되는 검색 결과 청크를 함께 보관해 문제 원인 분석에 활용해야 한다.
• 빠른 완화책으로는 검색 쿼리를 최근 3개 사용자 턴과 최신 어시스턴트 턴으로 구성하고 전체 길이를 약 300자 내외로 제한하는 방식을 도입할 수 있다. 이 방식은 봇이 명명한 주제나 누락된 맥락을 쿼리에 포함시켜 즉시 관련 문서를 검색하도록 돕고 구현 난이도가 낮아 우선 적용하기에 적합하다. 서비스별로 적정 턴 수와 문자 제한을 A/B 테스트해 최적값을 찾아야 한다.
• 근본적 해결을 원하면 대화 이력과 현재 턴을 LLM에 입력해 하나의 자립형 질문으로 재작성한 뒤 그 텍스트를 임베딩해 검색에 사용하는 체인을 구축해야 한다. 이 방식은 의미적으로 필요한 맥락만 압축해 전달하므로 검색 정확도가 향상되지만 추가 LLM 호출로 인한 비용과 지연을 설계 단계에서 고려해야 한다. 비용 절감을 위해 재작성 결과를 캐시하거나 빈도 높은 패턴만 적용하는 하이브리드 전략을 검토할 수 있다.

RAG

— 검색 증강 생성은 외부 지식 소스에서 관련 문서를 검색해 그 내용을 조건(context)으로 LLM에 전달하여 응답을 생성하는 방법이다. 입력 쿼리로 관련 문서 조각을 조회하고 조회 결과를 모델의 컨텍스트에 결합해 답변을 생성하므로 검색 품질과 쿼리 구성 방식이 최종 응답 정확도에 직접 영향을 미친다. 대화형 시스템에서는 누적 대화 히스토리를 어떻게 요약해 쿼리로 만드는지가 핵심 구현 과제이다.

Query Rewriting

— 질문 재작성은 대화의 이전 발화와 현재 발화를 하나의 자립형 질문으로 변환하는 기법으로, LLM을 이용해 문맥을 압축하고 핵심 의도를 명료화한 후 임베딩이나 검색에 사용한다. 이렇게 하면 주어지지 않은 주제(예: 봇이 명명한 주제)가 쿼리에 포함되어 잘못된 문서가 검색되는 문제를 줄일 수 있다. 재작성은 검색 결과의 정확도를 개선하고 후속 모델 추론 단계에서 '주제 상실'을 방지하는 역할을 한다.

Conversational Contextualization

— 대화 컨텍스트 구성은 사용자의 연속 발화를 적절히 결합해 검색 쿼리나 모델 입력으로 만드는 과정으로, 최근 턴 수를 단순 병합하거나 의미적으로 압축하는 방식이 있다. 입력을 어떻게 자르고 요약하느냐에 따라 검색된 문서의 관련성 및 모델의 응답 거부 발생 여부가 달라진다. 실무에서는 토큰·문자 수 제한과 응답 지연을 고려해 가중치 있는 창(window)이나 요약 모델을 함께 사용한다.

Embedding Model

— 임베딩 모델은 문장이나 쿼리를 고정 길이의 벡터로 변환하여 유사도 기반 검색에 사용되는 모델이다. 쿼리 임베딩과 인덱스의 문서 임베딩 간 코사인 유사도나 내적을 통해 관련 문서 조각을 선택하므로 입력 쿼리에 어떤 문맥이 포함되느냐가 검색 결과를 결정한다. 임베딩 품질 외에도 쿼리 구성 방식이 검색 성공률에 큰 영향을 미친다.