[AI] RAG란? - 검색 증강 생성의 개념과 동작 원리 이해하기

ChatGPT와 같은 LLM은 방대한 데이터를 학습하기 때문에 다양한 질문에 답할 수 있다.

하지만 LLM이라고 해서 모든 정보를 알고 있는 것은 아니다.

 

예를 들어 다음과 같은 질문을 생각해보자.

우리 회사의 휴가 규정은 어떻게 돼?

지난주에 변경된 서비스 정책을 알려줘.

사내 개발 가이드에서 API Naming Rule을 찾아줘.

이러한 정보는 LLM이 학습할 때 존재하지 않았거나, 외부에 공개되지 않은 정보일 수 있다.

또한 LLM은 답을 정확히 모르는 상황에서도 그럴듯한 내용을 만들어낼 수 있다.

 

대표적인 문제가 다음 세 가지다.

Knowledge Cutoff
→ 학습 이후의 최신 정보를 모름

Lack of Context
→ 회사 내부 문서나 특정 도메인 정보를 모름

Hallucination
→ 사실이 아닌 내용을 그럴듯하게 생성할 수 있음

이러한 LLM과 실제 데이터 사이의 간극을 줄이기 위해 사용하는 대표적인 방법이 RAG다.

RAG

---

RAG란?

RAG 구조

RAG는 다음의 약자다.

Retrieval-Augmented Generation

Retrieval
→ 검색

Augmented
→ 증강, 보강

Generation
→ 생성

한 문장으로 정리하면 다음과 같다.

RAG는 사용자의 질문과 관련된 외부 정보를 먼저 검색한 뒤, 검색된 정보를 LLM에게 함께 제공하여 답변을 생성하는 방식이다.

전체적인 구조는 매우 단순하다.

사용자 질문
     │
     ▼
관련 정보 검색
Retrieval
     │
     ▼
검색 결과를 질문에 추가
Augmentation
     │
     ▼
LLM
     │
     ▼
답변 생성
Generation

즉 LLM에게 바로 질문하지 않고, 답변에 필요한 자료를 먼저 찾아준 다음 질문과 함께 전달한다.

RAG의 Runtime 과정 역시 Retrieve → Augment → Generate 흐름으로 구성된다.

---

RAG를 쉽게 이해해보자

RAG를 오픈북 시험에 비유해보자.

일반적인 LLM은 다음과 같다.

시험 문제
   ↓
학생의 기억
   ↓
답변

학생이 예전에 공부한 내용만 가지고 답을 작성하는 것이다.

반면 RAG는 오픈북 시험과 비슷하다.

시험 문제
   ↓
책에서 관련 내용 검색
   ↓
관련 페이지 확인
   ↓
문제 + 참고 자료
   ↓
답변 작성

LLM이 모든 내용을 기억하고 있을 필요가 없다.

필요한 순간에 외부 데이터에서 관련 정보를 찾아서 LLM에게 제공하면 된다.

따라서 RAG에서 LLM의 역할과 검색 시스템의 역할은 다르다.

검색 시스템
→ 필요한 지식을 찾아준다.

LLM
→ 찾아온 지식을 이용해서 답변을 만든다.

---

RAG에서 가장 중요한 개념

RAG를 이해하려면 다음 요소들의 관계를 먼저 이해해야 한다.

Document

Chunk

Embedding

Vector

Vector DB

Similarity Search

Prompt Context

LLM

전체적으로 연결하면 다음과 같다.

Document
   │
   ▼
Chunk
   │
   ▼
Embedding
   │
   ▼
Vector
   │
   ▼
Vector DB


사용자 질문
   │
   ▼
Embedding
   │
   ▼
Query Vector
   │
   ▼
Vector DB 검색
   │
   ▼
관련 Chunk
   │
   ▼
Prompt Context
   │
   ▼
LLM

결국 RAG는 문서를 잘 저장하고, 질문과 관련된 문서를 잘 찾아서, LLM에게 잘 전달하는 기술이라고 볼 수 있다.

---

RAG는 크게 두 과정

RAG는 하나의 과정처럼 보이지만 실제로는 크게 두 단계로 나누어 생각할 수 있다.

RAG

├─ Offline
│
│  문서를 미리 가공하고 저장
│
└─ Runtime

   질문이 들어왔을 때
   관련 문서를 검색하고 답변 생성

자료에서도 외부 데이터를 DocumentReader → DocumentTransformer → DocumentWriter로 처리하는 Offline 과정과, 실제 질문에 대해 Retrieve → Augment → Generate하는 Runtime 과정을 구분하고 있다.

---

Offline 과정

Offline은 RAG가 사용할 지식을 미리 준비하는 과정이다.

예를 들어 다음과 같은 회사 문서가 있다고 해보자.

사내규정.pdf
개발가이드.pdf
보안정책.docx
서비스매뉴얼.txt

이 파일을 그대로 검색하는 것이 아니라 RAG가 검색하기 좋은 형태로 가공한다.

전체 과정은 다음과 같다.

원본 Document
      │
      ▼
텍스트 추출
      │
      ▼
문서 분할
Chunking
      │
      ▼
Embedding
      │
      ▼
Vector
      │
      ▼
Vector DB 저장

이 과정은 일반적으로 다음과 같은 ETL 형태로 볼 수 있다.

Extract
→ 데이터를 읽는다.

Transform
→ 검색하기 좋은 형태로 가공한다.

Load
→ Vector DB에 저장한다.

---

Document

RAG에서 가장 처음 다루게 되는 것은 Document다.

Document는 말 그대로 검색에 사용할 원본 정보다.

 

다음과 같은 것들이 모두 Document의 원천이 될 수 있다.

PDF
TXT
DOCX
HTML
JSON

웹페이지
사내 Wiki
DB 데이터
업무 매뉴얼
정책 문서

하지만 원본 파일 하나가 반드시 검색 단위 하나가 되는 것은 아니다.

대부분의 경우 문서를 더 작은 단위로 분리해서 사용한다.

---

Chunk란?

Chunk는 큰 Document를 검색하기 좋은 작은 단위로 나눈 문서 조각이다.

100페이지짜리 회사 규정 문서가 있다고 해보자.

회사규정.pdf

├─ 근무 규정
├─ 휴가 규정
├─ 경조사 규정
├─ 출장 규정
├─ 보안 규정
└─ 복리후생 규정

이 문서 전체를 하나의 검색 단위로 사용하면 문제가 생긴다.

사용자가 다음과 같이 질문했다고 해보자.

경조사 휴가는 며칠이야?

필요한 내용은 전체 100페이지 중 몇 문장뿐이다.

그런데 전체 문서를 하나로 사용하면:

경조사 질문
    ↓
100페이지 전체
    ↓
LLM

처럼 너무 많은 불필요한 정보가 들어간다.

그래서 문서를 작은 Chunk로 나눈다.

회사규정.pdf

        ↓ Chunking

Chunk 1
→ 근무시간 규정

Chunk 2
→ 연차 규정

Chunk 3
→ 경조사 휴가 규정

Chunk 4
→ 출장 규정

Chunk 5
→ 보안 규정

이제 경조사 휴가에 대해 질문하면:

"경조사 휴가는 며칠이야?"

          ↓

      Chunk 검색

          ↓

Chunk 3
"경조사 휴가 규정 ..."

처럼 필요한 부분만 가져올 수 있다.

---

왜 Chunk가 중요한가?

RAG에서는 Chunk 크기가 검색 품질에 큰 영향을 준다.

너무 큰 Chunk를 사용하면:

Chunk가 너무 큼

→ 여러 주제가 한 Chunk에 섞임
→ Embedding 의미가 모호해짐
→ 관련 없는 정보까지 LLM에 전달

반대로 너무 작은 Chunk를 사용하면:

Chunk가 너무 작음

→ 문맥이 끊어짐
→ 필요한 정보가 여러 Chunk로 분산
→ 검색 결과 하나만으로 의미를 이해하기 어려움

예를 들어 다음 문장을 생각해보자.

직원은 입사 1년 이후 15일의 연차를 사용할 수 있다.
미사용 연차의 처리 기준은 별도 규정을 따른다.

너무 잘게 나누면:

Chunk 1
"직원은 입사 1년 이후"

Chunk 2
"15일의 연차를 사용할 수 있다."

Chunk 3
"미사용 연차의 처리 기준은"

Chunk 4
"별도 규정을 따른다."

처럼 문맥이 깨질 수 있다.

따라서 Chunk는 단순히 작게 만드는 것이 아니라 질문에 답할 수 있을 정도의 의미 있는 정보 단위로 만드는 것이 중요하다.

---

Embedding

Chunk를 만들었다면 다음으로 필요한 것이 Embedding이다.

Embedding은 텍스트의 의미를 숫자로 이루어진 Vector로 변환하는 과정이다.

예를 들어:

"고양이가 뛰고 있다"

        ↓

  Embedding Model

        ↓

[0.12, 0.41, -0.31, 0.72, ...]

다른 문장도 같은 방식으로 Vector가 된다.

"고양이가 달린다"

        ↓

[0.11, 0.39, -0.30, 0.70, ...]

두 문장은 의미가 비슷하다.

따라서 Embedding Model이 잘 학습되어 있다면 두 Vector 역시 서로 비슷하게 만들어진다.

반대로:

"Spring Boot 서버를 실행한다."

는 의미가 전혀 다르기 때문에 다른 위치의 Vector가 생성된다.

개념적으로 표현하면 다음과 같다.

Vector Space


 ● 고양이가 달린다
   ● 고양이가 뛰고 있다



                         ● Spring Boot 서버 실행

이렇게 의미가 비슷한 데이터가 Vector 공간에서도 가까워지도록 만드는 것이 Embedding의 핵심이다.

---

왜 그냥 키워드 검색을 하지 않을까?

일반적인 검색은 동일한 단어가 있는지를 중심으로 검색할 수 있다.

예를 들어 사용자가 다음과 같이 검색한다.

"휴가 일수"

그런데 문서에는 이렇게 적혀 있을 수도 있다.

"근로자는 연간 15일의 연차를 사용할 수 있다."

휴가 일수라는 단어가 정확히 존재하지 않는다.

하지만 의미적으로는 매우 관련이 있다.

휴가 일수

≈ 연간 연차 15일

Embedding을 이용하면 단순한 문자열 일치보다 의미적 유사성을 이용해 검색할 수 있다.

이것을 Semantic Search라고 한다.

---

Vector DB

Embedding으로 만든 Vector를 저장하는 곳이 Vector Database다.

일반적인 Database가 다음과 같은 검색에 강하다면:

WHERE name = 'Kim'

Vector DB는 다음과 같은 질문에 강하다.

"이 문장과 의미가 가장 비슷한 문서를 찾아줘."

즉 검색 기준이 다음과 같이 달라진다.

일반 DB

값이 같은가?
      ↓
Exact Match


Vector DB

의미가 비슷한가?
      ↓
Similarity Search

RAG에서 Vector Store는 Document를 Embedding하여 저장하고, 질문을 이용해 유사한 Document를 다시 검색하는 역할을 한다.

---

Offline 과정에서 실제로 저장되는 것

예를 들어 다음 Chunk가 있다고 해보자.

"대한민국의 영토는 한반도와 그 부속도서로 한다."

Embedding을 수행한다.

Embedding Model

        ↓

[0.13, -0.42, 0.81, 0.22, ...]

그리고 Vector DB에는 개념적으로 다음과 같은 정보가 저장된다.

Document

content
→ 대한민국의 영토는 한반도와 그 부속도서로 한다.

metadata
→ article: 3

embedding
→ [0.13, -0.42, 0.81, ...]

이러한 데이터가 수백, 수천, 수백만 개 저장될 수 있다.

여기까지가 RAG의 지식 준비 과정이다.

---

Runtime 과정

이제 사용자가 실제 질문을 한다.

대한민국의 영토는 어디까지야?

여기부터 Runtime RAG가 시작된다.

전체 흐름은 다음과 같다.

사용자 질문

     ↓

Query Embedding

     ↓

Query Vector

     ↓

Vector DB

     ↓

Similarity Search

     ↓

관련 Chunk 검색

     ↓

Prompt에 추가

     ↓

LLM

     ↓

최종 답변

하나씩 보면 이해하기 쉽다.

---

1. 사용자의 질문을 Vector로 만든다

저장된 Document만 Vector로 만드는 것이 아니다.

검색할 질문 역시 같은 Embedding Model을 이용해 Vector로 변환한다.

질문

"대한민국의 영토는 어디까지야?"

        ↓

Embedding Model

        ↓

Query Vector

[0.15, -0.40, 0.78, ...]

이 Query Vector와 Vector DB에 저장된 Vector들을 비교한다.

---

2. Similarity Search

Vector DB에서는 Query Vector와 가장 비슷한 Vector를 찾는다.

예를 들어 다음과 같은 결과가 나왔다고 해보자.

질문 Vector

      ↓

Vector DB

      ↓

Document A
Similarity = 0.93

Document B
Similarity = 0.82

Document C
Similarity = 0.57

Document D
Similarity = 0.21

가장 높은 문서가 질문과 의미적으로 가장 관련성이 높다고 판단할 수 있다.

자료에서는 VectorStoreDocumentRetriever가 이러한 VectorStore 기반 유사도 검색을 수행하는 Retrieval 역할을 담당한다.

---

Top-K

RAG에서는 일반적으로 문서 하나만 가져오지 않는다.

관련성이 높은 상위 몇 개를 가져온다.

이를 Top-K라고 한다.

예를 들어:

Top-K = 3

이면:

검색 결과

1위 0.93  ← 사용
2위 0.88  ← 사용
3위 0.82  ← 사용
4위 0.71
5위 0.65

상위 3개의 Document를 가져온다.

구조는 다음과 같다.

Query

  ↓

Vector Search

  ↓

Top-K

  ├─ Chunk A
  ├─ Chunk B
  └─ Chunk C

K가 너무 작으면 필요한 정보를 놓칠 수 있고, 너무 크면 불필요한 문서가 함께 들어올 수 있다.

---

Similarity Threshold

또 하나 중요한 개념이 Similarity Threshold다.

Top-K만 사용하면 문제가 하나 있다.

관련 있는 문서가 전혀 없어도 무조건 상위 몇 개를 가져올 수 있다는 것이다.

예를 들어:

질문

"회사 주차장 이용 규정 알려줘"

그런데 Vector DB에는 주차장 관련 내용이 하나도 없다고 해보자.

그래도 Top-3를 강제로 가져오면:

1위 0.34
2위 0.29
3위 0.23

같이 별로 관련 없는 문서가 선택될 수 있다.

그래서 최소 유사도를 설정한다.

Similarity Threshold = 0.7

그러면:

0.92 → 사용
0.83 → 사용
0.75 → 사용
0.63 → 제외
0.41 → 제외

처럼 일정 수준 이상의 문서만 사용한다.

---

Retrieval

여기까지가 RAG의 첫 번째 단계인 Retrieval이다.

Question
   │
   ▼
Embedding
   │
   ▼
Vector Search
   │
   ▼
Top-K / Threshold
   │
   ▼
관련 Chunk

Retrieval의 목적은 단순하다.

사용자의 질문에 답하기 위해 필요한 정보를 외부 데이터에서 찾아오는 것

이다.

---

Augmentation

그런데 문서를 찾는 것만으로 끝나지 않는다.

검색된 내용을 LLM에게 전달해야 한다.

이 과정이 Augmentation이다.

 

검색 결과가 다음과 같다고 해보자.

대한민국의 영토는 한반도와 그 부속도서로 한다.

이 정보를 사용자의 질문과 함께 Prompt에 넣는다.

아래 정보를 참고하여 질문에 답하세요.

[Context]

대한민국의 영토는
한반도와 그 부속도서로 한다.

[Question]

대한민국의 영토는 어디까지인가?

원래 Prompt가:

Question

이었다면 RAG에서는:

Context
+
Question

형태가 되는 것이다.

자료에서도 검색된 Document를 사용자 Query와 결합하여 최종 Prompt를 만드는 것을 Generation 단계의 증강 과정으로 설명한다.

---

Context란?

RAG에서 매우 자주 등장하는 단어가 Context다.

Context는 LLM에게 제공하는 참고 정보라고 보면 된다.

Context
→ LLM이 답변할 때 참고해야 하는 외부 정보

예를 들어:

사용자 질문

"경조사 휴가가 며칠이야?"

Context가 없으면:

LLM

→ 자신의 기존 지식으로 답변

RAG에서는:

Context

"회사 규정 제12조:
직계가족의 경조사 발생 시
최대 5일의 특별휴가를 제공한다."

           +

Question

"경조사 휴가가 며칠이야?"

           ↓

          LLM

이 된다.

LLM 입장에서는 검색을 직접 수행했다기보다 질문을 받았는데 참고 자료까지 같이 받은 것에 가깝다.

---

Generation

마지막 단계가 Generation이다.

Context
+
Question

     ↓

    LLM

     ↓

Answer

LLM은 검색된 데이터를 바탕으로 자연어 답변을 만든다.

예를 들어:

Context

"연차는 입사 1년 이후 15일이 부여된다."


Question

"1년 이상 근무하면 연차가 몇 개야?"

LLM은 이를 이용해서:

입사 후 1년 이상 근무한 직원에게는
15일의 연차가 부여된다.

같은 자연어 답변을 생성한다.

즉 RAG에서 LLM은 검색 엔진이 아니다.

Retriever
→ 정보를 검색

LLM
→ 검색된 정보를 이해하고 답변 생성

역할이 나누어져 있다.

---

RAG의 전체 원리

지금까지 내용을 하나로 연결하면 다음과 같다.

                 [ Offline ]


             원본 Document
                   │
                   ▼
               Chunking
                   │
                   ▼
             Embedding Model
                   │
                   ▼
                Vector
                   │
                   ▼
               Vector DB


────────────────────────────────


                 [ Runtime ]


             User Question
                   │
                   ▼
             Embedding Model
                   │
                   ▼
              Query Vector
                   │
                   ▼
               Vector DB
                   │
                   ▼
           Similarity Search
                   │
              Retrieval
                   ▼
             Related Chunks
                   │
              Augmentation
                   ▼
           Context + Question
                   │
                   ▼
                  LLM
                   │
              Generation
                   ▼
                Answer

이 구조가 가장 기본적인 RAG다.

---

RAG의 핵심은 사실 LLM보다 Retrieval

RAG에서는 검색 결과가 매우 중요하다.

아무리 좋은 LLM을 사용하더라도 검색에서 잘못된 Document를 가져오면 제대로 답변하기 어렵다.

좋은 Retrieval

정확한 Document
      ↓
좋은 Context
      ↓
좋은 Answer

반대로:

나쁜 Retrieval

관련 없는 Document
       ↓
나쁜 Context
       ↓
잘못된 Answer

이런 구조가 될 수 있다.

따라서 RAG 품질을 개선할 때는 단순히 LLM만 좋은 모델로 바꾸는 것이 아니라 다음 요소들을 함께 고려해야 한다.

Embedding Model

Chunk 크기

Chunk 분할 방식

검색 방식

Top-K

Similarity Threshold

Metadata Filtering

Prompt 구성

---

Hallucination이 사라지는 것은 아니다

RAG의 대표적인 목적 중 하나는 LLM에게 근거를 제공하는 것이다.

하지만 RAG를 사용했다고 해서 항상 정확한 답변이 만들어지는 것은 아니다.

 

예를 들어 검색 단계에서 잘못된 문서를 가져오면:

잘못된 Retrieval
      ↓
잘못된 Context
      ↓
LLM
      ↓
잘못된 답변

이 가능하다.

또 제대로 된 문서를 검색했어도 Prompt가 좋지 않다면 LLM이 외부 지식을 섞어서 답할 수도 있다.

그래서 RAG Prompt에는 다음과 같은 규칙을 넣기도 한다.

제공된 Context만 이용하여 답변하세요.

Context에 답이 없다면
답을 찾을 수 없다고 응답하세요.

자료에서도 검색 결과가 없을 경우 별도의 응답을 사용하거나, 제공된 Context만을 사용하도록 Prompt를 구성하는 방법을 다룬다.

---

기본 RAG의 한계

지금까지 설명한 구조를 흔히 가장 기본적인 RAG 형태로 볼 수 있다.

Question
   ↓
Vector Search
   ↓
Context
   ↓
LLM

하지만 실제 사용자가 항상 검색하기 좋은 질문을 입력하는 것은 아니다.

예를 들어:

아 그 저번에 얘기했던 거 있잖아
그거 기간 얼마나 돼?

이 문장만 Vector Search하면 무엇을 의미하는지 알기 어렵다.

또 다음과 같이 필요 이상으로 장황한 질문도 있을 수 있다.

제가 지금 프로젝트를 하다가 문득 궁금해졌는데요.
Spring AI에서 RAG를 쓰고 있는데 혹시 검색 정확도를
높일 수 있는 방법이 있나 해서 질문드립니다.

검색에 필요한 핵심은 사실:

RAG 검색 정확도 향상 방법

이다.

이러한 문제를 개선하기 위해 Advanced RAG에서는 검색 전후에 추가 처리를 수행한다.

---

Pre-Retrieval

Pre-Retrieval은 실제 검색을 하기 전에 사용자의 Query를 가공하는 단계다.

User Query
    │
    ▼
Pre-Retrieval
    │
    ▼
검색에 최적화된 Query

대표적인 방법은 다음과 같다.

Query Rewrite
→ 불필요한 표현을 제거하고 질문을 다시 작성

Query Compression
→ 이전 대화까지 참고해 독립적인 질문으로 변경

Multi Query
→ 하나의 질문을 여러 형태의 검색 Query로 확장

Translation
→ 검색에 적합한 언어로 변환

예를 들어:

원본

"오늘 날씨도 좋고 갑자기 궁금해졌는데
Spring AI RAG 검색 속도 올리는 방법이 있을까?"

다음처럼 바꿀 수 있다.

Spring AI RAG 검색 성능 최적화 방법

이렇게 하면 검색 품질을 높일 수 있다.

---

Multi Query

하나의 질문을 여러 형태로 바꾸어 검색하는 방법도 있다.

예를 들어:

원본 Query

"RAG 성능 개선 방법"

을 다음처럼 확장한다.

Query 1
RAG 검색 정확도 향상 방법

Query 2
Embedding 기반 RAG 성능 개선 방법

Query 3
Vector DB Retrieval 최적화 방법

그 후 각 Query로 문서를 검색한다.

             Original Query
                   │
                   ▼
             Query Expander
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼

      Query 1    Query 2    Query 3

        │          │          │
        └──────────┼──────────┘
                   ▼

               Retrieval

검색 범위를 넓혀 관련 정보를 찾을 가능성을 높이는 방식이다. 자료에서도 MultiQueryExpander의 목적을 단일 질문을 다양한 질문으로 확장해 더 많은 관련 문서를 찾는 것으로 설명한다.

---

Post-Retrieval

검색 결과를 그대로 LLM에게 전달할 필요도 없다.

검색된 문서를 다시 가공하는 과정을 Post-Retrieval이라고 한다.

Vector Search

     ↓

Documents

     ↓

Post-Retrieval

     ↓

정제된 Documents

대표적으로 다음과 같은 작업이 있다.

Filtering
→ 관련 없는 문서 제거

Reranking
→ 질문과 관련성이 높은 순서로 다시 정렬

Deduplication
→ 중복 Document 제거

Compression
→ Document에서 필요한 부분만 추출 또는 요약

자료에서도 Post-Retrieval의 역할로 재정렬, 관련 없는 문서 제거, 압축 등을 설명한다.

---

기본 RAG와 Advanced RAG

결국 두 구조를 비교하면 다음과 같다.

기본 RAG

Question
   │
   ▼
Retrieval
   │
   ▼
Context
   │
   ▼
LLM

Advanced RAG

Question
   │
   ▼
Pre-Retrieval
Query Rewrite / Expansion
   │
   ▼
Retrieval
Vector Search
   │
   ▼
Post-Retrieval
Filtering / Reranking
   │
   ▼
Augmentation
Context + Query
   │
   ▼
Generation
LLM
   │
   ▼
Answer

즉 RAG가 발전할수록 단순히 Vector DB에서 몇 개 가져와 LLM에게 넣는 구조를 넘어, 검색 품질 자체를 개선하는 방향으로 확장된다.

---

RAG를 사용할 때 중요한 포인트

RAG를 이해할 때 다음 네 가지를 기억하면 된다.

1. 무엇을 저장할 것인가?

Document / Data


2. 어떻게 나눌 것인가?

Chunking


3. 어떻게 찾을 것인가?

Embedding / Retrieval


4. 어떻게 LLM에게 전달할 것인가?

Augmentation / Prompt

결국 RAG 성능은 이 네 과정의 결과가 합쳐져 만들어진다.

---

RAG 전체 구조 다시 보기

                         RAG


              ┌─────────────────────┐
              │      Offline        │
              └─────────────────────┘

                  Original Data
                       │
                       ▼
                    Extract
                       │
                       ▼
                    Document
                       │
                       ▼
                    Chunking
                       │
                       ▼
                 Embedding Model
                       │
                       ▼
                     Vector
                       │
                       ▼
                   Vector DB


════════════════════════════════════════════════


              ┌─────────────────────┐
              │       Runtime       │
              └─────────────────────┘

                  User Question
                       │
                       ▼
                   Embedding
                       │
                       ▼
                  Query Vector
                       │
                       ▼
                   Vector DB
                       │
                  Retrieval
                       ▼
                Related Documents
                       │
                  Augmentation
                       ▼
                 Context + Query
                       │
                       ▼
                      LLM
                       │
                   Generation
                       ▼
                     Answer

---

정리

RAG는 Retrieval-Augmented Generation, 즉 검색 증강 생성이다.

LLM에게 질문을 바로 전달하는 대신, 질문과 관련된 정보를 외부 데이터에서 먼저 검색하여 함께 전달한다.

핵심은 세 단계다.

Retrieval

질문과 관련된 정보를 검색한다.


Augmentation

검색된 정보를
Prompt의 Context로 추가한다.


Generation

LLM이 질문과 Context를 이용하여
최종 답변을 생성한다.

하지만 실제 RAG는 그 전에 데이터를 준비하는 과정까지 포함해서 이해해야 한다.

문서
 ↓
Chunking
 ↓
Embedding
 ↓
Vector DB

그리고 질문이 들어오면:

질문
 ↓
Embedding
 ↓
Similarity Search
 ↓
관련 Chunk
 ↓
Context
 ↓
LLM
 ↓
답변

이라는 흐름으로 동작한다.

따라서 RAG에서 가장 중요한 것은 단순히 LLM에게 문서를 전달하는 것이 아니다.

사용자의 질문에 필요한 정보를 얼마나 정확하게 찾아서, 적절한 Context로 LLM에게 전달하느냐가 RAG의 핵심이다.

그리고 이 관점에서 보면 RAG는 단순한 LLM + Vector DB가 아니라,

문서 준비
+
Chunking
+
Embedding
+
Retrieval
+
Context 구성
+
Generation

이 모두 연결된 하나의 정보 검색 + 생성 파이프라인이라고 이해하는 것이 가장 정확하다.