Vector Graph RAG: 그래프 데이터베이스 없이 멀티 홉 RAG
Source: Dev.to
Standard RAG vs. Multi‑Hop Reasoning
Standard RAG는 답변이 단일 청크에 없을 때 무너집니다.
“1차 치료 당뇨병 약물의 부작용은 무엇을 주의해야 하나요?” 라고 물으면 시스템은 먼저 메트포르민이 1차 치료 약물이라는 것을 인식하고, 그 다음 메트포르민의 부작용을 찾아야 합니다. 질의에는 메트포르민이 언급되지 않으며, 이는 시스템이 스스로 발견해야 하는 연결 엔터티입니다. 순수 벡터 검색만으로는 이를 할 수 없습니다.
업계에서는 지식 그래프 + 그래프 데이터베이스를 답으로 제시했습니다. 이것은 작동하지만 Neo4j(또는 유사 제품)를 배포하고, 그래프 쿼리 언어를 배우며, 두 개의 별도 저장 시스템을 운영해야 함을 의미합니다. 본질적으로 하나의 기능—패시지 간 엔터티 체인을 따라가는 것—에 대한 복잡성이 두 배가 되는 것입니다.
Vector Graph RAG
나는 Vector Graph RAG를 구축하여 이러한 오버헤드 없이 멀티‑홉 추론을 가능하게 했습니다. 전체 그래프는 Milvus 안에 존재합니다—엔터티, 관계, 그리고 패시지는 ID 교차 참조가 포함된 세 개의 컬렉션으로 저장됩니다. 그래프 데이터베이스도 없고, Cypher 쿼리도 없으며, 벡터 검색과 메타데이터 조회만 사용합니다.
Core Insight
다음과 같은 지식‑그래프 트리플
(metformin, is_first_line_drug_for, type_2_diabetes)은 단순히 텍스트일 뿐입니다. 텍스트는 벡터로 임베딩될 수 있습니다. 그렇다면 전체 그래프 구조를 벡터 데이터베이스에 저장하지 않을 이유가 무엇일까요?
Data Model (Three Milvus Collections)
| Collection | What it stores | Key fields |
|---|---|---|
| Entities | 중복 제거된 엔터티 이름, 의미 검색을 위한 임베딩 | entity_id, embedding, relation_ids |
| Relations | 트리플 기반 관계 (subject, predicate, object) | relation_id, subject_id, object_id, passage_ids, embedding |
| Passages | 원본 문서 청크 | passage_id, text, entity_ids, relation_ids |
이 컬렉션들은 ID 참조를 통해 논리적인 그래프를 형성합니다. “그래프 탐색”은 Milvus에서 ID 기반 메타데이터 쿼리의 연속이 되며, 별도의 그래프 쿼리 언어가 필요하지 않습니다. 추가 조회는 홉당 2‑3개의 기본키 쿼리만 추가합니다 (≈).