본문
RAG 성능의 핵심: 방대한 문서, 어떻게 쪼개고 검색해야 할까?
RAG 시스템을 직접 구축하면서 가장 크게 부딪혔던 난관 중 하나는 바로 '데이터 쪼개기'였습니다. 처음에는 "그냥 문서를 500자씩 자르거나 문단 단위로 뭉텅뭉텅 넣으면 되는 거 아냐?"라고 가볍게 생각했습니다.
하지만 실제 업무에서 마주하는 복잡하고 방대한 문서를 다뤄보니, 단순히 글자 수나 길이를 기준으로 쪼개는 방식은 핵심 문맥이 엉뚱한 곳에서 잘려나가는 '문맥 파편화(Context Fragmentation)'라는 문제를 일으키더라구요.
디버깅을 하며 깨달은 점은, 데이터가 커질수록 RAG는 '어떻게 쪼갤 것인가(Indexing)'와 '어떻게 찾아올 것인가(Retrieval)'를 철저히 분리해서 설계해야 한다는 것이었습니다.
오늘은 RAG 시스템을 고도화하며 겪은 시행착오를 바탕으로, 4가지 핵심 전략을 간단히 정리해 봅니다.
1. 의미 중심의 '시맨틱 청킹(Semantic Chunking)'
글자 수로 자르는 대신, 문장의 '의미적 경계'를 활용하세요.
- 원리: 문장 간의 임베딩 거리를 계산하여, 의미가 급격히 바뀌는 지점(예: 서론에서 본론으로 넘어갈 때)에서 청크를 나눕니다.
- 효과: 청크 하나하나가 독립적인 의미를 갖게 되어, 검색 시 모호함이 사라집니다.
2. 정밀도와 맥락의 균형: 'Parent-Child Retrieval' (Small-to-Big)
검색은 날카롭게, 답변은 풍부하게 하고 싶다면 이 전략이 정답입니다.
- Child (검색용): 원본을 잘게 쪼갠 작은 조각입니다. 임베딩하여 벡터 DB에 저장합니다.
- Parent (맥락용): 쪼개기 전의 큰 문단이나 섹션입니다.
- 흐름: 질문으로 Child를 검색하고, 실제 LLM에게는 그와 연결된 Parent를 통째로 전달합니다. 검색은 정밀하게, 답변을 위한 맥락은 충분하게 제공할 수 있습니다.
3. 문맥 주입(Contextual Retrieval): 청크에 '족보'를 붙여라
큰 문서에서 문단 하나만 떼어내면, 그 문단이 무엇에 대한 내용인지 알기 어렵습니다.
- 전략: 청크를 생성할 때 해당 청크의 상위 제목, 문서명, 요약 정보를 앞부분에 강제로 삽입하세요.
- 효과: "삼성전자 2026 1분기 보고서 > 반도체 부문 > [본문: 10% 증가]"와 같이 맥락이 문장 자체에 녹아들어 검색 정확도가 비약적으로 상승합니다.
4. 검색의 마침표: '리랭킹(Reranking)'
벡터 검색으로 뽑아온 문서가 항상 정답은 아닙니다. 검색 직후, 리랭커(Reranker) 모델을 통과시키세요.
- 원리 (LLM이 직접 채점할까?): 결론부터 말씀드리면, 답변을 만들어내는 무거운 LLM(GPT, Claude 등)이 직접 문서를 채점하는 것이 아닙니다. 대신 '문서와 질문의 연관성 평가'에만 특화된 별도의 가벼운 AI 알고리즘(주로 Cross-Encoder 모델)을 사용합니다.
1차 벡터 검색이 질문과 문서를 각각 따로 임베딩해 '좌표상의 거리'만 빠르게 계산한다면, 리랭커 모델은 질문과 문서를 한 세트로 묶어 동시에 깊이 읽어냅니다. 무거운 LLM에게 검색된 수십 개의 문서를 다 읽게 하면 비용과 속도 문제가 발생하므로, 문맥을 꼼꼼히 따져 진짜 정답만 골라내는 '전문 평가관' 알고리즘을 중간에 두는 원리입니다. - 효과: 벡터 검색의 단순한 '의미적 유사도'에만 의존하지 않고, 진짜 정답인 데이터만 1~2개로 압축해 최종 LLM에게 전달함으로써 할루시네이션을 막고 API 토큰 비용도 크게 절약할 수 있습니다.
마치며: 완성도 높은 RAG를 위한 파이프라인
정리하자면, 대용량 문서를 다루는 고도화된 RAG 파이프라인의 표준은 다음과 같습니다.
- Indexing: 글자 수가 아닌 의미 단위로 문서를 쪼개고(Semantic Chunking), 문맥을 담은 메타데이터를 덧붙여(Contextual Retrieval) 작은 단위(Child)로 임베딩한다.
- Retrieval: 하이브리드 서치로 후보를 뽑고, Reranker를 거쳐 상위 정답만 필터링한다.
- Generation: 필터링된 원본 데이터(Parent)를 LLM에 전달하여 정확한 답변을 생성한다.
단순히 문단을 나누는 것을 넘어, 데이터의 맥락을 살리고 검색 후 검증(Reranking)하는 과정을 추가하는 것만으로도 RAG 서비스의 성능은 이전과 확연히 달라질 것 같습니다 :)
댓글