Graph RAG
텍스트 조각 검색에 지식 그래프의 관계 추론을 결합한 검색 증강 생성 패턴.
— RAG 고도화 아키텍처 문서와 엔터프라이즈 AI 검색 백서
벡터 DB가 못 찾는 맥락을 그래프로 찾겠다며 시작했지만, 결국 사내 문서에서 사람 이름, 제품명, 팀명, 약어를 추출하다가 하루가 끝난다. 관계를 넣으면 똑똑해진다더니 관계를 정의하는 사람이 먼저 무너진다
1. 개요
Graph RAG는 기존 RAG의 검색 단계를 지식 그래프로 확장한 아키텍처다. 일반 RAG는 보통 질문과 문서 조각을 임베딩한 뒤 벡터 데이터베이스에서 의미적으로 가까운 텍스트를 가져온다. 이 방식은 “비슷한 문장”을 찾는 데 강하지만, 사람과 조직, 제품, 사건, 코드 모듈처럼 서로 얽힌 관계를 따라가야 하는 질문에는 쉽게 허둥댄다. Graph RAG는 문서에서 엔티티와 관계를 뽑아 그래프를 만들고, 질문이 들어오면 관련 노드와 주변 관계망을 탐색한 뒤 그 결과를 LLM의 컨텍스트로 넣는다. 쉽게 말해 LLM에게 단순 참고 문서 더미가 아니라 “누가 누구와 어떤 관계인지”가 정리된 인맥도를 같이 쥐여주는 방식이다.(...)
2. 왜 그냥 RAG로는 부족한가
일반 RAG는 검색어와 문서 조각의 의미적 유사도를 기준으로 상위 몇 개를 가져오는 방식이 많다. “환불 정책 알려줘”처럼 답이 한 문단 안에 들어 있는 질문에는 충분히 강력하다. 하지만 “A 서비스 장애가 B 팀의 배포와 어떤 관련이 있나?”처럼 여러 문서와 사람, 시스템, 시간 순서가 엮인 질문은 이야기가 달라진다. 관련 문서 조각들이 각각 따로 흩어져 있고, 그 사이의 관계는 본문 어딘가에 암시적으로 박혀 있기 때문이다. Graph RAG는 이때 문서에서 “A 서비스”, “B 팀”, “배포”, “장애” 같은 엔티티를 뽑고, 이들 사이의 관계를 그래프로 저장해 탐색한다. 벡터 검색이 비슷한 문장을 찾는 도구라면, 그래프 검색은 연결된 사실의 경로를 찾는 도구에 가깝다.
3. 구축 파이프라인
대표적인 흐름은 1단계 문서 수집, 2단계 엔티티 추출, 3단계 관계 추출, 4단계 그래프 저장, 5단계 질의 시 그래프 탐색, 6단계 LLM 답변 생성이다. 문제는 이 중 어느 하나도 “그냥 버튼 누르면 끝”이 아니라는 점이다. 엔티티 추출이 조금만 흔들려도 “OpenAI”, “Open AI”, “오픈AI”가 서로 다른 노드가 되고, 관계 추출이 과하면 온 세상 모든 단어가 선으로 이어진 미술 작품이 된다. 그래서 실무에서는 임베딩 검색과 그래프 검색을 같이 쓰는 하이브리드 구성이 흔하다. 벡터 검색으로 후보 문서를 좁히고, 지식 그래프로 관계를 보강한 뒤, 마지막에 리랭킹이나 요약 단계를 덧붙이는 식이다.
4. 관련 밈 및 드립
4.1. 그래프 만들면 다 해결된다며?
Graph RAG 도입 회의에서 자주 등장하는 마법 주문. 하지만 막상 시작하면 “그래프를 어떻게 만들지”, “관계 타입은 누가 정하지”, “동명이인은 어떻게 처리하지” 같은 현실적인 질문이 쏟아진다. 결국 문제는 검색 알고리즘보다 데이터 모델링과 정제라는 오래된 숙제로 돌아온다.
4.2. 엔티티 지옥
문서 안의 용어를 노드로 뽑는 순간 시작되는 고통. 같은 대상을 가리키는 표현이 문서마다 다르고, 줄임말과 별칭이 난무하며, 사람이 보면 당연한 관계를 기계는 끝까지 모른다. 이 지옥을 정리하려고 만든 별칭 사전이 또 하나의 사내 위키가 되는 장면이 자주 펼쳐진다.
5. 여담
- Graph RAG와 GraphRAG: 띄어 쓴 Graph RAG는 일반적인 아키텍처 명칭으로 쓰이고, 붙여 쓴 GraphRAG는 특정 구현체나 프로젝트 이름으로 쓰이는 경우가 많다. 검색할 때는 둘 다 찾아봐야 자료가 덜 빠진다.
- 벡터 검색의 대체재가 아니다: Graph RAG는 벡터 데이터베이스를 버리는 개념이 아니라, 벡터 검색이 약한 관계형 질문을 보완하는 레이어에 가깝다. 실무에서는 둘을 섞는 쪽이 훨씬 현실적이다.
- 비용의 방향이 바뀐다: 일반 RAG는 청킹과 임베딩 비용이 크고, Graph RAG는 여기에 엔티티/관계 추출과 그래프 유지보수 비용이 얹힌다. 정확도를 얻는 대신 운영 난이도 청구서를 받는 셈이다.