Contextual Retrieval 소개

AI 모델이 특정 업무에 유용하려면 배경 지식이 필요하고, 이를 보완하는 대표 방식이 RAG다. 하지만 전통적인 RAG는 문서를 잘게 쪼개는 과정에서 맥락이 사라져, 의미상 맞는 조각을 놓치거나 정확한 용어·식별자를 찾지 못하는 문제가 생긴다.

그 대안으로 Contextual Retrieval이 제안된다. 각 청크 앞에 문서 전체를 바탕으로 만든 짧은 설명을 붙여 Contextual Embeddings와 Contextual BM25를 동시에 구성하면, 검색에 필요한 맥락이 보존된다. 예시로 SEC filing의 한 문장을 임베딩하기 전에 "어느 회사의 어느 분기 문서인지"를 먼저 덧붙여, "매출이 3% 증가했다" 같은 문장이 원래 의미를 잃지 않도록 만든다.

핵심 흐름은 다음과 같다.

• 문서를 청크로 분할한다.
• Claude로 각 청크에 들어갈 짧은 상황 설명을 생성한다.
• 그 설명을 청크 앞에 붙인 뒤 임베딩과 BM25 인덱스를 만든다.
• 검색 시에는 의미 검색과 정확 일치 검색을 함께 쓰고, 결과를 합쳐 상위 청크를 모델에 넣는다.

이 방식은 전통적 RAG의 약점을 크게 줄인다. 실험 결과, Contextual Embeddings만으로도 top-20 청크 검색 실패율이 35% 감소했고, Contextual Embeddings + Contextual BM25 조합은 **49%**까지 낮췄다. 여기에 reranking까지 더하면 실패율이 67% 감소해, downstream task 성능으로도 이어질 가능성을 보여준다.

비용 측면에서는 Claude의 prompt caching이 중요하다. 전체 문서를 매번 다시 넣지 않고 캐시에 한 번 올린 뒤 청크별로 참조할 수 있어, 800토큰 청크와 8k 토큰 문서 기준으로 contextualized chunk 생성 비용이 문서 토큰 100만 개당 $1.02 수준까지 내려간다.

다만 적용 시에는 몇 가지를 따져봐야 한다.

• chunk boundary와 overlap은 검색 성능에 직접 영향을 준다.
• 임베딩 모델에 따라 개선 폭이 다르며, 글에서는 Gemini Text 004와 Voyage 임베딩이 특히 좋았다고 밝힌다.
• 범용 프롬프트보다 도메인별 glossary를 넣은 맞춤형 contextualizer가 더 나을 수 있다.
• top-K로 몇 개 청크를 넣을지, reranking에서 몇 개 후보를 볼지는 직접 eval로 확인해야 한다.

전체적으로 이 접근은 "더 큰 모델"보다 "더 좋은 검색 입력"이 RAG 품질을 얼마나 크게 좌우하는지 보여준다. 문서가 충분히 작으면 아예 전체를 프롬프트에 넣는 단순한 방법도 가능하지만, 지식베이스가 커질수록 맥락을 보존한 검색 파이프라인이 핵심이 된다.