그래프 기반 LLM 시스템은 역할과 계산 위치로 나눠 평가해야 한다

무엇인가

이 논문은 그래프를 쓰는 LLM 시스템, 특히 에이전트 시대의 GraphRAG·KGQA·다중 에이전트 시스템을 대상으로 그래프 연산이 실제로 무엇을 하는지 분해하는 서베이다. 그래프는 구조적 추론, 지식 근거, 검색·기억, 실행 의존성, 에이전트 간 통신을 조직하는 데 쓰이지만, 기존 논의는 그래프를 썼다는 사실과 성능 향상을 혼동하기 쉽다. 저자들은 그래프 연산의 기능, 그 계산을 맡는 구성 요소, 출력이 이후 판단에 어떻게 쓰이는지를 구분해야 한다고 본다. 예를 들어 연구자 A의 출생 도시에서 시설을 운영하는 조직을 묻는 질문에서 검색된 경로가 관계 근거를 주더라도, 시설 운영자가 바뀐 뒤에는 현재·과거 운영자를 시간별로 구분해야 하고 저장된 계획이 이전 운영자를 가리켜도 알림은 현재 운영자에게 가야 한다. 즉 올바른 검색만으로 올바른 행동이 보장되지 않는다는 것이 문제 설정이다.

어떻게 동작하나

해법의 중심은 연산 수준의 역할-계산 위치 분류법이다. 역할은 그래프가 맡는 기능으로 추론 객체, 지식과 근거, 검색과 기억, 실행 프로그램, 조정과 통신의 다섯 가지다. 계산 위치는 내부 LLM 추론, 그래프 조건화 인터페이스, 외부 그래프 순회·실행, 에이전트 오케스트레이션의 네 가지다. 분류는 시스템 전체가 아니라 특정 단계의 개별 연산과 출력에 적용되므로 한 시스템이 여러 역할·위치를 가질 수 있다. 예를 들어 GCR의 경로 토큰 제약 적용은 지식·근거 역할의 그래프 조건화 인터페이스로, ChatKBQA의 그라운딩된 쿼리 실행은 같은 역할의 외부 실행으로 분류된다. MuSe의 뷰 추출과 GraphChain의 대상 계산은 둘 다 추론 객체·외부 실행이지만, 전자는 모델에게 국소 관측을 주고 후자는 계산된 결과를 준다는 점에서 남는 일이 다르다.

무엇과 다른가

이 분류 위에서 논문은 세 연구 질문을 따라 문헌을 질적 종합한다. 첫째, 그래프 관측·외부 계산 결과·실행 피드백이 이후 행동과 완료 결정을 어떻게 이끄는가. 둘째, 기억 표현·검색·갱신이 이후 답변·계획·협업에 쓸 정보를 어떻게 바꾸는가. 셋째, 올바른 다운스트림 행동을 위해 어떤 근거·실행·통신 의존성을 보존해야 하는가. 본문은 관측 선택(MuSe), 절차 학습(GraphWiz, GraphThought, G1, MAGMA), 외부 계산 위임(GraphChain, GraphArena), 근거 구성과 검색(GraphRAG, RAPTOR, HippoRAG, GNN-RAG), KGQA 상호작용(Think-on-Graph, Plan-on-Graph, ChatKBQA), 제약 생성(GCR), 기억과 조정으로 이어지는 사례를 이 질문들에 맞춰 비교한다. 특히 중간 상태 정확도, 경로 적합성, 검색 재현율, 최종 과제 성공률이 서로 다른 것을 측정한다는 점을 반복해서 강조한다.

어떻게 쓰나

평가 프레임워크는 전체 파이프라인 비교, 조건부 온라인 비교, 구성 요소 개입을 구분하고, 과제 결과·과정 증거·시스템 비용을 함께 보게 한다. 완료 규칙도 측정 대상이다. Graph Explorer의 finish-or-fail은 예산 안에 유효한 Finish와 최소 한 번의 KG 호출을 통해 정답을 내야 성공이고, 최선 노력 정확도나 사후 가시성 점검은 별개다. GCR의 경로 적합성, ChatKBQA의 쿼리 표시 의미, 인용의 완전·부분·부재 지원도 각각 다른 속성이다. 기억 평가에서는 공통 초기 이력에서 시간순으로 상호작용하고, 리셋·갱신 완료 시각을 보고하며 미래 정보를 배제해야 한다. 의존성 평가에서는 답변 단계에 어떤 관계가 제공됐는지 추적하고, 실행 비교에서는 스킬과 초기 환경을 고정하며, 라우팅 비교에서는 참여자·능력·집계 규칙을 고정해야 한다. 비용은 추출·인덱싱·요약·학습·온라인 연산·검증·재시도·실패·기억 갱신까지 포함해 계산 경계를 명시해야 한다.

전제와 한계

이 논문은 새 실험을 수행한 연구가 아니라 인용 연구들의 결과를 재해석한 서베이므로, 자체 데이터셋이나 통합 순위표는 없다. 대신 국소 지표와 다운스트림 성능이 어긋나는 사례를 수치와 함께 제시한다. GraphArena의 GPT-4o 비교에서 코드 지원은 작은 그래프에서는 정확도를 낮추고 큰 그래프에서는 높였으며, 저자들은 작은 그래프의 손실 원인으로 추출·코드 생성 오류를 지목한다. GNN-RAG에서는 후보 부분그래프를 희소화하면 CWQ의 GNN 노드 예측은 좋아지지만 다운스트림 LLM 답변 성능은 떨어진다. 저자들은 질문 엔티티와 정답 후보 사이의 경로가 끊긴 지원을 원인으로 본다. HippoRAG의 PPR은 top-5 all-support recall에서 MuSiQue와 2WikiMultiHopQA에서는 ColBERTv2를 앞섰지만 HotpotQA에서는 앞서지 못했다. Fan 등의 Qwen2.5-7B-Instruct/HotpotQA 결과도 인용되는데, Search-o1 아래에서는 dense retrieval이 Contain Exact Match 33.76, GraphRAG 백엔드가 32.73이었고, GraphSearch 아래에서는 dense가 38.22, 같은 GraphRAG 백엔드가 42.25로 역전됐다. 서베이는 이 역전이 검색 워크플로와 백엔드, 비용을 함께 보고해야 함을 보여준다고 해석한다.

개발자에게 이 논문의 실무적 의미는 GraphRAG나 KG 기반 에이전트를 만들 때 그래프 연산을 한 덩어리로 보지 말라는 것이다. 먼저 그 연산이 추론 객체인지, 지식·근거인지, 검색·기억인지, 실행 프로그램인지, 조정·통신인지 정하고, 계산이 LLM 내부·그래프 조건화 인터페이스·외부 실행·오케스트레이션 중 어디서 일어나는지 표시해야 한다. 그다음 검색된 근거가 실제 행동 단계까지 전달되는지, 기억 갱신이 이후 질문의 현재 상태와 과거 상태를 구분하는지, 실행 의존성이 재시도·타임아웃·보상에서 보존되는지 확인해야 한다. 평가는 정답률 하나로 끝내지 말고 전체 파이프라인, 조건부 온라인 비교, 구성 요소 개입, 실패·중단·미해결 검사, 지연·비용을 함께 보고해야 한다. 특히 judge 기반 평가는 루브릭, judge 모델, 응답 순서, 무효 결과 처리를 명시해야 한다.

저자가 밝힌 전제와 한계도 분명하다. 이 작업은 2026년 8월 20일까지 공개된 문헌을 대상으로 한 방향성 있는 질적 종합이며, 포괄적 목록이나 통합 성능 순위를 목표로 하지 않는다. 결과는 각 연구의 데이터셋, 모델, 접근 조건, 예산 안에서 해석하고, 역할 간 함의와 제안 진단은 인용 연구의 실험이 아니라 저자들의 종합으로 구분한다. 오프라인 최적화와 인덱스 재사용은 런타임 그래프 수정이나 유지 상태 관리를 입증하지 않으며, 그래프 기반 사전 준비와 답변 중 그래프 사용도 구분해야 한다. 향후 과제로는 관측·계산·중단을 적응적으로 결정하는 문제, 압축과 갱신 중에도 일관된 기억 유지, 불완전한 의존성 기록 아래에서의 복구와 수정 전파를 꼽는다.