핵심 요약
RAG 답변이 부정확하면 생성(LLM)보다 검색(retrieval)이 원인인 경우가 대부분이다. 관련 없는 청크가 들어오면 모델은 그걸 근거로 틀린 답을 만든다. 청크 크기·오버랩 조정, 메타데이터 필터, 키워드+벡터 하이브리드 검색, 리랭킹으로 적합도를 끌어올리는 게 1순위다.
1. 개선 레버
| 레버 | 효과 |
|---|---|
| 청크 크기(예: 300~800토큰) | 너무 크면 잡음, 작으면 맥락 부족 |
| 오버랩(10~20%) | 경계에서 잘린 문맥 보완 |
| 하이브리드(BM25+벡터) | 고유명사·코드 검색 보강 |
| 리랭커 | 상위 후보 재정렬로 정밀도↑ |
2. 점검 순서
- 먼저 "검색된 청크"를 눈으로 확인 — 답이 그 안에 있나?
- 없으면 검색 문제(청킹·임베딩·필터), 있는데 틀리면 프롬프트 문제
- 평가셋(질문-정답)으로 retrieval recall을 수치화
3. 함정
- 문서를 통째 임베딩하면 핵심이 평균에 묻힌다 — 의미 단위로 청킹
- top_k를 무작정 키우면 잡음·비용↑ — 리랭킹과 병행
- 표·코드는 일반 텍스트 청킹과 다르게 다뤄야 한다
자주 묻는 질문
RAG가 자꾸 틀린 답을 합니다.
먼저 검색된 청크에 정답 근거가 있는지 확인하세요. 없다면 검색 문제이니 청킹·하이브리드·리랭킹을 손보고, 있는데 틀리면 프롬프트에 "근거 밖이면 모른다고 답하라"를 추가하세요.
청크는 얼마나 크게 잡나요?
정답은 없지만 300~800토큰에 10~20% 오버랩이 흔한 출발점입니다. 문서 성격(FAQ·코드·논문)에 따라 평가셋으로 조정하세요.
댓글 0