#43에서 graph engineering의 두 갈래를 정리하면서 지식 그래프 쪽에 판별 질문 하나를 남겨뒀다. “벡터로 안 되는 질문이 내 워크로드에 진짜 있는가.” 그 질문에 데이터를 들이대는 논문이 6월 말에 나왔다. AWS와 Cisco 소속 엔지니어들이 쓴 Is GraphRAG Needed? From Basic RAG to Graph-/Agentic Solutions with Context Optimization — 제목부터 정면 승부다.
이 실험이 귀한 이유는 판의 짜임에 있다. 그동안 GraphRAG 논쟁의 수치는 대부분 서로 다른 데이터, 서로 다른 베이스라인 위에서 나왔다. 각자 자기 쪽 구현만 잘 튜닝한 비교는 비교가 아니다. 이 논문은 같은 지식베이스, 같은 생성 모델 위에 regular RAG부터 GraphRAG, Modular RAG, Agentic RAG까지 9개 시나리오를 전부 직접 구현해서 같은 조건으로 겨루게 했다. 그리고 이번 글의 테제는 성적표보다 그 뒤에 있다. 실험이 실제로 가리킨 병목은 검색이 아니라 검색 이후, 가져온 근거를 다루는 쪽이었다.
판의 짜임 — 9개 시나리오, 하나의 지식베이스
실험대는 STaRK-Prime이다. 정밀의료 도메인의 semi-structured 지식베이스로, 질병·약물·단백질·유전자 엔티티 12.9만 개에 지식 그래프 관계가 810만 개 걸려 있다. 짚어둘 점이 하나 있다. 관계 밀도가 이 정도면 그래프의 홈그라운드다. 여기서 나온 결과라는 게 뒤의 반전을 더 아프게 만든다.
그 위에 9개 시나리오를 올렸다. 엔티티 설명 문서만 검색하는 기본 RAG(1), 관계 정보를 문서에 합쳐 넣은 RAG(2), 사전 정의된 지식 그래프만 쓰는 GraphRAG(3), 문서에서 그래프를 계산해 만드는 GraphRAG(4), 텍스트·그래프 하이브리드(5), 워크플로가 고정된 Modular RAG(6), 모듈을 도구로 쥔 에이전트(7), 문서 검색 도구 하나만 쥔 자율 에이전트(8), 거기에 그래프 검색 도구를 더한 자율 에이전트(9). 생성 모델은 전부 Claude 3.7 Sonnet 하나로 고정했다. 평가는 검색 순위가 아니라 모델이 답을 쓰면서 최종 선택한 엔티티를 정답과 대조하는 end-to-end 방식이다.
성적표의 세 가지 반전
첫째, 그래프만으로는 검색이 붕괴한다. 사전 정의된 지식 그래프만 쓴 시나리오 3의 Hit@1은 0.14. 기본 RAG(0.61)의 4분의 1도 안 된다. 그래프 순회는 시작점을 잘 잡았을 때 얘기고 자연어 질문에서 시작점을 잡는 일은 결국 텍스트 검색이 한다.
반전은 여기서 커진다. 그래프를 세우지 않은 쪽이 그래프를 이겼다. 시나리오 2는 인덱싱 전에 각 엔티티 문서에 1-hop 이웃을 관계 타입별로 묶어 붙여 넣었을 뿐인 평범한 벡터 검색 RAG다. 이게 Hit@1 0.70으로, 텍스트와 그래프를 다 동원한 하이브리드 GraphRAG(시나리오 5, 0.64)를 앞섰다. 기본 RAG 대비로도 0.61에서 0.70으로 올랐으니, 이 판에서 그래프가 주는 효용의 대부분은 관계 정보 자체였지 그래프라는 자료구조가 아니었다는 뜻이다. 관계는 문장으로 펴서 문서에 넣어도 임베딩이 받아먹는다.
가장 아픈 건 세 번째다. 도구를 더한 에이전트가 뺀 에이전트에게 졌다. 종합 1위는 문서 검색 도구 하나만 쥔 자율 에이전트(시나리오 8)다 — 논문 표현으로 “미니멀한 도구의 자율 Agentic RAG가 전반에 걸쳐 최상의 결과”. 그런데 여기에 그래프 검색 도구를 하나 더 쥐여준 시나리오 9는 Hit@1이 0.69에서 0.61로 떨어지고 지연은 27초에서 72초로 2.6배가 됐다. 선택지를 늘렸더니 모델이 그 선택지에 시간을 쓰고 결과가 나빠졌다. #40에서 본 “마이그레이션은 삭제부터”와 같은 방향의 교훈이 검색 도구에서도 반복된다.
정직하게 하나 더 적어두면, Hit@1만 보면 시나리오 2(0.70)가 1위 시나리오 8(0.69)보다도 근소하게 높다. 에이전트 루프 없이 한 번 검색하는 RAG가, 쿼리마다 수십만 토큰을 태우는 자율 에이전트와 최상위를 다툰 셈이다. 성능의 왕좌는 에이전트가 가져갔지만 가성비의 왕좌는 명백히 관계 평탄화 RAG다.
가져온 근거의 절반을 버린다
순위표보다 값진 건 그 뒤의 해부다. 하이브리드 시나리오에서 검색 경로를 500개까지 넓혔을 때, 정답 엔티티가 컨텍스트 안에 들어온 비율은 83.5%였다. 그런데 모델이 답을 쓰면서 실제로 집어낸 비율은 47.9%. 검색은 근거를 가져다 놨는데 생성이 그 절반을 버린다. 저자들의 결론은 이렇다. “retrieval 중심 지표(Hit@k, MRR)는 확장된 검색의 이점을 과대평가할 수 있으며, RAG 시스템 평가는 검색 커버리지와 생성 활용도를 분리해서 재야 한다.”
어디서 버려지는지도 재봤다. 모델이 집어낸 엔티티는 평균적으로 컨텍스트 앞쪽 10.5% 지점에 있었다. 놓친 엔티티는 36.8% 지점이었다. 컨텍스트의 첫 10%에 놓인 근거는 85.5% 확률로 살아남지만 70~80% 지점에 놓인 근거의 생존율은 0%다. “lost in the middle”이라고 불러온 현상의 실측판인데, 실제로 죽는 건 중간을 지나 뒤쪽 전체다. #30에서 컨텍스트의 문제는 양보다 배치라고 했던 것이 숫자로 확인됐다.
#34에서 본 현상과도 뿌리가 같다. 거기서는 충분한 컨텍스트를 쥐여줘도 모델이 모른다고 말하지 못하고 과신하는 문제를 다뤘다. 이번엔 쥐여준 근거를 아예 소비하지 못하는 쪽이 계측됐다. 두 결과를 합치면 그림이 완성된다 — recall을 올리는 것과 답이 좋아지는 것 사이에는 모델의 소화력이라는 별도의 단계가 있고, 그 단계는 검색을 고쳐서는 좋아지지 않는다.
처방은 검색이 아니라 표기법이었다
그럼 뭘 고치나. 논문 후반부의 처방이 흥미로운 건, 검색 알고리즘도 모델도 건드리지 않았기 때문이다. 바꾼 건 검색 결과를 컨텍스트에 적는 방식이다.
그래프 검색 결과는 원래 트리플 목록으로 들어간다. (아스피린, 치료한다, 두통), (아스피린, 부작용이다, 위출혈)… 같은 엔티티 쌍에 관계가 n개면 줄도 n개다. 논문은 이걸 엔티티1 - (관계1||관계2||관계3) - 엔티티2 꼴로 묶어 엔티티 쌍당 한 줄로 만들었다. 여기에 에이전트 루프가 돌 때마다 서브그래프를 새로 쌓지 않고 세션 전체에서 하나로 합쳐 유지하고 문서 검색 결과는 내용 해시로 중복을 걸렀다. 이 세 가지로 토큰 사용량이 시나리오별로 19~53% 줄었다. 하이브리드 GraphRAG는 쿼리당 4.9만 토큰이 2.3만으로 반토막 났다.
뒤집어 읽으면, 기존 구현들은 컨텍스트의 절반 가까이를 같은 정보의 다른 표기에 쓰고 있었다는 얘기다. 그리고 위 해부 결과와 겹쳐 읽으면 이 절감은 비용 절감 이상이다. 뒤쪽 70%에 놓인 근거가 죽는 세계에서, 중복을 걷어내 근거를 앞으로 당기는 일은 곧 정확도 개입이다.
이 실험 하나가 아니다
한 논문의 결과였다면 도메인 특이성으로 치웠을 텐데, 방향이 겹치는 비교가 앞뒤로 더 있다. 4월에 나온 Do We Still Need GraphRAG?는 에이전트 검색 루프를 붙이는 것만으로 dense RAG가 GraphRAG와의 격차를 대부분 좁힌다고 보고했다. 다만 이 논문은 그래프의 남은 자리도 명시한다 — 복잡한 멀티홉 추론에서는 여전히 그래프가 유리하고, 인덱싱의 오프라인 비용이 상각될 만큼 쿼리가 쌓이는 워크로드라면 계산이 선다. 더 앞서 GraphRAG-Bench를 만든 연구진은 “GraphRAG가 실제 태스크 다수에서 vanilla RAG에 밀린다는 보고가 잇따른다”는 문제의식 자체를 벤치마크 제작 동기로 적었다.
세 실험이 가리키는 방향은 같다. 그래프는 기본값이 아니라 조건부 옵션이고, 기본값의 자리는 에이전트 검색 루프가 가져갔다. 이건 #43에서 정리한 두 갈래 중 “찾기 위한 그래프” 갈래의 중간 성적표이기도 하다. 참고로 그래프 진영도 손을 놓고 있던 건 아니어서, 인덱싱 비용을 0.1% 수준으로 떨어뜨린 계보는 #43에서 다뤘다.
실전: 그래프 없이 그래프 효과부터
이 실험에서 실무로 가져올 순서는 이렇다.
1. 관계 평탄화부터 한다. 시나리오 2는 그래프 DB도, 순회 엔진도, 온톨로지도 없이 인덱싱 파이프라인 수정만으로 Hit@1을 8%p 올렸다. 엔티티 중심 문서가 있는 코퍼스라면, 각 문서에 1-hop 이웃 관계를 타입별로 묶어 붙여 넣는 것이 이 판 전체에서 가성비가 가장 좋은 한 수였다. 그래프 도입 검토는 이걸 해보고 나서다.
2. 커버리지와 활용도를 따로 잰다. 정답 근거가 컨텍스트에 들어왔는지(retrieval)와 답이 그걸 썼는지(generation)를 분리해서 계측한다. #32에서 정리한 평가 축에 이 분리가 들어가야, 검색 지표만 좋아지는 개선에 예산을 계속 태우는 일을 멈출 수 있다.
3. 컨텍스트 표기를 다이어트한다. 중복 제거, 관계 묶음 표기, 루프 간 누적 정리. 검색도 모델도 안 바꾸고 토큰 19~53%를 회수한 개입이고 근거가 앞으로 당겨지는 만큼 정확도에도 개입한다.
4. 도구는 증명 후에 더한다. 에이전트에 검색 도구를 하나 더 쥐여주는 것도 공짜가 아니다. 시나리오 9는 도구를 더해서 더 느려지고 더 부정확해졌다. 새 도구는 eval 위에서 이긴 다음에 넣는다.
5. 그 다음이 그래프다. 위를 다 하고도 멀티홉 관계 추론이 워크로드에 실재하고 쿼리량이 인덱싱 비용을 상각한다면, 그때가 #43의 판별 질문과 #45의 사다리로 넘어갈 시점이다.
한계와 관전 포인트
실험의 한계도 그대로 적어둔다. 단일 도메인(정밀의료), 단일 모델(Claude 3.7 Sonnet)이다. 저자들 스스로 “평가가 retrieval 지향 지표에 한정되며 사실 충실성이나 환각률은 재지 않았다”고 명시했다. temperature 0에서도 에이전트 시나리오는 실행마다 결과가 흔들렸다는 비결정성 언급도 있다. 그러니 이 숫자들은 “GraphRAG는 죽었다”가 아니라 “그래프의 입증 책임이 그래프 쪽에 있다”로 읽어야 한다. 관계 밀도 810만의 홈그라운드에서도 자동으로 이기지 못했다는 것, 거기까지가 이 논문이 증명한 범위다.
관전 포인트는 두 개다. 하나는 이런 통제 비교가 다른 도메인과 다른 모델 체급에서 재현되는가다. 특히 소화력이 모델 체급의 함수라면, 체급이 오를수록 gap이 줄어드는지 커지는지가 그래프 투자의 손익을 다시 쓴다. 다른 하나는 승자의 가격표다. 시나리오 8은 최적화 후에도 쿼리당 19만 토큰을 쓴다. 이 판의 결론이 “에이전트 루프가 기본값”이라면, 다음 병목은 그 루프의 경제성이 된다.
#45에서 온톨로지의 판별 질문은 “스키마만으로 안 통하는 질문이 실제로 들어오는가”였다. 이 논문은 그 앞에 세울 질문을 하나 준다. 가져온 근거나 제대로 쓰고 있는가. 이 질문에 숫자로 답하기 전까지, 더 정교한 검색은 해답 후보에 올리지 않는 게 맞다.