[KT AIVLE School] 6주차: RAG(Retrieval Augmented Generation)

왜 LLM은 RAG가 필요할까?

최근 생성형 AI 서비스를 만들거나 실무 사례를 보다 보면, 이제는 너무나 자연스럽게 등장하는 개념이 있습니다.

바로 RAG(Retrieval Augmented Generation) 입니다.

 

처음에는 단순히 

"문서를 넣고 답변하게 하는 기술?"

 

정도로 이해했지만, 직접 구현해보면서 왜 실무에서 RAG를 많이 사용하는지 알게 되었습니다.

 

이번 글에서는 

• LLM의 구조적 한계
• RAG의 필요성
• RAG의 동작 과정
• RAG Chain 흐름

까지 정리해보겠습니다!

---

LLM의 구조적 한계

LLM(Large Language Model)은 매우 강력하지만, 구조적으로 몇 가지 한계를 가지고 있습니다.

1. 학습 이후 정보 반영 불가

LLM은 학습이 끝난 이후의 정보를 알지 못합니다.

예를 들어:

• 최신 뉴스
• 최근 정책 변경
• 회사 내부 공지

같은 정보는 기본적으로 반영되지 않습니다.

즉,

학습 시점 이후 정보는 알 수 없습니다.

 

2. 모든 지식을 파라미터에 저장

LLM은 정보를 모델 내부 파라미터에 저장합니다.

 

하지만 현실의 데이터는:

• 너무 많고
• 계속 바뀌며
• 기업마다 다릅니다.

따라서 모든 정보를 모델 안에 저장하는 방식에는 한계가 존재합니다.

 

3. 할루시네이션(Hallucination)

LLM은 "정답"을 찾는 모델이라기보다,

다음 단어를 확률적으로 생성하는 모델에 가깝습니다.

 

그래서 실제 근거가 없더라도 그럴듯한 답변을 생성할 수 있습니다.

 

4. 기업 내부 데이터 활용 어려움

실무에서는:

• 사내 문서
• 회의록
• 매뉴얼
• 정책 문서

같은 내부 데이터를 활용해야 하는 경우가 많습니다.

하지만 일반적인 LLM은 이러한 데이터를 학습하고 있지 않습니다.

---

이것이 바로 RAG를 쓰는 이유!

RAG는:

질문(Query)만 전달하는 것이 아니라
관련 문서(Context)도 함께 제공하는 방식입니다.

 

즉, 

Prompt = Query + Context 

형태로 동작합니다.

 

LLM이 검색한 문서를 참고해서 답변하도록 만드는 것입니다.

---

RAG란?

RAG는

Retrieval Augmented Generation

한글로는:

검색 증강 생성

 

이라고 부릅니다.

 

핵심 아이디어는 단순합니다.

1. 관련 문서를 검색한다.
2. 검색한 문서를 프롬프트에 함께 넣는다.
3. LLM이 해당 문서를 기반으로 답변한다.

즉,

검색으로 프롬프트를 강화하는 방식입니다.

 

그래서 '증강' 이라고 하는 것이죠.

 

Fine-tuning vs RAG

많이 헷갈리는 부분이 바로 Fine-tuning과 RAG의 차이입니다.

 

가장 큰 차이는:

Fine-tuning 

• 모델 자체를 다시 학습
• 지식을 모델 내부에 내재화
• 시간과 비용 소모가 큼

모델 자체를 바꾸는 방식

 

 

RAG

• 모델은 그대로 사용
• 필요한 외부 문서를 검색해서 제공
• 최신 정보 반영이 쉬움

 

필요한 자료를 그때그때 참고시키는 방식

 

→ 실무에서 RAG가 많이 사용되는 이유도 여기에 있습니다.

---

RAG 동작 과정

그렇다면 실제로 RAG는 어떻게 동작할까요?

핵심 흐름은 생각보다 단순합니다.

문서 업로드
↓
Chunking
↓
Embedding
↓
Vector DB 저장
↓
질문(Query)
↓
유사한 문서 검색(Retrieval)
↓
LLM에게 Context와 함께 전달
↓
최종 답변 생성

 

1. 문서를 그대로 넣지는 않는다

처음에는:

"문서를 통째로 넣으면 되는 거 아닌가?"

라고 생각할 수 있습니다.

 

하지만 실제 문서는:

• 너무 길고
• 토큰 제한이 존재하며
• 불필요한 내용도 많습니다.

그래서 필요한 과정이 바로:

Chunking

입니다.

 

2. Chunking

Chunking은 문서를 작은 단위로 나누는 과정입니다.

예를 들어:

긴 PDF 문서
→ 여러 개의 작은 문서 조각(Chunk)으로 분리

하는 방식입니다.

이렇게 해야 질문과 관련된 일부 내용만 검색할 수 있습니다.

 

3. Embedding & Vector DB

나뉜 Chunk들은 숫자 벡터(Vector) 형태로 변환됩니다.

이 과정을:

Embedding

이라고 합니다.

그리고 변환된 벡터들은 Vector DB에 저장됩니다.

 

이번 실습에서는:

• FAISS

를 사용했습니다.

 

4. Retrieval

질문이 들어오면,
질문과 가장 유사한 문서 Chunk를 검색합니다.

예를 들어:

"출석 인정은 어떻게 하나요?"

라는 질문이 들어오면,

관련성이 높은 문서 3~4개 정도를 가져오는 방식입니다.

---

RAG Chain

LangChain에서는 이러한 흐름을 Chain 형태로 매우 간단하게 구성할 수 있습니다.

핵심 흐름은 아래와 같습니다.

Retriever
↓
관련 문서 검색
↓
format_docs()
↓
문서 합치기
↓
Prompt
↓
LLM
↓
최종 답변 생성

 

Retriever

Retriever는:

Vector DB에서 유사도가 높은 문서를 검색하는 역할

을 합니다.

 

즉, 질문과 가장 관련된 Chunk들을 가져오는 단계입니다.

 

format_docs()

검색된 문서는 여러 개로 나뉘어 있습니다.

하지만 프롬프트는 결국 하나이기 때문에,
검색 결과를 다시 하나의 문자열로 합쳐야 합니다.

예시:

def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

 

Prompt

합쳐진 문서는 Prompt의 {context} 부분으로 들어갑니다.

즉,

Prompt = Query + Context

구조가 실제로 여기서 만들어지는 것입니다.

 

Chain으로 연결

LangChain에서는 이러한 흐름을 파이프(|) 형태로 연결할 수 있습니다.

rag_chain = (
    {
        "context": itemgetter("input") | retriever | format_docs,
        "question": itemgetter("input")
    }
    | prompt
    | llm
)

이러한 방식을:

LCEL(LangChain Expression Language)

이라고 부릅니다.

복잡한 흐름도 체인처럼 직관적으로 연결할 수 있다는 장점이 있습니다.