Post-RAG 아키텍처: GraphRAG, 하이브리드 검색, 평가 체계의 실전 설계
벡터 RAG만으로는 왜 한계가 생기는지, GraphRAG를 언제 도입해야 하는지, 하이브리드 검색과 평가 체계를 어떻게 운영해야 하는지 공식 문서 기반으로 정리합니다.
Post-RAG 아키텍처: GraphRAG, 하이브리드 검색, 평가 체계의 실전 설계
RAG는 이미 기본기가 됐다. 문제는 이제부터다.
실무에서 부딪히는 실패의 대부분은 모델이 아니라 검색 전략과 평가 설계에서 나온다.
이 글은 Microsoft Research, Azure AI Search, Haystack 문서를 기준으로 다음 세 가지를 정리한다.
- GraphRAG는 정확히 어떤 질문에서 이기는가
- 하이브리드 검색은 왜 사실상 기본값이 되었는가
- 평가를 Retriever/Generator로 분리하지 않으면 왜 운영이 망가지는가
한 줄 결론
- 벡터 RAG 단독은 로컬 질의(정답 단서가 좁은 범위에 있는 질문)에는 강하지만, 전역 질의에는 약하다.
- **하이브리드 검색(Dense + Sparse + 리랭크)**은 정확 토큰과 의미 검색을 동시에 잡아 실무 안정성이 높다.
- 평가 체계는 정답률 하나가 아니라, 검색 품질·근거 충실도·운영 비용/지연까지 함께 봐야 한다.
1) 왜 기존 RAG가 자주 흔들리나
벡터 기반 RAG는 "질문과 비슷한 텍스트"를 잘 찾는다.
하지만 실무 질문은 항상 그렇게 단순하지 않다.
- 코드/에러번호/상품코드처럼 정확 매칭이 중요한 질의
- "데이터셋 전체의 테마" 같은 전역 요약 질의
- 여러 엔터티 관계를 함께 봐야 하는 관계형 질의
Microsoft Research가 GraphRAG 논문에서 강조하는 포인트도 같다.
전통적 RAG는 "What are the main themes in the dataset?" 같은 전역 질문에서 한계가 크다.
2) GraphRAG는 언제 써야 하나
GraphRAG의 핵심은 문서를 단순 chunk 집합이 아니라 엔터티-관계-커뮤니티 구조로 다루는 것이다.
논문/프로젝트 설명 기준으로 동작은 대략 다음 순서다.
- 문서에서 엔터티와 관계를 뽑아 그래프를 만든다.
- 관련 커뮤니티 단위 요약을 준비한다.
- 질의 시 부분 응답을 만든 뒤 최종 응답으로 합친다.
잘 맞는 상황
- 리서치/전략 문서처럼 코퍼스 전역 이해가 필요한 경우
- "A와 B의 연결 고리" 같은 관계 탐색 질의가 많은 경우
- 답변의 다양성/포괄성이 중요한 경우
주의할 점
- 그래프 인덱싱과 운영이 무겁다.
- 데이터 갱신이 빠른 환경에서는 유지 비용이 커질 수 있다.
- 단순 FAQ 중심 서비스에는 과투자일 수 있다.
LazyGraphRAG/BenchmarkQED 흐름도 이 지점을 보완하려고 나온다.
즉 "품질은 올리고, 인덱싱/질의 비용은 줄이는" 방향으로 진화 중이다.
3) 하이브리드 검색은 왜 기본 전략이 됐나
Azure AI Search 공식 문서 기준으로 하이브리드 검색은 명확하다.
- full-text(BM25)와 vector 검색을 병렬 실행
- 결과를 **RRF(Reciprocal Rank Fusion)**로 병합
- 필요 시 semantic reranker를 후단에 적용
핵심은 "한 가지 검색에 올인하지 않는다"는 점이다.
- Dense는 의미 유사성에 강함
- Sparse/BM25는 정확 키워드·고유명사·코드에 강함
- RRF는 서로 다른 랭킹 리스트의 상위 항목을 안정적으로 결합
실무에서는 여기에 cross-encoder 리랭커를 추가해 top-k를 정제하는 패턴이 가장 재현성이 좋다.
4) 평가 체계: 정답률 하나로는 부족하다
Haystack 문서가 잘 보여주듯 RAG 평가는 최소 두 층으로 나눠야 한다.
- Retriever 평가: 관련 문서를 제대로 가져왔는가
- Generator 평가: 가져온 근거에 충실하게 답했는가
권장 지표 세트
- Retrieval: Recall@k, MRR/MAP(라벨 기반), context relevance
- Generation: faithfulness, answer relevance, hallucination rate
- 운영: p95 latency, 질의당 비용, 재시도율, 에스컬레이션율
BenchmarkQED가 의미 있는 이유도 여기에 있다.
질의 생성(AutoQ), 평가(AutoE), 데이터 샘플링(AutoD)을 분리해 재현 가능한 비교를 만들기 때문이다.
5) 실전 아키텍처 권장안 (3단계)
1단계: 빠른 성과
- Hybrid retrieval(BM25 + Vector) 도입
- RRF + 리랭커 적용
- 최소 평가 대시보드(Recall/faithfulness/latency/cost) 구축
2단계: 품질 안정화
- 질의 라우터(정확 매칭형, 의미형, 전역형) 도입
- 근거 인용 강제 및 컨텍스트 압축
- 오프라인 회귀셋 + 온라인 샘플 리뷰 운영
3단계: 고급화
- 관계/전역 질의 비중이 높아지면 GraphRAG 계열 도입
- 도메인별 평가셋과 비용 한계선(Budget Guardrail) 함께 운영
6) 아키텍트 관점 체크리스트
- "우리 질문의 대부분은 로컬인가, 전역인가?"
- "정확 토큰(코드/숫자/명칭) 실패가 잦은가?"
- "팀이 평가를 Retriever/Generator로 분리해 보고 있는가?"
- "검색 개선 전, 생성 모델만 계속 바꾸고 있지는 않은가?"
이 네 가지에 답하면, 과도한 모델 교체 없이도 품질이 빠르게 오른다.
마무리
Post-RAG 시대의 경쟁력은 "더 큰 모델"보다 더 좋은 검색 전략과 더 단단한 평가 루프에서 나온다.
순서는 단순하다.
- 하이브리드 검색을 기본값으로 만든다.
- 평가를 검색/생성/운영 지표로 분리한다.
- 전역·관계형 질의가 많아질 때 GraphRAG를 확장한다.
이 흐름을 지키면, 기능 데모가 아니라 운영 가능한 RAG로 넘어갈 수 있다.
참고 링크
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft Research)
- Project GraphRAG (Microsoft Research)
- LazyGraphRAG: Setting a new standard for quality and cost (Microsoft Research Blog)
- BenchmarkQED: Automated benchmarking of RAG systems (Microsoft Research Blog)
- Hybrid search overview (Azure AI Search)
- Hybrid search scoring with RRF (Azure AI Search)
- Evaluation (Haystack docs)
이 글은 공개 문서와 연구/기술 블로그를 기반으로 작성했습니다. 제품 기능과 수치, API 동작은 버전/릴리즈 시점에 따라 바뀔 수 있으니 실제 적용 전 최신 문서를 다시 확인하세요.