Contextual Retrieval이란? RAG 검색 정확도를 높이는 방법

Updated 9월 9, 2026 1 min read

theinfoworld

한눈에 보기

Contextual Retrieval은 RAG 검색 과정에서 문서 조각이 원문 속 맥락을 잃는 문제를 해결하는 전처리 기법입니다. 문서에서 잘라낸 각 청크에 짧은 설명을 덧붙인 뒤 임베딩과 BM25 색인을 생성합니다.

핵심 구성은 다음 세 가지입니다.

Contextual Embeddings: 문맥이 보강된 청크를 임베딩하는 방식
Contextual BM25: 문맥이 보강된 청크를 키워드 검색 색인에 넣는 방식
Reranking: 1차 검색 결과를 관련성 기준으로 다시 정렬하는 단계

원문 실험에서는 Contextual Embeddings와 Contextual BM25를 함께 사용했을 때 상위 20개 청크 기준 검색 실패율이 49% 감소했고, Reranking까지 결합했을 때는 67% 감소했습니다.

1. Contextual Retrieval의 정의

1.1 Contextual Retrieval이란?

Contextual Retrieval은 대규모 지식베이스에서 정보를 검색할 때, 문서 청크마다 원문 전체를 기준으로 짧은 맥락 설명을 추가하는 방법입니다.

일반적인 RAG는 문서를 수백 토큰 단위의 작은 청크로 나눈 뒤 각각을 벡터 임베딩으로 변환합니다. 하지만 청크가 너무 작으면 문장만으로는 대상, 시점, 용어의 의미를 알기 어렵습니다. Contextual Retrieval은 이 청크에 문서 내 위치와 의미를 설명하는 문맥을 덧붙여 검색 가능성을 높입니다.

1.2 왜 필요한가?

다음과 같은 문장을 생각해 보겠습니다.

회사의 매출은 전 분기보다 3% 증가했습니다.

이 문장만 검색 색인에 들어가면 다음 정보가 빠져 있을 수 있습니다.

어느 회사의 매출인지
어느 분기의 실적인지
전 분기의 매출 규모가 얼마였는지
앞뒤 문장에서 정의된 용어가 무엇인지

질문이 “2023년 2분기 ACME의 매출 성장률은 얼마인가?”라면, 청크의 실제 내용은 관련성이 높아도 검색 시스템이 이를 정확히 찾아내기 어렵습니다. Contextual Retrieval은 “이 청크는 ACME의 2023년 2분기 실적을 다룬 문서에서 가져왔으며…”와 같은 설명을 덧붙여 문제를 완화합니다.

2. RAG와 Contextual Retrieval의 관계

2.1 RAG의 기본 흐름

RAG는 대규모 지식베이스의 정보를 검색한 뒤, 검색 결과를 생성형 AI의 프롬프트에 넣어 답변을 만드는 구조입니다.

일반적인 처리 과정은 다음과 같습니다.

문서 모음에서 텍스트를 추출합니다.
문서를 작은 청크로 분할합니다.
각 청크를 임베딩 모델로 변환합니다.
벡터 데이터베이스에 임베딩을 저장합니다.
사용자의 질문과 의미적으로 가까운 청크를 검색합니다.
검색 결과를 언어 모델의 입력에 추가합니다.
언어 모델이 최종 답변을 생성합니다.

2.2 기존 RAG의 한계

기존 RAG의 핵심 약점은 청크 분할 과정에서 맥락이 제거된다는 점입니다. 문서 전체에서는 의미가 분명했던 문장이 작은 청크 안에서는 모호해질 수 있습니다.

특히 다음 유형의 데이터에서 문제가 커집니다.

법률 문서와 판례
재무 보고서와 공시 자료
API 및 제품 기술 문서
코드베이스와 설계 문서
학술 논문
기업 내부 규정과 업무 매뉴얼

이런 문서는 앞부분에서 정의한 용어와 뒷부분의 결론이 멀리 떨어져 있는 경우가 많습니다.

3. Contextual Retrieval의 핵심 구성요소

3.1 Contextual Embeddings

Contextual Embeddings는 청크를 임베딩하기 전에 문서 전체를 참고해 짧은 맥락 설명을 덧붙이는 방식입니다.

기존 방식:

원본 청크 = 회사의 매출은 전 분기보다 3% 증가했습니다.

문맥 보강 방식:

문맥 = 이 청크는 ACME의 2023년 2분기 실적을 설명하는 SEC 공시에서 가져왔습니다. 전 분기 매출은 3억 1,400만 달러였습니다.
청크 = 회사의 매출은 전 분기보다 3% 증가했습니다.

이후 문맥과 청크를 결합한 텍스트를 임베딩합니다. 그러면 임베딩 모델이 문장 자체뿐 아니라 회사명, 기간, 문서 유형과 같은 검색 단서도 함께 반영할 수 있습니다.

3.2 Contextual BM25

BM25는 문서 안에 특정 단어나 구문이 실제로 등장하는지를 바탕으로 관련성을 계산하는 키워드 검색 방식입니다. 임베딩 검색이 의미적 유사성에 강하다면 BM25는 정확한 문자열 일치에 강합니다.

예를 들어 사용자가 “TS-999 오류 코드”를 검색할 때 임베딩 검색은 일반적인 오류 코드 문서를 찾을 수 있지만, 정확히 TS-999가 등장하는 문서를 놓칠 수도 있습니다. BM25는 이처럼 고유 식별자, 제품명, 버전 번호, 함수명, 계약 조항 번호를 찾는 데 유리합니다.

Contextual BM25는 문맥이 덧붙은 청크를 대상으로 BM25 색인을 구축합니다. 따라서 원래 청크에 없던 회사명이나 기간 같은 단어도 검색 단서로 활용할 수 있습니다.

3.3 Reranking

Reranking은 1차 검색 결과를 다시 평가해 최종적으로 모델에 전달할 청크를 선별하는 단계입니다.

일반적인 흐름은 다음과 같습니다.

임베딩과 BM25로 후보 청크를 넓게 검색합니다.
후보 청크와 사용자의 질문을 Reranking 모델에 전달합니다.
각 청크의 관련성 점수를 계산합니다.
점수가 높은 청크만 최종 프롬프트에 넣습니다.

검색 후보를 많이 확보하면 관련 문서를 놓칠 가능성은 줄어들지만, 모델에 불필요한 정보가 많이 들어갈 수 있습니다. Reranking은 이 사이에서 균형을 잡는 역할을 합니다.

4. Contextual Retrieval 처리 과정

4.1 전처리 단계

Contextual Retrieval은 주로 검색 시점이 아니라 색인을 만드는 전처리 단계에서 적용됩니다.

문서 원문
  ↓
청크 분할
  ↓
청크별 맥락 생성
  ↓
문맥 + 청크 결합
  ↓
Contextual Embeddings 생성
  ↓
Contextual BM25 색인 생성

4.2 검색 및 생성 단계

사용자 질문
  ↓
임베딩 검색 + BM25 검색
  ↓
후보 결과 통합 및 중복 제거
  ↓
Reranking
  ↓
상위 청크를 프롬프트에 추가
  ↓
AI 답변 생성

임베딩 검색과 BM25 검색 결과를 결합할 때는 순위 기반 결합 방법을 사용할 수 있습니다. 두 검색 방식에서 모두 높은 순위를 얻은 청크는 최종 후보로 선택될 가능성이 커집니다.

5. 청크별 맥락을 생성하는 방법

수천 개 또는 수백만 개의 청크에 사람이 직접 설명을 붙이는 것은 현실적으로 어렵습니다. 그래서 언어 모델을 사용해 문서 전체와 개별 청크를 함께 전달하고, 해당 청크를 설명하는 짧은 맥락을 자동 생성합니다.

맥락 생성 프롬프트의 기본 원칙은 다음과 같습니다.

문서 전체를 참고하게 합니다.
설명할 청크를 명확히 구분합니다.
검색에 도움이 되는 정보만 간결하게 쓰게 합니다.
최종 답변이 아니라 청크의 위치와 의미를 설명하게 합니다.
불필요한 서론이나 추측을 금지합니다.

생성된 맥락은 보통 50~100토큰 정도의 짧은 설명으로 구성합니다. 이 설명을 청크 앞에 붙인 뒤 임베딩을 만들고 BM25 색인에도 사용합니다.

6. Prompt Caching으로 비용 줄이기

청크마다 문서 전체를 반복해서 모델에 전달하면 전처리 비용이 커질 수 있습니다. Prompt Caching을 사용하면 문서 전체를 한 번 캐시에 올린 뒤 여러 청크 처리에서 재사용할 수 있습니다.

이 방식의 장점은 다음과 같습니다.

동일한 원문을 반복 전송하는 비용 감소
대규모 문서의 청크별 맥락 생성 속도 개선
문서 전체의 일관된 배경정보 유지
Contextual Retrieval 전처리의 운영 비용 절감

원문 실험에서는 800토큰 청크, 8,000토큰 문서, 50토큰 지시문, 청크당 100토큰 맥락을 가정했을 때 문서 토큰 100만 개당 일회성 맥락 생성 비용을 약 1.02달러로 계산했습니다. 실제 비용은 사용하는 모델, 토큰 수, 캐시 정책에 따라 달라질 수 있습니다.

7. 성능 개선 결과

원문 실험의 핵심 결과는 다음과 같습니다.

검색 구성	상위 20개 청크 기준 검색 실패율	개선 효과
기본 검색 기준	5.7%	기준
Contextual Embeddings	3.7%	35% 감소
Contextual Embeddings + Contextual BM25	2.9%	49% 감소
Contextual Retrieval + Reranking	1.9%	67% 감소

이 결과는 코드베이스, 소설, 연구 논문, 과학 논문 등 여러 지식 영역과 다양한 임베딩 설정을 대상으로 평가한 결과입니다. 다만 실제 서비스 성능은 데이터 품질, 청크 전략, 질문 유형, 임베딩 모델에 따라 달라질 수 있으므로 자체 평가가 필요합니다.

8. 구현 시 고려사항

8.1 청크 경계와 크기

청크 크기, 분할 위치, 청크 간 중첩 범위는 검색 성능에 직접적인 영향을 줍니다. 문장이나 표의 중간에서 잘라내면 맥락 생성 단계에서도 정보가 손실될 수 있습니다.

다음 원칙을 고려할 수 있습니다.

문장과 문단 경계를 우선합니다.
제목과 본문이 분리되지 않도록 합니다.
표, 코드, 목록은 구조를 보존합니다.
지나치게 작은 청크는 피합니다.
긴 문서에서는 청크 중첩을 실험합니다.

8.2 임베딩 모델 선택

Contextual Retrieval은 다양한 임베딩 모델에서 성능 개선을 보일 수 있지만, 모델별 효과의 크기는 다를 수 있습니다. 따라서 하나의 모델만 고정하기보다 실제 데이터셋에서 여러 모델을 비교하는 것이 좋습니다.

8.3 도메인 맞춤형 맥락 프롬프트

일반적인 맥락 생성 프롬프트로도 효과를 볼 수 있지만, 전문 분야에서는 도메인별 지침을 추가하면 더 나은 결과를 기대할 수 있습니다.

예를 들어 다음 정보를 프롬프트에 포함할 수 있습니다.

조직 내부 약어와 용어집
제품명과 버전 체계
법률 문서의 사건번호 형식
재무 데이터의 회계 기간 정의
코드베이스의 모듈 및 서비스 구조

8.4 검색 청크 수

최종 프롬프트에 넣는 청크 수가 많으면 관련 정보를 포함할 가능성이 커지지만, 불필요한 정보가 늘어나 모델의 판단을 방해할 수 있습니다. 원문 실험에서는 5개, 10개, 20개를 비교했을 때 20개 청크가 가장 좋은 성능을 보였지만, 이는 데이터와 모델에 따라 달라질 수 있습니다.

8.5 항상 평가하기

검색 정확도가 좋아졌다고 해서 최종 답변 품질도 자동으로 좋아지는 것은 아닙니다. 다음 항목을 별도로 평가해야 합니다.

관련 문서가 검색되는가
검색 결과의 순위가 적절한가
답변이 검색된 근거를 정확히 사용하는가
잘못된 문서가 함께 들어가 혼란을 주지 않는가
응답 지연과 비용이 허용 범위인가

9. Contextual Retrieval 도입 체크리스트

문서 유형별로 청크 전략을 정의했는가
청크에 문서명, 섹션, 시점 등 핵심 맥락을 추가했는가
임베딩 검색과 BM25 검색을 함께 테스트했는가
후보 검색과 최종 선별을 분리했는가
Reranking의 비용과 지연시간을 측정했는가
상위 5개, 10개, 20개 청크를 비교했는가
대표 질문 세트로 검색 실패율을 측정했는가
답변 생성 품질과 검색 품질을 따로 평가했는가
문서 변경 시 색인을 갱신하는 방법을 정했는가

10. Contextual Retrieval과 기존 방식 비교

방식	강점	한계	적합한 상황
벡터 검색	의미가 비슷한 내용을 잘 찾음	고유 코드나 정확한 문자열에 약할 수 있음	일반적인 자연어 질문
BM25	정확한 단어와 식별자 검색에 강함	표현이 달라지면 의미를 놓칠 수 있음	오류 코드, 제품명, 조항 번호
벡터 검색 + BM25	의미 검색과 키워드 검색을 결합	색인과 결과 통합이 필요함	대부분의 업무용 RAG
Contextual Retrieval	청크의 맥락 손실을 보완	전처리 단계와 비용이 추가됨	대규모 전문 지식베이스
Contextual Retrieval + Reranking	높은 검색 정확도와 정밀한 최종 선별	추가 지연시간과 비용 발생	정확도가 중요한 서비스

11. 자주 묻는 질문

Contextual Retrieval은 RAG를 대체하나요?

아닙니다. Contextual Retrieval은 RAG의 검색 단계를 개선하는 방법입니다. 문서 검색과 생성형 AI 답변 생성을 연결하는 RAG 구조 안에 적용할 수 있습니다.

모든 문서에 Contextual Retrieval이 필요한가요?

그렇지는 않습니다. 지식베이스가 작아서 전체 문서를 프롬프트에 넣을 수 있다면 단순히 긴 컨텍스트를 사용하는 편이 더 쉬울 수 있습니다. 문서가 커져 전체를 한 번에 넣기 어려울 때 Contextual Retrieval의 가치가 커집니다.

BM25만 사용해도 되나요?

가능하지만 의미가 다른 표현을 놓칠 수 있습니다. 정확한 키워드 검색과 의미 기반 검색을 함께 사용하면 서로의 약점을 보완할 수 있습니다.

Reranking은 반드시 추가해야 하나요?

서비스의 정확도 요구 수준과 비용에 따라 다릅니다. 검색 후보가 많고 관련성 차이가 큰 환경에서는 Reranking이 유용하지만, 응답 지연시간이 중요한 경우에는 후보 수와 모델 크기를 조정해야 합니다.

Contextual Retrieval의 가장 중요한 포인트는 무엇인가요?

문서 청크를 독립적인 문장으로 보지 않고, 원문 안에서 어떤 의미를 갖는지 설명하는 것입니다. 그 맥락을 임베딩과 키워드 색인에 함께 반영하면 검색 시스템이 더 풍부한 단서를 사용할 수 있습니다.

12. 결론

RAG의 검색 품질은 생성 모델의 성능만으로 결정되지 않습니다. 어떤 청크를 찾아서 프롬프트에 넣느냐가 답변의 정확도와 신뢰도에 큰 영향을 줍니다.

Contextual Retrieval은 문서 청크에 원문 기반 설명을 추가해 맥락 손실을 줄입니다. 여기에 Contextual Embeddings, Contextual BM25, Reranking을 결합하면 의미 기반 검색, 정확한 키워드 검색, 최종 관련성 선별을 하나의 파이프라인으로 구성할 수 있습니다.

실무에서는 다음 순서로 접근하는 것이 좋습니다.

현재 RAG의 검색 실패 사례를 수집합니다.
문서 유형에 맞는 청크 전략을 정합니다.
청크별 맥락을 자동 생성합니다.
임베딩 검색과 BM25 검색을 결합합니다.
Reranking과 상위 청크 수를 실험합니다.
검색 품질, 답변 품질, 비용, 지연시간을 함께 평가합니다.

결국 Contextual Retrieval의 핵심은 더 많은 정보를 무작정 넣는 것이 아니라, 검색 단위인 청크가 원문 속에서 무엇을 의미하는지 보존하는 데 있습니다.

※ 이 글은 Anthropic의 Contextual Retrieval 기술 소개 문서를 바탕으로 한국어 독자가 이해하기 쉽도록 재구성한 위키형 해설입니다.