Bubblog v2/ask 구현 내역 및 구조 보고서

1) 개요

목표: v1의 고정형 RAG(임베딩 기반 문맥 검색 + 단순 프롬프트) 방식의 한계를 극복
- 기존 시멘틱 서치만으로 글을 찾고 대답하는 방식에서 서브 llm을 통해 검색 계획을 설계하고 하이브리드 검색을 통해 rag를 하는 구조로 고도화
→ 사용자 질문으로부터 **검색 계획(JSON)**을 생성하고, 서버에서 안전하게 정규화/검증 → 시맨틱 검색 또는 하이브리드(벡터+텍스트) 검색 수행 → 응답을 SSE 스트리밍 방식으로 제공
현재 상태: POST /ai/v2/ask (SSE) 엔드포인트 정상 운영 중. 기존 v1 방식은 유지됨.

구분	v1 현황	v2 개선 방향 / 효과
고정 파라미터	임계치(threshold), LIMIT, 가중치(weights) 등이 고정되어 있어 다양한 사용자 요구 반영 불가	top_k, threshold, weights, sort, limit 등을 질문의 맥락에 맞게 유연 조정. 다만 범위는 서버에서 강제하여 안정성 확보
시간/정렬 의도 반영	“최근/이번 달/지난주/9월/작년” 등의 자연어 표현을 반영 못함	filters.time 항목을 받아 KST 기준의 절대 기간(from/to)으로 변환하여 검색 쿼리에 적용. 정렬 순서(최신순/오래된순)도 반영
키워드 민감 질의 대응	단순 임베딩 유사도 기반 탐색만 가능 → 키워드 중심 질의에서 정확도 부족	하이브리드 검색 도입. 벡터 경로와 텍스트(키워드/질의) 경로 병합. 민감한 키워드 반영 가능. 리콜성과 정밀도 균형 개선 가능
관측성(어떤 검색 전략이 쓰였는지 등) 부족	내부 동작이 불투명, 사용자가 왜 이런 응답이 나왔는지 알기 어려움	SSE에 중간 메타 이벤트(search_plan, rewrite, keywords, hybrid_result 등)를 포함하여 어떤 전략으로 검색했는지 사용자에게 투명하게 제공
보안 / 실행 정합성	사용자의 입력에 의한 시멘틱 서치만 수행하므로 실행 정합성 보장	JSON 스키마(strict) + 서버 측 Zod 검증 + 범위 강제. SQL은 파라미터 바인딩 + 템플릿 방식 사용하여 SQL 인젝션 위험 줄임. 부적절한 계획 시 v1 경로로 폴백 가능
토큰 / 비용 관리	고정 상수 기준 접근 → 일부 상황(긴 질의, 많은 결과 필요 등)에서 비효율적	top_k, (추후 적용할 limit / dedupe), 하이브리드 조합 등으로 문맥 길이 및 결과 수를 상황별로 조절 가능 → 토큰 사용 최적화

3) 검색 계획(JSON) 구조 및 안전 표준화

3.1 계획 항목 설계

주요 필드
- mode: "rag" 또는 "post" 모드 선택
- top_k: 검색 후보 수 (1 ~ 10)
- threshold: 유사도 기준 (0 ~ 1)
- weights: { "chunk": number, "title": number } — 합이 1이 되도록 정규화
- filters:

{
  "user_id": string,
  "category_ids?": [number],
  "post_id?": string,
  "time?": string
}

- sort: "recent" 또는 "oldest" 같은 정렬 옵션
- limit: 최종 컨텍스트 수 제한(1 ~ 20)
- hybrid?: (선택 시)

{
  "enabled": boolean,
  "retrieval_bias": "lexical" | "balanced" | "semantic",
  "alpha?": number,
  "max_rewrites?": number,
  "max_keywords?": number
}

- rewrites?: 재작성된 질의 문자열 배열
- keywords?: 핵심 키워드 목록

3.2 계획 생성 및 정규화

프롬프트 지침:
- 서버 고정 필터(user_id, category_id, post_id)는 클라이언트가 변경할 수 없음 (변경 시 무시 또는 오류).
- 플래너는 top_k, threshold, filters.time, sort, limit, hybrid, rewrites, keywords 등을 중심으로 계획 수립.
- 하이브리드 사용 시 retrieval_bias 값을 제시하며, 내부적으로 alpha로 매핑됨 (예: lexical → 0.3, balanced → 0.5, semantic → 0.75).
서버 측 처리:
- 응답(JSON) 형식 강제: 구조 검증, 전체 필드 유효성 검사(Zod 등).
- weights 합 1로 정규화.
- 상대적 시간 표현(“지난주”, “9월 등”)을 절대 기간(from/to)로 변환.
- 하이브리드 설정 값(alpha) 클램프 및 기본값 주입.
- 부적절한 계획인 경우 (스키마 미충족, 범위 초과 등) 자동으로 v1 방식으로 폴백.

4) 검색 엔진 구조: 시맨틱 + 하이브리드

4.1 시맨틱 검색

질문 → 임베딩 생성
postRepository.findSimilarChunksV2(...) 호출 — 파라미터 바인딩 기반 안전 쿼리
유사도 점수 계산:

\[

score = w_{\rm chunk} \times (1 - \text{chunk\distance}) + w{\rm title} \times (1 - \text{title\_distance})

\]
top_k 수만큼 후보 선택, threshold 아래 후보는 필터링