[GenAI] 검색 증강 생성 (RAG)이란 무엇인가요?

RAG에 앞서,

 

Foundation Model이란?

Foundation Model은 대규모의 비정형/비지도 데이터를 기반으로 학습된 AI 신경망 모델로, 다양한 작업에 범용적으로 적용될 수 있는 기반 모델을 의미합니다. 기존의 목적 지향적 모델들과 달리, 한 번의 학습으로 다양한 다운스트림 태스크(예: 번역, 요약, 이미지 분석, 질의응답 등)에 소량의 튜닝만으로 적용 가능하다는 점이 가장 큰 특징입니다.

• 데이터: 대부분 라벨 없는 방대한 텍스트, 이미지, 영상 등 비정형 데이터.
• 학습 방식: 주로 자가(supervised) 학습 또는 비지도(unsupervised) 학습.
• 활용 범위: 언어 → 영상 → 멀티모달 → 물리 기반 AI까지 빠르게 확장 중.
• GPT, BERT, PaLM, LLaMA, Claude 등이 여기에 포함됩니다.

 

발전 역사

연도	주요 사건
2017	Google의 Transformer 아키텍처 제안 (Vaswani 외, "Attention is All You Need")
2018	BERT 등장 – 자연어 처리 분야의 전환점
2020	OpenAI GPT-3 공개 (175B 파라미터, 언어 생성을 대중화)
2022	Stable Diffusion 등 텍스트 → 이미지 생성 확산
2023~2024	Multimodal 모델 및 물리 기반 AI(Omniverse, Cosmos 등)로 확장

 

주요 특징

1. Emergence (창발성): 학습하지 않은 태스크에서도 일정 수준의 성능을 보임.
2. Homogenization (동질화): 텍스트, 이미지, 음성 등 다양한 입력을 다룰 수 있는 통합 모델 구조의 등장.
3. Multimodal Processing: 텍스트, 이미지, 비디오, 오디오 등의 데이터를 동시에 처리 및 생성 가능.
4. Scalability: 파라미터 수와 계산량이 기하급수적으로 증가 (예: GPT-3 → Gemini Ultra: 50B PFLOPS 요구).
5. Adaptability: 특정 도메인에 대해 소량의 fine-tuning으로 빠르게 적응 가능.

 

RAG란?

RAG(Retrieval-Augmented Generation)는 신뢰할 수 있는 지식 베이스를 참조하여, 대규모 언어 모델(LLM)이 특정 도메인이나 내부 지식을 기반으로 최적화된 응답을 생성할 수 있는 방법입니다.

 

 

 

RAG는 기본적으로 두 단계로 이루어져 있습니다:

1. Retrieval (검색 단계)
   → 사용자 질문(Query)에 대해 유사한 문서를 DB 또는 벡터DB에서 검색
   → 문서(컨텍스트)를 LLM에게 전달
2. Generation (생성 단계)
   → LLM이 검색된 문서를 참고하여, 사용자 질문에 대한 응답을 생성

 

그렇다면, 왜 RAG가 왜 필요할까?

LLM은 지능형 챗봇을 지원하는 핵심 인공 지능 기술이나, 다음과 같은 한계를 가지고 있습니다.

 

• 지식의 고정성 (Static Knowledge)
  • LLM은 학습 시점까지의 정보만 알고 있음.
  • 최신 정보나 실시간 데이터를 반영하지 못함.
• 사실 오류 (Hallucination)
  • 자신감 있게 틀린 정보를 만들어내는 경향이 있음.
  • 존재하지 않는 문서, 숫자, 인용을 생성할 수 있음.
• 출처 불명확
  • 답변이 어디서 나왔는지 추적이 어려움.
  • 사용자는 신뢰 여부를 판단하기 힘듦.
• 도메인 특화 지식 부족
  • 특정 산업이나 기업 내부 지식 등은 잘 모름. 

 

이러한 문제를 해결하기 위한 접근 방식으로 신뢰할 수 있는 지식 출처를 제공해 텍스트 반환을 잘 제어할 수 있도록 합니다.

 

RAG를 구축하려고 하면, 어떤 게 필요할까?

구성 요소	기술	역할
문서 로딩 & 전처리	LangChain, LlamaIndex	다국어/문서 포맷 다양성 고려. PDF는 OCR 필요할 수도. 데이터 정합성 유지가 핵심.
텍스트 분할기	LangChain RecursiveCharacterTextSplitter	도메인 특화 문서라면 문단/헤더 단위로 custom splitter 설계.
임베딩 생성기	OpenAIEmbeddings, bge, E5, InstructorXL	벡터 크기, 도메인 적합성 고려. LLM과 임베딩 간 언어적 정합성 맞춰야 성능 좋음.
벡터 DB	FAISS, Qdrant, Weaviate, Milvus, Elasticsearch	검색 latency와 scale-out 구조 고려. Qdrant/Weaviate는 멀티노드 운영에 적합.
검색기(Search Retriever)	similarity_search, hybrid retriever, multi-query retriever	Hybrid(BM25 + 벡터)로 precision 향상. 실서비스엔 Reranking 꼭 고려.
LLM	GPT-4, Claude, Mistral, LLaMA2	응답 품질 vs 비용 trade-off. Mistral 7B는 성능 대비 경량화 우수.
Chain / Prompt	LangChain RetrievalQA, ConversationalRetrievalQA, RAGPrompt	기본 Chain은 충분히 커스터마이징. System Prompt 튜닝은 실제 품질 좌우.
서빙	FastAPI, LangServe, Flask	FastAPI + LangChain agent server 구성. FastAPI를 gateway로 사용.
프론트엔드	Vue / React	UI/UX는 검색 결과와 생성된 답변을 분리해서 보여주는 게 신뢰도 ↑
모니터링	Prometheus + Grafana, Sentry, Logtail	임베딩 실패, LLM latency 모니터링. 사용자 Feedback 수집 중요.

 

 

Vector DB 선택 기준

• 로컬 개발, 소규모: FAISS (속도 빠름, lightweight)
• 클라우드 서비스, 다수 사용자: Qdrant (REST API 지원, 멀티노드)
• 엔터프라이즈 통합: Elasticsearch + Dense vector

더 높은 품질의 응답을 반환하기 위해, 현업에서는: Feedback Loop

사용자가 RAG 기반 시스템을 사용한 뒤, 정답인지/오답인지 피드백을 주면, 그걸 바탕으로 모델이 점점 검색 정확도와 응답 품질을 개선해가도록 설계할 수 있습니다.