RAG에서 컨텍스트와 컨텍스트 기반 검색 이해

Source: Towards Data Science

Hybrid Search + RAG: 왜 중요한가

최근 글 RAG with Hybrid Search – How Does Keyword Search Work? 에서 키워드‑검색 요소(예: BM25)를 Retrieval‑Augmented Generation (RAG) 파이프라인에 추가하면 효과가 크게 향상된다는 점을 설명했습니다.

• 시맨틱 검색만 사용 – 임베딩을 활용해 우리 문서에서 AI‑기반 인사이트를 끌어낼 수 있습니다.
• 문제점 – 방대한 지식 베이스에서는 순수 시맨틱 검색만으로는 원본에 존재하는 정확한 구문 매치를 놓칠 수 있습니다.
• 하이브리드 검색 – 시맨틱 임베딩과 키워드 매칭을 결합해 보다 포괄적인 결과를 제공하고, RAG 시스템의 성능을 눈에 띄게 끌어올립니다.

Chunk‑Based Retrieval에서의 Context‑Loss 문제

하이브리드 검색을 사용하더라도, RAG는 여전히 문서 전체에 흩어져 있는 중요한 정보를 놓칠 수 있습니다. 이는 다음과 같은 이유 때문입니다:

1. Chunking removes surrounding text – 문서를 작은 조각으로 나누면 각 청크에 의미를 부여하는 주변 문맥이 사라질 수 있습니다.
2. Complex, inter‑connected content suffers – 표, 그림, 혹은 여러 섹션에 걸친 개념(예: “표에 표시된 대로, 이익이 6% 증가했습니다”)에 대한 참조가 주변 문맥이 제거되면 모호해집니다.
3. Resulting retrieval errors – 관련 없는 청크가 검색되어 모델의 응답이 주제와 맞지 않거나 부정확해질 수 있습니다.

일반적인 (하지만 불충분한) 해결책

이러한 기술들이 도움이 되지만, 근본 원인을 완전히 해결하지는 못합니다: 개별 청크를 연결하는 더 넓은 서사의 손실.

실제 솔루션: 컨텍스추얼 리트리벌

컨텍스추얼 리트리벌 – 2024년 Anthropic이 도입 – 각 청크를 검색할 때 주변 컨텍스트를 보존하여 RAG 정확도를 크게 향상시킵니다.
원본 논문 읽기: Anthropic – Contextual Retrieval (2024)

작동 방식

1. 청크‑단위 컨텍스트 윈도우 – 청크가 검색될 때 시스템은 설정 가능한 양만큼 앞뒤 텍스트도 함께 가져옵니다.
2. 동적 컨텍스트 스티칭 – 겹치는 윈도우를 실시간으로 병합해, 검색된 구절 주변의 원래 서술을 재구성합니다.
3. 선택적 확장 – 가장 관련성이 높은 컨텍스트만 추가하여 토큰 사용을 효율적으로 유지하면서도 모델에 필요한 배경 정보를 제공합니다.

장점

• 높은 관련성 – 모델이 전체 이야기를 파악하게 되어 환각 및 주제 벗어난 답변을 줄입니다.
• 전체 문서 검색보다 낮은 지연 시간 – 필요한 컨텍스트만 추가하므로 전체 문서를 모두 가져올 필요가 없습니다.
• 하이브리드 검색과 호환 – 의미 임베딩과 키워드 기반 BM25 점수 모두와 원활하게 작동합니다.

TL;DR

• Hybrid search (semantic + keyword) already improves RAG, but chunking still discards essential context. → Hybrid search(시맨틱 + 키워드)는 이미 RAG를 개선하지만, 청킹은 여전히 중요한 컨텍스트를 놓친다.
• Traditional fixes (larger chunks, overlap, HyDE, summary indexes) only provide marginal gains. → 전통적인 해결책(더 큰 청크, 오버랩, HyDE, 요약 인덱스)은 미미한 개선만 제공한다.
• Contextual retrieval restores surrounding text at query time, giving the LLM the full picture it needs for accurate, grounded responses. → Contextual retrieval는 질의 시점에 주변 텍스트를 복원하여 LLM이 정확하고 근거 있는 응답을 위해 필요한 전체 그림을 제공한다.

Implementing contextual retrieval is currently the most effective way to overcome the context‑loss problem and unlock the full potential of RAG pipelines. → Contextual retrieval를 구현하는 것이 현재 컨텍스트 손실 문제를 극복하고 RAG 파이프라인의 전체 잠재력을 발휘하는 가장 효과적인 방법이다.

Source: …

컨텍스트란 무엇인가?

컨텍스트 기반 검색에 들어가기 전에, 대형 언어 모델(LLM)에게 컨텍스트가 실제로 무엇을 의미하는지 명확히 해보자.

우리는 모두 “컨텍스트 윈도우”에 대해 들어봤지만, 그 용어가 정확히 무엇을 가리키는 걸까?

정의

컨텍스트 = 다음 토큰을 예측할 때 LLM이 사용할 수 있는 모든 토큰
실제로는 다음이 포함된다:

• 사용자 프롬프트
• 시스템 프롬프트
• 모델 출력에 영향을 주는 지시사항, 스킬, 기타 가이드라인
• 이미 생성된 모델 자체의 응답 부분(각 새로운 토큰은 이전에 나온 모든 것을 기반으로 생성됨)

LLM은 토큰을 하나씩 생성하기 때문에, 대화 전체 히스토리가 컨텍스트의 일부가 된다.

왜 컨텍스트가 중요한가

컨텍스트가 조금만 바뀌어도 매우 다른 완성 결과가 나올 수 있다:

컨텍스트‑윈도우 제한

컨텍스트 윈도우는 LLM이 한 번의 요청에서 고려할 수 있는 최대 토큰 수이다.

• 초기 모델: 8 k 토큰 정도
• 최신 최첨단 모델: 수십만 토큰

예를 들어, Claude Opus 4.6(200 k‑토큰 윈도우)은 한 번에 대략 500–600 페이지 분량의 텍스트를 처리할 수 있다. 필요한 모든 정보가 이 한도 안에 들어간다면, 모델에 그대로 전달하고 강력한 답변을 기대하면 된다.

지식 베이스가 윈도우보다 클 때

대부분의 실제 사용 사례는 지식 베이스가 어느 컨텍스트 윈도우보다 훨씬 큰 경우다(예: 법률 라이브러리, 장비 매뉴얼). 모든 정보를 모델에 전달할 수 없으므로, 가장 관련성 높은 정보를 선택해야 한다. 이 선택 과정이 **Retrieval‑Augmented Generation (RAG)**의 핵심이며, 흔히 컨텍스트 엔지니어링이라고도 부른다:

제한된 컨텍스트 윈도우 안에 넣을 최적의 정보 하위 집합을 식별하여 모델이 가능한 최고의 응답을 생성하도록 하는 과정.
— LangChain Context Engineering docs

RAG에서의 Retrieval 단계

RAG 시스템에서 가장 중요한 부분은 올바른 정보를 찾아 LLM에 전달하는 것이다. 검색은 다음과 같이 수행될 수 있다:

• 시맨틱 검색 – 의미가 비슷한 청크를 찾음
• 키워드 검색 – 정확히 일치하는 용어를 찾음

두 방법을 모두 결합하더라도, 일부 중요한 정보가 누락될 수 있다.

어떤 정보가 놓칠 수 있을까?

다른 도메인을 가진 두 문서가 동일한 문구를 포함하고 있다고 가정해 보자:

“혼합물을 천천히 가열한다.”

• 레시피 책에서는 요리를 의미한다.
• 화학 공정 매뉴얼에서는 산업 공정을 의미한다.

시맨틱 의미(가열 행위)는 동일하지만, 컨텍스트(요리 vs. 화학 공학)는 다르다. 주변 컨텍스트를 보존하는 것이 정확한 검색을 위해 필수적이다.

컨텍스트 기반 검색

컨텍스트 기반 검색은 각 텍스트 청크의 주변 의미를 유지하도록 하여, 모델이 관련 문장뿐 아니라 그 문장을 구분해 주는 도메인‑특화 컨텍스트도 함께 받도록 한다.

Source: https://example.com/contextual-retrieval

컨텍스추얼 리트리벌은?

컨텍스추얼 리트리벌은 Retrieval‑Augmented Generation (RAG)에서 각 청크의 컨텍스트를 보존하기 위해 사용되는 방법론입니다. 청크가 검색되어 LLM에 전달될 때, 원래 의미—즉 의미론, 키워드, 주변 컨텍스트—를 최대한 유지하고자 합니다.

작동 방식

1. 각 청크마다 보조 텍스트(컨텍스추얼 텍스트)를 생성 – 청크가 속한 원본 문서 내에서의 위치를 설명합니다.
2. LLM에 프롬프트를 제공하여 전체 문서와 해당 청크를 함께 제시하고, 이 컨텍스추얼 텍스트를 생성하도록 합니다.
3. 생성된 컨텍스추얼 텍스트와 원본 청크를 결합하고, 이 쌍을 인덱싱 및 검색을 위한 불가분의 단위로 취급합니다.

프롬프트 예시

아래는 이탈리안 요리책의 청크에 대한 컨텍스추얼 텍스트를 얻기 위해 LLM에 보낼 수 있는 프롬프트 예시입니다:

[청크가 포함된 전체 이탈리안 요리책 문서]

전체 문서의 컨텍스트 안에 배치하고 싶은 청크는 다음과 같습니다.

[실제 청크]

전체 문서 내에서 이 청크가 어떤 위치에 있는지 간략히 설명해 주세요. 검색 정확도 향상을 위해 컨텍스트만 제공하고 그 외는 답변하지 말아 주세요.

기대되는 LLM 응답

LLM은 짧은 컨텍스추얼 설명을 반환하고, 이를 청크 앞에 붙입니다:

Context: 레시피 단계 – 집에서 만든 토마토 파스타 소스를 끓이는 과정.
Chunk:   혼합물을 천천히 가열하고 가끔 저어가며 눌어붙지 않게 합니다.

이제 검색 시스템은 “혼합물”이 토마토 소스를 의미한다는 것을 정확히 파악하여, 실험실에서 만든 전분 용액과 같은 혼동을 없앨 수 있습니다.

인덱싱

이 시점부터 컨텍스트 + 청크 쌍을 하나의 단위로 취급합니다:

• 임베딩은 결합된 텍스트 전체에 대해 생성되어 벡터 스토어에 저장됩니다.
• BM25(또는 다른 레키컬 인덱스)도 동일한 결합 텍스트를 기반으로 구축됩니다.

따라서 조밀(dense) 인덱스와 희소(sparse) 인덱스 모두 컨텍스추얼 정보를 포함하게 되며, 검색 관련성이 크게 향상됩니다.

효과

Anthropic에 따르면, 컨텍스추얼 리트리벌은 검색 정확도를 약 35 % 향상시킬 수 있다고 합니다【¹】.

프롬프트 캐싱으로 비용 절감

“하지만 이거 비용이 많이 들지 않을까?” 라는 질문을 들을 수 있습니다. 놀랍게도, 그렇지 않습니다.

직관적으로 보면, 이 설정이 RAG 파이프라인의 인제스트 비용을 크게 증가시킬 것처럼 보입니다—사실상 두 배 이상이 될 수도 있겠죠. 결국 우리는 LLM에 추가 호출을 많이 넣은 것이니까요.

어느 정도는 맞는 말입니다: 각 청크마다 이제 소스 문서 내에서 위치를 지정하고 컨텍스트 텍스트를 가져오기 위해 추가 LLM 호출을 수행합니다.

왜 추가 비용이 인제스트 단계에만 발생하는가

• 일회성 비용 – 추가 LLM 호출은 문서 인제스트 중에만 발생합니다.
• 런타임 오버헤드 없음 – 쿼리 시점에 컨텍스트를 유지하는 기술(예: Hypothetical Document Embeddings, HyDE)과 달리, 컨텍스트 검색은 사전에 무거운 작업을 수행합니다.
• 확장성 – 런타임 접근 방식은 사용자 쿼리마다 추가 LLM 호출이 필요하므로 지연 시간과 운영 비용이 급격히 증가합니다.

계산을 인제스트 단계로 옮김으로써, 런타임 중에는 추가 오버헤드 없이 더 높은 검색 품질을 얻을 수 있습니다.

추가 비용 절감 방안

• 프롬프트 캐싱 – 문서 요약을 한 번 생성한 뒤 캐시합니다. 각 청크는 요약을 다시 생성하는 대신 캐시된 요약을 사용해 위치를 지정할 수 있습니다.
• 배치 처리 – LLM 호출 시 청크를 그룹화하여 일부 제공업체가 제공하는 토큰‑단위 할인 혜택을 활용합니다.
• 선택적 캐싱 – 가장 자주 접근되는 문서나 검색 중요도가 높은 문서만 캐시합니다.

요약하면, 컨텍스트 검색은 초기 비용을 어느 정도 추가하지만, 프롬프트 캐싱 및 기타 최적화를 전략적으로 활용하면 전체 비용을 낮게 유지하면서 런타임 추가 비용을 없앨 수 있습니다.

내 생각

Contextual retrieval는 기존 RAG 시스템에 비해 간단하면서도 강력한 개선을 제공합니다. 각 청크에 컨텍스트 텍스트를 추가하여—해당 청크가 원본 문서 내에서 차지하는 의미적 위치를 정확히 지정함으로써—청크별 모호성을 크게 줄이고 LLM에 전달되는 정보의 품질을 향상시킵니다. 하이브리드 검색과 결합하면 이 기법을 통해 의미, 키워드, 컨텍스트를 동시에 보존할 수 있습니다.

---

이 글이 마음에 드셨나요? 친구가 되어 주세요! 다음에서 만나세요:

• 📰 Substack
• 💌 Medium
• 💼 LinkedIn
• ☕ Buy me a coffee

모든 이미지는 저자가 제공했으며, 별도 언급이 없는 한 그대로 사용되었습니다.

Footnotes

1. Anthropic, Contextual Retrieval – link ↩