[Antropic 리뷰] Introducing Contextual Retrieval

 

 

출처 : 

https://www.anthropic.com/news/contextual-retrieval

Introducing Contextual Retrieval

CookBook : https://github.com/anthropics/anthropic-cookbook/blob/main/skills/contextual-embeddings/guide.ipynb

 

Conclusion

모든 기술(임베딩 모델, BM25 사용, Contextual Retrieval 사용, ReRanker 사용, 검색된 상위 K개 결과의 총 수)의 다양한 조합을 비교하는 많은 테스트를 다양한 데이터셋 유형에 걸쳐 실행.

 

다음은 발견한 내용을 요약한 것입니다:

1. 임베딩만 사용하는 것보다 임베딩과 BM25를 함께 사용하는 것이 더 좋다.
2. 우리가 테스트한 임베딩 중에서는 Voyage와 Gemini가 가장 좋다.
3. 모델에 상위 5개나 10개보다 상위 20개 조각을 전달하는 것이 더 효과적.
4. 조각에 맥락을 추가하면 검색 정확도가 크게 향상.
5. ReRanking을 사용하는 것이 사용하지 않는 것보다 낫다.
6. 이 모든 이점은 누적됩니다: 성능을 극대화하려면 Contextual Embeddings(Voyage나 Gemini의)와 Contextual BM25를 결합하고, ReRanking 단계를 추가한 다음, 20개의 조각을 프롬프트에 추가.

 

Abstract

 

• AI 모델 한계 : 특정 상황 활용을 위해 배경지식 필요
  • 예: 고객 지원 챗봇은 해당 기업 정보 필요
  • 예: 법률 분석 봇은 다양한 과거 사례 지식 필요
• 개발자들이 AI 지식 향상에 사용하는 방법: RAG
  • RAG : 지식 베이스에서 관련 정보 검색해 사용자 질문에 추가
  • 문제점 : 기존 RAG는 정보 인코딩 시 맥락이 제거되어 검색 실패 발생
• 새로운 방법 소개: 'Contextual Retrieval'
  • 세부 기술: 'Contextual Embedding'과 'Contextual BM25' 사용
  • 효과 : 검색 실패율 49% 감소 (ReRank 기법 결합 시 67% 감소)
  • 결과 : 검색 정확도 크게 향상, 다양한 작업 성능 개선
• Claude AI로 맥락적 검색 솔루션 구현 가능
  • 상세 방법은 가이드북 참조
• Contextual Retrieval의 간단한 대안
  • 적용 가능 조건: 지식 베이스가 200,000 토큰(약 500페이지) 미만일 때
  • 방법: 전체 지식 베이스를 프롬프트에 직접 포함

 

A primer on RAG : scaling to larger knowledge bases

 

컨텍스트 윈도우(AI 모델이 한 번에 처리할 수 있는 텍스트의 양)에 맞지 않는 더 큰 지식 베이스의 경우, RAG가 일반적인 해결책

RAG는 다음과 같은 단계로 지식 베이스를 전처 한다.:

1. 지식 베이스(문서의 "말뭉치")를 보통 몇 백 토큰을 넘지 않는 작은 텍스트 조각으로 나누고
2. 임베딩 모델을 사용해 이 조각들을 의미를 인코딩하는 벡터 임베딩으로 변환
3. 이 임베딩을 의미적 유사성으로 검색할 수 있는 벡터 데이터베이스에 저장

임베딩 모델의 한계

• 장점: 의미적 관계 포착에 뛰어남
• 단점: 정확한 단어/구문 일치를 놓칠 수 있음
• 보완 : BM25

BM25 (Best Matching 25)의 역할

• 기능: 정확한 단어/구문 일치를 찾는 순위 함수
• 기반: TF-IDF (Term Frequency-Inverse Document Frequency) 개념
• 장점: 문서 길이 고려, 일반적인 단어의 과도한 영향 방지
• 특징: 고유 식별자나 기술 용어 검색에 효과적
• BM25가 의미 있는 예) :
  사용자가 데이터베이스에서 "오류 코드 TS-999"를 검색한다고 가정. 임베딩 모델은 일반적인 오류 코드에 대한 내용은 찾을 수 있지만, 정확한 "TS-999" 일치를 놓칠 수 있다. BM25는 이 특정 텍스트 문자열을 찾아 관련 문서를 식별한다.

RAG와 BM25 결합 방식

1. 지식 베이스를 작은 조각으로 분할
2. 각 조각에 대해 TF-IDF 인코딩과 의미적 임베딩 생성
3. BM25로 정확한 일치 기반 상위 조각 검색
4. 임베딩으로 의미적 유사성 기반 상위 조각 검색
5. 두 결과를 결합하고 중복 제거 (Using rank fusion techniques)
6. 최종 선택된 상위 조각들을 AI 모델에 제공

 

이 방식의 장점

• 더 포괄적이고 정확한 결과 제공
• 정확한 용어 매칭과 넓은 의미적 이해 사이의 균형
• 매우 큰 지식 베이스로의 비용 효율적 확장 가능

현재 RAG 시스템의 주요 한계

• 맥락 파괴: 정보를 작은 조각으로 나누는 과정에서 전체적인 맥락이 손실될 수 있음
• 문서를 작은 조각으로 나누면서 맥락이 손실됨
• 이로 인해 관련 정보 검색 실패 가능성 증가

 

Introducing Contextual Retrieval

 

각 조각에 맥락 정보를 추가하는 새로운 방법

• 문서 검색은 임베딩 전에 각 청크에, 청크별 설명 문맥을 추가하고 BM25인덱스를 생성함으로서 문제를 해결
• whole document + chunk1 -> LLM -> context1 + chunk 1
• whole document + chunk2 -> LLM -> context2 + chunk 2
• whole document + chunk3 -> LLM -> context3 + chunk3

과거 방법들...

• 청크에 일반적인 문서 요약을 추가하는 방법(매우 제한적인 성능 향상)
• 가상 문서 임베딩, 요약 기반 인덱싱(실험해보니 성능이 낮았음.)

Context Example)

 

 

Implementing Contextual Retrieval

 

지식 베이스의 수많은 청크에 수동으로 주석을 달기에는 불가능

모델에게 전체 문서의 맥락을 사용해 조각을 설명하는 간결하고 조각별 맥락을 제공하는 프롬프트 작성

결과 : 결과로 나온 context text는 50-100토큰 조각이고, BM25와 Embedding전에, chunk앞 부분에 위치하게 된다.
(context + chunk)

 

Using Prompt Caching to reduce the costs of Contextual Retrieval

(제가 알기로, google에서 먼저 제안한 기술)

• 프롬프트 캐싱 기능으로 낮은 비용 가능
• 모든 chunk에 대해 참조 문서를 전달할 필요가 없음.
• 문서를 캐시에 로드한 다음 이전에 캐시된 내용을 참조하면 된다.

Methodology(Appendix II)

• 다양한 지식 도메인(코드베이스, 소설, ArXiv 논문, 과학 논문)
• 다양한 임베딩 모델
• 다양한 검색 전략
• 다양한 평가 지표

최고 성능...

• 임베딩 : Gemini Text 004
• 검색 전략(retrieve 수) : 20개 chunk를 검색하는 방식

위 두 조합을 할 경우, 아래와 같은 결과과 나온다.

 

실험 결과 : 

• Contextual Embeddings는 상위 20개 조각 검색 실패율은 35% 줄었다(5.7% → 3.7%).
• Contextual Embeddings와 Contextual BM25를 결합하면 상위 20개 조각 검색 실패율은 49% 줄었다(5.7% → 2.9%).

 

Implementation Considerations

 

• Chunk boundaries : 문서를 조각으로 나누는 방법을 고려. chunk (크기, 경계, 중복) 선택이 검색 성능에 영향을 미침.
• Embedding model : Contextual Retrieval은 테스트한 모든 임베딩 모델에서 성능을 향상시키지만, 일부 모델은 다른 모델보다 더 좋은 성능을 얻을 수 있음. (Gemini와 Voyage 임베딩이 특히 효과적)
• Custom contextualizer prompts : 일반적인 프롬프트도 잘 작동하지만, 특정 도메인이나 사용 사례에 맞춘 프롬프트를 사용하면 더 나은 결과를 얻을 수 있다(예: 지식 베이스의 다른 문서에서만 정의될 수 있는 주요 용어 목록 포함).
• Number of chunks : context window에 더 많은 조각을 추가하면 관련 정보를 포함할 가능성이 높아진다. 그러나 정보가 너무 많으면 모델에게 혼란을 줄 수 있어 한계가 있다. 우리는 5, 10, 20개의 조각을 전달하는 실험을 했고, 20개를 사용하는 것이 이 옵션들 중 가장 성능이 좋았다(비교는 부록 참조). 하지만 데이터마다 optimal 조각 갯수가 다르므로 실험해보길 권장한다.
• Always run evals : contextualized chunk와 원본 chunk를 구분하여 전달하는게, 응답 성능을 향상시킬 수 있다.

 

 

Further boosting performance with Reranking

• 마지막 단계로, Contextual Retrieval과 또 다른 기술을 결합하여 더 큰 성능 향상을 얻을 수 있다.
• 큰 지식 베이스의 경우, 수백 개를 반환한다.
• ReRanking은 가장 관련성 높은 조각만 모델에 전달되도록 하는 일반적으로 사용되는 필터링 기술.
• ReRanking은 모델이 처리하는 정보량을 줄여 더 나은 응답을 제공하고 비용과 지연 시간을 줄인다.

주요 단계 :

1. 초기 검색을 수행하여 잠재적으로 관련 있는 상위 조각들을 가져온다(여기서는 상위 150개 사용 했다고 함).
2. 상위 N개의 조각과 사용자의 질문을 ReRanking 모델에 전달
3. ReRanking 모델을 사용하여 각 조각에 프롬프트에 대한 관련성과 중요도를 기반으로 점수를 매긴 다음 상위 K개의 조각을 선택(우리는 상위 20개 사용).
4. 선택된 상위 K개의 조각을 최종 결과를 생성하기 위한 맥락으로 모델에 전달

 

Performance Improvements

• 상용화된 여러 ReRanking 모델이 있다.
• 여기서는 Cohere ReRanker로 테스트를 진행.
• Voyage도 ReRanker를 제공하지만, 우리는 시간 관계로 테스트하지 못함.
• 실험은 다양한 도메인에서 ReRanking 단계를 추가하면 검색을 더욱 최적화한다는 것을 보여줌
• 구체적으로, Reranked Contextual Embedding과 Contextual BM25를 사용하면 상위 20개 조각 검색 실패율을 67% 줄었다(5.7% → 1.9%).

 

Cost and latency considerations

ReRanking할 때 지연 시간과 비용 발생. 특정 사용 사례에 대해 다양한 설정으로 실험해 보고 적절한 균형을 찾는 것을 권장

 

 

Codebase에 실험 : 출처 : https://assets.anthropic.com/m/1632cded0a125333/original/Contextual-Retrieval-Appendix-2.pdf

고민할 부분 :

• 블로그에 나온 방법대로, 코드에 적용하기 위해서는 어떻게 해야하지? context 정보를 어떻게 chunk 앞 부분에 넣지?
• Chunking strategy는 뭐지?