happybell80
a15415b623
- intent_analyzer.py는 LLM 기반 명령어 변환, 현재 미사용 - 실용적인 패턴 매칭 방식으로 검색 라우팅 제안 - 문서 간소화 (84줄 → 80줄)
81 lines
2.3 KiB
Markdown
81 lines
2.3 KiB
Markdown
# 로빙 검색 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로" 또는 직접 패턴 매칭.
|
|
|
|
```python
|
|
# 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 자동 선택
|
|
- 무료 한도 최대 활용으로 비용 최소화
|
|
- 캐싱으로 중복 검색 방지 |