跳轉到

自訂 GraphRAG 管線：自帶圖譜邁向生產環境

文章資訊

作者：QuarkAndCode　　日期：2026-06-21

原文標題：Custom GraphRAG Pipelines: Bring Your Own Graph for Production

Medium 原連結：https://medium.com/@QuarkAndCode/custom-graphrag-pipelines-bring-your-own-graph-for-production-bb0d6b38ef07

🎧 摘要語音

📝 重點摘要

TL;DR

GraphRAG 的價值在社群層與檢索路由，而非節點邊本身。

核心問題

純向量 RAG 擅長找相似段落，但面對跨文件推理或全語料庫摘要時力有未逮。文章探討如何在既有圖譜上以微軟 GraphRAG 加蓋摘要與檢索層（即「自帶圖譜 BYOG」），並依問題類型路由不同檢索法，使系統真正可上線。

關鍵發現 / 數據

  • 微軟原始 From Local to Global 論文指出此法在大型私有語料的全域感知問題上，答案的「全面性」與「多樣性」優於傳統 RAG。
  • BYOG 最小輸入為 entities.parquet 與 relationships.parquet；text_units.parquet 為選用，僅在需 Local / DRIFT / Basic Search 時必要。
  • relationships 的 weight 欄位非裝飾用，會用於正確計算 Leiden 社群。
  • 在微軟 AP News benchmark 中，DRIFT Search 在「全面性」勝過 Local Search 達 78%、「多樣性」達 81%（但僅限該 benchmark）。
  • 階層較低層級答案更完整，但處理報告數增加，時間與 LLM 成本上升。

方法亮點

  • 以階層式 Leiden 社群偵測，由下而上生成社群報告，建立多層抽象，使系統能回答「語料庫主要主題/風險」而非僅「實體 X 連到誰」。
  • 查詢路由：實體問題走 Local、跨文件/抽象問題走 Global（map-reduce）、模糊問題走 DRIFT 或混合。
  • 自訂檢索器（Neo4j VectorCypherRetriever、LlamaIndex 結合向量 + Text-to-Cypher 再 rerank）兼顧語意相似、圖樣式比對與 schema 感知。
  • 優化階層（動態社群選擇、剪除無關分支）優先於優化模型。

對我的研究有用嗎？

有參考價值。「社群層 / 階層摘要才是 GraphRAG 核心優勢」與「不同檢索模式對應不同問題類別、需路由」兩個觀念，對 GraphRAG 系統設計與評估很實用。BYOG 的表格契約（entities/relationships 欄位、保留自然語言描述與 provenance 連結）提醒：圖譜對機器精準但對 LLM 不透明時檢索品質會下降——這對知識圖譜建模值得借鏡。動態社群剪枝亦是降本方向。

評語

實務導向、引用紮實的整理型文章，無原創實驗；適合當 GraphRAG 生產化的入門地圖，但數據多轉述自微軟文件，深度有限，值得略讀而非精讀。

🌐 中英對照

Author: QuarkAndCode
Published:
Source: https://medium.com/@QuarkAndCode/custom-graphrag-pipelines-bring-your-own-graph-for-production-bb0d6b38ef07
Fetched: 2026-06-21T11:05:18.526050

Custom GraphRAG Pipelines: Bring Your Own Graph for Production / 自訂 GraphRAG 管線：在生產環境中帶入你自己的圖譜

Press enter or click to view image in full size

按下 Enter 或點擊以檢視完整大小的圖片

Custom GraphRAG pipelines matter because plain vector RAG is good at surfacing similar passages, but it often struggles when a question requires cross-document reasoning or a whole-corpus summary. Microsoft’s GraphRAG takes a different path: it chunks documents into TextUnits, extracts entities and relationships, optionally extracts claims, clusters the graph into communities, generates community reports, and then uses those graph artifacts at query time.

自訂的 GraphRAG 管線 (pipeline) 之所以重要，是因為單純的向量 RAG (vector RAG) 擅長找出相似的段落，但當問題需要跨文件推理 (cross-document reasoning) 或對整個語料庫 (corpus) 進行摘要時，它往往力有未逮。微軟的 GraphRAG 採取了一條不同的路徑：它將文件切分成文字單元 (TextUnits)，抽取實體 (entities) 與關係 (relationships)，並可選擇性地抽取主張 (claims)，將圖譜分群成社群 (communities)，產生社群報告 (community reports)，然後在查詢時運用這些圖譜產物。

In the original From Local to Global paper, Microsoft researchers reported that this approach improved the comprehensiveness and diversity of answers over a conventional RAG baseline on global sensemaking questions across large private corpora.

在最初的 From Local to Global 論文中，微軟的研究人員指出，在橫跨大型私有語料庫的全域意義建構 (global sensemaking) 問題上，這種方法相較於傳統的 RAG 基準，提升了答案的全面性 (comprehensiveness) 與多樣性 (diversity)。

It’s also important to know that GraphRAG is not a single fixed method. Recent surveys describe it as a broad design space that includes graph-based indexing, graph-guided retrieval, and graph-enhanced generation. Another survey explains that a full GraphRAG system combines a query processor, retriever, organizer, generator, and data source.

同樣重要的是要明白，GraphRAG 並不是一種固定不變的方法。近期的綜述 (surveys) 將它描述為一個廣闊的設計空間，涵蓋基於圖譜的索引 (graph-based indexing)、圖譜引導的檢索 (graph-guided retrieval)，以及圖譜增強的生成 (graph-enhanced generation)。另一篇綜述則說明，一套完整的 GraphRAG 系統結合了查詢處理器 (query processor)、檢索器 (retriever)、組織器 (organizer)、生成器 (generator) 與資料來源 (data source)。

The field has grown quickly, with formal surveys now available on arXiv and in the ACM Digital Library. Neo4j’s GraphRAG pattern catalog highlights the same idea for practitioners: different graph patterns and retrievers work best for different types of questions, so production systems should be tested and adjusted instead of sticking to one approach.

這個領域發展迅速，如今在 arXiv 與 ACM 數位圖書館 (ACM Digital Library) 上都已有正式的綜述。Neo4j 的 GraphRAG 模式目錄 (pattern catalog) 對實務工作者強調了同樣的觀念：不同的圖譜模式 (graph patterns) 與檢索器各自適合不同類型的問題，因此生產系統應該經過測試與調整，而不是死守單一種做法。

What “Bring Your Own Graph” Really Means / 「帶入你自己的圖譜」真正的意涵

In a production setting, “bring your own graph” does not mean abandoning GraphRAG. It means you start from an existing graph or graph export and let GraphRAG build the summarization and retrieval layer on top of it.

在生產環境中，「帶入你自己的圖譜」(bring your own graph，BYOG) 並不代表放棄 GraphRAG。它的意思是，你從一個既有的圖譜或圖譜匯出檔出發，讓 GraphRAG 在其之上建構摘要層與檢索層。

Microsoft’s official BYOG workflow says the minimum input is usually entities.parquet and relationships.parquet, while text_units.parquet is optional unless you want Local Search, DRIFT Search, or Basic Search. For summarization, entities need fields such as id, title, description, and text_unit_ids; relationships need fields such as id, source, target, description, weight, and text_unit_ids. That weight field is not cosmetic: Microsoft notes that it is used to compute Leiden communities correctly. This tabular contract also aligns with standard data engineering practices, since GraphRAG stores outputs as Parquet tables by default and writes embeddings to a configured vector store.

微軟官方的 BYOG 工作流程指出，最少的輸入通常是 entities.parquet 與 relationships.parquet，而 text_units.parquet 則是選用的，除非你想使用區域搜尋 (Local Search)、DRIFT 搜尋 (DRIFT Search) 或基本搜尋 (Basic Search)。就摘要而言，實體需要 id、title、description 與 text_unit_ids 等欄位；關係則需要 id、source、target、description、weight 與 text_unit_ids 等欄位。其中的 weight 欄位並非裝飾性的：微軟指出它被用來正確地計算 Leiden 社群 (Leiden communities)。這份表格化的契約也符合標準的資料工程實務，因為 GraphRAG 預設會將輸出儲存為 Parquet 表格，並將嵌入向量 (embeddings) 寫入所設定的向量儲存庫 (vector store)。

That detail matters because GraphRAG’s real power comes from the community layer, not from the bare existence of nodes and edges. In Microsoft’s minimal BYOG configuration, a custom graph can be turned into a GraphRAG query asset by running only create_communities and create_community_reports, which is enough for Global Search. If you also want Local or DRIFT, you need text units and embeddings. If your graph lacks rich node and edge descriptions, Microsoft also documents a text-based community-report option that relies on linked text_unit_ids instead.

這個細節之所以重要，是因為 GraphRAG 真正的威力來自社群層 (community layer)，而不是僅僅存在節點 (nodes) 與邊 (edges)。在微軟最精簡的 BYOG 設定中，只要執行 create_communities 與 create_community_reports，就能將自訂圖譜轉化為 GraphRAG 的查詢資產，這對全域搜尋 (Global Search) 而言就已足夠。如果你還想使用 Local 或 DRIFT，就需要文字單元與嵌入向量。如果你的圖譜缺乏豐富的節點與邊描述，微軟也記載了一個基於文字的社群報告選項，改為依賴所連結的 text_unit_ids。

The Architecture of a Custom GraphRAG Pipeline / 自訂 GraphRAG 管線的架構

A strong custom GraphRAG pipeline starts with graph modeling for retrieval, not just storage. Microsoft’s dataflow treats TextUnits as the atomic analysis units and uses them as breadcrumbs back to the original source text.

一套強大的自訂 GraphRAG 管線，起點是為了檢索而進行的圖譜建模，而不只是為了儲存。微軟的資料流 (dataflow) 將文字單元視為最小的分析單位，並用它們作為回溯到原始來源文字的麵包屑 (breadcrumbs)。

Entities and relationships are extracted or imported; claims are optional covariates; and all of these feed into later retrieval steps. That means a production BYOG graph should preserve natural-language descriptions and provenance links, not only normalized IDs and topology. If a node or edge is precise for machines but opaque to an LLM, retrieval quality usually suffers.

實體與關係是被抽取或匯入的；主張則是選用的共變量 (covariates)；而這些全都會餵入後續的檢索步驟。這意味著一個生產級的 BYOG 圖譜應該保留自然語言的描述與來源溯源 (provenance) 連結，而不只是正規化的 ID 與拓撲結構。如果一個節點或邊對機器而言很精確，但對大型語言模型 (LLM) 來說卻晦澀難懂，檢索品質通常就會受損。

The next layer is community construction. In GraphRAG’s default pipeline, Microsoft applies hierarchical Leiden community detection, then generates community reports and shorter summaries from the bottom up. This turns a graph into multiple abstraction levels, which is why GraphRAG can answer “What are the major themes, risks, or patterns in this corpus?” rather than only “What does entity X connect to?”

下一層是社群建構。在 GraphRAG 的預設管線中，微軟採用階層式 Leiden 社群偵測 (hierarchical Leiden community detection)，然後由下而上產生社群報告與較短的摘要。這把一個圖譜轉化為多個抽象層級，這也正是為什麼 GraphRAG 能回答「這個語料庫中的主要主題、風險或模式是什麼？」，而不只是「實體 X 連接到了什麼？」。

Global Search then uses those community reports in a map-reduce flow. Microsoft’s docs note that lower levels of the hierarchy often produce more thorough answers, but they also increase time and LLM cost because more reports must be processed.

全域搜尋接著在一個 map-reduce 流程中運用這些社群報告。微軟的文件指出，階層中較低的層級往往能產生更周詳的答案，但也會增加時間與 LLM 成本，因為必須處理更多的報告。

For production use, routing queries is just as important as building the graph. Microsoft describes Local Search as an entity-based method that starts with entities related to the query, gathers the connected text units, relationships, community reports, and any extra data, then filters everything into one context window. Global Search works differently by searching community reports to answer broad or abstract questions.

就生產用途而言，為查詢進行路由 (routing) 與建構圖譜同等重要。微軟將區域搜尋描述為一種基於實體的方法，它從與查詢相關的實體出發，蒐集相連的文字單元、關係、社群報告以及任何額外資料，然後把所有內容過濾進單一的脈絡視窗 (context window)。全域搜尋的運作方式則不同，它透過搜尋社群報告來回答廣泛或抽象的問題。

DRIFT Search is in between, using community information to create follow-up questions and then refining answers with more focused retrieval. In Microsoft’s AP News benchmark, DRIFT did better than Local Search 78% of the time for thoroughness and 81% for diversity, but these results are specific to that benchmark and not a universal rule.

DRIFT 搜尋則介於兩者之間，它運用社群資訊來產生後續追問，然後再以更聚焦的檢索來精煉答案。在微軟的 AP News 基準測試中，DRIFT 在周詳度上有 78% 的情況優於區域搜尋，在多樣性上則有 81%，但這些結果僅針對該基準測試而言，並非放諸四海皆準的規則。

Many teams make the mistake of asking whether GraphRAG ‘works,’ when the real question should be which retrieval method fits each type of question. The official Neo4j pattern catalog clearly states that each pattern is designed for specific question types and should be tested. This means having a production router is almost required.

許多團隊會犯一個錯誤，去問 GraphRAG「行不行得通」，然而真正該問的問題應該是：哪一種檢索方法適合哪一類型的問題。Neo4j 官方的模式目錄清楚說明，每一種模式都是為特定問題類型而設計，且應該經過測試。這意味著擁有一個生產級的路由器幾乎是必要的。

Questions about specific entities should usually go to Local Search or a graph neighborhood retriever. For questions that need information from multiple documents, use Global Search. For unclear or partly defined questions, DRIFT or a hybrid approach often works better.

關於特定實體的問題通常應該交給區域搜尋或圖譜鄰域檢索器 (graph neighborhood retriever)。對於需要從多份文件取得資訊的問題，則使用全域搜尋。對於不明確或只部分定義的問題，DRIFT 或混合式 (hybrid) 做法往往效果更好。

Custom Retrieval Is Where Production Quality Is Won / 自訂檢索正是贏得生產品質的關鍵所在

Bring-your-own-graph systems become truly valuable when you also bring your own retrieval logic. Neo4j’s GraphRAG package is built around that idea: its docs separate the driver, retriever, and LLM, and they explicitly allow developers to write a custom retriever when built-in retrievers do not match application needs. Neo4j also documents a VectorCypherRetriever pattern in which a vector hit is expanded via graph traversals, yielding a final context that includes both raw chunk text and graph relationships, not just nearest-neighbor text matches.

當你同時也帶入自己的檢索邏輯時，帶入你自己的圖譜的系統才會真正展現價值。Neo4j 的 GraphRAG 套件就是圍繞這個理念打造的：其文件將驅動程式 (driver)、檢索器與 LLM 分離開來，並明確允許開發者在內建檢索器無法符合應用需求時撰寫自訂檢索器。Neo4j 也記載了一種 VectorCypherRetriever 模式，其中一次向量命中會透過圖譜走訪 (graph traversals) 進行擴展，產生的最終脈絡同時包含原始的區塊文字 (chunk text) 與圖譜關係，而不只是最近鄰 (nearest-neighbor) 的文字匹配。

LlamaIndex reaches a similar conclusion from a different direction. Its property-graph documentation says several retrieval methods can be combined at once, and its retriever stack includes vector retrieval, LLM synonym retrieval, Text-to-Cypher, Cypher templates, and custom property-graph retrievers.

LlamaIndex 則從不同方向得出了類似的結論。它的屬性圖譜 (property-graph) 文件指出，可以同時結合多種檢索方法，而它的檢索器堆疊包含向量檢索、LLM 同義詞檢索 (LLM synonym retrieval)、文字轉 Cypher (Text-to-Cypher)、Cypher 模板，以及自訂的屬性圖譜檢索器。

In the official custom retriever example, LlamaIndex combines vector search and Text-to-Cypher, then reranks the results. That is a strong pattern for production GraphRAG, because real enterprise queries often combine semantic similarity, graph pattern matching, and schema-aware retrieval in a single request.

在官方的自訂檢索器範例中，LlamaIndex 結合了向量搜尋與文字轉 Cypher，然後對結果進行重新排序 (rerank)。這對生產級的 GraphRAG 而言是一個強大的模式，因為真實的企業查詢往往會在單一請求中結合語意相似度 (semantic similarity)、圖譜模式匹配 (graph pattern matching) 與感知綱要 (schema-aware) 的檢索。

Prompt Tuning, Schema Tuning, And Domain Adaptation / 提示調校、綱要調校與領域適應

Microsoft’s documentation is clear on this: out-of-the-box GraphRAG might not give the best results, and the docs strongly suggest prompt tuning. This is even more important for BYOG systems, since importing a graph does not automatically provide useful descriptions, claims, community reports, or user-friendly language.

微軟的文件對此說得很清楚：開箱即用的 GraphRAG 未必能給出最佳結果，文件強烈建議進行提示調校 (prompt tuning)。對 BYOG 系統而言這甚至更為重要，因為匯入一個圖譜並不會自動提供有用的描述、主張、社群報告或對使用者友善的語言。

Microsoft’s prompt-tuning docs describe auto-tuning as a way to create domain-specific prompts from the input data, and Microsoft Research’s blog says this was designed to avoid the cost of manual prompt engineering for each new domain.

微軟的提示調校文件將自動調校 (auto-tuning) 描述為一種從輸入資料產生領域特定提示的方法，而微軟研究院 (Microsoft Research) 的部落格則指出，這個設計是為了避免每進入一個新領域就得手動進行提示工程 (prompt engineering) 的成本。

The dataflow documentation gives the same advice about claims. Microsoft offers claim extraction as an optional workflow that generates additional data, but it is turned off by default because it usually requires prompt tuning to work well. This is a practical warning for production teams: if your domain needs time-based statements, status, compliance, or evidence tracking, you should treat schema design and prompt design as a single task, not separate ones.

資料流文件對於主張也給出了相同的建議。微軟將主張抽取 (claim extraction) 作為一個會產生額外資料的選用工作流程，但它預設是關閉的，因為它通常需要提示調校才能運作良好。這對生產團隊是一個務實的警示：如果你的領域需要基於時間的陳述、狀態、合規 (compliance) 或證據追蹤，你就應該把綱要 (schema) 設計與提示設計當成同一項任務，而不是分開的兩件事。

A Practical Production Blueprint / 一份務實的生產藍圖

A practical custom GraphRAG pipeline usually follows six steps. First, ensure the graph aligns with business needs by using stable IDs, clear natural-language descriptions, and links back to the source text. Second, create communities and community reports to help with both local and global analysis.

一套務實的自訂 GraphRAG 管線通常遵循六個步驟。第一，透過使用穩定的 ID、清晰的自然語言描述，以及回溯到來源文字的連結，確保圖譜與業務需求一致。第二，建立社群與社群報告，以同時支援區域與全域分析。

Third, route queries by question type rather than using a single retriever for everything. Fourth, mix graph traversal with vector or Cypher-style retrieval when similarity search alone is not enough. Fifth, adjust prompts and extraction templates to fit your domain and users. Sixth, test each retrieval path separately, since both the literature and official pattern catalogs stress that different patterns solve different retrieval problems.

第三，依問題類型來路由查詢，而不是用單一檢索器處理一切。第四，當僅靠相似度搜尋不足時，將圖譜走訪與向量式或 Cypher 式的檢索混合運用。第五，調整提示與抽取模板，使其符合你的領域與使用者。第六，分別測試每一條檢索路徑，因為文獻與官方模式目錄都強調，不同的模式解決不同的檢索問題。

If latency or cost becomes a problem, optimize the hierarchy before you optimize the model. Microsoft’s dynamic community selection work shows one clear production direction: prune irrelevant community branches before a full global map-reduce pass. That idea is powerful because it respects GraphRAG’s main advantage, the hierarchy, instead of reducing the system back to flat chunk retrieval.

如果延遲 (latency) 或成本成為問題，先優化階層，再去優化模型。微軟的動態社群選擇 (dynamic community selection) 工作展示了一個明確的生產方向：在進行完整的全域 map-reduce 流程之前，先修剪掉不相關的社群分支。這個構想之所以強大，是因為它尊重了 GraphRAG 的主要優勢——階層，而不是把系統退回成扁平的區塊檢索。

Common Mistakes to Avoid / 應避免的常見錯誤

The first mistake is importing a graph that is technically correct but has poor language quality. The second is leaving out text_unit_ids and losing links to the source, which weakens Local and DRIFT-style retrieval. The third is using Global Search for every question, even though Microsoft’s docs warn that deeper levels give better answers but take more time and tokens. The fourth is not doing prompt tuning. The fifth is relying on a single benchmark as proof that the pipeline is ready for production. A better approach is to test the system repeatedly on the types of questions your users actually ask.

第一個錯誤是匯入一個技術上正確、但語言品質低落的圖譜。第二個是遺漏 text_unit_ids 而失去與來源的連結，這會削弱 Local 與 DRIFT 式的檢索。第三個是對每一個問題都使用全域搜尋，儘管微軟的文件已警告較深的層級雖能給出更好的答案，卻要花費更多時間與符元 (tokens)。第四個是沒有進行提示調校。第五個是仰賴單一基準測試來證明管線已準備好上線生產。更好的做法是針對你的使用者實際會問的問題類型，反覆測試整個系統。

Frequently Asked Questions / 常見問題

What is BYOG in GraphRAG?

GraphRAG 中的 BYOG 是什麼？

It is a workflow in which you start with an existing graph and let GraphRAG generate the community and query artifacts needed for search and summarization, rather than extracting the full graph from raw text from scratch. In Microsoft’s implementation, the minimal BYOG inputs are entities and relationship tables, with text units added when you need more advanced search modes.

它是一種工作流程，你從一個既有的圖譜出發，讓 GraphRAG 產生搜尋與摘要所需的社群與查詢產物，而不是從原始文字從零開始抽取出完整的圖譜。在微軟的實作中，最精簡的 BYOG 輸入是實體表與關係表，當你需要更進階的搜尋模式時，再加入文字單元。

Do I need text units if I already have a graph?

如果我已經有一個圖譜，還需要文字單元嗎？

Not always. Microsoft’s official BYOG guide says you can run a basic Global Search workflow with just entities and relationships, but Local Search, DRIFT Search, and Basic Search need text units and some embeddings. Text units also help keep links to the source and allow for text-based community reports when graph descriptions are not detailed.

不一定。微軟官方的 BYOG 指南指出，你只用實體與關係就能執行一個基本的全域搜尋工作流程，但區域搜尋、DRIFT 搜尋與基本搜尋都需要文字單元與一些嵌入向量。文字單元也有助於維持與來源的連結，並在圖譜描述不夠詳細時，讓你能使用基於文字的社群報告。

When should I use Local, Global, or DRIFT Search?

我應該在什麼時候使用 Local、Global 或 DRIFT 搜尋？

Use Local Search for entity-specific questions that need detailed neighborhood context. Use Global Search for abstract or corpus-wide questions that require synthesis across the dataset. Use DRIFT when the user’s question needs both broad context and targeted follow-up retrieval, especially when the wording does not map neatly onto your original extraction templates.

對於需要詳盡鄰域脈絡的特定實體問題，使用區域搜尋。對於需要跨資料集進行綜整的抽象或語料庫範圍的問題，使用全域搜尋。當使用者的問題同時需要廣泛脈絡與針對性的後續檢索時——尤其是當其措辭無法整齊地對應到你原始的抽取模板時——使用 DRIFT。

In short, advanced GraphRAG production work is not about choosing between “graph” and “RAG.” It is about deciding which parts of your domain knowledge should be a durable graph structure, which parts should become summaries, which parts should stay as raw evidence, and which retrieval path should answer each question. “ Bring your own graph” is therefore not a shortcut. It is the mature version of GraphRAG: keep the graph you trust, add the summarization and retrieval layers you need, and evaluate the whole system by real question classes rather than by demo-friendly examples.

簡而言之，進階的 GraphRAG 生產工作並不是在「圖譜」與「RAG」之間做選擇。它的重點在於判定：你的領域知識中，哪些部分應該成為持久的圖譜結構，哪些部分應該轉化為摘要，哪些部分應該保留為原始證據，以及哪一條檢索路徑應該回答哪一個問題。因此，「帶入你自己的圖譜」並不是一條捷徑。它是 GraphRAG 成熟的樣貌：保留你所信任的圖譜，加上你所需要的摘要層與檢索層，並以真實的問題類別、而非便於展示的範例來評估整個系統。

For readers who want a longer practitioner guide beyond papers and framework docs, Neo4j also points to Essential GraphRAG from Manning as a book-length guide to building GraphRAG systems from scratch, improving traceability, and evaluating performance.

對於想要一份超越論文與框架文件、篇幅更長的實務指南的讀者，Neo4j 也推薦了 Manning 出版的 Essential GraphRAG，作為一本書本長度的指南，內容涵蓋從零打造 GraphRAG 系統、改善可追溯性 (traceability) 與評估效能。

References / 參考資料

  1. Microsoft GraphRAG Documentation — Indexing Dataflow.

微軟 GraphRAG 文件 — 索引資料流 (Indexing Dataflow)。

  1. Microsoft GraphRAG Documentation — Custom Graphs / Bring Your Own Graph.

微軟 GraphRAG 文件 — 自訂圖譜 / 帶入你自己的圖譜 (Bring Your Own Graph)。

  1. Microsoft GraphRAG Documentation — Local Search, Global Search, DRIFT Search, Prompt Tuning.

微軟 GraphRAG 文件 — 區域搜尋、全域搜尋、DRIFT 搜尋、提示調校。

  1. Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization.

Edge 等人，《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》。

  1. Microsoft Research Blog — GraphRAG auto-tuning, dynamic community selection, and DRIFT Search.

微軟研究院部落格 — GraphRAG 自動調校、動態社群選擇與 DRIFT 搜尋。

  1. Peng et al., Graph Retrieval-Augmented Generation: A Survey; Han et al., Retrieval-Augmented Generation with Graphs (GraphRAG); ACM Digital Library entry for Graph Retrieval-Augmented Generation: A Survey.

Peng 等人，《Graph Retrieval-Augmented Generation: A Survey》；Han 等人，《Retrieval-Augmented Generation with Graphs (GraphRAG)》；ACM 數位圖書館中《Graph Retrieval-Augmented Generation: A Survey》的條目。

  1. Neo4j GraphRAG Pattern Catalog and Neo4j GraphRAG documentation.

Neo4j GraphRAG 模式目錄與 Neo4j GraphRAG 文件。

  1. LlamaIndex Property Graph documentation and custom retriever guide.

LlamaIndex 屬性圖譜文件與自訂檢索器指南。

  1. Essential GraphRAG book pages from Neo4j/Manning.

來自 Neo4j／Manning 的 Essential GraphRAG 書籍頁面。

🔤 關鍵術語

英文 繁中譯名 文章中的脈絡 / 簡短說明
GraphRAG 圖譜檢索增強生成 微軟提出的方法，將文件抽取成圖譜並利用社群報告於查詢時回答跨文件問題
BYOG (Bring Your Own Graph) 自帶圖譜 從既有圖譜出發，讓 GraphRAG 在其上建立摘要與檢索層的工作流程
vector RAG 向量檢索增強生成 傳統 RAG，擅長找相似段落但難以做跨文件推理或全語料摘要
TextUnits 文本單元 文件切分後的原子分析單位，並作為回溯原始來源文字的依據
entities / relationships 實體 / 關係 從文本抽取或匯入的圖譜節點與邊，存於 entities.parquet、relationships.parquet
claims (covariates) 主張（共變量） 可選的抽取資料，預設關閉，通常需 prompt tuning 才有效
community reports 社群報告 由圖譜社群由下而上生成的摘要，是 Global Search 的核心素材
hierarchical Leiden community detection 階層式 Leiden 社群偵測 預設用於將圖譜分群成多層抽象，weight 欄位用以正確計算社群
Local Search 局部搜尋 以實體為起點，聚集鄰近文本單元、關係、社群報告於單一上下文窗
Global Search 全域搜尋 以 map-reduce 流程搜尋社群報告，回答廣泛或抽象問題
DRIFT Search DRIFT 搜尋 介於局部與全域之間，用社群資訊產生追問再做聚焦檢索
map-reduce 映射—歸併 Global Search 處理社群報告以彙整答案的流程
vector store / embeddings 向量資料庫 / 向量嵌入 GraphRAG 將嵌入寫入設定的向量儲存，Local/DRIFT 檢索所需
Parquet Parquet 表格 GraphRAG 預設以 Parquet 表格儲存輸出，符合資料工程實務
VectorCypherRetriever 向量-Cypher 檢索器 Neo4j 模式，向量命中後再經圖譜遍歷擴展上下文
Text-to-Cypher 文字轉 Cypher LlamaIndex 檢索堆疊之一，將自然語言轉為 Cypher 查詢
property graph 屬性圖譜 LlamaIndex 可組合多種檢索方法的圖譜檢索架構
graph traversal 圖譜遍歷 自向量命中沿關係擴展，取得含原文與關係的最終上下文
prompt tuning / auto-tuning 提示調校 / 自動調校 由輸入資料生成領域特定提示，避免逐領域手動提示工程
dynamic community selection 動態社群選擇 在全域 map-reduce 前剪除無關社群分支以降低延遲與成本