[RAG] GraphRAG: 지식 그래프를 결합해 복잡한 관계형 질문 해결하기

RAG 시스템을 운영하다 보면 어느 순간 한계가 보입니다. 단순 문서 검색은 잘 되는데 관계가 있는 질문이 나오면 답변 품질이 갑자기 떨어집니다. 저희 팀도 이 문제 때문에 꽤 오래 고생했습니다. 결국 벡터 검색만으로는 해결되지 않는 질문이 있다는 것을 느끼게 되더군요.

RAG 시스템에서 관계형 질문이 깨지는 문제

RAG 시스템은 기본적으로 문서 유사도 기반 검색입니다. 질문과 가장 유사한 문서를 찾고 그 내용을 기반으로 답변을 생성합니다.

초기에는 이 구조가 꽤 잘 동작합니다. 특히 FAQ, 정책 문서, 매뉴얼 같은 콘텐츠에서는 정확도가 좋습니다.

하지만 서비스가 조금 복잡해지면 다른 유형의 질문이 등장합니다. 바로 관계형 질문입니다.

예를 들어 이런 질문입니다. 특정 상품을 만든 회사는 어디인가. 그 회사의 대표 서비스는 무엇인가. 또는 특정 기능을 만든 팀과 관련된 다른 프로젝트는 무엇인가 같은 질문입니다.

이런 질문은 하나의 문서에 답이 존재하지 않는 경우가 많습니다. 여러 문서에 흩어져 있는 정보를 연결해야 합니다. 

 

운영 로그에서 발견한 패턴

로그를 분석해보니 전체 질문 중 약 15퍼센트 정도가 관계형 질문이었습니다.

문제는 이 질문에서 답변 정확도가 크게 떨어진다는 점이었습니다. 단순 문서 검색에서는 정답률이 약 85퍼센트였는데 관계형 질문에서는 약 40퍼센트 수준이었습니다.

LLM이 틀린 답을 만드는 경우도 많았습니다. 서로 다른 문서를 섞어서 잘못된 관계를 만들어내기도 했습니다. 운영에서 한번 겪어보면 꽤 당황스럽습니다.

그래서 이 문제를 해결하기 위해 GraphRAG 구조를 검토하기 시작했습니다.

 

GraphRAG 도입을 위한 접근 방식 비교

GraphRAG을 도입하기 전에 두 가지 접근 방법을 먼저 검토했습니다. 기존 RAG 구조를 유지할지 아니면 그래프 기반 구조를 추가할지였습니다.

방법 A 벡터 검색 강화

가장 먼저 시도한 것은 벡터 검색을 강화하는 것이었습니다. top k 값을 늘리고 더 많은 문서를 LLM에 전달했습니다.

장점은 기존 구조를 크게 바꾸지 않아도 된다는 점입니다.

하지만 단점이 있었습니다. 프롬프트 토큰이 크게 증가했습니다. 그리고 문서 관계를 정확히 이해하지 못하는 문제는 여전히 남았습니다.

방법 B GraphRAG 구조 도입

두 번째 방법은 지식 그래프를 구축하는 방식이었습니다. 문서 간 관계를 그래프로 표현하고 이를 기반으로 검색하는 구조입니다.

장점은 관계형 질문 처리 능력입니다. 엔티티와 관계를 명확하게 모델링할 수 있습니다.

단점은 구축 비용입니다. 그래프 데이터를 생성하고 유지해야 합니다.

결론적으로 저희는 두 방식을 결합했습니다. 기본 검색은 벡터 기반으로 하고 관계형 질문은 그래프 검색을 사용하도록 했습니다. 운영에서는 이런 하이브리드 구조가 꽤 좋습니다.

 

GraphRAG 기반 지식 그래프 구축 방법

GraphRAG의 핵심은 엔티티와 관계입니다. 문서에서 엔티티를 추출하고 이를 그래프로 저장합니다.

저희는 문서 파이프라인에서 엔티티 추출 단계를 추가했습니다. 예를 들어 회사, 제품, 기능 같은 엔티티를 추출했습니다.

{
  "entity": "ProductA",
  "relation": "developed_by",
  "target": "CompanyX"
}

이 데이터를 그래프 데이터베이스에 저장했습니다. Neo4j를 사용했습니다.

MATCH (p:Product {name:"ProductA"})-[:DEVELOPED_BY]->(c:Company)
RETURN c

이렇게 관계를 먼저 찾고 관련 문서를 RAG에 전달하는 구조를 만들었습니다.

GraphRAG 적용 결과

GraphRAG 적용 이후 관계형 질문 정확도가 크게 개선되었습니다.

기존에는 관계형 질문 정답률이 약 40퍼센트 수준이었습니다. GraphRAG 적용 이후 약 75퍼센트 수준까지 올라갔습니다.

특히 여러 문서를 연결해야 하는 질문에서 성능 차이가 컸습니다.

LLM hallucination도 줄어들었습니다. 그래프에서 관계를 먼저 확인하기 때문입니다.

 

GraphRAG의 현실적인 운영 결론

GraphRAG은 꽤 강력한 구조입니다. 특히 관계형 질문이 많은 서비스에서는 효과가 있습니다.

하지만 모든 서비스에 필요한 것은 아닙니다. 단순 FAQ 검색이라면 기존 RAG로 충분합니다.

또 하나 중요한 점이 있습니다. 그래프 데이터 유지 비용입니다. 문서가 바뀌면 그래프도 업데이트해야 합니다.

그래서 운영 경험상 GraphRAG은 데이터 파이프라인과 같이 설계해야 합니다. 그래프 생성과 인덱싱이 자동화되어야 합니다.

결국 RAG 시스템은 점점 복잡해집니다. 단순 벡터 검색에서 시작하지만 운영을 하다 보면 그래프, 메타데이터, 데이터 파이프라인까지 확장됩니다.