ブログ一覧

2026.10.12

知識圖譜RAG如何讓企業問答更準確可追溯

知識圖譜RAG的價值，在於不只找出相似文件，而是能沿著「人、制度、產品、事件與證據」之間的關係回答問題。當使用者問「這項採購例外由誰核准、依據哪份規範、影響哪些供應商」時，單純向量搜尋容易回傳零散段落；圖譜式檢索則能串起多跳關係，讓答案更完整且可追溯。

傳統 RAG 技術透過切塊、嵌入、向量資料庫與生成模型，把企業文件帶進問答流程；然而，跨部門規章、設備維修、法遵與供應鏈問題往往需要理解關聯、版本與權限。RAG這一術語最早出現於2020年發表的一篇研究論文，而企業導入的重點已從「能不能回答」轉向「能否引用、治理、評估與持續更新」。

本文會先說明知識圖譜RAG與 Vector RAG、Hybrid RAG 的差異，再逐步介紹文件智慧擷取、Schema 設計、圖譜與向量索引、RAG重新排序及 Agentic RAG。接著也會聚焦 LLM幻覺治理、LLM模型評估、權限傳遞與 PoC 驗證，協助團隊以實際資料建立可衡量的企業知識庫。

知識圖譜RAG是什麼，何時比傳統檢索更適合

知識圖譜RAG以節點與關係連結企業文件的架構示意圖

從文件相似度走向關係脈絡

知識圖譜RAG是把文件內容轉成實體、關係與可查詢的圖結構，再搭配生成模型回答問題的架構。它不會只因兩段文字語意相近就回傳結果，而會辨識「合約屬於哪個專案」、「條款由哪個部門維護」、「規範影響哪些流程」等關係，特別適合跨文件、多步推理與需要說明依據的企業問答。

傳統 Vector RAG 的核心是把文字切成區塊後轉成向量，利用距離找到語意接近的內容；優點是建置快、適合 FAQ 與單一文件問答。相對地，Graph RAG 會將「實體─關係─實體」整理為三元組，例如「採購政策－規範－核准層級」，使系統能沿關係查找，而不是只比對字詞相似度。

實務上不必將兩者視為二選一。Hybrid RAG 可先以向量資料庫迅速召回候選內容，再以圖遍歷補出相關角色、文件版本與上下游影響範圍。這種組合能避免圖譜涵蓋不足時答不出來，也能降低只憑相似段落拼湊答案的風險；重點在於依查詢複雜度選擇檢索路徑。

  • 單跳、語意明確的 FAQ，可優先使用向量檢索。
  • 涉及角色、時間、依賴關係的問題，應啟用圖譜檢索。
  • 高風險回答應保留文件與關係鏈的引用證據。

判斷是否需要圖譜的三個問題

最直接的判斷方式是看問題是否需要多跳推理。若使用者必須從產品找到零件、再從零件找到供應商、最後確認供應商的認證是否有效，答案至少橫跨三層資料。這類問題若只取 Top-K 相似文字，常會漏掉關鍵中間節點；知識圖譜RAG則能依關係路徑補齊查詢脈絡。

第二個判斷點是資料是否高度結構化卻分散。企業知識庫經常同時存在 PDF 規範、試算表、工單、CRM 與資料庫紀錄；文件內的敘述、欄位中的代碼與組織權限彼此有關。圖譜能將它們對齊成共用語意層，並以實體識別碼避免同一供應商被不同寫法誤判為多個對象。

第三個判斷點是答案是否必須可解釋。醫療、金融、製造或法遵情境若只輸出結論，審核者無法判斷系統是否引用過期條款。知識圖譜RAG可回傳「使用哪些節點、經過哪些關係、對應哪些文件區塊」，讓人員能檢查推理路徑；但仍須把生成內容與證據逐句比對。

  • 問題是否需要跨兩份以上文件完成回答。
  • 資料是否包含主檔、事件紀錄與長篇文件。
  • 使用者是否需要查驗回答來源與權限範圍。

核心架構與查詢流程

一個可維運的架構通常包含資料擷取層、知識抽取層、圖資料庫、向量資料庫、檢索編排層與生成層。資料進來後先保留原始文件及版本，再產生文字區塊、向量、實體與關係；每一筆衍生資料都應能回指來源。如此一來，索引出錯、文件撤銷或權限改變時，團隊才有能力精準更新。

查詢開始時，系統先辨識意圖與實體，例如「A 廠的保固例外」涉及廠區、設備與保固條款。接著可同時執行關鍵字搜尋、向量搜尋與 Cypher 圖查詢，取得局部文件證據與圖中鄰近節點。編排器再根據相關性、資料新鮮度、使用者 ACL 與來源可信度，篩選可放進提示詞的上下文。

最後階段不應只讓 LLM 自由摘要，而要要求它依證據回答、標示引用、指出不足資料，並拒答超出證據的推論。若檢索到的文件互相矛盾，系統應呈現版本與生效日期，而非硬湊單一答案。這是將知識圖譜RAG從展示型聊天機器人，提升為可進入業務流程工具的關鍵。

  • 原始文件、區塊、節點與關係都需保存來源 ID。
  • 查詢時同步考量相關性、權限與資料版本。
  • 生成前後都需要證據覆蓋與引用檢查。

打造企業知識庫：文件智慧擷取與圖譜建模

先建立可回溯的文件智慧擷取管線

文件智慧擷取的第一原則是保留原貌與位置資訊。PDF、掃描檔、簡報與試算表不應只抽成純文字，還要記錄頁碼、表格座標、標題層級、附件關係與文件版本。這些中繼資料不僅支援後續引用，也能在使用者追問「這項結論出自哪一頁」時，提供可人工覆核的精確證據。

處理流程可先依格式分流：原生 PDF 擷取文字與段落結構，掃描件經 OCR 處理，表格則保留列欄標題及儲存格關係。切塊不宜只按固定字數切割，應優先遵從章節、條款、表格與語意邊界；否則核准條件與例外條件被切到不同區塊時，RAG 技術即使找到文字也容易做出錯誤解讀。

若要先建立可重現的實驗環境，可使用指令 virtualenv kg_rag –python=python3.12 建立隔離環境。這不是生產部署的完整答案，卻有助於固定 Python 版本、套件與測試資料，避免同一批文件在不同開發者環境產生不一致結果。每次擷取都應記錄模型、提示詞、程式版本與執行時間。

  • 保留原檔、頁碼、座標與版本，才能支持引用與稽核。
  • 表格、條款與標題應採結構化切塊，而非機械截斷。
  • 擷取紀錄必須可追查至模型、程式與來源文件版本。

Schema、三元組與實體對齊如何設計

圖譜建模應先從業務問題開始，而不是急著把所有名詞都變成節點。若目標是回答設備維修問題，Schema 至少要界定設備、零件、故障模式、工單、技師、廠區與維護手冊等實體，並定義「安裝於、導致、處置於、引用」等關係。Schema 越貼近決策問題，檢索與維護成本越容易控制。

三元組是「主體─關係─客體」的基本單位，例如「機台 A－使用－濾芯 B」。LLM 可以協助抽取三元組，但不應直接把輸出全數寫進正式圖譜；應加入受控詞彙、欄位驗證與信心分數。尤其關係方向、否定條件與生效範圍最常被誤抽，必須用規則、抽樣複核或人工審核防止錯誤擴散。

實體對齊用來解決同一對象的多種名稱，例如「台北總部」、「臺北 HQ」與內部代碼是否代表同一單位。應優先採用主資料 ID、別名表與上下文條件，向量相似度只能作為候選提示。若把名稱相近但不同的客戶合併，圖譜會產生錯誤關係；後續多跳查詢看似合理，實際上卻會洩漏不相干資訊。

  • Schema 以高價值問題與業務名詞為起點。
  • 三元組入庫前應有格式、詞彙與信心檢核。
  • 實體對齊應以主資料識別碼優先於名稱相似度。

版本更新、刪除與衝突合併

企業知識庫最容易被忽略的問題，是文件更新後舊關係沒有失效。正確做法是為文件、區塊、實體與關係建立版本與有效期間，並保留「由哪份文件、哪次抽取、哪個模型」產生的血緣。當新版規範上傳時，系統可比較差異，只重抽受影響章節並標記舊條款已失效，而非每次都全量重建。

增量更新需要處理刪除與衝突。例如某份作業程序被撤回，相關向量區塊、圖節點與關係都要從可檢索集合移除；但為稽核目的，原始紀錄可保留在受限封存區。若兩份有效文件對同一規則給出不同內容，系統不應自行選擇，而要依文件層級、生效日與權責單位建立衝突處理規則。

建議將圖譜 Schema 與抽取規則納入版本控制，並支援索引重建與回滾。生產環境可先在影子索引驗證新版抽取結果，再切換流量，避免一次更新讓大量關係消失。這種資料生命週期治理比單次建圖更重要，因為企業知識庫的可信度取決於它是否能反映當下有效的業務事實。

  • 以版本、有效期間與血緣管理每一項圖譜資料。
  • 刪除文件時，必須同步處理向量、節點與關係索引。
  • 更新前先在影子環境評估，再執行正式切換。

RAG 技術如何結合向量資料庫與重新排序

向量資料庫不是企業知識庫的全部

向量資料庫負責儲存文字、圖片或表格轉換後的向量，讓系統可用語意相近度尋找內容。它非常適合處理同義詞、自然語言提問與大量非結構化文件；但向量距離不是事實正確性的證明。若同一主題存在新舊制度，僅憑相似度很可能找回已失效的條款，因此必須併用版本、權限與時間等過濾條件。

完整的 RAG 技術通常含資料清洗、切塊、嵌入、索引、檢索、RAG重新排序、上下文組裝與回答生成。研究與產品案例常提到答案品質的準確度提升了77.6%，但這類改善必須回到自己的測試集驗證，因為文件品質、問題難度、模型與評分方式不同，任何單一數字都不能直接當成企業上線的保證。

服務選型也不能只看宣傳規格。市場資料中可見 $300 美元 的方案、宣稱可用性高達 99.999%的服務，以及擁有11.9K subscribers、標示Posted: 2024-12-31或2024-12-31的技術內容；這些資訊可作為初步調查線索，卻不能取代延遲、資料駐留、權限整合與總持有成本的實測。

  • 向量相似度適合召回，不等於可直接作為事實依據。
  • 索引應同時帶入文件版本、ACL 與來源欄位。
  • 外部規格與案例數字只能作為假設，必須以內部資料驗證。

RAG重新排序決定上下文是否真的有用

RAG重新排序的目的，是從初步召回的多筆內容中，挑出最能回答問題的少數證據。第一階段的向量或關鍵字搜尋追求高召回率，允許帶回一些雜訊；第二階段則使用 cross-encoder、LLM 評分或規則模型，重新判斷問題與文件片段之間的精確關聯，降低無關上下文占用提示詞空間。

重新排序不應只看語意分數。企業情境至少還要納入來源權威性、文件新鮮度、使用者權限、是否為正式發布版本，以及片段是否含完整條件。舉例來說，某段文字雖然最相似，若其文件已被新版政策取代，排序器應降權；若使用者無權查看，即使分數最高也必須在檢索階段排除。

對圖譜檢索而言，排序對象還可包括關係路徑。系統可以評估一條路徑是否過長、關係類型是否可靠、是否跨越不必要的實體，並優先保留能回指原始文件的路徑。最終提供給 LLM 的不是最多資料，而是少量、完整、互相不矛盾且有明確來源的證據組合。

  • 第一階段追求召回，第二階段追求精準與可用性。
  • 排序特徵應包含新鮮度、權限、權威性與完整性。
  • 圖譜路徑也要排序，避免無意義的遠距關聯。

混合檢索的查詢編排策略

混合檢索應依問題動態路由，而不是每一題都執行所有工具。定義清楚、只需查單一規範的問題，可走關鍵字與向量搜尋；包含代碼、日期或精確欄位的問題，可優先查結構化資料；問到原因、影響與關聯時，再啟動圖遍歷。這樣能兼顧速度、成本與答案覆蓋率，也讓除錯時更容易知道是哪一條檢索路徑失敗。

查詢擴展可把使用者口語問題改寫成關鍵詞、同義詞、實體名稱與關係條件。例如「誰能核可緊急採購」可擴展為核准角色、金額門檻、例外流程與現行政策版本。但改寫必須保留原問題，且不能擅自加入未被詢問的假設；否則系統可能因錯誤擴展而在大量文件中找到看似合理的錯誤答案。

高品質混合檢索還需要快取與觀測。常見查詢可快取檢索結果，但文件更新、權限異動或政策生效時必須立即失效；同時記錄每次查詢用了哪些索引、取回哪些片段、經過何種重新排序，才能比較不同設定對正確率、延遲與成本的影響。這些紀錄是後續 LLM模型評估與治理的基礎。

  • 按問題類型路由工具，避免固定且昂貴的全量流程。
  • 查詢改寫要可追溯，並保留原始提問。
  • 快取策略必須與文件版本及權限異動連動。

Agentic RAG如何處理多步查詢與工具決策

代理式檢索的價值與邊界

Agentic RAG讓模型不只執行一次檢索，而是能判斷要搜尋什麼、使用哪個資料來源、證據是否足夠，以及是否需要再次查詢。它適合複雜的跨來源問題，例如先查合約條款、再查產品主檔、最後核對工單狀態；但不適合拿來處理所有簡單問答，否則額外的工具呼叫與推理迴圈只會拉高延遲與成本。

資料碎片化正是代理架構受到關注的原因。Gartner reports that 80% of organizations struggle with fragmented data，而McKinsey reports employees lose 20% of their time searching for information。當資料散落在文件庫、工單、CRM 與內部系統時，代理能協助規劃檢索順序；不過它仍必須在明確的資料邊界內執行，而非任意存取所有系統。

導入前也要正視中繼資料與合規缺口：With 70% lacking effective metadata practices and 60% facing challenges balancing access, security, and compliance。若文件沒有擁有者、有效日期、敏感標記與 ACL，Agentic RAG 只會更快地放大治理問題。因此，代理策略必須建立在已整理的企業知識庫與可驗證工具權限之上。

  • Agentic RAG 適合多步、跨來源及需自我驗證的問題。
  • 簡單 FAQ 應維持單次檢索，避免不必要的代理成本。
  • 缺乏中繼資料與 ACL 時，先治理資料再擴大代理能力。

設計可控制的代理迴圈

可控的 Agentic RAG 應以狀態機實作，而非讓模型無限制自由規劃。基本狀態可包括：解析問題、選擇資料源、檢索、檢查證據、補查或停止、生成與驗證。每次工具呼叫都要寫入追蹤紀錄，包含輸入、結果摘要、耗時、權限判定與失敗原因；這些資料可讓團隊重播問題並定位代理在哪一步偏離目標。

停止條件必須可計算，例如已找到足以支撐每個子問題的引用、連續兩輪沒有新增高分證據，或達到最大迭代次數。複雜查詢可設定 max_retrieval_rounds = 3，並控制在max 3 to 4 steps內；超過門檻時應回覆「目前證據不足」或轉人工，而不是為了完成任務繼續猜測。

開發框架版本也需鎖定並測試相容性，例如LangChain v0.3。工具 Schema、提示詞與模型升級都可能改變代理決策，造成同一問題走到不同資料源。因此每次變更都要跑回歸測試，檢查權限、引用、停止條件與成本上限是否仍符合規範，而不是只確認程式能成功執行。

  • 以狀態機、工具白名單與完整日誌約束代理行為。
  • 設定可量化的證據門檻、迭代上限與人工接管條件。
  • 框架、工具與提示詞變更都需進行回歸測試。

成本、延遲與權限不能交給代理猜

Agentic RAG 的成本不只來自生成 token，還包括多輪檢索、重新排序、圖查詢、外部工具與失敗重試。市場上可見€39/mo flat, ~€0.065/1M等計價資訊，也有案例宣稱340%的成效；企業不應直接以此推估投資報酬，而要以自身查詢量、平均輪數、模型價格與尖峰流量建立成本模型，再設定每題與每位使用者的預算上限。

權限設計必須從使用者身分一路傳到查詢改寫、圖節點、向量區塊、工具呼叫及最終引用。代理不可以因為改寫問題後換了關鍵詞，就跳過原始使用者 ACL；同一份文件的標題、摘要與內容也可能有不同敏感等級。最安全的做法是由檢索服務執行強制過濾，而非相信 LLM 會主動遵守文字指令。

對高風險系統，還應防範惡意文件中的間接提示注入。例如文件內要求模型忽略規則、洩漏其他資料，代理若把它視為操作指令就可能越權。防禦方式包括將文件內容視為不可信資料、限制工具參數、分離系統提示詞與檢索內容、掃描可疑指令，並在工具執行前進行政策檢查。

  • 成本模型需拆分檢索、排序、模型、工具與重試費用。
  • ACL 必須在每一次檢索與工具呼叫中強制傳遞。
  • 文件內容一律視為不可信資料，防止間接提示注入。

用LLM幻覺治理與模型評估讓系統可上線

LLM幻覺治理要從檢索到回答分層處理

LLM幻覺治理不是只靠一句「請勿編造」的提示詞，而是要拆解錯誤發生的位置。第一層是資料錯誤，例如 OCR 讀錯、文件過期或三元組抽取失真；第二層是檢索錯誤，例如沒有找回關鍵條款、圖遍歷走錯節點或重新排序漏掉證據；第三層才是模型生成了來源未支持的內容。分層後才知道該修資料、索引還是提示策略。

回答端應採取證據約束：每個結論都需對應至少一段來源、無證據時明確說明不足、遇到衝突時呈現差異而不強行整合。對數字、日期、責任歸屬與法規條件等高風險欄位，可要求系統逐項抽取來源原文並進行一致性比對。引用連結應指向使用者有權存取的原始位置，避免只提供無法查核的摘要。

此外，要建立拒答與升級機制。當檢索信心低、資料版本衝突、問題涉及個資或需要專業簽核時，系統應提供下一步建議，例如列出需要補充的文件或轉交權責人。可靠的企業 AI 不以「每題都回答」為目標，而以「每個回答都知道證據邊界」為設計原則。

  • 將錯誤區分為資料、檢索與生成三層。
  • 高風險結論必須逐項連回可查驗的來源。
  • 低信心與衝突情境應拒答、說明原因或轉人工。

LLM模型評估必須同時看答案與檢索

LLM模型評估應從真實業務問題建立測試集，並將問題依單跳、多跳、表格理解、版本衝突、權限限制與拒答需求分類。每一題要有標準答案、必要證據、可接受表述及不可洩漏資料；測試集需與開發資料分離，才能避免團隊只針對看過的問題調參，誤以為模型已經穩定。

指標至少要分成檢索召回率、上下文精確率、答案正確性、忠實性、引用完整性、拒答正確率、延遲與單題成本。若答案錯誤，還要標記是文件不存在、切塊不佳、實體消歧錯誤、圖路徑錯誤、排序失敗或模型幻覺。這種誤差分析比單一平均分數更有行動價值，能直接對應改善優先順序。

部署時可採影子模式與金絲雀發布：先讓新版本在不影響使用者的情況下處理真實問題，與正式版本比較引用、正確率、延遲及成本，再逐步擴大流量。模型、嵌入、Schema、提示詞或排序器任一變更，都可能造成行為漂移；因此評估不是上線前一次性的驗收，而是持續性的營運機制。

  • 測試集應涵蓋真實任務、例外情境與拒答情境。
  • 同時衡量檢索品質、答案品質、引用品質與營運成本。
  • 以影子模式和漸進發布降低模型更新風險。

以小規模 PoC 驗證是否值得正式投資

最務實的導入方式是先以 AI PoC 驗證關鍵假設，而非一開始就把所有文件建成大型圖譜。PoC 應挑選具體且高價值的問題，例如「維修人員能否在工單中找到正確處置規範」，並定義可衡量 KPI：回答正確率、引用完整率、平均查詢時間、人工查找工時與可接受成本。這可避免需求模糊下的過度開發。

ALION 的做法強調以現場調查、實際資料與最小配置原型驗證可行性，並依結果做 Go／No-Go 判斷。其 AI 上游工程訂閱服務為月費 20 萬日圓起；相較於聘僱 CTO 級人才月薪 80〜150 萬日圓，或外包開發啟動費約 300 萬日圓起，小規模驗證能先取得決策證據，再判斷是否值得進入正式建置。

PoC 的交付不應只是一個聊天介面，而要包含測試問題集、資料盤點、Schema 草案、檢索日誌、評估報告與後續架構建議。若驗證顯示資料品質不足、使用者沒有明確任務或效益無法成立，選擇暫緩也是有價值的結果。反之，若指標達標，原型的設計與程式碼應能延續到正式系統，降低交接損耗。

  • PoC 要驗證業務 KPI，不只展示模型能否生成文字。
  • 使用實際資料與現場流程，才能看見真實精度與限制。
  • Go／No-Go 都應以可追溯的評估證據支撐。

總結

知識圖譜RAG不是取代向量搜尋，而是為需要關係推理、可解釋引用與嚴格治理的企業問題補上結構化脈絡。成功關鍵不在於堆疊更多模型，而在於把文件智慧擷取、Schema、權限、混合檢索、RAG重新排序、幻覺治理與持續評估串成可維運流程。

重點整理

  • 先依問題複雜度選擇 Vector RAG、Graph RAG 或 Hybrid RAG，而非盲目全面建圖。
  • 圖譜資料必須具備來源、版本、有效期間與 ACL，才能支援可信回答。
  • Agentic RAG 應有明確的狀態機、輪數上限、預算與人工接管機制。
  • LLM模型評估要拆分檢索、引用、答案、拒答、延遲與成本，才能有效改善。
  • 以實際資料執行小規模 PoC，可及早判斷正式投資是否合理。

若您的企業正面臨規章分散、跨文件查找困難或 AI 回答難以驗證的問題，建議先挑選一個明確流程建立 PoC。透過現場訪談、資料盤點與測試題集，先量化知識圖譜RAG對正確率、工時與風險的影響，再決定圖譜規模、Agentic RAG 範圍與正式上線路徑。

常見問題 FAQ

Q1. 知識圖譜RAG與一般 RAG 最大差異是什麼？

一般 RAG 多以文件區塊的語意相似度檢索；知識圖譜RAG則額外建立實體與關係，可處理跨文件、多跳與需要解釋來源鏈的問題。兩者常以 Hybrid RAG 搭配使用，而非互相取代。

Q2. 企業導入知識圖譜RAG前，最先要整理什麼？

先盤點高價值問題、資料來源、文件版本、主資料識別碼、權限規則與文件擁有者。沒有清楚的中繼資料、ACL 與更新責任，即使模型表現良好，也難以長期維持答案可信度。

Q3. Agentic RAG一定比傳統 RAG 好嗎？

不一定。Agentic RAG 適合需要多步檢索、跨系統工具與證據驗證的複雜任務；對簡單 FAQ，單次檢索通常更快、更便宜也更容易治理。應以測試集比較正確率、延遲與成本後決定。

Q4. 有哪些可信的延伸參考資料？

可參考 Microsoft GraphRAG 官方專案：https://github.com/microsoft/graphrag；Neo4j GraphRAG for Python 文件：https://neo4j.com/docs/neo4j-graphrag-python/current/；Lewis 等人的 RAG 論文：https://arxiv.org/abs/2005.11401；以及 NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework。

Q5. 如何驗證知識圖譜RAG是否值得正式開發？

以小規模 PoC 選定一個真實業務流程，建立含標準答案與來源的測試題集，量測檢索召回、回答正確、引用完整、拒答正確、平均耗時與單題成本。只有在實際資料與現場使用者都驗證價值後，再擴大到正式企業知識庫。



ブログ一覧へ戻る