Chapter 08
무엇을 언제 쓸까
네 가지를 모두 배웠다. 실제로는 “어느 것이 최고인가”보다 “내 자료와 내 질문에는 무엇이 맞나”가 중요하고, 하나만 고르기보다 섞어 쓰는 경우가 많다.
자료가 작고 고정 → CAG. 자료가 크거나 자주 바뀜 → RAG. 여러 사실을 이어야 하고 정확한 관계가 중요 → KAG. 답이 글이 아니라 프로그램이 쓸 결정이어야 함 → Jev를 앞의 것들 위에 얹는다.
- 네 방식을 자료 크기, 갱신 빈도, 질문 종류, 출력 형태로 비교할 수 있다.
- 주어진 상황에 맞는 방식(또는 조합)을 고르고 이유를 말할 수 있다.
네 방식 비교표
| 기준 | RAG | CAG | KAG | Jev |
|---|---|---|---|---|
| 한 줄 비유 | 사서가 관련 쪽을 찾아 줌 | 얇은 노트를 미리 외움 | 탐정의 관계도 | OMR 카드 |
| 미리 하는 일 | 조각내기·임베딩·저장 | 자료 전체 prefill → KV 캐시 | 트리플 추출·그래프 구축·정렬 | (없음) 선택지 설계 |
| 질문마다 하는 일 | 검색 + 프롬프트 조립 + 생성 | 캐시 불러오기 + 생성 | 계획 + 그래프 탐색 + 생성 | 선택지별 확률 계산 |
| 자료 크기 | 거의 무제한 | 컨텍스트 창 이하 | 크게 가능 (구축 비용 비례) | 요청당 입력 제한 안 |
| 자료 갱신 | 쉬움 (바뀐 조각만) | 캐시 재생성 필요 | 그래프 갱신 필요 | 해당 없음 |
| 다단계 질문 | 약함 | 가능 (다 보고 있음) | 강함 | 질문 하나 = 결정 하나 |
| 응답 속도 | 보통 (검색 포함) | 빠름 | 느린 편 (여러 단계) | 매우 빠름 (회사 발표) |
| 설명 가능성 | 출처 조각 | 약함 (전체를 봄) | 추론 경로 + 출처 | 확률 (근거는 따로) |
| 구축 난이도 | 보통 | 쉬움 | 어려움 | 쉬움 (API 호출) |
| 출력 | 글 | 글 | 글 | 확률·선택 |
상황별 추천 마법사
내 상황을 고르면 점수와 이유가 바로 바뀐다. 점수는 이 교재의 경험 규칙을 숫자로 옮긴 것으로, 정답이라기보다 생각의 출발점이다.
SIMULATOR
내 프로젝트에는 무엇이 맞을까
① 자료의 양은?
② 자료가 얼마나 자주 바뀌나?
③ 주로 어떤 질문인가?
④ 결과를 누가 쓰나?
⑤ 가장 중요한 것은?
섞어 쓰기: 한 서비스 안의 네 방식
실제 사내 도우미를 만든다면 이렇게 될 수 있다. 질문이 들어오면 Jev가 종류를 가르고, 종류에 맞는 길로 보낸 뒤, 마지막에 다시 Jev가 답을 검사한다. 질문 칩을 바꿔 가며 길이 어떻게 달라지는지 보자.
기억할 경험 규칙
먼저 CAG를 의심하라
자료가 창에 들어가고 잘 안 바뀐다면, 검색 시스템을 만들기 전에 통째로 넣어 보자. 상용 API의 프롬프트 캐싱으로 비용도 줄일 수 있다.
크고 변하면 RAG
대부분의 실무 출발점. 4장의 손잡이(조각·k·하이브리드·재순위화)를 차근차근 맞춘다.
관계가 핵심이면 KAG
“누가 누구의 무엇”을 여러 번 따라가야 하고 틀리면 곤란한 분야라면, 그래프를 만드는 비용을 감수할 가치가 있다.
결정은 Jev 방식으로
분기·분류·점수가 필요하면 긴 글 대신 확률을 받고, 보정과 임계값으로 사람과 일을 나눈다.
핵심 정리
- RAG·CAG·KAG는 ‘무엇을 어떻게 읽힐까’, Jev는 ‘결과를 어떤 모양으로 받을까’의 선택이다.
- 자료 크기와 갱신 빈도가 RAG vs CAG를, 질문의 연결 깊이가 KAG 여부를 가른다.
- 실무에서는 조합이 흔하다: 핵심 자료 캐시 + 검색, 그래프 + 검색, Jev 라우팅·검사.