IVGraph
GraphRAG 是一種檢索增強生成技術，利用由實體及其關係構成的知識圖譜，為大型語言模型（LLM）找出所需的脈絡。當答案取決於相互關聯的事實，或橫跨整個資料集合的模式時，就值得測試 GraphRAG；但如果只是需要找到正確的段落，並不代表就該採用它。向量 RAG 仍是合理的起點，而將兩者結合，往往是更實用、值得探索的設計。
簡單來說：相似度搜尋找出段落；圖譜連結事實
向量檢索問的是：哪些段落與這個問題的語意相近？圖譜檢索則多問了一個問題：哪些內容與這個問題涉及的事物有關聯？
想像一個專案工作空間。「我們要如何部署這項服務？」可能只要一份操作手冊就能解答。「哪次上線依賴處理這起事件的團隊所負責的服務？」則需要循著事件、團隊、服務與上線之間的連結，才能找到答案。
這就是圖譜 RAG 與向量 RAG 在實務上的差別。兩者並不是「聰明的檢索與愚笨的檢索」之分，而是要選擇哪種結構能幫助你蒐集所需的證據。
一段話看懂 RAG，以及向量搜尋的不足之處
檢索增強生成會先檢索相關資訊，在模型回答前將這些資訊提供給大型語言模型（LLM）作為上下文。傳統的向量 RAG 會將文件切分成區塊，透過嵌入將這些區塊轉換為數值表示，再根據它們與問題的向量相似度進行檢索。接著，負責回答的模型會依據選出的文字作答。Meilisearch 的比較文章說明了兩者的根本差異：一種依據相似度檢索，另一種則透過相互連結的實體檢索。
對於「我們的退款政策對取消有什麼規定？」這類問題，找到相關的政策段落可能就夠了。要測試這個工作流程，不需要將每位客戶、每項政策和每項產品都以節點表示。
當所需的脈絡分散在不同地方時，這些限制就變得更有意思了：
- 多跳問題：必須沿著多個關聯逐步追查，才能找到答案，而不是只找出一段相符的內容。
- 整體性問題：「我們的專案回顧中，有哪些主題反覆出現？」問的是整組專案回顧資料，而不只是與問題最相符的內容。
- 分散的事實：答案的不同部分散落在不同頁面中，其中有些部分可能看起來與原始問題並不相似。
在這個事件範例中，某個上線頁面可能完全沒有提到該事件。檢索與問題表述相似的段落，和沿著已記錄的相依關係找到該上線頁面，是兩種不同的操作。
這並不代表向量檢索無法提供答案，而是說，你應該測試它是否能找出所有必要的資訊片段，而不是只憑第一筆結果看起來是否相關來評斷它的成效。
逐步解析 Microsoft GraphRAG 的運作方式
Microsoft GraphRAG 是一套以圖譜為基礎的開源 RAG 系統。其擷取、社群與摘要流程，可作為理解這種方法的實用參考。將工作分成兩個階段：先準備資料集，再根據資料集回答問題。
建立索引：將文字轉為彼此串聯的脈絡
- 擷取實體。 大型語言模型（LLM）會辨識來源資料中討論的事物。以一組假想的工程資料為例，這些事物可能包含服務、團隊、專案和事件。
- 擷取關係。 LLM 會辨識這些實體之間的關係。例如，文件可能提到某個服務由特定團隊負責。
- 建立圖譜。 實體轉為節點，關係轉為連結，為檢索提供能呈現資料間連結的結構。
- 將實體分成群集。 系統會將圖譜整理成由相互連結的實體組成的群集，而不是將每個實體視為孤立的個體。
- 撰寫群集摘要。 產生的摘要會概述這些群集，供後續檢索與回答使用。
關鍵的改變在於，系統準備的不只是可供搜尋的段落，也會建立對應的表徵，呈現這些段落討論的事物、這些事物彼此如何連結，以及相互連結的群組包含哪些內容。
查詢：局部問題與全域問題
局部搜尋以實體為中心。試想：「哪些項目與帳務服務有關聯？」相關脈絡會以特定實體及其關係為中心來組織。
全域搜尋涵蓋整個資料集。試想：「這些專案中有哪些反覆出現的協調問題？」社群摘要提供素材，讓你能進行更廣泛的綜合分析，而不只是依賴與問題相似的段落。
Microsoft 的 GraphRAG 文件將索引建立、查詢方法與提示詞調校分開說明。初步評估時，可以先做一個簡單且實用的區分：你是在探究某個特定事物，還是想綜觀整個資料集合？
別把「局部」誤解為「在我的筆電上執行」。這裡指的是搜尋範圍。也別以為每次圖譜查詢都需要社群摘要：沿著頁面間明確的關聯進行檢索，是範圍較小的圖譜檢索流程。
圖譜 RAG 與向量 RAG：實務比較
下方的圖譜欄位包含 Microsoft 的擷取與摘要方法。以現有連結建立的工作流程可以省去擷取這些連結的步驟，因此設定方式並不相同。
| 比較面向 | 向量 RAG | 圖譜式 RAG |
|---|---|---|
| 資料模型 | 以嵌入向量表示文字區塊。 | 透過關係連結的實體或頁面；Microsoft GraphRAG 也會建立社群摘要。 |
| 索引建置作業與成本 | 準備文字區塊並產生嵌入向量。 | 準備圖譜結構；若處理流程使用 LLM 擷取資料及產生摘要，需為這些作業編列預算。 |
| 優先測試的問題 | 可從一段或少數幾段相關文字中找到答案的問題。 | 需要串聯多項事實的問題；有社群摘要時，可測試需要統整整個資料集的問題。 |
| 可解釋性 | 檢視檢索到的文字段落及其來源。 | 檢視檢索到的來源與關係路徑；即使路徑可見，仍需有證據支持。 |
| 資料新鮮度與維護 | 規劃如何將文字變更反映在文字區塊與嵌入向量中。 | 也需規劃變更如何影響關係及任何已產生的摘要。 |
| 常見工具或元件 | 嵌入模型、向量索引、來源儲存庫，以及用於回答問題的 LLM。 | 圖譜表示方式與檢索邏輯；Microsoft GraphRAG 是可供評估的開源實作。 |
| 需留意的失敗情況 | 結果看似相關，卻遺漏了必要的事實。 | 關係缺漏或具有誤導性，或摘要遺漏了必要的細節。 |
我一開始採用的原則：如果一段文字就能涵蓋所需證據，就先測試段落檢索。如果證據形成一條鏈，就測試檢索整條鏈。如果問題涉及整個集合，就測試集合層級的方法。
何時分別使用，何時搭配使用
需要段落式回答時，先從向量 RAG 著手
當預期答案能在明確可辨識的文字中找到時，政策、指示與說明都是適合作為起點的案例。在為同一批內容引入另一種呈現方式之前，先建立基準。
先釐清失敗是出在檢索，還是作答。如果當時已有正確的佐證資料，加入圖譜可能無法解決真正的問題。
測試圖譜檢索，取得以關係呈現的答案
請使用確實需要依據關聯才能回答的問題：哪些專案依賴某項服務、哪些決策連結到某項需求，或哪些研究筆記支持某個論點。這些是建議的評估案例，並非承諾能提高準確度。
請確認你的資料是否包含這些關係。若來源結構和擷取流程都未提供某條有用的連線，圖譜就無法沿著該連線探索。
全面替換前，先試試混合式工作流程
一種可供測試的實用設計，是將語意入口與圖譜擴展結合：
- 搜尋與問題相關的文字或節點。
- 從這些起點沿著選定的關聯探索。
- 擷取相連項目的來源內容。
- 將佐證資料及其來源參照提供給負責回答的模型。
以事件案例為例，搜尋可以找到事件報告。接著，可透過圖譜遍歷，沿著連結找到受影響的服務與依賴該服務的上線作業。閱讀這些頁面，就能取得回答所需的實際證據。
測試前，先訂好範圍：哪些關係類型有用、要沿著關係探索到多遠，以及要傳回多少內容？「納入所有相連的內容」不是檢索策略，只是在迴避取捨。
GraphRAG 的實際成本
若未確定語料庫、模型選擇與設定，就無法合理訂出通用價格或固定的成本倍數。編列預算時，真正有用的問題是：這套處理流程增加了哪些工作？
若採用 Microsoft 的擷取與摘要方法，請將使用模型擷取實體與關係並產生社群摘要的工作納入考量。這些都是基本的分塊與嵌入流程之外的額外準備步驟。不要把「開源」當成執行這些工作的預算。
試行時，請將成本分開記錄：
- 初期準備：依你的設計，在有使用到的環節進行嵌入、擷取與摘要生成。
- 提問：檢索作業、提供給大型語言模型的上下文，以及答案生成。
- 更新：讓你維護的資料表示形式反映來源內容修改所需的作業。
- 維運：儲存、除錯，以及檢查錯誤或遺漏的關係。
資料更新也需要單獨測試。修改來源中的一項陳述，重新執行你選定的更新流程，再檢查產生的回答。檢查原始內容、圖譜中的呈現，以及任何依據舊陳述產生的摘要。不要因為初次建立索引成功，就認定整批資料會持續保持最新。
如果你的連線已經以明確連結的形式存在，就不必透過 LLM 擷取這些連線。但這並不代表可以省去內容檢索、答案生成或維護。省去的只是其中一個步驟，而不是以圖譜為基礎的 RAG 所涉及的所有成本。
你的筆記本來就有圖譜結構
相較於存放彼此未連結文件的資料夾，內容相互連結的工作空間提供了不同的起點。Notion 中的資料庫關聯、頁面提及與反向連結，以及上層頁面與子頁面之間的關係，都已構成明確的連線。Obsidian 儲存庫中則有維基連結。這些連結可以成為圖譜中的連線，不必請 LLM 找出它們。
假設你的「專案」資料庫與「服務」資料庫建立了關聯，而事件筆記中也提及服務頁面。你就已經有一條路徑，可以從事件筆記連到服務，再連到相關專案。我們的 Notion 資料庫關聯指南說明了明確建立的連結；涵蓋範圍更廣的 Notion 知識圖譜指南則將這些連結放在整體脈絡中說明。
有一點必須坦白說明：頁面圖譜並不必然是實體知識圖譜。一個頁面可能討論多個實體。提及某個頁面，表示一個頁面參照了另一個頁面，不一定表示一項服務依賴另一項服務。父子連結表達的是階層關係，而非所有權或因果關係。
檢索時，請保留這項區別。循著提及內容尋找可能有用的佐證，接著閱讀該頁面，再對這項關係的意義下定論。
這自然與 LLM 維基 相呼應：分別思考來源頁面、頁面之間的連結，以及生成的解讀。將這些層次明確區分，就更容易檢視答案，而不是把每個生成的關聯都當成已確立的事實。
讓代理存取結構與內容
IVGraph 根據 Notion 頁面、反向連結、提及及資料庫關聯建立圖譜。其唯讀 V1 LLM API 讓代理程式能夠搜尋、取得節點詳細資訊與頁面內容，以及走訪圖譜。兩者結合，就足以在你已維護的工作空間基礎上，建立能運用圖譜資訊的檢索工作流程。
可供測試的代理工作流程很簡單：搜尋專案、查看其節點、循著相關連結、擷取相連頁面的內容，再根據這些證據回答。若想了解更全面的個人工作流程，請參閱使用 LLM、Notion 和 Claude Code 打造第二大腦。
別一開始就擷取你已經明確維護的關聯。先測試將這些關聯呈現出來，是否能解決缺乏脈絡的問題。
如何從小處開始
先從問題著手，而不是遷移資料庫。使用這份檢查清單，確保實驗始終針對實際查找資料失敗的情況進行：
- 選定一組範圍明確的資料。 挑選一個專案領域，確保其中的內容與關係都能由你親自檢視。
- 寫下實際會問的問題。 如果與你的工作相關，請納入直接查找資訊的問題、需要串聯相關事實的問題，以及涵蓋整組資料的問題。
- 確認所需的佐證。 記下正確答案必須使用哪些段落與關係。
- 執行向量檢索，建立比較基準。 保存檢索出的上下文及生成的答案。在調整架構之前，先找出缺少哪些佐證。
- 盤點現有連線。 將有用的關係與偶然提及的內容及階層連結區分開來。
- 只補上缺少的能力。 針對需要串聯相關事實的問題，測試走訪功能；或針對 Microsoft 擷取與摘要處理流程原本設計要解決的問題，測試該流程。
- 比較並更新。 檢視佐證的涵蓋程度、缺乏佐證的說法、成本及回應時間。接著修改一項來源內容，檢查結果是否反映最新資訊。
如果圖譜層能在你可負擔的成本下，找出基準方法遺漏的必要脈絡，就保留它。如果兩種方法的回答品質一樣好，就選擇較容易維護的那一種。
常見問題
簡單來說，什麼是 GraphRAG？
GraphRAG 是一種檢索增強生成技術，利用由實體及其關係組成的知識圖譜，為大型語言模型（LLM）找出脈絡資訊。它不只尋找相似的段落，還能透過事物之間的連結檢索資訊。
GraphRAG 比向量 RAG 更好嗎？
並非所有問題都如此。要找出相關段落，向量 RAG 是合理的起點。若回答需要串聯彼此相關的事實，就值得測試圖譜檢索；而 Microsoft 的社群摘要方法也支援針對整個資料集的提問。請用你自己的問題和資料來源比較這些方法。
Microsoft GraphRAG 和所有以圖譜為基礎的 RAG 都一樣嗎？
不一樣。Microsoft GraphRAG 是一套開源實作，會擷取實體與關係，將它們分成社群，產生摘要，並提供局部與全域搜尋。以圖譜為基礎的檢索也可以利用既有關係，不必經過完整的擷取與摘要產生流程。
GraphRAG 的成本是多少？
若未確定語料庫、模型選擇與處理流程設定，就無法提供有參考價值的單一價格。編列預算時，應納入擷取與摘要生成（如有使用）、檢索與回答生成、儲存及更新的成本。請以具代表性的小樣本實測，而非假設成本是向量 RAG 的固定倍數。
可以用 Notion 連結做 GraphRAG 嗎？
可以。資料庫關聯、提及與反向連結，以及父子頁面，都能提供明確的圖譜邊，無須透過 LLM 擷取。你仍需要一套檢索流程，選出相關頁面、讀取其內容，並將佐證提供給負責回答的模型。單靠頁面連結，並無法說明連結所代表的關係。