CAG: LLM의 근거를 마련하는 더 간단한 방법
요약
RAG의 대안으로 떠오르는 캐시 증강 생성(CAG) 방식을 소개합니다. 컨텍스트 창이 확장됨에 따라 검색 과정 없이 지식을 컨텍스트에 직접 로드하여 사용하는 CAG의 개념과 장점을 설명합니다.
핵심 포인트
- CAG는 검색 단계 없이 지식을 컨텍스트에 캐싱하여 사용함
- RAG 대비 낮은 지연 시간과 단순한 아키텍처가 강점
- 방대한 지식 베이스나 실시간 데이터는 RAG가 유리
- 정적이고 컨텍스트 창에 들어오는 규모의 데이터는 CAG가 효율적
최근 AI 애플리케이션을 구축해 보셨다면, 아마 **검색 증강 생성 (Retrieval-Augmented Generation, RAG)**을 접해 보셨을 것입니다. 이는 LLM에 외부 지식에 대한 접근 권한을 부여하는 가장 일반적인 방법이 되었습니다.
하지만 RAG가 유일한 선택지는 아닙니다.
컨텍스트 창 (Context window)이 계속해서 커짐에 따라, 또 다른 접근 방식이 점점 더 실용적으로 변하고 있습니다. 바로 **캐시 증강 생성 (Cache-Augmented Generation, CAG)**입니다.
시작하기 전에 짧은 면책 조항을 말씀드립니다. 이 글은 의도적으로 CAG의 입장을 옹호합니다. RAG가 잠시 커피를 마시러 간 사이, CAG가 드디어 발언 기회를 얻는 친근한 토론이라고 생각해주세요.
RAG가 왜 그렇게 인기를 얻었는가
RAG는 실제 문제를 해결했습니다.
LLM이 모든 것을 알기를 기대하는 대신, 우리는 정보를 벡터 데이터베이스 (Vector database)에 저장합니다. 사용자가 질문을 하면, 가장 관련 있는 조각들을 검색하여 모델에 전달합니다.
전형적인 RAG 파이프라인은 다음과 같습니다:
질의 (Query) → 임베딩 (Embed) → 검색 (Search) → 순위 매기기 (Rank) → 검색 (Retrieve) → 생성 (Generate)
이는 검증된 접근 방식이며, 특히 지식 베이스가 방대하거나 자주 변경되는 경우 매우 효과적입니다.
유일한 단점은 모델이 답변을 생성하기 전에 모든 질문이 이 검색 과정을 거쳐야 한다는 점입니다.
이는 더 많은 인프라, 더 많은 구성 요소, 그리고 약간의 추가적인 지연 시간 (Latency)을 의미합니다.
CAG 소개
CAG는 훨씬 더 간단한 접근 방식을 취합니다.
누군가 질문할 때마다 정보를 검색하는 대신, 필요한 지식을 모델의 컨텍스트 (Context)에 한 번 로드하여 계속 사용하는 방식입니다.
워크플로우는 다음과 같습니다:
지식 로드 (Load knowledge) → 컨텍스트 캐싱 (Cache context) → 생성 (Generate)
이것이 핵심 아이디어의 전부입니다.
벡터 검색 (Vector search)도 없습니다.
검색 (Retrieval) 단계도 없습니다.
순위 매기기 (Ranking)도 없습니다.
모델은 이미 필요한 정보를 가지고 있습니다.
이것이 왜 지금 가능한가?
몇 년 전만 해도 CAG는 실용적이지 않았습니다.
컨텍스트 창 (Context windows)이 너무 작았기 때문입니다.
하지만 오늘날에는 더 이상 그렇지 않습니다.
많은 현대적 모델들이 수십만, 때로는 수백만 토큰 (Tokens)을 지원합니다.
이로 인해 질문의 성격이 다음과 같이 바뀝니다:
"어떻게 하면 올바른 문서를 검색할 수 있을까?"
에서
"내 지식을 컨텍스트 창에 다 담을 수 있을까?"로 말입니다.
많은 내부 도구, 회사 문서, 온보딩 가이드, 제품 매뉴얼 및 API 레퍼런스의 경우, 그 대답은 놀랍게도 자주 **'예'**입니다.
RAG vs CAG
두 접근 방식은 동일한 문제를 해결하지만, 방식은 다릅니다.
RAG를 선택해야 하는 경우:
- 지식 베이스 (Knowledge base)가 모델의 컨텍스트 (Context)에 담기에는 너무 큰 경우.
- 정보가 빈번하게 변경되는 경우.
- 사용자마다 서로 다른 지식의 하위 집합 (Subsets)이 필요한 경우.
- 실시간 데이터가 필요한 경우.
CAG를 선택해야 하는 경우:
- 문서가 컨텍스트 창 (Context window)에 여유롭게 들어가는 경우.
- 대부분의 정보가 비교적 정적인 경우.
- 낮은 지연 시간 (Low latency)이 중요한 경우.
- 구성 요소가 적은 더 단순한 아키텍처 (Architecture)를 원하는 경우.
어느 한 쪽이 더 "낫다"고 할 수는 없습니다.
올바른 선택은 사용 사례 (Use case)에 달려 있습니다.
간단한 예시
전통적인 RAG 파이프라인 (Pipeline)은 다음과 같을 수 있습니다:
query = "우리 환불 정책은 무엇인가요?"
embedding = embed(query)
...
CAG 구현은 훨씬 더 간단합니다:
with open("knowledge_base.txt") as f:
knowledge = f.read()
...
가장 큰 차이점은 코드의 양이 아닙니다.
추론 (Inference) 과정 중에 검색 (Retrieval)이 일어나지 않는다는 점입니다.
둘 다 사용하면 안 되나요?
실제로 많은 애플리케이션은 하나를 다른 하나보다 우선하여 선택할 필요가 없습니다.
하이브리드 (Hybrid) 접근 방식이 종종 가장 효과적입니다.
CAG를 사용하여 안정적인 문서를 모델의 캐시된 컨텍스트 (Cached context)에 유지하세요.
RAG를 사용하여 빈번하게 변경되는 정보만 검색하세요.
이렇게 하면 대부분의 질문에 대해 빠른 응답을 제공하면서도, 필요할 때마다 최신 정보에 접근할 수 있습니다.
마치며
개발자로서 우리는 때때로 모든 LLM 애플리케이션에 벡터 데이터베이스 (Vector database)가 필요하다고 가정하곤 합니다.
하지만 그것이 항상 사실인 것은 이제 아닙니다.
RAG 파이프라인을 구축하기 전에, 스스로에게 한 가지 간단한 질문을 던져보세요:
내 지식 베이스가 실제로 모델의 컨텍스트 창 안에 들어가는가?
만약 그렇다면, CAG는 구축하기 더 쉽고, 유지보수하기 더 쉬우며, 종종 더 빠르게 서비스할 수 있는 더 간단한 솔루션이 될 수 있습니다.
만약 그렇지 않다면, RAG는 여전히 훌륭한 선택입니다.
목표는 RAG를 대체하는 것이 아닙니다.
그것은 현대의 컨텍스트 윈도우 (context windows)가 가능하게 하는 것들을 변화시켰음을 인식하는 것이며, CAG가 논의의 장에서 자리를 차지할 가치가 있다는 것을 의미합니다.
요약 (TL;DR)
- RAG는 매 쿼리 (query) 전에 관련 정보를 검색 (retrieves) 합니다.
- CAG는 지식을 모델의 컨텍스트 (context)에 미리 로드합니다.
- 현대의 컨텍스트 윈도우 (context windows)는 많은 유스케이스 (use cases)에서 CAG를 실용적으로 만듭니다.
- 만약 당신의 지식이 컨텍스트 (context) 안에 들어간다면, 벡터 데이터베이스 (vector database)를 찾기 전에 CAG를 고려해 볼 가치가 있습니다.
- 대규모이거나 빈번하게 변경되는 지식 베이스 (knowledge bases)의 경우, RAG가 여전히 더 나은 선택입니다.
때로는 가장 단순한 아키텍처 (architecture)가 모델의 방해를 하지 않는 아키텍처입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기