Naive RAG의 한계를 Query, Retrieval, Generation 세 단계로 나누어 보완하는 Advanced RAG 기법들의 전체 지형을 정리할 수 있습니다.

우선 4주차 과제에서 다룬 Hybrid Search와 Re-ranking을 중심으로 실무 관점에서 리뷰합니다.

개요

3주차에서는 RAG 파이프라인을 구축하고 Golden Dataset으로 품질을 측정하는 방법을 다뤘습니다.

하지만 파이프라인을 만들고 평가해보면 금방 벽에 부딪힙니다. 질문이 조금만 애매해져도 엉뚱한 청크가 끌려오고, 정답 근거를 담은 청크가 Top-K 밖으로 밀려나는 일이 반복되죠.

Advanced RAG는 이런 Naive RAG의 한계를 검색 전(Pre-Retrieval)·검색 후(Post-Retrieval)·생성(Generation) 단계에 별도의 처리 레이어를 끼워넣어 해결하는 접근입니다.

이번 글에서는 다음 내용을 다룹니다.

• Naive RAG가 실패하는 지점
• Advanced RAG를 Query / Retrieval / Generation 3단계 프레임으로 정리
  • Query 단계 개선 기법 (HyDE, Multi-Query, Step-back, RAG-Fusion 등)
  • Retrieval 단계 개선 기법 (Hybrid Search, Re-ranking, Parent Document, ColBERT 등)
  • Generation 단계 및 최신 아키텍처 (Self-RAG, CRAG, GraphRAG, Agentic RAG)
• 4주차 과제에서 구현한 Hybrid Search + Re-ranking 파이프라인

Naive RAG가 실패하는 지점

Naive RAG는 "질문 → 임베딩 → Top-K 벡터 검색 → LLM 생성" 구조가 전부입니다. 단순한 만큼 실패 모드도 단순하게 반복됩니다.

• 키워드 매칭 실패: "1종 수급권자"처럼 도메인 고유 용어가 들어가면 벡터 검색은 의미가 비슷한 다른 표현을 가져오고 정작 필요한 문서를 놓칩니다.
• 검색 정밀도 부족: Top-K 안의 청크 중 실제 질문과 관련 있는 것은 소수입니다. 나머지는 그냥 노이즈죠.
• 검색 재현율 부족: 정답 근거가 Top-K 안에 들어오지 못하면, LLM이 아무리 뛰어나도 답을 만들 수 없습니다.
• Lost in the middle: 긴 컨텍스트의 중간 부분을 LLM이 덜 참조한다는 경향(arxiv 2307.03172). 무작정 Top-K를 늘리면 오히려 품질이 떨어집니다.

따라서 Advanced RAG의 핵심 질문은 두 가지입니다. 질문을 어떻게 바꿔야 좋은 문서를 불러올 수 있는가, 그리고 불러온 문서를 어떻게 정제해야 LLM이 잘 쓸 수 있는가.

이 두 질문이 각각 Query 단계와 Retrieval 단계 기법으로, 그리고 생성 자체를 교정하는 것이 Generation 단계 기법으로 이어집니다.

AI 에이전트 기억이란 무엇인가요? | IBM

AI 에이전트 기억은 인공지 능(AI) 시스템이 과거 경험을 저장하고 회상하여 의사 결정, 인식 및 전체 성능을 향상시키는 능력을 의미합니다.

IBMCole Stryker

Advanced RAG의 3단계 프레임

실무에서 한 번에 다 넣을 필요는 없습니다. 기본 RAG → Hybrid Search + Re-ranking → Query 변환 → Self-reflection 순서로 필요할 때 하나씩 붙여가는 방식이 일반적입니다.

Query 단계 개선 기법

사용자가 던진 질문을 그대로 쓰지 않고, 검색에 유리한 형태로 변환·확장하는 단계입니다. 질문 자체를 바꾸는 레이어라고 생각하시면 됩니다.

HyDE (Hypothetical Document Embeddings)

• 해결하려는 것: 짧은 질문의 임베딩이 실제 문서 임베딩과 분포가 달라 검색이 어긋나는 문제.
• 동작 방식: LLM에게 질문에 대한 가상의 정답 문서를 먼저 생성시키고, 그 문서를 임베딩해서 검색에 사용합니다. 질문↔문서 대신 문서↔문서 유사도로 매칭하는 셈입니다.
• 언제 좋은가: FAQ·사실질의처럼 정답 형태가 일정한 도메인에서 효과가 크고, 반대로 창의적·탐색적 질문에서는 과적합된 가짜 근거를 만들 위험이 있습니다.

Query2Doc

• HyDE와 같은 계열이지만, 가상의 문서 전체를 임베딩하는 대신 원본 질문 + 생성된 구절을 concat해서 사용합니다.
• 원본 질문의 신호를 유지하면서 확장 효과를 가져가는 절충안입니다.

Multi-Query Retrieval

• 해결하려는 것: 하나의 질문 표현으로는 놓치는 의미적 변형.
• 동작 방식: LLM으로 같은 질문을 3~5개로 다시 쓰게 한 뒤 각각 검색하고 결과를 합집합으로 가져옵니다. LangChain의 MultiQueryRetriever가 이 패턴입니다.
• 언제 좋은가: 용어 편차가 큰 도메인(의료, 법률 등)에서 재현율을 끌어올릴 때 유용합니다.

Step-back Prompting

• 해결하려는 것: 질문이 너무 구체적이어서 관련 근거 문서가 검색되지 않는 경우.
• 동작 방식: 원 질문을 한 단계 추상화한 상위 개념 질문으로 먼저 검색합니다. 예를 들어 "2025년 A 제도의 본인부담률은?" → "A 제도의 본인부담률 산정 원칙은?"을 추가로 검색.
• 언제 좋은가: 배경 지식과 구체 수치가 같이 필요한 질의에 강합니다.

Query Decomposition / Sub-question Generation

• 해결하려는 것: 다중 사실(multi-hop)을 요구하는 복합 질문.
• 동작 방식: LLM이 원 질문을 독립적으로 검색 가능한 하위 질문들로 쪼개고, 각각 검색한 뒤 합쳐서 답을 구성합니다. Kong Inc. LlamaIndex의 SubQuestionQueryEngine이 대표적입니다.
• 언제 좋은가: "A와 B를 비교해줘"처럼 두 개 이상의 주제를 동시에 다루는 질문에서 필수에 가깝습니다.

RAG-Fusion

• Multi-Query + Reciprocal Rank Fusion(RRF) 의 조합입니다.
• 여러 변형 질문의 검색 결과를 순위 기반 점수(1/(k+rank))로 재결합해 최종 순위를 만듭니다.

Multi-Query의 합집합 문제(중복·정렬 혼란)를 랭킹 차원에서 해소한다는 점이 차별점입니다.

Query 단계 기법은 대부분 LLM 호출 비용과 지연시간을 대가로 재현율(recall)을 올리는 트레이드오프입니다. 실시간성이 중요한 서비스라면 Multi-Query의 변형 개수나 HyDE 생성 길이부터 먼저 조여보시는 것을 권장드립니다.

Retrieval 단계 개선 기법

질문은 그대로 두고 검색 엔진과 검색 결과 자체를 개선하는 단계입니다.

실무 체감상 가장 투자 대비 효과가 좋은 영역이기도 합니다.

Hybrid Search (Dense + Sparse/BM25)

• 하이브리드 검색은 사실상 Advanced RAG의 기본값입니다.
  • 최신의 검색용 데이터베이스의 경우 많이 지원하는 기능

Re-ranking (Cross-encoder, Cohere Rerank 등)

• Top-K 안의 노이즈와 순서 문제.
• 차 검색으로 Top-20~50을 넓게 가져온 뒤, Cross-encoder(질문·문서를 같이 입력해 관련도 점수를 뽑는 모델) 나 Cohere Rerank / bge-reranker-v2 같은 전용 Reranker로 재정렬하고 상위 3~5개만 LLM에 전달합니다.
• 언제 좋은가: 거의 항상 켜두는 편이 좋습니다. "lost in the middle"을 직접적으로 완화합니다.

Parent Document Retriever

• 해결하려는 것: 청크가 작을수록 검색 정밀도는 오르지만 LLM이 보는 문맥은 파편적이 되는 딜레마.
• 동작 방식: 작은 청크로 검색하고, LLM에는 그 청크의 부모(원 문서·섹션)를 전달합니다.
• 언제 좋은가: 긴 설명이 필요한 기술 문서·매뉴얼에서 특히 유효합니다.

Sentence Window Retrieval

• 문장 단위로 검색하되, 전달 시 그 문장 앞뒤 N개 문장을 윈도우로 함께 전달합니다. Parent Document보다 더 세밀한 단위로 같은 아이디어를 구현한 것입니다.

Auto-merging Retrieval

• 문서를 계층적 청크(큰 덩어리 → 작은 덩어리)로 저장한 뒤, 작은 청크들이 같은 부모 아래에서 다수 검색되면 자동으로 부모 단위로 합쳐서 반환하는 LlamaIndex의 기법입니다.
• 흩어진 청크를 하나의 의미 있는 블록으로 재조립하는 효과가 있습니다.

ColBERT / Late Interaction

• 문서와 질문을 단일 벡터가 아니라 토큰별 벡터 시퀀스로 저장하고, 검색 시 토큰 간 최대 유사도를 합산합니다.
• 일반 벡터 검색보다 정밀도가 높지만 저장 용량·연산량이 많아, 고정밀이 필요한 검색이나 Reranker 대체용으로 선택적으로 도입합니다.
• https://www.youtube.com/watch?v=hh2Bx6DYgpw
• https://www.msap.ai/blog-home/blog/colpali/

MMR (Maximum Marginal Relevance)

• 해결하려는 것: Top-K가 서로 거의 똑같은 청크로 채워지는 중복 문제.
• 동작 방식: 관련도와 다양성을 같이 고려해, 이미 선택된 청크와 유사한 후보에는 페널티를 부여합니다.
• 언제 좋은가: 같은 문서에서 비슷한 문장이 여러 번 반복되는 데이터셋에서 체감 효과가 큽니다.
  • https://wikidocs.net/231585

Generation 단계 개선 및 최신 아키텍처

여기서부터는 단순히 "검색을 잘하자"를 넘어, 생성 과정에서 스스로 검증·재검색·추론을 수행하는 방향의 기법들입니다.

2024~2026년 사이 RAG가 Agent 쪽으로 급격히 기울고 있는 흐름을 반영합니다.

Self-RAG (자가 성찰 RAG)

• 해결하려는 것: 검색이 불필요한 질문에도 무조건 검색해 오히려 품질이 떨어지는 문제.
• 동작 방식: LLM이 특별한 reflection 토큰([Retrieve], [IsRel], [IsSup], [IsUse])을 생성해, 검색 여부와 각 문서의 관련성·근거 일치도·유용성을 스스로 평가합니다.
• 언제 좋은가: 할루시네이션 허용치가 낮은 도메인(의료·법률·금융)에 적합합니다.

CRAG (Corrective RAG)

• 동작 방식: 검색 결과에 대해 경량 evaluator가 Correct / Ambiguous / Incorrect 라벨을 붙이고, Incorrect면 웹 검색으로 대체하며, Ambiguous면 두 소스를 결합합니다.
• Self-RAG가 "내부적 확신"을 평가한다면, CRAG는 "외부 근거로 보정"하는 쪽에 가깝습니다.

GraphRAG

• 해결하려는 것: "이 기업의 주요 리스크 테마는?" 같이 문서 전체를 가로지르는 글로벌 질문에 벡터 검색이 약한 문제.
• 동작 방식: 문서에서 엔티티·관계를 추출해 지식 그래프를 구축하고, 커뮤니티 요약(community summaries)을 미리 만들어 두었다가 글로벌 질문에는 이 요약을, 로컬 질문에는 벡터 검색을 사용하는 하이브리드입니다.
• 언제 좋은가: 수백·수천 건 문서를 관통하는 통찰형 질의.
  • 2025년 들어 Microsoft GraphRAG, LlamaIndex PropertyGraph, Neo4j GraphRAG로 생태계가 빠르게 확장됐습니다.

Agentic RAG

• 검색을 Tool로 정의하고, LLM Agent가 언제·어느 인덱스를 쓸지 스스로 결정 Designveloper하는 구조입니다.
• 여러 인덱스(제품 매뉴얼, 최신 공지, 웹 등)를 Tool로 등록하면 Agent가 질문을 보고 라우팅하며, 필요 시 재검색과 질문 재작성을 반복합니다.
• 2025~2026년 실무 RAG의 사실상 표준으로 자리잡는 중입니다. LangGraph 기반 구현이 특히 많습니다.

Adaptive RAG

• 질문의 복잡도를 먼저 분류해 단순 질문 → 바로 답변, 중간 → 단일 검색, 복잡 → multi-hop / Agentic로 경로를 나눕니다.
• 비용·지연시간을 제어하고 싶은 상용 서비스에서 유효한 전략입니다.

Long RAG

• 해결하려는 것: 작은 청크로 자르면서 생기는 문맥 손실.
• 동작 방식: Long-context LLM(Gemini 1.5/2.x, Claude 3.7/4, GPT-4.1 등)의 긴 컨텍스트 윈도우를 전제로, 청크 자체를 수천 토큰 단위로 크게 유지하고 Top-K를 줄여 전달합니다.

언제 좋은가: 모델 비용이 낮아지고 컨텍스트가 수백만 토큰대로 커지면서, 2025년 이후 "청킹을 덜 해도 되는가"라는 실험이 계속 늘고 있습니다.

실제 프로덕션에서는 이 모든 기법을 한꺼번에 넣기보다는, Hybrid Search + Reranker를 기본 베이스라인으로 두고, 도메인 특성에 따라 GraphRAG(관계형 지식 필요)나 Agentic RAG(다중 소스 라우팅 필요)를 선택적으로 얹는 방식을 선택하게 됩니다.

4주차 과제에서의 실습

이번 과제는 3주차에서 만든 Naive RAG 파이프라인에 Pre-Retrieval / Post-Retrieval 레이어를 실제로 끼워보는 것이 핵심이었습니다. 범위를 넓게 가져가기보다, 위에서 정리한 기법 중 실무에서 가장 먼저 적용하게 되는 3가지에 집중했습니다.

과제에서 구현한 기법

• Hybrid Search: 기존 벡터 검색에 BM25를 결합.
  • LangChain EnsembleRetriever로 가중치(예: [0.5, 0.5])를 두고 병합.
  • 데이터베이스에 따라 검색 지원 형식이 다른 경우 존재
• Re-ranking: Hybrid Search로 Top-20을 가져온 뒤, Cross-encoder 기반 Reranker로 Top-3~5로 축소.
• 메타데이터 필터링: source_year, section 같은 부가 정보로 검색 범위를 사전에 좁히기

핵심 구조를 코드로 보면 다음과 같은 형태입니다.

과제를 하면서 확인한 포인트

• Hybrid 효과​: "1종 수급권자" 같은 고유 용어가 들어간 질문은 BM25가 바로 잡아주고, 의역된 질문은 벡터 쪽이 보완합니다.
• Reranker의 효과: Top-20 안에 정답 청크가 있더라도 순서가 3등 아래에 있으면 답변 품질이 흔들렸는데, Reranker를 붙이면 이 순서 문제가 사라집니다.

메타데이터 필터링은 검색 기법이 아니라 스키마 설계에 가깝습니다. 청킹할 때 어떤 메타데이터를 남길지를 먼저 결정해야 효과가 납니다.

중요한 것은 기법을 많이 쌓는 것이 아니라, Golden Dataset 위에서 각 기법이 붙을 때마다 recall과 정답 정확도가 어떻게 움직이는지 숫자로 확인하는 습관입니다.

기법을 늘릴수록 품질이 오른다는 보장은 없습니다.

정리: Advanced RAG 전체 그림

• Naive RAG의 한계는 특정 한 단계의 문제가 아니라, Query·Retrieval·Generation 세 지점에서 동시에 일어나는 현상입니다.
• 4주차 과제가 다룬 Hybrid Search + Reranker는 가장 비용 대비 효과가 좋은 조합이고, 그 위에 도메인에 따라 Query 변환과 Generation 단계 기법을 덧붙이는 것이 일반적인 진화 경로입니다.
• 2025~2026년 들어 RAG는 Agentic RAG / GraphRAG 방향으로 빠르게 이동 중입니다.
  • 다음 주차의 평가 파이프라인과 함께, 어떤 기법을 어떤 기준으로 선택해야 하는지를 이후 글에서 이어서 다뤄보겠습니다.
• 평가 방법과 각 기법의 정량적 비교는 5주차에서 자세히 다룰 예정입니다.

12화 복잡한 RAG 분해하기-Modular RAG란?

RAG의 성능을 개선하는 비법, 모듈화 | 지금까지 검색증강생성(RAG, Retrieval Augmented Generation)을 구성하는 핵심적인 요소들에 대해 배워보았습니다. RAG 파이프라인을 구성하는 요소인 임베딩 모델과 벡터 DB 그리고 최종적인 LLM 답변의 전체적인 톤 앤 매너와 제약사항 등을 통해 답변을 제어하는 시스템 프롬프트(System Prompt)까지 검색증강생성 파이프라인에

알바트로스알바트로스