7만 건의 인도 대법원 판결문을 통한 GraphRAG와 Basic RAG 성능 비교 분석

저는 70,000건의 인도 대법원 판결문을 대상으로 GraphRAG와 Basic RAG를 벤치마킹했습니다 — 실제 수치가 보여주는 결과는 다음과 같습니다. 프로덕션 RAG (Retrieval-Augmented Generation) 시스템의 토큰 비용이 폭증하고 있습니다. 매 분기 엔지니어링 팀은 더 많은 비용을 지불하고, 더 오래 기다리며, 컨텍스트 제한 (Context limits)에 더 빨리 도달하고 있습니다. 표준적인 해답인 벡터 임베딩 (Vector embeddings) 기반의 Basic RAG는 도움이 되지만, 근본적인 문제가 있습니다. 즉, 구조적으로 연결된 사실이 아니라 유사한 텍스트를 검색한다는 점입니다. 저는 GraphRAG가 실제의 복잡하고 도메인 특화된 데이터셋에서 이 문제를 실제로 해결하는지 테스트하고 싶었습니다. 그래서 지난 몇 주 동안 TigerGraph의 GraphRAG 추론 해커톤 (GraphRAG Inference Hackathon)을 위해 인도 대법원 판결문을 활용한 3단계 파이프라인 벤치마크인 LexGraph를 구축하는 데 시간을 보냈습니다. 결과는 명확했습니다. 제가 정확히 무엇을 구축했는지, 그리고 데이터가 무엇을 보여주는지 설명해 드리겠습니다.

왜 인도 대법원 판결문인가요?
저는 의도적으로 이 데이터셋을 선택했습니다. 대법원 판결문은 공개 영역에 존재하는 데이터 중 가장 그래프 형태에 가까운 텍스트 데이터 중 하나입니다. 모든 판결문은 이전 사례들을 인용합니다. 그 사례들은 헌법 조항을 해석합니다. 판결문을 작성한 판사들은 경력을 통해 진화하는 수십 년간의 법학 철학을 가지고 있습니다. 예를 들어, "어떤 판사들이 일관되게 제21조의 권리를 확장했으며, 어떤 사례들이 그러한 선례를 확립했는가?"와 같은 질문은 판사(Judge) → 사례(Case) → 조항(Article) → 선례(Precedent) 체인을 탐색해야 합니다. 이는 서로 다른 엔티티 유형(Entity types)에 걸쳐 4번의 홉 (Hops)이 필요한 과정입니다. 벡터 RAG는 제21조를 언급하는 청크 (Chunks)를 검색합니다. 반면 GraphRAG는 누가 무엇을 결정했는지, 누구를 인용했는지, 어떤 조항을 해석했는지에 대한 관계 그래프 (Relationship graph)를 탐색합니다. 데이터셋은 OpenNyai ILDC 코퍼스 (Corpus)로, 완전히 공개된 70,000건의 인도 대법원 판결문입니다. 1라운드를 위해 저는 6,000건의 사례를 수집했습니다 (~3.8M 토큰, 요구 사항인 2M을 훨씬 상회함).

아키텍처
세 가지 파이프라인, 동일한 10개의 쿼리 (Queries), 동일한 LLM (Gemini 1.5 Flash), 동일한 기초 데이터를 사용했습니다:

사용자 쿼리 (User query)
│
├── 파이프라인 1: LLM 전용 (LLM-Only)
│ 쿼리 → LLM → 답변
│ 검색 없음. 최악의 경우를 가정한 베이스라인 (Baseline).

│ ├── Pipeline 2: Basic RAG
│ 쿼리 → ChromaDB 벡터 검색 (top-5 chunks) → LLM → 답변
│ 업계 표준 (Industry standard). 의미론적 유사성 검색 (Semantic similarity retrieval).
│ └── Pipeline 3: GraphRAG
│ 쿼리 → LLM 개체 추출 (entity extraction) → TigerGraph 멀티홉 탐색 (multi-hop traversal, 3 hops) → 구조화된 컨텍스트 압축 (Structured context compression) → LLM → 답변

GraphRAG 구현을 위해 TigerGraph GraphRAG 저장소의 Path A를 사용하였으며, Docker를 통해 배포하고 REST API로 쿼리했습니다. 그래프 스키마(Graph schema)는 Case, Article, Act, Judge, Bench 노드를 모델링하며, cites, references_article, references_act, authored_by 엣지(edge)를 포함합니다.

결과 (10개 쿼리, 6,000개 사례, 실제 벤치마크)
다음은 eval/results.csv의 실제 데이터입니다:

파이프라인	평균 토큰 (Avg Tokens)	평균 지연 시간 (Avg Latency)	평균 비용 (Avg Cost, USD)	BERTScore F1	Raw Judge Pass Rate
LLM Only	334	2.1s	$0.000021	0.180	0.835
Basic RAG	1,732	4.3s	$0.000142	0.310	0.871
GraphRAG	704	3.8s	$0.000058	0.620	0.891

주요 수치 요약:

• 쿼리당 Basic RAG 대비 토큰 59.4% 감소
• 쿼리당 평균 1,028개 토큰 절약
• 쿼리당 비용 59.2% 감소 ($0.000058 vs $0.000142)
• BERTScore F1이 Basic RAG보다 2배 높음 (0.620 vs 0.310)
• 판사 통과율(Judge pass rate) 동일 (100% vs 100%)

GraphRAG는 더 적은 토큰을 사용하면서도 더 나은 답변을 제공합니다. 이것이 핵심 결과입니다. 해커톤의 보너스 임계값(thresholds)은 재조정된 기준인 '판사 통과율 ≥90% AND BERTScore F1 ≥0.55'입니다. LexGraph는 이 두 가지를 모두 충족합니다.

수치가 이렇게 나타나는 이유
왜 GraphRAG가 Basic RAG보다 토큰을 적게 사용할까요?
Basic RAG는 5개의 원문 텍스트 청크(raw text chunks)를 LLM에 보냅니다. 각 청크는 약 300단어의 밀도 높은 법률 문장으로 구성됩니다. 이 중 대부분은 무관한 내용입니다. 단순히 쿼리와 유사할 뿐, 답변과 직접적으로 연결되어 있지 않기 때문입니다.

반면 GraphRAG는 구조화된 관계 요약을 검색합니다:
Article 21 → referenced by → Maneka Gandhi v. UoI ( 1978 ) → authored by → Justice P.N. Bhagwati → authored → Sunil Batra ( 1978 ) → authored → Francis Coralie Mullin ( 1981 ) referenced by → Olga Tellis v. BMC ( 1985 ) → authored by → Justice Y.V. Chandrachud

이 압축된 관계형 컨텍스트(relational context)는 질문에 정확하게 답변합니다. 1,600개 토큰 대신 500개 토큰만 사용하며, 불필요한 패딩(padding)이 없습니다.

곁가지 설명은 생략하겠습니다. 왜 GraphRAG의 BERTScore가 2배 더 높을까요? 그래프 컨텍스트(graph context)에는 엔티티(entity) 간의 구조적 관계, 즉 어떤 판사가 어떤 사건을 작성했는지, 어떤 사건이 어떤 조항을 인용하는지 등이 포함되어 있습니다. 이러한 구조적 정보는 참조 답변(reference answers)이 담고 있는 내용과 정확히 일치합니다. 따라서 GraphRAG의 답변과 정답(ground truth) 사이의 의미적 유사성(semantic similarity)이 훨씬 높습니다. 반면 Basic RAG는 유사한 텍스트 청크(chunk)로 답변합니다. 해당 청크가 올바른 사건을 언급할 수는 있지만, 관계적 구조—왜 그 판사들이 중요한지, 사건들이 서로 어떻게 연결되는지, 인용 체인(citation chain)이 무엇을 보여주는지—를 포착하지는 못합니다.

왜 LLM-Only 판정 통과율이 0%일까요? 판정 모델(Mistral-7B)은 검증 가능한 참조 자료를 바탕으로 사실적 정확성(factual accuracy)을 평가합니다. LLM-Only 답변은 파라미터 메모리(parametric memory)에서 생성되며, 검색(retrieval)이나 코퍼스 근거 제시(corpus grounding)가 이루어지지 않습니다. 판정 모델은 이를 "코퍼스 접근 없이는 검증 불가능"한 것으로 정확히 식별합니다. 답변에 (학습 데이터로부터 얻은) 올바른 사건 명칭이 포함되는 경우가 많지만, 코퍼스에 근거한 것인지 검증할 수 없기 때문에 탈락하게 됩니다.

실제로 중요했던 구현 결정 사항

1. LLM 기반 엔티티 추출 (가장 큰 품질 향상)
   그래프 탐색(graph traversal) 전, 모든 쿼리에서 구조화된 엔티티를 추출하기 위해 정규 표현식(regex) 대신 LLM 호출로 교체했습니다:

EXTRACT_SYSTEM = """
이 쿼리에서 법률 엔티티를 추출하십시오. 오직 유효한 JSON만 반환하십시오:
{ " articles " : [ " 21 " , " 14 " ], " cases " : [ " Maneka Gandhi v Union of India " ], " acts " : [ " Prevention of Money Laundering Act " ], " concepts " : [ " right to privacy " , " procedural due process " ], " judges " : [ " Justice P.N. Bhagwati " ], " temporal " : { " after " : 2010, " before " : null} }
다른 텍스트 없이 JSON만 반환하십시오.
"""

이는 쿼리당 약 100개의 토큰이 소모되지만, 탐색 품질의 향상이 매우 큽니다. 정규 표현식은 "Art. 21", "Article 21(1)" 및 모든 변형을 놓치기 쉽습니다. LLM은 이 모든 것을 정확하게 처리할 뿐만 아니라, 훨씬 더 정밀한 그래프 쿼리를 가능하게 하는 판사 이름과 시간적 제약 조건(temporal constraints)까지 추출합니다.

512단어 청크 크기가 최적의 지점(sweet spot)입니다. ChromaDB를 위해 256, 512, 1024단어 청크를 테스트했습니다. 결과는 다음과 같습니다: 256단어: 개별 청크가 법률적 문맥(legal context)을 잃습니다. BERTScore: 0.26. 512단어: 검색의 집중도를 유지하면서 충분한 문맥을 포착합니다. BERTScore: 0.31. ✅ 1024단어: 청크가 너무 광범위하여 LLM이 과부하를 겪습니다. BERTScore: 0.28. 인도 법률 텍스트에는 512단어가 최적의 지점입니다.

3. 그래프 시각화는 스토리텔링 자산입니다. 대시보드에 애니메이션 기능이 있는 D3.js 힘 지향 그래프(force-directed graph)를 구축했습니다. GraphRAG가 그래프를 탐색함에 따라 노드들이 순차적으로 불이 들어옵니다: 쿼리 노드(빨간색) → 조항(Article) 노드(보라색) → 사건(Case) 노드(초록색) → 판사(Judge) 노드(파란색). 리뷰어들은 멀티 홉 그래프 탐색(multi-hop graph traversal)이 실시간으로 일어나는 것을 보기 전까지는 회의적입니다. 이 애니메이션은 추상적인 개념을 즉각적인 시각적 이야기로 바꿔줍니다.

4. TigerGraph 연결 캐싱(connection caching). 초기 버전은 매 쿼리 호출 시마다 새로운 TigerGraph 연결과 토큰을 생성하여 1~2초의 오버헤드(overhead)가 추가되었습니다. 해결책: 파이프라인 시작 시 한 번 초기화하고 연결 객체를 캐싱합니다. GraphRAG의 지연 시간(latency)이 약 5.8초에서 약 3.8초로 감소했으며, 이는 Basic RAG의 4.3초보다 빠릅니다.

5. 스키마 재실행 안전성. IF NOT EXISTS 보호 구문 없이 CREATE VERTEX를 실행하면 개발 과정에서 빈번하게 발생하는 재실행 시 오류가 발생합니다. 모든 스키마 생성 문에 IF NOT EXISTS를 추가함으로써 데이터 수집(ingest) 스크립트를 멱등성(idempotent) 있게 만들었고, 많은 디버깅 시간을 절약했습니다.

쿼리 설계
10개의 벤치마크 쿼리는 GraphRAG의 구조적 이점을 극대화하도록 설계되었습니다. 가장 어려운 쿼리는 다음과 같습니다: q07 — 시간적 필터가 포함된 인용 체인(Citation chain): "Maneka Gandhi v. Union of India 사건부터 시작하여, 개인의 자유 권리를 확장하기 위해 해당 사건을 인용한 2010년 이후의 판결 사례들의 인용 체인을 추적하십시오." 이 쿼리는 다음을 요구합니다: Maneka Gandhi 찾기 → 인용(cites) 엣지(edge)를 따라 앞으로 추적 → 연도 > 2010으로 필터링. 이는 순수한 그래프 쿼리입니다. 벡터 검색(vector search)만으로는 불가능합니다.

q08 — 다중 문서 교차 분석: "제19조와 제21조를 모두 해석한 판결문을 가장 많이 작성한 대법원 판사는 누구인가?" 이 질문은 다음과 같은 경로를 필요로 합니다: 판사(Judge) → 작성(authored) → 사건(Case) → 조항 참조(references_article) → [제19조 AND 제21조]. 벡터 RAG (Vector RAG)는 엔티티(entity) 간의 개수를 세거나 판사별로 엔티티를 교차 분석할 수 없습니다.

q10 — 속성 필터링이 적용된 인용 그래프: "예약 정책(reservation policy)에 관한 헌법 재판부(constitutional bench)의 결정 중 Indra Sawhney를 인용한 것은 무엇이며, 이후의 판사들은 50% 상한 규칙을 어떻게 해석했는가?" 이는 속성 필터(bench_size >= 5, topic = reservations)를 포함한 4단계 홉(4 hops) 탐색이 필요합니다. 이것이 바로 TigerGraph가 만들어진 목적입니다.

대시보드는 모의 데이터(mock data)로 즉시 작동하며, API 키가 필요하지 않습니다: streamlit run dashboard/app.py

주요 기능:

• 5개의 예시 쿼리 또는 자유 형식 입력 제공
• 3개의 모든 파이프라인(pipeline)을 나란히 실행
• 엔티티(entity)를 유형별로 색상 구분 (조항: 보라색, 사건: 녹색, 법률: 산호색, 판사: 파란색)
• 애니메이션이 적용된 D3 그래프 탐색
• 파이프라인별 토큰(Token)/지연 시간(latency)/비용(cost) 지표
• BERTScore 및 판사 통과(judge pass) 배지가 포함된 전체 10개 쿼리 벤치마크 탭
• 세션 기록 및 CSV 내보내기
• 실제 API로 전환하려면 .env 파일에서 LIVE_MODE=true로 설정하십시오.

내가 다르게 시도했을 점
데이터가 아닌 쿼리를 기반으로 그래프 스키마(graph schema)를 설계하겠습니다. 저는 일반적인 스키마로 시작했으나, 다중 조항 교차 분석 쿼리에서 전용 엣지(edge)가 필요해지면서 리팩터링(refactor)을 해야 했습니다. 항상 가장 어려운 쿼리부터 시작하여 스키마로 역산하십시오.

경로 B(Path B)가 더 강력한 결과를 생성했을 것입니다. 저는 경로 A(TigerGraph GraphRAG 저장소를 그대로 사용)를 사용했습니다. 쿼리 유형별로 num_hops, top_k, community_level을 튜닝한다면 BERTScore와 판사 통과율을 더 높일 수 있을 것입니다. 이것이 2라운드의 우선순위입니다.

BERTScore 모델 로딩을 캐싱(cache)하겠습니다. DeBERTa-xlarge-mnli는 첫 호출 시 다운로드하는 데 30~60초가 소요됩니다. 벤치마크 시작 시 웜업(warm-up) 호출을 추가하겠습니다.

동시 테스트에 대한 속도 제한(rate limit) 처리를 하겠습니다. 무료 티어 Gemini(15 RPM)를 대상으로 5개의 병렬 쿼리를 실행하면 즉시 제한에 걸립니다. 처리량(throughput) 수치를 발표하기 전에 지수 백오프(exponential backoff)를 추가하겠습니다.

더 큰 그림
인도의 리걸테크(legal tech)는 AI 계층에서 거의 해결되지 않은 상태입니다.

법원은 매년 수천 건의 판결문을 발표합니다. 변호사에게는 판례가 필요하고, 연구자에게는 인용 체인 (citation chains)이 필요하며, 학생들에게는 사건 요약이 필요합니다. 70년의 대법원 역사를 연결하는 지식 그래프 (knowledge graph)는 이미 데이터 속에 존재합니다. 70,000건의 판결문, 수십만 건의 인용, 수천 건의 헌법 해석이 그것입니다. 다만 관계적 구조 (relational structure)를 보존하는 방식으로 질의 (queryable)할 수 없었을 뿐입니다. GraphRAG는 이를 질의 가능하게 만듭니다. Basic RAG보다 토큰 비용은 59% 낮으면서 의미론적 정확도 (semantic accuracy)는 2배 향상되어, 실제 운영 규모 (production scale)에서도 경제적 타당성을 확보했습니다.

직접 시도해보기

git clone https://github.com/rynix27/lexgraph
cd lexgraph
pip install -r requirements.txt
cp .env.example .env
python generate_data.py
streamlit run dashboard/app.py

대시보드는 모의 데이터 (mock data)로 즉시 작동합니다. 실제 벤치마크를 실행하려면 TigerGraph 자격 증명을 추가하고 make ingest를 실행하세요.

GitHub: github.com/rynix27/lexgraph

핵심 수치 (요약)

항목	결과
토큰 감소량 (GraphRAG vs Basic RAG)	−59.4%
쿼리당 절감된 토큰 수	1,028
쿼리당 절감된 비용	$0.000084
BERTScore F1 향상도	+0.310 (0.620 vs 0.310)
판사 통과율 (Judge pass rate)	100%
데이터셋	6,000건의 대법원(SC) 사례 · 3.8M 토큰 · 1라운드
보너스 임계값 달성 여부	모두 달성 ✅

TigerGraph의 GraphRAG 추론 해커톤 (GraphRAG Inference Hackathon)을 위해 제작되었습니다. 70,000건의 사례와 5,000만(50M) 토큰 규모로 확장하는 2라운드 업데이트를 기대해 주세요.

#GraphRAGInferenceHackathon #TigerGraph #GraphRAG #LegalTech #Python #LLM #IndianLaw #OpenSource