JisooLog

[논문 원본]

https://arxiv.org/pdf/2412.15605

Abstract

본 연구에서는 기존의 실시간 검색(RAG) 기반 시스템을 개선한 $\text{CAG (Context-Aware Generation)}$ 시스템을 제안합니다. CAG는 대규모 문서 집합을 미리 Key-Value $\text{(KV)}$ 캐시 형식으로 인코딩하여 저장하고, 이를 이용해 실시간 검색 없이 질의에 대한 답변을 생성하는 방식입니다. 이를 통해, 검색 지연을 없애고, 검색 오류를 줄이며, 시스템 복잡도를 최소화하는 장점이 있습니다. 이 방식은 특히 제한된 지식 기반에 대해 효율적이고 간소화된 대안을 제공할 수 있습니다.

Introduction

RAG$\text{(Retrieval-Augmented Generation)}$는 외부 지식 출처를 통합하여 대규모 언어 모델의 성능을 향상시킬 수 있는 강력한 접근법으로 주목받고 있다. 그러나 실시간 검색이 필요하며, 이는 검색 지연과 문서 선택 오류를 초래할 수 있다. 이에 대한 대안으로, 본 논문은 $\text{CAG (Context-Aware Generation)}$ 방법을 제안한다. CAG는 문서를 미리 로드하고 KV 캐시를 계산하여 저장함으로써, 실시간 검색을 생략하고 검색 지연을 제거한다. 이 방법은 특히 지식 기반이 제한적이고 관리 가능한 크기일 때 유용하다.

Methodology

CAG는 LLM의 확장된 컨텍스트 기능을 활용하여 외부 지식 출처를 사전 로드하고, 이를 KV 캐시로 인코딩하여 저장한다. CAG의 작업 흐름은 다음 세 가지 단계로 나뉜다:

1. $\text{External Knowledge Preloading (외부 지식 미리 로딩)}$: 관련 문서를 LLM의 확장된 컨텍스트 윈도우에 맞게 전처리하고 KV 캐시로 인코딩하여 저장한다.
2. $\text{Inference (추론)}$: 사전 계산된 KV 캐시와 사용자 쿼리를 함께 로드하여 추론을 수행한다. 실시간 검색이 필요 없어 검색 지연을 없애고, 문서 선택 오류를 줄인다.
3. $\text{Cache Reset (캐시 초기화)}$: 여러 추론 세션을 지원하기 위해, KV 캐시는 효율적으로 초기화되어야 한다. 이를 통해 성능을 유지하며, 새로운 정보를 빠르게 반영할 수 있다.

3.1 Experimental Setup

본 실험에서는 SQuAD 1.0과 HotPotQA 두 개의 대표적인 질문 응답 데이터셋을 사용하여 성능을 평가했습니다. 실험에서는 문서 수와 참고 텍스트의 길이가 시스템 성능에 미치는 영향을 분석했습니다. 각 실험은 CAG와 두 가지 $\text{RAG 시스템(Sparse Retrieval (BM25)와 Dense Retrieval(OpenAI Indexes))}$ 간의 성능 비교를 기반으로 진행되었습니다.

사용된 모델:

• 실험에서는 Llama 3.1 8B Instruction 모델을 기반으로 CAG와 RAG 시스템을 모두 평가했습니다. 이 모델은 최대 128k 토큰까지 처리할 수 있는 능력을 가진 대형 언어 모델로, 문서의 대용량 텍스트를 효과적으로 처리하며 성능을 발휘합니다. 실험은 Tesla V100 32GB × 8 GPUs 환경에서 수행되었습니다.

모델 작업 방식:

• 본 시스템에서 생성된 응답은 사전 계산된 키-값 캐시 $\text{(Key-Value Cache)}$ 를 사용하여 처리됩니다. 즉, 각 데이터셋의 문서들이 KV 인코딩되어 Offline에 저장된 후, 추론 시 불러와서 실시간 검색을 하지 않고도 응답을 생성합니다.

$$CKV = KV-Encode(D)$$

위 수식에서 CKV는 문서 D의 키-값 캐시입니다. 이 캐시는 문서 D의 텍스트가 KV-Encode 함수에 의해 사전 계산되어 저장된 값입니다. 이후 이 값들을 사용하여 질문에 대한 답을 생성하는데, 이는 모델의 빠른 응답 생성에 기여합니다.

3.2 Baseline Systems

• Sparse Retrieval System (BM25): BM25는 전통적인 텍스트 검색 알고리즘으로, 질의와 문서 간의 단어 빈도와 문서 길이를 기반으로 순위를 매깁니다. 질의와 문서 간의 일치도를 계산하고, 이를 바탕으로 적합한 문서를 검색합니다. 질의 $q$에 대해 BM25는 다음과 같이 문서 $D$를 평가합니다.

$$ \text{BM25}(q, D) = \sum_{t \in q} \text{IDF}(t) \cdot \frac{f(t, D) \cdot (k_1 + 1)}{f(t, D) + k_1 \cdot \left(1 - b + b \cdot \frac{|D|}{avgDL}\right)}$$

여기서 $f(t, D)$는 문서 $D$에서 용어 $t$의 빈도, $|D|$는 문서의 길이, $avgDL$은 문서들의 평균 길이, $k_1$과 $b$는 하이퍼파라미터입니다.

• Dense Retrieval System $\text{(OpenAI Indexes)}$: OpenAI Indexes는 dense embedding을 사용하여 문서와 질의를 공유된 의미 공간$\text{(shared semantic space)}$에서 처리합니다. Dense retrieval은 문서와 질의 간의 의미적 유사성을 계산하여 관련 문서를 찾습니다. 이는 다음과 같은 방식으로 계산됩니다:

$$\text{similarity}(q, D) = \mathbf{q}^T \mathbf{D}$$

여기서 $q$와 $D$는 각각 질의와 문서의 임베딩 벡터입니다. 이 벡터들은 고차원 공간에서의 유사성을 기반으로 계산되며, 단어의 의미적 관계를 반영합니다.

3.3 Results

표 설명: 위 표는 BERTScore를 기반으로 한 CAG와 RAG 시스템의 성능 비교를 나타냅니다. CAG 시스템은 대부분의 실험에서 상위 점수를 기록하며, 특히 Top-1 BERTScore에서 월등히 높은 성과를 보였습니다.

3.4 Generation Time (생성 시간)

표 설명: CAG 시스템은 생성 시간 면에서도 크게 향상된 결과를 보여줍니다. 기존의 RAG 시스템에 비해 생성 시간이 현저히 빠름을 확인할 수 있습니다.

Conclusion

긴 컨텍스트를 처리할 수 있는 LLM의 발전을 바탕으로, CAG는 기존 RAG 시스템을 대체할 수 있는 가능성을 제시한다. 특히, 지식 기반이 상대적으로 제한적이고 관리 가능한 경우 CAG가 효율적이고 간단한 해결책을 제공할 수 있다. 또한, 향후 LLM의 발전에 따라, CAG는 더 많은 복잡한 작업에도 적용될 수 있을 것이다. 하이브리드 접근법으로는, 사전 로딩된 컨텍스트와 선택적인 검색을 결합하여 유연성을 높일 수 있다.

생각한 한계점 (예상)

• 실시간 문서 처리 불가능: CAG 방식은 문서를 미리 KV 캐시로 로드하여 사용하므로, 새로운 문서를 실시간으로 처리하고 반영하는 데 한계가 있을 수 있다. 실시간 문서 업로드 후 즉시 질문을 처리하는 것은 불가능하다.
• 메모리 한계: 문서가 많을 경우, 모든 정보를 RAM에 저장해야 하므로 메모리의 용량이 제한적일 수 있다. 메모리 용량을 초과할 경우, 캐시를 초기화하거나 일부 데이터를 제외하는 방법을 사용할 수 있지만, 이는 실시간 반영의 유연성을 떨어뜨릴 수 있다.
• 스케일링 문제: CAG가 효과적으로 작동하기 위해서는 전체 문서가 모델의 컨텍스트 윈도우에 맞는 크기로 전처리되어야 한다. 하지만 대규모 데이터셋에서는 이 방법이 비효율적일 수 있다. 특히 문서가 방대할 경우, 모든 데이터를 사전 로딩하는 데 시간이 많이 소요될 수 있다.

테디노트 영상을 보고 정리한 글입니다.

실전! RAG 고급 기법 - Retriever (1)

Multi-query

• 대충 질문해도 좋은 답변 원할 때

예시

[기존의 RAG]

사용자의 질문: B은행의 대출은 어때? → LLM 답변: B 은형의 대출은 좋은 편입니다.

[Multi-query RAG]

사용자의 질문: B은행의 대출은 어때?

→ 재생성 질문:

1) B 은행의 대출 금리는 어때?

2) B 은행의 대출 조건은 어때?

3) B 은행의 대출 후기는 어때?

→ LLM 답변: B 은행 대출 요약 (금리, 조건, 후기 등등)

from langchain.retrievers.multi_query import MultiQueryRetriever

Parent-Document

• 앞 뒤 문맥 잘 담아야할 때

[기존 RAG]

query와 가장 유사한 chuck를 참고문서로 LLM에게 넘겨주고 그에 맞는 답을 받는다.

• 문제점: 예를들어 유사한 청크(1-1)를 참고문서라고 했을 때, 질문이 청크(1-1)에서 모두 커버가 되면 문제가 없음. but, 중요한 내용이 1-2에 있다면, LLM은 정확한 답변을 해줄 수 없다. (1-1만 참고하고 있기 때문)

[Parent-Document RAG]

1-1만 LLM에게 주는 것이 아니라 1-1을 포함하고 있는 parent-document를 주게 된다.

유사 문서의 부모 문서를 참고하므로, 조금 더 맥락을 담아 LLM에게 제공 가능

from langchain.retrievers import ParentDocumentRetriever

from langchain.storage import InMemoryStory

Self-Querying

• 시맨틱 검색 말고 쿼리가 필요할 때
• 문서가 갖고 있는 metadata를 기반으로 필터링을 생성해서, 더 정확한 답변을 가능하도록 만드는 retriever

• 평점, 장르 필터링이 필요함

[주의할 점]

필터링이 필요한 query에 적합한 retreiver (excel, csv..)

from langchain.retrievers.self_query_base import SelfQueryRetriever

[결과]

Time-weighted

• 오래된 자료는 덜 참고했으면 할 때
• 시간에 가중치

사용자 질문: 평점이 9점 이상인 영화 중에 SF 영화를 추천해줄래?

사용자의 속마음: 최신 영화 중에 + 평점 9점 이상 + SF 영화

⇒ Document 중에서 최근 이용된 영화 위주로 추천

⇒ 시간이 지난 만큼 패널티를 주자!

(semantic_similarity + (1.0 - decay_rate) ^ 경과한 시간*)

from langchain.retrievers import TimeWeightVectorStoreRetriever

[주의해야할 점]

decay_rate에 따라서 답변이 완전 달라짐

decay_rate = 0.01일 경우

• decay_rate를 적게 줌으로써, 시간이 오래됐더라도 상관없어. 유사한 것을 우선으로 찾아

decay_rate = 0.99 일 경우

• decay_rate를 너무 높게 주면, 문장이 유사하던지 말던지, 가장 최근값만 가져옴

Ensemble Retriever

• Retriever + Dense Retrieve

비타민 B1, 비타민 B2, 비타민 B3에 대한 document 중에 비타민 B1에 관한 정보만 원한다면 sparse Retriever + Dense Retriever 필요

ex) BM25(키워드 검색) + FAISS(맥락 검색) = Hybrid Search

Retrive된 결과를 재정렬하는 Reciprocal Rank Fusion으로 더욱 좋은 참고문서 생성

Long Context Reorder

• RAG의 Source Document가 많을 경우, 중간 순서는 무시되는 경우가 많음
• context의 중간에 위치한 참고문서는 무시하는 경향
• → 연관성이 높은 문서는 일부로 맨앞과 맨뒤에 Reorder

[결과]

Reranker란?

Reranker는 retriever가 찾아낸 문서들의 순위를 재조정하여 질문과 가장 유사도가 높은 문서를 추출하는 것이 목표

작동 원리

1. 문서들을 준비한다.
2. Retriever를 이용해 관련 문서 결과를 받는다.
3. 검색된 문서를 Reranker를 통해서 다시 재순위를 매긴다.

Retriever과 Reranker 동작방식

Retriever의 동작방식

Retriever는 질문과 문서에 대한 독립적인 임베딩을 활용하는 **Bi-encoder** 방식을 사용하고 있다.
Bi-encode 방식은 질문과 문서를 각각 임베딩한 후 유사도를 계산하여 문서와 가장 유사한 top k개의 문서를 선택한다.

정리하자면

1. 질문과 문서를 각각 임베딩한다. (벡터로 인코딩)
2. 벡터 간의 유사도를 계산하여 질문과 문서 사이의 관련성 측정
3. 유사한 상위 k개의 문서 도출

Reranker 동작방식

Reranker는 질문과 문서를 하나의 input으로 활용하는 **Cross-encder**방식을 사용하고 있다. Reranker는 질문과 문서를 하나의 input으로 활용함으로써, 독립적인 임베딩 벡터 기반의 Bi-encoder 방식보다 **정확한 유사도 측정**이 가능하다는 장점을 가지고 있다.

Retriever과 Reranker를 모두 사용하는 이유

Reranker가 Retriever보다 더 정확한 유사도 측정이 가능하다면, Reranker 하나만 사용하면 안 되는 건가?

라고 생각했다면 지니어스

질문과 문서를 동시에 input으로 활용하는 Reranker의 특성상, 사용자가 질문을 하는 시점에서 모든 문서에 대한 질문과의 유사도를 측정한다. 가진 문서가 많다면 굉장히 오래 걸릴 수밖에 없는 구조이다.
(이와 관련해서 Sentence-BERT에서 4천만 개 문서에 대해 V100 GPU 기반으로 연관성 측정을 수행한 결과 약 50시간이 소요됐다고 한다.)

사용자가 질문했는데 50시간 뒤에 답을 주면..^^

그렇기 때문에 Retriver과 Reranker를 two-stage로 적용할 수 있다.
정확도는 낮지만 계산 비용이 낮고 빠르게 검색 가능한 Retrieval로 먼저 검색한 후 Reranker로 유사도를 다시 측정하게 된다. 이렇게 되면 문서의 검색 속도를 높이면서(Retriever) 질문과 관련성을 정확히 측정(Rerankr)하는 것이 가능해진다.

Retrieval vs Reranker

Retrieval

- 계산 비용이 상대적으로 낮음
- 빠르게 검색 가능
- 그러나, 정확도가 낮음

Reranker

- 계산 비용이 높음
- 질문과 문서를 동시에 input으로 사용하기 때문에 연산이 굉장히 오래 걸림
- 그러나 Retrieval기반으로 측정했을 때보다 정확도가 높음

전략적 방법

1. Retriever를 통해서 문서 50개(최대한 많이) 검색한다.
2. 최대한 많이 검색된 결과를 다시 Reranker를 통해서 재순위 측정
3. 상위 k개의 문서를 추출

참고