happybell80 a15415b623 Update: 검색 API 문서에 intent_analyzer 현황 반영

- intent_analyzer.py는 LLM 기반 명령어 변환, 현재 미사용
- 실용적인 패턴 매칭 방식으로 검색 라우팅 제안
- 문서 간소화 (84줄 → 80줄)

2025-09-10 00:42:47 +09:00

2.3 KiB

Raw Blame History

로빙 검색 API 통합 전략

작성일: 2025-09-09
작성자: happybell80 & Claude
관련 서비스: rb8001 (SearchService 내부 구현)
핵심 기술: Multi-provider Search API, Query Routing, Caching

1. 검색 프로바이더 계층 구조

1.1 기본 드라이버: Tavily

검색과 본문 추출 통합 제공
월 1,000회 무료
RAG 파이프라인 단순화

1.2 보조 프로바이더

Brave Search API: 자체 인덱스, 월 2,000회 무료
Serper.dev: Google SERP, 2,500회 무료
DuckDuckGo IA: 즉답형 무료 무제한
Exa API: 심층 분석용 (유료)
SearxNG: 자체 호스팅 폴백

2. 의도 분석 현황 & 라우팅

현재 intent_analyzer.py는 LLM으로 명령어 변환(/news, /digest)만 수행, 미사용 상태. 검색 의도 추가: LLM 프롬프트에 "검색 요청은 /search로" 또는 직접 패턴 매칭.

# rb8001/app/services/search_service.py
def route_by_pattern(query):
    if "뉴스" in query: return 'news_api'
    if "언제" in query: return 'duckduckgo'  # 즉답
    return 'tavily'  # 기본 검색

3. 구현 아키텍처

사용자 → rb8001 내부 SearchService
         ↓
    [Query Router]
         ↓
    [Provider Manager]
    /    |    |    \
Tavily Brave Serper DuckDuckGo
         ↓
    [Result Merger]
         ↓
    [Redis Cache]

4. 캐싱 전략

쿼리 타입	TTL	근거
즉답형	24시간	변하지 않는 사실
일반	6시간	적당한 최신성
뉴스	30분	실시간성 중요
네비게이셔널	12시간	URL 변경 드물음

5. 비용 최적화

월간 쿼터 배분 (70-20-10)

Tavily: 700회 (기본)
Brave: 200회 (다양성)
Serper/Exa: 100회 (특수 목적)

예상 월 비용: $0.05

6. 구현 위치: rb8001/app/services/search_service.py

별도 스킬 서비스 대신 rb8001 내부 SearchService로 구현

의도 분류 후 직접 처리 (네트워크 홉 감소)
Phase 1: Tavily + DuckDuckGo 통합
Phase 2: 복잡도 증가 시 skill-search 분리 검토

7. 핵심 차별점

다층 프로바이더로 안정성 확보
쿼리 타입별 최적 API 자동 선택
무료 한도 최대 활용으로 비용 최소화
캐싱으로 중복 검색 방지

2.3 KiB Raw Blame History