26년 7월 4주차 그래프 오마카세

GUG 커뮤니티의 반가운 소식

• 오랜만에 인사드립니다 ! 다시 오마카세를 찾아주신 분들도, 이번에 처음 오신 분들도 모두 반갑습니다. 한국도 무더위가 이어지고 있다고 들었는데, 모두 건강하게 잘 지내고 계셨나요?
• 최근 저희 GUG(Graph User Group)에 정말 ​반가운 소식이 있어서 전해드리고자 합니다. GUG가 2026 오픈소스 AI·SW 커뮤니티 지원사업에 선정되었습니다. 7월 25일(토요일) 한국과학기술회관에서 진행된 발대식에도 저희 운영진분들께서 참석해주셨습니다.
• 이번 지원을 바탕으로, 하반기부터 멘토 기반 프로젝트 완주 프로그램인 Graph Batch Program을 운영하고자 합니다. 단순히 그래프 기술을 공부하는 데서 그치지 않고, 실제 프로젝트를 끝까지 완성할 수 있도록 멘토링과 실험 환경을 함께 지원하는 프로그램입니다.
  • 프로젝트 아이디어를 가진 학부생, 대학원생, 연구자, 실무자를 선발해 온톨로지, 지식그래프, GraphRAG, 인과추론, 복잡계, 의료영상 분석 등 분야별 멘토와 연결합니다.
  • 참여 팀에는 GPU·클라우드·API 등의 컴퓨팅 자원과 주간 오피스아워를 제공하며, 완성된 결과물은 오픈소스로 공개하고 데모데이와 학회 및 해외 컨퍼런스 발표로 이어갈 예정입니다.
• 관심 있는 GUG 회원분들과 오마카세 구독자분들의 많은 참여를 기다리겠습니다. 또한 그래프 기술을 함께 배우고, 만들고, 국내외로 확산하는 일에 함께하고 싶은 분이라면 언제든 GUG의 문을 두드려주세요. 늘 함께해주셔서 감사합니다 !

RAGU:A Multi-Step GraphRAG Engine with a Compact Domain-Adapted LLM

RAGU: A Multi-Step GraphRAG Engine with a Compact Domain-Adapted LLM

Graph retrieval-augmented generation (GraphRAG) enhances large language models with structured knowledge, yet existing systems construct knowledge graphs in a single extraction pass, producing noisy entities and brittle retrieval. RAGU, an open-source modular GraphRAG engine, addresses this by separating extraction from consolidation: entities and relations pass through two-stage typed extraction, DBSCAN-backed deduplication, LLM summarization, and Leiden community detection. A key insight motivates a compact extractor: the skills an in-pipeline LLM needs - comprehension, extraction, reasoning over context - are language skills that grow only weakly with model size, unlike factual world knowledge. Accordingly, we train Meno-Lite-0.1, a 7B model optimized for language skills, which outperforms Qwen2.5-32B on knowledge-graph construction (+12.5% relative harmonic mean) and matches it on English GraphRAG tasks. On GraphRAG-Bench (Medical), RAGU retrieves the most complete context at every factoid level (evidence recall up to 0.84 vs. $\leq$0.76) and overtakes HippoRAG2 on synthesis tasks; on multi-hop factoid QA, the apparent HippoRAG2 advantage is shown to be largely an answer-format artifact. RAGU is installable via $\texttt{pip install graph_ragu}$, runs on a single GPU, and is released under MIT. The source code is publicly available at https://github.com/RaguTeam/RAGU, and the Meno-Lite-0.1 model can be obtained from https://huggingface.co/bond005/meno-lite-0.1.

arXiv.orgMikhail Komarov

Paper page - RAGU: A Multi-Step GraphRAG Engine with a Compact Domain-Adapted LLM

Join the discussion on this paper page

RAGU: A Multi-Step GraphRAG Engine with a Compact Domain-Adapted LLMMikhail Komarov

• 충전 후 돌아온 만큼 뭔가 거창한 주제나 이야기부터 꺼내는것 보다는 예전 오마카세의 주제와 연결되는 질문으로 천천히 시작해보는 것이 좋을거 같아서, 관련된 재밌는 논문 한편을 들고 왔습니다.
• 지난 호에서는 Deep GraphRAG(5월 2주차 발행) 논문을 통해 지식 그래프를 어떻게 더 빠르고 정확하게 탐색할 것인지 살펴봤습니다. 하지만 여전히 실무 도입을 막는 몇 가지 걸림돌이 존재하고 있는데, 이번 논문의 저자들은 GraphRAG 도입의 문제점을 크게 세 가지로 정리합니다.
  • 단발성 추출 (Single-pass extraction) : 대부분의 시스템이 그래프 구성을 한 번의 LLM 추출로 끝내다보니, 같은 엔티티와 관계에 대한 설명이 중복해서 쌓이고, 이를 정리하는 단계가 없음.
  • 값비싼 LLM에 크게 의존: 추출 품질이 그래프 품질을 좌우한다는 이유로 대부분 대형 API 모델을 기본값으로 사용함.
  • 엔지니어링의 미성숙함: 오픈소스 GraphRAG 프레임워크 상당수가 설치가 까다롭거나, 심하게는 LLM 출력을 단순 eval함수 호출로 그대로 실행하는 안전하지 않은 코드 경로를 가지고 있음.
• 비싼 LLM이 꼭 필요하다는 통념이 사실은 잘못된 전제 위에 서 있다고 저자들은 주장합니다. 아무리 검색 전략이 정교하고 그 부분을 똑똑하게 처리하는 베이스 모델을 사용한다고 하더라도, 재료가 되는 그래프 자체가 중복 오류 투성이라면 당연히 좋은 답을 얻기 어렵기 때문입니다.

• 그로부터 저자들이 세운 가설은 다음과 같습니다. 그리고 이를 Qwen2.5 모델 패밀리(0.5B~72B)로 직접 검증합니다.
  • Figure 1에서 보여주듯이, 순수 세계 지식 퀴즈인 CheGeKa에서는 F1 점수가 0.5B에서 72B로 갈 때 21.1배 뛰지만, 정답에 필요한 사실이 모두 문맥 안에 주어지는 MultiQ에서는 겨우 4배 오르는 데 그칩니다. 로그-선형 기울기로 보면 0.65 대 0.26, 두 능력의 성장 속도가 확연히 다릅니다. 이 관찰이 논문 전반적으로 잡혀있는 설계적 철학으로 연결되어집니다.
  • 다만 이는 Qwen2.5 계열과 이 두 벤치마크에서 관찰된 결과로, 저자들 스스로도 이를 모든 모델과 과제에 그대로 적용되는 보편 법칙이 아니라 잘 뒷받침된 가설로 규정하고 있습니다.

• 즉, GraphRAG 파이프라인 안에서 LLM에게 정말 필요한 능력은 주어진 문맥을 정확히 읽고 엔티티,관계로 구조화하며, 근거 안에서 답을 만들어내는 능력이라는 것을 해당 논문에서 핵심 주장으로 강조하고 있습니다.
• 이 가설을 바탕으로 저자들은 두 가지의 산출모델인 7B 소형 모델 Meno-Lite-0.1과 RAGU 모듈형 파이프라인을 오픈소스로 제공합니다. RAGU 코드는 MIT 라이선스, Meno-Lite-0.1 모델은 Apache 2.0 라이선스로 공개되어 있으며, 위의 허깅페이스로부터 모델 접근이 가능합니다.

• RAGU의 핵심 아이디어는 단순합니다. 추출(Extraction)과 정리(Consolidation)를 같은 단계에서 처리하지 말자, 이 한 줄을 여섯 단계짜리 파이프라인으로 구체화한 것이 이 논문의 핵심입니다.
  • Figure 2는 그 전체 흐름을 보여줍니다. 문서를 작은 단위로 나눈 뒤 엔티티와 관계를 추출하고, 바로 그래프로 넘기지 않고 먼저 중복된 설명과 관계를 정리합니다. 그다음 정제된 정보로 그래프를 구성하고, 서로 밀접하게 연결된 노드들을 커뮤니티로 묶어 요약한 뒤, 그래프, Key-Value(KV), 벡터 저장소에 각각 저장합니다.
  • 그림에서 가장 눈여겨볼 부분은 추출과 그래프 구성 사이에 ‘Deduplication & Summarization’이 별도의 단계로 들어가 있다는 점입니다. 기존 단발성 방식이 추출 결과를 곧바로 그래프로 만드는 데 비해, RAGU는 그래프가 만들어지기 전에 한 차례 정리 과정을 거칩니다. 저자들이 말하는 Consolidation이 바로 이 구간입니다.
• '4. Demonstration' 섹션의 case study로 나온 Dennis Ritchie 사례를 살펴보면서 핵심 아이디어를 직관적으로 이해할 수 있습니다.

• 예를 들어 문서에 "C 언어를 만든 Dennis Ritchie의 아버지 Alistair Ritchie는 Bell Laboratories에서 일했다"는 문장이 들어 있다고 해봅시다.
• 일반적인 텍스트 검색은 관련 문장을 찾아주는 데 강하지만, 그래프로 만들어두면 'C 언어 → Dennis Ritchie → 아버지 → Bell Laboratories' 처럼 여러 관계를 명시적으로 따라가 'C 언어를 만든 사람의 아버지는 어디서 일했나?' 처럼 여러 단계를 거쳐야 답할 수 있는 질문에도 대응할 수 있습니다.
• RAGU가 공들이는 지점은 바로 이 그래프를 얼마나 깨끗하게, 노이즈 없이 만들어내느냐입니다.

Two-Stage Extraction ㅡ 2단계 추출

• 기존 시스템 대부분은 엔티티와 관계를 한 번에 같이 뽑지만, RAGU는 이를 명확히 분리합니다. 
• 1단계에서 먼저 엔티티만 추출하고, NEREL (러시아어 개체명 인식 스키, 29개 엔티티 타입, 49개 관계 타입) 기준으로 검증합니다. 2단계에서 관계를 추출할 때는, 검증된 엔티티 목록을 제약 조건으로 피드백합니다. 
• 여기에서 source, target은 반드시 1단계에서 확인된 엔티티 이름과 일치해야 합니다. 이렇게 하면 관계가 앞 단계에서 발견되지 않은 엔티티를 새로 만들어 가리키는 오류는 막을 수 있습니다. 다만 두 엔티티 사이에 실제로 어떤 관계가 있는지, 그 내용 자체가 항상 정확해지는 것은 아닙니다.

Consolidation ㅡ 중복 오류 관계 및 노이즈 정리

• LightRAG 같은 단발성 시스템에는 없는 단계로, RAGU는 커뮤니티를 찾기 전에 먼저 그래프의 중복과 노이즈를 줄입니다. 여기서 중요한 것은 서로 다른 별칭을 하나로 통합하는 것이 아니라, 같은 엔티티에 대해 여러 청크에 흩어진 중복 설명과 관계를 정리한다는 점입니다.
• RAGU는 여러 청크에서 같은 이름과 타입을 가진 엔티티가 반복 추출되면, 그 엔티티에 쌓인 설명들을 유사도에 따라 DBSCAN으로 묶고, LLM이 하나의 대표 설명으로 요약합니다. 그리고 정리된 그래프 위에서 Leiden 클러스터링을 통해 계층적으로 커뮤니티를 나누고, LLM이 각 커뮤니티마다 제목, 요약, 핵심 발견을 담은 구조화된 리포트를 생성합니다.

언어 특화 7B 모델: Meno-Lite-0.1

• Meno-Lite-0.1은 러시아어 특화 7B 모델(RuadaptQwen2.5-7B)을 정보추출과 멀티홉 QA 중심으로 추가 학습한 모델입니다. 핵심은 사실을 암기하게 하는 것이 아니라 주어진 문맥을 활용하도록 가르치는 것에 학습 목표를 맞췄다는 점입니다.
• 저자들이 밝히기를, Meno-Lite-0.1 7B 모델은 사실 지식의 암기보다 문맥 활용 능력에 학습 역량을 집중한 모델이라 만능은 아니며, 단독 지식 베이스로 쓰기엔 적합하지 않다고 합니다. 따라서 이 모델이 전하는 핵심 의미는 단순히 소형 모델이 대형 모델을 이겼다는 것보다, 오히려 정리 단계를 포함한 파이프라인 구조가 최종 성능의 모델 의존도를 낮췄다는 점입니다.

엔지니어링 성숙도 ㅡ 잘 작동하는 것과 안전하게 배포 가능한 것의 차이

• RAGU는 검색 성능뿐 아니라 실제 배포를 고려한 구조에도 공을 들였습니다. LLM 출력을 eval로 실행하지 않고 Pydantic으로 검증하며, 그래프, KV, 벡터 저장소를 교체 가능한 계층으로 분리했습니다. 또한 약 374개의 자동화 테스트를 제공합니다. 이는 단순히 작동하는 코드와 안전하게 운영할 수 있는 시스템 사이의 차이를 보여줍니다.

• 논문 부록 A에서는 2025년 9월 당시 특정 HippoRAG 2 커밋에서 eval 기반 출력 처리 경로를 지적합니다. 다만 이는 현재 버전 전체에 대한 단정이 아니라, 저자들이 고정한 당시 코드 상태에 대한 비교로 이해하는 것이 올바릅니다. (각주번호 5 참고)
• RAGU는 여러 검색 방식(Local & Global Search 등)을 제공하지만, 이 논문의 핵심 차별점은 검색보다 그래프 구축과 정리 과정에 있다는 것을 기억해두시면 됩니다.

Experimental GraphRAG-Bench Results

• 위에서 말씀드렸듯이, Meno-Lite-0.1은 만능 모델이 아니라, 정보추출과 문맥 이해라는 특정 목표에 맞춰 설계된 경량 모델입니다. 따라서 실험 결과를 볼 때 가장 먼저 구분해야 할 것은, 관련 근거를 폭넓게 모으는 능력과 그 가운데 정답 하나를 정확히 찾아내는 능력이 서로 다른 성격의 과제라는 점입니다. 전자는 RAGU가, 후자는 HippoRAG 2가 상대적으로 강점을 보입니다.
• GraphRAG-Bench 결과에서 나타나는 교차 패턴도 이 구분으로 설명됩니다. Fact Retrieval에서는 personalized PageRank로 단일 사실을 정확히 짚어내는 HippoRAG 2가 앞서지만, 과제가 복잡한 종합,추론으로 갈수록 격차가 좁혀지다가, 창의적 생성에서는 오히려 RAGU가 역전합니다.
• Creative Generation에서는 Coverage도 RAGU가 57.4%로 HippoRAG 2(34.7%)를 크게 앞섭니다. Evidence Recall은 모든 난이도 구간에서 RAGU가 가장 높습니다. 즉, 필요한 근거를 빠짐없이 찾아오는 능력에서는 가장 안정적인 모습을 보였습니다.

Multi-hop QA Results

• 멀티홉 QA(BioASQ, MuSiQue, 2WikiMultiHopQA)에서는 답변 형식이 점수를 크게 왜곡한다는 점도 짚어둘 만합니다. 기본 설정 그대로 비교하면 HippoRAG 2가 전 항목에서 압도적으로 보이지만, 이 격차의 상당 부분은 답변 형식 차이에서 비롯된 것이었습니다. 
  • 한 문장으로만 답하라는 동일한 terse 프롬프트로 통일하면 RAGU는 BioASQ에서 HippoRAG 2를 근소하게 앞서고(72.9 vs 72.4), 2WikiMultiHopQA 격차도 -19.3pp에서 -5.5pp로 좁혀집니다.
  • 다만 형식을 통제한 뒤에도 가장 어려운 멀티홉 벤치마크인 MuSiQue에서는 HippoRAG 2의 우위(54.4 vs 40.1)가 그대로 유지됩니다
  • 저자들은 personalized PageRank 기반 탐색이 긴 추론 체인을 따라가는 데 여전히 강점을 보이기 때문으로 해석합니다.

IE Benchmark Results

• 정보추출(IE) 자체의 성능을 보면, 지식그래프 구성 작업의 조화평균 기준으로 Meno-Lite-0.1(7B)이 Qwen2.5-32B보다 12.5% 높은 상대 점수를 기록합니다. 특히 문맥 이해가 가장 많이 요구되는 관계 추출(RE)에서 격차가 큽니다(F1 0.347 vs 0.239). 다만 학습과 평가가 동일한 NEREL 스키마, 도메인을 공유하므로, 이 우위의 일부는 도메인 적합성에서 왔을 가능성이 있습니다.
  • 흥미로운 점은 별도의 정보추출 시험에서는 모델 간 차이가 컸지만, 완성된 GraphRAG의 답변 성능에서는 추출 모델을 바꿔도 차이가 약 1~2%포인트에 그쳤다는 점입니다. (3B~14B Ablation 실험에서도 변화 폭은 약 1.5%포인트 이내)
  • 저자들은 이를 Consolidation이 추출기의 오류를 일부 흡수해, 파이프라인 전체가 모델 선택에 덜 민감해진 결과로 해석합니다. 즉 이 논문의 기여는 7B가 32B를 이겼다! 라는 직관적인 해석보다, 파이프라인 구조가 모델 선택에 대한 의존도를 낮췄다는 쪽에 더 가깝습니다.
• 위의 실험결과들을 바탕으로 요약해본 각 시스템별 강점은 다음과 같습니다.
  • LightRAG : 모든 난이도에서 전반적으로 가장 낮은 성능을 보임.
  • HippoRAG2 : personalized PageRank 기반 체인 추적. 단일 사실 검색과 정밀한 멀티홉 추론에 강함.
  • RAGU : 정리 기반 넓은 컨텍스트 확보. 종합, 창의적 생성, 폭넓은 근거 커버리지에 강함. 타입 검증과 정리 단계를 포함한 구축 방식이 보다 안정적인 그래프를 만들 수 있음.

• RAGU가 던지는 메시지는 명확합니다. GraphRAG 파이프라인을 설계할 때 어떤 단계에 어떤 크기의 모델을 배치할 것인가는 단순한 비용 문제가 아니라, 그 단계가 요구하는 능력이 세계 지식인지 문맥 이해 능력인지를 먼저 구분해야 풀리는 설계 문제라는 것입니다.
• 추출,정리,요약처럼 주어진 문맥을 잘 다루는 것이 핵심인 단계는 소형 특화 모델로도 충분하고, 오히려 그 편이 비용과 배포 난이도 면에서 훨씬 유리합니다.
• 지난 호에서 소개했던 Deep GraphRAG는 강화학습을 통해 이 문제를 풀었다면, RAGU는 도메인 특화 파인튜닝과 파이프라인 설계라는 전혀 다른 접근을 택했습니다. 방법은 다르지만, 모델 크기보다 역할 분리가 중요하다는 결론은 두 논문이 공통적으로 보여주는 메시지입니다.

• 한계도 분명히 언급하고 있습니다. 이 논문의 핵심 가설은 Qwen2.5 한 계열에서만 검증됐고, 기본 NetworkX 백엔드는 대규모 그래프에 바로 적합하지 않으며, NEREL 역시 러시아어 뉴스 도메인에 맞춰진 스키마입니다. 따라서 다른 언어나 산업 도메인에 적용하려면 모델과 스키마를 다시 검증해야 합니다.
• 실무적인 관점에서 보더라도, 추출과 정리를 분리하는 2단계 설계, 커뮤니티 탐지 전에 DBSCAN으로 노이즈를 먼저 줄이는 순서, 그리고 LLM 출력을 eval호출 없이 Pydantic으로 검증하는 안전한 파싱 방식은 GraphRAG가 아니더라도 어느 LLM 파이프라인에나 바로 적용할 수 있는 설계 원칙입니다.
• 물론 모든 환경에서 이런 비용 절감이 그대로 재현된다는 뜻은 아닙니다. 그럼에도 이 논문은 작은 모델과 좋은 파이프라인 설계만으로도 충분히 경쟁력 있는 GraphRAG를 만들 수 있다는 점을 설득력 있게 보여주었습니다.
• 큰 모델이 정말 필요한 단계와, 그렇지 않은 단계를 구분하는 것이 더 중요하다는 관점은 GraphRAG뿐 아니라 앞으로 등장할 많은 LLM 시스템에서 계속 중요해질 것 같습니다.

Reference

• RAGU 시연 동영상 : https://www.youtube.com/watch?v=bicJDMJuQfg&feature=youtu.be
• Leiden 클러스터링이란 : https://m.blog.naver.com/sw4r/222504677091
• 논문 가설 (세계 지식 vs 문맥 이해) 근거문헌 : https://aclanthology.org/2024.acl-long.534.pdf

[Contact Info]

Gmail: jhbae1184@akane.waseda.jp

Twitter (X): @jhbae1184

LinkedIn