검색 아키텍처

검색 시스템

1. 색인 · 파이프라인 (적용)

   원천에서 색인까지. 문서 임베딩은 이 축에서 오프라인으로 일어난다

   place DB 를 매일 전량 훑어 새 색인을 만들고 별칭을 한 번에 옮긴다. 상품은 Kafka 이벤트로 증분 색인한다

2. 검색어 파이프라인 (부분)

   검색어가 결과가 되기까지 — 쿼리 재작성 · 쿼리 언더스탠딩 · 리트리벌(키워드 · 덴스) · 하이브리드 RRF · 랭킹을 거쳐 결과를 구성하고, 0건이면 대응한다. 싼 것으로 많이 거르고 비싼 것은 적게 쓴다

   쿼리 이해 · 리트리벌 · 하이브리드 RRF 는 적용이다. 랭킹은 규칙 기반 피처 결합 위에 관광지 국문만 Learning to Rank 재정렬이 붙고, 리랭킹 모델은 재 보고 보류했다

3. 평가 · 로그 (부분)

   오프라인은 판정 세트가, 온라인은 트래픽이 필요하다. 어느 한쪽만 보면 각각의 맹점에 빠진다

   판정 세트 v3(228쿼리 · 9,692쌍)로 매일 nDCG 게이트가 돈다. 검색 → 노출 → 클릭 원장은 이어졌지만 사람이 직접 친 검색이 적고 온라인 A/B 는 없다

4. 서빙 · 운영 (부분)

   색인을 샤드로 나눠 여러 노드에 두고, 질의를 흩뿌려 모으고, 캐시와 지연 예산으로 꼬리를 누르고, 수명 주기 · 백업으로 운영한다

   OpenSearch 3.8 단일 노드(샤드 1 · 레플리카 0)와 질의 인코더 사이드카로 서빙한다. 전용 모델 서빙 스택(Triton · vLLM)은 없다

5. 콘텐츠 이해 (부분)

   문서가 무엇인지를 사람 대신 읽어 둔다 — 지식 그래프 · 구조화된 속성 · 임베딩 · LLM 추출. 색인에 들어갈 필드와 벡터의 질이 여기서 정해진다

   개념 온톨로지 · 분류 코드 사전 · 텍스트 임베딩 · LLM 실내 · 실외 판정이 있다. 멀티모달 임베딩과 검색 결과에 붙은 RAG 는 없다