概念地圖・GraphRAG 知識圖譜檢索管線
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
GraphRAG 知識圖譜檢索管線：追查關係
金紙店的型錄貼滿便條，店員問哪些品項共用同一條交貨限制，搜尋結果只吐出各自的商品頁。限制寫在另一封供應商通知裡，連起兩份文件的線，還在老闆腦中。GraphRAG 把文件裡的實體與關係整理成圖，再依問題挑選查找路線。這頁聚焦 Microsoft 的經典局部與全域設計：前者追一個品項周邊，後者整理跨群主題。線接對了，資訊才有機會串起來——接錯了，答案也可能跟著錯。
建圖一次，依問題選查找路線
依 Microsoft 索引說明，流程會抽取實體與關係、偵測社群、製作摘要。圖中的社群是圖上關聯形成的群組。表格把兩條查詢路線對到店員的問題。
| 位置 | 使用的資料 | 店內要查的事 |
|---|---|---|
| 建索引 | 文件切塊後，建立關係與社群摘要 | 供應商、品項、配送限制各自指回哪份文件 |
| 局部查找 | 實體鄰域加原文文字塊 | 品項竹的交期，通知適用到哪一天 |
| 全域查找 | 社群報告分組回答，再彙整重點 | 本季文件提到哪些共同配送風險 |
| 交付答案 | 附可回查的來源，另做權限檢查 | 摘要省略日期時，先補查原文再承諾到貨 |
查詢總覽把 local 用於特定實體，把 global 用於整體主題，現行也列有 DRIFT 與 basic。這張圖選兩條代表路線；實際系統還要決定查詢範圍。全域的 map-reduce 流程先讀指定層級的社群報告，再篩選中間重點做彙整——日期與例外條款，交付前仍須回查。
先查關係從哪段文字長出來
一、讓真問題決定是否建圖。先收集店員上週卡住的問句。查單一品項報價，可能找到那張報價單就夠；問哪些商品會一起延遲，才需要連接供應商、配送車次與品項。把這些問題各跑一次現有搜尋，記下漏了哪份通知——建圖的理由要落在一次具體的漏接上。自問：我的真實問題，需要串起不同文件裡的關係嗎？
二、抽查每條邊的出生證明。供應商甲提供松與竹，圖上至少要保留甲與品項的對應來源。店員把竹的商品簡稱輸入系統後，還要查看它是否被併到另一個同名品項。抽到一條「甲供應竹」的邊，就沿回鏈打開那段型錄——一個名稱像，不足以替兩個品項共用交期。自問：實體合併有什麼依據，每條關係能回到哪段原文？
三、先指定維護與拒答的人。採購接到改期訊息，誰負責讓圖譜失效或更新；店員權限撤掉，哪批摘要也要重新限縮；通知互相衝突，誰回覆供應商確認。這些都要寫進上線責任。把最後更新時間放在答案旁邊——過期資料的回答，再流暢也會讓櫃檯白等。自問：資料更新、權限異動與資訊不足時，各由誰處理？
金紙店的供應商文件，走一遍
底下這家台灣中部的金紙店，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。甲、乙、松、竹、梅都是示意名稱，下列三份通知與日期也都為演練假設。範圍只涵蓋交易文件。
- 先留下三份原件：通知 A，九月一日：「甲供應松、竹，兩品項同車配送。」通知 B，九月十日：「甲的九月十二日配送車停駛，恢復日另行通知。」通知 C，九月十一日：「竹新報價自九月十五日起生效；乙供應梅，另車配送。」每份原件都留文件代碼、日期與可讀取人員。日期先留在來源上。
- 把關係接回證據：甲連到松與竹，兩條供應邊引用 A；同車關係也引用 A。停駛限制由 B 連到甲的那次配送；竹的報價有效日引用 C。甲、竹與停駛能串起來，所依據的是兩份文件的連接。報價生效日不要黏成交貨日。
- 走局部路線問竹的最新交期：系統沿竹找到甲，再取 A 與 B 的原文。可交付的回答是：「竹與松共用甲的配送車次〔A〕；九月十二日停駛、恢復日尚待通知〔B〕。目前資料不足以確認下一次交貨日。」另外註明 C 只更新報價條件。缺的那段資訊，直接留白。
- 走全域路線問本季共同配送風險：讀甲相關群組與乙相關群組的摘要，分組後彙整：「已知松、竹共用甲的車次，受同一次停駛影響〔A、B〕；梅記為另車配送〔C〕，現有文件未載明其餘限制。」回答把檢索範圍寫成這三份示意文件；店員另向乙確認風險。季報的問法，仍受手上資料限制。
櫃檯真正需要的是一句能往下辦事的回答：先通知訂松、竹的客人有交期風險，再向甲追問復駛時間。這裡最容易出錯的接縫，是把「同一車」擴寫成「所有品項都延遲」，或拿九月十五日的報價生效日填入交期。讓店員點開 A、B、C，親自看到系統如何把兩段文字接在一起——確認後再對外承諾。回答也應列出尚未掌握的恢復日期，留下採購待追的事項。以上為說明結構用的示意情境，僅供理解框架之用。
圖譜什麼時候會騙你
- 錯接的邊會把錯誤帶到下一題。竹若被合併到同名的另一個品項，供應商、價格與交期可能一起串錯。回答還會拿那些連線組成合理的故事——越完整越難察覺。抽查時從一個答案倒走，確認每個節點的識別碼，以及每條邊的原文依據；推測的關係另行標示。
- 社群摘要可能磨掉有效日期與例外。「甲近期配送不穩」容易留在摘要裡，九月十二日是哪一車、恢復日仍未定等條件，可能在壓縮時失去位置。讀者接到的是概括句——櫃檯承諾要靠具體條件。交期、適用品項與例外條款應逐項點回原文確認。
- 建圖之後仍有刷新帳單。甲每次改通知，受影響的關係與摘要都要檢查；原件限縮權限，衍生資料也得跟著處理。試用成本要把抽取、摘要、查詢、人工查核和更新工時一起記錄——營運人員下班後補這些洞，也算成本。用真問題評估，保留停用低價值路線的選項。
痛點視角拆出答案責任
關係一旦寫進圖譜，錯接的邊也會跟著回答出門。
店員敢不敢照答案回覆客人，取決於答案把多少責任留給他。《痛點》的 P.A.I.N. 視角在這裡追問：誰還在人工翻通知，卡住的是核對日期、追問供應商，還是負責對客人改口？這張圖畫得出資料如何串接，畫不出店員替一句交期承諾承擔的壓力。導入後先看那個負擔有沒有減輕。若他每次都得重查整疊文件，便利只出現在展示畫面——查核工作還壓在同一個人身上。今晚挑一筆尚未確認的到貨詢問，請店員照系統回答實際追一遍，記下在哪個引用停住，再由採購補上那一段可核實的通知。
GraphRAG，常見問題
文件不多的店，也需要做 GraphRAG 嗎？
先看最常卡住的問題。若店員找一份通知就能回答，整理檔名、日期與基本檢索可能已經有效。只有反覆出現跨文件關係的漏接，才值得試建一小組圖譜——用同一批真問題比對查找完整度、來源可查性與維護工時，再決定擴大範圍。
答案附了來源，還需要人工查嗎？
需要確認來源真的支持那句結論。案例裡 A 支持同車，B 支持某日停駛，兩份都沒有提供復駛日期。引用齊全之後，還要逐句對照日期與適用品項——尤其是交期、價格等會影響交易的資訊。缺少的條件應顯示待確認，並指派人追問。
把文件權限設好，就能放心共用圖譜嗎？
還要檢查衍生資料的可見範圍。某位店員讀不到原報價單，若共用摘要已含價格，資訊仍可能透過回答出現。建圖時記錄來源權限，查詢前按使用者篩選可用資料，權限異動後檢查關係與摘要——這些是部署端要補齊並實測的責任。
怎麼判斷「不知道」該不該出現在答案裡？
讓問題需要的欄位逐一對到證據。問交期就查適用品項、車次與日期；目前只有停駛公告，下一次配送時間便維持未確認。外部常識與模型推論應獨立標示。店員需要看到缺的是哪份通知——下一通電話才知道該追問什麼。
回答牽涉跨文件關係時，來源的切塊與引用仍是底座，接著可用RAG 檢索增強生成管線檢查證據如何進入回答，再用語意三角核對品項名稱所指的對象。把那封供應商通知打開，從第一條供應關係往回查。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。