RAG 적용 설계(5단계 과제) - 100-hours-a-week/5-yeosa-wiki GitHub Wiki
1. RAG를 도입하지 않는 이유
a. 외부 지식 검색의 필요 없음
- 프롬프트 생성을 위한 Gemini API 호출은 이미지를 바탕으로 묘사를 생성한다.
- 이 과정에서는 외부 지식(문서, 위키, DB)을 참조할 필요 없이 이미지 자체가 모든 컨텍스트를 제공한다.
- 예를 들어, "이 사진의 구성 요소들을 묘사해주세요"라는 요청은 이미 충분한 입력 조건이며, 별도의 정보 조회가 필요하지 않다.
b. 질의 다양성과 최신성 요구가 없음
- 질문은 단순히 "이 사진을 묘사해줘"이며, 최신 뉴스, 재고, 제품정보, 사용자 로그 등 변동하는 외부 데이터가 개입될 여지가 없음.
- 따라서, 문서 기반 벡터 DB를 만들고 검색하여 모델에 포함시키는 구조는 불필요하고 과설계에 해당함.
c. LLM 자체 생성 능력으로 충분한 품질 확보 가능
- Gemini는 이미지와 예시 프롬프트를 함께 제공할 경우 스타일 특징을 반영한 응답 생성에 충분히 강력하며,
- 이 응답을 Stable Diffusion에 전달하는 것으로 목적이 달성됨.
d. 추후 확장 시
- 추후 확장 시에도 ‘Gemini를 통한 단순 프롬프트 생성’의 구조는 유지될 예정이다.
- 이에 따라 RAG 구조 도입은 없을 것으로 예상된다.