지금 누구나 일반 RAG보다 18% 더 높은 정확도와 85% 더 낮은 비용으로 복잡한 질문에 답하는 AI 시스템을 구축할 수 있습니다. 박사 학위도, 수백만 달러 예산도, 연구팀도 필요 없습니다.
여러분과 그 결과 사이에 있는 유일한 장애물은 Microsoft, Stanford, Anthropic이 모두 독자적으로 발견했지만, 대부분의 개발자가 아직 따라잡지 못한 하나의 개념입니다.
일반 RAG는 텍스트를 찾습니다. Graph Engineering은 관계를 찾습니다. 여기에 그 전체 시스템이 있습니다.
이 글을 북마크하고 팔로우하세요
- 저는 Sprytix입니다. AI 시스템과 자동화 파이프라인을 구축하여 기술을 실제 수익으로 전환하는 개발자입니다. DM은 항상 열려 있습니다.
일반 RAG의 한계
일반 RAG는 다음과 같이 작동합니다:
1질문2↓3일치하는 텍스트를 찾기 위해 문서 검색4↓5가장 관련성 높은 청크 반환6↓7청크를 기반으로 모델이 답변 생성
이 방식은 간단한 질문에는 잘 작동합니다. 하지만 복잡한 질문에는 완전히 실패합니다.
"3월에 제품 판매가 하락한 이유는 무엇인가요?"라고 물으면 RAG는 "판매"와 "3월"이라는 단어가 포함된 문서를 찾습니다. 단편만 찾을 뿐, 인과 관계의 사슬은 찾지 못합니다.
1RAG 답변:23월 판매와 관련된 5개의 문서를 찾았습니다.34Graph Engineering 답변:5판매 하락은6공급업체 의존성으로 인한 출시 지연으로 인해 발생했으며,7이는 창고 문제로 촉발되었고,8부정적인 리뷰를 생성했으며,9이는 전환율을 23% 감소시켰습니다.
동일한 모델. 동일한 데이터. 완전히 다른 결과 - 한 시스템은 텍스트를 검색하고 다른 시스템은 현실을 검색하기 때문입니다.
이것이 Microsoft, Stanford, Anthropic이 모두 독자적으로 발견한 사실입니다. 그리고 이것이 세 기업 모두 Graph Engineering으로 전환한 이유입니다.
문서 1 - Microsoft GraphRAG
Microsoft는 GraphRAG를 구축하여 오픈소스로 공개했습니다. 그들의 연구 결과는 Graph Engineering이 일반 RAG에 비해 실제로 제공하는 성능에 대한 가장 구체적인 수치를 제공합니다.
이 아키텍처는 구조화되지 않은 텍스트를 완전한 지식 그래프로 변환합니다:
1문서 로드2↓3문서 청킹4↓5엔터티 및 관계 추출6↓7그래프 구축8↓9커뮤니티 탐지10↓11커뮤니티 보고서 생성12↓13엔터티 및 보고서 임베딩14↓15로컬 검색 / 글로벌 검색
Microsoft가 문서화한 핵심 통찰력: 일반 RAG는 로컬 질문(특정 엔터티에 대한 정보 찾기)에는 잘 대응하지만, 글로벌 질문(전체 데이터셋의 주요 테마, 10,000개 문서를 연결하는 패턴)에는 실패합니다.
Graph Engineering은 둘 다 대답합니다.
1로컬 검색 | 3월에 공급업체 X에서 무슨 일이 있었나2 | 특정 노드와 그 연결을 찾음34글로벌 검색 | 모든 공급업체 관계에서5 | 주요 위험 패턴은 무엇인가6 | 전체 그래프에서 패턴을 찾음
Microsoft GraphRAG 연구의 실제 결과:
1정확도 향상 | 원시 문서 접근 방식보다 18% 높음2토큰 비용 절감 | 구조화된 파일을 직접 로드하는 것보다 85% 낮음3작업당 비용 | 테스트 구성에서 약 $0.004
이 수치는 ChatP&ID 논문(산업 엔지니어링 다이어그램에 GraphRAG를 적용)에서 가져온 것입니다. 동일한 원리가 다양한 영역에 적용됩니다.
문서 2 - Stanford DSPy와 그래프 연결
Stanford의 DSPy 논문은 모델이 그래프의 노드일 뿐, 우주의 중심이 아니라는 점을 확립했습니다. 이것이 Graph Engineering에 직접 연결되는 이론적 기반입니다.
DSPy는 AI 파이프라인을 모듈의 그래프로 취급합니다:
1질문2↓3검색기(Retriever) - 관련 정보를 찾음4↓5추론(Reasoning) - 처리 및 연결6↓7검증기(Verifier) - 결과 확인8↓9답변
Graph Engineering과의 연결은 직접적입니다: DSPy는 파이프라인 그래프를 최적화하고, GraphRAG는 지식 그래프를 최적화합니다. 둘 다 모델을 전체 솔루션이 아닌 더 큰 구조의 한 구성 요소로 취급합니다.
Stanford의 STORM 논문은 한 걸음 더 나아갑니다:
STORM은 한 단어도 쓰기 전에 구조화된 연구 단계 그래프를 통해 처음부터 지식을 구축합니다. 연구, 소스 수집, 개요, 작성, 검증, 수정 - 각 단계는 이전 단계에서 발견된 관계에 의해 정보를 얻습니다.
모든 Stanford 연구의 공유된 통찰력: 복잡한 작업은 단일 모델 호출이 아니라 연결된 단계의 시스템이 필요합니다. 그래프가 곧 시스템입니다.
문서 3 - 지식 그래프에 대한 Stanford 확장 법칙
이 논문은 지식 그래프 엔지니어링 작업에 대해 26개의 오픈소스 모델을 비교했습니다. 결론은 이 분야에서 가장 중요한 결론 중 하나입니다:
1더 큰 모델 + 나쁜 그래프 | 더 나쁜 결과2더 작은 모델 + 좋은 그래프 | 더 나은 결과
올바른 그래프가 더 큰 모델을 이깁니다. 항상 그렇습니다.
이는 Microsoft가 GraphRAG로, Anthropic이 Claude Code로 도달한 것과 동일한 결론입니다 - 모델 주변의 시스템이 모델 자체보다 출력을 더 많이 결정합니다. Graph Engineering은 그 원칙의 가장 구체적인 구현입니다.
문서 4 - 관계형 메모리에 대한 MIT Press 연구
direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476
계산 언어학 협회(Transactions of the Association for Computational Linguistics)에 게재됨.
이 연구는 언어 모델을 관계형 메모리(텍스트 청크가 아닌 관계의 지식 그래프)에 연결할 때 어떤 일이 발생하는지 보여줍니다.
1텍스트 컨텍스트2↓3그래프에서 관련 관계 검색4↓5관계형 메모리6↓7언어 모델8↓9더 일관되고 정확한 생성
핵심 발견: 명시적 관계 구조에 접근할 수 있는 모델은 텍스트만으로 작업하는 모델보다 더 일관된 텍스트를 생성하고 논리적 오류를 더 적게 범합니다.
이것이 Graph Engineering이 작동하는 이유에 대한 과학적 설명입니다. 모델은 텍스트에서 관계를 추론할 필요가 없습니다. 관계는 그래프에 명시적으로 존재합니다. 모델은 이를 직접 사용합니다.
문서 5 - KEPLER
KEPLER는 언어 모델 훈련과 지식 그래프 임베딩을 결합합니다. 언어 이해와 사실적 지식을 별개의 문제로 취급하는 대신, KEPLER는 둘을 동시에 최적화합니다.
1언어 모델2+3지식 임베딩4+5지식 그래프6=7언어와 사실을 모두 이해하는 모델
실용적 의미: 적절히 구조화된 지식 그래프에 접근할 수 있는 모델은 엔터티 간의 관계를 추측할 필요가 없습니다. 그냥 조회하면 됩니다. 사실적 질문에 대한 정확도 차이는 상당합니다.
문서 6 - Anthropic과 그래프 속의 Claude
- www.anthropic.com/customers/graph
- github.com/anthropics/anthropic-cookbook
- github.com/modelcontextprotocol
Anthropic에는 "Graph Engineering"이라는 제품이 없습니다. 대신 Claude가 그래프 아키텍처에 직접 통합되는 세 가지 계층이 있습니다.
계층 1 - Claude가 텍스트에서 그래프 추출
1문서2↓3Claude가 엔터티와 관계 추출4↓5JSON 트리플:6{7 "subject": "Anthropic",8 "relation": "created",9 "object": "Claude"10}11↓12지식 그래프
Claude는 엔터티 추출, 관계 추출, 중복 제거, 정규화 및 온톨로지 초안 작성을 처리합니다. 이전에 특수 NLP 파이프라인이 필요했던 작업이 이제는 하나의 API 호출로 실행됩니다.
계층 2 - Claude가 그래프 쿼리
1사용자 질문2↓3Claude4↓5Cypher / SPARQL 쿼리6↓7지식 그래프8↓9결과10↓11Claude의 평이한 언어 설명
Claude는 자연어를 그래프 쿼리로 변환하고, Neo4j 또는 모든 그래프 데이터베이스에 대해 실행한 후 결과를 설명합니다. 사용자는 쿼리 언어를 알 필요가 없습니다.
계층 3 - MCP가 Claude를 그래프에 연결
github.com/modelcontextprotocol
1Claude2↓3MCP 프로토콜4↓5그래프 데이터베이스6↓7엔터티 + 관계8↓9전체 그래프 컨텍스트를 가진 Claude
MCP는 매 세션마다 연결을 다시 구축할 필요 없이 Claude에게 모든 지식 그래프에 대한 영구적인 액세스 권한을 부여하는 전송 계층입니다.
LaunchNotes 사례 - 실제 프로덕션 수치
www.anthropic.com/customers/graph
LaunchNotes는 GitHub, Jira 및 Linear를 연결하는 Graph라는 제품을 구축했습니다. Claude는 세 시스템 모두에서 엔지니어링 작업 간의 관계를 분석합니다.
1GitHub 커밋2+3Jira 티켓4+5Linear 작업6↓7엔지니어링 작업 그래프8↓9Claude10↓11인시던트 탐지 + 프로젝트 인사이트
Anthropic 사례 연구의 결과:
1인시던트 탐지 | 최대 5배 빠름2회의 시간 | 약 50% 감소3릴리스 노트 | 몇 초 만에 자동 생성
이 수치는 문서 검색이 아닌 구조화된 관계 데이터 연결에서 비롯됩니다.
지식 그래프란 실제로 무엇인가
구축하기 전에 기본 개념을 알아보겠습니다.
지식 그래프는 정보를 트리플로 저장합니다:
1주어 → 관계 → 목적어
예시:
1Anthropic → created → Claude2Claude → supports → MCP3MCP → connects → external tools4Microsoft → built → GraphRAG5GraphRAG → reduces token cost by → 85%
모든 정보 조각은 두 엔터티 간의 명시적 관계입니다. 이 정보를 포함할 수도 있는 텍스트 단락이 아니라, 명시적이고 구조화되며 쿼리 가능한 사실입니다.
1일반 데이터베이스:2회사 테이블3제품 테이블4둘 사이의 명시적 관계 없음56지식 그래프:7회사 → created → 제품8제품 → competes with → 다른 제품9다른 제품 → owned by → 다른 회사10회사 → invested in → 다른 회사
그래프는 사실을 저장할 뿐만 아니라 사실들이 서로 어떻게 연결되는지도 저장합니다. 이것이 복잡한 추론을 가능하게 하는 이유입니다.
전체 Graph Engineering 파이프라인
11단계 | 원시 문서 수집2 | PDF, 이메일, 보고서, 데이터베이스 내보내기342단계 | 엔터티 추출5 | 사람, 회사, 제품, 이벤트, 개념673단계 | 관계 추출8 | 누가 누구에게 무엇을, 언제, 왜, 어떻게 했는지9104단계 | 스키마 구축11 | 엔터티 유형 및 관계 유형 정의12135단계 | 중복 제거 및 정규화14 | "Microsoft Corp"와 "MSFT"는 동일한 엔터티15166단계 | 그래프 데이터베이스에 저장17 | Neo4j, Amazon Neptune, 그래프 확장이 있는 PostgreSQL18197단계 | 검색 계층 구축20 | 특정 엔터티에 대한 로컬 검색21 | 전체 그래프의 패턴에 대한 글로벌 검색22238단계 | 모델 연결24 | Claude가 MCP 또는 직접 API를 통해 그래프 쿼리25269단계 | 지속적 업데이트27 | 새 문서가 그래프 확장28 | 모순 사항은 검토 플래그 지정
arxiv.org/abs/2307.06917의 LLM 지원 지식 그래프 엔지니어링(LLM-assisted Knowledge Graph Engineering) 논문은 언어 모델이 각 단계를 얼마나 잘 처리하는지 벤치마킹합니다. 솔직한 결과: LLM은 추출 및 정규화에 탁월한 어시스턴트이지만, 제로샷 그래프 생성은 스키마 및 중복 제거 단계에 대한 사람의 검토 없이 프로덕션에 사용하기에는 아직 충분히 신뢰할 수 없습니다.
전체 파이프라인을 실행하는 다섯 가지 프롬프트
Graph Engineering이 프롬프트를 없애는 것은 아닙니다. 그래프 파이프라인의 각 특정 단계에서 프롬프트를 사용합니다.
프롬프트 1 - 추출
1모든 조직, 사람, 제품 및 이벤트를 추출하세요.23각 엔터티에 대해 다음을 반환하세요:4- canonical_name5- type6- description7- source89각 관계에 대해 다음을 반환하세요:10- source_entity11- relation_type12- target_entity13- evidence14- confidence_score
프롬프트 2 - 정규화
1다음 엔터티들을 비교하세요.2이것들이 다음 중 무엇을 참조하는지 결정하세요:3- 동일한 엔터티4- 관련되지만 다른 엔터티5- 관련 없는 엔터티67정식 이름과 설명을 반환하세요.8명확한 증거 없이 엔터티를 병합하지 마세요.
프롬프트 3 - 그래프 쿼리
1사용자 질문을 Cypher 쿼리로 변환하세요.2스키마에 있는 관계만 사용하세요.3레이블이나 속성을 임의로 만들지 마세요.4쿼리와 로직에 대한 짧은 설명을 반환하세요.
프롬프트 4 - 근거 기반 답변
1검색된 그래프 경로만 사용하여 답변하세요.2모든 결론에 대해:3- 지원 노드를 식별하세요4- 관계 경로를 식별하세요5- 불확실성을 명확히 밝히세요6- 상관관계로부터 인과관계를 추론하지 마세요
프롬프트 5 - 그래프 유지보수
1새로운 사실을 기존 그래프와 비교하세요.2각 사실을 다음 중 하나로 분류하세요:3- 새로운(new)4- 중복(duplicate)5- 모순(contradiction)6- 업데이트(update)7- 불확실(uncertain)89증거 없이 기존 사실을 덮어쓰지 마세요.
Microsoft의 GraphRAG 문서에서 볼 수 있듯이, 프롬프트는 내부적으로 추출, 관계 식별, 요약 및 커뮤니티 보고서 생성을 처리합니다. 프롬프트 엔지니어링은 그래프 엔지니어링 내부의 메커니즘이지, 그 경쟁자가 아닙니다.
지식 그래프로 구축할 수 있는 다섯 가지 비즈니스
1 - 실사 플랫폼
1기업 보고서 + 창업자 + 투자자2+ 법적 사건 + 자회사 + 거래3↓4지식 그래프5↓6Claude7↓8위험 분석 + 숨은 연결 + 이해 충돌 탐지
고객: 투자 펀드, 로펌, 은행, M&A 컨설턴트. 고객당 월 정액 $2,000-10,000.
2 - 영업 인텔리전스
1연락처 + 회사 + 역할2+ 이전 이메일 + 회사 문제 + 제품3↓4지식 그래프5↓6누가 의사 결정에 영향력을 행사하는지7어떤 반대 의견이 반복되는지8이 특정 고객에게 보여줄 사례 연구는 무엇인지9딜이 막힌 지점은 어디인지
3 - 엔지니어링 인텔리전스
1GitHub 커밋 + Jira 티켓 + Linear 작업2↓3엔지니어링 작업 그래프4↓55배 빠른 인시던트 탐지650% 적은 회의 시간7자동 릴리스 노트
LaunchNotes는 이미 이 제품을 판매하고 있습니다. 시장은 둘 이상의 프로젝트 관리 도구를 사용하는 모든 엔지니어링 팀입니다.
4 - 연구 인텔리전스
1논문 + 저자 + 기관2+ 방법 + 데이터셋 + 결과 + 모순3↓4지식 그래프5↓6어떤 GraphRAG 방법이 커뮤니티 탐지를 사용하는지7어떤 데이터셋에서 테스트되었는지8어떤 논문이 서로 모순되는지
5 - 개인 지식 OS
1Obsidian 노트 + 이메일 + 캘린더2+ PDF + 연락처 + 작업3↓4개인 지식 그래프5↓6이 아이디어를 누구와 논의했는지7어떤 작업이 한 사람의 응답에 달려있는지8어떤 결정이 이전 합의와 모순되는지9이번 달에 무엇을 하기로 약속했는지
Microsoft, Stanford, Anthropic을 연결하는 변화
1프롬프트 엔지니어링 | 올바른 질문을 하는 방법2RAG | 어떤 문서를 찾을지3Graph Engineering | 어떤 엔터티가 존재하는지4 | 그것들이 어떻게 연결되는지5 | 어떤 경로가 답으로 이어지는지6 | 하나의 노드가 변경되면 무엇이 바뀌는지
LLM은 단어를 알고 있습니다. 지식 그래프는 관계를 알고 있습니다. 가장 강력한 AI 시스템은 둘이 함께 작동할 때 나타납니다.
Microsoft는 GraphRAG로 프로덕션에서 이를 입증했습니다 - 18% 더 나은 정확도, 85% 더 낮은 비용. Stanford는 DSPy, STORM 및 확장 법칙 논문을 통해 연구에서 입증했습니다. Anthropic은 LaunchNotes 사례에서 입증했습니다 - 5배 빠른 인시던트 탐지, 50% 적은 회의 시간.
세 조직. 세 개의 독립적인 경로. 하나의 결론.
모델은 텍스트를 찾습니다. 그래프는 현실을 찾습니다. 그래프를 구축하세요.
대부분의 개발자는 계속해서 프롬프트를 개선하고 복잡한 질문에 여전히 나쁜 답변이 나오는 이유를 궁금해할 것입니다. 소수는 주말을 투자하여 첫 번째 지식 그래프를 구축하고 다시는 문서 검색으로 돌아가지 않을 것입니다.
/ 이 글이 유용했다면 팔로우해 주세요. 다음 글은 여기서 가장 먼저 공개됩니다.
