GraphRAG, 확장보다 압축이 먼저다

많이 찾는다고 답이 좋아지지는 않는다

AWS와 Cisco 연구진은 같은 지식베이스에서 아홉 가지 RAG 방식을 비교했다. 검색 단계에서는 정답 엔티티의 83.5%를 찾았지만 최종 답변에 반영된 비율은 47.9%에 그쳤다. 프롬프트에 들어간 정답 237개 중 실제로 쓰인 것은 136개, 즉 57.4%뿐이었다.

검색된 정보 중 실제로 답변에 반영되는 비율은 그보다 훨씬 낮다. 아무리 많이 찾아도 모델이 활용하지 못하면 소용없다. 연구진은 이를 ‘검색-생성 격차’라고 불렀다. Recall@20처럼 검색 성능만 보는 지표로는 이 손실을 알기 어렵다.

실험 환경은 그래프 검색에 유리했다. 질병, 약물, 유전자, 단백질 약 12만9천 개와 관계 810만 개가 담긴 정밀의료 벤치마크를 사용했고 관계 탐색이 필요한 질문도 포함했다. 그런데도 고급 검색 기법의 이점은 검색 지표에서 실제보다 크게 나타났다.

긴 컨텍스트도 앞부분만 잘 읽힌다

모델이 답변에 사용한 엔티티(정보 단위)는 컨텍스트의 평균 10.5% 지점에 있었다. 반면 누락된 엔티티는 평균 36.8% 지점에 놓였다. 상위 10% 구간의 정보는 85.5%가 쓰였지만 50위 밖의 엔티티는 단 하나도 사용되지 않았다.

컨텍스트 창이 길다는 것은 많이 넣을 수 있다는 뜻이지, 끝까지 고르게 읽는다는 뜻은 아니다. 여러 최신 모델을 비교한 AI 검색 인프라 기업 Chroma의 실험에서도 입력이 길어질수록 성능이 떨어졌다. 200K 컨텍스트를 지원하는 것과 200K를 안정적으로 이해하는 것은 다른 문제다.

정보의 위치만이 원인은 아니다. 모델은 낯선 하위 질환보다 익숙한 질환명을 고르고 가능한 답을 모두 나열하기보다 몇 개의 유력한 후보만 제시하는 경향이 있었다. 특히 질문이 단수형이면 답도 하나로 좁혔다. 따라서 검색기를 개선하더라도 정보 배치와 질문 방식이 그대로라면 누락은 계속된다.

성능은 가장 좁은 병목이 결정한다

복잡한 검색 방식이 항상 더 좋은 결과를 내지는 않았다.

오히려 문서 검색 도구 하나만 쓴 에이전트가 MRR 0.7549로 가장 높았다. 도구와 관계가 늘어날수록 모델이 검토해야 할 후보와 중간 결과도 많아진다. 이 실험의 병목은 검색 범위가 아니라 검색된 정보를 모델이 실제로 처리하는 능력이었다.

GraphRAG의 구축비가 낮아져도 이 문제는 사라지지 않는다. 활용하지 못할 정보를 더 많이 가져오는 설계는 비용만 늘리고 중요한 정보가 뒤로 밀릴 가능성도 키운다.

그래프는 더 모으기보다 잘 덜어내야 한다

연구진은 같은 엔티티 사이의 관계를 한 줄로 묶고 중복 관계와 문서를 제거했다. 여러 하위 질의도 한 번에 처리했다. 그 결과 LLM 호출은 평균 4.2회에서 2.8회로 줄었고 검색 범위는 84%에서 88%로 높아졌다. 관계 그룹핑은 반복 관계의 토큰 복잡도를 O(n)에서 O(1)로 낮췄다.

기본 GraphRAG가 쓰던 평균 4만9천100토큰은 최적화 후 2만3천토큰으로 53% 줄었지만 성능은 거의 유지됐다. 일부 조건에서는 토큰을 41% 줄이면서 Hit@5가 오르기도 했다. 다만 지나친 압축은 생성 점수를 떨어뜨렸다. 중간 추론 없이 많은 결과를 한꺼번에 넣으면 무엇이 중요한지 구분하기 어려워지기 때문이다.

GraphRAG의 강점은 후보를 무작정 늘리는 데 있지 않다. 관계가 약한 후보를 걷어내고 남은 정보를 짧고 명확하게 제시하는 데 있다. 이를 위해서는 세 가지를 함께 봐야 한다.

• 검색된 정답 중 실제 답변에 쓰인 비율을 측정하고
• 중요한 정보는 컨텍스트 앞부분에 배치하며
• 질문의 단복수를 기대하는 답의 개수와 맞추고 필요하면 “모두 나열하라”고 명시해야 한다.

이 연구는 정밀의료 분야와 Claude 3.7 Sonnet 한 모델만 다뤘다는 한계가 있다. GraphRAG 자체는 여전히 쓸모가 있다. 다만 RAG를 평가할 때 검색 성공률만 봐서는 안 된다. 얼마나 많이 찾았느냐가 아니라 찾은 정보가 최종 답변에 얼마나 살아남았느냐가 성능을 결정한다.

#지식 인프라#언어모델