요약: RAG 품질을 좌우하는 Chunk 전략, 임베딩, Retriever, 평가 지표를 실무 기준으로 정리합니다.
대상 독자: 문서 기반 질의응답 품질을 높이고 싶은 RAG 개발자와 AI 서비스 운영자
핵심 키워드: RAG 성능 최적화, Chunk 전략, Retriever, LLM 평가, 문서 검색
로컬 LLM/RAG 구축 시리즈 바로가기
로컬 LLM 구축 가이드 (3편)
RAG 성능 최적화 + 평가 지표 편
vLLM + FastAPI + VectorDB 기반 문서검색 AI 품질 극대화 전략
이전 편에서 모델 서빙과 API 구축까지 마쳤습니다.
이번 편은 실무에서 가장 많은 시간을 잡아먹는 단계,
바로 RAG 정확도 튜닝 + 평가 지표 설계입니다.
검색 품질이 올라가면
LLM 모델 자체를 바꾸지 않아도 정확도·응답 품질·정답률이 폭발적으로 상승합니다.
1. RAG 성능 최적화의 핵심 요소
RAG 품질은 크게 4가지가 결정합니다.
- Chunking 전략
- Embedding 모델 선택
- VectorDB 필터링·유사도 옵션
- Rerank 모델 적용 여부
이 4가지만 잘 튜닝해도 정확도는 1.5~3배 개선됩니다.
2. Chunk(문서 분할) 전략
Chunking은 RAG 성능의 절반을 결정할 정도로 중요합니다.
✔ 권장 기본 설정
- Chunk size: 400~800 tokens
- Overlap: 100~150 tokens
✔ Chunk가 너무 작으면?
- 문맥이 끊기고 잘못된 문서가 매칭됨
→ “검색은 됐는데 내용이 이상함”
✔ Chunk가 너무 크면?
- 답변에 불필요한 내용 포함
→ “장황하고 핵심 없는 답변”
실무 추천 조합
데이터 형태 Chunk Overlap
| 기술문서/매뉴얼 | 500~700 | 150 |
| 회의록/보고서 | 400~500 | 100 |
| 법률/규정 | 800~1200 | 200 |
| FAQ/짧은 문서 | 200~300 | 50 |
3. Embedding 모델 선택 전략
Embedding 모델은 검색 정확도를 좌우합니다.
✔ 추천 모델 (실무 검증됨)
한국어 포함 문서:
- bge-m3
- bge-large-zh-v1.5 (국문도 의외로 잘 맞음)
- gte-large (다국어 강함)
영어 중심 문서:
- text-embedding-3-large (OpenAI)
- nomic-embed-text v1
✔ 성능을 높이는 3가지 설정
- 문서를 lowercase 변환 X
- 숫자·단위·특수명사 그대로 유지
- 표·리스트·헤더 정보는 Chunk 상단에 포함
4. VectorDB 최적화
사용 DB가 무엇이든 설정이 중요합니다.
✔ 검색 Top-k는 3~7이 가장 안정적
- Top-k > 10: 오히려 LLM 혼란
- Top-k = 1~2: 문맥 누락 증가
✔ 필수 옵션
- cosine 유사도 사용
- 세부 필드로 메타데이터 필터링
(예: 문서 타입, 날짜, 프로젝트명, 보안등급)
✔ 실제 예시 (Chroma)
results = collection.query(
query_embeddings=[embed],
n_results=5,
where={"doc_type": "manual"}
)
5. Rerank 도입 (정확도 체감 상승)
LLM 검색 시스템에서 정확도를 가장 크게 올리는 방법은 Reranking입니다.
✔ 추천 Rerank 모델
- bge-reranker-large
- colbertv2
- cross-encoder/ms-marco-MiniLM-L-6-v2 (경량)
✔ Rerank 적용 파이프라인
검색 단계: VectorDB에서 10개 추출
↓
Rerank 모델로 상위 3개만 선택
↓
LLM Context로 전달
실제 구축 기업 기준,
rerank 적용 후 정확도 20~45% 개선 사례 다수.
6. RAG 성능 평가 지표
사내 AI는 ‘정확도 보장’이 핵심이므로 지표가 필요합니다.
✔ 대표 지표 3개
1) Hit Rate (Top-K Recall)
→ 검색된 문서가 정답 문서를 포함하는 비율
예: Top-5 검색 문서 중 실제 정답 문서가 포함되어 있는가?
2) Faithfulness Score (근거 일치도)
→ LLM이 검색된 문서 내용과 일치해서 답변했는가?
3) Answer Correctness Score (정답률)
→ 도메인 전문가의 수동 평가
7. RAG 프롬프트 최적화
실전에서 가장 효과적인 구조는 아래 형태입니다.
당신은 기업 내부 문서를 기반으로 답변하는 AI 비서입니다.
다음 [검색 결과]만 사용하여 답하세요.
추가적인 지식을 사용하지 마세요.
[질문]
{user_query}
[검색 결과]
{retrieved_docs}
규칙:
1) 제공된 문서 정보만 사용
2) 문서에서 찾을 수 없는 내용은 “문서에 없습니다”라고 답변
3) 핵심만 3~5줄로 요약하여 답변
8. 운영 중 자주 발생하는 문제 해결
문제 원인 해결
| “근거 없는 답변(할루시네이션)” | 프롬프트 규칙 약함 | 근거 기반 답변 구조 강화 |
| “정확도 낮음” | Chunk 구조 불량 | Chunk/Overlap 재설계 |
| “문서가 너무 많아져 검색 느림” | DB indexing 부족 | HNSW 파라미터 튜닝 |
| “국문 품질 이상함” | 영어 모델 사용 | bge-m3 등 국문 우수 모델로 교체 |
실전 팁 3개
1) 처음부터 모델을 바꾸지 말고 Chunking부터 손봐라
→ 잘못된 Chunk 구조가 가장 큰 오류 원인.
2) Rerank는 선택이 아니라 필수
→ 실제 검색 시스템 정확도 향상에 가장 효과적.
3) 평가 지표는 자동화하라
→ Hit Rate와 Faithfulness는 자동화 스크립트 만들면 지속 모니터링 가능.
'AI·LLM 엔지니어링' 카테고리의 다른 글
| 2025.11.27 |
| 2025.11.27 |
| 2025.11.27 |
| 2025.11.26 |
| 2025.11.26 |
실무 적용 체크리스트
점검 항목운영 기준
| Chunk 설계 | 문서 유형별 길이와 overlap을 다르게 설정 |
| 검색 품질 | Top-K, reranking, metadata filter를 함께 튜닝 |
| 답변 품질 | 근거 포함 여부와 hallucination 비율을 평가 |
| 운영 평가 | 정답률뿐 아니라 응답 속도와 재현율을 함께 추적 |
자주 묻는 질문
RAG 성능은 모델 크기만 키우면 좋아지나요?
아닙니다. 검색된 문서 품질, chunk 크기, reranking 여부가 답변 품질에 더 큰 영향을 주는 경우가 많습니다.
Chunk 크기는 어떻게 정해야 하나요?
정답 근거가 한 chunk 안에 들어가도록 시작하고, 문서 유형별로 검색 재현율을 비교하며 조정하는 것이 좋습니다.
RAG 평가는 어떤 지표를 봐야 하나요?
검색 재현율, 근거 충실도, 답변 정확도, 응답 시간, 실패 케이스 유형을 함께 봐야 합니다.
함께 읽으면 좋은 글
- 로컬 LLM 구축 1편: vLLM·GGUF·FastAPI
- 로컬 LLM 구축 2편: GPU 서버 사양
- 로컬 LLM API 서버 구축 심화
- LangChain RAG 구축 1편: 문서 파이프라인
- LangChain RAG 구축 2편: 임베딩·Vector DB
- 1편 — vLLM·GGUF·FastAPI로 사내 AI 서버 만들기
- 2편 — GPU 서버 사양과 환경 구축
- 3편 — RAG 성능 최적화와 평가 지표 (현재 글)
- 4편 — vLLM 모델 서빙 & API 구축 심화
'AI·LLM 엔지니어링' 카테고리의 다른 글
| LangChain RAG 구축 2편: 임베딩 모델 선택과 Vector DB 구축 (0) | 2025.11.27 |
|---|---|
| LangChain RAG 구축 1편: 문서 수집·파싱·전처리 파이프라인 (0) | 2025.11.27 |
| 로컬 LLM 서버 구축 가이드: vLLM, GGUF, FastAPI로 사내 AI API 만들기 (0) | 2025.11.27 |
| 로컬 LLM 구축 2편: GPU 서버 사양·인프라 구성 실전 가이드 (0) | 2025.11.26 |
| 로컬 LLM 구축 1편: vLLM·GGUF·FastAPI로 사내 AI 서버 만들기 (0) | 2025.11.26 |
