Ask-Docs Architecture: Semantic Embeddings or Keyword Search for a SaaS Help Center?

개요

SaaS 고객 지원 센터의 '문서 기반 질문' 기능을 위해 임베딩 기반 의미 검색과 키워드 검색을 결합하는 최적의 아키텍처는 문서 조각(chunk)에 대한 임베딩을 우선적으로 사용하고, 정확한 식별자 매칭을 위해 키워드 검색을 유지하며, 검색 결과 순위가 낮을 경우에만 리랭킹(reranking)을 추가하는 것이다.

주요 내용

* 검색 전략:
* 일반적인 언어 불일치(고객 질문과 문서 내용 간의 의미 차이)를 해결하기 위해 임베딩 기반 의미 검색을 사용한다.
* 오류 코드, 플랜 이름, API 필드, 송장 식별자 등 리터럴 매칭이 필요한 경우 키워드 검색을 병행한다.
* 초기 구현 단계에서는 벡터 검색을 기본으로 사용하고, 쿼리에 식별자가 포함될 경우 정확한 매칭 결과를 병합한다. 복잡한 다단계 랭킹 시스템은 초기부터 구축하지 않는다.
* 데이터 처리:
* 검색 결과는 문서가 아닌 청크 단위로 반환되므로, 의미 있는 문서 구조로 청크를 분할하고 페이지 제목 및 안정적인 소스 식별자를 유지해야 한다.
* 모든 청크와 함께 테넌트(tenant) 식별자를 저장하여 데이터 격리를 보장한다. 벡터 쿼리 시 테넌트 범위를 불변값으로 적용해야 한다.
* 리랭킹(Reranking):
* 고도로 관련성 높은 구절이 낮은 순위로 밀려나는 문제를 해결하기 위해 벡터 검색 이후 리랭킹을 사용한다.
* 리랭킹은 누락된 문서, 잘못된 테넌트 필터, 부실하게 분할된 청크를 복구하지 못하므로, 먼저 근본적인 문제를 해결해야 한다.
* 비용 가시성 및 계측:
* 멀티테넌트 SaaS 환경에서 모든 검색 및 모델 호출은 테넌트 식별자를 포함하여 메터링(metering)해야 한다.
* 외부 호출당 불변의 사용량 이벤트를 발생시키고, 테넌트 컨텍스트를 요청이 서비스 경계를 벗어나기 전에 첨부하여 나중에 집계한다.
* 기술 스택 선택:
* Pinecone (관리형 벡터 DB), Elasticsearch (기존 렉시컬 검색 기반), PostgreSQL + pgvector (관계형 데이터와 벡터 근접), LiteLLM (셀프 호스팅 게이트웨이), Infrai (통합 API 옵션) 등 다양한 옵션이 있으며, 팀의 요구사항과 기존 환경에 따라 선택이 달라진다.
* Infrai는 단일 키와 청구로 여러 백엔드 모듈을 제공하는 장점이 있지만, 이미 잘 운영 중인 데이터베이스를 대체하는 기준은 아니다.
* 검증 및 배포:
* 리랭킹 기능 통합 전, 라이브 계약을 검증하고, 실제 도움말 센터 질문으로 구성된 작은 평가 세트로 검색 품질을 테스트해야 한다.
* 정확한 청크가 초기 후보군에 포함되는지, 테넌트 필터링을 통과하는지, 최종 답변이 올바른 출처를 인용하는지 추적한다.
* 처음에는 임베딩과 키워드 검색으로 시작하고, 관련 청크가 자주 발견되지만 순위가 낮을 때만 리랭킹을 테스트한다.
* 배포는 3단계로 진행: 평가 세트로 리트리벌(retrieval) 그림자 테스트, 소규모 테넌트 코호트에 대한 결과 노출, 메트릭이 추가 호출을 정당화할 경우 리랭킹 추가.

시사점

SaaS 도움말 센터의 '문서 기반 질문' 기능 구현 시, 테넌트별 데이터 격리 및 비용 투명성을 최우선으로 고려하며, 임베딩 기반 의미 검색을 기본으로 하되 키워드 검색을 보완적으로 활용하고, 실제 데이터에 대한 검증을 통해 리랭킹 도입 시점을 결정하는 것이 효과적이다.