AI 上下文平台：圖形驅動上下文層何時勝過純向量 RAG

Gartner 於 2026 年 8 月 13 日為 "AI Context Platforms" 給出了正式定義：一類使資料與 AI 工程團隊能夠建構、治理並向 AI 智慧代理人交付語義化組織知識的軟體——把上下文當作企業的一等資產來對待，而不是每個代理人各自維護的配置。兩家廠商在 48 小時內用產品為該品類背書：Neo4j 於 10 月 20 日交付 Context Engine，NVIDIA 於 10 月 21 日交付 Agent Knowledge Foundation。當分析機構為品類命名、且兩家平台廠商在兩天內填滿它時，買方得到的是真實的選擇——和一道全新的決策題。本指南梳理這道題：圖形驅動上下文層勝過純向量 RAG 的五個問題、純向量 RAG 依然占優的三個問題，以及比你買什麼產品更重要的三項控制——因為無論買什麼，這三項都必須自己建構。

關鍵要點

• 86% 對 57% —— 微軟 GraphRAG 研究（Edge et al., 2024）測得，在複雜的多實體查詢上，圖形檢索的完整性達到 86%，而純向量 RAG 只有 57%。只要問題需要沿關係行走而不是匹配文字，這個差距就會出現。
• Gartner 於 2026 年 8 月 13 日為品類命名 —— 按分析師定義，AI Context Platforms「將組織知識的生命週期與單個智慧代理人的生命週期分離開來」。這一分離是治理論據，不是檢索功能。
• Neo4j 的 Business Ontology 是一個 6 層圖形模型 —— 業務流程與組織、領域本體、資料產品、實體系統、工具與整合、執行期知識——Neo4j 稱其源自數百個企業級部署。Context Engine 以私有預覽版（private preview）出貨。
• 純向量 RAG 在建構成本與文件問答上依然占優 —— 上線 6–8 週（圖譜建構 12–16 週），並且晚交互嵌入已在 800 份真實 PDF 的代理人問答上達到 92.4%（MADQA），全程無需 OCR。
• 部署方的三項控制是：出處溯源、攜帶權限的檢索、生命週期分離 —— 沒有任何一項由市售產品完整提供；每一項都活在團隊自有的 MCP 模組與稽核層裡。

獲得名字的品類

Gartner 的定義（Kjell Carlsson、Afraz Jaffri、Christopher Long、Radu Miclaus，2026 年 8 月 13 日）值得讀兩遍，因為它是治理層面的定義，不是檢索層面的：AI 上下文平台是「使資料與 AI 工程團隊能夠建構、治理並向 AI 智慧代理人交付語義化組織知識的軟體」，而「透過把上下文當作企業的一等資產而非代理人各自維護的配置，這些平台將組織知識的生命週期與單個智慧代理人的生命週期分離開來，提高了組織跨領域擴展和治理其 AI 智慧代理人的能力」。

品類所命名的那個問題，是代理人特有的。資料在這個世界裡有兩類消費方，持續了幾十年：人——腦袋裡裝著記錄之間的關係；以及應用——這層含義活在寫死的邏輯程式碼裡。代理人是第三類消費方，而這兩類遺產它一樣都繼承不到。Neo4j 的發布部落格把失敗模式寫得具體：應用知道帳戶狀態「二」表示「暫停待審」，因為映射寫在程式碼裡；代理人對此一無所知，而且映射因組織而異——「客戶」在行銷部是一種含義，在財務部是另一種（Neo4j 部落格）。

兩家廠商在 48 小時內交付了回應。Neo4j 的 Context Engine 打包了預定義的 6 層 Business Ontology、從 Databricks 或 Snowflake 等來源建構本體並向編排層暴露的建置與執行環境層、Context Studio 控制平面，以及記錄代理人推理與決策路徑的圖形原生記憶層。Neo4j 的 President of Technology 兼 CPO 把後果說得很直白：「所有其他方案都是權宜之計，隨著 AI 代理人在複雜度與系統存取需求上繼續增長，它們會失效」（新聞稿）。對買方而言，兩個誠實標記值得注意：Context Engine 處於私有預覽階段；它那句「GraphRAG 比純向量 RAG 更精確、更具成本效益」是廠商自述——獨立數字來自微軟的研究，不是 Neo4j。

NVIDIA 在 10 月 21 日選擇了相反的架構立場：不是平台，而是由你自己組裝的模型與 CUDA-X 函式庫。其 Agent Knowledge Foundation 頁面聲明，元件「可與現有的資料平台、本體、向量資料庫和代理人框架協同工作；不需要採用新的端到端平台」，並包含一個 Auto Ontology 產生器——NVIDIA 稱在測試中把本體建構時間縮短了 90%，同時業務專家仍需「測試、精煉並認證」其輸出（NVIDIA）。這最後一條正是本體建構的誠實版本：軟體提出，擁有者認證。

純向量 RAG 依然做得好的事

純向量檢索並不是品類發布材料所暗示的稻草人。它做好的三件事，決定了它何時仍是正確選擇。

第一，建構成本。本站的 GraphRAG 實施指南給出的估算是：當語料是文字文件、問題是單實體查找時，傳統 RAG 以 30% 的投入達到 GraphRAG 結果的 85–90%，上線週期 6–8 週（圖譜建構 12–16 週）。一個需要在 11 月就開始從服務手冊回答技師問題的精幹團隊，先上向量檢索。

第二，文件檢索的地板還在抬高。Perplexity 的 pplx-embed-v2-late（10 月 7 日發布，MIT 授權）把開放權重的晚交互嵌入推到 MADQA 92.4%——對 800 份真實 PDF、18,000 多頁的代理人問答——直接檢索文字、影像和 PDF 整頁，不需要 OCR。在非結構化文件這條軸上，向量檢索是一個移動目標，而知識圖譜彌合的差距並非文件問答的差距。

第三，向量生態已經知道自己的弱區並做了結構性補償。盤點十款自架引擎的 vdf.ai 2026 年 10 月彙總顯示，多租戶已在索引層得到處理——Qdrant 按租戶鍵分分區、大租戶會被升級到獨立 shard，Weaviate 採用每租戶一 shard 模型——而因為稠密向量「會漏掉合約號、錯誤碼這類精確 token」，混合檢索已在引擎內部完成融合。換句話說，權限過濾和關鍵字召回已經作為工程問題在向量堆疊內部解決。向量堆疊永遠解決不了的，是語義：它沒有地方存放「客戶」「供應商」「風險」在你的組織裡意味著什麼，也無法回答為什麼檢索到的兩條記錄彼此相關。

被治理的上下文層多出來的東西

圖形驅動上下文層多出四樣純向量 RAG 根本無法表達的東西——第四樣是購買判據。

顯式關係。 檢索到的塊只是暗示了關係；圖譜明言關係。微軟 GraphRAG 的數字——多實體查詢上 86% 對 57% 的完整性——是這句話的測量版：當問題需要從產品走到替代件、再走到分店可用庫存時，相似度檢索每一跳都得猜。

業務語義的唯一所在。 Neo4j 的 6 層 Business Ontology 把組織的定義——流程、領域術語、資料產品、實體系統、工具、執行期知識——搬進所有代理人共同讀取的一張圖，而不是每個代理人各自重新學習（Neo4j 部落格）。SanjMo 的 Principal Sanjeev Mohan 在新聞稿裡點出了向量堆疊跨不過去的那道坎：「Context 不只是更多資料。它真正關乎關係：不只是兩個東西有連接，而是為什麼、怎麼連接的。這正是圖所原生建模的。」

每條答案的出處溯源。 Context Engine 的記憶層「記錄代理人的推理與操作路徑，形成企業經驗的永久檔案」（新聞稿）。答案帶著產生它的路徑一起到來。向量檢索給你的只是排名最高的那些塊。

攜帶權限的檢索路徑。 Neo4j 的 Context Build and Runtime 內建治理，「確保它們只能存取被授權存取的資料」——策略隨檢索而行，而不是事後過濾器。在向量堆疊裡，租戶過濾只是你選定的那家資料庫的索引工程特性（vdf.ai 彙總記錄了 pgvector、Qdrant、Weaviate 的實作差異之大），還要應用層重新實作一遍規則。

這個模式不必等待私有預覽的軟體就能建構。在本站 RFQ 系列文章背後的參考實作裡，報價桌 MCP 模組對外只暴露一個 inquire_catalog 工具：它把自然語言問題路由到知識圖譜引擎並返回排名結果——一次被治理的呼叫同時完成檢索與語義——交易側則由一組獨立可用性扣留（hold）工具負責。讓它被治理的是工具邊界，不是檢索器：每一次呼叫都經過一個執行裝飾器，把狀態、時長與淨化後的承載寫入 DynamoDB 裡的稽核模型；租戶範圍由儲存層的分區鍵強制。關於模組程式碼標準的文章把這個模式做了端到端記錄。

決策矩陣

實務中，五個問題把兩種架構分開。對每個問題如實給自己的工作負載打分；圖形一欄有兩行以上命中，上下文層就值得那 12–16 週的建設。

買方問題	選圖形驅動上下文	純向量 RAG 就夠
問題的形態是什麼？	多實體、沿關係行走（「本週五前，這個件號有哪些已核准的替代件在波士頓 DC 有庫存？」）—— 86% 對 57% 的差距在這裡	文件文字上的單實體查找（「手冊對 E-204 錯誤碼怎麼說？」）
語義住在哪裡？	分散在系統和團隊之間——「客戶」「供應商」「風險」需要代理人共讀的一個定義	就在文件裡——文字即語義
治理要能出示什麼？	答案級出處：決策路徑、授權它的策略——Gartner 的生命週期分離	內容級存取控制：索引上的租戶過濾與承載權限
必須多快上線？	12–16 週，外加持續的本體維護——當代理人要作用於業務資料時，值得	上線 6–8 週——用途是文件問答時的正確第一步
每個季度什麼會變？	語義在變（新產品線、改名檔位、新合規規則）——改圖，不改代理人	語料在變——夜間重新嵌入即可跟上

有兩行值得誠實標註。查詢成本上，GraphRAG 檢索比向量相似度更重——賣圖的一方自己承認，實施指南的單查詢運算（圖更新按工單計為 O(N)，文件檢索為 O(1)）也解釋了為什麼高吞吐、淺問題的負載應該留在向量側。而「第三類消費方」的敘事：它是 Neo4j 的發布故事，但底層觀察早已存在——帳戶狀態「二」的問題在每一家中型 B2B 公司都真實存在，無論你買什麼產品去修。

並排對比：兩種架構如何回答五個買方問題，每個主張背後的實測證據一併給出。

比買什麼產品更重要的部署方控制

Gartner 的定義列舉出讓上下文成為「資產」的三項能力：被建構、被治理、被交付。仔細讀廠商頁面，各自交付了一部分——Context Studio 是控制平面，建置執行環境強制授權，記憶層記錄決策。沒有一家端到端交付全部三項，而其中兩項在結構上就屬於你。

出處溯源是控制，不是功能。 帶記錄決策路徑的答案，只有當路徑是只追加式、且比產出它的代理人活得更久時，才是稽核產物。在參考實作裡，每一次 MCP 工具呼叫都把狀態、時長與淨化後的承載寫入按租戶劃分的稽核模型——這就是智慧代理治理架構的模式。無論你的上下文層是 Neo4j 的，還是一張自有的圖，關於代理人檢索了什麼、作用於什麼的記錄，都應該屬於你的邊界。

權限攜帶必須活著越過最後一跳。 在圖內做過濾的上下文平台，依然要經由工具邊界連接代理人。如果這條邊界不攜帶身份——每次呼叫一個經認證的主體、按租戶與角色劃定範圍——平台的授權就只是建議。governed modules 模式把驗證放進攔截每個請求的中介層（MCP 安全文章），這樣 Neo4j 在圖內強制執行的策略，才不會被一個未劃定範圍的工具呼叫繞過。

生命週期分離是你的架構選擇。 品類的核心主張——組織知識活得比單個代理人久——只有在你的代理人是上下文服務的消費方、而不是把上下文內嵌到自身時才成立。實務上：代理人透過查詢引用上下文，絕不引用固定快照；下線一個代理人刪掉的是代理人狀態，不是圖狀態；智慧代理人記憶模式文章的短期/長期切分，正對應廠商如今銷售的圖形原生記憶層。

給中型團隊的一條實踐序列：在向量檢索擅長的文件問題上先上純向量 RAG；建一張窄的、單一領域（產品、供應商或客戶）的業務本體，配 NVIDIA 描述的認證環節；在出處重要的地方，經由一兩個被治理的 MCP 工具把它暴露給代理人；只有當某個用例問出一個向量檢索答錯且代價高昂的關係問題時，再把本體拓寬。

相關閱讀

• GraphRAG 實施指南：從文字文件到生產級知識圖譜檢索 —— 選擇圖一側時的五階段建置管線與成本陷阱
• 智慧代理人生產堆疊正式落地：深入 NVIDIA GTC 柏林參考架構 —— Agent Knowledge Foundation 的模型與函式庫在完整生產堆疊中的位置
• 智慧代理人記憶設計：三種失敗模式與強制底線 —— 圖形原生記憶層所實作的短期/長期記憶切分

申請範圍確定的建置

一個代表性的建置：一家把報價台跑在 NetSuite 上、檔位定價放在 Postgres、替代件知識存在四位資深估價員腦子裡的工業分銷商。我們在產品、替代件、價格檔位與分店庫存之上建一張知識圖譜；把它封裝成一個 MCP 模組，帶每次呼叫的稽核日誌、可用性扣留與取消快照工具，都歸團隊所有；代理人框架保持可替換。報價回答帶著產生它的路徑回來——替代了哪個件、落在哪一檔、分店還有多少庫存——以小時計，而不是以天計。

申請範圍確定的建置：一週發現期。無論是否與我們合作，你都會得到一份系統清單、工作流程圖和固定範圍。