RAG와 CAG 비교 설명

표준 RAG(Retrieval-Augmented Generation) 설정에서는 제품 매뉴얼이나 정책 문서 등 몇 달 동안 변경되지 않은 내용에 대한 질의까지 모든 쿼리가 벡터 DB를 조회합니다.

이러한 검색 과정은 지연 시간(latency)을 추가하며, 이후 모델은 동일하게 검색된 청크들을 매번의 후속 쿼리에서 다시 프리필(prefill) 합니다.

CAG는 이러한 벡터 검색 과정을 생략하고 프리필 작업을 쿼리 경로에서 분리하는 기법입니다.

이 전처리 단계에서는 어떤 질의가 도착하기 전에 해당 문서들을 모델을 통해 한 번 실행하며, 모든 레이어의 모든 토큰에 대한 키(key)와 값(value) 텐서를 저장합니다. 이후 질의 시점에는 모델이 이 상태를 로드하고, 벡터 검색이나 지식 기반의 프리필 없이 디코딩을 시작합니다.

캐시로 저장할 수 있는 컨텍스트 양은 모델의 컨텍스트 길이(context length)에 의해 제한되는 것이 아니라 GPU 메모리에 의해 제한됩니다. 예를 들어, BF16으로 작동하는 70B 모델의 경우 캐시는 토큰당 약 300 KB가 소요되므로, 작은 코퍼스만으로도 관리할 수 있는 수십 GB의 캐시를 생성할 수 있습니다.

이것이 바로 프로덕션 환경에서 RAG와 CAG를 함께 사용하는 이유입니다.

↳ 거의 모든 질의가 읽는 정적이고 가치 높은 지식(예: 정책, 제품 문서, 표준 지침)은 한 번에 캐싱됩니다.

↳ 그 외의 모든 것은 벡터 DB에 남아있습니다. 왜냐하면 천 개의 질의 중 단 하나의 질의에서만 등장하는 문서는 하루 종일 GPU에 텐서를 유지할 만큼 충분한 가치를 가지지 못하기 때문입니다.

아래 다이어그램이 이를 보여줍니다.

실제 적용을 위해서는 커스텀 서빙 스택(serving stack)을 구축할 필요가 없습니다. transformers 라이브러리 자체가 보존할 수 있는 KV 벡터 객체 형태로 캐시를 구현했기 때문에, 코퍼스를 한 번 프리필하고 반환된 텐서를 유지한 다음 약 10줄의 코드로 쿼리 전반에 걸쳐 재사용할 수 있습니다.

그리고 이 KV 캐시는 LLM 스택에서 존재하는 네 가지 별개의 캐싱 레이어 중 하나일 뿐입니다. 나머지 세 가지는 서버 측 프리픽스 캐싱(prefix caching), 제공업체별로 청구되는 프롬프트 캐싱(prompt caching), 그리고 모델 자체를 완전히 건너뛰는 시맨틱 캐시(semantic cache)입니다.

AI 엔지니어로서 알아야 할 네 가지 캐시에 대한 전체 분석과 각 케이스의 코드를 LLM serving에 작성했습니다. 아래에서 읽어보세요.