GraphRAG가 필요한 질문은 무엇인가: 벡터 RAG와 비용, 평가 비교

GraphRAG는 문서에서 엔티티와 관계를 추출하고 커뮤니티를 요약해 여러 문서에 걸친 관계, 경향 질문을 다루려는 접근입니다. 단일 사실 검색까지 모두 그래프로 바꾸면 인덱싱 비용과 운영 복잡도만 커질 수 있습니다. 벡터 RAG가 실제로 실패하는 질문을 먼저 모은 뒤 같은 평가 세트에서 관계 검색의 추가 가치와 비용을 비교해야 합니다.

어떤 질문이 GraphRAG 후보인가

“휴가 신청 절차는 무엇인가”처럼 한 문서에 답이 있는 질문은 관련 청크를 찾는 벡터 검색으로 충분할 가능성이 큽니다. “여러 분기의 장애에서 반복된 서비스와 담당 팀은 무엇인가”처럼 문서 여러 개의 개체, 관계와 전체 패턴을 묻는 질문은 개별 청크 Top-K만으로 필요한 연결이 함께 나오지 않을 수 있습니다. GraphRAG는 이 두 번째 유형을 겨냥합니다.

후보 질문을 세 범주로 나누면 선택이 쉬워집니다. 단일 엔티티의 국소 사실, 두세 엔티티의 다중 홉 관계, 전체 데이터의 주제, 경향입니다. 첫 범주에는 벡터나 키워드 검색이 강한 기준선이고, 두 번째에는 그래프 경로, 세 번째에는 커뮤니티 요약을 비교할 수 있습니다. 질문을 구분하지 않고 전체 평균만 보면 쉬운 FAQ가 관계 검색의 이득을 가립니다.

그래프를 쓴다는 사실이 추론을 보장하지는 않습니다. 필요한 관계가 추출되지 않았거나 동일 인물이 여러 노드로 갈라지면 경로가 끊깁니다. 반대로 우연한 동시 등장만 관계로 만들면 잘못된 멀티홉 답이 더 그럴듯해집니다. 실제 업무 질문에서 어떤 연결이 필요한지를 데이터 모델과 평가 기준으로 먼저 정의해야 합니다.

인덱싱 파이프라인은 무엇을 추가하는가

일반적인 벡터 RAG는 문서를 청크로 나눠 임베딩하고 검색 인덱스에 저장합니다. GraphRAG는 이 위에 엔티티, 관계 추출, 중복 개체 정리, 그래프 구축, 커뮤니티 군집과 요약 같은 단계를 추가합니다. 논문과 microsoft/graphrag 저장소는 로컬, 글로벌 질문을 위한 이 구조를 확인할 출발점입니다.

다음 원문 코드는 LLM에 엔티티와 관계의 JSON을 요청하는 단순화된 예입니다. 특정 LangGraph나 모델 사용이 공식 GraphRAG의 필수 구현이라는 뜻은 아니며, 스키마 검증, 재시도, 근거 연결이 생략돼 있습니다.

# GraphRAG 엔티티 추출기 핵심 로직 (LangGraph 기반 단순화)
def extract_graph_entities(chunk_text: str) -> dict:
    system_prompt = """
    당신은 사내 인프라 데이터 분석 전문가입니다. 주어진 텍스트에서 주요 개체(Person, System, Incident, Team)를 추출하고,
    이들 간의 관계를 JSON 배열 형태로 반환하세요.
    반드시 다음 스키마를 따르세요:
    [{"source": "A", "target": "B", "relation": "CAUSED_BY", "weight": 8.5}]
    """
    
    response = llm.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": chunk_text}
        ],
        temperature=0.0 # 환각 방지를 위해 극도로 보수적인 세팅
    )
    return json.loads(response.choices[0].message.content)

temperature를 낮추어도 추출 사실이 자동으로 정확해지지는 않습니다. JSON 스키마를 지켰는지, source와 target이 원문에 있는지, 관계 문장이 실제 근거를 갖는지 각각 확인해야 합니다. “결제 장애가 고객 불만을 야기했다”와 “결제 장애 문서 옆에 고객 불만이 언급됐다”를 같은 엣지로 저장하면 이후 경로 질의가 잘못됩니다.

엔티티와 관계의 근거는 어떻게 보존할까

각 노드에는 정규화된 이름만 두지 말고 원문 표기, 문서 ID와 시간 범위를 연결합니다. “Payments”, “결제 서비스”와 내부 코드명이 같은 시스템인지 정리하는 entity resolution이 필요합니다. 자동 병합이 잘못되면 서로 다른 서비스를 하나로 묶고, 병합하지 못하면 관계가 여러 노드로 분산됩니다.

엣지에도 근거 문장, 출처 문서, 추출 시각과 확신 또는 검수 상태를 둡니다. 관계를 만든 모델의 요약만 저장하면 답변이 틀렸을 때 원문으로 돌아갈 수 없습니다. 같은 두 엔티티 사이에 상반된 관계가 들어오면 최신 문서를 무조건 덮어쓰기보다 시점과 적용 범위를 보존해야 합니다.

커뮤니티 요약은 여러 노드와 관계를 압축하므로 또 다른 정보 손실 단계입니다. 요약이 포함한 주장마다 어떤 하위 근거를 사용했는지 연결하고, 그래프가 갱신되면 영향을 받은 요약을 다시 계산합니다. 오래된 요약이 새 그래프 위에 남으면 검색은 최신 노드를 찾고 최종 답은 과거 결론을 말하는 불일치가 생깁니다.

검색 설정은 어떤 역할을 하나

원문의 설정 예시는 그래프 스냅샷과 엔티티 추출 프롬프트, 엔티티 유형과 반복 추출 횟수를 보여 줍니다. 반복 횟수를 늘리면 놓친 항목을 찾을 가능성과 모델 호출 비용이 함께 늘 수 있습니다. 값 하나를 모든 문서에 고정하기보다 추출 누락률과 비용 곡선을 봐야 합니다.

# settings.yaml 예시 (GraphRAG 파라미터 튜닝)
snapshots:
  graphml: true
entity_extraction:
  prompt: "prompts/entity_extraction.txt"
  entity_types: ["organization", "person", "incident", "microservice", "database"]
  max_gleanings: 2 # 추출 정확도를 높이기 위한 멀티 패스 재귀 호출 횟수 (비용 폭발의 주범!)

엔티티 유형이 너무 넓으면 노드가 많아지고 모호한 관계가 늘 수 있습니다. 너무 좁으면 업무 질문에 필요한 사건이나 팀이 빠집니다. 소수 문서를 사람이 주석한 골드 세트로 만들어 유형별 precision, recall과 중복 병합 오류를 확인한 뒤 전체 인덱싱으로 확대합니다.

커뮤니티 군집의 해상도도 답변 범위를 바꿉니다. 큰 군집은 전체 경향을 요약하지만 세부 주제를 섞을 수 있고 작은 군집은 국소 맥락은 살리지만 글로벌 질문에 많은 요약을 합쳐야 합니다. 점수 하나보다 대표 글로벌 질문의 근거 누락, 중복과 첫 응답 시간을 함께 비교합니다.

그래프 질의가 관계 정확성을 보장하는가

다음 Cypher는 특정 장애가 영향을 준 시스템과 담당 팀을 잇는 예입니다. 데이터에 AFFECTS와 MANAGED_BY가 정확히 존재할 때는 명시적인 경로를 찾을 수 있습니다.

// 특정 장애(Incident)와 연관된 시스템, 그리고 그 시스템을 관리하는 팀을 최대 3-depth까지 탐색
MATCH (i:Incident {id: 'INC-2025-104'})-[r1:AFFECTS]->(s:System)-[r2:MANAGED_BY]->(t:Team)
RETURN i.description, s.name, t.contact
ORDER BY r1.weight DESC LIMIT 5;

하지만 쿼리가 결정적이라는 사실과 저장된 관계가 사실이라는 결론은 다릅니다. 잘못 추출한 AFFECTS 엣지는 Cypher가 정확히 따라가며 틀린 팀을 반환합니다. 결과에 각 엣지의 원문 근거를 붙이고, 답변 모델이 경로에 없는 인과를 추가하지 않는지 확인해야 합니다.

경로 길이를 무작정 늘리면 가능한 조합과 오탐이 빠르게 늘어납니다. 업무상 의미 있는 관계 유형과 최대 깊이를 정하고, 관계 방향과 시간 순서를 검사합니다. 담당 팀이 장애 당시와 현재 다르다면 단일 MANAGED_BY 관계로는 정확한 답을 만들 수 없습니다.

인덱싱과 갱신 비용은 어떻게 계산할까

초기 인덱싱 비용은 문서 수만이 아니라 청크 수, 추출 반복, 요약 계층과 사용 모델에 좌우됩니다. 모델 API, 로컬 GPU, 그래프 저장소, 임베딩과 실패 재처리를 항목별로 기록합니다. 원문의 가상 비용이나 특정 모델 가격을 현재 예산으로 복사하지 않고 실제 토큰과 실행 시간을 작은 샘플에서 측정합니다.

문서가 바뀔 때 전체 그래프를 다시 만들지 증분 갱신할지 정해야 합니다. 변경된 청크의 노드, 엣지를 갱신하면 비용은 줄지만 삭제된 관계, 병합된 엔티티와 영향을 받은 커뮤니티 요약을 함께 처리해야 합니다. 단순 MERGE만 반복하면 오래된 엣지가 남고 가중치가 의미 없이 누적될 수 있습니다.

업데이트 테스트에는 문서 수정, 삭제, 엔티티 이름 변경과 소유 팀 교체를 넣습니다. 검색에서 새 사실이 나타나는 시간, 과거 사실의 비활성화와 요약 재생성 범위를 기록합니다. 재색인 비용뿐 아니라 그래프가 서로 모순된 상태로 머무는 시간도 운영 지표입니다.

답변 품질은 어떤 평가표로 판단할까

질문 세트를 단일 사실, 멀티홉 관계와 글로벌 요약으로 나누고 벡터 RAG, GraphRAG와 검색 없는 답변을 같은 생성 모델로 비교합니다. 정답뿐 아니라 인용한 원문이 주장을 실제로 지지하는지, 필요한 관계를 모두 거쳤는지, 존재하지 않는 연결을 추가했는지 채점합니다.

그래프 절제 실험도 필요합니다. 커뮤니티 요약 없이 경로만 쓴 조건, 벡터 청크와 그래프를 함께 쓴 조건, 관계 하나를 제거한 대조 질의를 비교합니다. GraphRAG가 좋아 보여도 더 많은 컨텍스트와 모델 호출 때문인지 구조화된 관계 때문인지 분리해야 합니다.

운영 지표에는 인덱싱, 갱신 비용, 검색 지연, 첫 응답 시간, 그래프 저장량, 추출 실패와 사람 검수 시간을 둡니다. 글로벌 질문 몇 개의 이득이 대부분의 단일 FAQ 요청에 추가 지연을 부과한다면 질문 분류 후 필요한 요청만 GraphRAG로 라우팅하는 방식이 낫습니다.

언제 벡터 RAG를 유지하는 편이 나은가

문서가 작고 질문이 특정 정책, 매뉴얼의 사실 조회에 집중되며 관계가 자주 바뀐다면 벡터 RAG가 단순합니다. 엔티티 스키마를 소유할 팀과 그래프 오류를 검수할 사람이 없다면 자동 추출 그래프는 새로운 부채가 됩니다. 최신성이 매우 중요한 데이터에서는 복잡한 요약 갱신보다 원문 검색이 안전할 수도 있습니다.

여러 문서의 사건, 조직, 시스템 관계가 반복 질문되고, 벡터 기준선이 필요한 청크를 함께 가져오지 못하며, 원문 근거를 연결할 수 있다면 제한된 도메인에서 GraphRAG 파일럿을 할 이유가 있습니다. Neo4j의 Graph RAG 자료는 구현 선택의 참고가 될 수 있지만 특정 그래프 데이터베이스가 GraphRAG의 유일한 전제는 아닙니다.

도입 결론은 그래프가 더 정교해 보이는지가 아니라 고유한 질문 유형에서 검증 가능한 품질 이득이 총비용을 넘는가입니다. 질문 분류와 하이브리드 라우팅을 포함해 가장 단순한 구조부터 비교해야 합니다.

원문과 버전 확인

• 공식 GitHub 저장소

함께 읽으면 이해가 이어지는 글

• Crawl4AI로 RAG용 Markdown을 만들 때 먼저 확인할 것 — AsyncWebCrawler로 동적 페이지를 Markdown, JSON으로 바꾸는 최소 흐름과 버전, 브라우저 의존성, 추출 정확도, 자원 비용 검증법을 정리합니다.
• Langfuse로 LLM 환각 원인을 찾을 수 있을까: Trace, Span, Generation, PII — Langfuse의 계층형 Trace와 비동기 전송이 RAG 실패를 어떻게 재구성하는지 살펴보고, 프롬프트 저장에 따른 PII, 스토리지, 샘플링 문제를 점검합니다.
• re4/LibreCode: 일렉트론을 걷어내고 로컬 AI와 리버싱을 통합한 네이티브 에디터 — re4/LibreCode는 .NET 10과 Avalonia UI를 기반으로 설계되어 일렉트론의 무거움을 극복하고, Ollama 기반의 완전 오프라인 로컬 AI(RAG)와 강력한 역공학(리버싱) 도구들을 단일 환경에 통합한 차세대 코드…

자주 묻는 질문

문서 검색에는 항상 GraphRAG가 벡터 RAG보다 좋은가요?

아닙니다. 단일 문서의 정확한 사실이나 키워드 질의는 벡터 검색이 더 단순하고 빠를 수 있으며, 여러 문서의 관계와 전체 경향을 묻는 질문에서 GraphRAG 후보가 됩니다.

지식 그래프를 만들면 환각이 사라지나요?

아닙니다. 엔티티, 관계를 추출하는 모델이 틀리거나 근거 문서가 오래되면 그래프가 잘못된 연결을 명시적으로 저장할 수 있어 원문 근거와 충돌 검사가 필요합니다.

GraphRAG 파일럿에서 무엇을 비교해야 하나요?

같은 질문, 문서, 답변 모델에서 벡터 RAG와 GraphRAG의 근거 정확도, 관계, 글로벌 질문 성능, 인덱싱, 갱신 비용, 첫 응답 시간과 운영 오류를 함께 비교해야 합니다.

References

• 논문 원문 (arXiv)
• GitHub 저장소
• neo4j.com 원문