Chapter 05 · CAG

CAG: 미리 다 읽어 두기

4장에서 본 것처럼, RAG의 실수는 대부분 검색에서 나온다. 그렇다면 자료가 충분히 작을 때는 검색을 아예 빼면 어떨까? CAG(Cache-Augmented Generation, 캐시 증강 생성)는 자료 전체를 미리 읽혀 두고, 그 ‘읽은 상태’를 저장해 재사용한다.

CAG = 얇은 교재를 시험 전에 통째로 외워 두기. 자료 전체를 컨텍스트 창에 넣어 한 번 읽히고(prefill), 그 결과인 KV 캐시를 저장해 질문마다 불러 쓴다. 검색 실수가 없고 빠르지만, 창에 들어갈 만큼 작고 잘 안 바뀌는 자료에만 맞는다.

아이디어: 검색을 빼 버리자

오픈북 vs 미리 외우기

RAG 학생은 문제가 나올 때마다 두꺼운 책에서 관련 쪽을 찾는다. 찾는 데 시간이 들고, 엉뚱한 쪽을 펴면 틀린다. CAG 학생은 얇은 요약 노트를 시험 전에 한 번 꼼꼼히 읽어 머릿속에 정리해 둔다. 문제가 나오면 찾을 필요 없이 바로 답한다. 노트가 얇아야만 가능한 방법이다.

CAG라는 이름과 방법은 2024년 말 논문 “Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks”(Chan 외)에서 정리되었다. 긴 컨텍스트를 처리할 수 있는 LLM이 늘어나면서, 자료가 창 안에 들어가는 경우에는 검색 없이도 충분하다는 주장이다. 논문의 실험(SQuAD, HotPotQA 등)에서는 RAG와 비슷하거나 더 나은 정확도를 보이면서 답 생성 시간이 크게 줄었다고 보고했다.

CAG의 전체 흐름

3장의 RAG 흐름과 비교해 보자. 조각내기, 임베딩, 벡터 저장소, 검색이 모두 사라졌다. 대신 KV 캐시라는 새 상자가 생겼다.

COMPARE

같은 질문, RAG(k=3) vs CAG

위 흐름의 질문 칩을 바꾸면 이 표도 바뀐다. ‘질문마다 새로 읽는 토큰’에서 CAG는 질문만 읽는다. 자료는 이미 캐시에 있다.

KV 캐시: ‘읽은 상태’를 저장한다는 것

LLM은 글을 읽을 때 토큰마다, 층(layer)마다 두 가지 메모를 만든다. “이 토큰은 어떤 내용과 관련 있나”를 나타내는 Key, “이 토큰이 전하는 내용”인 Value다. 뒤에 오는 토큰은 앞 토큰들의 Key·Value를 참고해 의미를 파악한다.

책갈피와 메모

책을 읽으면서 쪽마다 포스트잇 메모를 붙여 두면, 다음에 질문을 받았을 때 책을 처음부터 다시 읽지 않고 메모만 훑어도 된다. KV 캐시가 그 포스트잇 묶음이다. 같은 자료를 매번 다시 읽는 대신 메모를 꺼내 쓰는 것, 그것이 CAG의 속도 비결이다.

SIMULATOR

KV 캐시 채우기 — 한 칸 = 약 5토큰

캐시된 자료질문·답 (새로 계산)RAG: 매번 새로 읽는 검색 조각빈 창
이번에 새로 계산한 토큰
누적 계산 토큰
답한 질문 수
①을 눌러 자료를 캐시에 올리자. 그다음 ②와 ③을 여러 번 번갈아 눌러 보면, 질문마다 새로 계산하는 양이 아주 적다는 것을 볼 수 있다. ‘비교: RAG’는 질문마다 검색 조각 k개를 새로 읽는다.

언제 이득일까: 비용·메모리 계산기

CAG는 처음에 자료 전체를 한 번 읽는 비용을 치르고, 이후 질문마다 아낀다. 질문이 많을수록 이득이 커진다. 상용 API에서는 이 아이디어가 프롬프트 캐싱이라는 기능으로 제공된다. 반복되는 앞부분(자료)을 캐시해 두면 다시 읽을 때 기본 입력 가격보다 훨씬 싸게(예: 일부 서비스는 약 1/10) 계산한다. 정확한 가격과 조건은 서비스마다 다르다.

SIMULATOR

누적 입력 처리량 — 질문 수가 늘어날 때

창에 들어가나
CAG가 RAG보다 싸지는 지점
KV 캐시 (8B급)
KV 캐시 (70B급)
세로축은 ‘입력 토큰 처리량’을 비용처럼 센 값이다(질문 30토큰, RAG 조각 하나 300토큰 가정). 매번 통째로 = 캐시 없이 질문마다 자료 전체를 다시 읽는 경우. KV 캐시 크기는 토큰당 2(K,V) × 층 수 × KV 헤드 수 × 헤드 차원 × 2바이트(fp16)로 계산했다: 8B급(32층·8헤드·128차원) 토큰당 128 KiB, 70B급(80층) 320 KiB. 교육용 모형이며, 실제 비용은 모델·하드웨어·요금제에 따라 다르다.
계산기로 확인할 것
  • 자료가 작고 질문이 많으면 CAG 선이 RAG 선보다 아래로 내려간다(더 싸다).
  • 캐시 재사용 비용을 1로 올리면(캐시 없음) CAG는 ‘매번 통째로’와 같아진다. 캐시가 핵심이다.
  • K를 수십만 토큰 이상으로 올리면 창을 넘거나 KV 캐시가 수십 GiB가 된다. 여기서 CAG는 멈추고 RAG·KAG의 차례가 된다.

CAG가 맞는 곳, 맞지 않는 곳

잘 맞는다

  • 제품 설명서, 사내 규정집, FAQ처럼 작고 고정된 자료
  • 같은 자료에 질문이 아주 많이 오는 서비스
  • 여러 문장을 엮어야 하는 질문(전부 보고 있으므로)
  • 검색 시스템을 따로 운영하기 싫을 때

맞지 않는다

  • 자료가 창보다 크다 (회사 위키 전체, 수천 개 문서)
  • 자료가 자주 바뀐다 — 바뀔 때마다 캐시를 새로 만들어야 함
  • 사용자마다 볼 수 있는 자료가 다르다(권한)
  • 창이 아주 길면 모델이 중간 내용을 놓치기 쉬워진다
둘을 섞을 수도 있다

자주 쓰는 핵심 자료(규정 요약, 용어집)는 CAG처럼 캐시해 두고, 나머지 방대한 자료는 RAG로 찾아 덧붙이는 하이브리드가 실무에서 흔하다. 8장에서 다시 다룬다.

핵심 정리

  1. CAG = 검색 없이 자료 전체를 미리 컨텍스트에 넣고, 그 KV 캐시를 저장해 질문마다 재사용.
  2. KV 캐시 = 모델이 글을 읽으며 토큰·층마다 만든 Key·Value 메모. 다시 읽지 않아도 되게 해 준다.
  3. 장점: 검색 실수 없음, 질문당 빠른 응답, 단순한 구조. 질문이 많을수록 이득.
  4. 한계: 창 크기, 큰 KV 캐시 메모리, 자료가 바뀌면 캐시 재생성, 긴 문맥에서의 주의력 저하.
  5. 상용 API의 프롬프트 캐싱은 CAG를 쉽게 쓰는 실용적인 방법이다.

확인 퀴즈