AI 시리즈 면접 문제 11: RAG는 어떻게 최적화할까?

RAG의 최적화는 단일 단계 조정이 아니라 전체 체인 최적화 과정입니다. 여기서는 데이터 인덱스 측면, 검색 측면, 생성 측면, 평가 측면의 네 가지 차원에서 체계적인 최적화 전략을 제시하고, 면접에서 언급할 수 있는 실전 경험도 함께 첨부합니다.

一、데이터 인덱스 측면 최적화 ("지식 베이스" 품질 향상)

가장 간과하기 쉽지만 효과가 가장 빠른 부분입니다.

최적화 포인트	문제 현상	구체적 방법	효과 지표
문서 파싱	PDF의 표, 플로우차트가 무시되거나 텍스트가 깨지거나 순서가 뒤섞임.	더 나은 파싱 라이브러리(예: `unstructured`, `pypdf`의 레이아웃 보존 모드) 사용; 표는 `pandas`로 추출 후 Markdown으로 변환.	리콜 +5~15%
텍스트 청크 크기	청크가 너무 작으면 문맥 손실(예: "올해 매출이 증가했다"에서 주체 누락); 청크가 너무 크면 검색 노이즈 증가.	다양한 청크 크기(256/512/768 token) 실험, 오버랩은 10~20% 설정; 긴 문서는 의미 경계(문단/제목) 기준으로 분할, 고정 길이 사용 지양.	히트율 / 충실도
메타데이터 추가	관련 문단은 검색되나 출처나 시간 추적 불가, 또는 도메인 필터링 필요.	각 청크에 메타데이터 추가: `source`(파일명/URL), `timestamp`, `page_num`, `doc_type`. 검색 시 필터 사용(예: `doc_type == 'legal'`).	필터 정확도
임베딩 모델 선택	범용 임베딩이 특정 도메인(의료, 코드, 법률)에서 성능 저하.	도메인 미세 조정 모델(BGE-large-zh, GTE-Qwen2-7B-instruct) 사용; 또는 triplet loss로 자체 임베딩 모델 미세 조정.	검색 MRR@10 +10~20%

二、검색 측면 최적화 ("책 찾기" 더 정확하게)

검색은 LLM에 제공되는 "참고 자료"의 품질을 결정합니다.

최적화 포인트	문제 현상	구체적 방법	효과
혼합 검색	벡터 검색이 정확한 용어(예: 제품 모델 `ABC-123`)를 매칭하지 못하고, 키워드 검색이 동의어를 이해하지 못함.	벡터 검색(의미)과 BM25(키워드)를 동시에 사용, 가중치(예: 0.7벡터 + 0.3BM25) 또는 rerank로 융합.	리콜 +10~25%
재순위화 (Rerank)	벡터 검색 상위 결과가 항상 가장 관련성 높지 않음, 10번째 결과가 더 좋을 수 있음.	cross-encoder 모델(예: `BGE-reranker-v2`, Cohere Rerank)로 후보 집합(예: 상위 20개) 재점수화, top-K 선택.	히트율 크게 향상 (특히 top-1)
쿼리 재작성	사용자 질문이 모호하거나 다중 턴 대화에서 지시어 불명확("그 가격은?").	LLM으로 원본 질문을 검색에 더 적합한 형태로 재작성(예: "iPhone 15의 가격은 얼마인가요?"); 대화 이력 활용하여 보완.	리콜 +5~15%
HyDE	사용자 질문이 너무 짧거나 추상적(예: "광합성에 대해 설명"), 직접 검색 효과 낮음.	LLM이 가상 답변을 먼저 생성하고, 이 답변으로 문서 검색.	개방형 도메인에 적합, 사실 기반 정밀 QA에는 부적합
검색 수 Top-K 조정	K가 너무 작으면 중요 정보 누락; K가 너무 크면 토큰 소모와 노이즈 증가.	K=3/5/10 실험, 리콜과 답변 충실도 균형 관찰.	효율과 효과 간 트레이드오프

三、생성 측면 최적화 (LLM이 참고 자료를 잘 활용하게 하기)

검색이 아무리 정확해도 프롬프트가 좋지 않거나 모델이 부족하면 소용없습니다.

최적화 포인트	문제 현상	구체적 방법	효과
프롬프트 엔지니어링	LLM이 검색 내용을 무시하거나 허위 생성.	명확한 지시: "제공된 참고 자료만을 기반으로 답변하세요. 자료가 부족하거나 관련 없으면 '충분한 정보가 없습니다'라고 답하세요." few-shot examples를 추가하여 출처 인용 방법 제시.	충실도 +20~40%
컨텍스트 압축	검색된 내용이 너무 길어(모델 컨텍스트 윈도우 초과) 또는 대부분 노이즈.	`LLMLingua` 또는 `선택적 컨텍스트` 압축 사용, 가장 관련성 높은 문장만 남기고 LLM에 전달.	정보 손실 위험 감소
LLM 모델 업그레이드	소형 모델(7B)이 복잡한 추론 불가 또는 긴 컨텍스트 기억 못함.	더 강력한 모델(GPT-4o, Claude 3.5 Sonnet, Qwen2.5-72B)로 교체.	추론 정확도 크게 향상
스트리밍 및 인용	사용자가 답변 신뢰성 검증 불가.	생성 시 LLM이 `[citation:1]` 출력, 검색 문서 번호 매핑. 백엔드에서 원문 링크 제공.	사용자 신뢰도 + 디버깅 용이
거부 응답 보정	모델이 답변하지 말아야 할 때 허위 생성, 또는 답변해야 할 때 모른다고 함.	유사도 임계값 설정: 검색된 top-1 청크와 질문의 코사인 유사도가 0.7 미만이면 LLM에 "자료가 관련 없음" 지시.	환각률 감소

四、평가 및 반복 측면 (최적화 방향 파악)

측정 없이는 최적화가 불가능합니다.

최적화 포인트	방법	지표
평가 세트 구축	100~300개의 실제 사용자 질문 + 정답 + 올바른 검색 문서 ID 준비.	다양한 난이도, 의도 포함.
자동 평가	RAGAS(Faithfulness, Answer Relevance, Context Recall) 또는 TruLens 사용.	세 가지 핵심 지표: 충실도, 답변 관련성, 컨텍스트 리콜.
수동 평가	매주 20개의 bad case 샘플링, 오류 유형 분석(검색 실패 / 생성 오류 / 지식 베이스 부족).	개선 우선순위 정렬.
A/B 테스트	프로덕션 환경에서 버킷 테스트로 다양한 검색 전략(예: BM25 vs 혼합 검색) 비교.	온라인 지표: 사용자 만족도, 무응답률.

五、면접에서 언급할 수 있는 "실전 경험" (가산점)

"제가 담당한 RAG 프로젝트에서 초기 기준 히트율은 67%에 불과했습니다. 저는 세 가지 작업을 수행했습니다:
1. 청크를 고정 1024에서 동적 의미 분할로 변경(제목+문단 기준), 히트율 74%로 향상;
2. 혼합 검색(벡터 + BM25) 및 소형 rerank 모델 도입, 히트율 83%로 상승;
3. 프롬프트 최적화 및 [관련 정보 없음] 강제 요구, 환각률 22%에서 5% 미만으로 감소.

또한 지속적 평가 파이프라인을 구축하여 매 변경 전 200개 질문의 RAGAS 점수를 측정, 성능 저하가 없도록 보장했습니다."

마지막 요약: 완전한 RAG 최적화 로드맵

데이터 층 ─→ 문서 정제, 청크 최적화, 메타데이터 강화, 도메인 임베딩
검색 층 ─→ 혼합 검색, rerank, 쿼리 재작성, HyDE, Top-K 조정
생성 층 ─→ 프롬프트 강화, 지시 요구, 압축, 인용, 거부 임계값
평가 층 ─→ 평가 세트, RAGAS, 수동 분석, A/B 실험