4. Graph RAG (그래프 RAG
4.1 Graph RAG란 무엇인가요?
Graph RAG는 지식 그래프(Knowledge Graph)를 활용하는 RAG입니다. 핵심 아이디어는 “문서”가 아니라 “관계”를 검색한다는 것입니다.
일반적인 RAG는 문서를 독립적인 조각으로 취급합니다. 각 청크는 그 안에 있는 텍스트만 담고 있고, 다른 청크와의 관계는 고려하지 않습니다. 하지만 현실 세계의 정보는 서로 연결되어 있습니다.
지식 그래프는 정보를 엔티티(Entity, 개체), 관계(Relationship), 속성(Property)으로 표현합니다.
- 엔티티: 사람, 회사, 제품, 장소 등 실체가 있는 것. 예: “삼성전자”, “이재용”, “갤럭시 S24”
- 관계: 엔티티 간의 연결. 예: “이재용”은 “삼성전자”의 “회장이다”, “갤럭시 S24″는 “삼성전자”가 “만들었다”
- 속성: 엔티티의 특성. 예: “삼성전자”의 “설립연도”는 “1969년”, “본사”는 “수원”
이런 정보가 그래프 형태로 연결되면, 관계를 따라가며 정보를 찾을 수 있습니다.
4.2 왜 그래프가 필요한가요?
일반 RAG의 한계를 예시로 설명하겠습니다.
예시 상황: 회사 내부 문서에 다음과 같은 정보가 흩어져 있습니다.
- 문서 A: “김철수는 개발팀의 팀장이다.”
- 문서 B: “개발팀은 기술본부 소속이다.”
- 문서 C: “기술본부장은 박영희이다.”
사용자가 “김철수의 최종 상사는 누구야?”라고 질문합니다.
일반 RAG에서는 이 질문으로 검색하면, 세 문서 중 일부만 검색될 수 있습니다. 설령 세 문서가 모두 검색되더라도, LLM이 이 정보들을 연결해서 “김철수 → 개발팀장 → 기술본부 → 박영희”라는 추론을 해야 합니다. 할 수도 있지만, 정보가 더 복잡해지면 어려워집니다.
Graph RAG에서는 이런 관계가 그래프로 명시적으로 표현됩니다:
- (김철수) -[직책]→ (개발팀장)
- (개발팀) -[소속]→ (기술본부)
- (기술본부) -[본부장]→ (박영희)
- (개발팀장) -[상위]→ (기술본부장)
“김철수의 최종 상사”를 찾으려면 그래프에서 김철수 노드에서 시작해서 상위 관계를 따라가면 됩니다. 이것이 멀티홉(multi-hop) 추론입니다. 한 번의 점프로 답을 찾는 게 아니라, 여러 번 관계를 타고 넘어가서 답을 찾는 것입니다.
4.3 Graph RAG가 강한 분야
Graph RAG는 특히 다음과 같은 분야에서 강점을 발휘합니다:
정책 및 법률: 법률은 서로 참조하고 의존합니다. “이 조항은 저 조항의 예외이다”, “이 법은 저 법보다 우선한다” 같은 관계를 그래프로 표현하면 복잡한 법률 질문에 답할 수 있습니다.
기업 구조: 대기업의 조직도, 지배 구조, 자회사 관계 등. “A 회사의 자회사인 B 회사가 만든 제품 C에 적용되는 규제는?”같은 질문에는 여러 관계를 거쳐야 답할 수 있습니다.
의학/생명과학: 질병-증상-치료법-약물-부작용의 복잡한 관계. “이 약을 먹으면서 저 약을 먹어도 되나요?”같은 질문은 약물 간 상호작용 관계를 알아야 합니다.
위키형 지식: 위키피디아처럼 서로 연결된 지식 베이스. “아인슈타인의 스승의 제자들은 누가 있나요?”같은 질문.
4.4 Graph RAG의 동작 방식
Graph RAG가 동작하는 과정을 설명하겠습니다.
지식 그래프 구축 단계
먼저 문서에서 엔티티와 관계를 추출합니다. “김철수는 개발팀의 팀장으로서 신제품 프로젝트를 담당한다”라는 문장에서:
- 엔티티: “김철수”, “개발팀”, “팀장”, “신제품 프로젝트”
- 관계: (김철수)-[직책]→(팀장), (김철수)-[소속]→(개발팀), (김철수)-[담당]→(신제품 프로젝트)
이 추출 과정은 여러 방법으로 할 수 있습니다:
- 규칙 기반: 패턴 매칭으로 추출. “A는 B의 C이다” 패턴을 찾아서 관계 추출.
- NER + 관계 추출 모델: Named Entity Recognition으로 엔티티를 찾고, 관계 추출 모델로 관계를 파악.
- LLM 기반: LLM에게 “이 문장에서 엔티티와 관계를 추출해줘”라고 요청.
추출된 엔티티와 관계는 그래프 데이터베이스(예: Neo4j)에 저장합니다.
검색 단계
사용자가 “김철수가 담당하는 프로젝트는?”이라고 질문하면:
- 질문에서 핵심 엔티티(“김철수”, “프로젝트”)를 파악합니다.
- 그래프에서 “김철수” 노드를 찾습니다.
- “김철수”에서 “담당” 관계로 연결된 노드를 찾습니다.
- “신제품 프로젝트”가 검색됩니다.
더 복잡한 질문의 경우, 여러 단계의 관계를 따라갑니다. “김철수의 상사가 관리하는 다른 프로젝트는?”이라는 질문은:
- 김철수 → 상사 찾기 → (예: 이영희)
- 이영희 → 관리하는 프로젝트 찾기 → (예: 프로젝트 A, 프로젝트 B)
답변 생성 단계
그래프에서 찾은 정보를 정리해서 LLM에게 전달합니다. LLM은 이를 바탕으로 자연스러운 문장으로 답변을 생성합니다.
4.5 Graph RAG의 장점
첫째, 멀티홉 추론에 강합니다. 여러 정보를 연결해야 하는 복잡한 질문도 관계를 따라가며 답을 찾을 수 있습니다.
둘째, 관계가 명시적입니다. 일반 RAG에서는 “이 문서와 저 문서가 관련 있나?”를 LLM이 알아서 파악해야 하지만, Graph RAG에서는 관계가 그래프에 명시되어 있어서 더 정확합니다.
셋째, 정보의 구조를 파악할 수 있습니다. 그래프를 시각화하면 조직도, 관계도 등을 한눈에 볼 수 있습니다. 단순히 답변을 제공하는 것을 넘어서, 정보가 어떻게 연결되어 있는지 보여줄 수 있습니다.
넷째, 정보 업데이트가 명확합니다. “김철수가 개발팀에서 기획팀으로 옮겼다”는 정보를 반영하려면, 해당 관계만 수정하면 됩니다. 전체 문서를 다시 인덱싱할 필요가 없습니다.
4.6 Graph RAG의 단점
첫째, 지식 그래프 구축이 어렵습니다. 문서에서 엔티티와 관계를 정확하게 추출하는 것은 여전히 어려운 NLP 문제입니다. 추출 과정에서 오류가 발생하면 잘못된 관계가 그래프에 저장되고, 이는 잘못된 답변으로 이어집니다.
둘째, 유지보수 부담이 있습니다. 새로운 정보가 추가되거나 기존 정보가 바뀌면 그래프를 업데이트해야 합니다. 자동화할 수 있지만, 품질 관리가 필요합니다.
셋째, 모든 정보가 그래프에 적합한 것은 아닙니다. “이 제품의 사용 후기”같은 비정형 텍스트는 그래프로 표현하기 어렵습니다.
넷째, 인프라 복잡도가 증가합니다. 벡터 데이터베이스 외에 그래프 데이터베이스도 운영해야 합니다.
4.7 Graph RAG는 언제 사용하면 좋을까요?
Graph RAG는 정보 간의 관계가 중요하고, 멀티홉 추론이 필요한 도메인에 적합합니다. 조직 구조 질의, 법률/규정 검색, 의학 지식 베이스, 제품-부품-규제 관계 등.
반면, 단순한 정보 검색이 주 목적이거나, 정보가 독립적인 경우에는 일반 RAG로 충분하고 Graph RAG의 복잡성이 오히려 부담이 됩니다.