과잉 설계 없는 RAG — 6가지 검색 아키텍처와 선택 기준

왜 대부분의 RAG는 과잉 설계되는가

RAG(Retrieval-Augmented Generation)를 구현할 때 많은 팀이 임베딩, 벡터 데이터베이스, 리랭킹 파이프라인으로 곧장 달려든다. 하지만 사용자가 원하는 것이 "비밀번호 초기화 방법"을 알려주는 문서 하나일 때 이런 복잡성은 불필요하다. AI 엔지니어 Rafael Pierre는 5가지 핵심 요인에 따라 6가지 RAG 아키텍처 중 최적의 것을 선택하는 방법을 안내한다.

5가지 결정 요인

• 데이터 신선도: 실시간 업데이트가 필요하면 재인덱싱이 쉬운 방식을, 안정적인 코퍼스라면 사전 임베딩도 가능하다.
• 코퍼스 특성: 하루 10% 이상 변경되는 고변동 데이터라면 전체 사전 임베딩을 피해야 한다. 장기 테일 분포 문서에는 온더플라이 임베딩이 유리하다.
• 쿼리 패턴: 키워드 중심 쿼리는 풀텍스트 검색으로, 의미 기반 질문은 임베딩으로, 혼합형은 하이브리드 접근이 적합하다.
• 규모와 성능: 하루 1000건 미만이면 단순 방식으로 충분하다. 1만 건 이상일 때만 전면 최적화를 고려한다.
• 팀 역량: ML 전문가가 없으면 풀텍스트 + 쿼리 재작성에 머물러야 한다.

6가지 RAG 레시피

Pierre의 원칙은 "위에서 시작하라. 데이터가 필요하다는 증거가 나올 때만 내려가라"이다.

1. 풀텍스트 검색 + 쿼리 재작성: ML 지식 없이도 구현 가능. 키워드 기반 쿼리에 강하다.
2. 온더플라이 임베딩: 실시간 코퍼스나 장기 테일 분포 문서에 유리.
3. 하이브리드 검색: 풀텍스트와 시맨틱 검색을 결합. 혼합 쿼리 패턴에 적합하다.
4. 사전 임베딩 인덱스: 안정적 코퍼스에서 고성능 시맨틱 검색을 제공한다.
5. 리랭킹 파이프라인: 초기 후보군을 더 정교한 모델로 재순위화. 정밀도가 중요한 고규모 환경에서 사용한다.
6. 멀티-스테이지 파이프라인: 쿼리 분석, 컨텍스트 압축, 적응형 검색을 결합한 최고 수준의 설계. ML 팀이 있을 때만 정당화된다.

핵심 교훈

적합한 도구는 기술적 유행이 아니라 실제 제약 조건에 따라 결정된다. 팀이 제대로 튜닝하지 못하는 과잉 설계된 임베딩 파이프라인보다 잘 관리된 풀텍스트 검색이 더 나은 결과를 낳는다.