知識圖譜并非魔法，也不是萬靈藥。它們擅長多跳推理和可解釋性，但也增加了復雜性，只有當用戶真正提出“為什么”和“它們之間有什么聯系”的問題時，這種復雜性才值得。

如果你最近參加過GenAI相關的大會，你可能聽說過，知識圖譜要么是企業AI的救星，要么就是徹頭徹尾的騙子。經過 20 多年的軟件開發，12 年的圖譜系統構建，以及過去兩年構建 GenAI 和知識圖譜系統、代理以及代理內存解決方案，我可以告訴你，這兩個陣營都有對有錯——這就是問題所在。

在過去兩年左右的時間里，我投入了大量時間研究各種使用知識圖譜的技術，例如 GraphRAG、Agent、MCP等。在此期間，一些主要的誤解占據了主流。在本文中，我將討論我所見所聞的一些最常見的誤解，并探討我所認為的這些誤解背后的真相。與往常一樣，這些只是我的經驗和觀點，因此我鼓勵其他人在此發表評論，無論是支持還是反對。以下是人工智能、大模型、大語言模型、AI代理、通用人工智能的關系，以便我們更好的理解下文所述的內容。

注意：就本文而言，我將知識圖譜指代為通用數據結構，而不是特定的格式、數據模型或技術。圖譜由許多不同的底層技術支持，例如庫、框架、處理引擎、數據庫等，所有這些技術都提供了本文強調的基本優勢。

誤解 1 — 知識圖譜對于所有 GenAI 工作都至關重要

如果您一直在研究 GenAI 問題，您可能已經讀過一篇或多篇博客文章，其中提到知識圖譜有助于實現這些技術在生產層面的運作和擴展，有時甚至更大膽地稱其至關重要，。這些大膽的論斷通常伴隨著一些輕描淡寫的概念，例如圖譜如何在這些工作中提供范式轉變，但除了一些關于捕捉復雜關聯數據中的關系、提供基礎和實現推理的基本陳述之外，通常很少提供實質性的解釋。

事實是，雖然有些工作會受益于它們所包含的結構化知識。

“對于一系列可靠性或安全關鍵型應用來說，結構化知識仍然不可或缺”

然而，添加這些數據確實會帶來額外的成本，包括時間和金錢成本，以及復雜性，而且并不一定能提供更好的答案。例如，GraphRAG 經常被吹捧為比基于向量的 RAG 能為 LLM 提供更完整、更全面的上下文，因此推斷其結果會更好。然而，實際情況遠非如此。

對于問答任務，我們觀察到 RAG 在單跳問題和需要詳細信息的問題上表現更好，而 GraphRAG 在多跳問題上更有效。

您是否曾經見過 GraphRAG 應用程序的演示，讓您不禁思考“這比矢量 RAG 的答案更好嗎？”，并且對它們之間的差異感到有些失望。這是因為并非所有工作或問題都需要將概念聯系在一起。在這些用例中，基于向量的 RAG 將提供相同或更好的性能。例如，讓我們看一個銷售應用程序的示例。如果問題是“我們第三季度的銷售額是多少？”，那么這些信息很可能包含在單個文檔的單個部分中。對于此用例，向量搜索很有可能找到相關信息來提供答案。但是，如果問題是“為什么第三季度的銷售額下降？”，那么向量搜索會找到提及第三季度銷售額的文檔。但是，圖譜將“第三季度銷售額→客戶投訴→延遲發貨→供應商問題”連接起來，為 LLM 提供了可能影響這些結果的相關概念的更完整圖景。

假設所提問題在語言上與向量中的數據相似，那么基于向量相似度的搜索將在 topK 中找到最相關的塊，從而為 LLM 提供足夠的上下文。只有當你需要跨多個文檔塊連接概念，或者查找概念相關但語言不相關的信息時，圖譜中的結構化知識才會開始發揮顯著的價值。

事實上，就連 Anthropic 也提到，對于較小的知識庫（<20 萬個詞條），直接向模型提供完整的上下文比考慮更復雜的架構模式（例如 RAG）更有效。誠然，這是 LLM 提供商建議你使用更多詞條，但我想說，其基本理念是，對于數據量較少的簡單問題領域，在應用程序中添加圖譜不會帶來或只有有限的好處。

誤解2——知識圖譜將解決LLM幻覺

這或許是最常見且最具誤導性的說法之一。讓我澄清一下，在你的項目中添加圖譜或任何其他技術并不能消除幻覺。正如我的一位同事常說的那樣，“幻覺并非設計缺陷，而是其本身的功能”，而像OpenAI 這樣的供應商現在也基本持同樣的觀點。LLM 中的幻覺是其工作原理的一個基本組成部分，它類似于手機在猜錯單詞時自動更正的功能，只不過它猜測的是下一個句子、段落等等。提供更相關的上下文和信息已被證明可以提高答案的準確性，但這也僅適用于所提問題是它擁有足夠信息來回答的問題的情況。由于 LLM 的設計和評估方式，LLM 仍然可能并且會產生幻覺。

知識圖譜可以提供結構化的事實信息，但 LLM 處理數據的基本方式仍然存在，這些方式可能會導致錯覺。首先，僅僅因為你提供了正確的數據并不意味著不會出現錯誤的邏輯跳躍，或者模型會對所提供的數據做出合理的推斷。其次，LLM 基于訓練數據的概率計算來生成響應。這意味著即使給出了正確的數據，LLM 仍然可以創建看似合理但不正確的信息來填補任何空白。最后，知識圖譜包含的信息量以及它在特定上下文中可以提供的信息量是有限的。這導致 LLM 依賴其訓練來填補任何空白，這可能會導致不理想的響應，尤其是在數據有限和或提出新問題時。

從本質上講，大語言模型 (LLM) 試圖預測你認為他們想要的答案，而幻覺則是預測錯誤。知識圖譜就像一本精準的參考書，然而，僅僅因為某人擁有正確的參考資料，并不意味著他們總是能夠正確地使用它，或者在遇到參考資料以外的問題時停止胡編亂造。

誤解3——圖系統總是優于矢量或其他系統

這或許是所有誤解中最具破壞性的，因為一些博客文章夸大了這種誤解，這些文章展示了一些精心挑選的例子，表明基于圖的系統產生了顯著更好的結果。其含義很明顯：如果你仍在使用“普通”的向量系統，那么性能就無從談起。

事實遠沒有那么戲劇化，而且更有用。

正如我之前提到的，研究表明，GraphRAG 和傳統 RAG 分別擅長不同類型的問題，但并不是說其中一種就普遍更勝一籌。我引用的系統評估論文發現：

“RAG 在單跳問題和需要詳細信息的問題上表現更好，而 GraphRAG 在多跳問題上更有效。”

然而，我經常看到團隊放棄完好的矢量 RAG 系統而用圖譜重建，結果卻發現他們的性能要么保持不變，要么變得更糟。

為什么會發生這種情況？

大多數現實世界的問題分布嚴重偏向單跳查詢。讓我們看一些實際的模式：

客戶支持聊天機器人：

• 大多數問題都是簡單的查找：“你們的退貨政策是什么？”“我如何重置密碼？”—— Vector 檢索可以很好地處理這些問題
• 復雜的故障排除問題將受益于圖檢索
• 您需要決定是否值得為您的解決方案增加復雜性

內部知識庫：

• 大多數查詢都是事實檢索：“第三季度的收入是多少？”“誰擁有項目 X？”并且可以通過向量檢索很好地處理
• 圖譜的優勢主要體現在分析問題上：“為什么 X 項目會失敗？”“這些舉措之間有什么關聯？”
• 如果您的分析是在其他地方完成的（BI 工具、報告），那么圖譜只會增加復雜性而無益處。

沒人談論的性能權衡

即使在圖譜為多跳問題提供更好答案的用例中，它也會帶來很少被強調的成本：

• 延遲：圖遍歷 + LLM 推理通常比向量相似性搜索 + LLM 推理花費的時間更長，主要是因為發送的上下文量更大
• 復雜性：需要構建、維護和調試的組件更多（圖構建、實體提取、關系建模）
• 令牌使用：多跳檢索通常會引入更多上下文，從而增加每個查詢的成本
• 脆弱性：不良的實體提取或關系建模可能會使結果比簡單的方法更差

問題不是“圖譜更好，”而是“它在哪些方面更好？

”這里有一個實用的框架：分析實際用戶查詢的樣本并對其進行分類：

• 單跳、直接提問→ 向量檢索可能足夠且更快；
• 多跳推理問題→圖檢索增加價值；
• 探索性/分析性問題→圖譜可能會增加價值；
• 混合工作→考慮采用混合方法，對問題進行分析并將其路由到適當的位置以使用向量、圖譜或兩者共用。

令人不安的真相

圖譜并非總是最佳選擇，GraphRAG 并非天生就是“更好的 RAG”，圖譜也并非天生就比非圖譜“更好”——它是針對不同問題類型優化的不同數據結構。將其視為通用升級會導致過度設計的解決方案，其性能不如更簡單的替代方案。我曾與一些公司合作，由于圖譜增加了復雜性，他們投入生產的時間比計劃長了數月甚至數年。最糟糕的是？投入生產后，他們的最終用戶并沒有注意到明顯的差異。那些從圖譜中看到真正價值的公司，是那些已經測量了問題分布并確認確實需要大規模多跳推理的公司。

如果您還沒有完成該分析，那么您還沒有準備好決定任何架構，您已經準備好運行實驗了。

那么圖譜何時能提供價值？

真相——大型語言模型 (LLM) 可以從圖的多跳推理和可解釋性中受益

構建 LLM 應用程序的根本挑戰之一源于其固有的不可預測性和可能產生幻覺，再加上其訓練數據是靜態的且可能已過時。事實證明，為 LLM 提供更相關、更可靠的數據，可以提供更準確、一致和更可靠的響應。在許多架構模式（例如 RAG）中，這些“黃金”數據是從 LLM或應用程序之外的數據源檢索的。但是，既然數據源如此之多，為什么人們還要關注知識圖譜呢？

我認為這歸結于圖譜或關系數據庫所回答問題的根本性質：圖譜回答的是“如何”和“為什么”的問題，而不是“什么”和“多少”的問題。我們這些從事圖譜工作的人常說：“當數據中的聯系與數據本身一樣重要時，圖譜就表現出色”——但我們很少深入探究這在實踐中究竟意味著什么。我的一位同事曾說過：關系數據會告訴你某人購買了多少白酒以及購買了哪種類型的白酒，而圖譜數據會告訴你他們為什么購買，以及他們接下來可能會購買什么。

舉個具體的例子：假設你正在分析白酒購買情況。關系數據庫查詢可能會告訴你：

• 顧客張三上個月購買了 12 瓶汾酒和 6 瓶茅臺酒
• 平均每位顧客每月購買 8 瓶白酒
• 本季度汾酒銷量增長15%

這些都是關于“發生了什么”的寶貴見解。但現在，不妨考慮一下，通過遍歷關系，圖譜可以揭示什么：在圖譜結構中，你不僅存儲購買記錄，還存儲實體之間的關系。張三購買了白酒 A。白酒 A 與白酒 B 共享酒香型信息。購買白酒 A 的顧客也經常購買白酒 C。白酒 C 是由張三在社交媒體上關注的白酒廠釀造的。現在，你可以回答不同的問題了：

張三為什么要買那種汾酒？（他一直在探索清香風格的白酒，購買了類似的白酒，并關注這家白酒廠）

接下來你應該推薦什么白酒？（按照他的購買記錄→相似的口味→他還沒有嘗試過的評價很高的白酒的路徑）

這位顧客是如何發現你的品牌的？（追蹤路徑：朋友推薦→共同購買場合→產品發現）

關鍵區別在于，關系數據庫針對聚合和過濾離散數據點進行了優化。而圖則針對遍歷數據點之間的連接進行了優化。當你的業務問題需要理解“是什么導致了這個問題”或“什么與這個問題相關”時，你就是在要求圖遍歷關系——這在 SQL 中代價高昂且笨拙（想想多個 JOIN 語句，它們的復雜度會呈指數級增長），但在圖查詢中卻很自然。

簡而言之：如果您需要計數、分類和聚合，請使用關系數據。如果您需要發現影響鏈、隱藏的聯系和多步驟推理路徑，請考慮使用圖譜。

這種在數據中尋找聯系和模式的能力提供了一定程度的數據推理能力，可以幫助大語言模型填補其知識上的空白。

讓我們看看這如何應用于兩個常見的 GenAI 工作負載，GraphRAG 和 Agentic Memory

2024 年 4 月，微軟研究院發布了論文《從局部到全局：基于 GraphRAG 的查詢中心摘要方法》，這是第一篇廣泛討論如何利用圖譜增強 RAG 架構有效性的論文。自該論文發表以來，涌現出許多遵循這一基本理念的論文、博客文章、工具包、公司等，它們認為圖譜比單純的語義搜索能夠提供更好的上下文信息。

GraphRAG 通過在檢索階段利用知識圖譜的固有連通性，擴展了傳統的檢索增強生成 (RAG)。傳統 RAG 通常對單個文檔或塊執行語義搜索，而 GraphRAG 通常但并非總是利用語義或全文搜索來查找起始實體，然后遍歷關系以提供更完整的上下文信息。

例如，GraphRAG 并非僅僅檢索關于產品的單一事實，而是經常使用類似基于向量的語義搜索來查找相關的產品描述，然后順藤摸瓜找到相關產品、客戶行為和歷史模式——本質上是執行“多跳”檢索，以捕捉更廣泛的上下文。這意味著，當 LLM 接收到檢索到的信息時，它獲得的不僅僅是孤立的事實，而是這些事實之間如何相互關聯的更完整的圖景。這種更豐富的上下文有助于 LLM 通過理解不同信息之間的關系來生成更準確、更細致的響應，類似于人類如何運用關聯知識來推理復雜主題。圖路徑的可解釋性也使得 LLM 更容易理解和驗證其得出結論的過程。

當我們觀察Agentic Memory時，我們會看到非常相似的模式。當思考長期代理記憶的需求，AI代理隨著時間的推移維護和利用自身經驗和知識的能力，知識圖譜提供了一種自然的結構，可以以有意義的方式組織和連接這些記憶。與平面文檔存儲或簡單的鍵值記憶不同，圖結構允許代理創建豐富的、相互關聯的表示，以體現其經驗、決策和學習到的信息。例如，代理可以跨時間連接相關的交互，關聯相似的經驗，并在其學習到的概念之間建立關系。這種網絡化的記憶結構支持更復雜的推理，因為代理可以遍歷這些連接來查找相關的經驗或知識，就像人類的聯想記憶一樣。

當代理需要做出決策或響應查詢時，它可以沿著這些關系路徑從多個相關記憶中收集上下文，不僅理解單個事實，還能理解它們如何相互關聯形成更廣泛的模式。這一點尤其強大，因為它允許代理隨著時間的推移發展出更細致的理解，將新的經驗整合到現有的知識網絡中，而不是作為孤立的數據點存在。

另一個我之前沒有立即意識到的價值是，為代理提供圖譜表示可以降低延遲，減少令牌或成本，從而提高效率。讓我們看看 Zep 的論文（ZEP：用于代理記憶的時態知識圖譜架構）中的下圖，他們比較了為代理提供記憶的完整上下文和相同記憶的圖譜表示的效果。

全上下文與基于圖的內存表示的比較。這里的得分顯示，不同方法的準確率大致相當（55-71%），這似乎有些不相上下。但這才是關鍵所在——基于圖的方法在保持同等質量的同時，效率得到了顯著提升。延遲降低了 10 倍，令牌使用量降低了 70 倍。對于每天處理數千次查詢的生產系統來說，這并非微不足道的優化，而是經濟可擴展系統與經濟可擴展系統之間的區別。

入門：你應該從哪里開始

快速驗證測試：

在構建任何內容之前，請手動追蹤 10-20 個最常見的用戶查詢。你能通過單個文檔查找來回答這些問題嗎？還是你會在腦海中將多個來源的信息串聯起來？

這 15 分鐘的練習比任何架構辯論都更有價值。如果你經常在文檔之間跳轉來回答問題，圖譜可能會有所幫助。如果大多數答案都存在于單個文檔中，那就堅持使用向量搜索。

如果你確實需要圖譜：從小處著手

如果你確定圖譜能夠提升價值，那就不要急于在第一天就對整個領域進行建模。我見過的最成功的實施都遵循以下模式：

• 從一個高價值用例開始（通常是當前系統失敗的多跳問題）
• 最低限度建模（核心實體和 2-3 種關鍵關系類型）
• 衡量你的基線（向量 RAG 或更簡單的方法）
• 僅當看到清晰的投資回報率 (ROI) 時才進行擴展

我見過一些團隊為了處理一個查詢，花了幾個月的時間完善他們的本體。一開始很混亂，但很快學會了，然后根據實際使用模式進行改進。

圖的真正作用：結構化知識解決結構化問題

在審視了炒作和現實之后，我們得出的結論是：知識圖譜并非萬能的解決方案，也不是靈丹妙藥——它只是一種在特定情況下才有效的專用工具。GenAI領域正在日趨成熟，超越“一刀切”的思維模式。正如我們不會使用圖數據庫進行簡單的鍵值查找，也不會使用關系數據庫進行網絡分析一樣，我們不應該將知識圖譜默認用于所有 GenAI 應用。問題不在于“我應該使用知識圖譜嗎？”，而在于“我的問題是否需要理解概念如何跨多個跳轉連接？”

當圖譜真正增加價值時：

• 您的用戶提出涉及多個相關概念的問題
• 數據點之間的關系與數據本身同樣重要
• 你需要可解釋的推理路徑（誰影響了誰，為什么提出這個建議）
• 您正在構建持久的代理記憶，必須將一段時間內的經歷聯系起來

當它們增加復雜性而沒有帶來好處時：

• 您的整個知識庫適合上下文窗口（<200k 個標記）
• 問題主要是單跳查找
• 您的數據自然適合表格格式，并且查詢是聚合
• 你需要快速交付并首先迭代快速工程

我見過的最成功的 GenAI 實現并不是那些跳上知識圖譜潮流的實現，它們都是從簡單開始，衡量用戶真正關心的內容，并且只有當簡單的方法遇到明顯的限制時才增加結構復雜性。

或許最重要的洞見是：大語言模型 (LLM) 讓我們重新思考如何構建和檢索信息，但它們并沒有改變數據架構應該與查詢模式匹配的基本原則。圖擅長解答“為什么”和“它們之間如何關聯”的問題。如果這些問題并非用戶真正關心的問題，那么無論圖多么復雜，都無法創造價值。

真正的機會并不在于在任何地方應用知識圖譜，而在于足夠深入地理解何時值得付出復雜性成本。

您的看法是什么？

我特別好奇：

• 您是否構建了真正影響 LLM 績效的知識圖譜？
• 或者您是否見過團隊針對不需要的問題過度設計圖形解決方案？
• 您使用什么決策標準來確定何時添加這種復雜性？