요약: AI 모델이 특정 문맥에서 유용하게 작동하려면 배경 지식 접근이 필요하며, 일반적으로 RAG(Retrieval-Augmented Generation)를 활용합니다. 하지만 전통적인 RAG는 정보 인코딩 시 문맥을 잃어버려 관련 정보 검색에 실패하는 경우가 많습니다. Anthropic이 제안하는 “Contextual Retrieval”은 각 청크에 문맥별 설명을 추가하여 검색 실패율을 49%까지 감소시키고, 리랭킹(reranking)과 결합하면 67%까지 감소시킬 수 있습니다.
AI 모델이 특정 문맥에서 유용하게 작동하려면 종종 배경 지식에 대한 접근이 필요합니다. 예를 들어, 고객 지원 챗봇은 사용되는 비즈니스에 대한 지식이 필요하고, 법률 분석 봇은 과거 다양한 사건에 대해 알아야 합니다. 개발자들은 일반적으로 RAG(Retrieval-Augmented Generation)를 사용하여 AI 모델의 지식을 향상시킵니다. RAG는 지식 베이스에서 관련 정보를 검색하여 사용자 프롬프트에 추가하는 방식으로, 모델의 응답을 크게 향상시킵니다. 문제는 전통적인 RAG 솔루션이 정보를 인코딩할 때 문맥을 제거하여, 지식 베이스에서 관련 정보를 검색하지 못하는 경우가 많다는 점입니다. 이 글에서는 RAG의 검색 단계를 크게 개선하는 방법을 설명합니다. 이 방법은 “Contextual Retrieval”이라고 불리며, 두 가지 하위 기법인 Contextual Embeddings와 Contextual BM25를 사용합니다. 이 방법은 검색 실패 횟수를 49% 감소시키고, 리랭킹(reranking)과 결합하면 67%까지 감소시킬 수 있습니다. 이는 검색 정확도의 상당한 개선을 의미하며, 이는 직접적으로 다운스트림 작업의 더 나은 성능으로 이어집니다. Claude를 사용하여 쿡북(cookbook)을 통해 자신만의 Contextual Retrieval 솔루션을 쉽게 배포할 수 있습니다.
더 긴 프롬프트를 단순히 사용하는 것에 대한 참고
때로는 가장 간단한 해결책이 최고입니다. 지식 베이스가 200,000 토큰 미만(약 500페이지 분량의 자료)인 경우, 모델에 전체 지식 베이스를 프롬프트에 포함시킬 수 있으며, RAG나 유사한 방법이 필요하지 않습니다. 몇 주 전, 우리는 Claude를 위한 프롬프트 캐싱을 출시했으며, 이는 이 접근 방식을 훨씬 더 빠르고 비용 효율적으로 만들었습니다. 개발자들은 이제 API 호출 간에 자주 사용되는 프롬프트를 캐시하여 대기 시간을 2배 이상 줄이고 비용을 최대 90%까지 절감할 수 있습니다(프롬프트 캐싱 쿡북을 통해 작동 방식을 볼 수 있습니다). 하지만 지식 베이스가 커지면 더 확장 가능한 솔루션이 필요합니다. 바로 여기서 Contextual Retrieval이 등장합니다.
RAG 기초: 더 큰 지식 베이스로 확장
컨텍스트 윈도우에 맞지 않는 더 큰 지식 베이스의 경우, RAG가 일반적인 해결책입니다. RAG는 지식 베이스를 다음 단계를 사용하여 전처리하여 작동합니다.
- 지식 베이스(문서 “corpus”)를 일반적으로 수백 토큰을 넘지 않는 작은 텍스트 청크(chunk)로 분할합니다.
- 임베딩 모델을 사용하여 이 청크를 의미를 인코딩하는 벡터 임베딩으로 변환합니다.
- 의미적 유사성으로 검색할 수 있도록 이 임베딩을 벡터 데이터베이스에 저장합니다.
런타임에서 사용자가 모델에 쿼리를 입력하면, 벡터 데이터베이스를 사용하여 쿼리와 의미적 유사성을 기준으로 가장 관련성 높은 청크를 찾습니다. 그런 다음 가장 관련성 높은 청크를 생성 모델에 보낼 프롬프트에 추가합니다.
임베딩 모델은 의미적 관계를 포착하는 데 뛰어나지만, 중요한 정확한 일치를 놓칠 수 있습니다. 다행히 이러한 상황에서 도움이 될 수 있는 오래된 기법이 있습니다. BM25(Best Matching 25)는 어휘적 일치(lexical matching)를 사용하여 정확한 단어나 구문 일치를 찾는 순위 함수입니다. 특히 고유 식별자나 기술 용어를 포함하는 쿼리에 효과적입니다.
BM25는 TF-IDF(Term Frequency-Inverse Document Frequency) 개념을 기반으로 작동합니다. TF-IDF는 컬렉션에서 문서에 대한 단어의 중요성을 측정합니다. BM25는 문서 길이를 고려하고 용어 빈도에 포화 함수를 적용하여 이를 개선하며, 이는 일반적인 단어가 결과를 지배하는 것을 방지하는 데 도움이 됩니다.
다음은 의미적 임베딩이 실패하는 곳에서 BM25가 성공할 수 있는 방법입니다. 사용자가 기술 지원 데이터베이스에서 “Error code TS-999″를 쿼리한다고 가정해 봅시다. 임베딩 모델은 일반적으로 오류 코드에 대한 콘텐츠를 찾을 수 있지만, 정확한 “TS-999” 일치를 놓칠 수 있습니다. BM25는 관련 문서를 식별하기 위해 이 특정 텍스트 문자열을 찾습니다.
RAG 솔루션은 다음 단계를 사용하여 임베딩과 BM25 기법을 결합함으로써 가장 적용 가능한 청크를 더 정확하게 검색할 수 있습니다.
- 지식 베이스(문서 “corpus”)를 일반적으로 수백 토큰을 넘지 않는 작은 텍스트 청크로 분할합니다.
- 이 청크에 대한 TF-IDF 인코딩과 의미적 임베딩을 생성합니다.
- BM25를 사용하여 정확한 일치를 기준으로 최상위 청크를 찾습니다.
- 임베딩을 사용하여 의미적 유사성을 기준으로 최상위 청크를 찾습니다.
- 순위 융합(rank fusion) 기법을 사용하여 (3)과 (4)의 결과를 결합하고 중복을 제거합니다.
- 최상위 K 청크를 프롬프트에 추가하여 응답을 생성합니다.
BM25와 임베딩 모델을 모두 활용함으로써 전통적인 RAG 시스템은 정확한 용어 일치와 더 넓은 의미적 이해 사이의 균형을 맞추어 더 포괄적이고 정확한 결과를 제공할 수 있습니다.
임베딩과 BM25(Best Match 25)를 모두 사용하여 정보를 검색하는 표준 RAG(Retrieval-Augmented Generation) 시스템. TF-IDF(용어 빈도-역 문서 빈도)는 단어 중요성을 측정하며 BM25의 기초를 형성합니다. 이 접근 방식은 단일 프롬프트에 맞을 수 있는 것보다 훨씬 더 큰 지식 베이스로 비용 효율적으로 확장할 수 있습니다. 하지만 이러한 전통적인 RAG 시스템에는 상당한 제한이 있습니다. 종종 문맥을 파괴합니다.
전통적 RAG의 문맥 딜레마
전통적인 RAG에서 문서는 일반적으로 효율적인 검색을 위해 작은 청크로 분할됩니다. 이 접근 방식은 많은 응용 프로그램에서 잘 작동하지만, 개별 청크에 충분한 문맥이 부족할 때 문제가 발생할 수 있습니다. 예를 들어, 재무 정보(예: 미국 SEC 제출물)가 지식 베이스에 임베딩되어 있고 다음 질문을 받았다고 가정해 봅시다.
“ACME Corp의 2023년 2분기 매출 성장률은 얼마였나요?”
관련 청크에는 다음 텍스트가 포함될 수 있습니다.
“The company’s revenue grew by 3% over the previous quarter.”
하지만 이 청크 자체는 어떤 회사를 참조하는지나 관련 시기가 무엇인지 명시하지 않아, 올바른 정보를 검색하거나 정보를 효과적으로 사용하기 어렵습니다.
Contextual Retrieval 소개
Contextual Retrieval은 각 청크에 청크별 설명 문맥을 임베딩하기 전에 추가(“Contextual Embeddings”)하고 BM25 인덱스를 생성하기 전에 추가(“Contextual BM25”)하여 이 문제를 해결합니다. SEC 제출물 모음 예제로 돌아가 보겠습니다. 청크가 어떻게 변환될 수 있는지에 대한 예는 다음과 같습니다.
“
original_chunk = "The company's revenue grew by 3% over the previous quarter."
contextualized_chunk = "This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter."
`
문맥을 사용하여 검색을 개선하는 다른 접근 방식이 과거에 제안되었다는 점은 주목할 가치가 있습니다. 다른 제안에는 청크에 일반적인 문서 요약 추가(우리는 실험했고 매우 제한적인 이득만 보았음), 가상 문서 임베딩(hypothetical document embedding), 요약 기반 인덱싱(우리는 평가했고 낮은 성능을 확인함)이 포함됩니다. 이러한 방법은 이 게시물에서 제안하는 것과 다릅니다.
Contextual Retrieval 구현
물론 지식 베이스의 수천 또는 수백만 청크를 수동으로 주석 처리하는 것은 너무 많은 작업입니다. Contextual Retrieval을 구현하기 위해 우리는 Claude를 활용합니다. 우리는 전체 문서의 문맥을 사용하여 청크를 설명하는 간결한 청크별 문맥을 제공하도록 모델에 지시하는 프롬프트를 작성했습니다. 우리는 각 청크에 대한 문맥을 생성하기 위해 다음 Claude 3 Haiku 프롬프트를 사용했습니다.
`
{{WHOLE_DOCUMENT}}
Here is the chunk we want to situate within the whole document
{{CHUNK_CONTENT}}
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.
“
결과 문맥 텍스트는 일반적으로 50-100 토큰이며, 임베딩하기 전과 BM25 인덱스를 생성하기 전에 청크 앞에 추가됩니다. 실제로 전처리 흐름이 어떻게 보이는지 다음과 같습니다.
Contextual Retrieval은 검색 정확도를 개선하는 전처리 기술입니다. Contextual Retrieval을 사용하는 데 관심이 있다면 쿡북으로 시작할 수 있습니다.
프롬프트 캐싱을 사용하여 Contextual Retrieval의 비용 절감
Contextual Retrieval은 위에서 언급한 특별한 프롬프트 캐싱 기능 덕분에 Claude로 저렴하게 구현할 수 있습니다. 프롬프트 캐싱을 사용하면 모든 청크에 참조 문서를 전달할 필요가 없습니다. 문서를 캐시에 한 번 로드한 다음 이전에 캐시된 콘텐츠를 참조하면 됩니다. 800 토큰 청크, 8k 토큰 문서, 50 토큰 문맥 지침, 청크당 100 토큰의 문맥을 가정하면, 문맥화된 청크를 생성하는 일회성 비용은 백만 문서 토큰당 $1.02입니다.
방법론
우리는 다양한 지식 도메인(코드베이스, 소설, ArXiv 논문, 과학 논문), 임베딩 모델, 검색 전략 및 평가 지표를 통해 실험했습니다. 우리는 부록 II에서 각 도메인에 사용한 질문과 답변의 예를 몇 가지 포함했습니다. 아래 그래프는 최고 성능의 임베딩 구성(Gemini Text 004)과 상위 20개 청크를 검색할 때 모든 지식 도메인의 평균 성능을 보여줍니다. 우리는 평가 지표로 1 빼기 recall@20을 사용하며, 이는 상위 20개 청크 내에서 검색되지 않은 관련 문서의 백분율을 측정합니다. 부록에서 전체 결과를 볼 수 있습니다. 문맥화는 우리가 평가한 모든 임베딩-소스 조합에서 성능을 향상시킵니다.
성능 개선
우리의 실험은 다음을 보여주었습니다.
- Contextual Embeddings는 상위 20개 청크 검색 실패율을 35% 감소시켰습니다(5.7% → 3.7%).
- Contextual Embeddings와 Contextual BM25를 결합하면 상위 20개 청크 검색 실패율을 49% 감소시켰습니다(5.7% → 2.9%).
Contextual Embedding과 Contextual BM25를 결합하면 상위 20개 청크 검색 실패율을 49% 감소시킵니다.
구현 고려사항
Contextual Retrieval을 구현할 때 몇 가지 고려사항을 염두에 두어야 합니다.
- 청크 경계: 문서를 청크로 분할하는 방법을 고려하세요. 청크 크기, 청크 경계, 청크 중복의 선택은 검색 성능에 영향을 미칠 수 있습니다.
- 임베딩 모델: Contextual Retrieval은 우리가 테스트한 모든 임베딩 모델에서 성능을 향상시키지만, 일부 모델은 다른 모델보다 더 많은 이점을 얻을 수 있습니다. 우리는 Gemini와 Voyage 임베딩이 특히 효과적이라는 것을 발견했습니다.
- 사용자 정의 문맥화 프롬프트: 우리가 제공한 일반적인 프롬프트는 잘 작동하지만, 특정 도메인이나 사용 사례에 맞게 조정된 프롬프트로 더 나은 결과를 얻을 수 있습니다(예: 지식 베이스의 다른 문서에서만 정의될 수 있는 주요 용어 용어집 포함).
- 청크 수: 컨텍스트 윈도우에 더 많은 청크를 추가하면 관련 정보를 포함할 확률이 높아집니다. 하지만 더 많은 정보는 모델에게 산만할 수 있으므로 여기에는 한계가 있습니다. 우리는 5, 10, 20개 청크를 전달해 보았고, 20개를 사용하는 것이 이 옵션 중에서 가장 성능이 좋다는 것을 발견했습니다(비교는 부록 참조). 하지만 사용 사례에서 실험해 볼 가치가 있습니다.
- 항상 평가 실행: 문맥화된 청크를 전달하고 문맥과 청크 사이를 구별하여 응답 생성을 개선할 수 있습니다.
리랭킹으로 성능 추가 향상
최종 단계에서, 우리는 Contextual Retrieval을 다른 기법과 결합하여 더 많은 성능 향상을 제공할 수 있습니다. 전통적인 RAG에서 AI 시스템은 지식 베이스를 검색하여 잠재적으로 관련 정보 청크를 찾습니다. 큰 지식 베이스의 경우, 이 초기 검색은 종종 다양한 관련성과 중요성을 가진 많은 청크(때로는 수백 개)를 반환합니다. 리랭킹(reranking)은 가장 관련성 높은 청크만 모델에 전달되도록 하는 일반적으로 사용되는 필터링 기법입니다. 리랭킹은 더 나은 응답을 제공하고 비용과 대기 시간을 줄입니다. 왜냐하면 모델이 처리하는 정보가 적기 때문입니다.
주요 단계는 다음과 같습니다.
- 최상위 잠재적으로 관련 있는 청크를 얻기 위해 초기 검색을 수행합니다(우리는 상위 150개를 사용함).
- 상위 N 청크와 사용자 쿼리를 리랭킹 모델에 전달합니다.
- 리랭킹 모델을 사용하여 각 청크에 프롬프트에 대한 관련성과 중요성을 기준으로 점수를 매기고, 상위 K 청크를 선택합니다(우리는 상위 20개를 사용함).
- 최종 결과를 생성하기 위해 컨텍스트로 상위 K 청크를 모델에 전달합니다.
Contextual Retrieval과 Reranking을 결합하여 검색 정확도를 최대화하세요.
성능 개선
시장에는 여러 리랭킹 모델이 있습니다. 우리는 Cohere reranker로 테스트를 실행했습니다. Voyage도 reranker를 제공하지만 테스트할 시간이 없었습니다. 우리의 실험은 다양한 도메인에서 리랭킹 단계를 추가하면 검색을 더욱 최적화한다는 것을 보여주었습니다. 구체적으로, 우리는 리랭킹된 Contextual Embedding과 Contextual BM25가 상위 20개 청크 검색 실패율을 67% 감소시킨다는 것을 발견했습니다(5.7% → 1.9%).
리랭킹된 Contextual Embedding과 Contextual BM25는 상위 20개 청크 검색 실패율을 67% 감소시킵니다.
비용 및 대기 시간 고려사항
리랭킹의 한 가지 중요한 고려사항은 특히 많은 수의 청크를 리랭킹할 때 대기 시간과 비용에 대한 영향입니다. 리랭킹은 런타임에 추가 단계를 추가하므로, 리랭커가 모든 청크를 병렬로 점수 매기더라도 작은 양의 대기 시간이 필연적으로 추가됩니다. 더 나은 성능을 위해 더 많은 청크를 리랭킹하는 것과 더 낮은 대기 시간과 비용을 위해 더 적은 청크를 리랭킹하는 것 사이에는 본질적인 트레이드오프가 있습니다. 올바른 균형을 찾기 위해 특정 사용 사례에서 다른 설정으로 실험해 보는 것이 좋습니다.
결론
우리는 위에서 설명한 모든 기법(임베딩 모델, BM25 사용, 문맥 검색 사용, 리랭커 사용, 검색된 상위 K 결과 총 수)의 다양한 조합을 다양한 데이터 세트 유형에 걸쳐 비교하는 많은 수의 테스트를 실행했습니다. 우리가 발견한 것의 요약은 다음과 같습니다.
- Embeddings+BM25는 단독 임베딩보다 낫습니다.
- Voyage와 Gemini는 우리가 테스트한 것 중 가장 좋은 임베딩을 가지고 있습니다.
- 상위 20개 청크를 모델에 전달하는 것이 상위 10개 또는 상위 5개만 전달하는 것보다 더 효과적입니다.
- 청크에 문맥을 추가하면 검색 정확도가 크게 향상됩니다.
- 리랭킹이 리랭킹 없는 것보다 낫습니다.
- 이러한 모든 이점은 중첩됩니다. 성능 향상을 최대화하기 위해 우리는 문맥화된 BM25와 함께 문맥화된 임베딩(Voyage 또는 Gemini), 리랭킹 단계, 프롬프트에 20개 청크 추가를 결합할 수 있습니다.
우리는 지식 베이스로 작업하는 모든 개발자가 새로운 수준의 성능을 잠금 해제하기 위해 이러한 접근 방식으로 실험하기 위해 쿡북을 사용하기를 권장합니다.
부록 I
다음은 데이터 세트, 임베딩 제공자, 임베딩 외의 BM25 사용, 문맥 검색 사용, 리랭킹 사용에 대한 결과 분석입니다. 검색 @ 10 및 @ 5에 대한 분해와 각 데이터 세트에 대한 예제 질문과 답변은 부록 II를 참조하세요.
데이터 세트 및 임베딩 제공자에 걸친 1 빼기 recall @ 20 결과.
감사의 말
연구 및 작성: Daniel Ford. 중요한 피드백을 제공한 Orowa Sikder, Gautam Mittal, Kenneth Lien에게 감사드립니다. 쿡북을 구현한 Samuel Flamini, 프로젝트 조정을 담당한 Lauren Polansky, 이 블로그 게시물을 형성한 Alex Albert, Susan Payne, Stuart Ritchie, Brad Abrams에게 감사드립니다.
핵심 포인트
- Contextual Retrieval은 각 텍스트 청크에 문맥별 설명을 추가하여 전통적 RAG 시스템의 문맥 손실 문제를 해결합니다.
- 이 방법은 검색 실패율을 49% 감소시키고, 리랭킹(reranking)과 결합하면 67%까지 감소시킬 수 있습니다.
- Claude의 프롬프트 캐싱 기능을 활용하면 효율적이고 비용 효율적으로 문맥화된 청크를 생성할 수 있습니다.
