이 글은 Anthropic 엔지니어링 블로그에 2024년 9월 19일 게재된 **“Introducing Contextual Retrieval”**을 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/contextual-retrieval
어떤 문제를 해결하려 했나 #
AI 모델이 특정 도메인에서 유용하게 동작하려면 배경 지식이 필요합니다. 고객 지원 챗봇은 해당 기업의 정보를 알아야 하고, 법률 분석 봇은 방대한 판례를 참조할 수 있어야 합니다.
이를 위해 개발자들은 RAG(Retrieval-Augmented Generation) 를 활용합니다. 문서를 작은 단위(청크)로 나누고, 질문과 가장 유사한 청크를 찾아 AI에게 전달하는 방식이죠.
그런데 여기서 근본적인 문제가 생깁니다.
문서를 청크로 잘라내는 순간, 문맥이 사라집니다.
예를 들어 재무 보고서에서 이런 청크가 추출됐다고 해봅시다.
“The company’s revenue grew by 3% over the previous quarter.”
이 문장만 봐서는 어느 회사인지, 어느 분기인지 알 수 없습니다. 검색 시스템도 마찬가지입니다. 문맥이 없는 청크는 엉뚱한 질문에 매칭되거나, 정작 필요한 순간에 검색되지 않습니다.
Anthropic의 해결책: Contextual Retrieval #
Anthropic은 이 문제를 두 가지 기법의 조합으로 해결했습니다.
1. Contextual Embeddings #
청크를 임베딩(벡터)으로 변환하기 전에, Claude가 해당 청크에 문맥 설명을 자동으로 추가합니다.
[기존 방식]
청크: "The company's revenue grew by 3% over the previous quarter."
→ 그대로 임베딩
[Contextual Embeddings]
청크 앞에 추가: "이 내용은 Apple Inc.의 2024년 Q2 재무 보고서 중
수익 성장 섹션에서 발췌된 내용입니다."
→ 문맥이 포함된 상태로 임베딩Claude가 원본 문서 전체를 보고 각 청크에 맞는 50~100 토큰 분량의 설명을 자동 생성합니다.
2. Contextual BM25 #
임베딩 기반 검색(의미 검색)에 더해, BM25(키워드 기반 검색) 도 함께 사용합니다. 이때도 마찬가지로 문맥이 추가된 청크를 인덱싱합니다.
임베딩 검색은 의미는 잘 잡지만 정확한 키워드를 놓치는 경우가 있고, BM25는 키워드에 강하지만 의미 파악에 약합니다. 두 방법을 합치면 서로의 약점을 보완합니다.
성능 결과 #
Anthropic이 다양한 도메인에서 테스트한 결과입니다.
| 방법 | Top-20 청크 검색 실패율 | 개선율 |
|---|---|---|
| 기존 RAG | 5.7% | 기준 |
| Contextual Embeddings | 3.7% | 35% 감소 |
| Contextual Embeddings + BM25 | 2.9% | 49% 감소 |
| + 리랭킹 추가 | ~1.9% | 67% 감소 |
단순히 청크에 문맥을 추가하는 것만으로 검색 실패율이 절반 가까이 줄었습니다.
비용은 얼마나 드나 #
문서 100만 토큰을 처리하는 기준으로 약 $1.02(단회 전처리 비용) 입니다.
Claude의 프롬프트 캐싱 기능 덕분입니다. 원본 문서 전체를 매번 재처리하지 않고 캐시해서 재사용하기 때문에 비용이 크게 낮아집니다.
핵심 결론 #
RAG의 문제는 청킹이 아니라, 청킹 후 문맥 손실이다.
기존에 많은 개발자들이 청크 크기를 조절하거나, 오버랩을 늘리거나, 더 좋은 임베딩 모델을 쓰는 방식으로 RAG 성능을 개선하려 했습니다. 하지만 Anthropic은 방향을 달리했습니다.
청크를 더 잘 자르는 게 아니라, 청크가 잘린 후에도 문맥을 기억하게 만드는 것. 이 발상의 전환이 핵심입니다.
실무 적용 방법 #
지금 당장 적용할 수 있는 것 #
하이브리드 검색 도입: 임베딩 검색만 쓰고 있다면 BM25를 함께 사용하세요. LangChain의 EnsembleRetriever로 쉽게 구현할 수 있습니다.
청킹 전 컨텍스트 추가: 청크를 임베딩하기 전에 원본 문서의 제목, 섹션, 출처 정보를 앞에 붙이는 것만으로도 효과가 있습니다. Claude 없이도 규칙 기반으로 구현 가능합니다.
리랭킹 모델 추가: 검색된 청크를 한 번 더 정렬하는 리랭커를 추가하면 정확도가 크게 오릅니다. Cohere Rerank나 cross-encoder 모델을 활용할 수 있습니다.
이 글이 RAG 구현에 주는 시사점 #
우리가 앞으로 만들 RAG 파이프라인에서도 이 원칙을 적용할 수 있습니다.
[단순 RAG]
문서 → 청킹 → 임베딩 → 검색 → 답변
[Contextual RAG]
문서 → 청킹 → 문맥 추가 → 임베딩 + BM25 → 하이브리드 검색 → 리랭킹 → 답변처음부터 완벽하게 구현할 필요는 없습니다. 기본 RAG를 먼저 만들고, 검색 품질이 떨어지는 지점에서 이 기법들을 하나씩 추가하면 됩니다.
Anthropic 엔지니어링 블로그를 읽고 정리합니다.