"RAG 핵심 학습 (1/26) — RAG가 무엇이고 왜 필요한가"

-

시리즈의 핵심 한 줄 — "질문에 맞는 근거를 정확히 찾고, 그 근거 밖으로 나가지 않는 답변을 만드는 것."

이 시리즈는 RAG(Retrieval-Augmented Generation)를 직접 만들고 운영해야 하는 사람을 위해 26편으로 설계되었다. 1편의 목표는 단순하다. RAG가 무엇이고, 왜 등장했고, 언제는 안 쓰는 게 맞는가를 한 자리에서 정리한다. 코드는 한 호출에 그치고, 수식은 Lewis 2020의 원공식 하나만 본다. 그 자리에서 "왜 RAG가 필요한가"가 손에 잡혀야 다음 25편의 모든 결정 — 청킹·임베딩·하이브리드·리랭커·라우팅 — 의 기준이 생긴다.

0. Prerequisites — 미리 알아야 할 것

본 편을 편하게 읽으려면 다음 세 가지는 익숙해야 한다. 없어도 이해는 되지만, 있으면 "왜 그런 결정을 했는지"가 더 빨리 들어온다.

  • Tokenization: 모델이 텍스트를 받기 전에 토큰(서브워드 단위)으로 자르는 과정. AI 입문 (1/11) LLM 기본 개념 2026 또는 LLM 핵심 학습 (1/6) 토큰화·임베딩·어텐션·위치 인코딩에서 자세히 다뤘다.
  • Context Window: 모델이 한 번에 보는 토큰 길이의 상한(요즘은 8K~1M까지). 본 편의 핵심 비교점인 "long-context vs RAG"는 이 상한과 직접 연결된다.
  • Hallucination(환각): 모델이 그럴듯하지만 사실과 다른 답을 만드는 현상. RAG가 환각을 완전히 없애는 도구가 아니라는 점이 8장에서 다시 나온다.

이 셋은 한 줄짜리 정의만 알아도 충분하다. 본 편은 그 정의 위에서 RAG의 5요소라는 다른 추상 계층을 쌓는다.

1. 학습 목표

이 글이 끝나고 나면 세 가지를 자신의 말로 설명할 수 있어야 한다.

  1. RAG의 5요소 — Retriever / Generator / Knowledge Base / Context / Grounding — 을 한 줄씩 정의하고, 그 다섯이 어떻게 묶여 한 답을 만드는지를 설명한다.
  2. RAG가 등장한 이유 — LLM의 가중치 안에 못 들어간 지식(최신·내부 문서·법령)과 근거 없이 자신감 있게 답하는 환각 — 두 문제를 동시에 줄이는 구조라는 점을 짚는다.
  3. RAG를 안 쓰는 게 맞는 경우 — 도메인이 좁고, 검색 비용 대비 long-context로 충분한 경우, 그리고 근거 추적성이 필요 없는 일회성 답변. 이 세 신호를 알아본다.

세 가지 목표는 본 시리즈 26편 전체의 출발점이다. 어떤 청킹 전략을, 어떤 임베딩을, 어떤 벡터DB를 고르더라도 "왜 RAG였는가"가 답해지지 않으면 그 결정들은 이유 없는 비용이 된다.

2. 핵심 요약 — 한 단락 요약

RAG는 Retrieval-Augmented Generation의 약자다. 한 줄: "질문에 맞는 외부 문서를 찾아 LLM이 그 안에서만 답하게 만드는 구조." 등장 배경은 두 가지다. 첫째, 모델 학습 시점 이후에 만들어진 지식 — 어제의 사내 문서, 오늘의 법령 개정, 30분 전 회의록 — 은 LLM의 가중치 안에 들어가지 못한다. 둘째, 같은 모델이 근거가 없을 때도 자신감 있게 그럴듯한 답을 만든다. 환각이다. RAG는 "검색 → 그 결과를 컨텍스트에 끼우고 → 그 안에서만 답하라"는 한 줄 처방으로 두 문제를 동시에 줄인다. 단, 검색 자체가 틀리면 환각은 사라지지 않고 더 그럴듯해진다. 그래서 본 시리즈의 25편이 "검색을 어떻게 정확하게 만들 것인가"에 집중한다.

3. 직관 — 책상 학생과 도서관 학생

같은 시험 문제를 두 학생이 푼다고 하자.

  • 학생 A(LLM 단독, parametric memory): 책상 위에 자기가 평소 외워 둔 노트 한 권만 있다. 빠르고, 자기 영역 안에서는 정확하다. 그러나 노트에 없는 질문이 나오면 "기억이 안 나서 모른다"라고 말하지 못하고 지어낸다. 그게 환각이다.
  • 학생 B(RAG): 같은 노트를 가지고 있지만, 시험 중 도서관에 가서 관련 책을 펼쳐서 확인하고 돌아온다. 시간이 더 걸리고, 도서관에서 엉뚱한 책을 가져오면 잘못된 답을 자신감 있게 적는다. 그러나 자기가 모르는 영역에서도 근거 있는 답을 만들 가능성이 생긴다.

RAG의 본질은 "책상만 보던 학생을 도서관에 다녀오는 학생으로 바꾸는 일"이다. 다만 "어느 책장으로 갈 것인가"·"어떤 책을 펼칠 것인가"·"펼친 페이지 중 어디를 읽을 것인가"가 모두 별도의 결정이다. 본 시리즈 26편은 그 결정들의 트리를 한 갈래씩 푸는 작업이다.

34장 핵심 메시지 인용: "질문에 맞는 근거를 정확히 찾고, 그 근거 밖으로 나가지 않는 답변을 만드는 것." — 이 한 줄이 모든 결정의 위에 놓인다.

학생 비유는 다음 그림처럼 단순하게 그릴 수 있다.

diagram-1

같은 모델을 쓰는데도 답이 달라진다. 모델이 아니라 답 만드는 절차를 바꾼 것이다. RAG는 절차의 디자인이다.

4. 정의 — RAG의 5요소

Lewis et al. 2020의 RAG 원논문이 정의한 구조를 다섯 단어로 정리한다.

요소 한 줄 정의 1차 자료
Retriever Query를 받아 관련 있는 top-K 문서를 반환하는 함수 Lewis 2020 2장
Generator (Query + Context)를 입력 받아 답을 만드는 LLM Lewis 2020 2장
Knowledge Base 외부 문서·임베딩 인덱스가 들어 있는 저장소 Khandelwal 2020 1장
Context Generator 입력에 끼어 들어가는 발췌. 보통 top-K 문서의 본문 일부 Liu 2023 2장
Grounding 답이 근거 안에 머무는 성질. "근거 밖으로 안 나가는" 행동 규약 Asai 2023 3장

다섯 요소는 따로따로 분리되지 않는다. 한 흐름으로 묶여 한 답을 만든다.

diagram-2

가장 자주 놓치는 점이 Knowledge Base와 Context의 차이다. Knowledge Base는 저장이고 Context는 발췌다. 검색이 "어디서 가져올 것인가"라면, 컨텍스트 조립은 "그 중 어떤 발췌를 어느 순서로 넣을 것인가"다. 둘은 비용도, 실패 양상도 다르다. 8.1절 Lost in the Middle은 Context 측 실패에 가깝다.

또 하나 자주 묻는 질문은 "Grounding을 어떻게 코드로 강제하는가"이다. 답: 강제하지 못한다. Generator는 여전히 LLM이고, 컨텍스트 밖의 가중치 기억을 끌어다 답할 수 있다. 그래서 RAG에서 프롬프트 설계("주어진 컨텍스트 밖의 정보는 사용하지 마라"), 근거 인용(인용 출처를 답에 포함시키게 하기), 검증 단계(Self-RAG, Corrective RAG 등)가 따로 필요하다. 본 시리즈 22편(Corrective RAG)·23편(Graph)·24편(Agentic)이 이 문제를 깊이 다룬다.

5. 수식 — Lewis 2020 한 줄

RAG 원논문이 정의한 답의 확률 분포는 다음과 같다.

$$P(y \mid x) = \sum_{z \in \text{top-K}(x)} P_\eta(z \mid x) \cdot P_\theta(y \mid x, z)$$

  • \(x\) = 입력 질문(Query)
  • \(z\) = 검색된 문서(Document)
  • \(y\) = 답(Answer)
  • \(P_\eta(z \mid x)\) = Retriever가 매기는 "이 문서가 이 질문에 얼마나 관련 있는가"의 확률
  • \(P_\theta(y \mid x, z)\) = Generator가 매기는 "이 질문과 이 문서가 주어졌을 때 이 답을 낼 확률"

핵심 한 줄: 답은 retriever와 generator의 곱에 대한 top-K의 합으로 분해된다. 두 모델은 각자 학습되거나 같이 학습될 수 있고, 같이 학습할 때 RAG-Token / RAG-Sequence 두 변형이 나뉜다. RAG-Token은 토큰 단위로 위 합을 다시 적용해 토큰마다 어떤 문서를 볼지 바꾼다. RAG-Sequence는 한 답 전체에 대해 한 번의 문서 선택을 한다. 두 변형의 trade-off는 Lewis 2020 4장 표 2에서 확인할 수 있다.

식 자체는 단순하지만, 본 시리즈의 거의 모든 후속 편이 이 식의 어디를 개선하는가로 정리된다.

  • Retriever(\(P_\eta\)) 측 개선: 7~11편(임베딩·벡터DB·Dense·BM25), 12편(Reranker), 17~21편(Query 처리·Dynamic).
  • Generator(\(P_\theta\)) 측 개선: 22편(Corrective), 24편(Agentic verification).
  • top-K 선택: 21편(Adaptive Top-K).
  • 합 자체의 효율화: RAG-Token vs RAG-Sequence는 본 시리즈에서 깊이는 다루지 않는다. 본 시리즈의 25편은 retrieve-then-read 패러다임에 집중한다.

곱-합 구조의 한 가지 부작용은 "Retriever가 자신감 있게 틀린 문서를 가져오면, Generator의 자신감도 함께 올라간다"는 점이다. 8.2절에서 다시 본다.

6. 원리 워크스루 — 한 질의가 답이 되기까지

코드는 일부러 한 줄로 줄였다. 학습 시리즈 v3 기준 — 원리 워크스루는 코드가 아니라 알고리즘의 한 줄 해부다.

answer = generator(prompt, context=retriever(query, k=5))

이 한 줄 안에서 실제로 일어나는 일은 여섯 단계다.

  1. 정규화(Normalization). Query에서 따옴표·기호·여백을 정리하고, 도메인에 따라 약어를 풀거나 단위를 정규화한다. 18편 Query Rewrite로 깊어진다.
  2. 임베딩(Embedding). 정규화된 Query를 임베딩 모델로 d-차원 벡터로 바꾼다. 8편 임베딩 모델 비교에서 다룬다.
  3. 검색(Search). Knowledge Base 안의 모든(또는 사전 필터링된) 문서 벡터에 대해 유사도 상위 K개를 뽑는다. Dense는 코사인 유사도, Sparse는 BM25 점수, Hybrid는 둘을 섞은 점수. 9·10·11·12편이 이 단계.
  4. 랭킹(Reranking) — 선택 사항. top-K를 cross-encoder가 다시 정렬해 top-K'(보통 K보다 작은 K')만 남긴다. 13편 Reranker 편.
  5. 컨텍스트 조립(Context Assembly). 남은 문서들을 어떤 순서로, 어떤 형식으로, 얼마나 잘라서 프롬프트에 끼울지 정한다. Lost in the Middle을 피하려면 가장 관련 있는 문서를 양 끝에 둔다는 경험칙이 있다(Liu 2023).
  6. 생성(Generation). (시스템 프롬프트 + 컨텍스트 + Query)를 한 묶음으로 LLM에 넣어 답을 만든다. 답이 근거 안에서만 머물도록 "주어진 컨텍스트 밖의 사실은 쓰지 마라" 같은 지시를 시스템 프롬프트에 넣는 경우가 많다.

각 단계가 나중에 어떤 편에서 깊어지는지를 다시 한 번 정리하면 다음과 같다.

단계 깊어지는 편
정규화·재작성 18편 Query Rewrite
임베딩 8편 임베딩 모델 비교
검색 (dense/sparse/hybrid) 10·11·12편
랭킹 13편 Reranker
컨텍스트 조립 6편 Contextual Chunking, 14편 평가셋
생성 (Grounding 강화) 22·24편 (Corrective·Agentic)

이 표가 본 시리즈의 목차 자체이기도 하다. 1편을 다 읽고 나면 "다음에 무엇을 읽어야 할지"가 자동으로 정해진다.

7. 변형과 사례 — Naive · Advanced · Modular · RETRO · kNN-LM

각 변형을 v3 5블록 패턴으로 본다. 무엇이 바뀌는가 → 왜 등장했나 → 무엇이 가능해졌나 → 어디에 적합한가 → 한계와 다음 단계.

7.1 Naive RAG — "retrieve → generate" 한 번

  • 무엇이 바뀌나: 한 번의 검색 + 한 번의 생성. 가장 단순한 형태.
  • 왜 등장했나: Lewis 2020 원논문의 형태이며, 2020~2022년의 표준이었다.
  • 무엇이 가능해졌나: LLM이 학습 시점 이후 지식과 비공개 문서에 닿게 되었다. 가중치를 다시 학습하지 않고도 도메인 적용이 가능해졌다.
  • 어디에 적합한가: 코퍼스가 작고 깨끗하며 질문 분포가 좁은 경우. POC, 사내 FAQ, 문서 한 권 안에서 답하는 케이스.
  • 한계와 다음 단계: 검색이 한 번뿐이라 재시도가 없고, top-K가 길어지면 Lost in the Middle에 그대로 노출된다. → Advanced RAG.

7.2 Advanced RAG — Pre-retrieval / Retrieval / Post-retrieval 3단

  • 무엇이 바뀌나: 검색 앞뒤에 단계가 붙는다. 앞: Query rewrite·expansion·classification. 뒤: rerank·filter·dedupe.
  • 왜 등장했나: Naive의 한계가 명확해지면서, 검색을 한 번 더 정제하는 시도가 모이기 시작했다. Gao et al. 2024 RAG Survey 4장가 이 분류를 정리했다.
  • 무엇이 가능해졌나: "질문이 모호하면 다시 쓴 다음 검색", "검색 결과가 너무 많으면 reranker로 줄임" 같은 행동이 표준이 됐다. Hybrid Search(12편)와 Reranker(13편)가 이 단계의 핵심.
  • 어디에 적합한가: 실무 운영. 사용자의 자연어 질의가 다양한 경우, 코퍼스가 충분히 크고 도메인이 여러 개인 경우.
  • 한계와 다음 단계: 단계가 늘면 지연(latency)이 누적된다. 또 각 단계의 모듈이 고정된 순서로 동작하므로 케이스마다 유연하게 조합하기 어렵다. → Modular RAG.

7.3 Modular RAG — 모듈 교체·재조합

  • 무엇이 바뀌나: Pre / Retrieval / Post의 각 단계를 모듈로 추상화한다. 모듈은 교체·삽입·삭제·반복 가능하다. Search 모듈, Memory 모듈, Routing 모듈, Predict 모듈 등.
  • 왜 등장했나: 도메인별로 필요한 단계가 다르고, 한 시스템 안에서 질문 유형에 따라 다른 모듈 조합을 쓰고 싶다는 요구가 모였다.
  • 무엇이 가능해졌나: "법령 질문은 정확 일치 모듈, 회의록 요약은 세션 컨텍스트 모듈, 일반 FAQ는 Hybrid + Rerank 모듈" 같은 라우팅이 한 시스템 안에서 가능해졌다.
  • 어디에 적합한가: 멀티 도메인. 사용자 그룹이 여러 개이고, 각 그룹의 질의 분포가 다른 큰 조직.
  • 한계와 다음 단계: 자유도가 늘수록 평가가 어렵다. 어떤 조합이 좋은지 알려면 실험 자동화가 필요하다. → 14편 평가셋·15편 검색 품질 지표·16편 LangSmith/Phoenix.

7.4 RETRO / Fusion-in-Decoder — 학습 단계에서 결합

  • 무엇이 바뀌나: 검색을 학습 단계에 끼운다. RETRO(Borgeaud 2022)는 25M 토큰 단위로 코퍼스를 검색해 그 결과를 디코더에 교차 어텐션으로 넣는다. Fusion-in-Decoder(Izacard 2021)는 인코더에서 각 문서를 따로 인코딩하고, 디코더에서 합친다.
  • 왜 등장했나: Lewis 2020처럼 생성만 학습하면 검색-생성 분리가 일어나 효율이 떨어진다. 두 모듈을 같이 학습하면 더 작은 모델로도 같은 품질이 가능하다는 가설.
  • 무엇이 가능해졌나: 7B 규모로 GPT-3 (175B)에 가까운 일부 벤치(언어 모델링)에 도달.
  • 어디에 적합한가: 사전 학습을 직접 하는 조직(연구·대형 모델 제공자). 운영 단계의 RAG에는 거리가 있다.
  • 한계와 다음 단계: 학습 비용·인프라가 커서 대부분의 실무 RAG는 여전히 retrieve-then-read에 머문다. 본 시리즈도 retrieve-then-read 패러다임에 집중한다.

7.5 kNN-LM — 토큰 단위 retrieval

  • 무엇이 바뀌나: 검색 단위가 문서가 아니라 토큰의 표현 벡터다. 생성 시점마다 코퍼스의 가장 가까운 토큰 컨텍스트를 찾아 다음 토큰 분포에 섞는다(Khandelwal 2020).
  • 왜 등장했나: 가중치 안의 "기억"이 부족할 때, 런타임에 외부 코퍼스의 통계를 빌려오는 발상.
  • 무엇이 가능해졌나: 도메인 적응이 추가 학습 없이 가능해졌고, 희귀 토큰 시퀀스에 대한 perplexity가 크게 줄었다.
  • 어디에 적합한가: 도메인이 좁고 표현 분포가 매우 특이한 영역(법령, 코드, 의학 노트).
  • 한계와 다음 단계: 디코딩 한 토큰마다 검색이 일어나 지연이 크다. RAG가 문서 단위 retrieve-then-read에 집중한 한 이유. 본 시리즈는 kNN-LM을 다루지 않는다. 다만 토큰 단위 retrieval이 왜 본권 흐름에서 비주류가 되었는지 알아 두면, 21편 Adaptive Top-K의 설계 동기가 더 잘 보인다.

다섯 변형을 한 표로 누르면 다음과 같다.

변형 검색 단위 학습 결합 운영 난이도 본 시리즈 깊이
Naive RAG 문서 X 1 1·2·5·6편
Advanced RAG 문서 X 2 7~13편
Modular RAG 문서 X 3 14~24편
RETRO / FiD 청크 O (사전학습) 매우 큼 다루지 않음
kNN-LM 토큰 O 매우 큼 다루지 않음

본 시리즈의 26편은 이 표의 위에서 세 번째 행까지다. 학습 단계까지 손대는 영역은 별도 시리즈(추후 Agent / Fine-tuning)로 분리한다.

8. 한계와 실패 양상

RAG는 만능이 아니다. 어떤 결정 한 군데가 틀어지면 어떤 결과가 나오는지, 어떻게 진단하고, 무엇으로 완화하는지를 본다. v3 5블록 — 왜 본질적인가 → 어떻게 진단하나 → 완화책 → 다음 편으로 연결.

8.1 Lost in the Middle

  • 왜 본질적인가: Liu et al. 2023(TACL 2024)가 보였듯, 긴 컨텍스트의 중간에 들어간 정보는 시작과 끝에 비해 모델의 활용도가 낮다. 이는 단순 attention 분포의 문제가 아니라, 학습 데이터의 위치 분포에서 비롯된다는 분석이 따랐다.
  • 어떻게 진단하나: 같은 문서를 처음에 / 중간에 / 끝에 넣어 동일 질문에 답하게 한 뒤 정답률을 비교. 정답률이 중간일 때 가장 낮다면 본 현상이 활성.
  • 완화책: top-K를 줄인다, 가장 관련 있는 문서를 양 끝에 둔다(reorder), reranker로 K'를 줄여 컨텍스트를 짧게 유지한다.
  • 다음 편으로 연결: 6편 Contextual Chunking, 13편 Reranker, 15편 검색 품질 지표.

8.2 Garbage-in Garbage-out — 잘못된 검색은 더 자신감 있는 환각을 만든다

  • 왜 본질적인가: 5장의 식에서 보았듯, Generator는 retriever의 출력에 조건을 건다. retriever가 그럴듯하지만 잘못된 문서를 가져오면, Generator의 출력 분포 \(P_\theta(y \mid x, z)\)가 그 문서에 맞춰 그럴듯한 답을 만든다. 환각이 줄어드는 게 아니라 근거 있는 환각이 된다.
  • 어떻게 진단하나: 답이 정답이 아닐 때, 컨텍스트에 정답 문서가 들어가 있었는지 따로 확인. RAGAS의 Context Recall 지표(14편)가 이 패턴을 직접 측정한다.
  • 완화책: Hybrid + Rerank로 retrieval 정확도 끌어올림, Confidence가 낮을 때 답하지 않는 정책, 답에 인용을 강제해 사용자 측 검증을 가능하게 함.
  • 다음 편으로 연결: 12편 Hybrid, 13편 Reranker, 14편 RAGAS, 22편 Corrective RAG.

8.3 비용·지연 누적

  • 왜 본질적인가: Retrieval(임베딩·벡터DB) + Rerank(cross-encoder) + Generation(LLM)이 직렬로 쌓인다. 각 단계가 ~수십~수백 ms일 수 있고, 사용자 체감 응답 시간이 늘어난다. 비용도 임베딩 호출·LLM 토큰·인프라(벡터DB)로 분산되어 누적된다.
  • 어떻게 진단하나: 각 단계의 p50·p95·p99 지연과 비용을 분리해 측정. LangSmith/Phoenix가 이 분리 측정의 표준 도구.
  • 완화책: Adaptive Top-K(21편)로 K를 줄임, Conditional Reranking(21편)로 reranker를 자신감 낮을 때만 호출, 캐시(query → top-K).
  • 다음 편으로 연결: 16편 LangSmith/Phoenix, 21편 Adaptive Top-K.

8.4 Parametric vs Retrieved 충돌

  • 왜 본질적인가: 모델이 가중치 안에 외워 둔 답과 검색 결과가 충돌할 때, 무엇을 따를지 명시되어 있지 않다. 시스템 프롬프트가 "컨텍스트만 보라"고 강하게 지시해도, 모델이 자신감이 매우 높은 영역에서는 가중치 답을 내는 경향이 있다.
  • 어떻게 진단하나: 정답이 알려진 질문에 고의로 잘못된 컨텍스트를 주입해 답이 어디로 가는지 본다. 컨텍스트를 따른다면 Grounding이 잘 됨, 가중치를 따른다면 충돌.
  • 완화책: 프롬프트에 "근거 인용을 답에 포함하라" 추가, Self-RAG / Corrective RAG로 답 자체를 다시 검증, 비교적 작은 모델을 쓰면 가중치 자신감이 낮아 컨텍스트 의존이 커진다는 실험 보고.
  • 다음 편으로 연결: 22편 Corrective RAG, 24편 Agentic RAG.

8.5 도메인 경계 누락 — "어느 문서 그룹에서 찾을 것인가"

  • 왜 본질적인가: 같은 벡터 공간에 정책 문서와 교육 자료, 최신 회의록과 과거 결정문, 개발자 문서와 사용자 매뉴얼이 섞이면, 의미 유사도가 목적 차이를 가린다. 사용자가 "최신 보안 정책"을 물었는데 교육용 안내문이 더 가까워서 뽑히는 사고가 여기서 나온다.
  • 어떻게 진단하나: 같은 질문을 문서 그룹별로 분리해 검색한 결과와 통합 검색 결과를 비교. 통합 검색이 그룹별 검색보다 정확도가 낮다면 본 현상 활성.
  • 완화책: Pre-filter(metadata로 문서 그룹을 먼저 좁힘), Multi-collection / Namespace 설계, Filter-first Retrieval. 이 모두를 한 자리에서 다루는 편이 3편이다.
  • 다음 편으로 연결: 3편 — Ingestion 설계: 문서 경계·Model-aware Schema·Filter-first Retrieval.

다섯 한계는 분리된 사고가 아니다. 한 시스템에서 동시에 일어나며, 서로의 진단을 가린다. 본 시리즈가 14~16편에 평가셋·검색 품질 지표·실험 자동화를 일찍 배치한 이유다.

8.5 Common Pitfalls — 자주 빠지는 함정

  • "chunk를 더 잘게 자르면 더 정확하다" — 의미 단위가 깨져 검색의 신호 자체가 약해진다. 5편 청킹 전략에서 적정 크기를 다룬다.
  • "top-K를 키우면 더 정확하다" — Lost in the Middle. 8.1 참고.
  • "RAG면 환각이 사라진다" — 8.2 참고. 검색이 틀리면 더 자신감 있는 환각.
  • "long-context 모델로 충분하다" — 비용은 줄지만 근거 추적성이 사라진다. 답의 어디가 어느 출처에서 왔는지 다시 묻기 어려워진다.
  • "Reranker는 항상 쓰면 좋다" — 비용이 추가되고, retrieval 자체가 정확한 케이스에서는 효과가 작다. 21편 Conditional Reranking.

요점: RAG의 어떤 결정도 항상 옳은 결정은 없다. 비용·지연·정확도의 trade-off를 측정해서 결정해야 하고, 그래서 본 시리즈의 절반이 평가·실험·라우팅에 배정되어 있다.

9. 정리된 결론 — 보지 않고 답해 보라

다섯 질문이다. 각 질문에 한 줄로 답한 뒤, 한 문장 근거와 본문 어느 챕터를 다시 들춘다. v3 retrieval practice.

Q1. RAG의 5요소를 기억나는 대로 적어 보라

정답: Retriever, Generator, Knowledge Base, Context, Grounding. 근거: Retriever는 top-K 검색, Generator는 LLM, Knowledge Base는 저장, Context는 발췌, Grounding은 근거 밖으로 안 나가는 행동 규약. 본문 챕터: 4장 정의 표.

Q2. Lewis 2020의 식 \(P(y \mid x) = \sum_z P_\eta(z\mid x) P_\theta(y \mid x, z)\)의 두 항은 각각 무엇인가

정답: \(P_\eta\)는 Retriever, \(P_\theta\)는 Generator. 근거: 첫 항은 이 문서가 이 질문에 얼마나 관련 있는지의 확률, 둘째 항은 이 질문과 이 문서가 주어졌을 때 이 답을 낼 확률. 둘의 곱을 top-K에 대해 합한다. 본문 챕터: 5장.

Q3. Lost in the Middle이 의미하는 것은

정답: 긴 컨텍스트의 중간에 들어간 정보가 시작·끝보다 모델에 의해 덜 활용되는 현상. 근거: Liu 2023이 보인 위치 의존성. 학습 데이터의 위치 분포에서 비롯되며, top-K를 줄이거나 reorder/rerank로 완화한다. 본문 챕터: 8.1.

Q4. RAG를 안 쓰는 게 맞는 경우 2가지를 들어 보라

정답: ① 도메인이 좁고 모델 가중치 안의 지식만으로 충분한 경우. ② 근거 추적성이 필요 없는 일회성 짧은 답변. (셋째로, long-context 모델 비용이 RAG 인프라 비용보다 작은 케이스도 가능하다.) 근거: RAG는 비용·지연을 추가한다. 그 비용을 근거 있는 답·도메인 적응·최신 정보로 회수해야 정당화된다. 본문 챕터: 1·2·8.4.

Q5. "Grounding"이 깨졌을 때 가장 먼저 의심해야 할 것은

정답: 검색 결과 자체가 정답을 포함하고 있었는가 — 즉 Context Recall. 근거: Grounding이 깨졌다고 해서 항상 Generator의 문제는 아니다. 컨텍스트에 정답이 없었다면 Generator는 처음부터 근거 안에 머물 수 없다. 8.2 + 14편 RAGAS Context Recall에서 다시 본다. 본문 챕터: 8.2.

다섯 질문을 모두 책을 닫고 답할 수 있다면, 본 편의 학습 목표 세 가지가 손에 잡힌 상태다.

10. 추가 학습 — 인용·근거

1차 자료 (원논문 · 표준 인용 형식)

  • Lewis, P. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401
  • Khandelwal, U. et al. Generalization through Memorization: Nearest Neighbor Language Models. ICLR 2020. arXiv:1911.00172
  • Borgeaud, S. et al. Improving Language Models by Retrieving from Trillions of Tokens (RETRO). ICML 2022. arXiv:2112.04426
  • Izacard, G. & Grave, E. Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering (Fusion-in-Decoder). EACL 2021. arXiv:2007.01282
  • Liu, N. et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 2024. arXiv:2307.03172
  • Asai, A. et al. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024. arXiv:2310.11511
  • Yan, S. et al. Corrective Retrieval Augmented Generation. arXiv:2401.15884
  • Gao, Y. et al. Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997

공식 docs · 가이드

  • LangChain RAG tutorial: https://python.langchain.com/docs/tutorials/rag/
  • LlamaIndex Indexing & Querying: https://docs.llamaindex.ai/en/stable/understanding/indexing/
  • Anthropic Contextual Retrieval blog (2024-09)
  • Pinecone "What is RAG" overview
  • Weaviate Academy — Vector Search & RAG fundamentals

보조 자료

  • 사용자 노트 0장~5장 — RAG의 정의·역사·전체 구조.
  • 사용자 노트 34장 — 핵심 메시지 ("질문에 맞는 근거를 정확히 찾고, 그 근거 밖으로 나가지 않는 답변을 만드는 것").
  • 사용자 노트 §35-9 — "어느 문서 그룹에서 찾을 것인가" → 본 편 8.5 → 3편 Ingestion 설계.

Cheat Sheet — 한 장 요약

단어 한 줄 정의
Retriever Query에 맞는 top-K 문서를 가져오는 함수
Generator Query + Context로 답을 만드는 LLM
Knowledge Base 외부 문서·임베딩이 들어 있는 저장소
Context Generator 입력에 끼어 들어가는 발췌본
Grounding 답이 근거 안에 머무는 성질
Naive RAG retrieve → generate 한 번
Advanced RAG Pre / Retrieval / Post 3단
Modular RAG 각 단을 모듈로 갈아끼우는 형태
Lost in the Middle 긴 컨텍스트의 중간이 무시되는 현상
Grounded Answer 검색 결과 안에서만 만든 답
RAG-Token / RAG-Sequence 토큰별·답 전체별 문서 선택의 두 변형
Context Recall 정답 문서가 컨텍스트 안에 들어와 있었는가 (8.2 진단 지표)

Bridge — 다음 편 안내

다음 — RAG 핵심 학습 (2/26) 문서 전처리와 PDF → Markdown 파이프라인.

RAG의 5요소 중 Knowledge Base를 처음 만들 때 만나는 문제: 원본 문서를 어떤 형태로 저장할 것인가. PDF·HWP·DOCX·HTML·CSV가 섞인 코퍼스를, LLM과 임베딩이 다룰 수 있는 마크다운으로 어떻게 바꿀까. MarkItDown · Unstructured · Docling · LlamaParse 네 가지 라이브러리를 구조 보존 능력·표 추출 정확도·이미지 처리·라이선스·운영 비용의 다섯 기준으로 비교한다. 2편은 그 결정의 시작이다.

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기