LLM

[LLM] GraphRAG 최신 트렌드 — 벡터 검색이 놓치는 관계와 현실적인 타협점

rubrub 2026. 9. 4. 00:05

GRAPH RAG · HYBRID RETRIEVAL · FINANCIAL AI

GraphRAG 최신 트렌드
벡터 검색이 놓치는 ‘관계’를 잡는다

RAG를 운영하다 보면 이런 질문을 만난다. “두 문서가 서로를 참조하는데, 왜 검색 결과에서는 남처럼 나오지?” 임베딩은 문장이 얼마나 비슷한지는 잘 찾지만, 누가 누구에게 적용되고 어떤 조항을 거쳐 결론에 도달했는지는 모른다. GraphRAG는 그 틈을 메운다. 다만 모든 문서를 거대한 지식 그래프로 만드는 순간, 정확도보다 먼저 비용과 운영 난도가 우리를 찾아온다.

먼저 결론 최신 실무 방향은 Vector RAG를 GraphRAG로 교체하는 것이 아니라, Hybrid Search를 기본값으로 두고 관계 추론이 필요한 질문만 Graph 경로로 보내는 것이다. 그래프는 검색엔진의 대체재라기보다 ‘관계가 중요한 구간에 붙이는 정밀 장비’에 가깝다.

벡터 검색이 놓치는 것은 의미가 아니라 구조다

기본 RAG는 질문과 가까운 청크를 찾는다. “보험료 납입면제 조건”처럼 답이 한두 청크 안에 있으면 빠르고 강하다. 하지만 다음 질문은 다르다.

“2019년에 가입한 A상품의 암 진단 특약이 면책 조항과 상품 개정 이력을 거쳤을 때, 현재 고객에게 어떤 조건으로 적용되는가?”

여기서는 상품 → 특약 → 약관 버전 → 시행일 → 면책 조항 → 고객 계약의 연결을 보존해야 한다. 유사도 Top-k만으로는 각 청크를 찾더라도 적용 순서와 유효 시점을 잃기 쉽다. GraphRAG는 엔티티와 관계를 추출하고, 필요한 경로를 따라가며 원문 청크를 다시 회수한다.

보험 약관 GraphRAG의 최소 단위

고객 계약
가입일 · 계약상태

→ 가입

상품/특약
product_id · rider_id

→ 적용

약관 버전
effective_from/to

→ 참조

보장/면책
조항 · 예외 · 근거

핵심: 그래프에는 관계와 유효기간을, 답변 근거에는 원문 청크와 페이지를 남긴다.

2026 GraphRAG 트렌드: ‘더 큰 그래프’보다 ‘덜 낭비하는 그래프’

흐름	기술적 변화	실무적 의미
Local · Global · DRIFT	엔티티 중심, 커뮤니티 요약 중심, 두 방식을 결합한 탐색으로 쿼리 모드 세분화	모든 질문에 같은 검색기를 쓰지 않는다
Lazy / On-demand	비싼 요약·추론을 인덱싱 시점에 전부 수행하지 않고 질문 시 필요한 만큼 실행	초기 구축비와 전체 재색인 부담을 줄인다
Adaptive Routing	Factoid는 Vector, 관계·경로는 Graph, 전체 요약은 Community로 라우팅	비용·지연·정확도의 Pareto 균형을 맞춘다
Schema-constrained KG	OpenIE로 아무 관계나 뽑지 않고 도메인 온톨로지와 구조화 출력으로 타입을 제한	그래프 노이즈와 중복 엔티티를 줄인다
Graph + Text 동시 회수	트리플만 LLM에 넣지 않고 연결된 원문 청크·인용·메타데이터를 함께 반환	관계는 정확하게, 답변은 원문에 근거하게 만든다
Temporal Graph	엣지에 유효기간·버전·근거 문서를 붙이고 시점 조건으로 탐색	약관·규정의 ‘현재/가입 당시’ 혼선을 막는다

Microsoft GraphRAG의 현재 쿼리 엔진도 구체적 엔티티 질문을 위한 Local Search, 데이터셋 전체를 map-reduce 방식으로 요약하는 Global Search, 커뮤니티 정보로 출발점을 넓히고 후속 질문을 생성하는 DRIFT Search를 구분한다. 즉 GraphRAG는 단일 알고리즘이 아니라 질문 범위에 따른 검색 전략의 묶음으로 보는 편이 정확하다.

GraphRAG의 진짜 한계: 그래프는 틀리면 더 그럴듯하게 틀린다

1. Entity Resolution이 전체 품질을 지배한다

“무배당 A종신”, “A종신보험”, “A Whole Life”가 같은 상품인지 구분하지 못하면 노드가 쪼개진다. 반대로 이름이 비슷한 다른 상품을 합치면 잘못된 관계가 전파된다. 그래프 검색은 잘 연결된 세계에서는 강하지만, 틀린 엣지도 자신 있게 따라간다.

2. 구축 비용보다 변경 비용이 더 무섭다

LLM 기반 엔티티·관계 추출, 커뮤니티 탐지, 요약 생성은 인덱싱 비용이 크다. 문서 한 건이 수정됐을 때 영향받는 노드·엣지·커뮤니티 요약만 증분 갱신하지 못하면 사실상 전체 재색인이 된다. 규정과 상품이 자주 바뀌는 금융권에서는 freshness가 정확도의 일부다.

3. NL2Cypher는 편하지만 보안 경계가 아니다

자연어를 Cypher로 바꾸면 탐색이 유연해지지만, 임의 쿼리 생성은 과도한 조회·비인가 경로·고비용 traversal 위험을 만든다. 허용된 템플릿, 읽기 전용 계정, 최대 홉·결과 수·타임아웃, tenant/ACL 필터를 쿼리 생성 이후에도 강제해야 한다.

4. 벤치마크 승리가 곧 우리 데이터의 승리는 아니다

최근 체계적 비교 연구는 GraphRAG가 관계 추론·전체 요약에서 장점을 보이지만 일반 텍스트 QA에서는 vanilla RAG보다 항상 우수하지 않으며, 두 방식의 강점이 상호 보완적이라고 보고한다. 평가도 단일 ‘정답률’ 대신 Retrieval Recall, Path Validity, Citation Correctness, Latency, Token/Indexing Cost를 함께 봐야 한다.

5. 권한 전파가 생각보다 어렵다

사용자가 볼 수 없는 문서에서 추출된 엔티티가 공개 노드와 연결되면, 원문을 주지 않아도 관계 자체가 민감정보를 누설할 수 있다. 문서 ACL을 청크에만 걸어서는 부족하고, 노드·엣지·커뮤니티 요약의 provenance와 권한까지 전파해야 한다.

GraphDB가 GraphRAG의 필수조건은 아니다 Microsoft GraphRAG 기본 파이프라인은 엔티티·관계·커뮤니티 결과를 테이블 형태로 만들고 기본적으로 Parquet에 저장하며, 임베딩은 별도 벡터 저장소에 쓴다. 관계 탐색이 제한적이라면 PostgreSQL의 node/edge 테이블과 recursive CTE만으로도 검증할 수 있다. Neo4j 같은 GraphDB는 복잡한 가변 경로, 빈번한 traversal, 그래프 분석이 실제 병목으로 확인됐을 때 도입해도 늦지 않다.

현실적 타협: Full GraphRAG 대신 ‘관계 인덱스’를 붙인다

이미 Azure AI Search나 PostgreSQL 기반 Hybrid RAG가 있다면 전체를 갈아엎지 않는다. 기존 청크 인덱스를 source of truth로 유지하고, 정확도가 필요한 엔티티와 관계만 얇은 그래프 레이어로 추가하는 편이 운영 가능성이 높다.

추천 아키텍처: Vector-first, Graph-on-demand

Query Router
질문 유형 · 엔티티 · 시점

Hybrid Search
BM25 + Vector + Rerank

Graph Expansion
1~2 hop · temporal · ACL

Context Builder
원문 · 경로 · 인용 병합

단순 질문은 Hybrid Search에서 종료하고, 관계 질문만 Graph Expansion을 실행한다.

def retrieve(query, user_context):
    intent = route(query)  # FACT, RELATION, GLOBAL

    chunks = hybrid_search(
        query=query,
        filters=acl_and_effective_date(user_context),
        top_k=20,
    )
    chunks = rerank(query, chunks)[:6]

    if intent == "FACT":
        return build_context(chunks)

    seeds = resolve_entities(query, chunks)
    paths = graph_expand(
        seeds=seeds,
        max_hops=2,
        allowed_relations=domain_allowlist,
        temporal_at=user_context.contract_date,
        acl=user_context.permissions,
    )

    evidence = fetch_source_chunks(paths)
    return build_context(rerank(query, chunks + evidence), paths=paths)

중요한 점은 그래프의 트리플만 답변에 넣지 않는 것이다. (특약)-[참조]->(면책조항)은 방향을 알려주지만 법적·업무적 문맥을 충분히 담지 못한다. 최종 컨텍스트에는 경로와 함께 원문, 문서 버전, 페이지, 유효기간을 다시 붙여야 한다.

도입 단계: 그래프 DB부터 사지 않는다

단계	구현	다음 단계 조건
0. Hybrid RAG	BM25 + Vector + Metadata filter + Reranker	실패 질문의 상당수가 관계·다중 홉 문제일 때
1. Relation Index	PostgreSQL node/edge + 원문 provenance + 1~2 hop	경로 종류가 늘고 recursive query가 운영 병목일 때
2. GraphDB	Neo4j 등 + 제한형 Cypher + Vector/Full-text 병행	복잡한 traversal과 그래프 분석이 품질 개선을 입증할 때
3. Community GraphRAG	커뮤니티 탐지·계층 요약·Global/DRIFT Search	전사 문서 전체의 패턴·테마 질문이 실제로 존재할 때

금융권 POC라면 이 6가지만 측정한다

Entity Linking Accuracy: 상품명·특약명·조항명이 올바른 canonical ID에 연결되는가
Path Validity: 회수된 관계 경로가 원문 근거와 일치하는가
Temporal Accuracy: 가입일·개정일·효력일에 맞는 버전을 선택하는가
Retrieval Recall@k: 답변에 필요한 원문 청크가 최종 컨텍스트에 들어오는가
ACL Leakage Rate: 권한 밖 노드·엣지·요약이 단 한 건이라도 노출되는가
Cost & Latency: 일반 Hybrid RAG 대비 인덱싱 비용과 P95 응답시간이 얼마 늘었는가

나의 현실적인 선택: 약관 전체를 LLM으로 자유롭게 그래프화하지 않는다. 우선 상품·특약·조항·버전·시행일처럼 업무적으로 검증 가능한 스키마만 추출하고, 기존 Hybrid Search의 실패 케이스 중 관계 질문만 1~2 hop으로 확장한다. 이 정도만 해도 “GraphRAG 데모”가 아니라 운영 가능한 검색 개선이 된다.

GraphRAG의 매력은 그래프가 멋있게 보인다는 데 있지 않다. 답변이 어떤 문서와 관계를 거쳐 나왔는지 설명할 수 있다는 것, 그리고 그 경로를 테스트할 수 있다는 데 있다. 반대로 관계가 중요하지 않은 질문까지 그래프로 보내는 순간 GraphRAG는 고가의 우회로가 된다. 정답은 Full Graph가 아니라, 관계가 정확도를 바꾸는 지점까지만 그래프화하는 것이다.

참고자료

※ GraphRAG의 성능은 데이터의 관계 밀도, 그래프 품질, 질문 유형과 평가 방식에 크게 좌우된다. 특정 프레임워크의 벤치마크 수치를 그대로 운영 환경의 기대 성능으로 해석해서는 안 된다.