Ch 13. 프로덕션 — 그래프 갱신 · 비용 · 지연¶

이 챕터에서 배우는 것

전제

Ch 9의 인덱싱 비용, Ch 12의 평가.

1. 개념 — GraphRAG의 운영 부담은 인덱싱에 쏠려 있다¶

벡터 RAG의 운영은 비교적 단순하다 — 임베딩 만들고, 벡터 DB 굴리고, 검색한다. GraphRAG는 Ch 9에서 봤듯 인덱싱이 무겁다(LLM으로 추출 + 커뮤니티 요약). 그래서 프로덕션의 세 고민 — 갱신·비용·지연 — 이 대부분 인덱싱 단계에 몰린다.

가장 흔한 실수는 문서가 바뀔 때마다 전체를 재인덱싱하는 것이다. 코퍼스가 크면 이건 곧 비용 폭발이다. 증분 전략의 골격:

새/변경 문서만 추출 → 새 트리플을 기존 그래프에 MERGE로 병합(Ch 6의 멱등 적재가 여기서 값을 한다).
영향받은 커뮤니티만 재요약. 새 노드가 들어간 커뮤니티만 다시 요약하고, 안 바뀐 커뮤니티 요약은 그대로 둔다. 전체 요약을 다시 만들지 않는다.
시간 인식이 필요하면 Ch 8의 bi-temporal로 옛 사실을 닫고 새 사실을 연다(삭제 아님).

새 문서 → 추출 → MERGE(그래프 병합)
        → 변경된 커뮤니티 식별 → 그 커뮤니티만 재요약
        (나머지 그래프·요약은 건드리지 않음)

인덱싱 비용의 대부분은 LLM 호출이다. 레버 몇 가지:

추출은 작은 모델로. 엔티티·관계 추출은 강추론이 필요 없다. Ch 7에서처럼 작은/빠른 모델로 충분하고, 비용이 크게 준다.
캐싱·배치. 같은 청크를 다시 추출하지 않게 해시로 캐시하고, 추출·요약을 배치 API로 묶는다(AI Assistant Engineering Ch30의 비용 레버와 같은 정신).
선택적 그래프화. 모든 문서를 그래프로 만들지 않는다. 멀티홉·전역 질문이 닿는 코퍼스만 그래프화하고, 나머지는 벡터 RAG로 둔다.

쿼리 지연의 주범은 글로벌 검색의 map-reduce다(Ch 10). 커뮤니티가 많을수록 map 호출이 쌓인다. 대응:

요약을 미리·계층으로. 커뮤니티 요약은 인덱싱 때 만들어 두니 쿼리 시점엔 읽기만 한다. 커뮤니티를 계층(상위 커뮤니티의 요약)으로 두면 map 범위를 좁힐 수 있다.
라우팅으로 글로벌을 아낀다. Ch 11의 결론 그대로 — 단순 사실·로컬 질문에 글로벌을 쓰지 않는다. 글로벌은 정말 전역 질문에만.

운영에서 놓치기 쉬운 게 그래프 품질의 드리프트다.

엔티티 해소 드리프트. 새 문서가 들어오며 같은 개체가 다른 이름으로 쌓여 노드가 쪼개진다(Ch 7). 중복 의심 노드 수를 주기적으로 모니터링한다.
고아 노드·끊긴 그래프. 관계 없이 떠 있는 노드가 늘면 추출이 관계를 놓치고 있다는 신호다.
평가 회귀. Ch 12의 평가 셋을 정기적으로 돌려, 인덱싱·모델 변경이 검색 품질을 떨어뜨리지 않았는지 게이트로 막는다.

전체 재인덱싱 습관. 작은 변경에도 전체를 다시 돌리면 비용이 감당 안 된다. 증분이 기본이어야 한다.

큰 모델로 전부 추출. 추출에 프런티어 모델을 쓰면 인덱싱 비용이 몇 배가 된다. 작은 모델 + 검수가 균형이다.

그래프를 만들고 방치. 그래프는 살아 있는 자산이라 갱신·모니터링이 없으면 조용히 낡는다. AI Eval 가이드의 "eval은 살아 있는 자산"과 같다.

마지막. 지금까지의 모든 조각을 하나의 파이프라인으로 묶는 캡스톤으로 간다 → Ch 14.