[RAG] LLM 기반 RAG 시스템 아키텍처 정리: Retriever·Reranker·Chunking 전략까지

안녕하세요 티아입니다👋

요즘, LLM을 공부하면 RAG라는 단어를 들어보지 않을 수 없을 정도인데요,

이 RAG가 무엇인가 공부하며 제가 이해한 내용에 대해

포스팅해보려 합니다.

 

 

---

 

1. RAG가 해결하는 문제 정의

기본적인 LLM은 고정된 파라미터 안의 분포 정보만 사용하기 때문에,

1. 모델 파라미터 밖의 지식(사내 문서, 도메인 스키마, 최신 데이터)을 반영할 수 없고,
2. 사실 기반 응답 보장이 어렵고,
3. 업데이트하려면 재학습 또는 미세조정이 필요하다는 구조적 한계를 가진다.

RAG는 이 문제를 해결하기 위해
외부 지식 소스(retriever)와 LLM(generator)을 분리하여 결합하는 아키텍처다.

---

2. RAG의 핵심 개념 (기술적으로 정확한 정의)

RAG(Retrieval-Augmented Generation)는 질의(q)에 대해 LLM을 실행하기 전에,
벡터 검색을 통해 관련 문맥 d₁…d_k를 retrieval하여
LLM의 context window에 주입하고 조건부 생성 p(y | q, d₁…d_k)를 수행하는 구조.

공식적으로 표현하면:

y = argmax p(y | q, R(q), θ)

 

여기서

• q: 사용자 질의
• R(q): retriever가 반환한 top-k 문서 집합
• θ: LLM 파라미터
• y: 생성된 응답

즉, 모델 파라미터에 지식을 저장하지 않고 외부 문서로 지식을 주입하는 방식이다.

 

---

3. RAG 시스템 구성 요소

AI 개발자에게 설명할 때 반드시 이 4가지 컴포넌트를 구분해야 한다.

1) Document Store

• 원문 텍스트, PDF, HTML, DB 레코드 등
• chunking 전략(semantic chunk, recursive chunking), metadata 관리 포함

2) Retriever

• Sparse (BM25)
• Dense (Sentence-BERT, E5, ColBERT, GTE 등)
• Hybrid Retrieval 가능
  retrieval quality가 RAG 전체 품질을 결정한다.

3) Reranker (선택)

• Cross-encoder 기반 재랭킹
• 미세조정된 BERT / E5-large / monoT5 등
• 노이즈 높은 도메인에서는 필수에 가깝다.

4) Generator (LLM)

retrieved chunk를 바탕으로

• grounding된 응답 생성
• hallucination 억제
• citation 포함 응답 등 수행

---

4. Chunking 전략이 중요한 이유?

RAG의 retrieval은 chunk 단위로 문서를 검색한다.
따라서 chunk를 어떻게 나누느냐에 따라 retrieval precision/recall, grounding 품질, hallucination 확률이 직접적으로 바뀐다.

(1) Chunk가 너무 크면 발생하는 문제

• 하나의 chunk에 irrelevant content(비관련 내용)이 같이 들어가서
  retriever가 “부분적으로만 관련 있어도” 매칭해버림 → 노이즈 증가
• LLM context window를 불필요하게 압박
• LLM이 어떤 정보가 핵심인지 판단하기 어려워져 hallucination 가능성 증가

예: PDF 표 전체를 하나의 chunk로 넣으면, 특정 셀만 필요해도 전체가 주입됨.

(2) Chunk가 너무 작으면 발생하는 문제

• 의미 단위가 분리되어 semantic coherence 손실
  (“의도–결론” 구조가 찢어지는 경우)
• retriever가 의미를 충분히 포착하지 못해서 recall 저하
• retrieval이 여러 개로 분산되며 prompt가 조각나 LLM이 맥락을 복구하기 어려움

(3) 결론: Chunking은 retrieval quality의 절반이다

Chunk는 단순 슬라이싱이 아니라,
‘LLM이 답변을 만드는 데 필요한 최소 의미 단위’를 최대한 손상 없이 유지하는 전략이다.

그래서 실제 실무에서는 다음과 같은 기법을 사용한다:

• Recursive Semantic Chunking
• Sliding window chunk
• 문단/문장 기반 segmentation + embedding similarity 기반 merge
• Table-aware chunking (표의 row/column을 logics 단위로 분리)

잘못된 chunking은 좋은 retriever를 써도 품질이 떨어지는 병목이 된다.

 

---

5. Retriever를 기술적으로 이해하기

Retriever는 결국
질의 q와 문서 chunk d_i의 embedding을 비교하여 relevance를 평가하는 모듈이다.

개발자가 이해해야 하는 Retriever의 핵심 요소는 아래 세 가지다.

 

---

(1) Sparse Retriever (BM25, Elasticsearch)

• 단순 단어 매칭 기반 (TF-IDF 확장)
• 장점: 키워드 기반 검색에는 매우 강함. 빠름. 해석 용이.
• 단점: 동의어 처리 불가, 의미 기반 매칭 약함.

하지만 법률/의료/기술문서처럼 키워드가 명확한 도메인에서는 여전히 강력하다.

 

(2) Dense Retriever (Embedding 기반)

Dense retriever는 문장 단위 의미를 벡터 공간에 투영하여 유사도 검색을 수행한다.

대표 모델:

• Sentence-BERT / KoSentenceBERT
• E5-small/base/large
• GTE-base/large
• bge / Jina Embedding
• ColBERT / ColBERTv2 / SPLADE (interaction-based retrieval)

Dense retrieval의 강점:

• 질문과 문서가 단어가 달라도 의미가 같으면 잘 매칭됨
• LLM 기반 시스템에서는 사실상 표준

약점:

• out-of-domain에서는 embedding quality 급락
• fine-tuning 없으면 성능이 불안정할 수 있음

 

(3) Interaction-based Dense Retriever

문장 전체를 하나의 벡터로 만들지 않고
token-level interaction을 기반으로 검색한다.

예: ColBERT

• 각 토큰 벡터를 유지한 상태에서 질의-문서 간 pairwise similarity 수행
• 정확도가 매우 높지만 비용이 높음
• 큰 시스템에서는 ANN(Index: FAISS, ScaNN, Milvus)를 결합해 속도 문제 해결

 

(4) Hybrid Retriever

Sparse + Dense 결합

예:

• BM25로 top-N 후보 추출 → dense로 re-ranking
• Sparse/Dense score weighted fusion

하나만 쓰는 것보다 품질이 월등히 높음.

---

6. Reranker가 필요한 이유

Retriever는 보통 fast but approximate 검색을 수행한다.
즉, “빠르게 비슷한 문서”를 가져오지만 완벽하게 판단하진 못한다.

Reranker는 여기서 정확한 relevance 판단을 수행하는 역할이다.

---

(1) Retrieval 단계를 보완하기 위해 존재

Dense retriever는 cosine similarity 기반 ANN 검색을 하기 때문에 다음 한계가 있다:

• 토큰 중요도 반영이 약함
• fine-grained semantics 판단이 어렵다
• domain-specific 문서는 embedding space가 왜곡되기 쉬움

즉, retriever가 가져온 top-k 문서에는 노이즈가 섞일 확률이 높다.

 

(2) Reranker는 Cross-encoder 구조로 훨씬 정밀하다

retriever는 q와 d를 독립적으로 embedding하지만,

Reranker는 q와 d를 concat한 후
Transformer 내부에서 직접 상호작용을 계산한다.

예:
score = CrossEncoder(q, d)

이 방식은 semantic relevance를 LLM 수준에서 판단하므로
retriever보다 정확도가 월등히 높다.

대표 모델:

• monoT5
• E5 reranker
• bge-reranker
• MiniLM-reranker

 

(3) 노이즈 높은 도메인에서는 사실상 필수

다음 상황에서는 retriever alone으로는 품질이 확보되지 않는다:

• 전자상거래(토큰 중복, 변형 표기, noise term 지나침)
• 의료(약어, 전문어 다수)
• 법률(서술형 길고 구조적 표현 많음)
• 사용자가 질문을 모호하게 던지는 경우
• PDF 기반 RAG (표, 이미지 등 구조화 약함)

이때 Reranker는 top-100 → top-10 → top-3 과정에서
실제 필요한 문서만 남겨 hallucination을 줄이는 핵심 역할을 한다.

 

(4) 최종적으로 LLM의 grounding 품질에 직접적 영향

LLM이 참고하는 문서는 retriever의 top-k가 아니라
reranker가 선별한 문서다.

따라서 Reranker 품질은 LLM 응답 품질로 직결된다.

---

7. 일반 LLM 대비 RAG의 장점 (기술적 관점)

1) Parametric Knowledge와 Non-parametric Knowledge의 분리

• 지식을 모델 파라미터에 넣지 않고 외부에서 주입하므로
  업데이트 주기와 배포 비용이 낮아짐.

2) 데이터 유실 없이 최신성 유지

• 재학습 없이 문서만 갱신하면 됨.

3) 도메인 문서 기반 답변 정확도 개선

• grounding 정보가 들어와서 hallucination 감소.

4) Large Context Window의 비용 압축

• 굳이 전체 문서를 LLM에 넣을 필요 없이
  retriever가 필요한 parts만 공급.

5) Compliance / Auditing 용이

• 어떤 문서를 참고했는지 citation이 가능하므로
  검증 가능성과 책임소재(traceability)가 확보됨.

 

---

8. RAG의 한계 (AI 개발자가 반드시 이해해야 할 부분)

1) Retrieval quality가 전체 성능을 좌우

• retriever가 잘못된 문서를 넘기면 LLM은 잘 생성해도 근거가 틀린 답변이 나온다.

2) Chunking 전략의 영향

• 너무 작은 chunk → context 분리로 의미 손실
• 너무 큰 chunk → irrelevant content 증가로 품질 저하

3) Domain-specific 어휘 문제

• 한국어 전자상거래, 법률, 의료 등에서는 dense embedding이 충분히 잘 학습되지 않아 out-of-domain 간극이 큼
  → retriever fine-tuning 또는 continual pretraining 필요

4) Real-time retrieval latency

• 검색 + LLM 생성이라 end-to-end latency가 증가