모두연 Lab에 떨어진 뒤: 혼자 시작할 Graph RAG 비교 실험

금요일에 모두연 Lab 지원을 위한 커피챗이 있었다. GraphDB와 관련된 Lab이었고 경력이 있으니 내가 해온 일을 설명할 수 있다고 생각했다. 토요일에 받은 결과는 탈락이었다. 좋은 경험으로 받아들이자고 생각했지만 그날은 허무했다.

처음에는 내가 자신 있게 말한 태도가 문제였을까 돌아봤다. 다만 내가 받은 결과만으로 선발 이유를 알 수는 없다. 자신감과 겸손을 같은 문제로 묶어 자책할 필요도 없고, 탈락이 내 실력과 무관하다고 단정할 근거도 없다. 당시 감정과 확인한 사실을 구분해서 남겨두려고 한다.

소속을 기다리는 동안 작게 시작할 수 있는 일

이틀째에는 혼자 시작할 수 있는 범위를 생각했다. 내가 궁금했던 것은 GraphDB라는 도구 이름보다 회사 문서 검색에서 관계 정보를 이용하면 어떤 질문이 나아지는가였다. Lab 참여 여부와 별개로 작은 공개 자료에서는 시험을 설계할 수 있다.

원래 글에는 Neo4j나 Memgraph로 그래프를 만들고 Vector RAG와 같은 질문으로 비교하겠다고 적었다. 그때의 계획을 아래에서 구체화했다. 아직 실행하지 않았으며 측정 수치도 없다. 실제 결과와 비용은 실험을 마친 뒤 실행 환경과 함께 별도로 기록해야 한다.

이번 계획의 범위는 검색 방식 비교다. 대규모 사내 시스템 구축, 최신 제품 간 순위 매기기, 그래프가 환각을 없앤다는 증명까지 한 번에 하려 하지 않는다. 처음부터 범위를 넓히면 실패 원인을 구분하기 어렵다. 공개 문서에서 동일한 질문을 반복해 검토할 수 있는 수준으로 시작한다.

같은 이름의 Graph RAG도 구성이 다르다

벡터 검색은 질문과 문서 조각을 임베딩 공간에서 비교해 관련 자료를 찾는 데 사용할 수 있다. 그래프를 활용하는 검색은 추출한 개체와 관계를 탐색하거나 관계 주변의 문서를 모으는 방식을 포함한다. 하나의 정해진 Graph RAG 구현만 존재하는 것은 아니다.

Microsoft의 GraphRAG는 문서에서 그래프와 커뮤니티 요약을 구성하고 자료 전체를 묻는 질문 등을 다루는 접근이다. 관련 논문의 결과를 곧바로 내 회사 리포트나 Neo4j 설정의 결과로 옮길 수는 없다. 평가 질문과 데이터가 다르면 장단점도 달라질 수 있다. GraphRAG 연구 논문

따라서 첫 실험에서는 구현 이름과 설정을 고정한다. 그래프 DB를 쓴다는 사실만 적지 않고 엔티티를 어떤 모델로 추출했는지, 관계를 몇 단계까지 따라가는지, 최종 답변에 어떤 근거를 전달하는지 기록한다. 비교 대상에는 단순한 키워드 검색도 둔다. 모델을 사용하는 두 방법 모두 제목 검색보다 비싸고 느리면서 틀린다면 그 사실도 결과다.

문서와 질문을 먼저 만들고 정답 근거를 고정한다

시작 데이터는 공개적으로 이용 가능한 문서 10~20개로 제한할 계획이다. 같은 분야의 보고서 중 발행 기관, 날짜, 원자료 링크를 확인할 수 있는 문서를 고른다. 공개 열람과 재배포 권리는 다르므로 원문 파일을 다른 저장소에 올릴 수 있는지도 확인한다. 사내·고객사 자료는 첫 실험에서 제외한다.

각 문서에는 식별자, 제목, 발행일, 파일 해시, 페이지 수를 기록한다. 표가 포함된 PDF에서 행과 열이 잘 추출됐는지 먼저 본다. 추출 텍스트에 숫자와 단위가 빠졌는데 검색 방식만 비교하면 전처리 오류를 검색 성능 차이로 오해할 수 있다. 그림 안의 글자나 각주도 질문의 근거라면 텍스트에 남아야 한다.

질문은 모델의 답을 보기 전에 작성한다. 아래 24개 구성은 이 소규모 시험을 위한 제안이며 통계적 충분성을 보장하는 표본 수가 아니다. 질문별로 예상 답의 범위와 근거 문단을 사람이 지정한다.

질문의 절반은 개발용, 나머지는 최종 확인용으로 나눌 생각이다. 개발용에서 검색 조건을 바꾸고 최종 질문은 마지막에 확인한다. 최종 결과를 보고 조건을 다시 바꿨다면 그 질문을 더 이상 독립적인 검증용으로 부르지 않는다. 바꾼 이유와 새 확인 방법을 기록한다.

검색 차이와 답변 생성 차이를 따로 측정한다

같은 문서를 처리하더라도 그래프 추출과 벡터 청킹에 드는 비용은 다르다. 비교할 때 원문 버전과 답변 생성 모델, 답변 형식, 근거에 사용할 최대 분량을 가능한 범위에서 맞춘다. 그래프 쪽에 더 많은 문서를 전달했다면 그 차이를 결과에 표시한다.

첫 판정은 검색 근거다. 정답이 있는 문단을 가져왔는지, 필요한 두 문서 중 하나만 찾았는지, 관련 없어 보이는 문단이 상위에 섞였는지 본다. 두 번째 판정은 생성한 답이다. 맞는 근거를 줬는데도 수치를 바꿨는지, 근거에 없는 관계를 만들어냈는지, 자료가 없을 때 추정을 사실처럼 썼는지 구분한다.

같은 질문을 여러 번 실행하면 출력이 달라질 수 있으므로 실행 횟수와 순서를 남긴다. 재실행에서 가장 좋은 답만 고르지 않는다. 실패한 실행도 같은 파일에 저장하고 오류의 원인을 분류한다. 모델 이름뿐 아니라 제공자가 허용하는 범위에서 버전, 설정, 호출 시각도 기록해야 이후 결과를 해석하기 쉽다.

아래 표의 판정 방식은 사람이 소규모 실험을 읽기 위한 기준이다. 서로 다른 오류를 총점 하나로 숨기지 않으려고 분리했다.

비용은 구축과 갱신, 질문 처리로 나눠 기록한다

그래프를 한 번 만드는 비용만 확인하면 운영 판단에 필요한 항목이 빠진다. 최초 텍스트 추출과 임베딩, 엔티티·관계 추출, 그래프 저장에 든 시간과 API 사용량을 나눈다. 질문마다 걸린 시간과 답변 생성 비용은 별도로 기록한다. DB 실행 비용과 사람의 검수 시간도 제외하지 않는다.

갱신 실험에는 문서 하나의 수치를 수정한 버전과 같은 문서의 중복 파일을 넣는다. 수정 전 사실을 최신 답에 섞는지, 중복 자료를 독립적인 근거처럼 세는지 확인한다. 원문을 제거해야 하는 경우에는 그 문서에서 만든 청크·관계·요약을 어떻게 처리할지도 검토한다. 삭제와 재구축을 포함한 유지 비용을 알아야 새 보고서가 매월 들어오는 상황을 판단할 수 있다.

사람이 그래프 오류를 수정한 시간이 길다면 자동 구축 시간과 함께 보고한다. 엔티티 이름을 합치고 잘못된 관계를 지운 시간을 빼면 도구가 편한 것처럼 보일 수 있다. 업무 도입을 생각하는 독자는 모델 호출 비용보다 사람이 맡을 운영 부담을 더 중요하게 볼 수도 있다.

중단할 조건을 정하고 실행 기록을 남긴다

첫 목표는 그래프 검색이 반드시 이기는 결과를 만드는 일이 아니다. 관계형 질문에서 어떤 차이를 얻고 그 차이에 얼마를 써야 하는지 확인하는 것이다. 원문 추출 품질이 나쁘거나 정답 근거를 사람이 합의할 수 없으면 검색 비교를 멈추고 데이터부터 정비한다. 기본 키워드 검색만으로 필요한 근거를 찾는다면 그 방법을 기준으로 남긴다.

지출 상한은 실제 사용 계정의 허용 예산을 확인한 뒤 정한다. 이 글에는 승인받지 않은 금액이나 실행 일정을 적지 않는다. 예산이나 처리 시간이 정한 범위를 넘으면 실행을 멈추고 남은 질문을 보고하는 절차가 필요하다. API를 반복 호출하면서 끝날 때까지 기다리는 방식은 실험 계획으로 충분하지 않다.

실험 폴더에는 문서 목록, 질문과 근거, 설정, 검색 결과, 생성 답변, 판정, 비용 기록을 분리할 생각이다. 공개 결과에는 사용 가능한 자료만 포함하고 민감한 키나 접근 토큰은 넣지 않는다. Microsoft GraphRAG 공식 문서도 살펴 구현과 평가의 범위를 맞출 예정이다.

탈락한 날의 감정을 성공담으로 덮을 필요는 없다. 혼자 시작하겠다고 쓴 계획이 아직 계획이라는 사실도 남겨둔다. 다음 기록에는 실제로 실행한 명령과 실패한 질문을 가져와야 한다. 그래야 이 회고 다음에 무엇을 했는지 설명할 수 있다.

참고자료

• Microsoft Research, From Local to Global: A Graph RAG Approach to Query-Focused Summarization: 특정 GraphRAG 구성과 평가 범위.
• Microsoft GraphRAG 공식 문서: 구현과 사용상의 안내. 본문의 실험 설계는 필자의 제안이며 실행 결과가 아니다.