[AI] RAG 파이프라인 전체 구조

 

 

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해

 

ㅁ 들어가며

RAG(Retrieval-Augmented Generation)를 처음 접했을 때는 구조가 단순해 보인다.

질문을 받고 → 문서를 찾고 → LLM에게 넘긴다.

그래서 자연스럽게 이렇게 생각하게 된다.

 

“LLM만 잘 고르고, 임베딩만 잘 쓰면 되는 거 아닐까?”

 

하지만 실제로 RAG를 붙여서 몇 번만 질의응답을 반복해보면
금방 다른 감각을 얻게 된다.

• 답변이 애매하다
• 근거 문서가 엉뚱하다
• 모델을 바꿔도 품질이 크게 나아지지 않는다

이때 문제는 대부분 LLM이 아니다.

RAG는 모델 기술이 아니라 아키텍처 문제에 가깝다.
이번 글에서는 RAG를 기능이 아닌 시스템 파이프라인으로 바라보며,
왜 구조 이해가 중요한지 정리해보려 한다.

 

 

ㅁ RAG를 한 줄로 요약하면

Retriever → Ranker → Reader

• Retriever: 관련 문서를 빠르게 찾는다
• Ranker: 그중에서 정말 중요한 문서를 고른다
• Reader: 선택된 문서를 읽고 답변을 생성한다

중요한 점은 LLM(Reader)은 마지막 단계라는 것이다.
앞단이 흔들리면, 아무리 좋은 모델을 써도 결과는 흔들린다.

 

 

ㅁ Retriever - RAG 품질이 시작되는 지점

RAG 품질을 좌우하는 가장 중요한 컴포넌트는 Retriever다.

그리고 Retriever는 하나의 모듈이 아니다.
여러 설계 결정이 겹쳐진 결과물이다.

 

Retriever를 구성하는 요소를 풀어보면 다음과 같다.

• 문서를 어떻게 나눌 것인가 (Chunking)
• 의미를 어떻게 벡터로 표현할 것인가 (Embedding)
• 무엇을 “가깝다”고 판단할 것인가 (Similarity)
• 얼마나 정밀하게 탐색할 것인가 (ANN / HNSW)
• 이 모든 것을 어떻게 저장하고 운영할 것인가 (VectorDB)

즉, Retriever는
Week 2에서 다뤘던 모든 요소가 수렴하는 지점이다.

그래서 RAG에서 검색 품질이 낮을 때
모델보다 먼저 Retriever를 의심해야 한다.

 

ㅁ Dense, Sparse, 그리고 Hybrid Search

Retriever를 구현하는 방식은 크게 세 가지로 나뉜다.

• Dense Retrieval: 벡터 유사도 기반 검색
• Sparse Retrieval: BM25 같은 키워드 기반 검색
• Hybrid Search: 두 방식을 결합

Dense 검색은 의미를 잘 잡지만,
  고유명사나 숫자, 정확한 키워드에는 약하다.

반대로 Sparse 검색은 키워드에는 강하지만
  의미적 유사성은 놓치기 쉽다.

그래서 실무에서는 대부분
  Hybrid Search가 기본 전제가 된다.

이 단계의 목표는 단 하나다.

“정답을 포함할 가능성이 있는 후보군을 최대한 놓치지 않는 것”

 

 

ㅁ Ranker - 빠른 검색과 정확한 판단의 분리

Retriever는 속도가 우선이다.
그래서 결과는 “대략 맞는 후보군” 수준이다.

여기서 필요한 것이 Ranker(Reranker)다.

Ranker는 질의와 문서를 함께 비교해
  정확한 순서를 다시 매긴다.

• Retriever: 빠른 후보 생성 (Recall 중심)
• Ranker: 정밀한 재정렬 (Precision 중심)

이 구조 덕분에
  RAG는 속도와 정확도를 동시에 확보할 수 있다.

실무에서 RAG 품질이 한 단계 올라가는 순간은
  대부분 Reranking을 붙였을 때다.

 

 

ㅁ Reader - LLM은 생각보다 단순하다

많은 경우 LLM이 너무 많은 책임을 떠안고 있다.

하지만 Reader의 역할은 명확하다.

 

주어진 컨텍스트를 바탕으로 답변을 생성하는 것

컨텍스트가 정확하면 모델은 비교적 안정적으로 답한다.

반대로 컨텍스트가 틀리면 환각은 구조적으로 발생한다.

그래서 Hallucination 문제는 프롬프트보다 검색과 컨텍스트 구성 문제인 경우가 많다.

 

 

ㅁ RAG는 검색 기능이 아니라 지식 파이프라인이다

RAG를 제대로 운영하려면
  검색 기능이 아니라 지식 수명주기로 봐야 한다.

• 원본 문서는 SSOT(Source of Truth)
• 벡터는 언제든 재생성 가능한 파생 데이터
• 지식 변경 → 재임베딩 → 재인덱싱 가능해야 함

이 관점이 없으면 운영 중인 RAG는 빠르게 망가진다.

 

 

ㅁ 마무리 - RAG 아키텍처를 이해한다는 것

RAG를 이해한다는 것은 모델을 하나 더 붙이는 방법을 아는 게 아니다.

• 어디서 의미가 결정되는지
• 어디서 품질이 갈리는지
• 어디가 튜닝 포인트인지

이 흐름을 구조로 이해하는 것이다.

그래서 RAG 아키텍처의 핵심은 단순하다.

좋은 답변은 LLM이 아니라,
좋은 검색 파이프라인에서 시작된다.