RAG Analysis

Retrieval-Augmented Generation (RAG) 심층 분석

Retrieval · Augmentation · Generation · Embedding/Vector DB · Hybrid Search · Reranking · GraphRAG

RAG(Retrieval-Augmented Generation)는 LLM에 외부 지식을 검색해 붙여 답하게 하는 프레임워크입니다. 모델의 가중치에 든 지식(parametric memory)만으로는 환각·지식 컷오프·비공개 데이터 미지원이라는 한계가 있는데, RAG는 질문에 관련된 문서를 검색해 프롬프트에 넣음으로써 이를 보완합니다. Lewis et al.(2020, NeurIPS)이 제안한 이래 LLM 응용의 핵심 인프라가 되었습니다. 본 문서는 전체 파이프라인 → 왜 RAG인가 → 검색의 내부 → 진화(Naive·Advanced·Modular)와 최적화 → 평가·프론티어의 순서로 분석합니다.

실무 관점에서 RAG는 단순히 "검색을 붙인 챗봇"이 아니라, 데이터 갱신 주기와 출처 추적, 응답 지연, 인프라 비용을 함께 설계해야 하는 시스템 문제입니다. 같은 LLM을 사용하더라도 청킹 방식, 임베딩 모델, 검색기 조합, 리랭킹 여부에 따라 정확도와 비용이 크게 달라지므로, 검색 파이프라인 자체를 하나의 제품 컴포넌트로 다뤄야 합니다.

1. RAG 전체 파이프라인

RAG는 이름 그대로 검색(Retrieval)·증강(Augmentation)·생성(Generation)의 세 단계로 작동합니다. 크게 보면 문서를 미리 벡터로 저장하는 오프라인 인덱싱과, 질문이 들어올 때마다 검색·증강·생성하는 온라인 질의로 나뉩니다.

그림 1. 인덱싱(오프라인)과 질의(온라인: 검색→증강→생성)의 전체 흐름

두 단계

• 인덱싱(오프라인) — 문서(PDF·웹·DB)를 작은 청크로 쪼개고, 임베딩 모델로 벡터화한 뒤, 벡터 DB(인덱스)에 저장합니다.

• 질의(온라인) — 질문을 같은 임베딩 공간으로 변환해 벡터 DB에서 유사한 top-k 청크를 검색하고(Retrieval), 그 청크를 질문과 함께 프롬프트에 넣어(Augmentation), LLM이 근거에 기반해 답을 생성합니다(Generation).

원논문(Lewis et al., 2020)은 밀집 검색기 DPR(Dense Passage Retrieval)로 위키피디아에서 top-5 passage를 검색하고 BART 생성기로 답을 만들었습니다. 핵심 개념은 두 가지 메모리의 결합입니다. LLM 가중치에 든 parametric memory와 외부 DB인 non-parametric memory를 함께 쓰며, 외부 DB만 갱신하면 모델 재학습 없이 지식을 업데이트할 수 있고 답의 근거(citation)도 보여줄 수 있습니다.

2. 왜 RAG인가 — LLM의 한계 보완

LLM은 학습된 가중치에만 의존하므로 세 가지 구조적 한계가 있습니다. RAG는 외부 지식을 검색해 이를 보완합니다.

그림 2. RAG가 해결하는 LLM의 세 문제, 그리고 RAG vs 파인튜닝

RAG가 해결하는 문제

• 환각(Hallucination) — 모르는 것을 그럴듯하게 지어냅니다. RAG는 검색된 근거에 기반해 답하므로 사실성과 신뢰성이 올라갑니다.

• 지식 컷오프 — 학습 시점 이후의 사건을 모릅니다. RAG는 최신 문서를 검색해 반영합니다(DB만 갱신).

• 비공개·도메인 지식 — 사내 문서나 전문 자료를 모릅니다. RAG는 조직 DB를 연결해 활용합니다.

RAG vs 파인튜닝

둘은 역할이 다릅니다. RAG는 '지식'을 외부에서 주입하는 데 강하고(새 정보·사실 반영·출처 추적·저비용 갱신), 파인튜닝은 '행동·스타일'을 학습시키는 데 강합니다(말투·출력 형식·도메인 추론 능력의 내재화). 사실·최신성·출처가 중요하면 RAG, 말투·형식·도메인 능력이면 파인튜닝이며, 둘을 함께 쓰기도 합니다. 다만 RAG에서는 검색 품질이 답의 상한선입니다 — 관련 없는 청크를 넣으면 답도 나빠지므로(garbage in, garbage out), 검색 단계의 품질이 결정적입니다.

핵심 개념

1. Chunking

원문 문서를 얼마나 잘게 나누는지는 검색 품질의 출발점입니다. 청크가 너무 크면 불필요한 문맥이 많이 따라와 컨텍스트 창을 낭비하고, 너무 작으면 답에 필요한 연결 정보가 끊깁니다. 실무에서는 문단 기반 분할, 슬라이딩 윈도우, 제목/섹션 경계 유지, 표/코드 블록 보존 같은 전략을 함께 사용합니다.

2. Embedding and Retrieval

질문과 문서를 같은 벡터 공간으로 보내는 임베딩 모델이 검색기의 의미 이해 능력을 좌우합니다. 임베딩이 좋지 않으면 리랭킹을 추가해도 상위 후보군 자체가 어긋날 수 있습니다. 그래서 도메인 특화 임베딩, 하이브리드 검색, 메타데이터 필터링이 함께 설계됩니다.

3. Augmentation and Grounded Generation

검색된 청크를 프롬프트에 어떻게 배치하느냐도 중요합니다. 단순 나열보다 질문, 검색 근거, 답변 지침, 인용 형식을 분리해 주는 편이 안정적이며, 모델이 근거 밖 내용을 추론하지 않도록 제약하는 프롬프트 설계가 필요합니다. 이 단계가 약하면 검색은 맞았는데 답변이 근거를 놓치거나 과장하는 문제가 생깁니다.

4. Reranking and Evaluation

1차 검색으로 모은 후보를 cross-encoder나 late-interaction 모델로 다시 정렬하면 정확도가 크게 오를 수 있습니다. 동시에 RAGAS 같은 평가 체계를 통해 실패가 검색 문제인지 생성 문제인지 분리해야, 임베딩 교체가 필요한지 프롬프트 수정이 필요한지 판단할 수 있습니다.

3. 검색의 내부 — 임베딩·유사도·하이브리드

RAG의 심장은 검색입니다. 텍스트를 벡터로 바꾸는 임베딩, 가까운 벡터를 찾는 유사도 검색, 그리고 대규모에서 빠르게 찾는 인덱스가 핵심입니다.

그림 3. 임베딩 공간, dense/sparse/hybrid 검색, ANN 벡터 인덱스

검색의 구성 요소

• 임베딩 — 임베딩 모델이 질문과 청크를 고차원 벡터로 변환합니다. 의미가 비슷하면 벡터 공간에서 가깝습니다. 유사도 검색은 질문 벡터에 가장 가까운(코사인 유사도 등) top-k 청크를 찾습니다.

• Dense vs Sparse — Dense(임베딩 기반)는 동의어·문맥에 강하지만 드문 고유명사·정확 키워드엔 약합니다. Sparse(BM25 등 키워드 기반)는 정확 일치·코드·약어에 강하지만 의미엔 약합니다. Hybrid는 둘의 top-k를 합쳐 리랭킹하는 방식으로, 현재 실무 표준입니다.

• ANN 인덱스 — 수백만~수십억 청크를 전수 비교하면 느리므로, HNSW·IVF 같은 근사 최근접 이웃(ANN) 알고리즘으로 정확도를 약간 양보하고 속도를 크게 높입니다. 벡터 DB(FAISS·Milvus·Qdrant·pgvector 등)가 인덱스·메타데이터·필터링을 담당합니다.

검색기에는 두 종류의 인코더가 쓰입니다. bi-encoder는 질문과 문서를 따로 임베딩해 빠르게 1차 검색하는 데 쓰이고, cross-encoder는 질문과 문서를 함께 넣어 정확한 점수를 매기지만 느려서 주로 리랭킹에 쓰입니다. ColBERT 같은 late-interaction 방식은 토큰 단위 유사도로 둘의 절충을 노립니다.

4. RAG의 진화와 최적화

RAG는 단순한 형태에서 출발해 검색 품질을 높이는 여러 기법으로 발전했습니다. Gao et al.(2023)의 서베이는 이를 Naive·Advanced·Modular의 세 패러다임으로 정리합니다.

그림 4. Naive→Advanced→Modular 패러다임과 검색 전·중·후 최적화 지점

세 패러다임

• Naive RAG — 검색→증강→생성의 기본 형태. 단순 top-k 검색으로, 종종 검색 정밀도와 정보 통합이 부족합니다.

• Advanced RAG — 검색 전후에 최적화를 추가합니다(아래 참조). 검색 품질을 높이는 데 집중합니다.

• Modular RAG — 각 요소를 교체 가능한 모듈로 만들어, 질문 유형별 라우팅·결과 부족 시 반복·외부 도구 호출까지 유연하게 조합합니다(에이전트형으로 이어짐).

Advanced RAG의 최적화 지점

대표 기법 — HyDE는 LLM이 '가상의 답변'을 먼저 생성하고 그 임베딩으로 검색해 질문-문서 간 표현 간극을 줄입니다. Multi-query는 한 질문을 여러 변형으로 확장해 각각 검색함으로써 누락을 줄입니다. 리랭킹은 빠른 bi-encoder로 20개 정도의 후보를 모은 뒤 정확한 cross-encoder로 재점수해 상위 5개를 고르는 식으로, 임베딩만으로는 놓치는 미묘한 관련성을 잡아 품질을 크게 높입니다.

비교/분석

5. 평가와 프론티어

그림 5. RAGAS 평가 지표, 검색/생성 두 축 분해, 그리고 RAG의 프론티어

평가 — RAGAS

RAG 품질은 검색 품질과 생성 품질로 분해해 평가합니다. RAGAS(2023)는 이를 네 지표로 진단합니다.

RAGAS는 참조 답 없이(reference-free) LLM-as-judge로 평가할 수 있어, 실패가 검색에서 났는지 생성에서 났는지 진단하는 데 유용합니다. 합성 테스트셋 생성도 지원합니다.

프론티어 — RAG의 현재

• GraphRAG — 문서를 청크가 아니라 (엔티티, 관계, 엔티티) 그래프로 표현합니다. 질의 시 그래프를 순회해 여러 문서를 잇는 다중 홉(multi-hop) 질문에 강합니다.

• Agentic RAG — 한 번의 검색이 아니라, 에이전트가 검색-평가-재검색을 반복하고 도구를 호출하는 자기교정 루프입니다(Self-RAG·CRAG·Adaptive RAG 등).

• RAG vs Long-context — 100만 토큰급 긴 문맥 모델이 RAG를 대체할지에 대한 논쟁이 있습니다. 다만 비용·지연·갱신성 측면에서 RAG가 여전히 유효하며, 둘은 상호 보완적으로 쓰입니다.

동작 원리

RAG의 실제 동작은 오프라인 인덱싱과 온라인 서빙으로 분리해 보면 명확합니다. 먼저 오프라인 단계에서 원문 문서를 수집하고, 정제 후 청크로 분할하며, 각 청크에 임베딩과 메타데이터를 붙여 벡터 DB나 검색 인덱스에 저장합니다. 이때 제목, 문서 유형, 작성 시점, 보안 등급 같은 필터링용 메타데이터를 같이 넣어 두면 검색 정밀도를 높이기 쉽습니다.

온라인 단계에서는 사용자의 질문을 정규화한 뒤 검색 질의로 바꾸고, dense/sparse 또는 hybrid 검색으로 후보 청크를 찾습니다. 이어서 리랭킹으로 우선순위를 다시 조정하고, 선택된 청크를 프롬프트의 근거 문맥으로 삽입합니다. 마지막으로 LLM이 답을 생성하되, 필요하면 인용 형식이나 "근거가 없으면 모른다고 답하기" 같은 제약을 함께 적용합니다. 이 흐름에서 병목은 검색 지연, 과도한 컨텍스트 길이, 낮은 근거 적합도 세 곳에서 주로 발생합니다.

장단점

장점

• 최신 문서나 사내 데이터처럼 학습 후에 바뀌는 지식을 빠르게 반영할 수 있습니다.
• 답변 근거를 함께 제시하기 쉬워 감사 가능성과 신뢰성을 높이기 좋습니다.
• 파인튜닝 없이도 특정 도메인 지식을 연결할 수 있어 초기 적용 비용이 낮습니다.

단점

• 검색 단계가 약하면 생성 단계가 좋아도 전체 품질이 크게 떨어집니다.
• 청킹, 임베딩, 인덱스, 리랭커, 프롬프트를 함께 튜닝해야 해서 운영 복잡도가 높습니다.
• 검색 지연과 긴 컨텍스트 비용이 누적되면 단순 LLM 호출보다 응답 시간이 길어질 수 있습니다.

관련 기술

• Dense retrieval: DPR, Contriever, E5, BGE 계열 임베딩 모델
• Sparse retrieval: BM25, SPLADE
• Reranking: cross-encoder, ColBERT, late interaction
• Vector DB / Index: FAISS, Milvus, Qdrant, pgvector, Elasticsearch hybrid search
• 확장 패턴: GraphRAG, Self-RAG, CRAG, Adaptive RAG, Agentic RAG

참고 문헌

• Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020
• Gao et al., "Retrieval-Augmented Generation for Large Language Models: A Survey", 2023
• Gao et al., "Precise Zero-Shot Dense Retrieval without Relevance Labels", 2022
• Es et al., "RAGAS: Automated Evaluation of Retrieval Augmented Generation", 2023
• Microsoft Research, GraphRAG 기술 문서

핵심 정리

RAG는 LLM 바깥의 지식을 검색해 답변 근거로 붙이는 구조이며, 최신성·출처 추적·도메인 데이터 연결에 강합니다. 실제 성능은 생성 모델보다 검색 파이프라인 품질에 더 크게 좌우되므로, 청킹·임베딩·하이브리드 검색·리랭킹·평가를 함께 설계해야 합니다. Naive RAG에서 Advanced, Modular RAG로 갈수록 정확도와 유연성은 올라가지만 운영 복잡도도 함께 증가합니다. 긴 문맥 모델이 발전해도 비용과 갱신성, 감사 가능성 때문에 RAG는 계속 독립적인 역할을 가질 가능성이 큽니다.

주의 — 본문은 원논문·서베이(RAG Lewis et al. 2020 NeurIPS arXiv 2005.11401, RAG 서베이 Gao et al. 2023 arXiv 2312.10997, HyDE Gao et al. 2022, RAGAS Es et al. 2023 arXiv 2309.15217)와 프레임워크 문서·기술 자료에 기반한다. RAG는 빠르게 진화하는 분야라 '실무 표준'·세부 기법의 우열은 데이터·도메인·워크로드에 따라 달라지며, 어떤 청킹·임베딩·검색·리랭킹 조합이 최적인지는 평가를 통한 튜닝이 필요하다('easy to use, hard to master'). RAG vs long-context 논쟁의 결론도 비용·지연·정확도 요구에 따라 사례별로 다르다.