[AI]5단계_RAG_적용_설계_성향기반_장소추천 - 100-hours-a-week/12-marong-Wiki GitHub Wiki
장소 추천 서비스의 RAG 적용 여부에 대한 검토
1. 전체 데이터 흐름도 (RAG 미적용)
사용자 요청 (스크립트 실행)
↓
MBTI/음식 키워드 추출 및 임베딩 (SBERT)
↓
ChromaDB에서 벡터 유사도 기반 검색
↓
후보지 유사도 + 거리 + 평점 기반 점수 계산
↓
최종 추천 결과 선정 및 DB 저장
- 검색 기반 시스템이며 LLM을 통한 생성(Generation)은 없음
- LangChain 미사용, RetrievalQA 미적용
- PyTorch + ChromaDB + 엔트로피 기반 수치 계산만으로 작동
2. 사용 외부 지식 소스 및 선택 이유
| 데이터 소스 | 설명 | 선택 이유 |
|---|---|---|
| Chroma 벡터 DB | 리뷰, 메뉴, 분위기 태그 등의 임베딩 데이터 저장소 | 사용자 성향 키워드 기반 유사도 검색 최적 |
| 크롤링 리뷰 DB(Chroma DB 내부) | 장소 이름, 위치, 평점, 리뷰 메타데이터 | 거리 기반 필터링 및 사용자 경험 반영 가능 |
- 외부 API 불필요
- 자체 구축 데이터만으로 검색 정확도 확보
3. 검색 구현 및 모델 통합 방법
- 임베딩 생성:
- 모델:
snunlp/KR-SBERT-V40K-klueNLI-augSTS - 방식: MBTI/음식 키워드 추출 후 벡터 임베딩
- 모델:
self.keywords = ExtractMBTIKeywords().extract(mbti_vector)
keyword_vectors = [self.embedding_model.encode(k, convert_to_tensor=True) for k in self.keywords]
-
ChromaDB 검색 방식:
- 벡터 유사도 기반 Top-K 후보 반환
-
후처리:
- 사용자 선호 정보, 평점, 거리, 유사도 기반
엔트로피 가중치 조합점수 산출 - 최종 추천 결과 저장 (MySQL + ChromaDB)
- 사용자 선호 정보, 평점, 거리, 유사도 기반
4. RAG 적용 전후 비교 및 검증 전략
| 항목 | 기존 방식 (Rule 기반 추천) | 현재 방식 (벡터 검색 기반) |
|---|---|---|
| 리뷰 반영 | 제한적 | 정교한 SBERT 기반 유사도 적용 |
| 정보 최신성 | 낮음 | 크롤링 리뷰 실시간 반영 |
| 추천 다양성 | 낮음 | 키워드 임베딩 다양성 확보 |
| 운영 비용 | 중간 | 낮음 (LLM 호출 無) |
검증 전략:
- 추천 Top-K Precision / Recall 측정
- 사용자 클릭율 및 피드백 기반 만족도 평가
- A/B 테스트 실험 설계 가능
5. RAG 미적용 사유 및 대안
| 항목 | 설명 |
|---|---|
| 모델 단독 추천 가능성 | 장소 추천은 생성형 문장이 아닌 수치 기반 점수로 충분 |
| 최신 정보 유지 방안 | 주기적인 리뷰/메뉴 크롤링 + 벡터 재인덱싱 자동화 |
| 확장 전략 | SBERT → 최신 KoSimCSE 또는 E5 모델로 교체 가능 |
- LLM 기반 RAG 구조는 불필요하게 과도한 설계
- 오히려 응답 지연, 비용 증가 요인으로 작용할 수 있음
6. 시스템 목표 부합성
-
정확도 향상
성향 기반 임베딩과 벡터 유사도 활용으로 정밀한 추천 가능 -
최신성 확보
db_update.ipynb, db_update.py를 이용하여 장소 리뷰/메뉴/위치 정보의 주기적 업데이트 -
운영 효율성
복잡한 프롬프트/LLM 없이 빠르고 저렴한 시스템 운영