GraphRAG 에 대한 생각

2000년 초반부터 온톨로지 연구를 해왔고, 관심을 갖고 있는 사람으로서 GraphRAG 에 대해 갖고 있는 생각을 적어봤습니다.

1.

GraphRAG는 전통적인 RAG 기법 대비 좋은 성능을 보인다는 연구들이 보고되고 있기는 합니다만, 일단 KG(knowledge graph) 자체가 잘 구축되어 있을 것을 1차적인 전제로 한다는 면에서 허들이 있습니다. 그럼에도 최근 이 기술이 각광을 받는 것은 일반적인 자연어에 비해 정보를 구조화해서 LLM에 전달할 때의 장점이 있기 때문이라 생각합니다.

2.

그러나, knowledge graph의 구축비용이 만만치 않습니다. 도메인 전문가가 직접 구축하는 것이 기본적인 접근인데 이 비용은 두말할 것 없을 겁니다. LLM을 활용해서 구축하는 방법도 있겠지만, 어차피 다시 LLM에 입력해서 활용할 정보인데 굳이 그래프 형태로 경유해야만 하는가에 대한 의문이 생길 수 있습니다.

제 생각엔(증명해보진 못했습니다만), 정보를 자연어 문장 형태로 나열하는 방식 대비, 동일한 용어나 정보를 사용하더라도 그래프 형태로 구성되었을 때 그 구조 자체가 주는 의미적인 정보가 더 명시적으로 표현될 수 있기에 (node 간 거리 등으로), LLM의 output을 graph로 구성만 해주더라도 답변에 더 도움이 될만한 여지가 있지 않을까 싶긴 합니다.

3.

하지만 GraphRAG에서의 허들은 KG 구축비용만이 아닙니다. KG로부터 sub graph를 추출할 때 사용자 질의에 필요한 지식의 편향이 오히려 오답을 유도할 수 있기에, KG 자체를 node를 균형있게 설계하고 실제 instance 레벨에서 일정한 수준의 밀도를 유지해야 하지만 query 할 때도 이를 고려한 튜닝을 해줘야 합니다.

예컨대 한 node는 edge가 많이 연결되고 다른 node는 적거나 없을 가능성이 다분하기에, 어떤 연구에서는 node 와 edge 의 비율이 1:2.5~3.5 수준으로 유지하는 것이 좋고, graph traversal도 5~7 수준으로 유지하는 것이 좋다라고 보고하기도 했습니다. 이 정도라도 할 수 있는 수준의 KG를 갖추기도 비용이 만만치 않다는 점도 현실이지만, 만일 있다고 하더라도 저 숫자가 정답은 아닐겁니다. 말그대로 케바케죠. query 를 케바케로 튜닝해야 한다는 건 결국 비용입니다.

4.

또한 sub graph 추출은 단순히 키워드 매칭을 하는 문제가 아니라, 그래프 탐색 전략, 랭킹 알고리즘 등을 조합해서 튜닝해야 하고, 불필요한 node는 필터링해야 할 수도 있습니다. 또 그렇게 추출한 결과에서 질문에 필요한 정보가 아닌 meta 성 property들은 제거해줘야 할 수도 있고, query 결과의 문법적 요소들을 정제해줘야 할 수도 있습니다 (LLM 입장에서 noise가 될 가능성도 있고, 불필요한 token을 소모하게 된다는 점 등을 고려하면).

5.

이런 복잡성과 튜닝비용을 감수하고서라도 GraphRAG의 성능이 전통적인 RAG나 이를 개선한 여러 방법론들 대비 장점이 있는지에 대한 것은, 프로젝트 성격에 따라 신중하게 검토해야 할 문제입니다. GraphRAG가 좋다고 하니 무작정 덤빌 문제가 아니라는 뜻이죠.