GraphRAG (그래프RAG)

검색·RAG

GraphRAG (그래프RAG)

chunk 사이의 관계를 그래프로 만들어 검색 결과를 '연결된 덩어리' 로 돌려주는 retrieval 구조층.

1줄 정의

chunk 사이의 관계 (엔티티·참조·계층) 를 그래프로 만들어, 검색 결과를 ‘연결된 덩어리’ 로 돌려주는 retrieval 의 구조층.

전체 시스템에서 맡는 역할

retrieval 을 이해하려 할 때 가장 먼저 나오는 건 대개 embedding 기반의 chunk 검색이다. 문서를 잘게 잘라 질문과 가까운 벡터의 chunk 를 끌어오는 방식. 구조가 단순하고 작동도 하고, 입문용으로는 괜찮다.

다만 이 방식에는 금방 드러나는 한계가 있다. chunk 끼리의 관계가 사라진다는 것. 같은 문서 안에서 바로 옆에 있던 두 chunk 가 벡터 공간에서는 따로 다뤄진다. A 는 B 의 자식 프로세스 같은 구조도, 이 절은 앞 절의 반박 같은 논리 관계도, chunk 로 자르는 순간 날아간다.

GraphRAG 의 역할은 여기서 시작된다.

chunk 의 집합에 그래프 구조를 얹고, 검색할 때는 “가까운 벡터” 뿐만 아니라 “연결된 노드” 도 같이 꺼내는 것 — 이게 GraphRAG 가 하는 일이다. 엔티티 추출, 참조 관계, 계층 구조, community detection 같은 전처리를 돌려 chunk 에 그래프 맥락을 심는다.

RAG 4층 지도에서 보면 GraphRAG 는 구조 검색층 (2층). embedding (1층) 위에 올라앉아 “일치” 뿐 아니라 “접속” 까지 다룰 수 있게 만드는 층이다.

이 층이 빠지면 어떻게 되는지 말하면, 모델은 “단발로 맞는 조각” 은 꺼낼 수 있어도 “그 조각과 이웃한 맥락” 은 못 꺼낸다. 결과적으로 같은 문서 안의 단서들을 엮는 유형의 질문에 약해진다.

흔한 오해

GraphRAG 는 이름의 임팩트가 커서 오해되기 쉬운 용어이기도 하다.

  • 오해 1: GraphRAG 는 벡터 DB 의 대체재다, 라고 받아들여지기 쉽다.

– 실제로는 GraphRAG 가 embedding 기반 검색을 대체하는 기술이 아니라, 그 위에 그래프 구조를 더하는 기술이다. 엔티티나 레퍼런스를 그래프화하려 해도 결국 노드 간 유사도는 많은 구현에서 embedding 을 쓴다. 벡터 DB 는 아래층으로 남는다.

  • 오해 2: GraphRAG 로 바꾸면 retrieval 품질이 자동으로 오른다, 라고 여겨지기 쉽다.

– 실제로는 그래프 구축 전처리의 품질 (엔티티 추출 정확도, 링크 걸기, community 입자 크기) 이 결과를 크게 좌우한다. 대충 만들면 노이즈만 더해진 retrieval 로 끝날 수 있다.

  • 오해 3: GraphRAG 는 knowledge graph 랑 거의 같다, 라고 묶여서 이야기되기 쉽다.

– 실제로는 전통적인 knowledge graph (Wikidata 처럼 사람이 정리한 관계 그래프) 와 GraphRAG 가 동적으로 쌓는 그래프는 성격이 다르다. 전자는 세계 지식의 정리, 후자는 특정 코퍼스에서의 관계 추출. 섞어서 설계하면 양쪽 장점 다 안 나온다.

이 용어가 중요한 이유

새 retrieval 계열 제품이나 논문이 “GraphRAG” 를 내걸고 나왔을 때, 그게 내 유스케이스에 도움이 되는지 안 되는지 를 판단할 수 있게 된다 — 이게 이 용어를 아는 실무적 가치다.

구체적으로 이런 질문에 스스로 답할 수 있게 된다.

  • 내 코퍼스가 “관계를 건질” 가치가 있는가 (예: API 레퍼런스처럼 함수들 간의 호출 관계가 있는 문서 vs 독립된 FAQ처럼 관계가 옅은 문서)
  • 그래프 구축 비용을 낼 가치가 있는가 (엔티티 추출이나 전처리는 꽤 있는 계산 부하)
  • 단발 검색으로 충분한가, 접속 검색까지 필요한가

이 판단 축이 없으면 “GraphRAG 유행이니 써 보자” 로 도입해서 비용 증가 대비 해당 쿼리가 없는 상황에 빠지기 쉽다. 반대로 관계성이 본질인 코퍼스 (기술 문서, 법률 문서, 의료 기록 등) 에서는 GraphRAG 를 아느냐 모르느냐에 따라 설계의 예리함이 크게 달라진다.

이 용어가 나오는 기사

다음에 읽을 용어 3개

  • embedding — GraphRAG 의 아래층. 노드 유사도의 상당 부분은 여기에 의존한다.
  • agentic retrieval — 같은 retrieval layer 의 workflow 쪽. GraphRAG 가 도구로 감싸져 호출되는 구도도 있다.
  • RAG — GraphRAG 가 속한 상위 틀.
最終更新: 2026-04-18 · shuntailor.net テイラー百科事典

GraphRAG

検索・RAG

GraphRAG

chunk 間の関係（エンティティ・参照・階層）をグラフ化し、検索結果を「繋がったかたまり」で返す retrieval の構造層。

一行定義

chunk 間の関係（エンティティ・参照・階層）をグラフ化し、検索結果を「繋がったかたまり」で返す retrieval の構造層。

全体システムの中での役割

retrieval を理解するとき、最初に出てくるのはたいてい embedding ベースの chunk 検索だ。ドキュメントを細かく切って、質問に近いベクトルの chunk を引っ張る。仕組みはシンプルで、動くし、入門としては良い。

ただこの方法には、すぐ出る限界がある。chunk 同士の関係が失われるのだ。同じ文書の中で隣り合っていた 2 つの chunk が、ベクトル空間では別々に扱われる。A は B の子プロセス のような構造も、この節は前節の反論 のような論理関係も、chunk に切った瞬間に消える。

GraphRAG の役割はここから始まる。

chunk の集合にグラフ構造を足し、検索時には「近いベクトル」だけでなく「繋がっているノード」も一緒に取り出す ── これが GraphRAG がやっていることだ。エンティティ抽出、参照関係、階層構造、community detection などを前処理で走らせて、chunk に grapha 的な文脈を持たせる。

RAG の 4 層マップで言えば、GraphRAG は 構造検索層 (2 層)。embedding (1 層) の上に乗って、「一致」だけでなく「接続」を扱えるようにする層だ。

この層が欠けるとどうなるかを言えば、モデルは「単発の正しい断片」は取れるが、「その断片と隣接する文脈」を取れない。結果として、同じドキュメント内の手掛かりを結び付けるタイプの質問に弱くなる。

よくある誤解

GraphRAG は名前のインパクトが強く、誤解されやすい用語でもある。

  • 誤解 1：GraphRAG はベクトル DB の代替だ、と受け取られがち。

– 実際には、GraphRAG は embedding ベース検索を置き換える技術ではなく、その上にグラフ構造を追加する技術だ。エンティティやリファレンスをグラフ化するにも、結局ノード間の類似度は多くの実装で embedding を使う。ベクトル DB は下層として残る。

  • 誤解 2：GraphRAG にすれば retrieval 品質が自動で上がる、と思われがち。

– 実際には、グラフ構築の前処理品質（エンティティ抽出の精度、リンクの張り方、community の粒度）が結果を大きく左右する。雑に組むと、むしろノイズだけ増えた retrieval になりかねない。

  • 誤解 3：GraphRAG は knowledge graph とほぼ同じだ、と一緒に語られがち。

– 実際には、伝統的な knowledge graph （Wikidata のような、人手で整備された関係グラフ）と、GraphRAG の動的に構築されるグラフは性格が違う。前者は世界知識の整理、後者は特定コーパスからの関係抽出。混ぜて設計すると、どちらの強みも出ない。

この用語が重要な理由

新しい retrieval 系プロダクトや論文が「GraphRAG」を名乗って出てきた時に、それが自分のユースケースを助けるかどうか を判断できるようになる、というのがこの語を知る実務的価値だ。

具体的には、次のような質問に自分で答えられるようになる。

  • 手元のコーパスは「関係を拾う」価値があるか（例：API リファレンスのように関数同士の呼び出し関係がある文書 vs 独立した FAQ のように関係の薄い文書）
  • グラフ構築コストを払う価値があるか（エンティティ抽出や前処理は decent の計算負荷がある）
  • 単発検索で十分か、接続検索まで必要か

この判断軸がないと、「GraphRAG が流行っているから使おう」で導入して、コスト増に見合うだけのクエリが存在しない ケースに陥りやすい。逆に、関係性が本質のコーパス（技術文書、法律文書、医療記録など）では、GraphRAG を知っているかどうかで設計の切れ味が大きく変わる。

この用語が登場する記事

次に読むべき用語 3 つ

  • embedding — GraphRAG の下層。ノード類似度の多くはここに依存する。
  • agentic retrieval — 同じ retrieval layer の workflow 側。GraphRAG がツール化されて呼び出される構図もある。
  • RAG — GraphRAG が属する上位枠組み。

実際の挙動イメージ

GraphRAG が動いている前処理 → 検索の一連を、一段だけ具体化する。

  • 前処理：コーパスを chunk 化 → 各 chunk からエンティティ抽出（人物・組織・概念など）→ chunk を「エンティティを含むノード」として結線 → 大きなクラスタが見える場合は community としてまとめる
  • 検索時：ユーザーの質問から embedding で近い chunk を引く → 引いた chunk が属するグラフ近傍（関連エンティティ、同じ community、参照元 chunk）も一緒に取り出す
  • 組み立て：近傍 chunk を添えてモデルに渡す。モデルは「一点の答え」だけでなく「その答えを支える隣接情報」を見た上で回答する

重要なのは、検索が「点」ではなく「繋がった近傍」を返す こと。これにより、単発 chunk を貼る従来型 RAG では答えづらかった、関係性を問う質問に強くなる。

設計上のトレードオフ

GraphRAG はフリーランチではない。

  • 前処理コスト：エンティティ抽出や community 検出は LLM を使うことも多く、コーパスサイズに対して計算コストが線形以上に増える。大規模コーパスでは初期コストがかなり効く。
  • 鮮度管理：コーパスが更新されるたびに、グラフ再構築が必要。差分更新の設計が甘いと、運用が重くなる。
  • 抽出品質への依存：自動抽出されたエンティティ・リンクに誤りが多いと、グラフ検索が「もっともらしい誤接続」を強化する方向に働いてしまう。
  • 評価の難しさ：単発 retrieval の精度と違って、「近傍の質」をどう評価するかは自明でない。

これらは「使わない理由」ではなく、「使う前に見積もるべきコスト」だ。特に前処理コストは、導入初期の判断を左右する。

最終更新: 2026-04-18 · shuntailor.net テイラー百科事典
JAKO