RAG 고급 패턴

문서 기준: 2026년 8월 | 이 문서는 변동이 빠른 영역으로 분기별 리뷰 대상입니다.

기본 RAG의 한계

단순히 “문서 → 임베딩 → 검색 → LLM에 전달”만으로는 실무 품질을 맞추기 어렵습니다. Azure와 AWS 공식 가이드가 공통으로 지적하는 문제:

청킹(Chunking)이 잘못되면 문맥이 잘려서 검색 품질이 떨어집니다.
검색된 문서 중 정말 관련 있는 것을 상위에 올리는 Re-ranking 없이는 LLM이 엉뚱한 맥락을 참조합니다.
사용자 질문이 모호하면 벡터 검색만으로는 답을 찾기 어렵습니다. (예: 대명사, 축약어)

출처:

청킹 전략

문서를 얼마나, 어떻게 나눌지가 검색 품질을 결정합니다.

주요 청킹 방식

방식	설명	적합한 문서 유형
Fixed-size	고정 크기(예: 512토큰)로 단순 분할	일반 텍스트, 블로그
Sentence-based	문장 단위로 분할	자연어 문서
Recursive	단락 → 문장 → 단어 순서로 계층 분할	구조화된 문서
Semantic	의미가 비슷한 문장을 묶어 분할	긴 설명문
Document-structure	헤딩, 섹션 기반 분할	매뉴얼, 위키, 기술 문서

Azure 공식 가이드는 Fixed-size → Recursive → Document-structure 순으로 난이도를 높이며 시도할 것을 권장합니다 (Chunking Phase 문서).

청크 크기 가이드

너무 작으면 — 문맥이 부족해서 검색된 조각이 의미를 잃음
너무 크면 — 한 청크에 여러 주제가 섞여 검색 정확도 하락, LLM 토큰 소비 증가

일반적인 시작점 (Azure 가이드):

청크 크기: 500–1500 토큰
중첩(Overlap): 청크 간 10–20% 겹침으로 문맥 유실 방지

벤더 제공 청킹 옵션

벤더	지원 방식	참고
AWS Bedrock Knowledge Bases	기본, 고정 크기, 계층적(Hierarchical), 시맨틱(Semantic) 청킹	Knowledge Bases 청킹 옵션
Azure AI Search (Foundry IQ)	통합 벡터화 시 자동 청킹, 사용자 정의 가능	Azure AI Search 청킹
Vertex AI RAG Engine	청크 크기/중첩 설정, RagManagedDb 자동 관리	RAG Engine 문서

관리형 RAG 파이프라인

청킹, 임베딩, 검색, 리랭킹을 직접 구축하는 대신 관리형 서비스로 파이프라인 전체를 위임할 수 있습니다.

벤더	서비스	특징
AWS	Amazon Bedrock Managed Knowledge Base	2026.06 GA. 6개 네이티브 데이터 커넥터(S3, SharePoint, Confluence, Web Crawler, Google Drive, OneDrive), Smart Parsing(멀티포맷 자동 파싱), Agentic Retriever(복잡한 멀티스텝 쿼리를 에이전트가 분해·검색), 관리형 벡터 스토어. AgentCore Gateway MCP 통합
Azure	Azure AI Search (Foundry IQ)	통합 벡터화, 시맨틱 랭커 내장, 커스텀 스킬 파이프라인. Microsoft Foundry 포털의 관리형 지식 계층으로도 활용
Google Cloud	RAG Engine (Gemini Enterprise Agent Platform)	소스 연결 → 임베딩 → 검색을 통합 관리. Cross Corpus Retrieval(여러 RAG 코퍼스 동시 검색, 프리뷰). RagManagedDb로 인프라 자동 관리

Re-ranking

벡터 검색은 빠르지만 “정말 관련 있는 순서”로 정렬하지는 못합니다. Re-ranking 은 검색 결과 상위 N개를 별도 모델로 재정렬하여 정확도를 높입니다.

graph LR
    Q[질문] --> V[벡터 검색<br/>상위 50개]
    V --> R[Re-ranker<br/>관련도 재평가]
    R --> T[상위 5개]
    T --> L[LLM]

벤더별 Re-ranking 서비스

벤더	서비스	참고
AWS	Bedrock Knowledge Bases Reranker (Amazon Rerank, Cohere Rerank)	Reranker 가이드
Azure	Azure AI Search Semantic Ranker	Semantic Ranker
Google Cloud	Vertex AI Ranking API	Ranking API
OCI	Cohere Rerank (OCI Enterprise AI)	OCI Enterprise AI 모델

하이브리드 검색

벡터 검색만으로는 제품 코드(SKU-12345), 고유명사, 정확한 문자열 매칭에 약합니다. 하이브리드 검색 은 벡터 검색과 전통적인 키워드 검색(BM25)을 조합합니다.

벤더	하이브리드 지원 방식	참고
AWS	OpenSearch Vector + BM25 (RRF 알고리즘)	Hybrid Search
Azure	Azure AI Search 하이브리드 쿼리	Hybrid Search
Google Cloud	Vertex AI Search (자동 하이브리드)	Vertex AI Search
OCI	OCI AI Vector Search에서 SQL로 조합	OCI AI Vector Search

쿼리 확장과 변환

사용자 질문이 짧거나 모호할 때 LLM으로 질문을 재작성하거나 확장합니다.

Query Rewriting — 대명사/축약어를 명시적으로 풀어냄 (예: “그거” → “지난 회의에서 논의한 정책 X”)
Multi-Query — 하나의 질문을 여러 버전으로 생성해 각각 검색
HyDE (Hypothetical Document Embeddings) — LLM이 가상의 답을 생성한 뒤, 그 답을 임베딩하여 검색

공식 가이드:

평가

RAG 시스템은 단순히 “답이 나온다”가 아니라, 검색 품질과 응답 품질을 분리해서 측정해야 합니다.

검색 품질 지표

지표	의미
Recall@K	상위 K개 결과 중 정답 문서를 포함한 비율
MRR (Mean Reciprocal Rank)	정답 문서의 평균 순위의 역수
NDCG (Normalized Discounted Cumulative Gain)	상위 결과일수록 가중치를 주는 랭킹 품질

응답 품질 지표

지표	의미
Faithfulness	생성된 답이 검색된 문서에 근거하는가
Answer Relevance	답이 질문에 실제로 답하고 있는가
Context Precision / Recall	검색된 문맥이 얼마나 정확하고 충분한가

평가 도구

도구	설명	참고
RAGAS	오픈소스 RAG 평가 프레임워크	RAGAS
Azure AI Evaluation SDK	Faithfulness, Relevance 등 내장 메트릭	Evaluation SDK
Amazon Bedrock Evaluations	모델/RAG 평가 통합	Bedrock Evaluations
Vertex AI Evaluation Service	Gen AI 평가 프레임워크	Vertex AI Eval

자주 하는 실수

청크 크기를 한 번 정하고 조정하지 않음 — 대표 질문으로 검색 품질을 측정하지 않아 문맥이 잘리거나 여러 주제가 섞인 청크가 반환됨
Re-ranking 없이 벡터 검색 결과를 그대로 LLM에 전달 — 상위 결과 중 관련 없는 문서가 섞여 환각(Hallucination) 발생
하이브리드 검색을 고려하지 않음 — 제품 코드, 고유명사 등 정확한 문자열 매칭이 필요한 경우 벡터 검색만으로는 찾지 못함

체크리스트

청크 크기와 중첩(Overlap)을 대표 질문으로 검색 품질을 측정하며 조정했는가
Re-ranking(Semantic Ranker, Cohere Rerank 등)을 적용하여 검색 결과 정확도를 높였는가
Faithfulness, Answer Relevance 등 RAG 평가 지표를 정기적으로 측정하는가