RAG 파이프라인 설계: 검색으로 환각 줄이기

사내 문서를 학습시킨 챗봇을 만들고 싶다는 요구는 흔합니다. 그런데 실제로 필요한 것은 학습이 아닌 경우가 대부분입니다. 파인튜닝은 비싸고 느리며, 문서가 바뀔 때마다 다시 해야 하고, 정확한 인용을 보장하지도 않습니다.

대안이 검색 증강 생성(RAG, Retrieval-Augmented Generation) 입니다. 질문이 들어오면 관련 문서를 먼저 찾아 프롬프트에 넣고, 모델에게 그 자료를 근거로만 답하게 하는 구조입니다. 모델은 기억을 더듬는 대신 주어진 텍스트를 읽고 정리하면 됩니다.

이 글에서는 RAG의 전체 단계를 따라가며 각 단계에서 무엇을 결정해야 하는지, 어디서 품질이 무너지는지, 그리고 RAG로 해결되지 않는 문제가 무엇인지 정리합니다.

전체 흐름

RAG는 두 시점으로 나뉩니다. 문서를 미리 준비하는 색인 단계와 질문이 들어왔을 때 동작하는 질의 단계입니다.

1. 문서를 어떻게 자를 것인가

가장 많은 문제가 여기서 생깁니다. 문서를 통째로 벡터 하나로 만들면 여러 주제가 평균되어 뭉개집니다(임베딩과 벡터 검색 참고). 그래서 적당한 크기로 잘라야 합니다.

너무 작으면 맥락이 끊깁니다. "이 경우에는 적용되지 않습니다"라는 문장만 검색되면 무엇이 적용되지 않는지 알 수 없습니다. 너무 크면 관련 없는 내용이 섞여 검색 정확도가 떨어지고 토큰도 낭비됩니다.

실무에서 쓸 만한 기준은 다음과 같습니다.

• 구조를 따라 자릅니다. 문자 수로 기계적으로 자르기보다 소제목, 문단, 조항 단위로 나누는 편이 훨씬 낫습니다. 마크다운 제목이나 HTML 구조가 있다면 활용하세요.
• 앞뒤를 조금 겹칩니다. 경계에서 문맥이 끊기는 것을 완화합니다. 청크 길이의 10~20% 정도가 흔한 선택입니다.
• 문맥 헤더를 붙입니다. 각 청크 앞에 "문서 제목 > 상위 섹션"을 넣으면 검색 정확도와 답변 품질이 함께 올라갑니다.
• 표는 따로 다룹니다. 표를 중간에서 자르면 의미가 사라집니다. 표 전체를 하나의 청크로 두고 앞에 설명을 붙이세요.

2. 검색을 벡터에만 맡기지 마세요

벡터 검색은 표현이 달라도 의미가 비슷하면 찾아냅니다. 하지만 약점이 분명합니다. 제품 코드, 오류 번호, 드문 고유명사처럼 정확히 일치해야 하는 값에 취약합니다.

그래서 실무에서는 하이브리드 검색이 기본에 가깝습니다. 키워드 검색(BM25 등)과 벡터 검색을 각각 수행한 뒤 결과를 합칩니다. 합치는 방법으로는 각 결과의 순위를 이용하는 RRF(Reciprocal Rank Fusion) 같은 단순한 방식이 널리 쓰이고, 대부분의 경우 충분히 잘 동작합니다.

메타데이터 필터링도 함께 설계해야 합니다. 부서, 문서 종류, 작성일, 공개 범위 같은 속성으로 먼저 범위를 좁히면 정확도와 속도가 모두 좋아집니다. 특히 권한 처리는 필수입니다. 사용자가 볼 수 없는 문서가 검색 결과에 섞이면 그 내용이 답변에 그대로 노출됩니다.

3. 재순위로 상위 결과를 다듬습니다

검색이 가져온 상위 결과가 항상 가장 적절하지는 않습니다. 임베딩은 질문과 문서를 각각 따로 벡터로 만들어 비교하기 때문에, 둘을 함께 보고 판단하는 정밀도에는 한계가 있습니다.

재순위(reranking) 는 검색으로 후보를 넉넉히(예: 30개) 가져온 뒤, 질문과 각 후보를 함께 입력받는 모델로 관련도를 다시 매겨 상위 몇 개만 남기는 단계입니다. 계산량이 많아 전체 문서에는 쓸 수 없지만 후보 수십 개에는 쓸 수 있습니다.

비용과 지연이 늘지만 답변 품질 개선 효과가 큰 편이라, 검색 정확도가 문제라면 우선 검토할 만한 단계입니다.

4. 근거를 프롬프트에 조립합니다

검색 결과를 모델에 넘길 때의 구성이 답변 품질을 좌우합니다.

아래 [자료]에 근거해서만 답하세요.

규칙:
- 자료에 없는 내용은 추측하지 말고 "자료에서 확인할 수 없습니다"라고 답하세요.
- 각 문장 끝에 근거 자료 번호를 [1] 형식으로 표시하세요.
- 자료끼리 내용이 다르면 그 사실을 함께 알려 주세요.

[자료]
[1] (문서 제목 > 섹션)
본문 ...

[2] (문서 제목 > 섹션)
본문 ...

[질문]
{{질문}}

중요한 점 세 가지입니다.

"자료에 없으면 없다고 답하라"를 반드시 넣으세요. 이것이 없으면 모델이 자기 파라미터의 지식으로 빈칸을 채웁니다. 환각에서 다룬 문맥 이탈이 여기서 발생합니다.

출처 번호를 요구하세요. 사용자가 검증할 수 있고, 근거 없는 문장을 찾아내기도 쉬워집니다.

질문을 자료 뒤에 두세요. 긴 입력에서는 가운데 내용이 묻히는 경향이 있으므로(컨텍스트 윈도우 참고), 지시와 질문을 끝에 다시 놓는 구성이 안정적입니다.

5. 평가 없이는 개선할 수 없습니다

RAG는 단계가 많아 어디서 틀렸는지 파악하기 어렵습니다. 검색이 잘못된 것인지, 근거는 맞는데 모델이 잘못 읽은 것인지 구분해야 대응할 수 있습니다.

검색 품질과 생성 품질을 따로 측정하세요.

평가셋은 실제 질문 30~50건과 정답, 그리고 정답이 있는 문서 위치로 구성합니다. 마지막 항목이 있어야 검색 단계를 따로 채점할 수 있습니다.

답할 수 없는 질문을 반드시 포함하세요. 자료에 없는 것을 물었을 때 모델이 지어내는지 확인하는 것이 가장 중요한 테스트 중 하나입니다.

RAG로 해결되지 않는 것

RAG가 만능은 아닙니다. 다음 상황에서는 다른 접근이 필요합니다.

전수 집계형 질문. "전체 계약서 중 위약금 조항이 있는 것이 몇 건인가" 같은 질문은 상위 몇 개를 검색해서는 답할 수 없습니다. 메타데이터를 미리 추출해 데이터베이스에 넣고 쿼리로 처리하는 편이 맞습니다.

여러 문서를 종합해야 하는 추론. "A 정책과 B 정책이 충돌하는 지점은?"처럼 여러 문서를 함께 놓고 비교해야 하는 질문은 단순 검색으로 약합니다. 질문을 나눠 여러 번 검색하는 구조가 필요합니다.

시간 흐름에 따른 질문. "이 규정이 언제 어떻게 바뀌었나"는 버전 관리가 색인에 반영되어 있어야 답할 수 있습니다.

문서 자체가 부실할 때. RAG는 없는 정보를 만들어 내지 못합니다. 문서가 오래되었거나 서로 모순되면 답변도 그렇게 나옵니다. 문서 정리가 선행되어야 합니다.

단순한 것부터 시작하세요

처음부터 재순위, 쿼리 재작성, 다단계 검색을 모두 넣을 필요는 없습니다. 다음 순서를 권합니다.

1. 문서가 적다면 RAG 없이 통째로 넣어 보세요. 그것으로 충분한 경우가 생각보다 많습니다.
2. 기본 구성으로 시작합니다. 구조 기반 청킹 + 하이브리드 검색 + 출처 표기.
3. 평가셋을 만들어 현재 수준을 측정합니다.
4. 검색 재현율이 낮으면 청킹과 검색을, 근거 충실도가 낮으면 프롬프트를 손봅니다.
5. 그래도 부족하면 재순위를 추가합니다.

정리

• RAG는 질문과 관련된 문서를 찾아 근거로 제공해, 모델이 기억 대신 자료를 읽고 답하게 하는 구조입니다.
• 청킹은 문자 수가 아니라 문서 구조를 따라 나누고, 앞뒤를 겹치며, 문맥 헤더를 붙입니다.
• 벡터 검색만으로는 코드·고유명사에 약하므로 키워드 검색과 함께 쓰는 하이브리드가 안전합니다.
• 프롬프트에 "자료에 없으면 없다고 답하라" 와 출처 표기 요구를 반드시 넣습니다.
• 검색 품질과 생성 품질을 따로 측정해야 어느 단계를 고칠지 알 수 있습니다.
• 전수 집계, 다문서 종합, 부실한 원본 문서는 RAG로 해결되지 않습니다.

참고 자료

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — RAG 원 논문
• Anthropic — 컨텍스트 검색 기법 — 청크에 문맥을 붙이는 방법
• Lost in the Middle — 긴 입력에서 정보 위치의 영향