How Graph Serialization Format Affects GraphRAG Cost and Accuracy — Agent Lab Journal

  Agent Lab Journal

    Guides
...

고급 가이드

그래프 직렬화 형식이 GraphRAG의 비용과 정확도에 미치는 영향

      Updated July 31, 2026
       · 
      45-minute read
...

그래프가 정확한 증거를 포함하고 있더라도, 텍스트 표현 방식이 컨텍스트 창 (context window)을 과도하게 소비하거나, 관련 사실들을 분리하거나, 엣지 (edge) 방향을 모호하게 만들면 잘못된 답변을 생성할 수 있습니다. 이 가이드는 이러한 실패 모드를 반복 가능한 실험으로 전환합니다. 즉, 하나의 그래프를 여러 방식으로 직렬화 (serialize)하고, 모델로 전송되는 실제 토큰 (token) 수를 측정하며, 모델을 개입시키기 전에 결정론적 탐색 (deterministic traversal)을 테스트한 다음, 고정된 컨텍스트 예산 (context budget) 하에서 멀티 홉 (multi-hop) 답변의 점수를 매깁니다.

목차

• 형식은 검색 시스템의 일부입니다

• 구체적인 사례: 의존성 영향 분석

• 테스트 대상 형식들

• 실험 설계

• 참조 구현 (Reference implementation)

• 벤치마크 실행

• 멀티 홉 모델 평가

• 검증 및 해석

• 실패 사례

• 운영 환경에서의 결정

• 한계점

형식은 검색 시스템의 일부입니다

GraphRAG는 검색 (retrieval)과 그래프 구조를 결합하여, 답변이 텍스트 유사성 (text similarity)에만 의존하는 대신 관계를 따라갈 수 있도록 합니다. 전형적인 요청은 서브그래프 (subgraph)를 검색하고, 이를 직렬화한 다음, 해당 텍스트를 모델 프롬프트 (prompt)에 배치합니다. 따라서 직렬화 도구 (serializer)는 검색과 추론 (reasoning) 사이의 핵심 경로 (critical path)에 위치합니다.

그래프 데이터베이스 (graph database)는 압축된 식별자 (identifiers)와 타입이 지정된 관계 (typed relationships)를 저장할 수 있지만, 프롬프트에서는 종종 이를 반복되는 필드 이름으로 확장합니다:

{
  "source": {"id": "svc-api", "type": "service"},
  "relationship": {"type": "depends_on"},
...

중복된 키(keys), 중괄호(braces), 따옴표(quotes), 쉼표(commas), 타입 레이블(type labels), 그리고 중복된 노드 속성(node properties)은 모두 토큰을 소비합니다. 이러한 구문이 자동으로 낭비인 것은 아닙니다. 명시적인 구조는 모호함(ambiguity)을 방지할 수 있기 때문입니다. 엔지니어링 측면에서의 질문은 각 토큰이 그 비용을 정당화할 만큼 올바른 순회(traversal) 확률을 충분히 높여주는가 하는 점입니다.

더 작은 표현 방식 또한 실패할 수 있습니다. A B C라는 라인은 비용이 저렴하지만, A가 B에 의존하는지(depends on), B를 소유하는지(owns), 혹은 B를 대체했는지(replaced)를 말해주지 않습니다. 따라서 유용한 목표는 최소한의 토큰이 아닙니다. 고정된 컨텍스트 윈도우(context window), 지연 시간(latency) 목표, 그리고 예산 하에서 측정된 최선의 답변 품질입니다.

세 가지 별개의 정확도 계층

모든 오류를 단순히 "모델이 틀렸다"로 뭉뚱그리지 마십시오. 다음 계층들을 독립적으로 측정해야 합니다:

• 직렬화 충실도 (Serialization fidelity): 파서(parser)가 원래의 노드(nodes), 엣지(edges), 방향(directions), 레이블(labels), 그리고 필수 속성(properties)을 재구성할 수 있는가?

• 순회 충실도 (Traversal fidelity): 재구성된 그래프가 결정론적 경로 쿼리(deterministic path queries)에 올바르게 답할 수 있는가?

• 답변 품질 (Answer quality): 언어 모델(language model)이 직렬화된 증거를 사용하여 기대되는 멀티 홉(multi-hop) 답변을 생성할 수 있는가?

만약 첫 번째 계층이 실패한다면, 프롬프트(prompt)를 변경하는 것으로는 누락된 정보를 복구할 수 없습니다. 만약 첫 번째와 두 번째 계층은 통과했지만 세 번째 계층이 실패한다면, 순서(ordering), 장황함(verbosity), 모델의 동작(model behavior), 또는 지시 사항(instructions)이 더 그럴듯한 원인입니다.

구체적인 사례: 의존성 영향 분석

내부 서비스 그래프를 가정해 봅시다. 노드는 서비스와 데이터베이스를 나타냅니다. 방향성이 있는 depends_on 엣지는 소비자(consumer)에서 그 의존 대상(dependency)으로 향합니다. 두 번째 관계인 owned_by는 서비스를 해당 팀과 연결합니다.

운영 측면에서의 질문은 다음과 같습니다:

db-identity가 실패할 경우, 전이적으로(transitively) 영향을 받는 고객 대면 서비스는 무엇이며, 해당 서비스들을 소유한 팀은 어디인가?

이를 해결하기 위해서는 최소 두 가지 작업이 필요합니다: 실패한 데이터베이스로부터 역방향으로 의존성 에지(dependency edges)를 탐색한 다음, 영향을 받는 서비스로부터 소유권 에지(ownership edges)를 따라가는 것입니다. 방향성을 제거하거나, 관계 유형(relationship types)을 생략하거나, 소유권 기록을 유실하는 표현 방식은 남아 있는 모든 라인이 구문론적으로 유효하더라도 정답을 지원할 수 없습니다.

이 지점이 바로 절단(truncation)이 위험해지는 구간입니다. 거대한 JSON 문서는 닫는 에지나 소유권 섹션을 가용 예산(budget) 너머로 밀어낼 수 있습니다. 프롬프트는 읽기 가능한 상태로 유지되지만, 마지막 홉(hop)에 필요한 증거가 부재하게 됩니다.

테스트 대상 형식 (Formats under test)

아래의 벤치마크는 동일한 유향 타입 그래프(directed, typed graph)에 대한 다섯 가지 무손실 표현(lossless representations)을 비교합니다. 모든 형식은 노드 식별자(node identifiers), 노드 유형(node types), 에지 유형(edge types) 및 방향성을 유지합니다.

            형식 (Format)
            예시 에지 (Example edge)
            예상 트레이드오프 (Expected trade-off)
...

의도적으로 정보 손실이 발생하는 형식(lossy format)을 별도의 라벨링 없이 주요 순위(ranking)에 포함하지 마십시오. 예를 들어, 타입이 지정되지 않은 쌍 목록(untyped pair list)은 질문에 필요한 정보를 제거했기 때문에 토큰(tokens) 측면에서만 승리할 수 있습니다.

실험 설계 (Experimental design)

통제 변수 (Control variables)

모든 형식에 대해 다음 사항을 고정합니다:

• 그래프 및 레코드가 제공되는 순서;

• 쿼리 세트 및 예상 정답;

• 토크나이저(tokenizer) 및 모델 버전;

• 프롬프트 지침 및 출력 스키마(output schema);

• 최대 입력 예산(maximum input budget) 및 절단 정책(truncation policy);

• 온도(temperature) 및 최대 출력 토큰을 포함한 생성 설정(generation settings);

• 반복 실행 횟수 및 채점 코드.

주요 측정 항목 (Primary measurements)

      직렬화된 바이트 (Serialized bytes)
      UTF-8 바이트 길이. 저장 및 전송에는 유용하지만, 모델별 토큰 측정치를 대체할 수는 없습니다.

...

권장 가설 (Recommended hypotheses)

테스트를 실행하기 전에 가설을 작성하십시오. 예를 들어:

• Compact JSON은 동일한 결정론적 (deterministic) 결과를 유지하면서 Pretty JSON보다 더 적은 토큰을 사용할 것입니다.

• 타입이 지정된 에지 리스트 (typed edge list)는 구문 오버헤드 (syntax overhead)를 줄이겠지만, 더 강력한 형식 지침 (format instructions)이 필요할 수 있습니다.

• 예산이 제한적인 상황에서는 레코드 인식 절단 (record-aware truncation)이 원시 문자 또는 토큰 슬라이싱 (raw character or token slicing)보다 더 나은 성능을 보일 것입니다.

• 예산이 작아질수록 쿼리 관련성에 따라 에지를 정렬하는 것이 더 중요해질 것입니다.

이것들은 가설일 뿐 결과가 아닙니다. 벤치마크는 사용자의 그래프, 토크나이저 (tokenizer), 모델, 그리고 쿼리 분포에 따라 이 가설들을 확인하거나 기각하도록 설계되었습니다.

레퍼런스 구현 (Reference implementation)

다음의 단일 파일 프로그램은 결정론적인 합성 그래프를 생성하고, 이를 다섯 가지 형식으로 직렬화(serialize)하며, 모든 형식을 디코딩(decode)하고, 라운드 트립 (round trips)을 검증하며, 도달 가능성 쿼리 (reachability queries)를 실행하고, 토큰을 측정합니다. 기본 그래프는 검토하기에 충분할 만큼 의도적으로 작게 설정되었습니다. 컨텍스트 압박 (context-pressure) 테스트를 위해 --services 및 --noise-edges 값을 늘리십시오.

환경 (Environment)

python -m venv .venv
. .venv/bin/activate
python -m pip install tiktoken

실험에 사용된 버전을 선택한 후 설치된 종속성을 고정하십시오:

python -m pip freeze > requirements-lock.txt
python --version
python -m pip show tiktoken

benchmark_graph_formats.py로 저장

#!/usr/bin/env python3
import argparse
import csv
...

벤치마크가 결정론적 파싱 (deterministic parsing)으로 시작하는 이유

모델은 파서 준수 테스트 (parser conformance test) 도구가 아닙니다. 추론 예산을 소비하기 전에, 손실이 없다고 가정된 모든 형식이 동일한 그래프를 재구성할 수 있는지 증명하십시오. 이 프로그램은 직렬화된 문자열 대신 정준 튜플 (canonical tuples)을 비교하므로, 무해한 순서나 공백 차이는 실패로 간주되지 않습니다.

그 후 쿼리 세트는 디코딩된 그래프를 대상으로 작동합니다. 탐색 점수 (traversal score)가 1.0 미만이라는 것은 직렬화 또는 디코더가 사용 가능한 그래프 의미론 (semantics)을 변경했음을 의미합니다. 언어 모델을 평가하기 전에 거기서 멈추고 표현 방식 (representation)을 수정하십시오.

벤치마크 실행하기

베이스라인 (Baseline)

python benchmark_graph_formats.py \
  --services 40 \
  --noise-edges 80 \
...

Scale sweep (규모 스윕)

for size in 40 100 250 500
do
  python benchmark_graph_formats.py \
...

선택한 모델에 필요한 인코딩 (encoding)을 사용하십시오. 단순히 이 예시에 등장한다고 해서 인코딩 이름을 그대로 복사하지 마십시오. 이를 함께 기록하십시오.