RAG 개념 정리 (3) — 벡터 검색이 못 잡는 관계, GraphRAG

2편에서 하이브리드 서치와 리랭킹으로 검색 정확도를 올렸지만, 이걸로도 못 푸는 질문 유형이 있습니다. "이 사건에 연루된 공급업체 중 마르티네즈 계정과 같은 지역 고객에게 영향을 준 곳은?" 같은 질문은 사건 기록, 공급업체 계약, 고객 계좌를 각각 검색해도 관계를 조합하지 못하면 답이 안 나옵니다. 이런 다중 엔티티 추론을 벡터 검색 대신 지식 그래프로 푸는 게 이번 편의 주제, GraphRAG입니다.

🕸️ 벡터 검색이 실패하는 지점

벡터 검색은 "질문과 의미가 비슷한 청크"를 찾는 데는 강하지만, "코퍼스 안의 엔티티들이 서로 어떻게 연결돼 있는가"는 애초에 다루는 방식이 아닙니다. 임베딩 아키텍처 자체가 문서를 각각 고립된 상태로 표현하기 때문에, 문서를 넘나드는 관계 정보가 임베딩 과정에서 사라집니다.

한 벤치마크 분석에서 나온 쿼리 유형별 정확도 차이가 이걸 잘 보여줍니다.

특정 문서를 그냥 찾는 단순 검색은 오히려 벡터 쪽이 낫습니다. 하지만 "여러 문서에 흩어진 정보를 종합해야 하는" 집계·다중 홉 질문에서는 벡터 검색이 거의 무너지고 GraphRAG이 3~4배 앞섭니다. 즉 GraphRAG은 벡터 검색의 상위 호환이 아니라 다른 종류의 질문에 강한 도구입니다.

🏗️ GraphRAG은 실제로 어떻게 동작하나

Microsoft의 오픈소스 구현 기준으로 4단계입니다.

1. 엔티티·관계 추출: LLM으로 원문에서 엔티티와 관계를 뽑아 지식 그래프를 구성
2. 커뮤니티 탐지: Leiden 알고리즘으로 그래프를 밀접하게 연결된 노드 군집(커뮤니티)으로 계층적으로 분할 — 수백만 노드를 수천 개 단위 커뮤니티로 좁혀줌
3. 계층적 요약: 각 커뮤니티를 주요 엔티티·관계·핵심 주장 중심으로 요약(바텀업 방식)
4. 그래프 인식 검색: 질문이 들어오면 먼저 관련 커뮤니티를 찾고, 그 안에서만 탐색

핵심은 2단계입니다. 커뮤니티 단위로 미리 의미 군집을 만들어두기 때문에, 질문이 들어왔을 때 그래프 전체를 뒤지지 않고 관련 커뮤니티만 보면 됩니다.

💰 비용 현실

문제는 이 그래프를 만드는 비용입니다. 500페이지 문서 기준 수치를 보면 격차가 큽니다.

풀 GraphRAG은 벡터 RAG 대비 최대 40배 이상 비쌉니다. Microsoft도 이 문제를 인지해서 2025년 1월 Dynamic Community Selection으로 토큰 사용량을 79% 줄였고, 아예 커뮤니티 요약을 인덱싱 시점이 아니라 쿼리 시점으로 미루는 LazyGraphRAG로 인덱싱 비용을 풀 버전의 0.1% 수준까지 낮췄습니다. 다만 인덱싱 비용만 문제가 아니라, 그래프 유지보수 비용이 초기 구축의 2~3배로 든다는 점도 감안해야 합니다 — 원본 문서가 바뀔 때마다 그래프도 다시 반영해야 하니까요.

⚖️ 언제 GraphRAG이 필요한가

결정을 내리는 실전 기준은 이렇습니다.

벡터 검색으로 충분한 경우

• 질문이 주로 시맨틱 검색("주제 X 관련 섹션 찾기")
• 단일 홉 팩트 검색 정확도가 70% 이상
• 지연 시간 요구사항이 엄격함 (100ms 미만)

GraphRAG이 필요한 경우

• 다중 엔티티 질문 ("A사의 규제 노출은 B사 인프라 투자 때문" 같은 관계 추론)
• 시간 축을 따라가는 질문 ("2024년 이후 계약 변경사항")
• 규제 → 산업 → 공급업체 → 컴플라이언스처럼 여러 단계를 거쳐야 하는 다중 홉 추론
• recall@k가 60% 미만으로 떨어지는 쿼리 슬라이스가 확인될 때

가장 흔한 실수는 이 판단을 6개월간 벡터 RAG를 운영한 뒤에야 하는 겁니다. 시스템은 멀쩡히 응답하니까 관계 오류나 엔티티 혼동 같은 근본적 실패가 표면에 잘 안 드러나서, 문제를 늦게 알아차리는 경우가 많습니다.

🪜 단계적으로 도입하기

바로 풀 GraphRAG부터 시작하지 말고, 실제 쿼리 로그로 필요성을 입증한 뒤 단계적으로 올라가는 게 권장됩니다.

1. 엔티티 1,000개 미만이면 그냥 벡터 RAG를 유지
2. 메타데이터 필터 추가만으로 실패 사례의 30~50%가 해결되는 경우가 많음 (가장 저렴한 개선)
3. 그래도 부족하면 가장 영향도 높은 쿼리 유형만 좁혀서 파일럿으로 그래프 도입
4. 90일 정도 운영하며 유지보수 비용까지 감당 가능한지 검증

진단 방법도 구체적입니다. 최근 사용자 쿼리 로그에서 100개를 뽑아 유형별로 분류하고, 쿼리 유형별 recall@k를 측정하면 GraphRAG이 실제로 필요한 쿼리 슬라이스가 어디인지 정확히 드러납니다. 결국 이건 "벡터냐 그래프냐"의 이분법이 아니라, 어떤 질문이 그래프 의미론을 필요로 하는지 측정하고 그쪽만 라우팅하는 문제에 가깝습니다.

📚 정리

• 벡터 검색은 고립된 청크 유사도만 봄 — 엔티티 간 관계는 임베딩 과정에서 사라짐
• 집계·다중 홉 질문에서 GraphRAG이 3~4배 우세, 반대로 단순 문서 검색은 벡터가 더 나음
• GraphRAG 4단계: 엔티티·관계 추출 → Leiden 알고리즘 커뮤니티 탐지 → 계층적 요약 → 커뮤니티 단위 검색
• 비용 격차가 큼 — 벡터 RAG $5 미만 vs 풀 GraphRAG$50~200(45분). LazyGraphRAG으로 인덱싱 비용을 0.1%까지 낮출 수 있지만 유지보수 비용은 여전히 큼
• 도입 기준은 recall@k 60% 미만 쿼리 슬라이스가 확인될 때 — 6개월 지나서 깨닫지 말고 쿼리 로그로 미리 진단
• 엔티티 1,000개 미만이면 벡터 유지 → 메타데이터 필터(30~50% 해결) → 좁은 파일럿 순으로 단계적 도입

다음 편은 이렇게 만든 RAG 시스템의 품질을 어떻게 자동으로 채점하는지, RAGAS와 LLM-as-a-judge를 다룰 예정입니다.

참고: TianPan.co 「GraphRAG in Production: When Vector Search Hits Its Ceiling」, TianPan.co 「GraphRAG vs. Vector RAG: The Architecture Decision Teams Make Too Late」, Mintlify/Microsoft 「Community detection - GraphRAG」, Weaviate 「Exploring RAG and GraphRAG」