RAG가 엉뚱한 답을 내놓는 건 모델 탓이 아닙니다. 디버깅 체크리스트를 확인하세요.
Your RAG isn't giving wrong answers because of the model. Here's a debug checklist.
핵심 요약
RAG 시스템의 환각 현상은 모델보다 검색 과정의 문제일 확률이 높으므로 4가지 핵심 요소를 먼저 점검해야 합니다.
- 청킹 전략 — 고정 길이 청킹 대신 의미 단위나 문단 기반 청킹을 사용하여 정보 손실을 방지함.
- 메타데이터 필터링 — 검색 시 날짜, 부서, 버전 등 메타데이터를 활용해 관련성 높은 문서만 필터링함.
- 유사도 임계값 — 검색된 청크의 유사도가 낮을 경우 답변을 생성하지 않도록 최소 임계값을 설정함.
- 쿼리-문서 불일치 — 질문과 문서 간의 표현 차이를 극복하기 위해 HyDE나 리랭커를 도입하여 검색 정확도를 높임.
매주 누군가 "제 RAG가 계속 환각을 일으키는데, 모델을 바꿔야 할까요?"라는 글을 올립니다. 열에 아홉은 모델이 문제가 아닙니다. 검색(Retrieval)이 문제죠.
RAG 시스템에서 잘못된 답변은 거의 항상 다음 네 가지 중 하나에서 비롯됩니다. LLM을 건드리기 전에 이 항목들을 먼저 확인하세요:
- Chunking strategy
글자 수, 문장, 문단, 혹은 의미 단위 중 어떤 기준으로 청킹하고 계신가요? 고정 글자 수 청킹은 설정하기는 가장 빠르지만, 핵심 사실을 두 청크로 쪼개버릴 가능성이 가장 높습니다. 그러면 검색기는 답변의 절반만 찾아내고, 모델은 나머지를 지어내서 아주 자신 있게 헛소리를 하게 됩니다. 의미 단위나 문단 기반 청킹을 시도하고, 적용 전후의 검색 정밀도를 측정해보세요. 저희 경험상 이 변경 하나만으로 잘못된 답변에 대한 불만의 40~50%가 해결됩니다.
- Metadata and filtering
지식 베이스에 여러 날짜, 부서, 제품 버전의 문서가 섞여 있다면, 검색 전에 필터링을 하고 계신가요? 필터링이 없으면 검색기는 2024년 가격에 대한 질문에 답하기 위해 2021년 정책 문서를 가져올 수도 있습니다. 모든 청크에 출처, 날짜, 카테고리 메타데이터를 추가하고 쿼리 시점에 필터링하세요.
- Retrieval score threshold
대부분의 설정은 실제 관련성과 상관없이 상위 k개의 청크를 가져옵니다. 가장 유사한 청크의 코사인 유사도가 0.52라면, 그 안에는 답이 없을 확률이 높습니다. 하지만 어쨌든 모델에게 전달되고, 모델은 그럴듯하게 내용을 지어냅니다. 최소 유사도 임계값을 추가하세요. 자신 있게 틀린 답을 내놓는 것보다 "정보가 충분하지 않습니다"라고 말하는 편이 훨씬 낫습니다.
- Query-document mismatch
문서는 서술형으로 작성되어 있고, 쿼리는 질문형으로 작성되어 있습니다. 임베딩 공간은 이를 다르게 처리합니다. HyDE(가상의 답변을 생성하고, 그것을 임베딩하여 검색에 활용)를 시도하거나 초기 검색 후 리랭커(reranker)를 사용해보세요. 둘 다 적은 노력으로 큰 효과를 볼 수 있는 해결책입니다.
파인튜닝이나 모델 교체를 고려하기 전에 이 네 가지를 먼저 해결하세요. 모델이 병목 현상의 원인인 경우는 거의 없습니다.
여러분은 프로덕션 RAG에서 어떤 검색 실패 유형을 가장 자주 보시나요?
