RAG System Architecture

Retrieval-Augmented Generation (RAG) 시스템은 자연어 처리(NLP)에서 사용되는 하이브리드 접근 방식으로, 대규모 언어 모델(LLM)의 생성 능력과 외부 데이터 검색 메커니즘을 결합한 것이다.

 

RAG 시스템의 동작

 

• 검색 단계: 사용자의 질의(Query)를 기반으로 관련 외부 문서나 데이터를 검색하여 가져온다. 이를 위해 벡터 데이터베이스나 인덱싱 기술(예: BM25, Dense Passage Retrieval) 이 사용된다.
• 증강 단계: 검색된 데이터를 언어 모델의 입력으로 제공하여 맥락을 풍부하게 만든다.
• 생성 단계: 강화된 맥락을 바탕으로, 언어 모델이 정확하고 최신의 응답을 생성합니다.

 

RAG 시스템의 목표

기 존	- 기존 언어 모델(LLM)은 사전 학습 데이터에만 의존하며, 실시간 정보 반영이 어려움. - 오래된 정보 제공, 사실 오류(hallucination) 발생 가능성 높음. - 맥락이 부족해 복잡한 질의에 한계. - 외부 데이터 검색을 결합해 실시간, 정확한 정보 제공 가능. 맥락 강화로 응답 품질 향상.
원 인	- 사전 학습 데이터의 고정성: 모델은 학습 시점 이후 데이터 업데이트 불가. - 컴퓨팅 자원 제약: 대규모 재학습으로 실시간 업데이트 어려움. - 맥락 이해 부족: 정적 데이터로는 복잡한 사용자 의도 파악 한계.
방 안	- 외부 데이터베이스를 활용한 동적 정보 검색 도입. - 검색된 데이터를 모델 입력에 통합해 맥락 보강. - 실시간 데이터 접근으로 최신 정보 반영 가능성 확보.
기 술	- 벡터 검색: Dense Passage Retrieval(DPR), FAISS로 관련 문서 검색. - 인덱싱: Elasticsearch, BM25로 효율적 데이터 색인. - 통합 프레임워크: LangChain, Haystack으로 검색-생성 통합. - 실시간 처리: API 통합, 캐싱 메커니즘으로 동적 데이터 활용.

 

 

RAG 시스템 아키텍처

RAG 시스템을 설계 시, 기존 LLM과 검색/DB 시스템을 결합하는 구조가 필요하다. 따라서 이 문제 해결을 위한 적합한 아키텍처 스타일을 선택하는 것이 매우 중요하다.

1. Retriever (검색 모듈)
   • 문서 DB, 벡터 DB에서 관련 정보를 검색
   • 예: Elasticsearch, Pinecone, Milvus 등
2. Generator (생성 모듈)
   • LLM이 검색된 문서를 기반으로 텍스트 생성
   • 예: GPT, LLaMA 등

추가 요소:

• Pre/Post Processing: 쿼리 전처리, 결과 후처리
• Cache / Logging / Metrics: 성능 최적화, 모니터링

 

Architecture Style

Layered Architecture (계층형)	책임 분리, 유지보수 쉬움	- Presentation Layer: API / UI - Application Layer: RAG orchestration- Data Layer: 벡터 DB / 문서 DB
Microservices Architecture	독립 배포, 확장 용이	- Retriever 서비스 독립- Generator(LLM) 서비스 독립 - Pre/Post Processing, Logging 각각 서비스화
Event-Driven Architecture	비동기 처리, 확장성 높음	- RAG 요청 → 이벤트 발행 → Retriever/Generator 비동기 처리 - 큐 기반 확장 가능, 실패 재처리 용이
Client-Server	간단한 요청-응답 구조	- 단일 애플리케이션 / 소규모 PoC에서 사용 가능 - 요청 → 검색 → 생성 → 응답

 

추천 조합

RAG 시스템은 보통 Microservices + Layered + Event-Driven를 조합해서 설계한다.

• Microservices: Retriever, Generator, Pre/Post Processor, Logging/Monitoring 각각 독립 서비스
• Layered: 각 서비스 내부 구조를 계층화 (Presentation, Application, Data Layer)
• Event-Driven: 요청 큐를 통해 비동기 처리, 고부하 환경에서도 안정적 확장 가능

아키텍처 흐름 예시

1. 클라이언트 → RAG API 호출
2. API → 이벤트 발행 (RAG 요청)
3. Retriever 서비스: 문서 DB / 벡터 DB 검색 → 결과 이벤트 발행
4. Generator 서비스: LLM으로 문서 기반 텍스트 생성 → 이벤트 발행
5. API → 클라이언트 응답

이 구조는 확장성, 장애 격리, 비동기 처리가 모두 가능

 

RAG Architecture

• 규모 작은 PoC: Layered + Client-Server
• 실제 서비스 / 대규모 트래픽: Microservices + Layered + Event-Driven 조합
• 핵심 고려 사항:
  1. Retriever와 Generator 분리 → 독립 확장 가능
  2. 비동기 처리 → 큐 기반 처리로 안정성 확보
  3. 서비스별 Layered 구조 → 유지보수 용이