[AI·소프트웨어] GraphRAG 특허는 검색을 바꾸는 연산에서 갈립니다

핵심 요약

GraphRAG는 문서군을 요약하고, 그래프를 따라 추가 근거를 검색하며, 대화에서 누락된 관계를 갱신합니다. 세 방식은 처리 시점과 청구항의 필수 연산이 서로 다릅니다.

기업이 수천 건의 기술문서·시험보고서·고객 요청사항을 AI로 검색한다고 가정해 보겠습니다. “부품 A의 허용 온도는 몇 도인가”처럼 특정 문서를 찾는 질문과 “최근 품질문제의 공통 원인은 무엇인가”처럼 여러 문서에 흩어진 정보를 종합하는 질문은 서로 다른 검색문제입니다. 이전 답변에서 빠진 부품–고장원인 관계를 다음 질문에서 보완하는 일은 또 다른 문제입니다.

이처럼 서로 다른 문제를 해결하는 기술이 모두 GraphRAG라는 이름 아래 묶이기 쉽습니다. 그러나 문서군을 요약하기 위한 커뮤니티 그래프, 찾은 문서에서 이웃 문서로 검색 범위를 넓히는 그래프, 실제 대화에 따라 관계를 바꾸는 지식그래프는 데이터 구조와 청구할 연산이 다릅니다. GraphRAG의 기술적 차이를 보려면 먼저 그래프가 어느 단계에 놓이는지 확인해야 합니다.

1. 그래프를 사용한다는 표현만으로 기술이 같아지지는 않습니다

지식그래프(Knowledge Graph)는 기업·장치·기술·사건처럼 의미 있는 객체를 노드로, 이들 사이의 관계를 에지(edge)로 표현합니다. 반면 HNSW처럼 벡터 간 근접 연결을 만들어 빠른 근사 최근접 이웃(ANN) 검색을 수행하는 그래프는 주된 목적이 검색 인덱스의 효율화입니다. 노드와 선을 그린 도면이라는 공통점만으로 동일한 청구구성이 되지는 않습니다.

특허분석에서는 그래프의 이름보다 노드가 의미하는 데이터, 에지의 생성기준, 질의가 그래프를 이용하는 시점, 선택 결과가 LLM 응답으로 전달되는 방식을 요소별로 대조해야 합니다.

2. Microsoft GraphRAG: 커뮤니티별 요약으로 문서 전체를 읽습니다

Microsoft Research가 2024년 발표한 From Local to Global: A Graph RAG Approach to Query-Focused Summarization은 전통적인 RAG가 문서 전체에 대한 ‘전반적 질문(global question)’에 약하다는 문제에서 출발했습니다. 일반적인 벡터 검색에서 질문과 비슷한 몇 개의 청크만 가져오면 문서군 전체에 반복되는 주제를 놓칠 수 있기 때문입니다.

Microsoft GraphRAG 공식 기술문서에서는 원문 TextUnits에서 객체와 관계를 추출하고, Leiden 커뮤니티 계층을 구성하며, 각 커뮤니티의 내용을 요약보고서로 정리합니다. 전체 주제를 묻는 Global Search는 여러 커뮤니티 보고서로부터 부분 답변을 만들고 이를 다시 통합하는 방식으로 동작합니다.

이 그림에서 중요한 부분은 색깔이 예쁘게 분리된다는 사실이 아닙니다. 서로 관련된 여러 객체를 하나의 커뮤니티로 묶고 그 전체 내용을 요약할 수 있다는 점입니다. 예를 들어 1,000건의 장비 품질보고서 중 일부는 냉각, 일부는 정렬, 일부는 소재 오염을 설명하더라도 커뮤니티 보고서를 활용하면 “전반적인 반복 원인”을 서로 다른 문서군에 걸쳐 정리할 수 있습니다.

Microsoft의 공식 Query Engine 문서는 이러한 검색 유형을 각각 구분합니다. Global Search는 커뮤니티 요약 생성·집계 비용이 추가될 수 있으므로 단순히 “GraphRAG가 일반 RAG보다 언제나 빠르다”는 식으로 평가할 수 없습니다. 무엇보다 이 연구의 모든 구현요소가 다음 미국 두 공개출원의 청구항 필수구성이라는 의미는 아닙니다.

3. 미국 공개출원 첫 번째: 시드 청크에서 연관 문서로 확산합니다

2026년 9월 24일 공개된 US20260289337A1 — Diffusion Based Retrieval Augmented Generation의 시스템 독립 제1항은 다음 처리관계를 청구합니다. 질문을 받고 문서를 청크로 나누어 지식그래프를 구성한 뒤, 질문에 일치하는 최초 청크(seed)를 선택하고, 그 지점에서 그래프 확산(diffusion)을 이용해 추가 청크를 선택하여 LLM의 답변에 사용합니다.

명세서의 FIG. 4A~4D는 확산에 따라 노드의 ‘열(heat)’이 옮겨가는 개념을 활용합니다. 이는 실제 온도의 전달을 측정한다는 뜻이 아니라, 그래프 연결과 확산 시간에 따라 어떤 문서 노드가 다음 후보가 되는지 수치적으로 표현하는 방식입니다. 특정 노드를 추가한 뒤 다시 확산을 시작하는 처리에서는 선택되는 후보가 달라질 수도 있습니다.

공개 제1항에 필요한 것과 종속항에서 추가하는 것

특히 문서 청크 연결 그래프와 객체(entity)·관계(triplet) 그래프는 실시형태가 다를 수 있습니다. 독립 제1항이 모든 구현에서 객체 삼중항을 반드시 만들어야 한다고 해석하면 종속 제9항 등의 의미를 놓치게 됩니다.

4. 그래프 확산의 계산은 ‘어떤 청크가 다음 후보인가’를 결정합니다

그래프의 노드 A가 최초 검색된 문서이고, B와 C가 A에 연결되어 있다고 가정하겠습니다. A에서 B로 향하는 정규화된 연결가중치가 0.8, C로 향하는 값이 0.2라면, 간단한 1회 이산 전파 예시에서 다음 선택점수를 계산할 수 있습니다.

이 예제에서 추가 검색의 후보를 한 개만 선택한다면 B가 우선됩니다. 하지만 이 계산이 그대로 공개 제7항의 Laplacian heat diffusion 수식이라는 의미는 아닙니다. 해당 종속항은 그래프 라플라시안과 초기 heat vector 등 더 구체적인 확산 연산을 추가로 규정합니다.

실무에서는 이 가중치가 임베딩 유사도인지, 실제 의미관계의 강도인지, 문서의 계층·최신성과 연결된 값인지 먼저 정의해야 합니다. 확산 경로가 잘못된 관계를 따라가면 오히려 무관한 근거가 추가될 수 있으므로, 검색 확장의 효과와 잘못된 근거 유입률을 함께 측정해야 합니다.

5. 미국 공개출원 두 번째: 사용자의 대화를 읽고 지식그래프 자체를 갱신합니다

2026년 7월 2일 공개된 US20260187105A1 — Dynamic Graph Augmentation for Improved Contextual Retrieval은 검색 범위를 넓히는 방식이 아니라 기존 지식그래프의 누락된 정보나 연결관계를 찾아 갱신하는 방식입니다.

공개 독립 제1항은 사용자 질문, 그때 검색된 KG 정보, LLM의 답변이 포함된 대화이력(chat history)을 얻습니다. 이어 KG와 graph schema를 함께 분석하는 KG-update MLM agent가 누락된 지식이나 노드 사이의 누락 관계를 찾아내고, 이를 그래프에 반영합니다.

가령 사용자가 기술문서를 조회한 뒤 “부품 A의 고장 원인은 열팽창이 아니라 체결력 부족이었습니다”라고 정정했다고 가정해 보겠습니다. 시스템이 이 피드백을 기존 지식그래프의 노드·관계와 대조해 현재 정보와 다른 관계를 발견한 뒤 수정 후보를 만드는 작업이 이에 가깝습니다. 하지만 사용자 발언만으로 사실이 확인되지는 않으므로 실제 제품에서는 원자료 검증·권한·변경 이력을 추가 설계할 필요가 있습니다.

독립 제1항과 선택적인 갱신 판단을 구분합니다

반복질문으로 만족도를 추정하거나 새로운 에지의 확률행렬을 만든다는 상세한 방식은 일부 종속항에서 구체화됩니다. 사용자의 감정분석이나 모든 확률행렬 연산을 독립 제1항의 필수구성으로 읽지 않는 것이 중요합니다.

6. 같은 GraphRAG라도 하나의 청구항 차트로 합칠 수는 없습니다

동일한 제품에 이러한 기능이 모두 포함될 수도 있습니다. 그러나 출원인·발명자·최초공개 시점·독립항은 별도로 확인해야 합니다. 특히 미국 공개출원 A1은 등록 B1/B2의 확정된 권리범위와 동일하지 않습니다. 경쟁특허 조사에서는 2026년 공개된 두 발명이 실제로 어느 국가에서 어떤 청구항으로 심사·등록되는지 확인해야 합니다.

7. GraphRAG IP-R&D의 성과는 그래프 크기가 아니라 검색의 변화를 증명하는 데 있습니다

그래프의 노드가 수십만 개라는 사실만으로 제품이 더 정확하게 작동하거나 특허성이 생기는 것은 아닙니다. 검색기술별로 성능을 바꾼 원인과 그 효과를 검증하는 지표가 달라져야 합니다.

예를 들어 문서검색 정확도가 낮아졌을 때 그래프 연결이 부족한 것인지, 커뮤니티 요약이 중요한 정보를 놓친 것인지, 오래된 관계가 갱신되지 않은 것인지를 구별해야 합니다. 원인이 다르면 재설계할 시스템 모듈과 청구할 기술구성도 달라집니다.

INTLAW가 기술 인터뷰에서 확인해야 할 질문도 여기서 출발합니다. “그래프를 만들었습니까?”가 아니라 “그래프의 어느 데이터와 판단 규칙을 바꾸어, 어떤 근거가 검색되거나 갱신되도록 했습니까?”입니다. 이 질문에 답하는 구현로그와 비교실험이 있어야 후속 특허출원·경쟁기술 대응·사업화를 같은 방향으로 설계할 수 있습니다.

마치며 — 그래프의 연결이 아니라 ‘판단이 바뀌는 순간’을 보호해야 합니다

GraphRAG는 기업 내부문서에 더 많은 선을 그리는 기술이 아닙니다. 전체 문서의 관계를 요약하거나, 한 문서에서 다른 근거로 확장하거나, 사용자의 질문을 통해 누락된 관계를 수정하는 서로 다른 처리결정을 구현하는 기술입니다.

커뮤니티 보고서를 만드는 시점, 확산검색을 멈추는 조건, 대화 이력으로 그래프를 수정하는 기준을 실제 코드·데이터·시험으로 분리해 기록해야 합니다. 그때 GraphRAG는 단순한 유행어가 아니라 구체적인 제품 경쟁력과 특허 포트폴리오로 설명될 수 있습니다.