RAG 한계와 보완 전략
청킹의 한계
RAG에서 문서를 벡터화하려면 적당한 크기로 잘라야 하는데, "적당한"의 기준이 없다.
- 너무 크게 자르면 → 검색은 되는데 노이즈가 섞여서 LLM이 헷갈림
- 너무 작게 자르면 → 맥락이 없어서 LLM이 제대로 답 못함
- 같은 문서도 자르는 방식에 따라 검색 결과가 달라짐
문서 형태별 문제
| 문서 형태 | 자르기 쉬운가 | 이유 |
|---|---|---|
| 마크다운 (## 기준) | 비교적 쉬움 | 헤딩이 의미 단위를 나눠줌 |
| 어려움 | 헤딩 구조 없을 수 있음, 표/이미지 섞임 | |
| 코드 | 어려움 | 함수/클래스 단위로 잘라야 의미 있음 |
| 대화 로그 | 어려움 | 화자 전환, 맥락 흐름이 중요 |
청킹 전략들
- 고정 크기 — 500자씩. 단순하지만 문맥 끊김
- 의미 단위 — 헤딩, 문단, 빈 줄 기준. 문서 구조에 의존
- 오버랩 — 앞뒤 100자씩 겹치게. 문맥 유지에 도움
- Recursive — 큰 단위(##)로 먼저 자르고, 너무 길면 작은 단위(\n\n)로 다시 자름
정답은 없고, 문서 특성에 맞게 실험해야 한다.
할루시네이션
RAG가 할루시네이션을 줄이는 거지 없애는 게 아니다.
발생 케이스
검색 실패 — 질문과 관련 없는 청크가 top-k에 들어옴. LLM은 그걸 기반으로 답하니까 엉뚱한 답이 나옴.
과잉 해석 — 컨텍스트에 "RBAC는 역할 기반"이라고만 있는데, LLM이 구체적인 구현 코드를 지어냄. 있는 내용을 넘어서 추론하는 것.
답 없음 무시 — 벡터DB에 답이 없는 질문인데, LLM이 일반 학습 지식으로 채워서 답함. "모르겠다"고 안 하고 그럴듯하게 답하는 게 제일 위험.
왜 프롬프트만으로 못 막나
"노트에 없는 내용은 답하지 마"라고 써도 LLM은 지시를 확률적으로 따른다. 컨텍스트와 질문이 애매하게 겹치면 LLM 입장에서 "있는 내용인지 아닌지" 판단이 흐려짐.
보완 전략
Reranker
1차 벡터 검색으로 후보 20개를 뽑고, 2차로 Cross-Encoder 모델이 질문-문서 쌍의 관련성을 다시 평가. 벡터 검색보다 정확하지만 느림. 그래서 2단계로 씀.
질문 → 벡터 검색 (top-20, 빠름) → Reranker (top-3, 정확함) → LLM
Hybrid Search
벡터 검색(의미)과 키워드 검색(정확한 단어 매칭)을 합치는 것.
- "RBAC"라는 정확한 용어가 중요하면 키워드 검색이 나음
- "접근 제어 방식"처럼 의미로 찾으려면 벡터 검색이 나음
- 둘을 합치면 커버리지가 올라감
출처 표시
답변과 함께 근거 문서를 보여줘서 사용자가 직접 검증할 수 있게. "이 답변은 RBAC.md > 개념 섹션 기반입니다" 형태. 할루시네이션을 막진 못하지만 발견은 할 수 있게.
Confidence 기반 거절
검색 결과의 거리(distance)가 임계값보다 크면 "관련 내용을 찾지 못했습니다"로 답하게. LLM이 억지로 답하는 걸 방지.
if results["distances"][0][0] > 0.5:
return "관련 노트를 찾지 못했습니다."
Evaluation 파이프라인
답변 품질을 자동 측정하는 구조.
- 검색 정확도 — 검색된 청크가 실제로 질문과 관련있는가 (retrieval precision)
- 답변 충실도 — 답변이 컨텍스트에 있는 내용만 쓰는가 (faithfulness)
- 답변 완전성 — 컨텍스트에 있는 관련 내용을 빠뜨리지 않았는가 (recall)
RAGAS, TruLens 같은 프레임워크가 이걸 자동화해줌.
정리
RAG는 "LLM에 커닝페이퍼를 주는 것"이지만, 커닝페이퍼를 잘못 만들거나(청킹), 잘못 골라주거나(검색), LLM이 커닝페이퍼 밖의 내용을 답하는(할루시네이션) 문제가 있다. 이걸 인정하고 보완 전략을 쌓는 게 RAG 엔지니어링의 핵심이다.