RAG 검색 품질이 흔들릴 때 가장 흔한 착각은 벡터DB만 바꾸면 해결될 것이라고 보는 것입니다. 실제로는 문서를 어떻게 나눴는지, 후보를 어떤 순서로 골랐는지, 최종 context에 무엇을 넣었는지가 함께 영향을 줍니다.
핵심은 RAG 품질을 retrieval 한 단계가 아니라 근거가 모델에 들어가기까지의 파이프라인으로 보는 것입니다. 이 글은 chunking, reranking, context packing을 한 흐름으로 묶어 설명합니다.
RAG 검색 품질은 왜 기대보다 흔들릴까
RAG는 문서를 검색해서 LLM 답변에 근거로 넣는 구조입니다. 말로는 단순하지만 실제 품질은 여러 단계의 작은 실패가 합쳐져 결정됩니다. 문서를 잘못 나누면 근거가 깨지고, 검색 후보가 틀리면 좋은 문서가 빠지고, context를 잘못 담으면 모델이 엉뚱한 부분을 더 강하게 봅니다.
그래서 RAG를 디버깅할 때는 답변만 보지 말고 질문에서 최종 context까지의 중간 산출물을 봐야 합니다.
1단계: chunking은 근거를 깨지 않게 나누는 일
chunking은 긴 문서를 작은 단위로 나누는 작업입니다. 너무 크게 자르면 검색 결과 하나가 많은 잡음을 담고, 너무 작게 자르면 답변에 필요한 문맥이 잘려 나갑니다.
- FAQ처럼 짧은 문서는 질문/답변 단위가 자연스럽다
- 기술 문서는 제목, 절, 코드 블록 경계를 보존하는 편이 좋다
- 표와 목록은 행 단위로 찢으면 의미가 사라질 수 있다
- 한국어 문서는 조사와 생략이 많아 앞뒤 문맥이 더 중요할 수 있다
나쁜 chunk 예:
... AccessDeniedHandler는 접근 거부 상황을 처리한다.
다음 chunk:
단, 인증되지 않은 요청은 AuthenticationEntryPoint가 처리한다.
문제:
두 문장이 함께 있어야 401/403 차이를 설명할 수 있는데
검색 결과에는 한쪽만 들어올 수 있다.2단계: 검색 후보는 recall을 먼저 본다
검색 후보 단계에서는 정답 문서가 top-k 안에 들어오는지가 중요합니다. 후보 안에 답이 없으면 reranker나 prompt를 아무리 바꿔도 답변은 흔들립니다.
이 단계에서는 사용자의 실제 질문을 평가셋으로 모아야 합니다. 좋아 보이는 샘플 질문이 아니라 실제로 검색이 실패했던 질문을 넣어야 합니다.
3단계: reranking은 후보의 순서를 다시 본다
벡터 검색은 의미적으로 가까운 후보를 빠르게 가져오는 데 강합니다. 하지만 질문에 직접 답하는 문서를 항상 맨 앞으로 올리지는 못합니다. reranking은 이 후보들을 질문 기준으로 다시 정렬하는 단계입니다.
질문: 401과 403은 어디서 갈라질까?
vector search 후보:
1. Spring Security 전체 구조
2. JWT 토큰 생성 방법
3. AuthenticationEntryPoint와 AccessDeniedHandler
reranking 후:
1. AuthenticationEntryPoint와 AccessDeniedHandler
2. Spring Security 전체 구조
3. JWT 토큰 생성 방법reranker는 후보 안에 답이 있을 때 강합니다. 다만 비용과 지연시간이 늘 수 있으므로 모든 요청에 무조건 붙이기보다 실패 비용이 큰 검색에 우선 적용하는 편이 현실적입니다.
4단계: context packing은 근거 배치 문제
검색 결과를 그대로 모델에 넣으면 context가 길어지고 중복이 늘어납니다. context packing은 제한된 토큰 안에 어떤 근거를 어떤 순서로 넣을지 정하는 작업입니다.
- 같은 내용을 반복하는 chunk는 줄인다
- 질문에 직접 답하는 근거를 앞쪽에 둔다
- 출처와 날짜가 필요한 문서는 메타데이터를 함께 넣는다
- 서로 충돌하는 근거가 있으면 하나만 숨기지 말고 충돌을 표시한다
답변이 틀렸을 때 보는 순서
- 정답 근거가 원문 문서에 있는지 확인한다
- 그 문서가 index에 들어갔는지 확인한다
- 정답 chunk가 top-k 후보 안에 들어오는지 확인한다
- 후보 안에 있는데 순서가 밀리면 reranking을 본다
- 후보가 좋은데 답변이 틀리면 context packing과 prompt를 본다
- 출처가 충돌하면 답변 생성이 아니라 데이터 정책 문제로 분리한다
작은 RAG에도 평가셋이 필요한 이유
RAG는 감으로 고치기 쉽습니다. chunk size를 바꾸고, top-k를 바꾸고, prompt를 바꾸다 보면 좋아진 것처럼 보이지만 다른 질문에서 다시 깨질 수 있습니다.
그래서 최소한의 평가셋이 필요합니다. 질문, 기대 근거, 기대 답변 범위, 실패 유형을 표로 관리하면 변경 전후를 비교할 수 있습니다.
question: Spring Security에서 401과 403은 어떻게 다를까?
expected_evidence:
- AuthenticationEntryPoint 설명 문서
- AccessDeniedHandler 설명 문서
acceptable_answer:
- 401은 인증 실패
- 403은 권한 부족
failure_type:
- wrong evidence
- missing evidence
- unsupported answer정리
RAG 검색 품질은 벡터DB 하나로 결정되지 않습니다. chunking이 근거를 보존하고, 검색이 후보를 놓치지 않고, reranking이 질문에 맞게 순서를 조정하고, context packing이 모델에 필요한 근거만 잘 전달해야 합니다.
RAG 운영 흐름은 RAG hallucination 평가 시작법, LangGraph state와 checkpoint, Embedding이란 무엇인가와 함께 보면 좋습니다. 외부 기준은 LlamaIndex Docs – Node Parsers, Pinecone Docs – Rerank results, OpenAI Docs – Retrieval를 확인했습니다.
