HyGRAG - 단순 벡터 검색이 놓치는 것

🏷️ 정보 LLM KMS

RAG를 쓰다 보면 이런 경험이 있습니다. 질문을 했는데 관련 있어 보이는 청크를 가져왔는데, 답이 틀립니다. 각각의 청크는 맞는 내용인데, 조합하면 틀린 결론이 나옵니다.

이것은 유사도 검색의 구조적 한계입니다. "이 청크가 질문과 얼마나 비슷한가"는 측정하지만, "이 청크들이 서로 어떤 관계인가"는 고려하지 않습니다.

HyGRAG는 이 문제를 청크와 엔티티를 함께 다루는 하이브리드 그래프로 풉니다. ACM Web Conference 2026(WWW '26)에 채택된 논문 기반입니다. 논문 전문 리뷰는 별도 포스트(HyGRAG - A Unified Framework for Context-Aware and Relation-Aware Graph RAG)를 참고하세요. 여기서는 핵심 아이디어를 풀어서 설명합니다.

기존 GraphRAG의 두 갈래

Graph RAG 접근은 크게 두 종류입니다.

청크 중심(Chunk-centric): 문서를 청크로 나누고, 청크 간 관계를 그래프로 연결합니다. Microsoft GraphRAG가 대표적입니다. 장점은 원문 맥락을 보존한다는 것입니다. 단점은 추상 개념 간 관계를 포착하기 어렵습니다.

엔티티 중심(Entity-centric): 텍스트에서 엔티티(사람, 장소, 개념)를 추출하고, 엔티티 간 관계를 Knowledge Graph로 구성합니다. 장점은 개념 수준의 관계를 다룰 수 있습니다. 단점은 원문의 세부 맥락이 소실됩니다.

두 방식은 독립적으로 유사도 검색을 수행합니다. 그래서 "청크 A에서 찾은 사실"과 "엔티티 B와의 관계"가 맞물리는 지점을 포착하지 못합니다.

HyGRAG의 핵심: 하이브리드 그래프

HyGRAG는 청크 노드와 엔티티 노드를 하나의 그래프에 함께 둡니다.

[청크 A] ──contains──▶ [엔티티 X]
    │                       │
    └──similar_to──▶ [청크 B] ──related_to──▶ [엔티티 Y]
                                                    │
                                              [엔티티 Z]

질문이 들어오면, 청크 수준과 엔티티 수준에서 동시에 검색합니다. 그리고 커뮤니티 멤버십(같은 그래프 클러스터에 속한 노드들)을 통해 검색 범위를 자연스럽게 확장합니다.

예를 들어 "Andrej Karpathy가 Tesla를 떠난 뒤 어떤 프로젝트에 집중했나"를 묻는다고 하면, 단순 벡터 검색은 "Karpathy + Tesla + 퇴사" 관련 청크를 가져옵니다. HyGRAG는 여기서 더 나아가, Karpathy 엔티티와 연결된 프로젝트 엔티티들, 그리고 그 프로젝트들에 대한 청크까지 함께 검색합니다.

다층 추상화 검색

HyGRAG는 세 추상화 수준에서 검색을 수행합니다.

원문 수준: 청크 간 직접 유사도 검색. 기존 RAG와 동일합니다.

엔티티 수준: 추출된 엔티티 간 관계 탐색. "이 엔티티와 직접 연결된 엔티티들은?"

커뮤니티 수준: 그래프 클러스터링으로 묶인 관련 개념 묶음 전체 검색. "이 주제와 같은 클러스터에 속한 것들은?"

질문의 성격에 따라 세 수준 중 적합한 것이 달라집니다. 단순 사실 확인은 원문 수준으로 충분합니다. "A와 B의 관계"는 엔티티 수준이 필요합니다. "이 분야 전반의 트렌드"는 커뮤니티 수준이 효과적입니다.

실험 결과

멀티홉 추론 작업, 즉 여러 단계를 거쳐야 답을 낼 수 있는 질문들에서 기준 대비 평균 9.7%의 정확도 향상을 기록했습니다.

단일 사실 검색에서는 기존 방식과 큰 차이가 없습니다. HyGRAG의 이점은 여러 정보를 연결해야 하는 질문에서 나타납니다. "A가 B에 영향을 미치고, B가 C에 영향을 미치는 경우 A가 C에 미치는 효과는?" 같은 질문입니다.

LLM Wiki와의 관계

LLM Wiki는 사람이 직접 쓴 의미형 기억입니다. 구조가 느슨하고, 관계가 암묵적입니다. "팀 코딩 컨벤션.md"에 "타입 힌트를 반드시 쓴다"고 쓰여 있고, 다른 파일에 "파이썬 프로젝트 구조.md"가 있어도, 두 파일 사이의 관계를 시스템이 명시적으로 알지 못합니다.

HyGRAG 방식을 적용하면, LLM Wiki의 각 파일을 청크로, 파일 내 개념들을 엔티티로, 파일 간 링크([위키링크](059ebd45.html))를 엣지로 표현할 수 있습니다. 그러면 "파이썬 프로젝트에서 타입 힌트 관련 규칙을 모두 찾아줘"라는 쿼리에서 여러 파일에 흩어진 관련 내용을 연결해서 가져올 수 있습니다.

개인 LLM Wiki 규모에서는 이 복잡도가 오버엔지니어링일 수 있습니다. 파일이 수백 개를 넘어가거나, 팀 단위로 위키를 공유할 때부터 그래프 구조의 이점이 나타납니다.

요약

단순 벡터 검색(RAG)이 "이 내용이 질문과 얼마나 비슷한가"를 보는 반면, HyGRAG는 "이 내용들이 서로 어떻게 연결되어 있고, 그 연결이 질문과 어떤 관련이 있는가"까지 봅니다. 멀티홉 추론이 필요한 복잡한 질문에서 차이가 납니다.

LLM Wiki에서 시작해서 지식베이스가 커지면, GraphRAG 구조로 전환을 고려할 시점이 옵니다. HyGRAG는 그 전환의 기술적 방향이 어디로 가고 있는지를 보여줍니다.

논문 전문 리뷰: HyGRAG - A Unified Framework for Context-Aware and Relation-Aware Graph RAG (grid_Papers) 참고: arXiv:2606.18075 / Awesome-GraphRAG